基准是一份测量契约

基准分数并不只是模型权重的属性。它来自这样一次运行：让一个模型版本通过一套运行框架，在一个测试集版本上作答，再用一套评分器和汇总规则得出结果。其中任何一项发生变化，数字都可能随之改变。因此，一份有用的报告应当从评测要支持的主张写起，并保留足够的证据，让别人能够重建这项主张。

本章将这套要求整理成一份测量契约：如何选择测试案例，如何让它们与开发过程保持隔离，如何固定执行框架，如何审计答案，以及如何保留逐案例记录。下一章 第 48 章 会在这些条件已经确定之后，继续分析结果还剩下多少不确定性。

从决策出发，而不是从数据集出发

假设一个团队问：「新模型是否更好？」在明确「更好」的含义之前，任何基准都无法回答这个问题。它要回答谁的问题，在什么条件下，付出多少成本，又要支持哪项决策？一份选择题试卷可以测量模型在这些题目上的表现，却不能在缺少其他证据时证明模型具备通用智能、适合生产环境或足够安全。Raji 等人指出，基准所测的狭窄任务与人们希望它代表的宽泛概念之间，往往存在这样的落差 (Raji et al. 2021)。

选择测试之前，先写下希望成立的主张：

对于上一季度收到的英文客服请求，在使用生产环境的提示和检索系统时，模型 B 比模型 A 解决了更多问题，同时没有降低政策合规率，也没有超出延迟预算。

这句话明确了总体、系统边界、比较对象和约束条件，也说明没有任何单一公开基准能够独自决定这项选择。公开套件仍适合外部比较和回归测试，但产品主张需要由贴近实际产品分布的样本来支持。以证据为中心的基准设计框架把这个顺序写得很清楚：先定义能力和预期用途，再说明测试内容为何合理，记录模型如何适配或接受提示，收集足够多且具有代表性的项目，最后解释案例级证据如何支持整套测试的结论 (Liu et al. 2024)。

常见的基准形式体现了不同的测量选择，不是同一种能力的可互换度量：

只有当套件的组成与待验证主张相符时，扩大覆盖面才有意义。「基准彩票」描述的正是这种现象：只要换一组任务、数据集或指标，结论和排名就可能改变 (Dehghani et al. 2021)。加入彼此无关的测试，可能让看板变得更大，却让含义更模糊。

明确评测对象

评测应当是一件带版本的工件，而不是某个人记得的一条终端命令。它的规格至少要固定数据、模型、运行框架和评分器：

EvaluationSpec:
  benchmark_id, benchmark_revision, item_manifest_hash
  model_id, model_revision, tokenizer_revision
  prompt_template_revision, system_policy_revision
  few_shot_policy, tool_environment_revision
  decoding_parameters, seeds, repetitions
  scorer_revision, normalization, exclusion_policy
  contamination_audit_revision, run_environment

EvaluationCase:
  case_id, source, license, created_at, language, domain
  input_hash, reference_hash, rubric_revision
  slice_labels, dependencies, leakage_status

EvaluationRecord:
  spec_hash, case_id, attempt, raw_output_hash
  parsed_output, score, scorer_trace
  latency, token_cost, tool_cost

这三类工件不能混在一起。EvaluationSpec 说明整次运行如何执行，EvaluationCase 说明每个项目代表什么，EvaluationRecord 则保存实际发生了什么。汇总分数可以由这些案例级记录重新计算；记录一旦丢弃，汇总分数无法把它们还原。数据集文档在更大的范围内承担同样的职责：把动机、组成、收集方式、推荐用途和局限写出来，不让它们停留在隐含假设中 (Gebru et al. 2021)。

设第 $i$ 个案例的得分为 $y_i$，预先声明的权重为 $w_i \ge 0$，案例总数为 $n$。报告中的加权均值为

$$\widehat{\mu} = \frac{\sum_{i=1}^{n} w_i y_i}{\sum_{i=1}^{n} w_i}.$$

这里，$i$ 标识一个评测案例；$y_i$ 可以是二元正确率，也可以是数值型准则分数；$w_i$ 决定该案例对结果的贡献；$\widehat{\mu}$ 则是这些权重所对应目标总体的均值估计。等权重并不等于没有假设，它假设抽到的每个案例都应当贡献相同分量。

