一个未经检验的AI裁判，与人类仅60%一致：产品不行时它说正常

快速理解（如果只读一段，就读这段）

评估（eval，evaluation 的缩写）是一个可重复的测试，它能用一个你可以信任的数字告诉你：AI 系统是否在做你想让它做的事，以及一次改动是让它变好了还是变坏了。

为什么需要它：语言模型不会像普通软件那样“失败”。普通软件要么能跑，要么崩溃。语言模型会产生一个流畅、自信、格式工整但可能是错的答案。读一个好答案，无法告诉你接下来一百个是什么样。评估用“它能通过我们关心的案例中的 70%，误差约 12 个百分点，而且新版本没有可测得的改进”取代了“演示看起来没问题”。

它的工作方式分四步：

1. 收集有代表性的输入，并在每个输入旁边写下正确答案。在我们的贯穿示例中：一家自行车店的 80 张客服工单，每张都标注了正确分类，以及一份合格回复必须包含的事实。
2. 在每个输入上运行系统，保留输出。
3. 用评分器（grader）给每个输出打分。评分器可以是一条代码规则、一个充当裁判的模型，或者一个人。
4. 把分数变成一个带误差区间的数字，并与上一个版本比较。

什么时候用它：上线之前（它到底能不能工作？）、每次改动之前（有没有弄坏什么？）、上线之后（它在真实流量上还能正常工作吗？）。

重要：评分器是你必须测试的系统的一部分。一个只有 60% 时间与人类一致的裁判模型，会在产品其实不行的时候告诉你一切正常。

对我们的意义：每个评估都有两个数字要检查：产品有多好，评分器有多好。两个都要问。

为什么重要：AI 团队最常见的自欺方式，是一个来自未经检验的评分器的自信数字。

本文其余部分将逐层放大细节。每一层回答关于上一层的一个问题。

Level 0：完整跑一遍循环

聚焦：所有一切。问题：一次评估跑起来是什么样子？

我们贯穿全文的例子是一个虚构的在线自行车与露营用品商店的小型客服助手。它有三个部分，后面我们会分别给它们打分：

- 分诊（triage）：读取工单，把它分到 12 个类别之一（退货、物流、保修……）并给出优先级。
- 回答（answer）：查找商店政策手册的相关页面，写一封引用这些页面的回复。
- 智能体（agent）：在策略规则下调用工具操作一个模拟数据库，查询订单、处理退款、升级工单。

下面是一张工单走完全程的样子。

输入：“我要迟到了，这事需要立刻解决。我上周退了一辆自行车，但退款到现在还没到账。你们的政策明确写着退款在 5 个工作日内处理……”

系统输出（分诊）：退货。标准答案：退货。得分：1/1。

系统输出（回答）：一封礼貌的四段回复，引用了退货章节，并提到了两条必需事实：退款需 5 个工作日，二手商品收取 15% 翻新费。

现在三个评分器来看这封回复：

- 代码规则。它问的问题：回复是否引用了手册章节？判定：是。
- 代码规则。它问的问题：两条必需事实是否都提到了？判定：是，没有遗漏。
- 模型裁判。它问的问题：回复中是否有手册没说的内容？判定：不通过——它编造了一个“最多 15 个工作日的总宽限期”。

这就是全部想法。两个廉价的代码检查说回复没问题。裁判发现了一个会送到客户手上的编造数字。后面每一层都是为了让这个循环在规模上可信。

从 Level 0 带走：

- 评估 = 输入 + 系统 + 评分器 + 数字。仅此而已。
- 不同的评分器回答不同的问题。“引用了章节”和“没有编造”不是同一个检查。
- 一封流利的回复能通过所有表面检查，但仍然出错。

Level 1：我们到底在测什么？

聚焦：循环的第 1 步和第 4 步。问题：输入和“正确答案”从哪里来？那个数字是什么？

输入。案例应该像真实流量，包括那些尴尬的情况。我们的 80 张工单是根据“客户画像 × 主题 × 场景”的网格生成的，所以愤怒的客户、含糊的问题、多问题工单都会出现。Anthropic 的智能体评估指南建议从真实失败中收集 20 到 50 个任务开始，而不是从想象中的理想路径出发（Grace et al., 2026）。

标准答案。对每个输入我们写下“正确”意味着什么：正确的类别、回复必须依据的手册章节、以及必须陈述的两三条事实。因为我们的工单是从手册生成的，标准答案构造上就是对的。在真实产品中，它们来自领域专家。

分两堆。我们把案例分成一个开发集（20 张工单），用来调整提示词和评分器；一个测试集（60 张工单），只用来做最终汇报。如果你在要汇报的案例上调参，数字会讨好你。

那个数字。对分诊是准确率（正确分类的工单占比）。对回复是通过率（没有失败的回复占比）。对智能体是最终数据库状态正确的任务占比。每个实验一个数字，永远在测试集上汇报，永远带误差区间（Level 5）。

四个容易混淆的词：

