← 返回闯关手册

Eval Set 实战：如何为你的 AI 产品建立第一套评测集？

核心内容速览

• 任务×难点矩阵：不要随机凑 Case。先列任务类型（问答/生成/Agent 操作），再叠加难点维度（长上下文、多步推理、边界输入、对抗表达），交叉处才是评测集该覆盖的格子。
• 20 条启动配比：第一套评测集不求大——约 70% 高频正常任务、20% 难点任务、10% 对抗/边缘案例，跑通闭环后再扩充。
• Case 六问模板：每条 Case 写清——输入是什么、期望行为、关键证据、失败长什么样、用什么裁判、不过怎么办。
• Case 要有保鲜期：线上真实 badcase 要持续回流进评测集，评测集否则会在几次迭代后「被刷熟」而失效。

适合谁 · 怎么用

适合作为「从读到做」的起点。建议读完后直接进入本站第 5 部分的实战任务，按六问模板写出你的前 5 条 Case。

闯关自测

先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。

Q1　第一套种子评测集的 20 条启动配比是什么？

约 70% 高频正常任务、20% 难点任务、10% 对抗/边缘案例。先跑通闭环再扩充，不求一步到位。

Q2　「Case 六问」是哪六问？

输入与环境、必须做到、不能出现（红线）、如何判断（程序还是 Rubric）、保存什么证据、来源与版本。

Q3　为什么评测集用久了会「被刷熟」？

模型/Prompt 迭代会针对已有 Case 过拟合，分数失真。解法是线上真实 badcase 持续回流，保持评测集的新鲜度。

以下为原文全文

上方为本站原创导读，下方为原文完整收录，便于对照阅读。

很多团队的第一套评测集，是从一张「问题—标准答案」表开始的。它能测「上海出差的住宿上限是多少？」这类问题，却容易错过真实用户的问法：「我下周去上海见客户，周末想多住两天再回。多出来的酒店和返程票怎么处理？」

第二个问题没有固定答案：系统要找到现行制度，区分公务与个人行程，看信息是否齐全，给出可核查的出处；条件不足时还要知道先追问，而不是猜一个结论。

固定场景，不等于固定唯一文案。Eval Set 真正要固定的，是任务、环境和判断方法。

先把位置放对：Eval Set 只是评测系统的一部分

发布前：固定 Case → 候选版本 → 独立评价 → 发布、修改或回滚
上线后：真实 Run / Trace → Online Eval → 监控趋势、发现新失败
交付时：生成结果 → 质量检查 → 不达标则修改、追问或转人工（Runtime Loop）

三者可以共用一套 Rubric；程序、模型或人工负责执行判断。本文只聚焦：如何把真实任务整理成一套能重放、比较和定位问题的固定 Eval Set。

第一步：先决定评测要支持什么决策

不要从「先收集 100 道题」开始。先完成这句话：

我们要判断______系统，能否帮助______用户，在______场景完成______任务，同时避免______失败。

企业知识助手示例：「判断企业知识助手，能否帮助员工查询现行制度和办事流程，在信息不完整、文档较多时给出有出处的回答，同时避免引用过期制度、编造规定和越权下结论。」

再写清这套评测支持哪个现实决策（比较两个模型？验证知识库改版？能否扩大上线范围？），并记录被测系统的版本和关键运行条件——否则模型、提示词、知识库变了，下一次就无法公平复现。

第二步：先找真实任务，再整理失败类型

第一批 Case 应优先来自业务现场：真实请求和运行记录、人工接管与差评、上线前反复手工检查的任务、领域专家认为绝不能发生的错误。

看一条原始记录：用户问「公务出差后想多住两天，酒店和返程票怎么处理？」原回答「个人延长行程产生的酒店和返程交通都不能报销」。失败信号：用户追问两次后转人工。初步标签：漏掉混合行程规则；回答过度一刀切。

这条日志告诉我们「这里值得测」，但还不能直接重放：当时有哪些文档？用户缺什么信息？怎样算合格？都没写清。此时不要按用户措辞分类，而要按「为什么失败」分类：过期文档干扰、条件遗漏、信息不足却直接下结论、无答案时继续编造、权限受限时仍泄露内容。

