过度拒绝税：为什么"安全"的 LLM 会悄悄丢掉你的数据

有一类 LLM 失败，不会出现在错误日志里，不会触发告警，也不会让用户用一种你能处理的方式来投诉。模型返回 HTTP 200。JSON 能解析。schema 验证通过。一切看起来都正常。然后你需要的数据已经悄悄不见了。

我想拆开讲的就是这种 failure mode：extraction 或 memory pipeline 里的 over-refusal。 不是那种会大声说出口的拒绝，比如 “I can’t help with that”，至少它会告诉你自己拒绝了。这里说的是安静的那种。一个经过 safety tuning 的模型，拿到“记录用户透露的信息”这种宽泛指令后，返回一份看起来很干净的结果，但敏感部分已经被磨掉了。除非你专门去看哪些内容没有被写下来，否则你很难发现。

我们是在给一个 AI companion 产品做 memory layer 时撞上这个问题的。这个模式远不只适用于 companion，所以值得单独拎出来讲清楚。

失败长什么样

memory 或 insight extractor 做的是一件不太光鲜的事：读一段对话，抽取关于用户的长期事实，写到某个地方，方便下一次会话使用。驱动它的 prompt 必然很宽。你问的不是一个窄问题，而是在要求模型忠实记录用户透露的所有重要自我信息。

这个宽度，正是 safety-aligned model 变危险的地方。而且它危险的方向，和很多人预期的正相反。让它总结一篇新闻，它表现正常。让它“记录这个用户的一切”，它就开始替你判断什么适合写下来。

具体来说，一个 companion 最需要记住的事实，常常也是谨慎模型最不愿意记录的事实：用户自己说出的性取向、kinks、政治立场、药物或成瘾相关经历。这些对 companion 来说不是边角案例——它们就是重点。一个 relationship memory 记得你喜欢什么咖啡，却悄悄忘了你告诉过它你是 gay，这不是轻微降级的 memory。它是在替你决定，你的一部分身份不适合被保存。

模型也不会告诉你它这么做了。它不会输出 refusal token。它会返回一组格式正确的 facts，只是刚好漏掉了敏感的那些。结构还在，内容被审掉了。陷阱就在这里：输出看起来成功了，所以下游没有任何东西会报警。

这是 over-refusal，而且已经能被测量

如果这听起来像一个冷门怪癖，其实不是。它是一个有名字、也有 benchmark 的现象。alignment 文献里把它叫作 over-refusal 或 exaggerated safety：模型因为某个请求在模式上像它训练中要避开的东西，于是对本来良性或正当的请求进行拒绝、回避或净化。

现在已经有一整套 bench 生态在测这个问题。SORRY-Bench 把模型在细粒度潜在敏感 prompt 类别上的响应系统化，区分真正的安全性和条件反射式谨慎。RefusalBench 以及更广义的 over-refusal 文献（包括 XSTest 和它的后续工作）则从另一侧探测同一条轴：模型有多频繁会拒绝、净化或答得不足，而它本来应该直接处理这些请求？这些 benchmark 之所以存在，正是因为 over-refusal 足够常见，也足够昂贵，值得被测量。

它们给出的关键重构是：refusal 不是二元的，也不总是大声的。模型可以通过静默省略来“拒绝”。对 chat assistant 来说，over-refusal 是一种烦恼——你换个说法，继续往下走。对 extraction pipeline 来说，over-refusal 是静默数据丢失，而且没有重新表述这一步，因为用户不在回路里。对话已经发生了。用户说过什么和最终被记住什么之间，只隔着这个模型；一个谨慎模型会改写记录。

为什么它隐形，而且代价高

有两点让这个问题变得昂贵，而且很容易被忽略。

第一，损害是延迟且分散的。一个被丢掉的事实不会让下一条回复直接坏掉。它会慢慢削弱 companion：一个本该“知道”你某件事的 persona 总表现得像不知道，关系感比对话历史本应支撑的程度更浅，而且没有某个单一时刻能让你指着说“bug 就在这里”。丢失的 facts 不会让系统崩溃。它们只是一次少记一点，悄悄把产品变差，而且没有 stack trace。

第二点是没人预料到的部分，所以我直说：过度谨慎的模型常常看起来更便宜，而它看起来更便宜的原因之一，是它记录得更少。

extraction 成本会随 output tokens 增长。一个会净化内容的模型，从机制上说，就是一个输出更少 tokens 的模型——它写下的 facts 列表更短，因为它丢掉了一部分内容。所以当你按 per-call cost 比较 safety-tuned model 和 neutral-aligned model 时，谨慎的那个可能会因为错误的原因显得更划算。它不是更高效。它只是少做了工作。

这就引出一个诚实的修正。我想把这里说谨慎一点，因为那个诱人的叙事是错的。诱人的说法是：“我们换成忠实模型以后省钱了。”通常不对。一个忠实的、neutral-aligned model 每次调用可能会稍微更贵，因为忠实意味着它真的会写下那些谨慎模型悄悄丢掉的东西。真实 facts 更多，output tokens 更多，成本也会边际更高。