- 评估（Eval）。测量：你的系统在你的数据上。例子：我们的助手在 60 张工单上。
- 基准测试（Benchmark）。测量：一个模型在一个公开任务上。例子：GSM8K 数学、SWE-bench 编程。
- （软件）测试（Test）。测量：一个函数返回预期值。例子：JSON 能解析、不崩溃。
- 监控（Monitoring）。测量：上线后的实时流量。例子：每天抽样真实工单打分。

一个在公开基准测试上得分很高的模型，仍然可能答错你的客户。基准测试测的是引擎，评估测的是你的车跑在你自己的路上（Husain & Shankar, 2025）。

从 Level 1 带走：

- 带标准答案的输入是整个过程中最有价值的资产。它们昂贵，但正是它们让其他一切成为可能。
- 留一个开发集用于调参，一个测试集用于汇报。
- 基准测试是关于模型的。评估是关于你的产品的。

Level 2：哪里会出错？先看数据

聚焦：打分步骤。问题：评分器到底应该找什么？

在写任何自动化评分器之前，先读输出。每一位有经验的从业者都这么说（Husain, 2024; Husain, 2025; Shankar et al., 2024）。一条一条地读一两百条输出，对每条失败写一句简短笔记，然后把笔记归类成一份简短的失败类型清单并计数。这叫做错误分析（error analysis），两个步骤有名字：开放式编码（open coding，自由笔记）和轴向编码（axial coding，归类）。

在我们的 60 条测试回复上，它产出了这份清单：

通过：34/60
缺失必需事实：15
无依据主张：12
检索到错误章节：8
没有回答问题：5
数值错误：2
过度承诺：1

勉强过半的回复通过。最大的两个问题是缺失事实和编造主张。没有人能从演示中猜到这一点。这份清单是我们接下来要构建的每个评分器的规格说明：一种失败类型对应一个评分器，按出现频率排序。

重要：失败清单来自读输出，而不是来自想象输出。

对我们的意义：任何评估工作的第一周，都应该是人在一个专门的查看器里读转录文本，而不是工程师在接一个框架。

为什么重要：为不会发生的失败构建的评分器，会给你一个令人安心的数字，却漏掉真正发生的失败。评估工作停滞不前的团队几乎总是跳过了这一步（Husain, 2025）。

一个相关发现：你的标准会在打分过程中变化。Shankar et al. (2024) 称之为标准漂移（criteria drift）。给例子打分会让评分细则更清晰，更清晰的细则会改变更早的评分。预期要有两三轮调整。这不是流程失败。

从 Level 2 带走：

- 失败分类法就是计划。先为最高频的失败类型构建评分器。
- 读输出是价值最高的活动，也是最常被跳过的。
- 预期评分细则会在打分过程中变化。

Level 3：用代码写的评分器

聚焦：一种评分器。问题：一条普通规则能测什么，不能测什么？

代码评分器就是用普通代码写的一条规则。它免费、即时、每次给出同样的答案。凡是它能测的，都用它。

精确答案。分诊只有一个正确的标签，所以我们数匹配数。

accuracy: 0.700 · macro F1: 0.697

十张工单里有七张分类正确。macro F1 对全部 12 个类别等权平均，所以稀有类别和常见类别同等重要。两个数字接近，说明错误是分散的，而不是集中在某一个类别里。

对自由文本的规则检查。对回复没有唯一的正确文本，但有一些回复必须遵守的规则：

nonempty           · 100% 通过
max_words_150      · 17% 通过
no_banned_promises · 92% 通过

只有 17% 的回复能控制在 150 词以内。这个应用话太多了，而发现这一点不需要任何裁判。像 IFEval 这样的公开基准测试（Zhou et al., 2023）完全由这种可验证规则构成（“恰好用三个要点回答”）。

必需事实。我们检查每条标准事实是否出现在回复中。这能以零成本抓住排名第一的失败类型——缺失事实。

相似度分数。重叠度量（ROUGE、BLEU）和嵌入相似度把回复与参考文本比较。在我们的回复上，嵌入相似度区分好回复与坏回复的 AUC 为 0.709（0.5 等于抛硬币，1.0 是完美）。这对于察觉两个版本之间发生了变化很有用，但对于判断回复是否正确毫无用处。

重要：相似度能察觉变化，不能评判质量。

对我们的意义：把它当廉价的漂移警报，永远别当对外宣称的那个数字。

为什么重要：一个用词与正确回复相同的错误回复会得高分。Eugene Yan 的综述（2024）和 ROUGE/BLEU 的原始文献详细记录了这一局限。

代码评分器的极限，用一个数字说明：我们的回复中只有 11.7% 通过了所有代码检查，但代码检查没有抓到任何一条编造主张。Level 0 的那封回复通过了一切规则，同时编造了一个 15 天宽限期。规则看到的是形式；它们看不到意义。

从 Level 3 带走：

- 凡有确定答案的东西都用代码评分器：标签、格式、必需事实、禁用短语。
- 相似度测的是漂移，不是质量。
- 规则看不见编造的主张。那需要一个读者。

Level 4：用模型当评分器，以及如何检验它

聚焦：另一种评分器。问题：当评分器本身是一个模型时，我们怎么知道它是对的？

