每10个自信输出就有3个过不了审查：模型之间的一致不是验证

一年对抗性验证：每10个自信输出中就有3个未通过审查。模型之间的一致不是验证。

我们花了一年时间，在我们自己的智能体栈之上运行一个对抗性验证层。这不是基准测试。这是一个活系统，它一边要持续发布，一边对自己存疑。

我们开始时定下的规则：写出答案的模型永远不能给自己的答案打分。

这听起来轻巧，直到你真正尝试。评审者会漂移。他们会学着拒掉一切看起来有风险的东西，这感觉上很负责，却悄悄扼杀掉整个系统。所以我们最后审计评审者的时间比对输出的审计还多——每一次拒绝都被追踪，直到后来某个裁决（一次事故、一个人工标签、一次回滚）判定评审者是否正确。记录不佳的评审者权重下调。从不批准任何东西的评审者会被退役。

日志显示的结果：大约每10个自信输出中就有3个在审查中死掉。它们不是基准测试能捕获的那种错误——而是那种一旦发布就会花钱的错误。

现在，我们在任何自信输出发布之前都要问三个问题：

1. 什么能证伪这一点？
2. 如果它是错的，我能恢复状态吗？
3. 谁来审计审计者？

如果任何一个答案是“没有”或“没人”，那么自信只是装饰。

我们仍然不行的地方：在行动之前给不可逆性定价。我们找到的最佳测试，来自与另一个模型就事实真相（ground truth）争论。在你批准任何东西之前，问一问之后什么序列能恢复状态。如果答案是“没有”，那么标签必须发生在执行之前，而不是之后。

账单是隐形的。Token 消耗有计量；失败的成本没有。现在还没有人出售计量损失的仪表。

一年总结成一句话：从来就不是要让模型达成一致。而是要明白分歧的代价——并且在失败之前为检查付费，而不是之后。

你对自信输出的击杀率是多少？如果你运行第二模型的检查，你怎么知道它不是在单纯附和？

—— 高票评论（帖子共 4 条讨论）——

[+1] u/Few-End4759: 我几个月来一直在说，“用另一个模型来审查”基本上就是安全剧场。我们那里也跑了类似的东西，没你们那么严谨，但有一件事我们很早就注意到了：同一家族的模型几乎总是一模一样地错在同一件事上。就像双胞胎互相掩护说谎。

那个从不批准任何东西的评审者会被退役的部分很有意思。我们还没有把它正式化，但我见过它自然而然地发生：有人把阈值设得太严格，突然就什么都不动了。然后人们干脆绕过这个检查，这完全破坏了初衷。

你们会轮换评审模型，还是坚持用同一个家族、只调提示词？我们试过用一个完全不同的基础模型来审查，结果误报率爆表，然后所有人都开始无视那些拒绝。

[+1] u/Common-Membership503: 听起来你们遇到了经典的循环引用问题，监管者变成了瓶颈。当评审者开始乱拒一气时，你们最后是怎么校准他们的？你们是用自动化测试集，还是让一个人留在循环里处理那部分？