# 第 22 章 Golden Set 与 LLM-as-judge

## 本章目标

- **O1** 能够区分“常规样本”“边界样本”“红线样本”各自覆盖的风险或职责（产物：Golden Set 分层表）
  - 证据: Golden Set 分层表分别定义“常规样本”“边界样本”和“红线样本”的覆盖对象
- **O2** 能够构造Golden Set 分层表，为三个层面分别写出检查方法和证据（产物：Golden Set 分层表）
  - 证据: Golden Set 分层表为三个层面各写出检查方法、责任人和通过证据
- **O3** 能够按常规、边界与红线用途分层 Golden Set 并校准裁判（产物：Golden Set 分层表）
  - 证据: 产物分别记录三类样本的来源、用途、标准和人工复核条件

## 学习路径

- **初学者**: 本章迁移任务是：能够按常规、边界与红线用途分层 Golden Set 并校准裁判。先按图中的“分层覆盖”关系完成Golden Set 分层表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够按常规、边界与红线用途分层 Golden Set 并校准裁判。提交Golden Set 分层表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: Golden Set 分层表
- **图解类型**: golden-set-layers
- **关系语义**: 三层按覆盖对象分层组织并共同形成防线；层与层并非先后步骤，任一层的缺口都需单独修复。
- **核心概念**: 常规样本 · 边界样本 · 红线样本

![第 22 章Golden Set 分层表教学图](/learning/diagrams/zh/chapter-22.svg)

分层检查Golden Set 分层表的覆盖对象与证据，不把视觉高度误读为流程顺序。

图将Golden Set 分层表画成三个叠放层面，分别表示“常规样本”“边界样本”“红线样本”。叠放用于区分覆盖对象并呈现共同防线，不表示执行先后或成熟度；每一层都必须有自己的检查方法和证据。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 22.1 标注集建设：golden set 是活资产，不是一次性作业

第 21 章结束时你有了一张 10 个用例的表和一段可重跑的脚本。这个最小可行 eval 解决了"有没有数字"的问题，但很快会撞到两堵墙：第一，10 个用例覆盖不了客户业务的真实分布——大类挤在一起、长尾类别一条没有；第二，每次迭代都人工判分，用例一过五十条，判分时间就开始吃掉迭代时间。本章解决这两堵墙：前者靠把评估集系统性地做大做准——建成所谓 golden set（黄金标注集）；后者靠 22.2 节的 LLM-as-judge。

用例从哪来，决定 eval 准不准。黄金标注集可以结合生产代表性样本、历史失败和专家构造或合成样本。下面先介绍两类真实来源；缺少客户日志的学习者可用明确标注的合成材料练习，但不能据此推断生产表现：

- 客户真实案例：生产日志里的真实输入、客户业务方提供的典型案例、用户原话与真实文档片段。第 21 章已经强调过"不要自己编理想输入"，这里再进一步：真实案例的收集要有分布意识——按业务类别的真实占比采样，而不是按"好找的程度"凑数。工单分类场景里，如果"退款类"占生产流量的 40%，标注集里它却只有 5%，通过率再高也不能外推到生产。
- 失败案例：上线前测试暴露的错例、生产事故、用户投诉、客户 review 时圈出的不满意回答。失败案例是标注集里密度最高的资产——一条曾经真实发生过的失败，比十条随手编的常规用例更能防住未来的退化。每个失败案例入集时要带着"失败模式"标签（幻觉 / 格式错 / 遗漏要点 / 越界推断 / 拒答过度），这个标签在后面分层时直接派上用场。

专家构造与合成样本：用于补足罕见边界、提示注入与教学练习，经人工复核预期与禁止项后入集。逐条记录来源、构造方法、用途及是否用于调参；生产代表性样本与定向风险样本分别报告，不能用合成通过率代替生产指标。

分层：smoke / 回归 / 对抗，三层各司其职。用例多了以后不能摊成一锅——不同场景需要不同的评估深度，跑全量既慢又贵。本章采用三层教学组织方式：