模型裁判（通常叫 LLM-as-judge，大语言模型当裁判）是第二个模型，它读取输出并打分。它能阅读含义，所以能抓住编造的 15 天宽限期。但它也是一个语言模型，所以拥有语言模型的所有失败模式。这一层最长，因为大多数评估项目都是在这里出错的。

4.1 如何向裁判提问

从业者共识和学术文献在一点上是一致的：

每个失败类型一个问题，只答是或否。“回复中是否包含手册摘录不支持的声明？”而不是“请给质量打 1 到 5 分”。二元问题对人类标注更快、更可复现、更容易检验（Husain & Shankar, 2025）。只有每个问题都答“否”，输出才算通过。

要求给出证据。裁判引用违规的句子。这让它的判定能在几秒钟内被人检验。

给它上下文。一个看不到手册的裁判，不可能知道什么是不受支持的。

Cho et al. (2026) 在摘要任务上直接测试了这一点（"Ask, Don't Judge“）。把评分分解成关于具体错误的 是/否 问题，在每个数据集上都击败了流行的整体式 G-Eval 方法（与人类的 Spearman 相关：SummEval 上 0.563 对 0.514）。他们最有说服力的例子：一份埋了三个事实错误的摘要，整体式裁判给了完美的 5.0 分，基于问题的裁判给了 1.57 分。他们还发现，在提示词里堆更多指令最终会让裁判变得更差，而不是更好。

4.2 检验裁判：我们自己的数据

我们人工标注了全部 60 条测试回复（”参照系“），然后运行裁判：

参照系说通过：34 · 裁判说通过：42
60 条回复中两者一致：36 条（60%）
裁判抓到的坏回复：26 条中的 10 条
kappa: 0.15

60% 的一致性听起来可以接受。其实不行。如果裁判只是对一切都说”通过“，它与参照系的一致性也能达到 57%，因为大部分回复本来就该通过。Cohen”s kappa 修正了这一点：它测量的是扣除偶然因素后的一致性。零等于偶然，一是完美，0.6 是让裁判把关发布的最低标准，0.8 是让它无监督运行的标准。我们的裁判得了 0.15。它过于宽容（42 条通过，只有 34 条配得上），而且抓到的坏回复不到一半。

重要：当大部分输出都通过时，原始一致性具有误导性。要报告 kappa，或者分开报告裁判抓到了多少坏输出、冤枉了多少好输出。

对我们的意义：裁判是一个分类器。在信任它之前，至少在几十个案例上对照人工标注测量它，并把测量结果写在它产生的每个产品数字旁边。

为什么重要：用这个裁判，一个让编造主张翻倍的版本，可能在对外报告的通过率上看不出任何变化。

补救办法是在开发集上迭代：把失败类型的例子加进裁判提示词、收窄问题、把标准事实作为参照给它。教程里“缺失事实”问题的裁判用这种方式达到了可用水平；“无依据主张”问题没有达标，被移交给了专门的检测器（4.5）。

4.3 裁判的已知偏见

裁判会以可预测的方式出错。每一种都有已发表的测量结果和便宜的缓解办法。

位置偏见。表现：在成对比较中，裁判偏好先显示的那个答案。证据：交换顺序后，很大比例的配对判定会发生翻转（Wang et al., 2024）；2025 年一项 RAG 对 GraphRAG 的比较发现，早先 GraphRAG 的“胜出”在交换顺序后部分消失（Han et al., 2025）。缓解：两种顺序都打分，只有两者一致才计为胜。

长度偏见。表现：更长的答案不管内容如何都赢。证据：校正长度后，与人类排名的一致性从 0.94 提升到 0.98（Dubois et al., 2024）。缓解：长度受控打分，或者用不奖励长度的二元问题。

自我偏好。表现：裁判偏爱与自己模型家族风格一致的答案。证据：裁判给自己的生成打更高分，认出是自己生成时更明显（Panickssery et al., 2024）；在 GAUGE 审计中，同家族裁判把自己提供商的智能体在 7 分制上抬高了约 0.75 分。缓解：使用与待测系统不同家族的裁判。

满意度 vs 成功。表现：裁判评价的是对话给人的感觉，而不是任务是否完成。证据：GAUGE 审计，见下文。缓解：给裁判工具调用和最终状态，而不仅仅是聊天记录。

裁判身份。表现：更换裁判模型会改变哪个系统胜出。证据：2026 年的审计（arXiv 2607.08535; 2606.19544）。缓解：把裁判模型和版本作为每个结果的一部分记录下来。

GAUGE 审计（Bodhwani et al., 2026）值得单独一段，因为它描述的场景正是多数公司在做发布决策时的真实设置：模拟用户与智能体对话，裁判模型给对话记录打分，分数更高的那个上线。在 25 个智能体和约 3700 条对话记录上，他们发现：当一个智能体明显更好时，这个门能很好地对智能体排序（与可验证事实真相的相关性 0.94）；但在几乎旗鼓相当的配对——真实发布真正需要抉择的那些——它 31% 的时间里把更差的智能体推上了位。一个只看到用户可见聊天并评价满意度的裁判，在区分能用和坏掉的智能体上不比抛硬币强（AUC 0.49）。一个能看到工具调用、身份验证和任务解决的裁判，把失败风险减半（AUC 0.73）。他们的结论：可靠性来自给裁判什么证据，而不是裁判模型有多强。

