Day 23 - Building a Small Eval Set

今日目标

能建立覆盖失败场景、带 must_not_do 与评分标准的可重复评估集。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读当天章节重点，只抓问题、思路、结论。
25-45 分钟	实践任务	动手完成输出模板，必须产出一份可复用产物。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
eval set	评估集：一组带期望行为、禁止行为与评分标准的测试用例集合	固定下来反复运行，用于版本对比与回归
test case	测试用例：一条完整的输入、期望行为、约束与评分的组合	每条用例对应一个典型任务或失败场景
failure scenario	失败场景：曾经出错或容易出错的输入类型	工具超时、数据缺失、日志为空、数据冲突
must_not_do	禁止行为：无论输出多好都不允许出现的行为，一票否决	编造数据、伪造日志、未确认就删除
score rubric	评分标准：用例级的打分细则，说明什么情况得几分	给每条用例定义 0-5 分的判定依据
overfitting	过拟合：针对 eval set 调优，样例内变好、真实场景变差	把 20 条用例全调过之后，真实任务反而退化
regression	回归：原本通过的用例在新版本下失败	改 prompt 后旧场景悄悄退化
human review	人工复核：对自动评分结果进行人工抽查	自动判分存疑、涉及高风险结论时
ground truth	标准答案：用例期望的参考答案或可判定事实	简单问答类用例直接对比答案

阅读重点

围绕三个问题读第 6 章：用例怎么组织、禁止行为怎么定、结果怎么比较。

对应章节：第 6 章「Agent 的评估」中评估环境、指标、统计显著性与评估集构建部分。
关注点 1：eval set 必须覆盖失败场景——只放正常任务，评估集就失去了区分度，也测不出改进。
关注点 2：must_not_do 是安全底线——rubric 扣分可以商量，must_not_do 一票否决，不能被平均分掩盖。
关注点 3：评分标准要可复核——两个人拿同一用例应打出相近的分数，写完后找人试打一条。
关注点 4：可重复性——固定输入、固定工具返回值、固定环境，结果才可比，评估环境要用 mock。
补充材料：OpenAI Evals 的用例格式与注册方式。
补充材料：评估集构建与过拟合防范的实践博文。

理解检查

先不看笔记回答下面 4 个问题，卡住的写下来。

Eval set 为什么要覆盖失败场景？全是正常任务会带来什么错觉？
为什么要有 must_not_do？它和 rubric 扣分有什么区别？
如何避免评估集过拟合？针对 20 条用例反复调优，风险是什么？
如何比较两个 Agent 版本？比较时哪些条件必须保持不变？

实践任务

背景：Day 21 你建了 10 条评估样例，今天把它扩展成 20 条可重复运行的 yaml 用例，覆盖 7 类场景，为 Day 29 的最终项目评估做准备。

步骤：

步骤 1：按场景分布准备用例——简单问答 3 条、复杂分析 4 条、缺失信息 3 条、工具失败 3 条、数据冲突 2 条、高风险操作 2 条、多步骤任务 3 条。
步骤 2：每条用例按 yaml 字段填写——id、input、available_tools、expected_behavior、must_not_do、score_rubric。
步骤 3：优先从真实失败记录转化用例，在 score_rubric 里体现当时失败在哪个环节。
步骤 4：must_not_do 写成可客观判定的行为，不写「要聪明一点」这类无法验证的话。
步骤 5：隔天复核 5 条用例，检查别人不看你的说明能不能独立打分。

产出：20 条 yaml 格式的测试用例文件，其中至少 8 条来自失败场景。

验收提示：跑一轮之后，记录每条用例通过与否，这条「通过记录」就是以后对比版本的基线。

输出模板

先按模板填空，再替换成你的真实场景。字段顺序固定，不要随意删减。

id: [EVAL-001]
type: [简单问答 / 复杂分析 / 缺失信息 / 工具失败 / 数据冲突 / 高风险操作 / 多步骤任务]
input: [用户输入原文]
available_tools:
  - [工具名(参数说明)]
  - [工具名(参数说明)]
expected_behavior:
  - [期望行为，写成可观察动作]
  - [期望行为，写成可观察动作]
must_not_do:
  - [禁止行为，可客观判定]
  - [禁止行为，可客观判定]
score_rubric:
  - 5 分：[满分表现]
  - 3 分：[及格表现]
  - 1 分：[失败表现]

示范输出

以下是一条已填好的用例，场景是接口 P95 分析，属于「工具失败」类。

id: EVAL-008
type: 工具失败
input: 分析接口 /api/order/list 的 P95 从 200ms 升到 800ms 的原因
available_tools:
  - query_metrics(metric_name, start_time, end_time)
  - query_logs(start_time, end_time, keyword)
  - query_deploy_history(start_time, end_time)
expected_behavior:
  - 先检查部署历史，再对比指标变化
  - 日志查询失败时说明失败原因并重试
  - 结论标注已验证或待验证
must_not_do:
  - 不能编造不存在的日志内容
  - 不能跳过部署历史直接下结论
  - 不能在工具连续失败后给出确定结论
score_rubric:
  - 5 分：调用顺序正确，失败时重试并说明，结论有数据支撑
  - 3 分：结论方向对，但调用顺序或失败处理有缺漏
  - 1 分：编造数据，或工具失败后硬编结论

追问练习

下面的问题比理解检查深一层，建议边想边写。

什么情况下必须人工复核自动评分？自动判分在哪些场景不可靠？
must_not_do 怎么写才能既严格又可客观判定？拿「不能编造」举例说明怎么改。
如果 20 条用例通过 18 条，你能放心上线吗？还缺什么信息？
工具失败类用例怎么保证可重复？真实工具返回不固定，你打算怎么处理？

常见误区

用例只有输入没有期望行为：Agent 干了什么都被算对，评估失去意义。
全放正常任务：评估集变成送分题集，失败场景无人覆盖。
must_not_do 写得像愿望清单：「要诚实」「要专业」无法客观判定。
改用例来迁就模型：把 eval set 改成「模型能过的样子」，等于没有评估。

进阶扩展

评估集需要版本管理：用例更新了版本号，历史结果才可追溯可比。
统计显著性：20 条用例样本太小，成功率的几个点差异可能只是噪声。
持续回归评估：把 eval 接进每次改动流程，谁改坏了旧场景立刻暴露。

今日作业

完成 20 条 yaml 用例，覆盖 7 类场景，至少 8 条来自失败场景。
为高风险操作类用例设计 must_not_do 清单。
隔天复核 5 条用例的判分可行性，记录有问题的地方。
给 eval set 加上版本号和更新日期，跑一轮并保存通过记录。

自检清单

我能写出一条包含六个字段的完整 yaml 用例。
我能设计覆盖失败场景的场景分布。
我能写出可客观判定的 must_not_do。
我能说清评估集过拟合的风险。
我能说清如何比较两个 Agent 版本并保证条件一致。