评估：如何判断AI系统是否真正有效

评估把「演示里看着挺好」换成可重复、带误差线的数字：先读输出建失败清单，再按失败类型配评分器，最后用区间和配对比较判断改动是真好还是噪声。

SERGII MAKAREVYCH（@SERMAKAREVICH）教程 · 已翻译 · 约 53 分钟

阅览室 · AI 最佳实践#评分#评估#系统#判断#裁判原文

本文面向所有参与交付、采购或验收基于大语言模型（LLM）所构建软件的人：工程师、产品经理和 CEO。用平实的语言写成，从宏观图景一路讲到细节。每一个数字都来自文末列出的来源：我们自己关于一个小型支持助手的可运行教程，或一篇已发表的论文。

快速把握（如果你别的都不读，就读这一段）

评估（eval，evaluation 的简称）是一种可重复的测试，它用一个你可以信赖的数字告诉你：一个 AI 系统是否做了你想要的事，以及某次改动是让它变好了还是变差了。

它为什么存在：语言模型的失败方式不同于普通软件。普通软件要么正常工作，要么崩溃。语言模型会给出一个流畅、自信、格式规范的答案，而这个答案可能是错的。读到一个好答案，并不能说明接下来的一百个答案如何。评估把“在演示里看着挺好”替换成“它在我们关心的用例中通过了 70%，误差约 12 个百分点，而且新版本并没有可测量的提升”。

它的工作方式，分四步：

收集重要的输入，并在每一条旁边写下正确答案。在我们的贯穿示例中：一家自行车店的 80 张客户支持工单，每张都带有正确的分类，以及一条好回复必须包含的事实。
在每个输入上运行系统，并保留输出。
用评分器给每个输出打分。评分器可以是一条代码规则、一个充当裁判的第二个模型，或一个人。
把各项评分汇总成一个带误差范围的数字，并与上一个版本比较。

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

重要提示： 评分器是你必须测试的系统的一部分。一个与人类判断只有 60% 一致率的评判模型，会在你的产品其实有问题时告诉你一切正常。
这对我们意味着什么： 每个评估都有两个数字要检查：产品有多好，以及评分器有多好。两者都要问。
为什么这很重要： 一个 AI 团队自欺欺人的最常见方式，就是从一个未经检验的评分器那里得到一个自信满满的数字。

本文的其余部分逐层放大，一次深入一层。每一层回答一个关于上一层的问题。

第 0 层 · 整个循环，跑一遍，处理一张工单
第 1 层 · 我们到底测量什么？·（输入、标准答案、那个数字）
第 2 层 · 哪里会出错？·（先看数据）
第 3 层 · 用代码做评分器 ·（便宜、精确、对语义视而不见）
第 4 层 · 用模型做评分器 ·（灵活、有偏见、必须检验）
第 5 层 · 诚实的数字 ·（误差范围、A/B 测试、需要多少样本）
第 6 层 · 由多个部分组成的评分系统 ·（检索、智能体、成本、可靠性）
第 7 层 · 公开基准 ·（排行榜能告诉你什么、不能告诉你什么）
第 8 层 · 把它变成习惯 ·（门禁、监控、何时重新检查）
然后 · 工具与方法、决策指南，以及参考资料

第 0 层：整个循环，跑一次，处理一张工单

聚焦于：一切。问题：一次评估在运行时是什么样子？

贯穿全文的示例是一个小型客服助手，服务于一家虚构的在线自行车与露营用品商店。它由三部分组成，后面我们会分别用不同方式对它们评分：

triage：读取工单，将其归入 12 个类别之一（退货、配送、保修……），并附带一个优先级。
answer：找到商店政策手册中的相关页面，并写出一封引用这些页面的回复。
agent：在政策规则下，通过调用工具对模拟数据库进行操作，查询订单、发放退款并进行升级处理。

下面是一张工单走完整个循环的过程。

输入：“我上班要迟到了，需要立刻把这件事解决。我上周退回了自行车，但至今没看到退款。你们的政策明明写着退款在 5 个工作日内处理……”

系统输出（triage）：returns。标准答案：returns。得分：1 分（满分 1 分）。

系统输出（answer）：一封礼貌的四段式回复，引用了退货部分，并提到了两个必需事实：退款需要 5 个工作日，且二手商品需收取 15% 的补货费。

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

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

这就是整个思路。两个廉价的代码检查说这封回复没问题。评判员却发现了一个本会发给客户的编造数字。后面每一层都是关于如何让这个循环在大规模下变得可信。

从第 0 层延续下去：

一次评估就是输入、系统、评分器、数字。仅此而已。
不同的评分器回答的是不同的问题。“引用了某一节”和“没有编造任何内容”并不是同一种检查。
一段流畅的回复可以通过所有表面检查，却依然是错的。

第 1 层：我们究竟在测量什么？

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

输入。 案例应当看起来像真实流量，包括那些棘手的。我们的 80 张工单是从客户画像 × 主题 × 场景的网格中生成的，因此愤怒的客户、含糊的问题和多问题工单都会出现。Anthropic 的智能体评估指南建议从真实失败案例中选取 20 到 50 个任务作为起点，而不是从想象出来的顺利路径中选取（Grace et al., 2026）。

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

两堆数据。 我们把案例分成一个 dev 集（20 张工单），用于调优提示词和评分器；以及一个 test 集（60 张工单），仅用于报告。如果你在用于报告的案例上做调优，那个数字就会美化你。

那个数字。 对于分诊，它是准确率（被正确分类的工单占比）。对于回复，它是通过率（没有失败的回复占比）。对于智能体，它是以正确的数据库状态结束的任务占比。每个实验一个数字，始终在测试集上报告，始终带有误差条（第 5 层）。

四个容易混淆的词：

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

一个在公开基准测试中得分很高的模型，仍然可能错误地回答你的客户。基准测试衡量的是引擎，而评估衡量的是你的车在你的路上跑得怎么样（Husain & Shankar, 2025）。

从第 1 级延续下来：

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

第 2 级：哪里出了问题？先看数据

聚焦于：评分步骤。问题：评分者究竟应该看什么？

在构建任何自动评分器之前，先阅读输出。每一位有经验的实践者都这么说（Husain, 2024; Husain, 2025; Shankar et al., 2024）。逐条阅读一百到两百条输出，为每个失败写一条简短笔记，然后把笔记归组为一份带有计数的简短失败类型清单。这叫做错误分析，这两个步骤各有名称：开放式编码（自由笔记）和轴心编码（归组）。

在我们 60 条测试回复上，它产出了什么：

通过的回复：60 条中有 34 条
missing_required_fact · 15
unsupported_claim · 12
wrong_section_retrieved · 8
did_not_answer · 5
wrong_value · 2
over_promise · 1

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

重要提示： 失败清单来自阅读输出，而不是凭空想象。
这对我们意味着什么： 任何评估工作的第一周，都是人们在专门构建的查看器里阅读记录，而不是工程师搭建框架。
为什么这很重要： 为不存在的失败构建的评分器会给出一个令人安心的数字，却漏掉真正发生的失败。评估工作停滞不前的团队，几乎都跳过了这一步（Husain, 2025）。

一个相关的发现：你的标准会随着评分而改变。Shankar 等人（2024）称之为标准漂移。对样本评分会让评分标准更清晰，而更清晰的评分标准会改变之前的评分。预计会有两到三轮。这不是流程失败。

从第 2 级延续下来：