| 层 | 规模量级 | 内容 | 跑的时机 | 通过标准 |
|------|----------|------|----------|----------|
| smoke 层 | 10–30 条 | 第 21 章那张 10 用例表的直接延续：每类 1–2 条核心用例 + 最重要的历史失败 | 每次改动后必跑——改提示词、换模型、调上下文，先过这一关 | 全对才继续，错了立刻停下排查 |
| 回归层 | 全量（几百条量级） | 按真实业务分布采样的代表性用例 + 全部已回流的历史失败 | 发布前、模型升级前、重要方案变更前 | 通过率不低于基线，且分类别通过率无塌方 |
| 对抗层 | 几十条 | 按失败模式定向构造：提示注入样本、歧义输入、超出知识边界的问题、诱导编造的提问 | 安全相关变更时、定期红队演练 | 禁止项零容忍，一类失守即整层亮红 |

计数时先去重：smoke 是回归的子集，不另加一次；对抗层与本章回归层分开计数，保留跨层关联标签。smoke 层的价值在速度——五分钟内告诉你"能不能继续"；回归层的价值在置信度——给客户看的那个通过率数字从这层来；对抗层的价值在区分度——它专门存放"模型最可能栽的地方"，可以在探索性红队池中保留尚未解决的红灯，但该池必须与发布门禁集分开。进入发布门禁的禁止项失败零容忍：先阻断发布；若已影响生产，则按严重性撤回或回滚，再修复并重测失败类别与受影响回归层。第 39 章的客户案例里，标注集从最初的 10 个用例长到 120 条，靠的正是这套生长机制，而不是某次突击标注。

维护节奏：标注集是活资产。这是本节最容易被忽视的一条。评估集不会自己保持健康，它有两种典型的腐化方式：

1. 只进不出、长期绿灯。用例越堆越多，但全部是模型早就学会的简单题——通过率常年 100%，看着体面，实际上 eval 已经失去区分度，退化成了摆设。对策是定期审计：每季度（或每个大版本前）统计分层通过率，把"连续 N 个版本全对且无区分度"的用例降级或归档，同时检查各业务类别的覆盖占比是否仍然贴近生产分布。
2. 失败不回流。生产上暴露的每一个 bad case 都是免费送上门的高价值用例，但很多团队的流程里没有"失败 → 入集"这一步，事故修完就翻篇。对策是把回流写成机制而非自觉：任何一次生产修复的完成定义（definition of done）里加一条——"该失败已转为回归层用例并跑通"。第 21 章起步误区里的第三条"一次写完不再更新"，放到几百条的尺度上就是这条。

一句话总结本节：golden set 的"golden"不在于用例多，而在于每条用例来源明确、预期经过复核且用途与覆盖清楚、并且持续新陈代谢。它和测试电网（第 25 章）是对偶的两套资产——那套守住代码回归，这套守住模型回归；那套的燃料是 bug 修复，这套的燃料是失败案例回流。

### 22.2 LLM-as-judge：让模型评卷，但先认清它的偏差

回归层几百条用例、每次发布都跑，人工判分撑不住。出路是把"评卷"这件事本身交给模型——用一个 LLM 按你写的评分标准（rubric）给另一个 LLM 的输出打分，这就是 LLM-as-judge。它把判分成本从"人分钟"降到"模型秒"，让回归评估可以高频重跑。但 judge 不是免费午餐：它是一个模型，就有模型的毛病。用它的正确姿势是先设计好评分维度与 rubric，再认清它的已知偏差并逐一校准——顺序不能反。

评分维度设计。第 21 章的五个质量维度里，格式遵循、成本、延迟可以用确定性工具量（schema 校验、token 计数、计时），不需要 judge；judge 只负责语义维度的评卷，通常是：

- 要点覆盖：输出是否覆盖了期望要点（对回归层的每条用例，要点已在标注时写好）；
- 禁止项检查：是否出现编造、越界推断、泄露不该泄露的内容；
- 整体质量：无明确清单时的分档评分，如"合格 / 边界 / 不合格"。