在同一批案例上的比较中，还要保留 $d_i = y_i^{(B)} - y_i^{(A)}$，也就是系统 B 与系统 A 在每个案例上的得分差，再汇总所有 $d_i$。这种配对记录可以看出 B 是修复了 A 的失败，还是用一批新失败换掉了旧失败。如果随机代码任务或智能体任务会重复尝试，应先在任务内部汇总或建模，再把任务当作独立单位。同一个代码仓库尝试二十次，并不等于二十个相互独立的仓库。第 48 章 将进一步介绍相应的区间估计和检验方法。

图 47.1 展示了这条依赖链。分数是多项带版本决策的最终投影，不是第一手证据。

留出数据究竟要避开哪些环节

留出集（held-out set） 是刻意排除在所有训练阶段之外的数据。它是一份流水线契约，不是文件自身能够证明的属性。在封闭的训练流水线中，这份契约可以覆盖预训练、监督微调、偏好数据、合成数据生成、提示选择和检查点选择。对于训练数据不公开的外部模型，评测者通常无法证明模型从未见过某个公开测试。诚实的状态应当是「暴露情况未知」，而不是「干净」。

「污染」一词经常把几种不同的失败混在一起：

1. 训练泄漏： 输入、答案或近似重复项进入预训练或后续训练数据。
2. 间接泄漏： 合成样本从教师模型或检索来源继承了基准内容。
3. 开发泄漏： 团队反复根据评测结果选择提示、解析器、检查点或政策。
4. 报告泄漏： 输出已经可见之后才过滤或重新解释项目，却没有在报告中披露排除规则。

第三种失败就是常见的自适应过拟合。开发者每查询一次测试集、修改系统、再查询一次，测试集作为新鲜证据的能力都会下降。可复用留出集研究为自适应数据分析形式化了这个问题：如果要在反复访问后仍保持有效性，就需要控制披露范围或引入新数据 (Dwork et al. 2015)。只有发布服务可以访问的私有最终集合，可以保留最后一道独立检查。但它并不会永久可信，还剩多少独立性取决于访问历史和以往决策。

审计只能提供是否暴露的证据，不能证明从未暴露。训练语料可用时，精确哈希和 n-gram 匹配可以找出完全相同或近似重复的内容。模型如果复现了预先植入的唯一金丝雀字符串，说明该字符串曾被摄入。成员推断（membership inference），也就是成员推断测试，会在无法查看语料时，通过模型权重推测某个具体样本是否用于训练。例如 Min-K% Prob 把一段文本中原本最不可能的词元在模型下异常偏高的概率作为成员信号 (Shi et al. 2024)。这项 ICLR 研究是在特定数据和模型条件下评估一种检测方法；检测结果为阴性时，阴性结果不能证明样本从未出现。

把审计范围直接写进状态名称，例如 known_overlap、suspected_overlap、no_overlap_found_under_audit_X 或 not_auditable。如果一个检测器没有发现问题就把案例标成 clean，最重要的限定条件也随之丢失。

不存在普遍最安全的发布方式。每种方案都在保护一种性质的同时牺牲另一种：

LiveBench 是持续轮换题目并自动评分的一个例子 (White et al. 2025)。这种设计降低了部分暴露风险，却不能保证题目具有代表性、评分器正确，也不能让不同轮换版本的分数自动具备可比性。「新鲜」与「有效」回答的是两个不同问题。

审计测量工具

即使测试确实从未出现过，也仍可能出错。题目的答案可能不正确，措辞可能有歧义，事实可能已经过期，依赖项可能损坏，解析器也可能拒绝一份有效答案。MMLU-Redux 对 5,700 道 MMLU 题进行了人工重标，并估计其中 6.49% 存在错误，不同学科之间的差异很大 (Gema et al. 2025)。这项结果提醒我们，不能因为一份答案写在标准答案中，就把它直接当成真值。

在把一套基准用作发布门禁之前，应当抽样审计案例，并检查每一个足以改变决策的案例：

• 题目是否只有一种站得住脚的解释；
• 参考答案与解释是否一致；
• 其他有效答案能否通过归一化和解析；
• 重复项或共同来源是否让不同案例彼此依赖；
• 日期、工具、软件包、网站和代码仓库是否仍然有效；
• 语言、领域、难度和用户切片是否覆盖目标总体；
• 许可证与访问条款是否允许预期用途；
• 排除规则是否在查看结果之前声明。

