拒绝还是上报：置信度门控 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 而进行批量处理，信任指标将因此暴跌，因为名义上的上报比完全不上报更糟糕。

在生产环境中实际能维持的上报率，对于大多数面向消费者的功能来说，通常落在 8–15% 的范围内。只有在每个案例的价值足以支撑专门审核团队的领域（法律、医疗、金融咨询），更高的比例才可行。如果你最初的初步估算产生了 30% 的上报率，问题不在于阈值——而是你的模型尚未准备好适应你所追求的部署形态。要么投入资源进行更好的校准以压缩灰色地带，要么缩小功能范围以专注于高置信度的意图，或者接受较低的覆盖目标并调高弃权阈值。

每次都会发生的组织失效模式

双阈值设计在生产环境出故障之前，往往先在组织架构上失效。这种模式非常一致，你甚至可以从人员配置图中预见它。

负责调优阈值的工程师坐在 AI 团队。他们的评估面是校准曲线、回答率指标和离线评估集。他们优化的目标是“在评估集上实现预期效用最大化的阈值”，然后发布一个在仪表盘上看起来很棒的数字。

审核队列由运营团队负责——有时是外包的，通常在不同的时区，偶尔是按小时 SLA 计费的合同供应商。他们只有在队列深度警报第一次响起时，才会知道新的上报流程。他们的评估面是队列深度、平均处理时间和审核员满意度。他们优化的目标是“防止队列溢出的吞吐量”，这通常意味着在质量下滑之前悄悄压缩每个案例的处理时间。

用户看到的“我不知道”和“让我找专业人士来处理”的文案由产品设计师或内容策略师负责，他们将这些视为一个功能：即“回退体验（fallback experience）”。他们发布一段足够模糊、能涵盖两种情况的文案，而这恰恰是双阈值设计本应修复的失效模式。

行之有效的单一负责人模式是：由一名产品经理（PM）负责整个置信度门控策略，将其视为一个统一的层面。该 PM 对弃权率、上报率、审核队列深度和恢复率这一整套指标负有明确的责任。PM 不需要具备深厚的技术背景，但必须理解这四个指标是耦合的，孤立地优化其中任何一个都会破坏其他指标。如果没有这个单一负责人，阈值每季度都会被当时感到痛苦的团队重新调优，而其他团队只能通过查看仪表盘来发现变化。

大多数团队最后才构建的 UX 层

一旦选定了阈值并配备了排班人员，UX 仍需完成一项工作：让这三个区间感觉像是一个连贯的产品。这是大多数团队最后才构建、且会重构三次的层级。

“弃权”文案必须起到重定向的作用，而不能听起来像是在推诿。“我不知道”是最糟糕的措辞，因为它让用户无处可去。“我无法处理这个问题——请尝试 [特定链接 / 特定人员]”要好得多，因为它将一次弃权转化为了成功的交付。衡量这个界面的指标是用户是否点击了重定向，而不是模型是否礼貌地拒绝。

“升级”文案有不同的要求。用户必须理解现在有真人介入，响应会变慢，且原始交互已保留，无需重复解释。延迟预期必须明确设定——“预计在四小时内回复”是一份契约，“我们会尽快回复你”则不是。通知流程必须以一种让用户回到原始上下文的方式处理最终响应，而不是发送一封通用的电子邮件，把用户丢到一个帮助中心的落地页。

“回答”文案是大多数团队已经具备的。错误在于让它跨界泄漏——在应该感觉像状态更新的升级中使用相同的对话语气，或者在应该感觉像转介的重定向中使用相同的直接回答格式。

三个区间，三种声音，三份延迟预算，一个产品。做对这一点的团队不仅调优了数字，还调优了围绕它们的整个协作流程。

置信度信号是一个路由层

更深层的认识是，生产环境中的 AI 置信度不是一个指标——它是一个路由层。单一阈值相当于运行一个只有一个后端的负载均衡器：要么是“后端可以处理”，要么是“请求被丢弃”，中间没有任何过渡。成熟的设计拥有多个具有不同成本和能力的后端，以及一个根据请求本身的属性为每个请求选择合适后端的路由规则。

在双阈值设计中，模型是廉价且快速的后端，人工审核员是昂贵且缓慢的后端，而重定向则是“这不是我们的问题”路径。阈值就是路由规则。一旦你从这个角度看待架构，你就会停止争论“什么是正确的置信度阈值”，并开始问正确的问题：“考虑到每个后端的成本和延迟，以及我们观察到的流量分布，在满足队列容量和信任预算的前提下，什么样的划分能使总预期成本降至最低？”

这是一个有明确答案的问题。而单一阈值的框架则不是。

从哪里开始

如果你今天正在交付一个置信度门控功能，并且只有一个阈值，以下是修复它的操作顺序。

首先，审计校准。如果你现在的置信度信号没有校准曲线，那么你就没有置信度信号——你只有一个以某种未知方式与正确性相关的数字。在触碰阈值之前，先建立曲线。

其次，对队列建模。与负责审核员容量的人沟通，获取真实的吞吐量数字，并反向计算出最大可持续的升级率。那个数字就是你上限阈值的硬性天花板。

第三，分离指标。停止将“弃权率”作为一个单一数字汇报。跟踪“回答率”、“升级率”、“拒绝并重定向率”以及“拒绝且无重定向率”这四个独立的量值。最后一个数字应该趋于零——如果不是，说明你的重定向 UX 出了问题。

第四，寻找单一负责人。阈值策略是一个决策对应四个指标；它需要一个 PM，而不是四个工程团队在争论该拨动哪个杠杆。

这种投入不会立即见效，但会产生复利。做对这一点的团队，其置信度门控功能会给人一种诚实感，这是单一阈值系统永远无法做到的——用户更信任回答，正是因为他们更信任弃权，而且升级过程不会像掉进黑洞。架构遵循问题的物理规律，而不是与其对抗。这比任何阈值调优突击战产生的价值都要大。