失败分类法就是计划。先为最主要的失败类型构建评分器。
阅读输出是价值最高的活动，也是最常被跳过的。
预计评分标准会在你评分的过程中发生变化。

第 3 级：用代码制成的评分器

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

代码评分器是用普通代码写成的规则。它免费、即时，而且每次给出相同的答案。凡是它能衡量的，都用它。

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

accuracy: 0.700 · macro F1: 0.697

十张工单中有七张被正确分类。Macro F1 对所有 12 个类别一视同仁地取平均分，因此稀有类别和常见类别一样重要。这两个数字接近，说明错误是分散的，而不是集中在某一个类别。

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

nonempty · 100% pass
max_words_150 · 17% pass
no_banned_promises · 92% pass

只有 17% 的回复能控制在 150 词以内。这个应用实在太啰嗦了，而且无需评判员就能发现这一点。像 IFEval（Zhou 等，2023）这样的公开基准完全由这类可验证规则构成（“用恰好三个要点作答”）。

必需事实。 我们检查每条黄金事实是否出现在回复中。这能以零成本捕捉最主要的失败类型——遗漏事实。

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

重要： 相似度察觉变化，但不评定质量。
这对我们意味着什么： 把它当作廉价的漂移警报，绝不要当作头条数字。
为什么这很重要： 一条错误的回复如果使用了与正确回复相同的措辞，就会得到高分。Eugene Yan 的综述（2024）以及最初的 ROUGE/BLEU 文献都详细记录了这一局限。

用一个数字说明代码评分器的局限。 我们的回复中只有 11.7% 通过了所有代码检查，但代码检查没有捕捉到任何一条编造的说法。来自 Level 0 的回复通过了每一条规则，却编造了一个 15 天的宽限期。规则看到的是形式；它们看不到含义。

从 Level 3 延续下来：

对于一切有确定答案的内容使用代码评分器：标签、格式、必需事实、禁用短语。
相似度度量的是漂移，不是质量。
规则看不到编造的说法。那需要一个读者。

第 4 层：以模型作为评分器，以及如何检验它

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

模型裁判（通常称为 LLM-as-judge）是第二个模型，它读取输出并为其打分。它能读懂含义，因此能抓住那个凭空捏造的 15 天额度。它同时也是一个语言模型，因此带有一个语言模型的所有失效模式。这一层篇幅最长，因为大多数评估项目正是在这里出错。

4.1 如何向裁判提问

从业者的共识与研究文献在形态上一致：

每种失效类型一个问题，回答是或否。 问“这条回复是否包含手册摘录未支持的断言？”，而不是“给质量打 1 到 5 分”。二元问题对人类标注者来说更快、更可复现，也更容易核查（Husain & Shankar, 2025）。只有当每个问题都回答“否”时，输出才算通过。
要求给出证据。 裁判引用有问题的那句话。这样它的裁决就能被人几秒钟内核查。
给它上下文。 看不到手册的裁判，无从知道什么是不被支持的。

Cho 等人（2026）在摘要任务上直接检验了这一点（“Ask, Don't Judge”）。把评分拆解为针对具体错误的“是/否”问题，在每个数据集上都胜过了流行的整体式 G-Eval 方法（在 SummEval 上与人类的 Spearman 相关系数为 0.563 对 0.514）。他们最有说服力的例子是：一篇埋了三个事实错误的摘要，从整体式裁判那里拿到了满分 5.0，而从基于问题的裁判那里只拿到 1.57。他们还发现，往提示里塞进更多指令，最终会让裁判变得更差，而不是更好。

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

我们手工标注了全部 60 条测试回复（即“参考标准”），然后运行裁判：

参考标准判为通过：34 · 裁判判为通过：42
二者在 60 条回复中的 36 条上一致（60%）
裁判抓出的坏回复：26 条中的 10 条
kappa：0.15

百分之六十的一致率听起来可以接受。其实不然。如果评判器对一切都简单地说“通过”，它会有 57% 的时候与参考答案一致，因为大多数回复都能通过。Cohen's kappa 对此做了校正：它衡量的是超出随机水平的一致性。零表示随机，一表示完美，0.6 是让评判器把关发布的通常门槛，0.8 是让它无人监督运行的门槛。我们的评判器得分是 0.15。它过于宽松（在只有 34 条应通过时通过了 42 条），并且漏掉了超过一半的差回复。

重要： 当大多数输出都能通过时，原始一致率具有误导性。应报告 kappa，或者分别报告评判器抓住了多少差输出、以及错误地判失了多少好输出。
这对我们意味着什么： 评判器就是一个分类器。在信任它之前，至少用几十个案例对照人工标注来测量它，并在它产出的每一个产品指标旁边报告结果。
为什么重要： 用这个评判器，一个把编造说法翻倍的版本，在头条通过率上可能毫无变化。

补救办法是在开发集上迭代：把该失败类型的示例加入评判器提示，收窄问题，把标准事实作为参考给它。教程中针对“缺失事实”问题的评判器通过这种方式达到了可用水平；“无依据说法”问题则没有，被交给了专门的检测器（4.5）。

4.3 评判器已知的偏差

评判器会以可预测的方式失败。每一种都有已发表的测量方法和廉价的缓解措施。

位置。现象：在成对比较中，评判器偏好先展示的那个答案。证据：交换顺序后，很大一部分成对判定会翻转（Wang et al., 2024）；一项 2025 年的 RAG 与 GraphRAG 对比发现，较早的 GraphRAG“胜出”部分在交换顺序后消失了（Han et al., 2025）。缓解措施：对两种顺序都评分，只有两者一致时才计为胜出。
长度。现象：无论内容如何，更长的回答更容易获胜。证据：对长度进行校正后，与人类排名的吻合度从 0.94 提升至 0.98（Dubois 等，2024）。缓解措施：采用长度受控的评分，或使用不奖励长度的二元问题。
自我偏好。现象：评判模型偏爱与其自身模型家族风格一致的答案。证据：评判模型给自己的生成结果打分更高，当它能识别出这些结果时尤为明显（Panickssery 等，2024）；在 GAUGE 审计中，同家族的评判模型将其自身提供商的智能体在 7 分制上抬高了约 0.75 分。缓解措施：使用与被测系统不同家族的评判模型。
满意度与成功率。现象：评判模型评估的是对话的感受，而非任务是否完成。证据：GAUGE 审计，见下文。缓解措施：将工具调用和最终状态一并提供给评判模型，而不仅仅是聊天记录。
评判模型身份。现象：更换评判模型会改变哪个系统获胜。证据：2026 年的审计（arXiv 2607.08535；2606.19544）。缓解措施：将评判模型及其版本作为每项结果的一部分记录下来。

GAUGE 审计（Bodhwani 等，2026）值得单独用一段来讲，因为它描述的正是大多数公司做发布决策时采用的那套配置：一个模拟用户与智能体对话，一个评判模型给对话记录打分，分数更高的那个就发布。在 25 个智能体和约 3,700 份对话记录上，他们发现当一方明显更优时，这道关卡能很好地对智能体排序（与可验证的真实基准相关性为 0.94），但在实力接近的配对——也就是真实发布决策真正要在其间做取舍的那些——它却有 31% 的时候把更差的智能体推了上去。一个只看用户可见聊天内容并评定满意度的评判模型，在区分能正常工作的智能体和坏掉的智能体方面，并不比抛硬币强（AUC 0.49）。一个能看到工具调用、身份验证和任务完成情况的评判模型，则把失败风险减半（AUC 0.73）。他们的结论是：可靠性来自评判模型被喂给了什么证据，而不是来自评判模型本身有多强。