还要保留裁定日志。修正一个项目就会产生新的基准版本；如果仍沿用旧名称悄悄修改答案，不同运行之间就失去了可比性。同时运行几项简单基线，例如适用时的随机选择、简单的词汇启发式方法、上一版生产系统，以及有意义时的理想上限（oracle）或合格专家估计。如果复杂模型输给简单启发式方法，往往说明测试里存在捷径，而不是模型出现了某种微妙失误。

运行框架也是受测系统的一部分

同一组权重经过不同的提示模板、少样本示范、对话模板、解码设置、工具版本和答案解析器，可能得到不同分数。HELM（Holistic Evaluation of Language Models） 等标准化框架把这些选择明确记录下来，并评测正确率之外的属性，从而改善可比性和可审计性 (Liang et al. 2023)。标准化不会消除运行框架，而是固定一套框架，让参与者在相同且公开的条件下接受测量。

由此产生两种合理但不同的实验：

• 受控模型比较尽可能固定运行框架，询问模型版本在同一接口下有何差异。
• 最佳系统比较允许针对不同模型设计提示或工具，询问完整部署系统在相同预算和任务契约下有何差异。

不要把后者称为权重比较。反过来，如果强迫每个模型使用与其训练方式不匹配的提示格式，所回答的问题虽然容易归因，却可能对实际部署毫无帮助。报告必须说明实际运行的是哪一种实验。

评分器也要遵守同样的纪律。保留解析前的原始输出，记录解析器和评分器版本，并把 invalid、unknown、timeout、scorer_error 与普通错误答案区分开。模型评判者还会引入自己的模型版本、提示、顺序效应和随机性，第 50 章 将专门讨论这种情况。测试运行器则会引入容器镜像、依赖项、时钟、网络状态和不稳定测试。自动评分不等于没有解释空间。

基准会衰退

固定基准会通过几条彼此独立的路径失去决策价值：

• 暴露： 案例或答案进入训练与开发循环。
• 自适应复用： 即使没有直接训练泄漏，反复根据结果修改系统也会对测试过拟合。
• 饱和： 分数集中到天花板附近，剩余差异不足以区分系统。
• 总体漂移： 与决策相关的用户、任务、语言或威胁发生变化。
• 评分器漂移： 曾经有效的答案、软件包、网站、政策或评判者不再代表期望行为。

图 47.2 展示了饱和现象。图中的曲线只是示意；重点不是所有基准都会经历相同时间线，而是当大多数系统几乎答对所有题目时，一份有界测试就会失去分辨率。

不要不加判断地堆入更难的问题。只有当新案例仍然代表待测概念和实际决策时，难度才有意义。应当像维护生产依赖一样维护基准：记录版本，监控项目统计和覆盖范围，淘汰损坏案例，加入新近相关的切片；如果长期比较很重要，还要保留稳定的锚点集合。

运行、保留与报告

一套经得起质疑的基准运行流程并不复杂：

1. 写明待测概念、目标总体、预期用途、主要指标和约束条件。
2. 在 EvaluationSpec 中冻结模型、运行框架、评分器、项目清单、权重、排除规则、随机种子和重复策略。
3. 审计来源、权利、答案质量、依赖项和暴露风险。
4. 按照声明的比较设计运行基线系统与候选系统。
5. 保存每次尝试的原始输出、解析结果、评分轨迹、成本和失败状态。
6. 在正确的抽样单位上汇总，并报告配对变化、各切片结果和不确定性。
7. 如果改变格式、选项顺序、措辞或环境后语义理应不变，就用这些变化对测量工具做压力测试。
8. 只应用预先声明的发布规则，并记录每个例外和事后分析。

四条不变量让这套流程可以审计：任何评测案例都不能进入训练或调优流程；任何项目都不能悄无声息地消失；原始输出不可修改；每个报告数字都能追溯到规格哈希和案例级记录。这些规则不能保证基准必然有效，但能让错误看得见，也能够修复。

因此，评测报告应当从带限定条件的主张开始，而不是从最高分开始。它要写明基准版本、模型和系统边界、运行框架、样本与权重、评分器、已知泄漏和题目缺陷、不确定性、重要切片，以及证据能够支持的决策。排行榜中的一行省略了其中大部分背景。它可以链接到完整结果记录，却不能取代记录。

测量对象已经定义清楚，下一步要问的是汇总结果有多稳定。第 48 章 会把保存下来的案例级记录转换成区间、配对比较和发布决策，同时提醒我们不要把精确度误当成效度。

延伸阅读