TransCrab
← 返回 关于

Evals：如何判断 AI 系统是否真的有效

2026-11-05 · 原文链接

这篇文章写给所有发布、采购或批准使用大语言模型（LLM）软件的人：工程师、产品经理，以及 CEO。我们用通俗语言，从全局一路讲到细节。文中每个数字都来自文末列出的来源：要么是我们围绕一个小型客服助手编写、可以实际运行的教程，要么是已发表的论文。

先抓住核心（如果只读一节，就读这里）

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

为什么需要它：语言模型的失败方式与普通软件不同。普通软件要么正常工作，要么崩溃。语言模型却可能给出流畅、自信、格式工整，但内容错误的回答。读到一条好回答，丝毫不能说明后面一百条会怎样。评估把“演示时看起来挺好”变成“在我们关心的案例中，通过率为 70%，误差约为上下 12 个百分点，而且新版本没有可测量的改善”。

它分四步运行：

  1. 收集有意义的输入，并为每条输入写下正确答案。贯穿本文的例子是：一家自行车商店的 80 张客服工单，每张都附有正确分类，以及合格回复必须包含的事实。
  2. 让系统处理每条输入，保存输出。
  3. 用评分器逐条评判输出。评分器可以是代码规则、另一个充当裁判的模型，也可以是人。
  4. 把评分汇总成一个带误差区间的数字，与上一版本比较。

什么时候使用：上线前（它到底能不能用？）、每次改动前（我们有没有弄坏什么？），以及上线后（面对真实流量，它是否仍然有效？）。

重要提醒：评分器本身也是必须测试的系统组成部分。如果裁判模型与人类只有 60% 的判断一致，它可能在产品有问题时仍告诉你一切正常。 对我们意味着什么：每项评估都要检查两个数字——产品有多好，以及评分器有多好。两个都要问。 为什么重要：AI 团队最常见的自我欺骗，就是相信未经验证的评分器给出的笃定数字。

接下来，本文逐层深入。每一层都回答上一层中的一个问题。

第 0 层：用一张工单走完一次完整闭环

深入对象：整个流程。问题：评估实际运行起来是什么样？

贯穿全文的例子，是一家虚构的自行车与露营用品网店的小型客服助手。它有三个部分，后面会分别采用不同方式评分：

下面让一张工单走完闭环。

输入：“我上班快迟到了，必须马上解决这件事。我上周退了自行车，但到现在还没收到退款。你们的政策明明说，退款会在 5 个工作日内处理……”

系统输出（分流）：退货。标准答案：退货。得分：1 分，满分 1 分。

系统输出（回复）：一封礼貌的四段式回复，引用退货章节，并提到两项必要事实：退款需要 5 个工作日，使用过的商品要收取 15% 的重新入库费。

现在，三个评分器来检查这封回复：

核心就是这样。两个廉价的代码检查都认为回复没问题，裁判却发现了一个原本会发给客户的虚构数字。后面每一层，都是为了让这个闭环在规模扩大后仍然可信。

第 0 层要记住：

第 1 层：我们到底在测量什么？

深入对象：闭环中的第 1 步和第 4 步。问题：输入和“正确答案”从哪里来，数字又是什么？

输入。案例应当像真实流量，包括那些棘手的情况。我们的 80 张工单根据“客户画像 × 主题 × 场景”的组合生成，因此包含愤怒的客户、模糊的问题，以及涉及多个问题的工单。Anthropic 的智能体评估指南建议，从真实失败中选取 20 到 50 个任务起步，而不是设想一批一切顺利的场景（Grace 等，2026）。

标准答案。为每条输入写清楚什么算“正确”：正确分类、回复必须依据的手册章节，以及必须陈述的两三项事实。由于我们的工单根据手册生成，标准答案的正确性由生成方式保证。在真实产品中，这些答案由领域专家提供。

