跳到主要内容

置信度描述而非评分:为什么 0.87 的徽章无法打动任何人

· 阅读需 12 分钟
Tian Pan
Software Engineer

产品团队在每个 AI 建议旁边都附带了一个置信度徽章。≥85% 为绿色,60–84% 为黄色,低于此数值为红色。六周后,他们运行了一次 A/B 测试,发现在任何阈值下用户行为都没有变化。置信度为 0.92 的误报被接受的比例与置信度为 0.61 的误报完全相同。团队的直觉是调整校准——拟合一个温度缩放层(temperature scaling layer),重新生成徽章,再次运行 A/B 测试。数据变了,但行为没变。

问题不在于模型没有校准好,尽管它几乎肯定没校准好。问题在于校准后的概率是错误的输出。用户可以据此行动的信号不是模型“有多确定”,而是“模型具体没检查什么”。一个 0.87 的徽章无法告诉用户任何可以验证的信息。“我对地址相当有信心,但我还没有核对单元号”则准确地告诉了他们该看哪里。

这是不确定性的学术框架(其目标是获得与经验准确性相匹配的概率)与生产框架(其目标是生成用户可以采取行动的字符串)之间的差距。这两者被混为一谈的时间太长了,以至于大多数团队发布了学术产物,并假设用户会将其转化为行动。但用户并不会。他们会选择无视。

概率徽章是 UI 的死胡同

关于自动化偏见(automation bias)的文献清楚地给出了坏消息:用户过度信任自信的 AI 输出,而当置信度信号与其现有信念冲突时,他们会忽略该信号。2024–2025 年的研究表明,数字形式的置信度评分与其说是决策输入,不如说更像是一个橡皮图章——原本就想接受建议的用户认为 0.61 为“足够好”,而原本就想拒绝建议的用户则认为 0.92 是“模型过拟合了”。

出现这种情况有一个结构性原因。概率是一个汇总统计量。它将模型不确定的每一个原因都压缩成一个数字,而这个数字并不能告诉用户具体是哪个原因。是模型在训练中没见过这种确切模式?是输入存在歧义?是工具调用被截断了?还是检索到的上下文自相矛盾?所有这些都塌陷成同一个 0.73,而 0.73 无法告诉用户该去哪里核查。

用户实际的决策问题不是“模型有多自信”,而是“在我信任这个结果之前,我应该检查什么”。标量无法回答这个问题,因为答案指向的是特定的字段、主张或假设。对于正在进行的决策来说,概率这种信号的形式是错误的。

校准研究花了十年时间试图让这些标量变得更准确。2025 年尖端模型的预期校准误差(Expected Calibration Error)在 0.05 到 0.20 之间,具体取决于任务——这意味着显示的概率平均偏差在 5 到 20 个百分点。对齐训练往往会让情况变得更糟,而不是更好;RLHF 期间的偏好塌陷系统性地推动模型走向过度自信,因为自信的回答会得到奖励。事后校准技术(如温度缩放)可以挽回一部分。但这些都无法改变用户行为,因为用户从一开始就没有在阅读那个数字。

真正能改变用户行为的是什么

在这方面,HCI 文献比校准文献更有用。FAccT 2024 年的一项研究发现,第一人称的不确定性表达(如“我不确定,但是……”)显著降低了用户对错误 AI 建议的认同感,并提高了用户在共同任务中的准确性——而一般视角的对冲表述(如“目前尚不清楚,但是……”)则没有产生统计学上的显著影响。语法人称很重要:用户对一个承认自己不确定性的模型,比对一个抽象地暗示不确定性的模型反应更积极。

另一篇关于 AI 辅助决策中言语化不确定性(verbalized uncertainty)的 2025 年论文发现,用户更喜欢“中度”的言语化不确定性——即承认局限性但听起来不被局限性压垮的语言——而不是自信的断言或不断的闪烁其词。信任度和任务表现都在这种中间设定下达到顶峰,而且这种效应独立于模型的实际准确性。用户是对语言的质感做出反应,而不是底层的概率。

概率徽章方法中所缺失的效应是具体性(specificity)。“我相当确定”没有帮助。“我相当确定,但我还没有检查这个地址是否有单元号”则非常有帮助。用户现在有了一个闭环操作:查看单元号,做出决定。叙述点名了一个可验证的主张,用户可以在几秒钟内完成验证。概率徽章只会显示 0.84,而用户会根据先入为主的偏好来接受或拒绝。

这就是不确定性叙述能做到而概率评分做不到的事情:它将验证工作从“模型对吗”(在有限时间内无法回答)转移到了“这个具体主张对吗”(在几秒钟内即可回答)。叙述将模型的剩余不确定性压缩成最小的主张,一旦核实,不确定性即告消除。

将不确定性叙述作为一等输出

实现模式与校准层不同。你不需要将 logits 后处理成校准后的概率;而是要求模型在给出答案的同时,输出一个结构化字段,指明它对哪些子主张有信心,对哪些没有,以及用户可以检查什么来解决每个不确定的子主张。

输出 Schema 为每个不确定的子主张包含三个字段:主张、不确定性来源和成本最低的验证方式。“地址:1234 Elm St, Apt 7B” -> 不确定性:“单元号是从带有背景噪音的通话录音中提取的” -> 验证:“与客户记录核实”。这是一个用户可以据此采取行动的短字符串,它与答案同时生成,而不是在答案之后计算出来的。

一些不那么显而易见的工程要点:

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates