作者：Lei阅读 --

什么是一个好的评测样本？不是一道难题，而是一份决策证据

结合 ECBD、CheckList、Dynabench、SWE-bench 与 LiveBench，建立一套判断 LLM/Agent 评测样本是否有效、可判、可复现、能区分且不过期的工程框架。

AILLM评测AgentAI Infra论文深读

一条评测样本的价值，不在于它有多难、看起来多真实，甚至不在于模型能不能答对。它的价值在于：模型在这条样本上的行为，能否成为某个真实决策的可信证据。

上一篇《业务评测覆盖地图》回答了「评测要覆盖哪些格子」；这一篇继续往下钻：一个格子里放什么样的样本，才不会把噪声包装成分数？

先说结论：不存在脱离用途、单独成立的“好样本”。 同一道题，用来挑选客服模型可能毫无意义，用来诊断长上下文引用能力却可能非常有价值。样本质量不是文本本身的属性，而是「决策—能力—行为—判据」这条证据链的属性。

先换一个心智模型：样本不是题目，是测量仪器的一次读数

教育考试不会因为一道题“很难”就认定它是好题。它先问：要推断学生具有什么能力？这道题会诱发什么可观察行为？怎样从答案中提取证据？这个分数最终拿来做什么？

ECBD（Evidence-Centered Benchmark Design，ACL 2024）把这套思路移植到了 NLP 基准设计：benchmark 不是题库，而是从模型的可观察行为中收集能力证据的系统。论文把设计拆成 capability、content、adaptation、assembly、evidence 五个模块，并要求每个选择都经过「描述、论证、证据支持」。

把它压缩到单条样本，可以得到一条最小证据链：

要做的决策
  → 想验证的能力主张
  → 能诱发该能力的输入与环境
  → 模型产生的可观察行为
  → Oracle / Rubric 提取出的证据
  → 与其他样本共同支持或否定决策

这里有五个需要一直盯住的杠杆：

  1. 用途：分数要支持上线、路由、回归门禁，还是故障诊断？
  2. 构念：想测的是事实正确、指令遵循、工具使用，还是任务终态？
  3. 诱发：输入和环境是否真的迫使模型表现这项能力？
  4. 判定：输出里的什么事实算成功，谁能稳定地判断？
  5. 组合：这条样本在整个分布中补了哪个缺口，而不是又重复了什么？

任何一环断掉，样本都可能“长得像评测”，却不能产生可解释的证据。

一个贯穿全文的例子：两条“修复代码”的样本

先看一条常见但糟糕的 Agent 评测样本：

task: 修复订单模块的偶发失败
repo: 当前开发分支
judge: 让另一个 LLM 按 1-10 分评价补丁质量
pass: judge_score >= 8

它很真实，也可能很难，但几乎每一环都在漏：

  • “偶发失败”没有定义目标行为，失败可能来自业务逻辑、环境或 flaky test；
  • 当前分支会变化，同一模型明天面对的不是同一道题；
  • 没有冻结依赖、工具、网络和基线状态，失败无法归因；
  • Judge 同时在判断正确性、风格和猜测需求，8 分没有稳定含义；
  • 即使模型通过，也不知道它证明了定位、修改、测试还是碰巧绕过断言的能力。

再看改造后的版本：

decision: 是否允许候选 Agent 处理“跨文件状态一致性”缺陷
capability: 根据 issue 与代码定位根因，并保持既有接口兼容
source: 已脱敏的真实缺陷；记录来源、采样日期与授权范围
fixture: 固定提交与依赖锁文件；干净工作区；网络关闭
baseline: 指定回归测试在原始代码上稳定失败
oracle:
  - 隐藏回归测试通过
  - 既有测试套件无回归
  - 不允许修改测试和公开接口
evidence:
  - 补丁、测试报告、退出码、运行日志、环境指纹
status: reviewed

后一条更好，不是因为字段多，而是因为证据链闭合了。它借鉴了 SWE-bench（ICLR 2024） 的关键形状：从真实 GitHub issue 和代码仓库出发，让模型在执行环境中修改代码；同时也符合Agent 测试决策地图里的 Oracle 原则——能判世界状态，就不要只判模型说得像不像。

好样本的七个条件

下面七条是我把上述测量、行为测试与动态基准研究映射到工程流程后的整理框架，不是哪篇论文的原文分类。

1. 有效：它直接服务于一个明确决策

第一问不是“这题测什么”，而是“这个分数会改变什么动作”。

  • 用于发布门禁，样本必须覆盖不可接受的回归风险；
  • 用于模型路由，样本必须能区分候选模型在目标流量上的能力、成本或延迟；
  • 用于诊断，样本应尽量隔离单一行为，让失败能指向修复方向；
  • 用于研究能力边界，样本可以偏难，但不能把业务上线结论外推过头。

ECBD 最重要的提醒正是：有效性不是“分数算得准不准”，而是证据和理论是否支持你对分数的解释与用途。如果团队说不出“这条样本失败后我们会做什么”，它大概率还只是收藏，不是评测资产。