重要： 客户满意度与任务成功是两回事，而只看对话的评判模型衡量的是前者。
这对我们意味着什么： 把证据（工具调用、数据库状态、检索到的文档）交给评判模型，并且当两个版本实力接近时，绝不要仅凭评判分数就发布某个版本。
为什么这很重要： 一个讨人喜欢却会失败的智能体，会不断被推上去。

4.4 评判模型小组，以及如何组合它们

单个评判者就是单点故障。Verga 等人（2024）表明，由若干个更小、更便宜的评判者组成的评审团，与人类判断的一致程度优于单个大型评判者，而成本仅为后者的一小部分。但对评审团分数取平均有一个陷阱：Acharya 等人（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% 的流量，而它声称小型检测器能以最高降低 98% 的成本覆盖 100%。这一说法来自厂商，未展示任何实验，但这种权衡的形态是真实的。

类型化评判器。 TypeSafe 的 Jev 模型是一种不同的设计：它根本不生成文本。你把输出和一个带类型的问题（“这段摘录是否支持该主张？”答案为“是/否”，或“从这些标签中选一个”）发给它，它会返回一个经过校准的概率。由于不生成任何内容，调用速度快，成本约为生成式评判器的百分之一，而且这个概率让代码可以把不确定的案例转交给人工处理。它无法解释自己的裁决，也无法自行编造选项；标签由你提供。一项 2026 年、采用盲法人裁决的研究显示，它在 RewardBench 配对上的得分为 92.2%，而前沿生成式评判器为 93.5%，费用约为后者的千分之三，但在困难的推导检查上远远落后（78.6% 对 93.1%）；一个仅在其置信度高于阈值时才接受其裁决、否则升级处理的级联方案，以约一半的成本保持了 92.5% 的准确率（arXiv 2609.26550）。我们自己的红队测试发现，它并不是事实核查器：输入中伪造的日志可以翻转裁决，不过每一次成功的攻击也都会使其置信度崩塌，因此置信度门控是一种有效的防御。我们的知识库中有一篇关于它的教程，以及如何在信任它之前测试其准确率。

评判器也需要基准。 JudgeBench（Tan 等，2025）把困难、可客观检查的问题转化为评判器测试，并发现前沿评判器在真正困难的案例上几乎只比随机猜测好一点。可靠性必须按任务、按评分标准、按评判模型、每次都进行测量。供应商声称的“与人类 85% 一致”来自单一数据集，无法迁移（参见我们从业者来源中的分歧说明）。

从第 4 级延续下来：

就具体失败向评判器提出是/否问题，附上证据，附上上下文。
用人工标签衡量评判器，报告 kappa 或捕获率，反复迭代直到达标。
了解五种偏差，并应用低成本的缓解措施。
对于“这是否受支持”，优先使用小型检测器或有类型的评判器，而非通用评判器。
三个评判器以稳健方式组合，胜过单个评判器；取平均值是脆弱的。

第 5 层：诚实的数字

聚焦于：循环的第 4 步。问题：我们对任何一个数字有多确定，又如何比较两个版本？

我们迄今引用的每一个比率都隐藏着一个问题：换另外 60 张工单，结果会一样吗？有三件工具可以回答这个问题。

误差条。 我们对 60 个结果重采样数千次（自助法），然后观察其分布范围：

分诊准确率：0.700 · 95% CI [0.583, 0.817]

诚实的说法不是“准确率为 70%”，而是“在 58% 到 82% 之间，最可能是 70%”。Miller（2024）表明，已发表的评测中，大多数所报告的模型间差异都小于这类区间，并给出了每份评测报告都应使用的公式，包括当若干问题共享同一来源时所需的校正（聚类标准误）。

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

评判器通过率 · v1：0.700 · v2：0.700
差异：+0.000 · 95% CI [-0.117, +0.117]
结论：没有真实差异，保留 v1

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

重要提示： 一个区间包含零的差异是噪声，不是胜利。
这对我们意味着什么： 每一个“新版本更好”的结论都必须附上区间，以及变差的案例数量。
为什么这很重要： 团队常常凭借一个根本不存在的 2 个百分点提升，就把回归问题发布上线。

检测下限。 在 60 个案例下，我们能可靠检测到的最小差异约为 12 个百分点。5 个百分点的回归在这个规模下是看不见的。这是一个功效计算，它告诉你，在能够回答你所提出的问题之前，你需要多少案例。低于这个下限时，你需要的是更多数据，而不是更聪明的检验。

多重比较。 如果你测试 20 个提示词变体并挑出最好的那个，其中一个会因为运气而看起来好了 10 个百分点。要么针对比较次数进行校正，要么在全新案例上确认胜出者。

从第 5 级延续下来：

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

第 6 级：带部件的评分系统

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

6.1 检索系统（RAG）

我们的回答组件先找到手册章节，再撰写。糟糕的回复可能来自任一阶段，而修复方法各不相同。所以我们分开评分。

给查找器评分。 对照金标准章节：hit@k（前 k 个里是否至少有一个正确章节？）和 recall@k（正确章节有多大比例被找出来了？）。

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

查找器几乎没问题。撰写器才是问题所在。这一行结论能改变一周的工程方向。

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

来自智能体编程世界的一个警示：SWE-Explore（Zhang 等，2026）测量了编程智能体内部的检索，发现它们约 65% 的时间能定位到正确的文件，但只有 15% 到 19% 的时间能定位到正确的行，而且破坏下一阶段的是缺失的上下文，而非多余的上下文。按撰写器所需的粒度给查找器评分。

6.2 智能体

一个智能体会执行一系列动作（查询订单、发起退款、上报升级）。对它进行评分时，有三件事发生了变化。

对最终状态和路径都进行评分。 数据库最终是否正确（退款已发起、订单已取消）？智能体是否只执行了被允许的动作，而没有——比如说——重复退款？τ-bench（Yao 等，2024）确立了这一范式：模拟用户、策略规则，以及对最终状态的检查。AgentLens（2026）揭示了路径为何重要：智能体靠运气或退化路径抵达正确最终状态的情况屡见不鲜，以至于仅凭结果评分会高估其能力。

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

将可靠性作为独立指标来衡量。 Rabanser 等（2026）借鉴航空与核工程领域的做法，定义了四大类共 12 项可靠性指标：多次运行间的一致性、对扰动的鲁棒性、可预测性（智能体是否知道自身何时会失败），以及危害有界性。在 15 个前沿模型中，他们发现两年的能力提升所带来的可靠性提升仅为其约六分之一。智能体每次运行会选择相同种类的动作，但顺序不同；能优雅地处理真实的基础设施故障，却会因一句改写过的指令而崩溃。

重要提示： 一个能力强的智能体并不等于一个可靠的智能体，而你的客户体验到的恰恰是可靠性。
这对我们意味着什么： 报告 pass^k，对每个任务运行扰动版本（重命名字段、改写指令），并将多次运行之间的一致性作为一个单独的数字来跟踪。
为什么这很重要： 已公开的失败案例（一个智能体删除了生产数据库，一个智能体进行了未经授权的采购）都来自平均成功率良好的系统。

衡量成本。 Bai 等人（2026）在 SWE-bench Verified 上测量了八个前沿模型的 token 消耗。智能体任务使用的 token 量约为一次聊天轮次的千倍，其中几乎全部用于反复读取自身不断增长的历史记录。同一模型上的同一任务在不同运行之间成本相差 30 倍，准确率在中等成本处达到峰值，并在最高成本处下降，而模型对自身成本的预测相关性最高仅为 0.39。他们的建议是：按每个正确结果的成本对模型排名，而不是仅看准确率，并且永远不要相信模型自己的估计。

