评估用例也是代码：警惕假阴性关卡 —

你编写了一个新的评估用例。它捕获了你刚刚在生产环境中看到的故障。你将其部署为一道关卡。恭喜——现在，在每次智能体运行的关键路径上，都有一段未经测试的代码在决定哪些内容可以发布，哪些内容会被拦截。

我们对待智能体评估的方式，仿佛编写它们才是困难的部分。其实并非如此。真正的难点在于确认你的评估用例确实具有区分能力：即它在不良轨迹上显示红色（失败），在良好轨迹上显示绿色（通过），而不是反过来。一个没有针对已知标记轨迹运行过的评估用例，只不过是一个带仪表盘的抛硬币游戏。

无人指出的故障：假阴性关卡

这就是潜在的灾难。你添加了一条规则来捕获幻觉产生的文件路径。但它存在一个正则表达式错误，导致它无法匹配任何内容。每次运行都通过了。你的仪表盘显示一切正常（绿色）。你感到安全。三周后，一位客户发现了你的“关卡”本应阻止的确切故障，而你才发现该规则从未触发过一次。

绿色的评估结果并不是智能体健康的证据。它只证明要么智能体是健康的，要么你的评估用例已损坏——除非你曾向其输入一条你已知为错误的轨迹并观察到它显示红色，否则你无法区分这两种情况。

评估用例也是代码。守护生产环境的代码需要针对固定测试数据进行测试。不知何故，评估用例免除了这一要求，而这是我看到的造成虚假信心的最大单一来源。

层级划分在此处的实际帮助

这一点之所以如此重要，与你首先应该如何对评估证据进行排序有关。不是按照成本轴排序——从廉价到昂贵是错误的思维模型。应该按照独立性轴排序：由生成输出的智能体伪造该信号的难易程度如何？

第一层级——智能体无法伪造的外部可观察证明。有效的 JSON、文件存在于磁盘上、编译成功、测试通过、在超时前完成、输出非空。这是客观事实，不含主观意见。
第二层级——针对智能体未参与的基线的统计信号。输出与任务规范之间的嵌入相似度、长度和重复性检查、差异比较是否实际产生了更改。
第三层级——模型即裁判。一种共享基础架构下的主观意见。这只是一个信号，绝非最终裁决。

这种排序正是使你的评估套件具备可测试性的关键。第一层级和第二层级是确定性的，运行成本几乎为零，且速度快——这就是为什么它们是你们的实时关卡：它们可以位于关键路径上并拦截运行。因为它们是确定性的，你可以将它们针对固定的轨迹语料库进行固定测试，并每次都获得相同的结果。这才是“测试你的评估用例”的真正含义。

第三层级做不到这一点。它是非确定性的、按量计费的且速度慢，因此仅适用于离线场景——它不能位于关键路径上，也无法以同样干净的方式进行回归测试，因为它无法两次给出稳定的答案。还有一个更深层次的问题：一个模型评判另一个模型的推理是循环论证。裁判与被裁判者共享相同的基础架构；不存在独立的客观事实。因此，第三层级仅允许检查被评判智能体未参与生成的产物，即便如此，它也只是“意见，而非证据”。你不应该基于它设置关卡，也不应该假装可以通过单元测试使其达到可靠状态。

实际结论：发布那 80% 的部分。大多数真实故障——过时的输出、崩溃、格式错误、幻觉路径、空结果——仅通过第一层级和第二层级就能确定性且免费地捕获。将裁判模型保留用于约 20% 的主观长尾情况，并明确标记其为意见。而恰恰是第一层级和第二层级的规则——那些确定性的规则——是你可以在信任之前且必须进行测试的。

您的新评估规则是未经测试的代码，正在守护生产环境

无人指出的故障：假阴性关卡

层级划分在此处的实际帮助