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

产品团队在每个 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” -> 不确定性：“单元号是从带有背景噪音的通话录音中提取的” -> 验证：“与客户记录核实”。这是一个用户可以据此采取行动的短字符串，它与答案同时生成，而不是在答案之后计算出来的。

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

• 强制模型即使在有信心时也要输出叙述。 如果你只在模型认为自己可能出错时才要求不确定性叙述，模型会认为自己是对的，然后你什么也得不到。将该字段视为必填项，并允许模型在有依据时说“无实质性不确定性”。空叙述也携带信息。

• 限制在可验证的主张上，而不是感觉上。 “我不确定这是否正确”是无用的。“我还没有验证该 SKU 是否有库存”是可操作的。模型需要明确的指令，即不确定性叙述必须指明一个用户可以检查的事实，而不是一种感觉。

• 限制叙述长度。 最多三到五个子主张。超过这个限度，你就以另一种形式重现了原始问题——一堆用户会略过并忽略的模棱两可的废话。这种约束是为了引出与决策最相关的不确定性，而不是所有的不确定性。

• 将不确定性叙述与拒绝回答区分开。 叙述是“我回答了，这是我不确定的地方”。拒绝是“我不会回答，因为我太不确定了”。这两者具有不同的下游 UX。将它们混为一谈会产生一个对所有内容都含糊其辞的模型，这会引导用户忽略这些提示。

• 将叙述锚定到特定的输出片段，而不是整个答案。 “中间段落提到的日期我尚未验证”优于“我对其中的部分内容有些不确定”。用户需要一个指向标，而不是一个伪装成文字的全局评分。

生成叙述比生成置信度数字成本更高——它消耗 token，且通常与答案在同一次推理中生成。在实践中，根据模型和答案长度，这会带来 5–15% 的延迟成本。这个成本是值得付出的，因为另一种选择——一个无人理睬的置信度数字——虽然付出了计算代价，但在用户层面上没有带来任何决策质量的提升。

评估方法论也必须改变

置信度评分的标准评估是校准：按声明的概率对预测进行分组，测量每个组中的经验准确率，计算预期校准误差（Expected Calibration Error）。对于概率来说，这是正确的评估方式，但对于叙述来说则是错误的。一个完美校准的概率仍然无法改变用户行为。而一个命名了正确具体主张的、即便校准不完美的叙述却可以。

对不确定性叙述的评估应侧重于可操作性。评分标准需要三个正交维度：

1. 明确性 (Specificity)。 叙述是否指明了可验证的子主张？“我不确定”是不合格的。“我不确定单元号”是合格的。这根据一个二元标准进行评分：用户仅阅读叙述，能否确定一个有限的验证动作？

2. 覆盖率 (Coverage)。 在答案的实际错误中，有多大比例在叙述中被提及？这就是召回率。一个完美标记了单元号但漏掉了错误街道名称的叙述，其覆盖率为 50%。你通过收集答案级的错误，然后检查每个错误是否在叙述中体现来构建此评估。

3. 精确率 (Precision)。 在叙述标记为不确定的项中，有多少比例实际上是错误的？一个标记所有内容的叙述具有 100% 的覆盖率和约 10% 的精确率，这会引导用户忽略它。你在数字徽章中看到的开销崩溃同样会发生在冗长的叙述中。

有趣的动态在于，这三个维度的权衡方式与校准误差不同。你可能有完美的校准但明确性极差（每个答案都有概率，但没有解释）。你可能有极好的明确性但覆盖率极差（模型在每个答案中指出了一个明显的不确定性，却漏掉了三个细微的错误）。优化其中一个并不代表能优化其他维度，而共同的最优解更接近于“适度的中等粒度对冲”，而不是“高准确度的概率”。

一个实际的方案是：从生产环境中保留一组带标签的错误集，其中每个错误都已根据哪个子主张出错进行了分类。在开启不确定性叙述的情况下运行模型。对于每个例子，评分叙述是否指出了实际错误的子主张（覆盖率），是否仅指出了最终证明是错误的子主张（精确率），以及每个指出的主张是否足够具体，以至于用户可以在 30 秒内完成验证（明确性）。随时间跟踪这三个指标；将任何单一维度的下降视为回归。

架构的演变

将不确定性视为概率，与将其视为叙述，是两种完全不同的架构决策，而非同一原语的不同表现形式。概率路径将不确定性置于模型的末端——校准 Logits，暴露一个数值，渲染一个徽章。叙述路径则将不确定性置于回答内部——在同一次前向传递中生成，对其进行 Schema 约束，并将其作为内容字段进行评估 (Eval)。

这会对上游产生影响。如果不确定性是内容，那么它就是系统提示词的职责。提示词必须指示模型：哪些算作可验证的声明，哪些内容过于模糊而不能呈现，以及细粒度该如何把握。它是评估面的一部分。当你升级模型时，它是回归测试集的一部分。它是少样本示例的一部分。它是模型生成的每一个产物的一部分。

它还消解了 AI 用户体验 (UX) 中长期存在的一个伪命题：“我们是否应该向用户展示置信度指标？”在叙述框架下，正确的答案是“始终展示，因为它是回答的一部分，而没有它的回答就是隐瞒真相的谎言。”一个在生成回答时不去指明它未核实的内容的模型，是一个预先剥离了对其决策最相关信息的模型。

我所见过的成功团队不再将不确定性视为 UI 元素，而是将其视为生成需求。他们针对叙述而非概率编写评估 (Evals)。他们训练产品设计师去思考“用户会核实什么”，而不是“徽章变红的阈值应该是多少”。他们放弃了校准冲刺，发布了叙述模式，并发现用户在协同任务中的准确性有了显著提升，而他们花六周时间调优的徽章则被悄然移除。

徽章无法打动任何人。字符串可以。