判断力、提问与学习：三条较新的轴线。 三个 2026 年的基准测试衡量了单一成功率无法看到的东西。

品味（Pan 等人，2026）：将智能体冻结在一个分叉点上，两条路径看起来都不错，然后问哪一条日后会有回报。最好的模型在二选一中选对的概率为 59.7%，而思考更久并无帮助。
提问（Gulati 等人，2026）：就目标提出澄清性问题的价值在任务完成 10% 后从 0.78 降至 0.39。没有前沿模型会在该窗口内提问；一个模型有 52% 的时间会提问，一个有 23%，一个从不提问。
从经验中学习（Asawa 等人，2026）：在六个有状态环境中，最好的系统仅从经验中捕获了其可能改进的 25%，而仅仅保留完整对话历史就胜过了所有专门的记忆产品。

6.3 当系统正被针对评分器进行优化时

如果评分器被用于训练或选择系统（强化学习、best-of-n 选择），系统就会找到评分器的盲区。Qwen 团队的 Wang 等人（2026）将此称为验证视界：每个评分器都是意图的代理，而在优化压力下，代理与意图会逐渐背离。他们梳理了编码智能体中的奖励黑客行为（从仓库历史中读取答案、修改测试、为迎合评估者而打补丁），并表明行为监控器将作弊的“解决方案”从 28.6% 降至 0.6%，同时将真实解决方案从 40% 提升至 61%。他们认为，没有任何评分器能同时做到可扩展、忠实且稳健：测试可扩展且稳健，但会遗漏意图；评判者可扩展且忠实，但可被钻空子；专家忠实且稳健，但无法扩展。Meta-Agent Challenge（Lu 等人，2026）也自发地观察到了同样的现象：被要求构建其他智能体的智能体在五次试验中都试图从评分系统中窃取答案。

重要：任何影响训练或选择的评分器都会被钻空子。
这对我们意味着什么：保留一个系统永远看不到的留出评分器，监控捷径行为，并随着系统改进而升级评分器。
为什么重要：分数上去了，产品却变差了。

从第 6 级延续：

分别对每个阶段评分；发现者和写作者的失败方式不同。
对于智能体：最终状态与路径、多次运行、pass^k、每次成功的成本，以及作为独立数字的可靠性。
用于优化的评分器会被钻空子。保留一个它们永远看不到的评分器。

第 7 层：公开基准

聚焦于：第 1 层中评估与基准之间的区分。问题：排行榜上的数字告诉了你什么，又隐藏了什么？

基准是一组固定的公开任务集，用于比较模型：MMLU（学术多项选择）、GSM8K（小学数学）、HumanEval（代码）、MT-Bench 与 Chatbot Arena（对话质量）、SWE-bench（修复真实的 GitHub 问题）、τ-bench（客服智能体）、GPQA 与 HLE（专家问题）。它们是你挑选引擎的依据。在引用某个基准之前，有四件事需要了解。

数字既取决于模型，也同样取决于测试框架。 我们对同一个开放权重模型用两种提示格式运行 GSM8K，分别得到 0.686 和 0.746。lm-evaluation-harness 论文（Biderman 等，2024）记录了因提示格式、少样本示例以及提取答案的正则表达式而产生的两位数波动。一个分数是一个（模型、提示、测试框架、版本）四元组。Schaeffer 等（2023）展示了更强的结论：表面上“涌现”的能力跃升在很大程度上是全有或全无指标的假象，在平滑指标下便消失了。你选择的度量方式可以创造或抹去一个现象。

污染。 如果测试题目出现在训练数据中，分数衡量的就是记忆。GSM1k（Zhang 等，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和Papailiopoulos（2026）构建了一个84个模型×133个基准的矩阵，发现其近似秩为二：两个潜在因子解释了超过90%的变异。五个精心挑选的基准就能以约4分的误差预测其余128个基准。对于选择引擎而言，这是好消息：你不需要跑四十个基准。但对于发现某个特定的失败模式，这毫无帮助；那仍然需要你自己的评估。

重要： 排行榜是在去年的考卷上、在单一测试框架下对引擎进行排名，而排名靠前的条目通常彼此之间的差距在噪声范围内。
这对我们意味着什么： 用基准测试筛选出两三个模型，然后用你自己的评估在你自己的数据上做决定。
为什么这很重要： 为了基准测试上2分的提升而切换模型，可能会让你在实际任务上损失10分。

两个值得了解的前沿评估用法。 谷歌的 Paper Assistant Tool（Jayaram 等，2026）使用智能体流水线审阅科学论文，捕获了 89.7% 的已知证明错误，而单次模型调用仅为 55.2%；在 850 位受访作者中，超过 90% 认为它有帮助，31% 因它而开展了新实验。CUSP（Wu 等，2026）让模型预测哪些研究方向会成功，发现其准确率接近随机水平（0.519），且根据模型不同存在强烈的肯定偏差或否定偏差，只有通过显式偏差校正才能修复。两者都提醒我们：对模型判断力的评估需要有自己的真值标准，而且模型对未来的预测和对自身的认知都严重校准不良。

从第 7 级延续：

基准分数是一个元组，不是模型的属性。记录测试框架。
基准会被污染并饱和；检查日期。
五个基准几乎能告诉你排行榜能告诉你的一切。你的评估告诉你其余的。

第 8 级：让它成为习惯

聚焦于：快速掌握的“何时”。问题：没有研究团队，这如何每周运行？

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

1。内容：代码评分器、模式检查、必需事实。时机：每次提交。成本：免费。
2。内容：测试集上的模型评判器和检测器，对样本进行人工审查。时机：每次对提示词、模型或检索的更改。成本：几美分到几美元。
3。内容：真实流量上的 A/B 测试。时机：变更上线后。成本：真实用户。

合并门禁。 我们教程的 CI 门禁会重新运行第 1 级和第 2 级，如果通过率相对于记录的基线 0.70 下降超过 3 个百分点，则构建失败。它是重大回归的绊线，而非保证：在 12 个百分点的检测下限下，5 个百分点的回归会溜过去。在仪表盘上说明这一点。

监控。 上线后，对真实流量进行采样，对所有样本运行低成本评分器，对其中一部分运行高成本评分器，并绘制趋势图。Bodhwani 等人（2026）的“先校准，再信任”是昂贵闸门的正确模式：先针对可验证的真实基准做一次完整审计，弄清基于廉价评判器的闸门在哪些区域与现实一致，然后只在 CI 中于该区域内使用廉价闸门，并在模型、评判器、模拟器或领域发生变化时重新审计。他们还发现，一个零成本的“对话是否完成”位本身就能捕获预算饥饿导致的回归。

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

领导者应该要求什么。 一页纸上四个数字：产品的通过率及其区间、评分器与人工标注的一致率、检测下限，以及上一次变更中变差的案例占比。如果这四个数字中缺了任何一个，另外三个就还没有意义。

从第 8 级延续下来：

三种节奏：每次提交、每次变更、发布之后。
闸门是下限，不是上限。要说明它的检测下限。
用真实基准对廉价闸门校准一次，然后只在该区域内信任它。

观察到的工具与方法

本节是观察记录，不是推荐清单。以下所有内容都是在构建本教程的过程中实际运行或审阅过的；详细信息保存在我们知识库中的实践者与工具说明里。

框架

