“无助但安全”的失败：为什么拒绝率是错误的安全性指标

有一类 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%）。这些并不是被包装成功能的“安全倒退”。这是供应商在承认之前的校准过度偏向于拒绝，而“更少的错误拒绝”是一种可交付的质量提升。尚未内化这一点的团队仍在根据旧的校准假设发布功能——即更多的拒绝单调地等同于更安全。

双轴评估标准

加载中…