5 篇博文 含有标签「uncertainty」

你想要表现得诚实。你在智能体给出的每个答案旁边都标上了一个小小的 92%。当智能体第三次以 92% 的置信度给出错误答案后，你的用户就不再看那个数字了。他们并没有因此生气。他们只是学会了——就像人类在面对失灵信号时总会学到的那样——仪表盘上的指针并没有连接到引擎。数字还在那里。生成它需要消耗你的 token。但它不再能为任何人的决策提供参考。

这种失败模式是置信度校准（calibration）UX 研究不断重现的：呈现概率是一种信任承诺，而且这种承诺是单向的。一旦数字在用户的使用体验中被证明与正确性无关，这个分数就失去了意义——你为了展示它而投入的信任也随之崩塌。你无法在事后通过修正数字来挽回局面。这个数字现在只是个装饰品。

在每个 AI 功能的演进过程中，审阅者总会提出一个听起来很合理的问题：“我们能不能让模型告诉我们它的置信度（confidence），这样我们就可以把低置信度的回答路由给人工或备选方案？”这听起来像是一份免费保险。你在输出 schema 中添加一个 confidence 字段，模型尽职尽责地填好它，现在你就有了一个可以调节的旋钮。发布吧。

那个旋钮并不是免费的，更糟糕的是，它通常没有连接到任何实际逻辑上。置信度数字只是模型乐于生成的一个 token 序列，模型并没有义务让它具有实际意义。团队支付真实的 token 和延迟来获取它，却从不检查它是否与正确性相关，然后根据它路由生产环境的流量，就好像 “0.9” 真的代表 90% 的可靠性评估一样。它就像一个用螺栓固定在仪表盘上的压力表，但玻璃后面其实什么也没连。

这篇文章讨论了两个没人定价的成本：生成置信度字段本身的单次请求税，以及信任一个未校准的数字来做路由决策所带来的更巨大的成本。

大多数构建多智能体系统的团队，把大量时间花在授权信任上：智能体 B 被允许执行哪些操作、可以调用哪些工具、能访问哪些数据。这是一个重要的问题。但还有第二个信任问题同样关键，却鲜少得到足够重视——而正是它在实际生产系统中造成严重故障。

这个问题是认知层面的：当智能体 A 将任务委托给智能体 B 并收到答案时，A 应该在多大程度上相信 B 返回的内容？

这不是 B 是否被授权回答的问题，而是 B 是否真的有能力回答的问题。

GPT-4 在用自身置信度评分区分正确答案与错误答案时，AUROC 仅约为 62%——这几乎与随机猜测（50%）相差无几。无论正确与否，模型的表达都同样自信流畅。如果你构建的生产系统默认高置信度响应是可靠的，那你实际上在依赖一个近乎随机的信号。

这就是知识边界信号问题，它处于绝大多数真实 LLM 质量故障的核心。模型不知道自己不知道什么——更准确地说，它内部其实知道，却无法可靠地表达出来。工程挑战不在于让模型拒绝得更多，而在于设计能将不确定性转化为可操作信号的系统，同时又不让产品体验显得残缺。

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

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