第三步：用「任务 × 难点」矩阵删重复、补盲区

候选题多，不等于覆盖充分。画一张矩阵：纵轴放核心任务（直接查制度、解释流程、跨文档综合、判断无答案），横轴放会真正改变系统表现的条件（信息缺失、版本冲突、权限受限、检索工具异常）。矩阵只做三件事：合并能力相同的重复题，补上重要空白，保留横跨多个难点的复杂链路。

第四步：从候选池选出第一批 20 个 Case

标准启动路径：先收集 30—50 条候选场景，再筛出 20 个可运行 Case 作为 v1.0。一个方便起步的结构：

• 8 个高频主路径，代表产品的日常价值；
• 4 个信息不足或表达模糊的边界；
• 4 个真实发生过的失败；
• 2 个文档、工具或权限异常；
• 2 个低频但高后果的红线。

这不是行业标准，而是一个启动配比。每条 Case 都要写一句入选理由。日常任务和高风险任务要分开报告——一类严重错误即使只占 1%，也不应被平均分掩盖。

第五步：把一条日志补成可运行的 Case

一条 Case 至少回答六个问题：

1. 输入与环境：系统收到什么，可以看到什么？
2. 必须做到：合格结果必须出现哪些事实或行为？
3. 不能出现：什么错误一发生就应该失败？
4. 如何判断：哪些由程序核对，哪些依据 Rubric 判断？
5. 保存证据：需要留下回答、引用、检索文档还是工具记录？
6. 来源与版本：它从哪来，为什么入选，当前是哪一版？

补完后的 CASE-002 示例：

来源：LOG-002，脱敏后加入回归集。

输入：员工询问公务出差叠加个人周末行程时，酒店和返程票怎么处理。

环境：知识库有现行制度 v3、已失效 v2 和混合行程说明；用户未提供原返程日期、票价和审批情况。

必须做到：说明个人追加住宿自理；按原公务行程合理票价和审批条件判断返程交通；追问缺失信息；给出有效引用。

不能出现：保证一定报销；简化成「返程交通一律不报」；引用 v2。

判断：程序检查文档版本、关键条件和引用；模型或人工按 Rubric 判断完整性、清晰度和风险意识。

证据：保存最终回答、检索文档 ID、引用位置和工具 Trace。

然后让两个版本面对同一条 Case：RUN v1 FAIL（未检索混合行程说明，也没追问）；RUN v2 PASS（关键条件、追问与引用均通过）。一次线上失败就这样被补成可反复运行、判断和定位的评测任务。

第六步：先验收评测任务，再用它评价系统

评测题本身也会坏。正式使用前检查四件事：

1. 可解：环境确实提供了完成任务需要的信息和工具；
2. 一致：题目写出的要求，与评价器实际检查的内容一致；
3. 可判：两位领域专家能对同一结果形成接近判断；
4. 可复现：至少有一份合格样例可以通过，环境不会频繁失败。

先让两位业务人员独立试判 3—5 条。分歧很大就先修 Case 和 Rubric，不要急着接模型 Judge。有随机性的系统，同一 Case 先试跑 3 次看结论是否稳定。第一版跑通后，再拆成核心集、回归集、风险集和留出集，并为每次修改记录版本与原因。

最后，让真实失败继续回流

线上发现新失败 → 脱敏并确认是真问题 → 补成可重放的回归 Case
→ 修复系统 → 用固定 Eval Set 重新验证

如果今天只有一小时

1. 用一句话写出评测目标；
2. 找 10 条真实任务和 5 条真实失败；
3. 画一张「任务 × 难点」矩阵；
4. 选出 8 个最有代表性的场景；
5. 按六项模板，先完整写好其中 3 个；
6. 找一位业务专家试做、试判，先修掉歧义。

这 8 条是种子集，不是完整 v1.0。但当下一次修改模型、提示词或知识库时，你已经可以让新旧版本面对同一部分现实，而不再靠几条 Demo 猜它有没有变好。