2. 代表：它在目标分布或风险地图上有清楚位置

“来自真实流量”不是充分条件。真实流量里同样有信息缺失、重复问题、脏数据和无法判定的请求。好样本要能回答：

  • 它来自哪个用户、业务、语言、任务与时间窗口？
  • 它代表高频主路径，还是低频但高损失的风险？
  • 它是随机抽样、失败挖掘、专家设计，还是合成增广？
  • 隐私、授权、脱敏和保留期限是否允许它长期进入金集？

Data Statements for NLP（TACL 2018）主张记录数据来源、语言与人群等背景，目的不是多写文档，而是让“结果可以泛化到谁”这件事变得可讨论。Benchmark Transparency（NAACL 2024）进一步分析了歧义、难度、区分度、长度、噪声和困惑度六类数据属性；其研究发现，不控制数据分布时，数据本身对评测结果的影响可能比更换指标还大。

因此，真实样本、专家样本和合成样本没有天然高下：真实样本负责分布代表性，专家样本补高风险边界，合成样本系统地改变一个变量。关键是知道每条样本为什么存在，以及它不能代表什么。

3. 可判：成功条件在运行前就已明确

Oracle 是样本的地基。工程上，我会按可机械验证程度从上往下寻找：

  1. 可执行终态：数据库状态、测试退出码、结构化约束、编译结果；
  2. 确定性规则：精确匹配、集合包含、schema、数值容差；
  3. 有参考答案的 Rubric：逐项判据、证据引用、边界例子；
  4. 经校准的人类或 LLM Judge：保留理由、版本和复核样本。

开放式任务无法全都写成单元测试，但这不等于“一律交给 Judge”。MT-Bench / Chatbot Arena 的 LLM-as-a-Judge 研究一方面证明强模型 Judge 可以在开放问答中近似人类偏好，另一方面也系统展示了位置、冗长、自我增强和推理能力等偏差。Judge 是测量工具，不是天然真值。

一条需要 Judge 的好样本，至少要有：单维度 Rubric、通过/失败锚点、Judge 与 Rubric 版本、位置交换或盲评策略，以及定期人审校准。评审者对正确答案持续分歧时，不应平均一下强行入库；它应该回到 candidate 状态，补上下文或拆分问题。

4. 有区分度：难不等于有信息

有三类样本的信息量都很低：所有模型都通过、所有模型都失败、强模型反而稳定失败且找不到合理原因。第一类可能太容易或重复，第二类可能超出当前能力边界，第三类常提示错标、歧义或环境缺陷。

Evaluation Examples Are Not Equally Informative（ACL 2021）用项目反应理论同时建模模型能力和样本难度、区分度，展示了 item-level 分析可以帮助发现标注错误、过拟合和真正有信息的样本。它给工程上的启发很直接：

不要只统计模型在多少题上失败；还要观察哪些题稳定地区分了你真正需要区分的候选方案。

区分度也依赖用途。一条所有模型都能通过的安全底线样本，对能力排名几乎没用，但对发布门禁仍然必要；一条只有最强模型能通过的边界样本，适合能力诊断，却不一定代表主流量。样本不能只贴“简单/困难”，还应标记它承担的是 baseline、boundary、regression 还是 discriminator。

5. 可归因：不要让无关变量偷走分数

如果想测长上下文检索，却让失败主要取决于网络是否稳定；想测工具选择，却让不同模型看到不同工具描述；想测代码修复，却允许模型修改测试——得到的分数都混入了无关变量。

CheckList（ACL 2020 Best Paper）借鉴软件测试，把评测组织为“能力 × 测试类型”矩阵，包括最小功能测试、保持标签不变的扰动测试，以及按预期方向变化的测试。它真正有价值的地方不是批量造题，而是提醒我们：一次只改变一个有解释力的条件，观察模型行为是否按预期变化。

对 Agent 样本，可归因意味着冻结初始状态、工具权限、依赖、网络、时间和随机性；对对话样本，则要冻结历史轮次、系统指令、知识快照和终止条件。否则你测到的是一团系统偶然性。

6. 可复现：样本必须连同执行条件一起版本化

同一段 input 不等于同一个样本。Prompt 模板、few-shot、解码参数、工具版本、知识库快照、Judge 和答案抽取逻辑都会改变结果。

Lessons from the Trenches on Reproducible Evaluation of Language Models（2024）总结了三年评测基础设施经验，核心问题之一就是评测对设置细节敏感，而这些细节经常在交流和报告中丢失。工程上，样本身份至少应绑定：

  • 不可变输入与上下文快照；
  • 环境、工具和依赖指纹；
  • Oracle / Rubric / Judge 版本；
  • 模型、Prompt、采样参数与 runner 版本；
  • 原始输出、结构化结果和失败证据。

样本内容修正后不要覆盖旧结果，而应发布新版本。否则趋势图把“模型变好了”和“题被改了”画成同一条线。