分成两组。我们把案例分为开发集（20 张工单），用于调整提示词和评分器；测试集（60 张工单），只用于报告结果。如果用同一批案例调优，又用它们汇报成绩，数字就会虚高。

指标。分流用准确率（正确分类的工单占比）；回复用通过率（没有任何失败的回复占比）；智能体用任务最终达到正确数据库状态的占比。每次实验一个指标，始终在测试集上报告，并始终附带误差区间（第 5 层）。

四个容易混淆的词：

公开基准得分很高的模型，仍然可能错误地回答你的客户。基准测的是发动机，评估测的是汽车在你的道路上行驶的表现（Husain 与 Shankar，2025）。

第 1 层要记住：

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

深入对象：评分环节。问题：评分器究竟应该寻找什么？

在搭建自动评分器之前，先阅读输出。所有有经验的实践者都在说同一件事（Husain，2024；Husain，2025；Shankar 等，2024）：逐条阅读一两百条输出，为每次失败写一条简短笔记，然后把笔记归纳为一份简短的失败类型清单，并统计数量。这叫错误分析，其中两步分别叫开放编码（自由记录）和主轴编码（归类）。

对我们 60 条测试回复做这件事，得到：

勉强只有一半回复通过。最大的两个问题是遗漏事实和编造断言，单看演示谁也猜不到。这份清单就是接下来所有评分器的规格说明：每种失败类型配一个评分器，按出现频率依次构建。

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

还有一个相关发现：评分过程中，你的标准会变化。Shankar 等（2024）称之为标准漂移。给样例评分会让评分准则更清晰，而更清晰的准则又会改变此前的评分。预期要经过两三轮，这并不代表流程出了问题。

第 2 层要记住：

第 3 层：用代码编写评分器

深入对象：其中一种评分器。问题：普通规则能测量什么，又不能测量什么？

代码评分器就是用普通代码编写的规则。它没有调用成本、立即返回结果，而且每次答案都一样。凡是它能测量的，都交给它。

精确答案。分流只有一个正确标签，因此我们统计匹配数量。

每十张工单有七张分类正确。宏平均 F1 对全部 12 个类别等权取平均，所以稀有类别和常见类别同样重要。两个数字接近，说明错误分布较分散，并未集中在某一个类别。

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

只有 17% 的回复控制在 150 个词以内。应用太啰嗦了，发现这一点根本不需要模型裁判。IFEval 等公开基准（Zhou 等，2023）完全由这类可验证规则构成，例如“恰好用三个项目符号作答”。

必要事实。我们检查每项标准事实是否出现在回复中。这能以零调用成本发现最常见的失败类型：事实遗漏。

相似度分数。重合度指标（ROUGE、BLEU）和嵌入相似度，会把回复与参考文本比较。在我们的回复上，嵌入相似度区分好坏回复的 AUC 为 0.709（0.5 相当于抛硬币，1.0 表示完美）。它有助于发现版本之间发生了变化，却不能据此判断回复是否正确。

重要提醒：相似度能发现变化，不能评判质量。 对我们意味着什么：把它当成廉价的漂移警报，绝不要用它作为核心指标。 为什么重要：错误回复只要与正确回复用了相同的词，也能得到高分。Eugene Yan 的综述（2024）以及 ROUGE、BLEU 的原始文献，都详细记录了这一局限。

用一个数字说明代码评分器的边界：只有 11.7% 的回复通过了所有代码检查，但代码检查没有发现任何编造的断言。第 0 层的那封回复编出了 15 天的宽限期，却通过了每条规则。规则看得见形式，看不懂含义。

第 3 层要记住：

第 4 层：让模型充当评分器，以及如何验证它

深入对象：另一种评分器。问题：如果评分器本身也是模型，我们怎么知道它判断正确？

模型裁判（通常称为 LLM-as-judge）是另一个负责阅读输出并评分的模型。它能理解含义，因此可以发现那个虚构的 15 天宽限期。但它也是语言模型，所以语言模型的所有失败模式，它一样具备。这一层篇幅最长，因为大多数评估计划都在这里出问题。

