小型评估集

学习目标

读完本课你能给你的 AI 应用建一个「小考题本」：8-15 个固定样例覆盖正常、边界、失败三类情况，每题记录的是期望行为而不是参考措辞——它是后面两课分层评估与版本回归的考纲。

问题场景

你改了一条提示词，随手问了两个问题感觉「还行」，就上线了。三天后发现：改写把某个场景的检索带偏了，而那个场景你恰好没问到。凭感觉测的覆盖面就是你当下想到的问题，而回归（A33）需要的是每次都测同一批问题——所以先把这批问题固定下来，这就是评估集（eval set）。

核心解释

评估集的三个组成部分，配比大致是 5 : 2 : 3（正常多、边界精、失败必测）：

1. 正常样例：资料库里明确有答案的问题。验证「该命中的能命中、该引用的有引用」。
2. 边界样例：答案要综合两个片段、或需要改写才能命中（A23 的口语问题）、或部分相关。验证系统的上限而不是运气。
3. 失败样例：资料库里没有答案的问题。期望行为是「明说资料里没有」——这类样例最容易被忘掉，却最能防住编造（A18/A22 的成果全靠它把关）。

最重要的纪律：记录期望行为，不记录参考措辞。「回答应包含『24 小时』」是措辞——换个说法就算错吗？期望行为长这样：

{
  "id": "case-001",
  "type": "normal",
  "question": "删除接口要求幂等吗？",
  "expect": {
    "retrieve": { "must_hit_document": "团队接口规范.md", "must_hit_heading": "删除接口" },
    "citation": { "required": true, "must_support_claim": true },
    "answer": { "must_state": "要求幂等", "must_not_invent": ["时间限制", "审批流程"] }
  },
  "note": "片段原文明确写了幂等要求，无时间条件"
}

它说的是：检索必须命中哪份文档哪个标题、必须带引用且引用支持结论、答案必须表达什么、不许编出什么。至于答案用「要求幂等」还是「必须幂等」，不管。

如何验证评估集本身可用：跑一遍，确认每条样例的期望都能被程序判定（命中与否、引用有无、关键词在不在），判定不了的主观项要删掉或改写成可判定形式。评估集里混进「人工感觉」项，后面就没法自动回归了。

示例拆解

三类样例各一条的完整对比（可直接抄作模板）：

{
  "cases": [
    { "id": "case-normal", "type": "normal", "question": "登录失败锁定多久？",
      "expect": { "retrieve": { "must_hit_heading": "用户接口" }, "answer": { "must_state": "十分钟" } } },
    { "id": "case-edge", "type": "edge", "question": "怎么让页面不再闪？",
      "expect": { "rewrite_needed": true, "retrieve": { "must_hit_heading": "重复渲染排查" },
                  "note": "口语问题，依赖 A23 的改写" } },
    { "id": "case-fail", "type": "fail", "question": "接口文档里写的部署价格是多少？",
      "expect": { "answer": { "must_admit_missing": true },
                  "note": "资料里没有价格信息，期望明说没有，禁止编造" } }
  ]
}

关键点：

• 失败样例的期望是「承认没有」：must_admit_missing: true 是评估器要检查的核心——这是把 A18「不知道也是一种结果」变成可自动判定的指标。
• 样例要绑定你的真实资料：样例里的文档名、标题都是自己资料库里真实存在的。资料一变（删了重传），评估集要跟着核对——考题和教材要配套。
• 数量克制：8-15 个足够起步。评估集的价值在「每次改动都全量跑」（A33），30 个跑不动的小集合不如 10 个天天跑的。
• 来源就用 A30 的复盘：项目助手工作流里 rejected 的建议、失败的中断，天然就是边界/失败样例的素材——评估集是复盘的沉淀形式。

动手任务

1. 为站内资料库写 6 条样例（3 正常 + 2 边界 + 1 失败），每条按本课模板填齐 expect 字段，特别注意失败样例要写清「期望承认没有」。
2. 自查任务：检查你写的期望里有没有「参考措辞」混入（如「必须包含某原句」），把它改写成行为判定（「必须表达 X 含义」「不许编 Y」）。
3. 推演任务：假设你要换一个嵌入模型（A20），列出评估集里哪些样例会被这次改动影响（提示：依赖语义检索的边界样例最敏感）——这就是 A33 回归的预演。

常见错误

• 只写正常样例：全部「一问一答都命中」的 happy path，测不出编造、测不出改写失效，评估集沦为摆设。
• 期望写成参考答案：评估变成「措辞匹配」，模型换个等价说法被判错——评估结果不可信，不如不评。
• 样例引用了不存在的资料：资料库更新后没核对，样例永久失败或永久空过，没人再信评估结果。
• 评估集只增不删不维护：堆到几十条，跑一次几分钟，渐渐地没人跑了。小而常跑，才是评估集的生存方式。

检查与复盘

自查清单：

• 能说出三类样例的配比与各自验证什么（正常:边界:失败 ≈ 5:2:3）
• 每条期望都能被程序判定，没有「人工感觉」项
• 失败样例的期望是「明说没有」而不是「给出答案」

参考资料

• OpenAI 文档：API Reference - Evals —— 评估任务的数据结构参照
• OpenAI 文档：Prompt engineering —— 评估与提示迭代的关系
• 下一课 A32 用这套考题做分层评估：检索、引用、答案分开打分。