选择性弃权问题：为何总给答案的 AI 系统是有缺陷的

这是一个几乎出现在每个生产 AI 部署中的模式：团队发布了一个能够处理 90% 查询的功能。然后开始收到投诉。某用户提了一个超出训练分布的问题，模型自信地给出了错误答案。RAG 流水线检索到一份过时文档，模型却将其当作最新信息来回答。一个法律查询触及了提示没有覆盖的边缘情况，模型靠猜测蒙混过关。在每一种情况下，修复方案都不是换一个更好的模型，而是让系统学会说"我不知道"。

弃权——有原则地决定不回答——是 AI 系统设计中最难、最被低估的能力之一。几乎所有产品工作都致力于让答案更好，几乎没有任何工作致力于让系统可靠地知道何时该拒绝作答。这种不对称是一种在生产环境中不断累积的设计债务。

为什么系统默认总是给出答案

在 AI 产品开发中，阻力最小的路径是构建一个永远输出内容的系统。这看起来像是进展。用户看到了响应，功能在运作。在用户测试中，一个错误但自信的答案往往比表达不确定性的回答评分更高——人们发现"我没有足够的信息来可靠地回答这个问题"令人不满意，而"这是你的答案（虽然是错的）"暂时不会引起察觉。

这造成了一个恶性反馈循环。在开发过程中，自信的输出从未注意到错误的用户那里获得正面信号；弃权的系统则从体验为失败的用户那里获得负面信号。于是团队倾向于调优出高置信度的覆盖率，生产系统学会了猜测而非承认不知道。

这个结果往往要到数月后的 A/B 测试中才会显现——彼时用户信任已经侵蚀，用户已经不再期待系统是可靠的。而此时，置信度-输出的耦合已经深深嵌入了产品的训练、评估和度量方式之中。

根本问题在于，大多数 AI 评测框架衡量的是模型回答的那些问题的准确率，而不是它收到的所有问题的准确率。一个在 60% 的问题上回答正确、其余问题弃权的系统，在朴素的准确率指标下，看起来比一个回答 100% 问题、准确率 75% 的系统更差——尽管前者在生产中造成的错误更少。

应该驱动弃权决策的三个信号

构建弃权需要明确系统究竟在对什么感到不确定。有三个不同的维度，混淆它们会导致校准不良的行为：

查询可回答性。 有些问题在现有知识下根本没有正确答案。它们可能包含错误前提（"爱因斯坦小时候数学不及格是什么时候？"——他从来没有）、欠规范（"这个最好的 API 是什么？"——根据什么标准的"最好"？），或者涉及真正未知的信息（"美联储下个季度会怎么做？"）。这些问题在结构上就无法回答，而不仅仅是困难。遇到没有支持证据的查询时，检索系统应当发出与模型在两个合理答案之间不确定时不同类型的信号。

模型置信度。 即使对于可回答的问题，模型对其输出的内部置信度也各不相同。正确校准这一点非常困难——大多数模型对流畅但错误的答案产生的 token 级概率，往往高于对带有保留意见但正确的答案。让模型明确表达不确定性有一定帮助，但 AbstentionBench 基准测试在 20 个弃权相关数据集上测试了 20 个前沿 LLM，发现即使是经过良好提示的模型也无法可靠地进行弃权。更令人担忧的是：针对推理优化的模型（经过逐步推理微调的模型）比其基础指令调优版本弃权能力差 24%。让模型在困难数学问题上表现更好的思维链推理，同样让它们更有可能通过推理得出自信的错误答案，而不是承认不确定性。

价值对齐。 第三类涉及那些技术上可以回答、但生成答案会违反安全或政策约束的查询。这是大多数团队最先投入的拒绝层，因为它整齐地映射到内容审核上。但对于工程可靠性而言，它是最无趣的——一个能拒绝有害查询但在模糊问题上自由编造内容的模型，在生产中仍然是一个风险。

大多数系统只实现了第三类。构建前两类需要刻意的工程投入。

在实践中构建弃权触发器

弃权不是单一机制——它是一个分层决策栈。构建可靠弃权的团队通常会叠加多个信号：

RAG 流水线中的检索质量阈值。 当系统检索上下文来回答查询时，检索内容的质量是答案好坏的强先验信号。嵌入距离相似度分数是粗粒度的，但将其与片段级覆盖度检查结合——检索文本是否真正包含能够解答查询的声明——可以形成有意义的门控。低于阈值时，正确行为是提示"可用信息可能不足以回答此问题"，而不是生成一个模型随后会在信息缺口周围编造内容的响应。

这一点很重要，因为 RAG 会产生一个反直觉的失败模式：给模型更多上下文会增加其置信度，即便额外的上下文是无关的或误导性的。遇到关于相关但不同主题的检索文档时，模型通常会将其融入一个流畅、自信、但错误的答案中。检索质量信号需要独立于生成步骤进行评估——不能委托给模型本身。

