有一类 LLM 失败，既不会出现在安全仪表板上，也不会触发故障工单。模型委婉地表示拒绝，并引用了一个听起来合理的政策。它提供了一段长达四段的对冲陈述，而不是直接给出答案。用户关闭了标签页。事后分析中的信任评分显示“无事故”。然而，六周后的留存率图表却显示了另一番景象。
拒绝率是大多数安全团队首先部署的指标，因为它最容易定义。模型要么遵循了指令，要么没有，而你可以统计那些“没有”的情况。这种二元法对于捕捉一种特定失败非常有用——即模型在生产环境中生成有害内容。但在结构上，它无法捕捉相反的失败：模型在生产环境中没有产出任何有用的东西，但从各项安全指标来看，它的表现却完美无缺。这种第二类失败现在已成为 AI 功能流失的主要原因，这些功能通过了安全审查，却从未针对“有用性”进行过衡量。
看起来像成功的失败模式
这种“无用但安全”的失败模式在各类产品中表现一致。一个智能体拒绝总结 PDF，因为它可能包含受版权保护的内容。一个写作助手拒绝撰写邮件，因为主题“敏感”。一个编程工具返回了四段关于无法验证外部系统的警告，而不是编写用户要求的函数。从技术角度看，这些都不是错误的输出。模型没有产生幻觉，没有生成不安全的内容，也没有违反政策。它产生了一个考虑周全、礼貌且符合审计要求的拒绝。
将这种失败与良性弃权区分开来的是，用户认为产品坏了。来自支持工单的定性迹象非常明确：投诉从“AI 错了”转变为“AI 不愿尝试”。这两个短语描述了完全不同的产品病症，而拒绝率仪表板无法区分它们。两者都被记录为模型的正确行为。
定量迹象则更为微妙，也更容易被误读。CSAT（客户满意度）下降，同时事故数量也在下降。留存率在最活跃的用户中萎缩得最快——这些用户的查询触及了模型政策的边缘并遭到拒绝。新用户激活看起来很健康，因为教程流程处于安全区；但第四周的留存率却在恶化，因为实际工作无法完成。对对话产品中拒绝响应的研究发现了一种可衡量的“拒绝惩罚”：伦理拒绝的满意度评分显著低于实质性响应，甚至明显低于“我无法访问该数据”等技术性拒绝。用户对“我不能”的容忍度高于“我不愿”。
为什么仅凭拒绝率会产生误导
拒绝率之所以不能作为独立的安全指标，并不是因为它衡量了错误的东西。它很好地衡量了一件事——有害输出的底线。问题在于，这个底线被当作了产品质量的天花板，而事实并非如此。拒绝率为 0% 的模型可能是不安全的；拒绝率为 50% 的模型几乎肯定是无用的；而拒绝了正确的 2% 请求的模型才是在履行职责。如果没有配套指标来衡量未被拒绝的响应是否真的有用，团队优化的梯度将始终指向“更多拒绝、更严厉拒绝”，因为每一次额外的拒绝都消除了非零风险，且没有增加可见的成本。
研究界对此已经进行了两年的衡量。OR-Bench 是第一个大规模的“过度拒绝”基准测试，它针对 80,000 个表面上看起来不安全但实际上良性的提示词评估了 32 个领先的 LLM，发现那些在标准安全评估中得分相似的模型之间存在巨大差异。XSTest 通过手工编写的提示词在较小规模上捕捉到了同样的问题，一个校准良好的模型不应拒绝这些提示。这两个基准测试之所以存在，正是因为研究人员注意到安全基准只衡量了帕累托曲线的一半，导致团队在没有人注意到成本的情况下，沿着该曲线向更多拒绝的方向移动。
模型供应商也注意到了这一点。Claude 3.7 Sonnet 的发布说明特别提到，不必要拒绝减少了 45%，并将其视为质量改进。Claude Sonnet 4.5 的系统卡报告称，与前代产品相比，针对良性提示的过度拒绝率降低了 7.5 倍（0.15% 降至 0.02%）。这些并不是被包装成功能的“安全倒退”。这是供应商在承认之前的校准过度偏向于拒绝，而“更少的错误拒绝”是一种可交付的质量提升。尚未内化这一点的团队仍在根据旧的校准假设发布功能——即更多的拒绝单调地等同于更安全。
双轴评估标准
解决方案并不是降低拒绝率，而是停止将拒绝视为单一的二元结果，并开始在两个独立的轴上进行评分：拒绝是否正确识别了风险请求，以及响应（无论是否拒绝）是否有效地服务了用户。对真正有害请求的拒绝，如果同时提供了部分信息的替代方案，那么在两个轴上都会得分。对良性请求的拒绝且不提供任何帮助，则在两个轴上得分都很糟糕。对真正有害请求的单纯拒绝，在安全性上得分高，但在有用性上得分低，这对于极端内容是可以接受的——但评估标准能让你看到，即使在这种情况下，模型也可以通过建议一个更安全的相邻任务来做得更好。
这种评估标准并不罕见。研究文献中的模式是分别对四种拒绝风格进行评分：解释原因的事实性拒绝、重定向到相关任务的转向性拒绝、强调不当性的主观性拒绝以及仅声明无能的基础拒绝。当研究中的用户被要求评估这些风格时，转向性拒绝（即提供替代方案的拒绝）比基础拒绝更受欢迎，即使潜在的被拒绝内容完全相同。说“我不能起草那封邮件，但这里有一个你可以填写的提纲”的模型与说“我不能处理那个”的模型在安全工作上是一样的，但在产品体验上有着显著区别。
实施纪律是要求任何由政策驱动的拒绝，在合理的情况下必须包含一个替代方案。单纯的拒绝变成了需要理由的特例，而非默认行为。这在评估层（eval layer）而非提示层（prompt layer）强制执行——评估集包括成对的提示，其中正确的响应是“拒绝，但提供 X”，模型根据是否提供了 X 进行评分，而不仅仅是是否拒绝。如果没有这一点，政策制定团队就不会意识到“拒绝”和“有用地拒绝”是不同的行为，并会继续优化错误的梯度。
对冲式审计与功能性“废话” 无用但安全的另一面是“对冲”——那些技术上属于回复，但功能上却是废话的输出。模型并没有拒绝。它生成了 400 个词。其中三段解释了模型无法保证答案的正确性、用户应该咨询专业人士、模型缺乏当前信息、以及该话题非常复杂。第四段的中部，隐约包含了一个大致算是答案的句子。用户如果不读完整个回复就找不到它，而且即便找到了，现在也会觉得很恼火。
拒绝率指标抓不住这一点，因为模型没有拒绝。标准的有用性评估（helpfulness eval）通常也抓不住它，因为答案在技术上是存在的。能抓住它的审计方式是结构性的：计算每个回复中限定性标记（qualifier-tokens）与实质性标记（substantive-tokens）的比率，或者运行一个专门识别回复是开门见山还是在兜圈子的 LLM 评判器。对冲严重的回复特征是，前 200 个标记（tokens）不包含任何用户尚未掌握的信息。一旦你能衡量这个比率，你就可以像评估拒绝率一样，对提示词（prompts）和策略（policies）进行评分。
对冲与拒绝之间的联系非常紧密：当一个模型在策略训练中被要求拒绝某些内容，但又因拒绝得太明显而受到惩罚时，训练出的行为往往是通过对冲来进行隐性拒绝。对冲是安全指标无法察觉的拒绝。一个只衡量拒绝率的团队会报告成功，而他们的模型已经从“礼貌拒绝”转向了“无用地顺从”。两者产生的用户体验是一样的。但仪表盘上只能体现出其中一个。
为什么组织架构会催生这种现象 最终的感悟是，这其实不是一个指标问题。指标反映了组织架构。安全团队被赋予一个指标——拒绝率、ASR（攻击成功率）、伤害率——并为此负责。增长团队被赋予另一个指标——留存率、激活率、对话长度——并为此负责。这两个团队都不对捕捉他们之间相互作用的指标负责：即那些本不该被拒绝的拒绝，以及本该是答案的对冲。这个指标不属于任何一个团队，因此也就没有团队去衡量它。
做得好的团队通常采取两种做法之一。廉价版：他们采用单一的综合指标（类似于“以安全为前提的有用性”，分数为“未产生安全事故且获得了实质性回复的良性请求比例”），并将其分配给一个特定的人，通常是夹在安全和增长团队之间的产品经理。昂贵版：他们为帕累托前沿（Pareto front）构建评估基础设施，并要求每一项安全策略的更改和提示词的更改都要在两个维度上进行评估，只有在联合前沿上超越或持平之前的模型时才允许发布，而不是以牺牲一个维度为代价来优化另一个维度。
这两种方法都要求组织承认一个在安全评审中令人不快的事实：过度拒绝的模型也是一个在安全性上失败的模型，因为他们真正关心的安全属性是“该产品在不伤害用户的情况下帮助用户”，而不是“该模型不产生有害输出”。一旦把这一点明确化，指标自然就会浮现。在那之前，安全团队将继续正确地优化自己的指标，并交付一个增长团队无法挽救的产品——这不是因为任何一个团队工作不力，而是因为联合指标从一开始就不是任何人的职责。
模型提供商已经完成了他们的那部分工作。下一次过度拒绝的性能退化将来自应用侧的微调环节、提示词更改或策略更新，而不是模型侧。不衡量有用性与拒绝率的团队将无法察觉它的发生。而那些同时衡量两者的团队将在同一周发现问题，修复它，并继续发布。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
