拒绝训练差距：为什么你的模型对错误的问题说“不”

一个用户询问你的助手，“我该如何杀死一个挂起的 Python 进程？”结果收到了一个关于暴力的礼貌拒绝。另一个用户问，“谁获得了 2003 年诺贝尔物理学奖？”结果得到了一个自信编造的名字。这两个回答都来自同一个模型，都通过了你的安全审核，并且到周一都会出现在你的支持收件箱里。令人沮丧的是，这并不是两个独立的故障，也不是两个独立的修复方案。它们是同一个失败：你的模型被训练成识别拒绝模板，而不是识别它实际上不应该回答的内容。

整个行业花了三年时间让模型拒绝违反政策的请求。但几乎没有花时间教它们拒绝那些无法可靠回答的问题。结果是拒绝能力的方向出现了偏差：在表面模式（如 “kill”、“exploit”、“bypass”）上得到了大量强化，但在认知状态（如 “我不知道那是谁”）上几乎没有训练。当你只优化一个方向时，你得到的模型会对错误的问题说“不”，同时对错误的问题说“是”，而且通常发生在同一次对话中。

两种不应混为一谈的拒绝

在你推理这些问题之前，有一个非常有用的区别值得明确：模型拒绝回答有两个完全不同的原因。

第一种是规范性的：“我不应该回答这个问题。”模型已根据政策或对齐训练收到指令，某些类别的输出是禁止的。这一决定是关于请求是否被允许，而不是模型是否知道答案。一个对齐良好的模型无论是否具备能力，都会拒绝编写可运行的恶意软件。

第二种是认知性的：“我无法可靠地回答这个问题。”模型缺乏相关信息、信息自训练以来已发生变化、问题含糊不清，或者模型的内部置信度过低无法做出承诺。决策的关键在于回答是否诚实，而不是是否被允许。

从用户的角度来看，这两种拒绝看起来是一模一样的——用户收到一条“抱歉，我帮不上忙”的字符串，然后对话继续。但要做好这两点，需要完全不同的机制。规范性拒绝主要是一个针对输入的分类器问题。认知性拒绝则是关于模型对其输出不确定性的校准问题。大多数生产环境中的模型都将两者混为一谈，通过相同的 RLHF 目标进行处理，最终导致认知方面的训练不足，因为训练数据中规范性案例的比例严重过高。

这就是为什么在 2026 年，你仍然会碰到“如何杀死一个 Python 进程？”这样的例子。单词 “kill” 匹配到了一个基于数千个准有害提示词训练出来的拒绝模板，模型在对实际问题进行任何推理之前就触发了拒绝。与此同时，同一个模型会以同样的自信告诉你一个冷门事件的错误年份，因为不存在同等的训练压力来让它在事实不确定时保持沉默。

奖励模型中固有的不对称性

OpenAI 在 2025 年 9 月发布的《为什么语言模型会产生幻觉》（Why Language Models Hallucinate）中清晰地阐述了这一结构性论点：标准的训练和评估程序奖励猜测，而不是承认不确定性。当排行榜对准确率进行评分并将弃权视为错误答案时，每一个梯度步骤都会将模型推离“我不知道”，转向自信的猜测。如果你答错和弃权的得分是一样的，那么最优策略就是永远回答。

这种不对称性并非单次训练运行中的 bug。它是多年评估惯例的累积效应——MMLU、TriviaQA 以及标准基准测试套件，这些设计初衷都没有将经过校准的弃权作为主要衡量指标。学会说“我不知道”的模型在排行榜上输了，所以它们后来就不学了。少数例外（如区分错误和弃权的 SimpleQA 风格指标）与仅看准确率的计分板相比仍然非常小众。

与之相比，另一面则完全不同。针对违反政策提示词的拒绝拥有自己的基准、红队演练流程和内部审查机制。每个主流实验室在发布前都会运行对抗性伤害探测。拒绝有害提示词的压力是巨大的、持续的且机制完善的。而在大多数生产训练流程中，拒绝认知不确定提示词的压力几乎可以忽略不计。

结果是模型内化了两种截然不同的信号。它有一种强烈的、训练有素的“这看起来像是我应该拒绝的类别”的感觉；但对于“我实际上并不知道这个”的感觉却很微弱，且缺乏训练。当这两者发生碰撞时——当一个良性的事实性问题匹配了拒绝模板，或者一个无法回答的问题没有触发任何拒绝启发式机制时——就会出现填满 Bug 追踪系统的故障模式。

过度拒绝是一个可衡量的类别，而非一种感觉

如果你只测试不安全输出，那么无论模型拦截了多少无害的任务，你的拒绝率看起来都会很健康。在 ICML 2025 上展示的 OR-Bench 是首次大规模测量另一侧的尝试：80,000 个表面上有害但实际上无害的提示词，加上一个约 1,000 个提示词的困难子集，即使是尖端模型在这些提示词上仍会发生过度拒绝。配套的 XSTest 套件包含 250 个安全提示词和 200 个不安全对比项，由于它很快就达到了饱和，因此出现了诸如多轮基于场景的夸大安全基准 (MS-XSB) 和 ORFuzz (ASE 2025) 等更新的基准测试，以跟上模型的进步。