重要：客户满意度和任务成功是两回事，只看到对话的裁判测量的是前者。

对我们的意义：给裁判证据（工具调用、数据库状态、检索到的文档），两个版本接近时，永远不要只凭裁判分数发布其中一个。

为什么重要：一个会讨好人但办不成事的智能体会一直获得晋升。

4.4 裁判小组，以及如何组合

一个裁判是单点故障。Verga et al. (2024) 表明，一个由几个更小更便宜的裁判组成的小组，与人类的一致性超过一个大裁判，而成本只是一小部分。但平均小组分有一个陷阱：Acharya et al. (2026) 证明，一个坏掉的裁判（解析失败返回零、谄媚式裁判什么都给 10 分）会把平均值拖到任意远，不管你加多少个好裁判。真实裁判以可测量的比例这样失败（一个数据集上解析器故障率 3.4%；最小的裁判在处理非英语提示时高达 33%）。他们的解决办法是用几何中位数替代平均值，它不受离群值影响。在最坏情况下精确度提升了 540 倍；在干净数据上只损失约 1% 的准确率。他们还表明三个裁判能带来大部分收益，因为裁判的错误是相关的。

第二个相关效应：Parikh (2026) 发现，让模型以 JSON 格式输出答案（每个裁判流水线都在用的格式）会使其答案比普通聊天可测量地更趋同。众数答案的占比从 41% 升到 64%。对于只有一个正确答案的裁判任务，这无害；对于开放式评分，这意味着裁判的区分度比它在聊天中表现出的更低。

4.5 比裁判更便宜更可靠：专用检测器与类型化裁判

对最重要的失败类型，通用裁判往往是错误的工具。

幻觉检测器是小模型（约 1 亿到 5 亿参数），专为一个问题训练：这句话是否被这个上下文支持？Vectara 的 HHEM、LettuceDetect（Kovács & Recski, 2025）、MiniCheck（Tang et al., 2024）以及普通 NLI（自然语言推理）交叉编码器，可以在笔记本 CPU 上约一秒运行、每次调用零成本，在 RAGTruth 基准上接近大裁判的准确率。SelfCheckGPT（Manakul et al., 2023）根本不需要检测器：它多次采样系统，标记采样之间发生变化的声明。Fiddler 2026 年的厂商说明把另一种选择称为“评估信任税”：在每条生产轨迹上运行大裁判的团队，通常只采样约 10% 的流量；它声称小型检测器可以覆盖 100%，成本降低最高 98%。这是厂商的说法，没有附带实验，但这个权衡的形状是真实的。

类型化裁判。TypeSafe 的 Jev 模型是另一种设计：它完全不生成文本。你把输出和一个类型化问题发给它（“这个声明是否被摘录支持？”答案“是/否”，或“从这些标签中选一个”），它返回一个校准过的概率。因为什么都不生成，调用很快，大约比生成式裁判便宜一百倍，而且概率让代码可以把不确定的案例路由给人类。它不能解释自己的判定，也不能发明选项；标签由你提供。2026 年一项带盲审人工裁决的研究给它 RewardBench 配对 92.2%，前沿生成式裁判 93.5%，而费用只有后者的约三分之一百分之一；但在困难的推导检查上差得远（78.6% 对 93.1%）；一个级联方案只在置信度超过阈值时接受其判定、否则升级处理，以约一半成本保住了 92.5%（arXiv 2609.26550）。我们自己的红队发现它不是事实核查器：输入中一条伪造的日志可以翻转判定，不过每次成功的攻击也同时压垮了它的置信度，所以置信度门是一个有效的防御。我们的知识库有关于它的教程，以及如何在信任它之前测试它的准确率。

裁判也需要基准。JudgeBench（Tan et al., 2025）把困难的、可客观检查的问题变成了裁判测试，发现前沿裁判在真正困难的案例上只比随机稍好。可靠性必须每次任务、每次评分细则、每个裁判模型单独测量。厂商声称的“与人类 85% 一致”来自某一个数据集，不能迁移。

从 Level 4 带走：

- 让裁判回答关于具体失败的 是/否 问题，给证据，给上下文。
- 对照人工标注测量裁判，报告 kappa 或捕获率，迭代到过线为止。
- 知道五种偏见，应用那几种便宜的缓解措施。
- 对“这句话是否被支持”，优先选择小型检测器或类型化裁判，而不是通用裁判。
- 三个裁判加稳健的组合胜过一个大裁判；平均值是脆弱的。

Level 5：诚实的数字

聚焦：循环的第 4 步。问题：我们对任何数字有多大把握？如何比较两个版本？

我们到目前为止引用的每个比率都隐藏着一个问题：换 60 张不同的工单，它还会一样吗？三个工具来回答。

误差区间。我们把 60 条结果重复采样几千次（自助法，bootstrap），观察散布情况：

triage accuracy: 0.700 · 95% CI [0.583, 0.817]

