评测集

它是什么

评测集是你为自己场景攒下的一组可重复运行的题：每条通常包含一个输入、一个期望结果（或一段判定标准）、以及为了让判定能自动执行而需要的人工标注。它的唯一职责是回答一个问题：这次改动，让系统变好了还是变差了。[S1]

它和「随手试几个例子」的差别有两条：固定（题目不变，才能比较前后）与覆盖（题目要专门包含那些容易出错的情况，而不只是正常情况）。少了任一条，它提供的就只是感觉，不是证据。

为什么需要它

因为没有它，团队对「好没好」的判断会退化成三种替代品，而且每一种都很有说服力：

• 看几个例子就下结论——你随手挑的那几个，恰好都是它擅长的场景；
• 看单个指标——满意率上升了，但没人知道它是靠更好地回答，还是靠少回答；
• 看 demo——演示用的输入是精挑过的，而线上没有精挑过的输入。

评测集的作用是把这三种替代品换成一个可复现的数字，并且这个数字可以被别人推翻——他可以说「你这 10 条题不代表性」，但这句话本身就成了可以讨论的具体问题。这比争论「我感觉它变好了」要高效得多。

NIST 把测试、评估、验证与确认（TEVV）列为 AI 系统可信性的必要环节，理由正是：没有可复现的测量，关于系统能力的说法就只是主张。[S1][S2]

它如何工作

从零开始建一个能用的小评测集，顺序通常是这样的：

1. 先定判定方式，再出题。 你打算怎么判断一条答得对不对？有标准答案、有客观字段、还是需要按标准打分？判定方式决定了题目该怎么写——如果一条题的判定方式还没想清楚，这条题就先别加。
2. 按失败类型配比，而不是按业务占比配比。 真实业务里 90% 是简单问题，但评测集里应该刻意提高难例和边界例的比例，否则整体通过率会很好看，而问题全被平均掉。常见的三类要分别出现：答错（用了错误信息）、答不全（漏掉关键约束）、编造（资料里没有却给了答案）。
3. 留一批不常用作调试的题。 如果你每次改提示词都盯着全部题目调，评测集就会慢慢被「对着题过拟合」。留出 20% 只在决定发布时才跑，能保留下它对真实效果的指示能力。
4. 让它可运行。 一次评测要能自动跑完并输出通过率与失败清单，否则它会在忙起来时第一个被跳过。

评测集的常见形态是二三十条起步，随线上发现的新问题持续增补——每修一个线上 bug，就把它变成一条新题，这是让评测集与真实世界保持同步的最省力方式。

必须澄清的误会

评测集 ≠ 基准测试。 基准测试（benchmark）是公共的、别人定好的题集，用途是横向比较模型——它能告诉你「换一个模型大概会怎样」，但不能告诉你「我们这次改的提示词在我们自己的场景里有没有变好」，因为它的题目不是你的场景。评测集恰恰相反：范围很窄，但直接对得上你的业务。两者是互补的，不能互相替代。

评测集 ≠ 黄金数据集。 「黄金」强调每条都有权威且唯一正确的答案。但很多真实任务的正确答案不唯一（一份好的摘要可以有多种写法），这时强求唯一答案会让你只接受恰好匹配的那一种。评测集的要求更低也更关键：可重复比较。判定可以是「包含这三个要点」，可以是「按量规打分」，不必是唯一字符串。

它不是一次性的交付物。 评测集会有生命周期：题目会过时（业务变了）、会被过拟合（一直盯着它调）、会失衡（只往里加出过错的那类题）。一份三个月没动过的评测集，通常已经不再反映当前的真实风险。

最需要留神的一条误解：评测集不是「证明我们做得不错」的材料。 如果它从来没有让团队放弃过一次改动，那它大概在起装饰作用。

真实例子

一个合同问答助手的评测集可以这样组织：20 条题，其中 8 条是正常条款查询，6 条是跨条款的约束类问题（答案需要综合两处条款，容易答不全），3 条是资料里没有、应当明确说「查不到」的问题，3 条是措辞含糊、需要澄清而不是硬答的问题。[S1][S2]

跑一次得到的结果会呈现这样的形状：正常查询 8/8，跨条款 3/6，越界 2/3，含糊 0/3。这个结果的价值不在于总分（13/20），而在于它指出改动的方向：问题集中在「答不全」和「不敢说不知道」两类上。如果只看总分，你会以为这是一个「大概还行」的系统。

什么时候适合与不适合

适合：任务有明确的成功判据（哪怕判据是「包含若干要点」）；系统会有多次迭代，需要判断每次改动的影响；上线后有合规或质量责任需要说明。

不适合：探索期、任务定义每天都在变——这时候出题本身就不稳定，应该先用小样本人工评估把任务收敛下来。也不适合把「收集题目」当成终点而无人跑它：一份没人运行的评测集不产生任何价值。

过拟合与选择偏差是两类不同的失真，各自要对症。 一种是过拟合：反复对着同一批题调参，通过率涨了但线上没变好。对策是留出隐藏题集并定期换题。另一种是选择偏差：出题的人只写自己想到的场景，于是评测集漏掉了真实用户最常遇到的输入。对策是从生产日志里取真实输入来出题，而不是凭想象写。

亲自试一下

用约 40 分钟为你手上的场景写 10 条题：

1. 写输入：尽量抄真实的用户输入（从日志里找），不要自己改写得更通顺。
2. 写期望：为每条写下「怎样算答对」，能客观判定就写客观标准。
3. 标类型：把 10 条分成答错 / 答不全 / 编造三类，看每类有几条。
4. 跑一遍：记录通过率和失败清单，重点写下失败集中在哪一类。

观察点不是那个通过率，而是：这 10 条里，有几条你现在已经能预测它会失败？ 能预测的题说明你对系统边界的认识已经清楚，剩下那些你预测错的题才是这次评测真正的收获。

接下来学什么

评测集是这一站（给判断）的起点：先有题，再谈好坏。 顺着走下去是 AI 评估（怎么组织判定）、大模型裁判（怎么低成本打分）、依据一致性（针对「编造」这一类失败的具体维度），以及 可观测性（把线上的真实失败变成新的题）。

如果你还没有「做检索」这个前提，可以先看上一站 给知识：检索增强生成 的失败模式恰好对应评测集里最需要覆盖的那几类。如果你正在纠结「用公共榜单行不行」，回头读一遍 基准测试 与本条的差别。

来源与修订

把测试、评估、验证与确认作为可信 AI 的必要环节，并强调评估需覆盖风险与影响，来自 NIST 的 AI Test, Evaluation, Validation and Verification (TEVV) 与 ARIA Pilot Evaluation Report。[S1][S2]

需要说明一处边界：「先定判定再出题」「按失败类型配比而不是按业务占比配比」「留 20% 隐藏题」「每修一个线上 bug 就加一条题」这四条操作规则，是本站在整理评测集实践时总结的，不是上述来源的原文。NIST 的文档面向评估框架与风险维度，不给出题集的规模与配比细则。

2026-09-21 按决策页规范重写，本次修订补入「先定判定再出题」、失败类型配比与隐藏题集的作用，把评测集与「随手试几个例子」区分开。