4.1 如何向裁判提问

实践共识与研究文献都指向同一种形式：

Cho 等（2026）直接在摘要任务中检验了这一点（“Ask, Don't Judge”）。把评分拆解为针对具体错误的是非题，在所有数据集上都优于流行的整体式 G-Eval 方法（在 SummEval 上，与人类评分的 Spearman 相关系数分别为 0.563 和 0.514）。最能说明问题的例子是：一份刻意植入三个事实错误的摘要，整体式裁判给了满分 5.0，基于问题的裁判却给了 1.57。他们还发现，在提示词中不断塞入更多指令，最终会让裁判变差，而非变好。

4.2 验证裁判：我们自己的数字

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

60% 的一致率听着还可以，其实不行。由于多数回复本来就通过，如果裁判把所有回复都判为“通过”，也能与参考标准达到 57% 的一致率。Cohen's kappa 会修正这个问题：它测量超出随机巧合的一致程度。0 代表随机，1 代表完美；通常，要让裁判把关发布，门槛是 0.6；要让它无人监督地运行，门槛是 0.8。我们的裁判只有 0.15。它过于宽松（只有 34 条值得通过，它却放行了 42 条），而且抓到的坏回复不足一半。

重要提醒：当大多数输出都通过时，原始一致率会误导人。应报告 kappa，或者分别报告裁判抓到了多少坏输出、又错误拦下了多少好输出。 对我们意味着什么：裁判就是分类器。在信任它之前，至少用几十个案例，将其判断与人类标注对照；它产生的每个产品指标旁边，都应附上这项验证结果。 为什么重要：用这个裁判，即使某个版本的编造断言翻倍，核心通过率也可能毫无变化。

补救办法是在开发集上迭代：在裁判提示词中加入这种失败的例子、缩小问题范围，并提供标准事实作为参考。教程中，针对“事实遗漏”的裁判通过这种方式达到了可用水平；针对“无依据断言”的裁判则没有，最后交给了专用检测器（4.5）。

4.3 裁判的已知偏差

裁判的失败有规律可循。每一种都有已发表的测量结果，也都有廉价的缓解办法。

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 等，2024），以及普通的 NLI 交叉编码器，都能在笔记本 CPU 上约一秒运行完，每次调用没有额外成本，在 RAGTruth 基准上接近大型裁判的准确率。SelfCheckGPT（Manakul 等，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 等，2025）把困难但可客观核验的问题转化为裁判测试，发现面对真正困难的案例，前沿裁判也只是勉强好于随机判断。每次都必须针对具体任务、具体评分准则、具体裁判模型测量可靠性。厂商所说的“与人类有 85% 的一致率”，来自某一个数据集，不能直接迁移（见实践者资料中的分歧说明）。

第 4 层要记住：

第 5 层：诚实的数字

深入对象：闭环的第 4 步。问题：任何一个数字，我们究竟有多确定？两个版本又该怎么比较？

到目前为止，每个比率背后都藏着一个问题：换另外 60 张工单，结果还一样吗？有三种工具可以回答。

误差区间。我们对这 60 个结果重复抽样数千次（即自助法 bootstrap），观察分布范围：

诚实的说法不是“准确率为 70%”，而是“大约在 58% 到 82% 之间，最可能是 70%”。Miller（2024）指出，已发表评估所报告的模型间差异，大多比这类区间更小；他还给出了每份评估报告都应采用的公式，包括多个问题来自同一来源时所需的修正（聚类标准误）。

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

注意，这个区间比单个准确率的区间更窄，因为比较是配对的：每张工单都在两个版本下评分，工单难度的影响因此抵消。McNemar 检验关注的是逐案例的问题：v2 是否在 v1 失败的地方胜出，还是两者只是互换了成功案例？这里是后者。v2 在改善一些案例的同时，也让 14% 的案例退步。“通过率相同”这个总指标，掩盖了产品对一些客户变好、对另一些客户变差的事实。

