拒绝还是上报：置信度门控 AI 中的双阈值问题

大多数生产环境中的 AI 功能在发布时只带有一个置信度阈值。在阈值之上，模型给出回答；在阈值之下，用户会得到一句生硬的“我不确定”。这个单一的数值同时承担着两个完全不同的任务，这就是为什么即便你对已回答查询的准确率看起来不错，但信任度指标却已经连续两个季度下滑的原因。

正确的设计至少应该有两个切分点。一个“弃权”（abstain）阈值设在低位：低于该值时，模型拒绝回答，因为此时保持沉默比给出任何答案都更有价值。一个“升级”（escalate）阈值设在中间：在两个切分点之间，系统将案例交给人工审核员，而不是直接将其丢弃。将它们合并成一个刻度盘，你发布的产品在出错时和不确定时会让人感到同样无用——在用户只需打开另一个标签页就能找到免费替代品的市场中，这是最糟糕的处境。

这并不是什么新鲜想法。拒绝选项分类器（reject-option classifier）的文献自 20 世纪 70 年代以来就一直在主张拆分阈值，将“歧义”拒绝（输入介于已知类别之间）与“距离”拒绝（输入远离任何训练数据）区分开来。生产环境中的 AI 团队总是在以惨痛的方式重新学习这一教训，通常是在首次发布大约六个月后，当支持队列中挤满了询问“这玩意儿是坏了还是怎么了”的人时。

为什么单一数值会欺骗你

单一置信度阈值假装“模型不该回答”和“应该由人工回答”是同一个决策。事实并非如此。

考虑一下在阈值 0.7 时会发生什么。置信度为 0.4 的查询与置信度为 0.65 的查询得到了相同的处理：两者都会收到弃权消息，在用户看来完全一样，并且都导致了回答率的同等下降。但这是截然不同的两种情况。0.4 的查询超出了模型的能力范围——无论投入多少审核时间都不会改变这一点，正确的做法应该是告诉用户“本产品无法为你提供帮助，这里有其他寻找帮助的途径”。而 0.65 的查询则是“差一点就成功”的情况，五分钟的人工审核就能产生用户所看重的正确答案。将它们视为相同的结果，意味着团队正在优化更容易的指标（提高阈值以减少幻觉），却悄悄破坏了更难的指标（在灰色地带为用户提供实际帮助）。

信任度的计算是非对称的，这往往令新团队感到惊讶。关于用户对 AI 功能感知的实证研究一致表明，当频繁发生时，生硬的“我不知道”对信任度的损害速度与言之凿凿的错误答案大致相同。用户并没有一个清晰的心理模型来区分“模型拒绝回答”和“模型回答失败”——他们只知道自己没有得到帮助。如果你的单一阈值产生了 25% 的弃权率，你正在承担“25% 的时间是错的”所带来的信任代价，却没有任何“偶尔正确”带来的收益。

必须先行落实的校准

在选择两个阈值之前，你需要一个有意义的置信度信号。大多数团队跳过了这一步，从一个根本不存在的校准曲线上选取数值。

Token 概率是最常被滥用的信号。它看起来像是一个置信度分数，API 可以免费返回它，而且它与正确性的相关性勉强够用，以至于在一段时间内没有人质疑它。问题在于这是有据可查的：Token 概率将词法不确定性（我会发出几种表述中的哪一种）与事实不确定性（我是否知道答案）混为一谈。一个 95% 确定下一个 Token 是 "Paris" 的模型，对于 Paris 是否是正确答案没有提供任何有用的信息。最近的测量显示，在实际准确率仅为 39% 的任务中，平均表达置信度为 91%，而语言化置信度（要求模型输出一个百分比）甚至比没用更糟糕，因为无论模型知道什么，它都会聚类在 90–100% 的范围内。

效果更好的是基于样本的一致性（sample-based agreement）。对于同一个问题，在非零温度下询问模型五次：如果答案趋于一致，模型很可能知道答案；如果答案在多个看似合理但各不相同的选项之间发散，模型就在产生幻觉。这需要真实的预算支持——五次样本并行是五倍的成本——但它能产生一个经得起生产环境流量检验的置信度信号。一些团队将其与一个较小的验证器模型配对，由验证器根据检索到的证据对答案进行评分，这提供了置信度的第二个维度，它的失效模式与样本一致性不同，并且可以与之结合使用。

无论你选择哪种信号，最终产出都应该是一条校准曲线：x 轴为预测置信度，y 轴为观察到的准确率，理想情况下是一条对角线。如果曲线远离对角线，任何阈值的选择都救不了你。阈值是校准的下游，而校准则是评估纪律的下游——而大多数团队在发布第一个版本时并不具备这种纪律。

两个阈值、三个区域、三个产品时刻

一旦信号经过校准，架构就会变得简单明了。你选择两个切分点，将置信度范围划分为三个区域，每个区域对应不同的产品行为。

高置信度（高于上限阈值）：模型直接回答。延迟预算很紧，UX 是对话式的，评估目标是“既然我们选择了提供答案，那么答案是否正确”。这里的指标是已回答查询的准确率（accuracy），这也是大多数团队已经在追踪的指标。

中等置信度（介于两个阈值之间）：案例会上报给人工审核员。延迟预算从秒级变为分钟级或小时级，UX 变为“我们正在调查此事，这是你的追踪链接”，评估目标是“审核员提供的答案是否比模型给出的更好”。这里的指标是上报收益（escalation yield）——即在上报的案例中，有多少比例产生了明显优于模型草稿的结果。

低置信度（低于下限阈值）：模型拒绝回答，UX 将用户重定向。这不只是没有后续的“我不知道”；而是“我无法处理这个，但这里有相关的文档/联系方式/表格/专家”。评估目标是“重定向是否引导用户进入了有用的下一步”，指标是恢复率（recovery rate）——即在被拒绝的案例中，有多少比例在 AI 界面之外获得了成功解决。

三个区域，三种完全不同的产品设计。三种不同的 SLA。在任何规模超过初创公司的企业中，这三个区域由三个不同的团队负责。单阈值版本往往假定底部两个区域是同一个产品时刻，而发布该版本的团队随后要花两个季度的时间来解释，为什么“弃权”率和“上报”率不能简单相加来得出一个有意义的指标。

审核队列是硬约束，而非脚注

双阈值设计中隐藏的陷阱是：上报阈值受限于大多数团队未建模的因素——人工审核队列的吞吐量。如果你的模型每天产生 100,000 个案例，上报率为 15%，那么你每天需要投入 15,000 个案例的审核时间。乐观估计平均每个案例审核时间为 3 分钟，那就是每天 750 个审核工时，大约需要 95 名全职审核员进行标准班次的工作。大多数团队只有在阈值已经配置完成，且队列在第一天午餐时间就溢出后，才会发现这个数字。

正确的做法是从队列出发。审核能力是一个固定量——以每天的审核工时衡量，且由于季节性波动和人员流动，它的弹性比工程能力更差。必须调整上报阈值，使弃权线之上、回答线之下的流量能够容纳在队列中，并为流量高峰留出余量。这是一个排队论问题，而不是模型调优问题。不对此建模的团队会看到队列溢出，支持团队会开始默默地丢弃案例或为了赶 SLA 而进行批量处理，信任指标将因此暴跌，因为名义上的上报比完全不上报更糟糕。

加载中…