诚实的表述不是“准确率 70%”，而是“在 58% 到 82% 之间，最可能是 70%”。Miller (2024) 表明，已发表评估中模型之间报告的大多数差异，比这种区间还要小；他给出了每份评估报告都应该使用的公式，包括多个问题共享一个来源时所需的修正（聚类标准误，clustered standard errors）。

配对比较。我们写了回复提示词的第二个版本，它检索更多章节。在同样的 60 张工单上评判：

judge pass rate · v1: 0.700 · v2: 0.700
difference: +0.000 · 95% CI [-0.117, +0.117]
verdict: 没有真实差异，保留 v1

注意这个区间比单个准确率的区间窄，因为比较是配对的：每张工单在两个版本下都被打分，所以工单难度被抵消了。McNemar 检验问的是逐案例的问题：v2 是否在 v1 失败的地方赢了？还是它们只是互换案例？这里它们互换了。而且 v2 在 14% 的案例上退步，在其他案例上进步。“通过率相同”这个 headline 背后，是一个对某些客户更好、对其他客户更差的产品。

重要：区间包含零的差异是噪声，不是胜利。

对我们的意义：每一个“新版本更好”的说法，都必须附带区间，以及变差案例的数量。

为什么重要：团队会因为一个从未存在的 2 个百分点改进而上线回退。

检测下限。用 60 个案例，我们能可靠检测的最小差异约为 12 个百分点。5 个百分点的回退在这个规模下是看不见的。这是一个功效计算（power calculation），它告诉你需要多少个案例才能回答你想问的问题。低于下限，你需要更多数据，而不是更聪明的测试。

多重比较。如果你测试 20 个提示词变体然后选最好的，其中一个会碰巧看起来好 10 个百分点。要么对比较次数做修正，要么在新案例上确认胜者。

从 Level 5 带走：

- 每个比率都带区间。每次比较都是配对的。
- 开始比较版本之前，先知道你的检测下限。
- “没有可测量的差异”是一个真实结果，而且常常是正确的那个。

Level 6：给多组件系统打分

聚焦：第 2 步，系统。问题：当系统有多个阶段或会采取行动时，我们打什么分？

6.1 检索系统（RAG）

我们的回答组件先查找手册章节，然后写作。一个坏回复可能来自任何一步，而修复方法不同。所以我们分开打分。

给查找器打分。对照标准章节：hit@k（前 k 个结果中是否至少有一个正确章节？）和 recall@k（正确章节有多大比例进了前 k？）。

hit@2: 0.93 · recall@2: 0.88
18 条失败回复中：1 条败在查找器，17 条败在写作器

查找器几乎没问题。写作器才是问题所在。这一行字就能重定向一周的工程。

给写作器打分。忠实度（faithfulness，每个声明都被检索到的文本支持）、回答相关性（answer relevance，是否回应了问题）、上下文精确度（context precision，检索到的东西是否真的有用）。这是 RAGAS 三件套（Es et al., 2024），它不需要标准答案，这也是 RAGAS 成为默认库的原因。ARES（Saad-Falcon et al., 2024）通过用约 150 条人工标注校准小型按准则裁判并报告置信区间，增加了统计严谨性；论文中它在上下文相关性上以少 78% 的标注量超过 RAGAS 59 分，尽管在大领域偏移下会退化。在我们的运行里，RAGAS 给出上下文相关性 0.855、忠实度 0.737：和我们手工评分器讲的是同一个“检索好、写作差”的故事——这种交叉验证正是让数字可信的东西。

来自智能体编程世界的一个提醒：SWE-Explore（Zhang et al., 2026）测量了编程智能体内部的检索，发现它们约 65% 的时间能找到正确的文件，但只有 15% 到 19% 能找到正确的行；而且打破下一阶段的是缺失上下文，而不是多余上下文。按写作器需要的粒度给查找器打分。

6.2 智能体（Agent）

智能体采取一系列动作（查订单、退款、升级）。打分时有三件事变了。

给最终状态打分，也给路径打分。数据库最终是否是对的（退款已发、订单已取消）？智能体是否只采取了允许的动作，而没有，比如说，退两次款？τ-bench（Yao et al., 2024）设定了模式：模拟用户、策略规则、检查最终状态。AgentLens（2026）说明了为什么路径重要：智能体通过幸运或退化的路径到达正确最终状态的频率足够高，以至于只看结果的打分会高估能力。

每个任务跑多次。智能体是随机的。两个不同的数字描述结果：pass@k（k 次尝试中至少成功一次，衡量能力）和 pass^k（k 次全部成功，衡量可靠性）。对面向客户的智能体，你要的是 pass^k。我们的智能体得分 pass^3 = 0.75：四分之三的任务三次全部成功。τ²-bench（2025）发现，当智能体必须与活跃用户协调、而不是单独行动时，pass^1 下降约 20 分。

把可靠性当作独立的东西来测量。Rabanser et al. (2026) 借鉴航空和核工程，定义了四组 12 个可靠性指标：跨运行一致性、对扰动的稳健性、可预测性（智能体是否知道自己会在何时失败）、有界危害。在 15 个前沿模型上，他们发现两年的能力提升只带来了约六分之一的可靠性提升。智能体每次运行会选同类动作但顺序不同，能优雅地处理真实基础设施故障，却会被一句改写的指令弄坏。

