5 篇博文 含有标签「abstention」

你在周二升级了模型。到了周五，“任务完成率”仪表盘从 71% 爬升到了 78%。领导层注意到了。有人在全员大会上截图展示了它。两周后，客服部门悄悄反馈说，特定一批复杂工单的流失率翻了一番。没人把这两件事联系起来，因为从纸面上看，智能体（agent）变得更好了。而现实情况是，新模型只是变得更擅长拒绝了。

这就是指标脱钩问题，也是以 LLM 为动力的产品欺骗其开发者的最昂贵方式之一。你的成功率并没有衡量你认为它在衡量的东西。它衡量的是“模型尝试的内容”与“模型尝试时做对的内容”的交集。当模型升级、提示词更改或安全调优（safety-tuning）改变了“尝试”的边界时，你的分子和分母会同步移动——即使在用户感知的质量一落千丈时，该比率也可能上升。

你教会了 Agent 在上下文不足时说"我不知道",然后把这当成一次安全胜利。OpenAI 账单确实降了。所有人都同意这是负责任的做法。三个月后,你的客服 VP 在追问为什么人头预算偏差 40%,AI 团队里没人答得上来——因为你跟踪的指标是弃答率,而真正动起来的指标是每周工单数,而那条把它们加起来的曲线没有任何 owner。

这就是弃答税。它不是一种模型成本。它不会出现在推理账单上。它出现在下游:出现在每接住一句"我无法回答"就要排队处理的人工团队队列深度里,出现在针对人工额外补足后的上下文再跑一次的第二次模型调用里,出现在等待期间流失掉的客户身上。只看模型成本的那张账面,悄悄把它藏了起来。再加上 AI 团队负责弃答、运营团队负责队列的那道组织接缝,意味着没有人有动力去看清这件事。

大多数团队通过在系统提示词中加入一句话来处理弃权（abstention）问题：“如果你不确定，就说你不知道。”模型偶尔会遵守，但经常不遵守，而且这种失败模式是不对称的。一个自信的错误答案会以全速发布——它直接落入用户手中，在 Slack 讨论串中被引用，在下游摘要中被采纳。而一个诚实的弃权则会触发客户成功（CS）升级，因为用户期望智能体处理请求，而现在必须有人解释为什么它没有处理。六个月后，团队已经了解到哪种失败的发布成本更低，而那个名义上控制弃权的系统提示词修改，已经被悄悄地调整为倾向于顺从，而非诚实。

解决这个问题的准则不是寻找更好的措辞。而是要认识到，弃权是一个路由决策，而不是一种提示词模式。它理应拥有一个一等公民级别的输出通道、自己的 SLO、自己的评估套件，以及在系统拓扑中的独立位置——位于提示词之外，可以被测试、维护和扩展。

你的模型可以拥有一种能力，在关键时刻，这种能力比你发布的任何其他行为升级都更有价值：能够说“我没有可靠的答案”并且是认真的。不是那种基于关键词匹配的安全拒绝。也不是模型在处理争议性话题时，从 RLHF 中学到的那种模棱两可的坏习惯 (hedging tic)。而是真正的能力——一种经过校准的弃权 (calibrated abstention)，仅当且仅当模型的内部证据不支持生成自信的回答时才会触发。

你永远不会偶然获得这种能力。LLM 技术栈中的每一个默认设置都在反向推动。

向生产环境中的 RAG 系统提一个你的语料库无法回答的问题，看看会发生什么。它很少会说“我没有那方面的信息”。相反，它会检索出五个排名最高的片段——由于没有更好的匹配项，这五个片段其实是五个最不糟糕的无关内容——然后将它们交给模型，并配上类似“请使用以下上下文回答用户的问题”的提示词。模型在被训练为要乐于助人的同时，手中握着与主题有几分相似的文本，于是产生了一个自信的回答。这个答案的错误在架构上是不可见的：检索成功了，生成也成功了，每个片段都在检索到的文档中有据可查，但用户却被误导了。

这就是检索空洞问题。它不是任何单一层级的 bug。它是一个流水线的涌现行为，该流水线将 “top-k” 视为一种契约，却从不询问 top-k 的质量如何。ICLR 2025 上发表的一项关于“充分上下文”（sufficient context）的研究量化了这一影响：当 Gemma 获得充分的上下文时，其在事实性问答上的幻觉率约为 10%。当它收到的上下文不足时——即检索到的文档实际上并不包含答案——该比率会飙升至 66%。向描述不足的查询中添加检索到的文档会让模型错得更自信，而不是更少。