重要提醒：差异的区间如果包含零，就不能算赢，只能视为噪声。 对我们意味着什么：每次声称“新版本更好”，都必须附上区间，以及变差案例的数量。 为什么重要：团队常凭一个从未真正成立的 2 个百分点提升，就把退步的版本上线。

可检测下限。用 60 个案例，我们能可靠检测的最小差异约为 12 个百分点。这个样本量下，5 个百分点的退步不可见。这就是统计功效计算，它能告诉你：要回答当前问题，首先需要多少案例。低于这个下限时，你需要的是更多数据，而不是更聪明的检验方法。

多重比较。如果测试 20 个提示词变体再挑最好的，其中一个可能纯靠运气看起来提升了 10 个百分点。要么按比较次数进行统计修正，要么用新案例确认胜者。

第 5 层要记住：

第 6 层：评估由多个部分组成的系统

深入对象：第 2 步，也就是系统本身。问题：系统有多个阶段，或者会采取行动时，我们该评估什么？

6.1 检索系统（RAG）

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

评估检索器。以标准章节为参照：hit@k（前 k 项中是否至少有一个正确章节）和 recall@k（正确章节中有多大比例被检索到了）。

检索器几乎没问题，问题在生成器。这一行结果，就能改变整整一周的工程投入方向。

评估生成器。忠实度（每项断言是否都得到检索文本的支持）、答案相关性（是否回应问题），以及上下文精确度（检索到的内容是否确实有用）。这就是 RAGAS 三项指标（Es 等，2024），不需要标准答案，也是 RAGAS 成为默认库的原因。ARES（Saad-Falcon 等，2024）进一步提高统计严谨性：用约 150 条人类标注校准小型的分项裁判，并报告置信区间。其论文中，上下文相关性表现比 RAGAS 高出 59 个百分点，标注量却少了 78%，不过领域发生大幅变化时性能会下降。我们运行时，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 年的三项基准测量了单一成功率看不到的东西。

6.3 当系统以评分器为目标进行优化时

如果用评分器来训练或筛选系统（强化学习、best-of-n 选择），系统就会发现评分器的盲点。Qwen 团队的 Wang 等（2026）称之为验证视界：每个评分器都是意图的代理指标，在优化压力下，代理指标与真实意图会逐渐分离。他们归纳了编程智能体的奖励作弊方式（从仓库历史读取答案、修改测试、专门为评估器打补丁），并发现行为监控能把作弊“解法”从 28.6% 降到 0.6%，同时让真正解法从 40% 升到 61%。他们认为，没有评分器能同时具备可扩展性、对意图的忠实性和稳健性：测试可扩展、稳健，却可能漏掉意图；裁判可扩展、忠实，却能被钻空子；专家忠实、稳健，却无法规模化。Meta-Agent Challenge（Lu 等，2026）也观察到了自发出现的同类现象：被要求构建其他智能体的智能体，在五次试验中试图从评分系统窃取答案。

重要提醒：任何影响训练或筛选的评分器，都会被钻空子。 对我们意味着什么：保留一个系统从未见过的独立评分器，监控走捷径的行为，并随系统进步升级评分器。 为什么重要：分数在上升，产品却在变差。

第 6 层要记住：

第 7 层：公开基准

深入对象：第 1 层中评估与基准的区别。问题：排行榜上的数字告诉了你什么，又隐藏了什么？

基准是一组固定的公开任务，用于比较模型：MMLU（学术多项选择题）、GSM8K（小学数学）、HumanEval（代码）、MT-Bench 和 Chatbot Arena（对话质量）、SWE-bench（修复真实 GitHub issue）、τ-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% 的变异。精选五个基准，就能把其余 128 个基准的预测误差控制在约 4 个百分点以内。对选择发动机来说，这是好消息：你不需要跑四十个基准。但对发现某种特定失败模式来说，它什么也说明不了，那仍然需要你自己的评估。