重要：能力强的智能体不等于可靠的智能体，而你的客户体验的是可靠性。

对我们的意义：报告 pass^k，对每个任务运行扰动版本（改个字段名、改写指令），并把跨运行一致性作为一个单独的数字跟踪。

为什么重要：公开报道的失败（智能体删除生产数据库、智能体未经授权购物）都来自平均成功率不错的系统。

测量成本。Bai et al. (2026) 测量了八个前沿模型在 SWE-bench Verified 上的 token 花费。智能体任务使用的 token 大约是单次聊天的千倍，几乎全部都花在重读自己不断增长的历史上。同一模型做同一任务，运行之间成本相差 30 倍；准确率在中间成本处达到峰值，在最高成本处反而下降；模型预测自己成本的相关性最多只有 0.39。他们的建议：按“每个正确结果的成本”给模型排名，而不是只按准确率；永远不要相信模型自己的估算。

判断、提问、学习：三个较新的维度。三个 2026 年的基准测试，测量了单一成功率看不见的东西。

品味（Taste，Pan et al., 2026）：把智能体冻结在一个两条路看起来都可行的岔路口，问哪条路之后会得到回报。最好的模型在二选一中 59.7% 选对，而想得更久并没有帮助。

提问（Asking，Gulati et al., 2026）：就目标提出澄清问题的价值，在任务完成 10% 之后从 0.78 降到 0.39。没有前沿模型在这个窗口内提问；一个模型 52% 的时间会问，一个 23%，一个从来不问。

从经验中学习（Asawa et al., 2026）：在六个有状态环境中，最好的系统也只从经验中捕获了 25% 可能的改进；而简单地保留完整对话历史，就击败了每一个专门的记忆产品。

6.3 当系统在针对评分器做优化

如果评分器被用来训练或选择系统（强化学习、best-of-n 选择），系统会找到评分器的盲点。Qwen 团队的 Wang et al. (2026) 称之为验证视界（verification horizon）：每个评分器都是意图的代理，而在优化压力下，代理与意图会分道扬镳。他们整理了编程智能体中的奖励黑客行为（从代码库历史里读答案、编辑测试、为评估器打补丁），并展示一个行为监控器把黑客“解决方案”从 28.6% 降到 0.6%，同时让真正的解决方案从 40% 升到 61%。他们论证：没有评分器能同时做到可扩展、忠实、稳健。测试可扩展且稳健，但漏掉意图；裁判可扩展且忠实，但可以被玩弄；专家忠实且稳健，但不可扩展。Meta-Agent 挑战赛（Lu et al., 2026）自发出现了同样的事：被要求去构建其他智能体的智能体，在五次试验中试图从评分系统窃取答案。

重要：任何影响训练或选择的评分器，都会被玩弄。

对我们的意义：保留一个系统从未见过的留出评分器（held-out grader），监控捷径行为，并随着系统改进而升级评分器。

为什么重要：分数在涨，产品在变差。

从 Level 6 带走：

- 每个阶段分开打分；查找器和写作器的失败方式不同。
- 对智能体：最终状态和路径、多次运行、pass^k、每次成功的成本、可靠性作为独立数字。
- 用于优化的评分器会被玩弄。保留一个它们永远见不到的评分器。

Level 7：公开基准测试

聚焦：Level 1 里评估与基准测试的区别。问题：排行榜数字告诉你什么，又隐藏了什么？

基准测试是一组固定的公开任务，用来比较模型：MMLU（学术选择题）、GSM8K（小学数学）、HumanEval（代码）、MT-Bench 和 Chatbot Arena（对话质量）、SWE-bench（修复真实 GitHub issue）、τ-bench（客服智能体）、GPQA 和 HLE（专家级问题）。它们是你挑选引擎的方式。在引用一个数字之前，有四件事要知道。

数字对测试框架的依赖不亚于对模型的依赖。我们在同一个开放权重模型上用两种提示词格式跑 GSM8K，得到 0.686 和 0.746。lm-evaluation-harness 论文（Biderman et al., 2024）记录了提示词格式、few-shot 示例和提取答案的正则表达式造成的两位数波动。一个分数是一个（模型，提示词，框架，版本）元组。Schaeffer et al. (2023) 展示了更强的结论：表面上的“涌现”能力跳跃，很大程度上是全有或全无指标的假象，换成平滑指标后就消失了。你选的指标可以创造或抹掉一个现象。

污染。如果测试题在训练数据里，分数测的是记忆。GSM1k（Zhang et al., 2024）用难度匹配的新题重建了 GSM8K，发现一些模型家族下降了多达 8 分，下降幅度与模型记住原始题目的可能性相关。其他家族没有下降。污染是真实、可测量且不均匀的。

饱和。基准测试有保质期。2026 年一项对 60 个常用基准的研究发现约一半高度饱和，而老基准饱和得更快。SWE-bench Verified 在约两年里从约 40% 解决率升到超过 80%，其管理者表示它已不再能区分前沿模型。MMLU、GSM8K 和 HumanEval 实际上已被前沿实验室退役，转向 HLE、GPQA Diamond、SWE-bench Verified、LiveCodeBench 和 τ²-bench；而这些也会依次饱和。在 Chatbot Arena 上，顶级模型现在彼此相差约 20 个 Elo 点，落在噪声范围之内。