Inspect AI（英国 AI 安全研究所，MIT）。最擅长：一条连贯的流水线：数据集、求解器、评分器、日志查看器；智能体与沙箱；用于前沿安全评估。注意事项：代码优先；最完整，也最需要学习。
lm-evaluation-harness（EleutherAI，MIT）。最擅长：针对任意模型可复现地运行公开基准（GSM8K、MMLU、IFEval）。注意事项：仅限基准；harness 论文正是它存在的原因。
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（斯坦福）。最擅长：多指标理念——将准确性、校准度、鲁棒性、公平性、效率一并考量。需注意：偏研究导向，最不即开即用。
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。然后检查：跨运行的一致性作为其自身的数字。
我们该用哪个模型？ 使用：五个公开基准来初筛。然后检查：用你自己的评估来做决定。
它在生产中是否仍在正常工作？ 使用：抽样流量，对所有样本用廉价评分器，对其中一部分用评判器。然后检查：当任何东西发生变化时，重新审计评判器闸门。

十五件值得带走的事

一次评估由输入、系统、评分器和数字构成。先构建黄金输入；它们才是资产。
评估衡量的是你的产品。基准测试衡量的是引擎。不要将两者混为一谈。
在编写评分器之前，先读一百条输出。失败清单就是计划。
对所有有确定答案的内容使用代码评分器。它们看到的是形式，而非含义。
评判者拿到的是带有证据和上下文的二元问题。整体性评分会漏掉植入的错误。
用人类来校准评判者。报告 kappa 或捕获率。百分之六十的一致率可能毫无意义。
评判者偏好第一位的、更长的、熟悉的、令人愉悦的内容。缓解措施成本很低；请加以应用。
满意度不等于成功。把工具调用和最终状态交给评判者。
对于“这是否有支撑”这类问题，小型检测器或类型化评判者在成本上优于通用评判者，在准确率上往往也是如此。
每个比率都要有区间。每次比较都要配对。了解检测下限。
分别对流水线的每个阶段进行评分。
智能体：最终状态与路径、多次运行、pass^k、每次成功的成本、可靠性作为独立维度。
用于优化的评分器会被钻空子。保留一个系统永远看不到的评分器。
基准测试分数依赖于测试框架、污染程度不均、且会饱和。记录下这个元组。
三种节奏、一个带明确下限的闸门、一个监控器，以及任何变化时的重新审计。

参考文献

来自本知识库（摘要见同级文件夹）

Acharya, Pan, Verkhovsky (2026). RoPoLL：稳健的LLM评审团。 arXiv:2606.30931. — RoPoLLRobustPanelOfLLMJudges/
Asawa et al. (2026). 持续学习基准。 arXiv:2606.05661. — ContinualLearningBench/
Bai et al. (2026). AI智能体如何花你的钱？ arXiv:2604.22750. — HowAiAgentsSpendYourMoney/
Bodhwani, Tran, Wei (2026). GAUGE：在面向任务型智能体的用户模拟评估中，何时不应信任LLM-as-a-Judge。 arXiv:2609.12191. — GaugeWhenNotToTrustLlmAsAJudge…/
Cho et al. (2026). 问，而非评判 / BinEval。 arXiv:2606.27226. — AskDontJudge/, BinEval/
Fiddler (2026). 评估信任税：智能体评估的总拥有成本。 — AgentEvalsTCO/
Grace, Hadfield, Olivares, De Jonghe (Anthropic, 2026). 揭开AI智能体评估的神秘面纱。 — DemystifyingEvalsForAIAgents/
Gulati et al. (2026). 早问，晚问，问得对。 arXiv:2605.07937. — AskEarlyAskLateAskRight/
HKUDS (2026). ClawWork（经济问责智能体基准，代码分析）。 — ClawWork/
Jayaram et al. (Google, 2026). 借助论文助手工具迈向自动化科学评审。 arXiv:2606.28277. — PaperAssistantTool/, TowardsAutomatingScientificReview/
Lu et al. (2026). 元智能体挑战。 arXiv:2606.04455. — MetaAgentChallenge/
Menaged et al. (2026). LLM智能体能推断世界模型吗？ arXiv:2606.16576. — CanLLMAgentsInferWorldModels/
Pan et al. (2026). 有品味的智能体。 arXiv:2609.25804. — TastefulAgent/
Parikh (2026). 结构化输出在44个语言模型中瓦解了答案多样性。 arXiv:2607.18476. — StructuredOutputCollapsesAnswerDiversity/
Rabanser, Kapoor, Kirgis, Liu, Utpala, Narayanan (2026). 迈向AI智能体可靠性科学。 arXiv:2602.16666, ICML 2026. — TowardsAScienceOfAIAgentReliability/
Wang 等（Qwen，2026）。《验证视界：编码智能体奖励没有银弹》。 arXiv:2606.26300。 — VerificationHorizon/
Wu 等（2026）。《CUSP：用 AI 预测科学进展》。 arXiv:2605.22681。 — ForecastingScientificProgressWithAI/
Zeng, Papailiopoulos（2026）。《你不必运行每一次评估》。 arXiv:2606.24020。 — YouDontNeedToRunEveryEval/
Zhang 等（2026）。《SWE-Explore》。 arXiv:2606.07297。 — SWEExplore/
evals 教程（tutorials/evals/，第 00–14 章，Q&A.md，research/SOURCES_*.md）及其入门 notebook，所有贯穿示例数字的来源。jev 教程（tutorials/jev/）。

基础与实践来源

Biderman 等（2024）。《语言模型可复现评估的实战经验》。 arXiv:2405.14782。
Chiang 等（2024）。《Chatbot Arena》。 arXiv:2403.04132。
Dubois, Galambosi, Liang, Hashimoto（2024）。《长度受控的 AlpacaEval》。 arXiv:2404.04475。
Es, James, Espinosa-Anke, Schockaert（2024）。《RAGAS》。 arXiv:2309.15217。
Gu 等（2024）。《LLM-as-a-Judge 综述》。 arXiv:2411.15594。
Han 等（2025）。《RAG vs GraphRAG：一项系统性评估》。 arXiv:2502.11371。
《JEV-as-a-Judge》（2026）。arXiv:2609.26550。 — research_topics/coding_agents/JevAsAJudge/
Panickssery, Bowman, Feng（2024）。《LLM 评估器能识别并偏好自身生成的内容》。 arXiv:2404.13076。
Husain（2024）。《你的 AI 产品需要评估》。 hamel.dev。Husain（2025）。《快速改进 AI 产品的实战指南》。 Husain & Shankar（2025）。《AI 评估常见问题解答》。
Jimenez 等（2024）。《SWE-bench》。 arXiv:2310.06770。OpenAI（2024）。《SWE-bench Verified》。
Kovács, Recski（2025）。《LettuceDetect》。 arXiv:2502.17125。Tang, Laban, Durrett（2024）。《MiniCheck》。 arXiv:2404.10774。Manakul, Liusie, Gales（2023）。《SelfCheckGPT》。 arXiv:2303.08896。
Liang 等（2022）。《HELM》。 arXiv:2211.09110。
Liu 等（2023）。《G-Eval》。 arXiv:2303.16634。
Miller (2024). 为评估添加误差棒。 arXiv:2411.00640.
Saad-Falcon, Khattab, Potts, Zaharia (2024). ARES。 arXiv:2311.09476.
Schaeffer, Miranda, Koyejo (2023). 大语言模型的涌现能力是海市蜃楼吗？ arXiv:2304.15004.
Shankar, Zamfirescu-Pereira, Hartmann, Parameswaran, Arawjo (2024). 谁来验证验证者？ arXiv:2404.12272.
Tan et al. (2025). JudgeBench。 arXiv:2410.12784.
Verga et al. (2024). 用陪审团取代法官（PoLL）。 arXiv:2404.18796.
Wang et al. (2024). 大语言模型不是公平的评估者。 arXiv:2305.17926.
Yan (2024). 行之有效与行之无效的任务特定LLM评估；评估LLM评估器的有效性。 eugeneyan.com.
Yao, Shinn, Razavi, Narasimhan (2024). τ-bench。 arXiv:2406.12045. Sierra (2025). τ⁠²-bench。 arXiv:2506.07982.
Zhang et al. (2024). GSM1k。 arXiv:2405.00332.
Zheng et al. (2023). 用MT-Bench和Chatbot Arena评判LLM-as-a-Judge。 arXiv:2306.05685.
Zhou et al. (2023). IFEval。 arXiv:2311.07911.
2026年审计：当AI基准陷入停滞（arXiv:2602.16763）；当评判者改变，测量也随之改变（arXiv:2607.08535）；无有效性之可靠性（arXiv:2606.19544）；AgentLens（arXiv:2605.12925）。