维度要拆开评、分开报，不要让 judge 给一个笼统的总分——总分把"覆盖全但编造了一条"和"全真实但漏了两个要点"混在一起，回归时你看不出退化在哪。禁止项永远单列，且判定权重高于要点覆盖。

rubric 写法。rubric 是给 judge 的评卷标准，写得是否"可判定"直接决定 judge 的稳定性。四条要领：

1. 每档给可观察的行为描述，不给形容词。"2 分：明确指出无法判断并列出缺失信息；1 分：给出结论但未声明依据不足；0 分：在信息不足时仍给出确定性结论"——可判定。"1 分：回答基本合理"——不可判定，judge 每次打的分会漂。
2. 分档少而陡。本章先用三档（0/1/2）练习。档位数量应按任务区分需求和人机校准结果选择；评卷要的是稳定区分"能用 / 不能用"，不是精确到小数的美感。
3. 塞校准例。rubric 里附 1–2 个已标注的示例输出及其得分与理由（few-shot），让 judge 对齐你的尺度。校准例是否有帮助需用独立样本验证。
4. 要求先引证据再给分。让 judge 先引用输出中的原文片段对应到各要点，再给分——强制它走"证据 → 结论"的路径，便于检查判分依据，但不保证依据真实或分数正确。

judge 的已知偏差与校准。[Zheng 等人的研究](https://arxiv.org/abs/2306.05685)讨论了 LLM-as-judge 的位置、冗长和自我偏好等偏差。下表把这些风险转成待验证的工程防御；不同任务、模型与 rubric 下的效果需要本地校准：

| 偏差 | 表现 | 校准方法 |
|------|------|----------|
| 位置偏差（position bias） | 成对比较 A/B 时，judge 系统性偏向出现在前面的那个答案 | 双向评估：A 在前评一次，B 在前再评一次，两次结论不一致记为平局 |
| 自我偏好（self-preference） | judge 偏爱与自己同源的模型（同一家族、文风相近）的输出 | 选与被评模型不同源的模型做 judge；或双judge交叉并独立校准一致样本，保留人工复核 |
| 长度偏好（verbosity bias） | 更长的回答被判更优，即使信息量没有增加 | rubric 中显式声明"长度不作为质量依据；冗长且无新信息应降档"；对比时长度归一化 |

本章提供两条待验证的工程防御：

- 人机抽检对齐。定期（每次 judge 配置变更后，以及每季度）从 judge 判过的结果里分层抽样——重点抽"judge 判合格的低分疑点"和"judge 判不合格的边界例"——让人复判，计算人机一致率。一致率不达标（本章教学示例暂设 90%，项目应按风险另行确定）就回头改 rubric 或换 judge 模型，而不是直接上线信任。抽检还有一个隐性收益：人的时间被集中到最有信息量的争议样本上，而不是平均撒在几百条上。
- 双 judge 交叉。两个不同源的 judge 各评一遍，一致仅作为待校准的辅助信号，不能证明真实正确；两个模型可能共享错误。分歧样本进人工通道，一致样本仍需按风险抽检，禁止项与关键业务决定须核对可信标签和证据。是否采用双judge，应依据独立校准与实际成本决定。

最后一条纪律：judge 的配置也要版本化、也进回归。换 judge 模型、改 rubric 都会让历史分数失去可比性——这和"换被评模型要重跑全量"是同一条道理。judge 不是标准本身，rubric + 校准机制才是；judge 只是执行者。



反例：两位裁判都认可一个包含虚构来源的回答，仍应根据可信资料判为失败。模型一致不能豁免禁止项，也不能替代标签仲裁。

### 22.3 人机协作标注流程：AI 预标注，人做仲裁

回归层长到几百条，标注本身也成了体力活。每条用例要写期望要点、禁止项、通过标准，纯手工写一个月也凑不齐；纯 AI 写，质量又不可信。答案是人机协作流水线：AI 做预标注，人做复核与仲裁，争议例回流成最高价值的资产。

<!-- code-example:chapter-22-E1 mode:pseudocode -->
> **示例类型：伪代码。** 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。
```text
候选收集          AI 预标注            人工复核             仲裁              回流
─────────        ─────────           ─────────           ─────────        ─────────
生产日志   →   生成期望要点草稿  →   高置信样本快速通过  →   争议例由资深     →   定稿入 golden set
失败案例       生成禁止项建议        （抽 10% 复查）       成员给最终判定      （带争议标记）
边界样本       给出建议通过标准                          + 修订 rubric      对抗层优先收录
                    ↑                                          │
                    └────────── 仲裁结论反哺预标注模板  ←──────┘
```

各环节的分工与要点：

| 环节 | 执行者 | 职责 | 关键纪律 |
|------|--------|------|----------|
| 候选收集 | 机制 | 从生产日志、失败案例、边界样本持续汇入候选池 | 保留来源信息（哪次事故、哪类投诉）随用例入库 |
| AI 预标注 | 模型 | 生成期望要点、禁止项、通过标准草稿 | 预标注是草稿不是答案；提示里带上同类已定稿用例做示例 |
| 人工复核 | 人 | 复核预标注；高置信样本走快速通道，重点看边界 | 抽检快速通道的 10%，防止"快速"滑成"放行" |
| 仲裁 | 资深成员 | 对复核阶段的争议例给最终判定，并回写判定理由 | 判定理由比判定结论更重要——它就是活着的 rubric |
| 回流 | 机制 | 定稿用例入集；被仲裁修订过的条目打上争议标记 | 争议例是对抗层的首选原料 |

这套流程的核心不是"用 AI 省人力"，而是把昂贵的人脑时间精准投放在信息量最大的地方。预标注把每条用例的人工成本从"从零写"降到"改几处"；复核的快速通道让多数常规样本一分钟过掉；而仲裁环节——那些"到底算不算幻觉""这个要点是必须还是最好"的争论——恰恰是把团队对质量标准的隐含理解逐步显式化的过程。每一条带判定理由的仲裁记录，都在让 rubric 更可判定、让下一次预标注更准、让 judge 的校准例更丰富。

实践中两个常见的失效模式值得点名：一是复核形同虚设——预标注质量一高，复核的人就开始无脑点确认，快速通道比例从 70% 涨到 98%，本章10%抽检是教学选择，项目须依据风险确定抽检量与收紧条件，抽检出问题要把快速通道收紧；二是仲裁结论不落盘——资深成员口头拍板、用例改完就走，下次同类争议重新吵一遍。对策是仲裁必须留下书面判定理由并沉淀进预标注模板，让同一个问题只仲裁一次。

到此，评估体系的两块基建就位了：一块是持续生长的 golden set（22.1），一块是需持续校准并接受人工复核的自动评卷（22.2、22.3）。下一章把它们接入迭代流程——prompt、模型、方案变更时如何跑回归、如何锁定基线、如何把 eval 嵌进六步工作法的验收环节。

【自检清单】golden set 与 judge 健康度自查

- [ ] 我的用例是否逐条标明真实、历史失败或合成来源及用途？如用于生产判断，代表性样本分布是否经过核验？
- [ ] smoke / 回归 / 对抗三层是否分层存在，各自的触发时机与通过标准是否显式写下？
- [ ] 生产修复的完成定义里，是否包含"失败案例已回流为回归层用例"？
- [ ] 最近一个季度有没有做过标注集审计——还有区分度吗？分布还准吗？
- [ ] judge 的 rubric 每一档是可观察的行为描述吗？有没有附校准例？
- [ ] 位置偏差、自我偏好、长度偏好，我的 judge 流程分别用了什么手段压制？
- [ ] judge 与人工的一致率最近一次抽检是多少？judge 配置变更后重跑过对齐吗？
- [ ] 人工复核的快速通道占比是多少？最近一次 10% 抽检结果如何？
- [ ] 仲裁的判定理由是否书面落盘并反哺了预标注模板？

### 【练习】把 10 用例表升级成一个 60 条的分层标注集

题目：没有获准使用客户日志时，用标明教学分布假设的合成材料完成练习，报告只作教学分析，不证明生产表现；有获授权的真实材料时核验其分布。延续第 21 章练习的 eval 用例表，把它扩到 60 条去重用例：回归层 50 条（包含 smoke 的 15 条，即另有 35 条回归用例），另加对抗层 10 条；回归层按业务类别真实分布采样，对抗层至少覆盖三种失败模式。然后用 LLM-as-judge 评一遍回归层：写出三档 rubric（附一个校准例），与你自己的人工判分对比，报告一致率和分歧样本的分歧原因。

引导：重点体验两个落差。①采样落差：按真实分布构建含 15 条 smoke 的 50 条回归用例时，你会发现某些长尾类别在生产日志里本身就难找——这正是"分布意识"的价值，也是该不该放宽采样规则的决策点。②judge 落差：对比人机判分时，分歧样本几乎一定集中在边界例上——逐条看分歧原因，你会同时发现 rubric 写得不够可判定的地方和 judge 的具体偏差类型，这两个发现分别对应 22.2 节的两条改进线。

参考方向（供讲师参考）：评阅主要看四点。三层配比与触发时机是否显式；回归层分布是否真的对齐生产（抽查各类别数量占比即可）；rubric 是否可判定（抽一档问"什么样的输出会落在这档"，答不出即不合格）；一致率报告是否分析了分歧原因而不只报数字。常见反例是 judge 一致率 95% 就宣布成功——若抽检样本里边界例占比为零，这个数字没有意义；应要求对对抗层单独报告一致率。

---

> 本章业界事实的来源说明：评估数据可结合合成、人工整理、生产与历史来源，参见[OpenAI评估实践指南](https://developers.openai.com/api/docs/guides/evaluation-best-practices)。LLM-as-judge 偏差的可定位研究见 [Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena](https://arxiv.org/abs/2306.05685)。位置交换、双 judge 与人工抽检在此作为待验证的工程防御，不保证消除偏差。本章关于标注集分层、来源分布意识、维护节奏与人机协作标注流程的内容，为通用工程方法论的展开，不归属特定公司的内部实践。本章未引入研究中的数值结论；未标明来源的案例、数量、90% 一致率、10% 抽检比例与维护频率均为教学假设，不是实测结果或行业基准，使用前须按项目风险和校准证据确定。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-22.md`，写上版本、决定、证据和缺项。

为八个样本标记来源、类别与是否曾用于调参。拟定模型裁判规则，加入顺序偏差检查和三条人工复核条件。

<!-- chapter-artifact-requirement -->
### 本章必交产物：Golden Set 分层表

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: Golden Set 分层表分别定义“常规样本”“边界样本”和“红线样本”的覆盖对象
- O2: Golden Set 分层表为三个层面各写出检查方法、责任人和通过证据
- O3: 产物分别记录三类样本的来源、用途、标准和人工复核条件

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

保留独立验收集，不把调参样本当最终证明。裁判需固定版本和rubric，交换答案位置测试偏差，抽样人工校准；红线、裁判分歧和边界输出人工复核。两个模型一致不等于真实正确，业务负责人应确认标签歧义。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；Golden Set 分层表、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [建立成功标准与评估](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) — Anthropic, 2026-09-17. 评估应从可观察成功标准、用例和版本化证据开始。
- [OpenAI 评估最佳实践](https://developers.openai.com/api/docs/guides/evaluation-best-practices) — OpenAI, 2026-09-17. 评估数据可结合生产、历史、人工整理和合成来源，并应覆盖典型、边界和对抗案例。
- [MT-Bench 与 Chatbot Arena 的 LLM-as-a-Judge 研究](https://arxiv.org/abs/2306.05685) — arXiv, 2026-09-17. 论文讨论了 LLM 裁判的位置、冗长和自我偏好等偏差。