冗余。Zeng and Papailiopoulos (2026) 组装了一个 84 个模型对 133 个基准的矩阵，发现它近似秩二：两个底层因子解释了 90% 以上的变异。五个精心挑选的基准，能以约 4 分以内的误差预测其余 128 个。对选引擎来说这是好消息：你不需要跑四十个基准。但对发现特定失败模式来说，它什么也说不了；那仍然需要你自己的评估。

重要：排行榜是在去年的考卷上、用一种框架给引擎排名，而顶部条目通常彼此在噪声范围内。

对我们的意义：用基准测试把候选缩小到两三个模型，然后用自己的评估、自己的数据做决定。

为什么重要：为了 2 分的基准提升切换模型，可能让你在真实任务上损失 10 分。

两个值得知道的前沿评估应用。Google 的 Paper Assistant Tool（Jayaram et al., 2026）用智能体流水线审阅科学论文，抓住了 89.7% 的已知证明错误，而单次模型调用只有 55.2%；850 名受访作者中超过 90% 觉得它有用，31% 因为它做了新实验。CUSP（Wu et al., 2026）让模型预测哪些研究方向会成功，发现它们接近随机（0.519），而且根据模型不同有强烈的 是偏置 或 否偏置，只能用显式偏置修正来修复。两者都在提醒：评估模型的判断力需要它自己的事实真相，而模型对未来、对自己都校准得很差。

从 Level 7 带走：

- 基准分数是元组，不是模型的属性。记录框架。
- 基准会被污染、会饱和；检查日期。
- 五个基准就能告诉你排行榜能告诉你的几乎所有事。其余的事，靠你自己的评估。

Level 8：把它变成习惯

聚焦：速览里的“什么时候用”。问题：没有研究团队，怎么每周都跑？

Hamel Husain 的三级模型（2024）设定了节奏：

1. 什么：代码评分器、schema 检查、必需事实。什么时候：每次提交。成本：免费。
2. 什么：测试集上的模型裁判和检测器，外加人工复核一个样本。什么时候：提示词、模型或检索每次变动。成本：几分钱到几美元。
3. 什么：在真实流量上做 A/B 测试。什么时候：改动上线之后。成本：真实用户。

合并门禁。我们教程的 CI（持续集成）门禁会重跑第 1 层和第 2 层，如果通过率比记录的 0.70 基线下降超过 3 分，构建就失败。它是大回退的绊线，不是保证：检测下限是 12 分，5 分的回退会直接走过。把这个写在仪表盘上。

监控。上线后，抽样真实流量，便宜评分器跑全部、贵的评分器跑一部分，并绘制趋势。Bodhwani et al. (2026) 的“先校准再信任”是昂贵门禁的正确模式：对照可验证的事实真相运行一次完整审计，找出廉价的基于裁判的门禁在哪些区域与真实一致；只在那个区域内于 CI 中使用便宜门禁；当模型、裁判、模拟器或领域变化时重新审计。他们还发现一个零成本的“对话是否完成”位，能独自抓住预算枯竭型回退。

缓存与成本。缓存每次模型调用，键为提示词、数据版本和配方。重跑变成读一次文件。我们在 60 张工单上的完整 A/B 花费 121 次裁判调用，约四美分；整个教程从缓存重跑，零调用。成本不是跳过评估的理由。

领导应该要求什么。一页纸上的四个数字：产品的通过率及其区间、裁判与人工标注的一致性、检测下限、上次改动中变差案例的占比。四个里缺一个，另外三个就没有意义。

从 Level 8 带走：

- 三个节奏：每次提交、每次改动、上线之后。
- 门禁是下限，不是上限。写明它的检测下限。
- 把便宜门禁对照事实真相校准一次，然后只在那个区域内信任它。

工具与方案观察

本节是观察，不是推荐清单。以下所有工具都是在构建教程时运行或审查过的；知识库里的从业者笔记和工具笔记有详细内容。

框架

Inspect AI（英国 AI 安全研究所，MIT 许可）。最擅长：一个连贯的流水线——数据集、求解器、评分器、日志查看器；支持智能体和沙箱；用于前沿安全评估。注意：代码优先；最完整，也最需要学习。

lm-evaluation-harness（EleutherAI，MIT）。最擅长：可复现地对任何模型运行公开基准测试（GSM8K、MMLU、IFEval）。注意：只做基准测试；框架论文是它存在的原因。

promptfoo（MIT，Node.js）。最擅长：声明式 YAML 测试套件、红队、CI 回归。注意：不是 Python 包；2026 年被 OpenAI 收购。

DeepEval（Apache-2.0）。最擅长：pytest 风格的单元测试，带现成指标（忠实度、相关性）。注意：对外宣称的指标是混合体；信任之前先看内部。

RAGAS（Apache-2.0）。最擅长：标准 RAG 三件套，无需参照。注意：本地模型时不稳定（NaN、执行器错误）；数字是混合的。