7. 会更新：金集不是墓碑，而是有生命周期的资产

静态公开题库会老化：能力提升后失去区分度，进入训练语料后又失去独立性，业务分布变化后还会失去代表性。

Dynabench（NAACL 2021）让标注者在人与模型的闭环中寻找“目标模型会错、另一个人不会错”的挑战样本，使数据创建、模型开发和评测互相推动。LiveBench则从近期信息源持续加入新题，并坚持客观真值与自动评分，正面处理污染、判分偏差和样本过期。

这两项工作共同说明：好样本不是一次验收后永久封存。我会给它设计类似这样的生命周期：

candidate → reviewed → golden → retired
      └──────────────→ rejected

这里也有一个反向风险：只收集“当前模型会错”的对抗样本，会把数据分布拖向某个模型的盲点。动态挖掘集适合找边界，代表性回放集负责守住真实分布；两者应该并存，不能互相替代。

单条样本合格，不等于数据集可信

样本质量还有一个组合效应。一百条都很清楚的退款题，仍然不能证明模型适合整个客服业务；一百条彼此改写的边界题，也不会提供一百倍证据。

把样本组装成数据集时，至少同时看四张表：

视角要检查什么典型误区
覆盖业务切片、能力、风险和语言是否有显式空格用总样本数代替覆盖率
权重高频流量与高损失风险如何进入总分所有样本简单平均
冗余语义近重复是否虚增样本量和置信度改写十次当十份独立证据
不确定性每个切片的样本量、方差和置信区间只报一个小数点后两位的总分

HELM用“场景 × 指标”显式呈现覆盖与空缺，正适合作为 assembly 层的心智模型：先决定需要哪些证据，再选择样本；不要先把手头的数据堆起来，再给总分编故事。

一张可直接使用的样本卡

下面这张卡不是要求每条样本都写成长文，而是把最容易隐形的假设变成字段：

sample_id: stable-id
intended_decision: 这条证据将影响什么决策
capability_claim: 想验证的单一能力主张
role: baseline | boundary | regression | discriminator

source_type: production | expert | synthetic | adversarial
provenance: 来源、时间窗、采样方法、授权与脱敏记录
slice: 业务 / 用户 / 语言 / 风险标签

input_snapshot: 不可变输入与上下文引用
environment_fingerprint: 工具、依赖、知识和初始状态
oracle_type: executable | rule | rubric | calibrated_judge
oracle_spec: 成功条件、容差、禁止动作与失败证据
scorer_version: 评分器 / Rubric / Judge 版本

difficulty: 基于历史运行的估计，而非作者直觉
discrimination: 它区分了哪些候选模型或系统
known_limitations: 不能据此推断什么

freshness: 创建时间、最近复核时间、污染风险
status: candidate | reviewed | golden | retired | rejected
review: 评审者、分歧、修改记录、数据集版本

最值得自动化的不是让 LLM 把这些字段全部填满，而是建立 fail-closed 门禁：缺少决策用途、Oracle、来源、版本或审核记录的样本，不得进入 golden；评审分歧、执行不稳定、身份污染或模型归因不清的样本，保留诊断证据但不进入发布结论。

六个常见误判

收尾前，把最容易混淆的六组概念压成一句话：

  • 真实不等于可用：真实请求可能缺上下文、不可判、含隐私；
  • 困难不等于有效：所有候选都失败的题，可能只是在测题目作者；
  • 可判不等于测对了：精确匹配很稳定，但可能把正确改写判错；
  • Judge 不等于真值：它是需版本化、校准和审计的测量工具；
  • 独特不等于互补：文字不同的样本可能仍在重复同一能力；
  • Golden 不等于永久：模型、业务、知识和污染状态都在变化。

诚实提醒，以及一个最便宜的实验

本文给的是设计与审核框架，不是一套被我重新跑过的 benchmark 实验；论文中的经验结论也不能自动证明它适合你的业务。尤其是“区分度”，至少要有多个候选模型或多个系统版本的响应矩阵后才能估计，不能靠出题人的直觉提前填写。

最便宜的下一步实验是：从现有评测集随机抽 30 条，找两位评审者独立填写上面的样本卡，只回答五个问题——它支持什么决策、测什么能力、怎样判定、代表哪个切片、何时应退休。然后比较分歧：

  1. 无法写出决策用途的，移出核心集；
  2. Oracle 分歧的，补规则或降回 candidate；
  3. 切片高度重复的，去重并补空格；
  4. 多个模型结果全同的，重新判断它是门禁底线还是低信息冗余；
  5. 无法复现执行条件的，先修证据链，不要继续跑分。

做完这 30 条，你得到的不是一个更漂亮的题库，而是一张评测系统的体检报告。

最后用一句话自检：

如果模型在这条样本上通过，我究竟多知道了什么；如果失败，我又能据此做什么？

两个问题都答不出来，它就还不是一个好的评测样本。

参考论文