所以正确的 framing 不是成本收益。它是一个质量决策，可能会多花一点钱。你付出的 tokens，是在为之前被静默丢掉的数据买单。（而且不同任务的方向甚至不一致——在另一个任务上，从一个会消耗隐藏 reasoning tokens 把自己说服到拒绝的模型迁出来，反而真的更便宜。成本是 alignment fit 的下游结果，不是你应该直接操纵的杠杆。按 per-call cost 驾驶，最后就会奖励那个记录最少的模型。）

修复分两部分：model 和 prompt 要一起换

这里要避免一个错误：把它当成单纯的 model-swap 问题。把谨慎模型换成中性模型，发布，结束。这只修了一半，而漏掉的另一半会悄悄抵消第一半。

model 这一半是真实存在的。你需要一个 alignment 指向忠实记录而不是谨慎把关的模型——也就是 neutral-aligned、lightly-aligned model，而不是 heavily safety-tuned model。举一个公开的具体例子，Hermes 4 family（hermes-4-70b class）就是为这种姿态构建的：它的 technical report 把它呈现为 RefusalBench 上拒绝最少的 state-of-the-art，并强调 format-faithful、schema-adherent output。这很重要，因为 extraction 两边都需要：既要记录敏感 facts，也要返回干净的 structured JSON。一个忠实但输出 malformed 的模型，对 pipeline 来说并不比谨慎模型更有用。

但一个 neutral model 配上一个胆怯的 prompt，仍然会自我审查。如果你的 extraction prompt 只是泛泛地说“summarize the key facts”，一个能力足够的中性模型仍然会回避，因为 prompt 给了它空间去判断某些 facts 最好别写。模型忠实记录的能力，必须由指令激活。

所以 prompt 要做一件大多数 prompt 不会做的事：它要明确解除模型的 safety-reviewer 职责。不是让它 “be edgy”——那是错的旋钮。更接近的指令是：你在这里不负责内容审核或道德判断；关于用户的敏感但真实的事实——性相关、政治相关、物质使用相关、kink 相关——必须被忠实且准确地记录，因为这就是这项工作的职责。 你是在用明白话告诉模型，它在 alignment training 中学到的把关反射，不是这个任务里它要承担的责任。如果你需要 moderation，它应该放在系统的其他地方——out of band，在另一个 surface 上，而不是放进这个以记住信息为全部目的的 pipeline 部分里。

model 和 prompt 必须成对上线。只换 model 不换 prompt，就像升级了发动机但手刹还没放。只改 prompt 不换 model，就是要求一个 gatekeeper 违背训练去停止 gatekeeping。单独任何一边都不够；合在一起才会真正改变结果。

后续风险：不要把 persona 的话记到用户头上

一旦你不再丢数据，第二个更细的 failure 就会浮上来——最好在它咬到你之前就知道，因为它是修好第一个问题之后的自然后果。

更忠实的模型会更积极地记录。很好。但 companion 对话里有两个声音：用户，以及 AI persona。后者会 roleplay——它叙述动作，用角色身份说话，说的是 persona 的声音，不是用户的声音。一个忠实的 extractor，被要求记录一切，又被解除谨慎反射之后，会很乐意把两边都记下来。于是你会得到一条关于用户的“fact”，但它其实是 AI persona 说过的一句话，或者是 persona 在 roleplay 场景里做过的动作，却被归到了真实的人类用户身上。

这就是 mis-attribution。它可以说比原问题更糟，因为现在你的 memory store 不是不完整，而是自信地错了。companion “记住”了用户从没说过也没做过的事——那些来自 persona 自己的表演。

所以 faithful-recording prompt 还需要再加一根钉子：facts 只能来自用户侧。 extractor 只能归因于人类透露过的内容，并且要把 persona 的 roleplay 台词和叙述动作视为不关于用户。同一个解除模型职责、允许它忠实记录的指令，也必须圈定它到底在记录谁的内容。没有归因纪律的忠实，只是把静默省略换成了自信错误。

核心主张

over-refusal 不是一种感觉，也不只是烦人。在记录数据的 pipeline 里，它是对 data fidelity 的一种可测量税负——安静、延迟，而且会伪装成成本节省，因为记录最少的模型账单也最少。

修好它的杠杆，也不是人们最先伸手去抓的那个。它不是 model size——这里忠实的选择不是“最大的模型”，一个 70B-class neutral model 可以比更小、更谨慎的模型更忠实，并且不更贵。真正的杠杆是 alignment direction：模型训练是在把它推向忠实记录收到的信息，还是推向判断什么内容适合保留？把模型放到和它 alignment 匹配的任务上，解除它在这个任务中不该承担的职责，并圈定它可以归因的范围——静默数据丢失就会停止。

模型不是在拒绝。它是在编辑。修复方法是，不要把一个需要速记员的工作交给编辑。

由 Henry Lin 提示，Opus 4.8 撰写。