跳转至

P1-6.3 AI 在哪些地方使用概率性判断

Section ID: P1-6.3 Version: v2026.07.20

6.2 已经区分了 uncertainty、probability 和 stochastic。这一节把这个区分推进成一个更实际的问题：在真实 AI 系统里，概率到底出现在哪些位置，这些数字又该怎样谨慎地读？

说 AI 使用概率，并不等于它“随便回答”。更准确地说，当信息不完整、候选结果不止一个时，系统会用数字去比较不同结果看起来有多可信。

在 Part 1 里，这一节先固定“概率式数字如何在真实 AI 系统里被使用”的基准。6.2 先固定了词汇基线，这里则关注这些数字在 classification、prediction、generation 和 decision making 里分别扮演什么角色，以及为什么它们不能被直接读成最终答案，或直接读成负责任的业务决定。

这一节不会讲概率本身的数学。条件概率、Bayes' rule 和概率分布会在 Part 2 再回来。

这里也不会展开 LLM 的完整生成算法。temperature、top-p 和 sampling 会在后面的 Part 6 再回来。

这里先固定一个更窄的基线：

概率会出现在分类、预测、生成和决策中，
但概率输出本身并不是最终答案，也不是最终负责的决策。

把概率输出读成判断材料的基准

  • 理解 probability estimate 在分类里是怎样使用的。
  • 理解预测任务里不仅会有一个值，也可能会同时给出围绕这个值的不确定性。
  • 在入门层面理解：生成为什么会和“从多个候选中做选择”连在一起，以及为什么这里会出现 temperature。
  • 理解概率输出只是判断材料，而不是最终决策本身。
  • 对为什么需要 calibration、threshold 和人工复核形成直觉。

三个基准

基准 为什么重要 本节需要达到的理解程度
在分类中，概率分数是在比较候选项的可信程度 这样能减少把高分直接读成真相的错误。 0.68 表示在当前设置下某个候选被打得最高，不表示它绝对为真。
在预测和生成中，不确定性和候选选择也同样重要 这样不会把概率的作用缩窄成只属于分类。 不能只看单个数字，还要看范围、候选和选择过程。
概率输出并不等于最终业务决策 这能说明为什么策略、阈值和人工复核仍然重要。 模型分数后面还会接着服务策略、成本判断和必要时的人工复核。

先做一个角色拆分：

术语 极短含义 本节里的作用
probability estimate 表示某个候选有多可信的数字 分类和预测里的比较基准
threshold 看到分数后切换行为的分界线 自动处理、暂缓和人工复核之间的分线
calibration 检查某个分数能不能像真实可信度那样读 用来判断该把 0.80 信到什么程度
generation setting 调整输出候选选择方式的值 用于控制输出波动，例如 temperature
decision making 把模型数字和成本、策略一起纳入后决定行动 把概率接到实际服务行为上的阶段

一眼看全局

概率式视角会出现在 AI 系统里的多个位置：

出现位置 例子 概率在那里做什么 主要注意点
分类 把客服消息分成配送、退款或支付 比较候选标签的可信程度 最高分不自动等于真相
预测 预测到达时间、需求或价格 表达一个值，有时也表达这个值周围的不确定性 只看平均值可能会误导判断
生成 选择下一个 token、句子或图像候选 在多个候选中控制“如何选一个” 同一输入在不同设置下可能给出不同输出
决策 决定自动处理、暂缓还是人工复核 在成本和策略约束下把概率接到行动上 概率本身不能替代负责任的判断

分类：哪个候选看起来更可信

classification 是把输入划到一个或多个预定义候选中的任务。比如客服消息可以被分成下面这样：

候选标签 概率估计
配送咨询 0.68
退款咨询 0.21
支付咨询 0.08
其他 0.03

这表示配送看起来是最可信的候选。但 0.68 并不表示“配送绝对为真”。它只是表示：在当前输入、数据、模型和计算方式下，配送这个候选得分最高。

Google 的 Machine Learning Glossary 说明，在 multiclass classification 里，softmax 会为各个可能类别计算概率，并让它们的和等于 1。scikit-learn 也说明，在分类任务里，人们常常不仅想拿到类别标签，也想拿到对应标签的概率。

在实际系统里，接下来常常会定义 threshold：

条件 处理方式
最高分在 0.90 以上 自动分类
最高分在 0.60 到 0.90 之间 提示候选并交给人工复核
最高分低于 0.60 追问更多信息或先暂缓

这个阈值不仅是技术参数，也会受误判成本、用户不便、安全要求和法律责任影响。

概率输出可能还需要校准