重要提醒：排行榜是在同一种评测框架下，用去年的考卷给发动机排名，榜首之间的差异通常还在噪声范围内。 对我们意味着什么：用基准筛出两三个候选模型，再用你自己的数据和评估做决定。 为什么重要：仅凭基准高出 2 个百分点就换模型，可能让你在实际任务上损失 10 个百分点。

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

第 7 层要记住：

第 8 层：让评估成为习惯

深入对象：开篇概览中的“何时”。问题：没有研究团队，怎样让它每周持续运转？

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

合并门禁。我们教程的 CI 门禁会重跑上述第 1、2 级检查；如果通过率相对已记录的 0.70 基线下降超过 3 个百分点，就让构建失败。它是大幅退步的警报线，不是保证：可检测下限为 12 个百分点时，5 个百分点的退步照样可能通过。要在仪表板上说清楚。

监控。上线后，抽样真实流量，廉价评分器全量运行，昂贵评分器只跑一部分，并绘制趋势。对于昂贵的门禁，Bodhwani 等（2026）的“先校准，再信任”是正确模式：先针对可验证的真实标准做一次完整审计，弄清廉价的裁判门禁在哪些范围内符合现实；CI 中只在该范围内使用它；模型、裁判、模拟器或领域变化时重新审计。他们还发现，一个零成本的“对话是否完成”布尔标记，本身就能发现预算不足造成的退步。

缓存与成本。对每次模型调用，以提示词、数据版本和执行配方为键缓存。重新运行就变成了读取文件。我们对 60 张工单进行完整 A/B 比较，需要 121 次裁判调用，约四美分；整个教程从缓存重跑时，调用次数为零。成本不是跳过评估的理由。

负责人该索取什么。一页上放四个数字：产品通过率及其区间、评分器与人类标注的一致程度、可检测下限，以及上次改动中变差的案例占比。少了任何一个，其余三个都还不足以说明问题。

第 8 层要记住：

工具与方法：实际观察

本节是观察记录，不是推荐清单。在搭建教程时，我们运行或审查过下面所有工具；详细信息见知识库中的实践与工具笔记。

框架

方法对比

我们在每个来源、也在自己的运行中都观察到一个规律：应对照着看手写评分器与框架的数字。一致是证据；不一致则提出了问题，而且通常是个有价值的问题。

决策指南

十五条要点

  1. 评估就是输入、系统、评分器、数字。先构建带标准答案的输入，那才是资产。
  2. 评估测量你的产品，基准测量发动机，别混淆。
  3. 写评分器之前先读一百条输出。失败清单就是计划。
  4. 凡是有明确答案的，都用代码评分器。它看得见形式，看不懂含义。
  5. 给裁判的是非题要附带证据和上下文。整体评分会漏掉刻意植入的错误。
  6. 对照人类判断测量裁判。报告 kappa 或错误捕获率，60% 的一致率可能毫无意义。
  7. 裁判偏爱靠前、更长、熟悉、讨人喜欢的答案。缓解办法不贵，要用起来。
  8. 满意不等于成功。给裁判提供工具调用和最终状态。
  9. 对“是否有依据”的问题，小型检测器或类型化裁判在成本上优于通用裁判，在准确率上也往往更好。
  10. 每个比率都附区间，每次比较都做配对。知道可检测下限。
  11. 流水线的每个阶段分别评分。
  12. 智能体：最终状态与路径、多次运行、pass^k、每次成功的成本，以及独立的可靠性维度。
  13. 用于优化的评分器会被钻空子。保留一个系统从未见过的评分器。
  14. 基准分数依赖评测框架，污染程度不均，也会饱和。记录完整元组。
  15. 三种节奏、说明可检测下限的门禁、监控，以及任何条件变化后的重新审计。

参考资料

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

基础文献与实践资料