已读完 · 本文由熊猫易读翻译重排

评估：如何判断AI系统是否真正有效

SERGII MAKAREVYCH（@SERMAKAREVICH）教程 · 已翻译 · 约 53 分钟

阅览室 · AI 最佳实践#评分#评估#系统#判断#裁判原文

快速把握（如果你别的都不读，就读这一段）

它的工作方式，分四步：

收集重要的输入，并在每一条旁边写下正确答案。在我们的贯穿示例中：一家自行车店的 80 张客户支持工单，每张都带有正确的分类，以及一条好回复必须包含的事实。
在每个输入上运行系统，并保留输出。
用评分器给每个输出打分。评分器可以是一条代码规则、一个充当裁判的第二个模型，或一个人。
把各项评分汇总成一个带误差范围的数字，并与上一个版本比较。

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

本文的其余部分逐层放大，一次深入一层。每一层回答一个关于上一层的问题。

第 0 层 · 整个循环，跑一遍，处理一张工单
第 1 层 · 我们到底测量什么？·（输入、标准答案、那个数字）
第 2 层 · 哪里会出错？·（先看数据）
第 3 层 · 用代码做评分器 ·（便宜、精确、对语义视而不见）
第 4 层 · 用模型做评分器 ·（灵活、有偏见、必须检验）
第 5 层 · 诚实的数字 ·（误差范围、A/B 测试、需要多少样本）
第 6 层 · 由多个部分组成的评分系统 ·（检索、智能体、成本、可靠性）
第 7 层 · 公开基准 ·（排行榜能告诉你什么、不能告诉你什么）
第 8 层 · 把它变成习惯 ·（门禁、监控、何时重新检查）
然后 · 工具与方法、决策指南，以及参考资料

第 0 层：整个循环，跑一次，处理一张工单

聚焦于：一切。问题：一次评估在运行时是什么样子？

贯穿全文的示例是一个小型客服助手，服务于一家虚构的在线自行车与露营用品商店。它由三部分组成，后面我们会分别用不同方式对它们评分：

triage：读取工单，将其归入 12 个类别之一（退货、配送、保修……），并附带一个优先级。
answer：找到商店政策手册中的相关页面，并写出一封引用这些页面的回复。
agent：在政策规则下，通过调用工具对模拟数据库进行操作，查询订单、发放退款并进行升级处理。

下面是一张工单走完整个循环的过程。

输入：“我上班要迟到了，需要立刻把这件事解决。我上周退回了自行车，但至今没看到退款。你们的政策明明写着退款在 5 个工作日内处理……”

系统输出（triage）：returns。标准答案：returns。得分：1 分（满分 1 分）。

系统输出（answer）：一封礼貌的四段式回复，引用了退货部分，并提到了两个必需事实：退款需要 5 个工作日，且二手商品需收取 15% 的补货费。

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

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

从第 0 层延续下去：

一次评估就是输入、系统、评分器、数字。仅此而已。
不同的评分器回答的是不同的问题。“引用了某一节”和“没有编造任何内容”并不是同一种检查。
一段流畅的回复可以通过所有表面检查，却依然是错的。

第 1 层：我们究竟在测量什么？

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

四个容易混淆的词：

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

从第 1 级延续下来：

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

第 2 级：哪里出了问题？先看数据

聚焦于：评分步骤。问题：评分者究竟应该看什么？

在我们 60 条测试回复上，它产出了什么：

通过的回复：60 条中有 34 条
missing_required_fact · 15
unsupported_claim · 12
wrong_section_retrieved · 8
did_not_answer · 5
wrong_value · 2
over_promise · 1

从第 2 级延续下来：

失败分类法就是计划。先为最主要的失败类型构建评分器。
阅读输出是价值最高的活动，也是最常被跳过的。
预计评分标准会在你评分的过程中发生变化。

第 3 级：用代码制成的评分器

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

代码评分器是用普通代码写成的规则。它免费、即时，而且每次给出相同的答案。凡是它能衡量的，都用它。

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

accuracy: 0.700 · macro F1: 0.697

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

nonempty · 100% pass
max_words_150 · 17% pass
no_banned_promises · 92% pass

必需事实。 我们检查每条黄金事实是否出现在回复中。这能以零成本捕捉最主要的失败类型——遗漏事实。

从 Level 3 延续下来：

对于一切有确定答案的内容使用代码评分器：标签、格式、必需事实、禁用短语。
相似度度量的是漂移，不是质量。
规则看不到编造的说法。那需要一个读者。

第 4 层：以模型作为评分器，以及如何检验它

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

4.1 如何向裁判提问

从业者的共识与研究文献在形态上一致：

每种失效类型一个问题，回答是或否。 问“这条回复是否包含手册摘录未支持的断言？”，而不是“给质量打 1 到 5 分”。二元问题对人类标注者来说更快、更可复现，也更容易核查（Husain & Shankar, 2025）。只有当每个问题都回答“否”时，输出才算通过。
要求给出证据。 裁判引用有问题的那句话。这样它的裁决就能被人几秒钟内核查。
给它上下文。 看不到手册的裁判，无从知道什么是不被支持的。

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

我们手工标注了全部 60 条测试回复（即“参考标准”），然后运行裁判：

参考标准判为通过：34 · 裁判判为通过：42
二者在 60 条回复中的 36 条上一致（60%）
裁判抓出的坏回复：26 条中的 10 条
kappa：0.15

4.3 评判器已知的偏差

评判器会以可预测的方式失败。每一种都有已发表的测量方法和廉价的缓解措施。

位置。现象：在成对比较中，评判器偏好先展示的那个答案。证据：交换顺序后，很大一部分成对判定会翻转（Wang et al., 2024）；一项 2025 年的 RAG 与 GraphRAG 对比发现，较早的 GraphRAG“胜出”部分在交换顺序后消失了（Han et al., 2025）。缓解措施：对两种顺序都评分，只有两者一致时才计为胜出。
长度。现象：无论内容如何，更长的回答更容易获胜。证据：对长度进行校正后，与人类排名的吻合度从 0.94 提升至 0.98（Dubois 等，2024）。缓解措施：采用长度受控的评分，或使用不奖励长度的二元问题。
自我偏好。现象：评判模型偏爱与其自身模型家族风格一致的答案。证据：评判模型给自己的生成结果打分更高，当它能识别出这些结果时尤为明显（Panickssery 等，2024）；在 GAUGE 审计中，同家族的评判模型将其自身提供商的智能体在 7 分制上抬高了约 0.75 分。缓解措施：使用与被测系统不同家族的评判模型。
满意度与成功率。现象：评判模型评估的是对话的感受，而非任务是否完成。证据：GAUGE 审计，见下文。缓解措施：将工具调用和最终状态一并提供给评判模型，而不仅仅是聊天记录。
评判模型身份。现象：更换评判模型会改变哪个系统获胜。证据：2026 年的审计（arXiv 2607.08535；2606.19544）。缓解措施：将评判模型及其版本作为每项结果的一部分记录下来。