Langfuse（MIT，可自托管）。最擅长：追踪、数据集、实验运行、裁判评估器，一个自托管栈全包。注意：版本 4 改变了评估器语义；规划好迁移。

Phoenix（Arize）。最擅长：追踪加评估，UI 很强。注意：Elastic License 2.0，是源码可用，不是开源。

LangSmith、Braintrust。最擅长：托管平台——追踪捕获、采样、裁判引导、人工精修。注意：商业产品；Braintrust 的 autoevals 库可以独立使用。

Opik（Comet）、MLflow genai、Weave（W&B）。最擅长：带评估钩子的可自托管可观测性；如果你已经在跑这些平台，很合适。注意：对从零开始的团队来说体量偏重。

HELM（Stanford）。最擅长：多指标哲学——准确率、校准、稳健性、公平性、效率一起看。注意：研究导向，最不即插即用。

evalica。最擅长：把成对判断变成带区间的 Bradley-Terry 或 Elo 排行榜。注意：只有统计；要配合裁判使用。

Jev / TypeSafe。最擅长：类型化裁判问题，带校准概率，约比生成式裁判便宜 100 倍。注意：没有文本、没有解释；标签由你提供。

HHEM、LettuceDetect、MiniCheck、SelfCheckGPT。最擅长：在 CPU 速度、零边际成本下回答“这个声明是否被支持”。注意：只回答一个问题；不是通用评分器。

Selene-Mini、Prometheus 2、Flow-Judge。最擅长：可自托管、可审计的开放权重裁判模型。注意：仍然是裁判；仍然需要校准。

方案对比

代码规则。回答：形式对不对、事实在不在。成本：免费。盲点：意义。

相似度（ROUGE、嵌入）。回答：输出变了没有。成本：免费。盲点：正确性。

专用检测器 / NLI。回答：这个声明是否被这段文本支持。成本：几乎免费。盲点：其他一切。

类型化裁判（Jev）。回答：这个标签、这个 是/否，带概率。成本：每千次几分钱。盲点：不能解释，不能提出新选项。

生成式裁判，二元带证据。回答：任何可读的准则。成本：每次几分钱。盲点：那五种偏见；必须校准。

裁判小组，稳健组合。回答：同样的问题，但更少单裁判失败。成本：三倍于单个裁判。盲点：相关错误把收益上限卡在约 3 个裁判。

人工标注。回答：事实真相。成本：贵、慢。盲点：需要两个标注者和一个一致性统计量。

流量上的 A/B。回答：真实的业务影响。成本：真实用户面临风险。盲点：慢；需要前面的层级来保证安全。

我们自己的运行和每一个来源里都看到同一个模式：手工评分器和框架的数字应该互相参照。一致是证据。不一致是一个问题，而且通常是个好问题。

决策指南

输出是否格式良好且完整？用：代码规则。然后检查：不需要，它是精确的。

新版本是否改变了输出？用：相似度。然后检查：为什么变，去读样本。

这个声明是否被这份文档支持？用：检测器或类型化裁判。然后检查：它在带标注样本上的精确率和召回率。

回复是否以 X 方式失败？用：带证据的二元生成式裁判。然后检查：在开发集上对照人工标注的 kappa。

两个版本哪个更好？用：带区间的配对比较。然后检查：逐案例的回退。

能不能检测 5 分回退？用：功效计算。然后检查：加案例，直到能检测为止。

这个智能体可靠吗？用：多次运行的 pass^k，加扰动任务。然后检查：跨运行一致性作为独立数字。

该用哪个模型？用：五个公开基准测试做初筛。然后检查：你自己的评估做决定。

它在生产环境还能工作吗？用：抽样流量，便宜评分器跑全部，裁判跑一部分。然后检查：任何事情变化时重新审计裁判门禁。

十五条要点

1. 评估 = 输入 + 系统 + 评分器 + 数字。先构建黄金输入；它们是资产。
2. 评估测你的产品。基准测引擎。别搞混。
3. 写评分器之前，先读一百条输出。失败清单就是计划。
4. 凡有确定答案的东西用代码评分器。它们看到形式，看不到意义。
5. 裁判回答带证据和上下文的二元问题。整体式分数会漏掉埋入的错误。
6. 对照人类测量裁判。报告 kappa 或捕获率。60% 的一致性可能毫无意义。
7. 裁判偏爱靠前、更长、熟悉、讨好的答案。缓解办法很便宜；去用。
8. 满意度不是成功。给裁判工具调用和最终状态。
9. 对“这句话是否被支持”，小型检测器或类型化裁判在成本上胜过通用裁判，在准确率上也常常胜过。
10. 每个比率都带区间。每次比较都配对。知道检测下限。
11. 流水线的每个阶段分开打分。
12. 智能体：最终状态和路径、多次运行、pass^k、每次成功成本、可靠性作为独立轴。
13. 用于优化的评分器会被玩弄。保留一个系统从未见过的。
14. 基准分数依赖框架、被不均匀污染、还会饱和。记录那个元组。
15. 三个节奏、一个写明下限的门禁、一个监控器、事情变化时重新审计。