查询类型分类器。 一个对传入查询进行分类的轻量级分类器，可以将不同类型路由到不同的弃权阈值。含有错误前提的问题、对实时信息的请求、涉及系统无法访问的个人或私密数据的查询、以及需要模型所缺乏的领域专业知识的问题，都可以在查询层面——生成之前——被识别并区别处理。这比试图在输出中检测不确定性更高效。

集成分歧作为低成本不确定性信号。 当对同一查询使用不同温度或提示进行两次模型调用产生截然不同的答案时，这种分歧是查询处于高模型不确定性区域的可靠信号。这在规模上计算代价较高，但对于答案出错代价高昂的高风险查询是可行的。

输出自一致性检查。 对于包含可验证声明的生成答案，进行第二轮检查，对照检索到的证据验证每个声明，可以标记出与实际检索内容不一致的答案。这是大多数 RAG 忠实度评估框架的基础，可以被操作化为对验证失败声明的弃权触发器。

没人谈论的用户体验设计问题

即使工程层面运作良好，产品问题依然存在：如何以一种不像失败的方式来呈现"不回答"？

朴素的实现——模型说"我不知道"或"我没有足够信息"——在用户测试中表现很差，尤其是在产品生命周期早期，用户尚未建立对系统的信任基线时。还不了解系统擅长什么的用户会将弃权解读为随机性，而不是有原则的可靠性。

有几种模式效果更好：

解释边界，而不只是局限。 "我没有[日期]之后的数据"或"我只能引用你已连接工作区中的文档"，让用户对系统能够可靠做什么形成心理模型。这比笼统的"我不确定"更有用。理解边界的用户会相应地调整自己的查询，从而随时间减少无法回答的查询频率。

重定向，而不只是拒绝。 当查询超出可靠范围时，系统可以指示它能够回答哪类问题。"我无法告诉你下个月会发生什么，但我可以展示历史趋势"——即使字面问题被拒绝，也保留了实用价值。

在 UI 中区分弃权类型。 将"我不知道因为信息不存在"与"我不知道因为我没有接受过这方面的训练"与"我不知道因为这个查询含糊不清"混为一谈的系统，会让遇到这三种情况的用户感到困惑。细微的 UI 信号——不同的图标、不同的措辞——可以传达系统有理由不回答，这比笼统的模糊回答感觉更有能力。

通过早期一致的弃权建立用户信任。 有效部署弃权的团队的反直觉发现是：早期经历过可靠不回答的用户——当系统明显不知道某事并正确说出时——对系统自信答案的信任度，高于从未看到系统拒绝任何事情的用户。自信答案的可靠性是以适当拒绝的基线来校准的。部署全覆盖自信系统的团队失去了这个校准锚点。

评估问题

大多数团队不投资弃权的原因是它难以衡量。标准基准准确率指标无法捕捉它——它们衡量可回答问题上的表现，通常将"我不知道"排除在有效答案类别之外。

构建弃权评测需要构建一个同时包含可回答和不可回答查询的测试集，并衡量两个方向：系统在不可回答输入上正确弃权的比率（弃权召回率），以及它在可回答输入上错误弃权的比率（错误弃权率）。同时做好两者是挑战所在——一个总是弃权的系统具有完美的弃权召回率，但毫无用处。

实际方法是针对不同查询类别分别定义弃权阈值，并按类别衡量表现。法律研究工具应该与代码文档助手具有非常不同的弃权校准。将弃权作为单一旋钮进行全局调优，会产生在其实际服务的领域中校准不良的系统。

对系统设计的启示

弃权应该是第一类产品需求，而不是事后补救。这意味着：

• 评测框架应该从第一天就包含不可回答的查询，而不是在第一次生产事故之后才加入。
• 在 RAG 系统中，检索质量应该独立于生成质量进行评估。
• 查询路由逻辑应该识别模型在结构上可靠性较低的查询类别，而不仅仅是历史上表现不佳的类别。
• 用户体验应该围绕弃权作为功能来设计——为不同类型的不回答提供明确的语言和界面模式——而不是作为错误状态来处理。

构建好这些的团队最终拥有的产品，比总是生成自信输出的系统更难演示。但他们也拥有能够在真实用户大规模使用下存活的产品。全覆盖自信系统在三十分钟评估中令人印象深刻，却在生产的第二个月失败。知道自己不知道什么的系统则赢得随时间复利增长的信任。

说"我不知道"很难。它要求系统拥有一个足够准确、足够有用的自身可靠性模型。构建这个模型是 AI 产品开发中真正的工程挑战——而它始于决定去衡量它。