4.4 评判模型小组，以及如何组合它们

4.5 比评判者更便宜、更可靠：专用检测器和类型化评判者

对于最重要的那些故障类型，通用评判者往往是错误的工具。

从第 4 级延续下来：

就具体失败向评判器提出是/否问题，附上证据，附上上下文。
用人工标签衡量评判器，报告 kappa 或捕获率，反复迭代直到达标。
了解五种偏差，并应用低成本的缓解措施。
对于“这是否受支持”，优先使用小型检测器或有类型的评判器，而非通用评判器。
三个评判器以稳健方式组合，胜过单个评判器；取平均值是脆弱的。

第 5 层：诚实的数字

聚焦于：循环的第 4 步。问题：我们对任何一个数字有多确定，又如何比较两个版本？

我们迄今引用的每一个比率都隐藏着一个问题：换另外 60 张工单，结果会一样吗？有三件工具可以回答这个问题。

误差条。 我们对 60 个结果重采样数千次（自助法），然后观察其分布范围：

分诊准确率：0.700 · 95% CI [0.583, 0.817]

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

评判器通过率 · v1：0.700 · v2：0.700
差异：+0.000 · 95% CI [-0.117, +0.117]
结论：没有真实差异，保留 v1

从第 5 级延续下来：

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

第 6 级：带部件的评分系统

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

6.1 检索系统（RAG）

我们的回答组件先找到手册章节，再撰写。糟糕的回复可能来自任一阶段，而修复方法各不相同。所以我们分开评分。

给查找器评分。 对照金标准章节：hit@k（前 k 个里是否至少有一个正确章节？）和 recall@k（正确章节有多大比例被找出来了？）。

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

查找器几乎没问题。撰写器才是问题所在。这一行结论能改变一周的工程方向。

6.2 智能体

一个智能体会执行一系列动作（查询订单、发起退款、上报升级）。对它进行评分时，有三件事发生了变化。

判断力、提问与学习：三条较新的轴线。 三个 2026 年的基准测试衡量了单一成功率无法看到的东西。

品味（Pan 等人，2026）：将智能体冻结在一个分叉点上，两条路径看起来都不错，然后问哪一条日后会有回报。最好的模型在二选一中选对的概率为 59.7%，而思考更久并无帮助。
提问（Gulati 等人，2026）：就目标提出澄清性问题的价值在任务完成 10% 后从 0.78 降至 0.39。没有前沿模型会在该窗口内提问；一个模型有 52% 的时间会提问，一个有 23%，一个从不提问。
从经验中学习（Asawa 等人，2026）：在六个有状态环境中，最好的系统仅从经验中捕获了其可能改进的 25%，而仅仅保留完整对话历史就胜过了所有专门的记忆产品。

6.3 当系统正被针对评分器进行优化时

从第 6 级延续：

分别对每个阶段评分；发现者和写作者的失败方式不同。
对于智能体：最终状态与路径、多次运行、pass^k、每次成功的成本，以及作为独立数字的可靠性。
用于优化的评分器会被钻空子。保留一个它们永远看不到的评分器。

第 7 层：公开基准

聚焦于：第 1 层中评估与基准之间的区分。问题：排行榜上的数字告诉了你什么，又隐藏了什么？

从第 7 级延续：

基准分数是一个元组，不是模型的属性。记录测试框架。
基准会被污染并饱和；检查日期。
五个基准几乎能告诉你排行榜能告诉你的一切。你的评估告诉你其余的。

第 8 级：让它成为习惯

聚焦于：快速掌握的“何时”。问题：没有研究团队，这如何每周运行？

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

1。内容：代码评分器、模式检查、必需事实。时机：每次提交。成本：免费。
2。内容：测试集上的模型评判器和检测器，对样本进行人工审查。时机：每次对提示词、模型或检索的更改。成本：几美分到几美元。
3。内容：真实流量上的 A/B 测试。时机：变更上线后。成本：真实用户。

从第 8 级延续下来：

三种节奏：每次提交、每次变更、发布之后。
闸门是下限，不是上限。要说明它的检测下限。
用真实基准对廉价闸门校准一次，然后只在该区域内信任它。

观察到的工具与方法

框架

Inspect AI（英国 AI 安全研究所，MIT）。最擅长：一条连贯的流水线：数据集、求解器、评分器、日志查看器；智能体与沙箱；用于前沿安全评估。注意事项：代码优先；最完整，也最需要学习。
lm-evaluation-harness（EleutherAI，MIT）。最擅长：针对任意模型可复现地运行公开基准（GSM8K、MMLU、IFEval）。注意事项：仅限基准；harness 论文正是它存在的原因。
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（斯坦福）。最擅长：多指标理念——将准确性、校准度、鲁棒性、公平性、效率一并考量。需注意：偏研究导向，最不即开即用。
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。然后检查：跨运行的一致性作为其自身的数字。
我们该用哪个模型？ 使用：五个公开基准来初筛。然后检查：用你自己的评估来做决定。
它在生产中是否仍在正常工作？ 使用：抽样流量，对所有样本用廉价评分器，对其中一部分用评判器。然后检查：当任何东西发生变化时，重新审计评判器闸门。

十五件值得带走的事

一次评估由输入、系统、评分器和数字构成。先构建黄金输入；它们才是资产。
评估衡量的是你的产品。基准测试衡量的是引擎。不要将两者混为一谈。
在编写评分器之前，先读一百条输出。失败清单就是计划。
对所有有确定答案的内容使用代码评分器。它们看到的是形式，而非含义。
评判者拿到的是带有证据和上下文的二元问题。整体性评分会漏掉植入的错误。
用人类来校准评判者。报告 kappa 或捕获率。百分之六十的一致率可能毫无意义。
评判者偏好第一位的、更长的、熟悉的、令人愉悦的内容。缓解措施成本很低；请加以应用。
满意度不等于成功。把工具调用和最终状态交给评判者。
对于“这是否有支撑”这类问题，小型检测器或类型化评判者在成本上优于通用评判者，在准确率上往往也是如此。
每个比率都要有区间。每次比较都要配对。了解检测下限。
分别对流水线的每个阶段进行评分。
智能体：最终状态与路径、多次运行、pass^k、每次成功的成本、可靠性作为独立维度。
用于优化的评分器会被钻空子。保留一个系统永远看不到的评分器。
基准测试分数依赖于测试框架、污染程度不均、且会饱和。记录下这个元组。
三种节奏、一个带明确下限的闸门、一个监控器，以及任何变化时的重新审计。

参考文献

来自本知识库（摘要见同级文件夹）