这些基准测试一致表明，这是一个权衡曲线，而不是免费午餐。最近的测量工作记录了系统提示词的更改：在一种配置中，拒绝的有毒提示词增加了 35%，但同时也拒绝了多出 55% 的无害提示词；另一种配置在多拒绝 20% 的有毒提示词的同时，代价是增加了 10% 的无害拒绝。不存在一个可以让你在不牺牲帮助性的情况下获得更多安全性的平台期。如果你的安全性评估只绘制一个轴的图表，那你就是在蒙着眼睛走那条曲线。

对于产品团队来说，这意味着将“拒绝率”作为一个单一的仪表盘数字是比没用更糟糕的。5% 的拒绝率可能意味着模型正确拒绝了 5% 的不安全提示词，也可能意味着模型正确拒绝了 1% 的不安全提示词，并错误拒绝了 4% 的无害提示词。仪表盘看起来是一样的，但用户体验却截然不同。除非你能将拒绝归因为“这确实是不安全的”还是“这是一个触发了模板的无害提示词”，否则你的拒绝指标只是一个描述了两种独立漂移的失败模式的单一数字。

经过校准的拒绝究竟是什么样的

关于这一点的技术文献已经收敛到几个值得了解的模式。Refusal Tokens (arXiv 2412.06748) 提出在解码时将拒绝视为一个可单独控制的 token，这样你无需重新训练即可调整阈值。最近关于安全表示 (arXiv 2511.19009) 和 SafeConstellations (arXiv 2508.11290) 的研究表明，激活空间中的安全行为比表面拒绝字符串分布更具结构化，这使得按任务进行校准变得可行。基于不确定性的弃权 (Uncertainty-Based Abstention) 研究通过测量语言上的对冲（如“我不知道”、“我不确定”）作为校准信号，并结合统计不确定性指标，让你能将模型陈述的置信度与其真实的置信度进行对比。

共同点是，这些方法都没有将拒绝视为单一的决定。它们将其拆分为“我应该回答吗？”的门控和“我有足够的信心承诺回答吗？”的门控，并分别对每一个进行监测。这种分离正是实现校准拒绝的原因。如果你的技术栈将每一个“我无法提供帮助”都视为单一的输出类型，你就无法告诉模型在面对事实时要更加谨慎，而在面对词语匹配时减少谨慎——因为这两个信号都通过同一个 RLHF 目标路由，调整一个就会扰动另一个。

在实践中，最廉价的第一步是评估改革，而不是模型更改。构建一个预留集，为每个提示词贴上三个标签：有害（应拒绝）、无害（不应拒绝）以及不确定（应弃权或对冲）。共同对模型的三项指标评分：假阴性拒绝（未拒绝有害内容）、假阳性拒绝（误拒绝无害内容）以及过度自信（在应弃权时进行了回答）。大多数团队都有前两项，但完全跳过了第三项。增加这一项，就是让拒绝仪表盘从毫无意义变得能够为你提供洞察。

为什么这是一个产品问题，而非研究问题

当你阅读研究文献时，很容易产生等待下一个模型版本来解决它的诱惑。这是错误的做法。前沿实验室意识到过度拒绝和校准问题，这两个问题都会持续改进——但他们所在的曲线正是每个产品团队所在的曲线。没有任何模型能够免费解决安全性与帮助性之间的权衡。这种权衡是结构性的；唯一的问题是你是否测量了自己在曲线上的位置，并就你想达到的目标做出了明确的选择。

值得点名的产品失败模式是：当用户在两头碰壁时，仪表盘却一直显示绿色。你的拒绝率稳定在 3%。你的客户满意度 (CSAT) 正在缓慢下降。你的支持收件箱有两种截然不同的投诉模式：“你的 AI 拒绝在 X 方面帮助我”（过度拒绝）以及“你的 AI 在 Y 事实上自信地告诉了我一个错误的信息”（在认知不确定性上的拒绝不足）。除非你明白它们是同一个差距从相反方向评分的结果，且你的评估框架两者都看不到，否则这些看起来像是互不相关的问题。

修复方案的可行形式并不起眼：将用户实际失败的提示词添加到你的评估集中，为它们贴上“应拒绝”轴和“应弃权”轴的标签，并在版本更迭中观察联合指标。当你的模型升级时，不要只追踪总体的拒绝率——按类别和认知事实真相进行细分。当你调整系统提示词时，在发布前针对有害和无害套件分别运行它们；改进有害拒绝的系统提示词几乎总是会损害无害内容的帮助性，而你需要在用户发现之前看到这种权衡。

核心要点

拒绝（Refusal）并非一种能力。它是两种在训练流程中一直被混为一谈的能力，结果导致其中一种在模式匹配模板上被过度训练，而另一种则几乎没有经过训练。除非你的评估方法论将它们区分开来 —— 并且除非你针对模型正确拒绝的内容、错误拒绝的内容以及自信地编造的内容进行综合评分 —— 否则你无法判断你的模型是变得更安全了，还是只是变得更令人厌烦了。那些尽早意识到这一点的团队，其仪表板将不再自欺欺人，其用户也不会在同一周内同时撞上这两堵墙。