模型输出 0.80，并不自动保证这个数字可以被当作真实世界里的 80% 可信度。scikit-learn 说明，有些模型对类别概率的估计并不好；而在 well-calibrated classifier 里，predict_proba 的输出才更适合被直接读成类似可信水平的东西。

更安全的起点是这个问题：

如果把模型说 0.80 的案例都拿出来，
其中大约 80% 真的会是对的吗？

这就是 calibration 的基本问题。

这一节不会去计算校准，只先留下一个重要注意点：模型给出的概率数字，并不自动等于可信的现实概率。

预测：有时范围比单个数字更重要

预测并不只是在选标签。它也可以是预测某个数值，比如配送到达时间、下个月需求、服务器成本或商品价格。

假设我们在预测配送到达时间：

输出方式 例子 解释
点预测 明天下午 3 点到达 给出一个代表值
区间预测 明天 1 点到 6 点之间到达的可能性较高 把不确定性一起给出
概率式预测 3 点前到达 60%，6 点前到达 90% 把时间相关的可能性写成数字

Google 的 glossary 说明，probabilistic regression model 可以同时生成预测值和这个预测值的不确定性。

这很重要，因为两个场景可能平均预测一样，但不确定性完全不同：

场景 平均预测 不确定性
同城当日配送 4 小时 低
暴雨中的长距离配送 4 小时 高

平均值一样，不代表业务判断也该一样。

生成：应该从多个候选中选哪一个

generative AI 会生成文本、图像、音频、代码等输出。即使在这里，系统面对的也不是唯一答案，而是多个候选之间的选择问题。

假设我们要继续这句话：

当 AI 处理不完整信息时

接下来的表达可以有很多种：

候选 感觉
它会使用概率 更偏说明性
它会等待更多证据 更偏判断过程
它会比较多个可能性 更一般化
它会请求人工复核 更偏服务运营语境

Google 的 Machine Learning Glossary 把 temperature 说明成：控制模型输出随机程度的超参数。更高的 temperature 往往会让输出更发散，更低的 temperature 则往往让输出更保守。

这里的关键注意点和前面一样：temperature 不是训练学出来的模型参数，而是运行模型时用于调节输出选择方式的设置。

所以，这里的基线是：

生成和“从多个候选里选一个”有关，
temperature 之类的设置则用来调节这种选择的波动性。

决策：概率是判断材料，不是判断本身

在 AI 系统里，概率经常会进一步接到行动选择上：

模型输出 可能行动
配送咨询 0.95 自动回复配送说明
配送 0.68，退款 0.25 把候选建议给客服人员
所有候选都低于 0.40 追问更多信息
风险交易 0.82 先暂缓并复核，而不是立刻自动封锁

重要的是：概率不能代替决策。真正的决策还会同时纳入成本、风险、政策、用户体验和法律责任。

例如在垃圾邮件过滤里，把正常邮件误判成垃圾邮件的代价可能很高；在医疗辅助系统里，漏掉危险信号可能很严重；在客服自动化里，低可信度的自动回复可能会直接放大用户不满。

所以，概率输出应该和这些问题一起读：

如果这个数字错了，会产生什么成本？
哪些位置必须有人来复核？
阈值是谁在什么责任框架下设定的？

同一个数字，在不同语境里含义也不同

哪怕是 0.70 这样的同一个数字，放到不同任务里也会有不同含义：

语境 0.70 可能表示什么 注意点
消息分类 配送咨询候选的分数 先确认它是不是经过校准的概率
图像分类 某个类别的概率 数据分布变了，含义也可能跟着变
配送预测 在某个时间前送达的可能性 要连同条件和预测范围一起看
生成 候选选择过程里的相对可能性 它不保证输出质量或事实性

所以看到概率数字时，第一个问题应该永远是：

这是谁的概率？它是在说“什么事情”的概率？

概率数字不会自己携带完整意义。它必须放回任务、数据、模型、校准条件、阈值和责任结构里一起理解。

检查清单

  • 能说明 probability estimate 在分类里是在表达候选标签的可信程度。
  • 能说明 threshold 既是技术设置，也是成本与责任问题。
  • 能说明 calibration 是在检查模型概率输出能否被读成可信水平。
  • 能说明预测任务里往往不仅要看一个值，也要看它周围的不确定性。
  • 能说明生成任务里存在候选选择问题，而 temperature 和输出波动性有关。
  • 能说明概率输出不是最终决策，而是决策材料。
  • 能说明模型分数、阈值、人工复核和最终决策分别在哪里分开。
  • 能把概率数字放回服务语境解释，而不是读成 概率数字 -> 直接就是答案。

来源与参考资料