Acharya, Pan, Verkhovsky (2026). RoPoLL：稳健的LLM评审团。 arXiv:2606.30931. — RoPoLLRobustPanelOfLLMJudges/
Asawa et al. (2026). 持续学习基准。 arXiv:2606.05661. — ContinualLearningBench/
Bai et al. (2026). AI智能体如何花你的钱？ arXiv:2604.22750. — HowAiAgentsSpendYourMoney/
Bodhwani, Tran, Wei (2026). GAUGE：在面向任务型智能体的用户模拟评估中，何时不应信任LLM-as-a-Judge。 arXiv:2609.12191. — GaugeWhenNotToTrustLlmAsAJudge…/
Cho et al. (2026). 问，而非评判 / BinEval。 arXiv:2606.27226. — AskDontJudge/, BinEval/
Fiddler (2026). 评估信任税：智能体评估的总拥有成本。 — AgentEvalsTCO/
Grace, Hadfield, Olivares, De Jonghe (Anthropic, 2026). 揭开AI智能体评估的神秘面纱。 — DemystifyingEvalsForAIAgents/
Gulati et al. (2026). 早问，晚问，问得对。 arXiv:2605.07937. — AskEarlyAskLateAskRight/
HKUDS (2026). ClawWork（经济问责智能体基准，代码分析）。 — ClawWork/
Jayaram et al. (Google, 2026). 借助论文助手工具迈向自动化科学评审。 arXiv:2606.28277. — PaperAssistantTool/, TowardsAutomatingScientificReview/
Lu et al. (2026). 元智能体挑战。 arXiv:2606.04455. — MetaAgentChallenge/
Menaged et al. (2026). LLM智能体能推断世界模型吗？ arXiv:2606.16576. — CanLLMAgentsInferWorldModels/
Pan et al. (2026). 有品味的智能体。 arXiv:2609.25804. — TastefulAgent/
Parikh (2026). 结构化输出在44个语言模型中瓦解了答案多样性。 arXiv:2607.18476. — StructuredOutputCollapsesAnswerDiversity/
Rabanser, Kapoor, Kirgis, Liu, Utpala, Narayanan (2026). 迈向AI智能体可靠性科学。 arXiv:2602.16666, ICML 2026. — TowardsAScienceOfAIAgentReliability/
Wang 等（Qwen，2026）。《验证视界：编码智能体奖励没有银弹》。 arXiv:2606.26300。 — VerificationHorizon/
Wu 等（2026）。《CUSP：用 AI 预测科学进展》。 arXiv:2605.22681。 — ForecastingScientificProgressWithAI/
Zeng, Papailiopoulos（2026）。《你不必运行每一次评估》。 arXiv:2606.24020。 — YouDontNeedToRunEveryEval/
Zhang 等（2026）。《SWE-Explore》。 arXiv:2606.07297。 — SWEExplore/
evals 教程（tutorials/evals/，第 00–14 章，Q&A.md，research/SOURCES_*.md）及其入门 notebook，所有贯穿示例数字的来源。jev 教程（tutorials/jev/）。

基础与实践来源

Biderman 等（2024）。《语言模型可复现评估的实战经验》。 arXiv:2405.14782。
Chiang 等（2024）。《Chatbot Arena》。 arXiv:2403.04132。
Dubois, Galambosi, Liang, Hashimoto（2024）。《长度受控的 AlpacaEval》。 arXiv:2404.04475。
Es, James, Espinosa-Anke, Schockaert（2024）。《RAGAS》。 arXiv:2309.15217。
Gu 等（2024）。《LLM-as-a-Judge 综述》。 arXiv:2411.15594。
Han 等（2025）。《RAG vs GraphRAG：一项系统性评估》。 arXiv:2502.11371。
《JEV-as-a-Judge》（2026）。arXiv:2609.26550。 — research_topics/coding_agents/JevAsAJudge/
Panickssery, Bowman, Feng（2024）。《LLM 评估器能识别并偏好自身生成的内容》。 arXiv:2404.13076。
Husain（2024）。《你的 AI 产品需要评估》。 hamel.dev。Husain（2025）。《快速改进 AI 产品的实战指南》。 Husain & Shankar（2025）。《AI 评估常见问题解答》。
Jimenez 等（2024）。《SWE-bench》。 arXiv:2310.06770。OpenAI（2024）。《SWE-bench Verified》。
Kovács, Recski（2025）。《LettuceDetect》。 arXiv:2502.17125。Tang, Laban, Durrett（2024）。《MiniCheck》。 arXiv:2404.10774。Manakul, Liusie, Gales（2023）。《SelfCheckGPT》。 arXiv:2303.08896。
Liang 等（2022）。《HELM》。 arXiv:2211.09110。
Liu 等（2023）。《G-Eval》。 arXiv:2303.16634。
Miller (2024). 为评估添加误差棒。 arXiv:2411.00640.
Saad-Falcon, Khattab, Potts, Zaharia (2024). ARES。 arXiv:2311.09476.
Schaeffer, Miranda, Koyejo (2023). 大语言模型的涌现能力是海市蜃楼吗？ arXiv:2304.15004.
Shankar, Zamfirescu-Pereira, Hartmann, Parameswaran, Arawjo (2024). 谁来验证验证者？ arXiv:2404.12272.
Tan et al. (2025). JudgeBench。 arXiv:2410.12784.
Verga et al. (2024). 用陪审团取代法官（PoLL）。 arXiv:2404.18796.
Wang et al. (2024). 大语言模型不是公平的评估者。 arXiv:2305.17926.
Yan (2024). 行之有效与行之无效的任务特定LLM评估；评估LLM评估器的有效性。 eugeneyan.com.
Yao, Shinn, Razavi, Narasimhan (2024). τ-bench。 arXiv:2406.12045. Sierra (2025). τ⁠²-bench。 arXiv:2506.07982.
Zhang et al. (2024). GSM1k。 arXiv:2405.00332.
Zheng et al. (2023). 用MT-Bench和Chatbot Arena评判LLM-as-a-Judge。 arXiv:2306.05685.
Zhou et al. (2023). IFEval。 arXiv:2311.07911.
2026年审计：当AI基准陷入停滞（arXiv:2602.16763）；当评判者改变，测量也随之改变（arXiv:2607.08535）；无有效性之可靠性（arXiv:2606.19544）；AgentLens（arXiv:2605.12925）。

已读完 · 本文由熊猫易读翻译重排

评估：如何判断AI系统是否真正有效

快速把握（如果你别的都不读，就读这一段）

第 0 层：整个循环，跑一次，处理一张工单

第 1 层：我们究竟在测量什么？

第 2 级：哪里出了问题？先看数据

第 3 级：用代码制成的评分器

第 4 层：以模型作为评分器，以及如何检验它

第 5 层：诚实的数字

第 6 级：带部件的评分系统

第 7 层：公开基准

第 8 级：让它成为习惯

观察到的工具与方法

决策指南

十五件值得带走的事

参考文献

评分器本身也是被测系统

先读输出，再写评分器

规则看形式，裁判看意义

没有区间的差异是噪声

评估：如何判断AI系统是否真正有效

快速把握（如果你别的都不读，就读这一段）

第 0 层：整个循环，跑一次，处理一张工单

第 1 层：我们究竟在测量什么？

第 2 级：哪里出了问题？先看数据

第 3 级：用代码制成的评分器

第 4 层：以模型作为评分器，以及如何检验它

第 5 层：诚实的数字

第 6 级：带部件的评分系统

第 7 层：公开基准

第 8 级：让它成为习惯

观察到的工具与方法

决策指南

十五件值得带走的事

参考文献

评分器本身也是被测系统

先读输出，再写评分器

规则看形式，裁判看意义

没有区间的差异是噪声