数据生成质量评估
LLM Evaluation 与反馈闭环 讲的是评模型输出；这一篇讲另一个问题：用模型生成训练数据时，怎么知道生成的数据够不够好。
这个问题在合成数据成为常规手段之后变得关键（见 06-缩放法则 里的数据墙）——人类文本买不到了，合成数据成了缩放杠杆，但合成数据的质量没人替你保证。
三种互补的方法
| 方法 | 形式 | 评什么 |
|---|---|---|
| LLM Judge | 多维度绝对打分 | 生成数据的质量 |
| Win Rate | 与人类真题成对对比 | 生成数据与真题的差距 |
| 人工验证 | 专家逐条核对 | 答案的正确性 |
分工是刻意的：前两种自动化方法评题目生成质量，人工评答案生成质量。理由是数学题这类内容需要严格逻辑推理，答案的准确性不能只靠模型自己判。
为什么三种都要有：绝对打分告诉你「够不够格」，相对对比告诉你「差多远」，人工告诉你「有没有错」。三个问题不一样，一个指标答不了三个问题。
三种方法各自回答一个不同的问题，缺一个就漏一类问题。
┌──────────────────────────────────────────────────────────┐
│ LLM Judge 多维度绝对打分 │
│ 评什么：生成数据的质量 │
│ 回答的问题：够不够格 │
└──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│ Win Rate 与人类真题成对对比 │
│ 评什么：生成数据与真题的差距 │
│ 回答的问题：差多远 │
└──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│ 人工验证 专家逐条核对 │
│ 评什么：答案的正确性 │
│ 回答的问题：有没有错 │
└──────────────────────────────────────────────────────────┘
分工是刻意的
前两种自动化方法评「题目生成质量」，人工评「答案生成质量」。
└─ 数学题这类内容需要严格逻辑推理，
答案的准确性不能只靠模型自己判
三个问题不一样，一个指标答不了三个问题。
落在链路上的位置
数据生成 ──▶【题目质量：LLM Judge + Win Rate】──▶
【答案质量：人工验证】──▶ 可用数据集LLM Judge：多维度打分 + 三个汇总指标
LLM Judge 从四个维度评估生成的题目（每个维度 1–5 分），然后汇总成三个指标：
一、平均分（Average Score） —— 整体水平：
二、及格率（Pass Rate） —— 基本质量保障，平均分 ≥ 3.5 的占比：
三、优秀率（Excellent Rate） —— 高质量产出能力，平均分 ≥ 4.5 的占比：
为什么要三个而不是一个：
平均分给出整体水平，及格率保证基本质量，优秀率衡量高质量产出能力。 一个「平均分 3.6、及格率 90%、优秀率 5%」的系统和一个「平均分 3.6、及格率 60%、优秀率 30%」的系统，均值相同但质量分布完全不同——只看平均分会把这两种情况混为一谈。
这和 那篇里「聚合指标会骗人」是同一条教训：分位数与分布形状必须一起看。
四个维度各打 1–5 分，汇总成三个指标。
平均分 整体水平
及格率 平均分 ≥ 3.5 的占比 —— 基本质量保障
优秀率 平均分 ≥ 4.5 的占比 —— 高质量产出能力
为什么要三个而不是一个
同一个平均分底下可以是完全不同的分布：
系统 A 平均分 3.6 及格率 90% 优秀率 5%
系统 B 平均分 3.6 及格率 60% 优秀率 30%
└─ 均值相同，质量分布完全不同 ——
只看平均分会把这两种情况混为一谈
这和 LLM Evaluation 里「聚合指标会骗人」是同一条教训：
分位数与分布形状必须一起看。
这里多一条特殊的风险
如果生成数据的模型和当 judge 的模型同源，
那评的是「像我生成的东西」，而不是「好题目」——
这是自我偏好在数据生成场景下的具体形态，
比在评测场景下更危险，因为它的产物会进入下一轮训练。用 LLM Judge 就绕不开偏差
任何 LLM Judge 都带着那六种已被量化的偏差（位置 / 长度 / 风格 / 自我偏好 / 对冲 / 具体性幻觉），缓解手段是位置交换、CoT、结构化 rubric、跨家族 judge —— 详见 LLM Evaluation 与反馈闭环。
这里多一条特殊的风险：如果生成数据的模型和当 judge 的模型同源，那评的是「像我生成的东西」而不是「好题目」——这是自我偏好在数据生成场景下的具体形态，比在评测场景下更危险，因为它的产物会进入下一轮训练。
Win Rate：用「接近 50%」当目标
设计动机：绝对评分能说清质量高低，但说不清离人类真题还差多远。Win Rate 用成对对比补这一块。
相对比较比绝对评分更符合人类的判断习惯——这一点在 LLM Evaluation 里也出现过：「LLM 在区分选项上比生成绝对分数更强」。
每次比较有三种结果，对应三个指标：
三者之和恒为 100% —— 所以单独报一个没有意义，三个必须一起报。
理想值是 50%，而且两个方向都有话说
理想结果：Win Rate ≈ 50%（说明生成质量接近真题）。
- 显著低于 50% → 生成题目质量不如真题，需要优化生成策略
- 显著高于 50% → 可能真的是更好，也可能只是评估标准有偏差
「显著高于 50% 要怀疑自己」这一条值得单独记。 一个自动化评测系统报出「我的合成数据比人类真题好」时，更可能的解释是评测本身有问题——比如 judge 偏好生成长度/风格（那六种偏差里的长度偏差和风格偏差正好都会朝这个方向偏）。
判据可以写成一句：评测的上限是评测本身的可信度。 一个没有校准过的 judge 给出的「超越人类」结论，不构成证据。
Win Rate 用「接近 50%」当目标，两个方向都有话说。
每次比较有三种结果，三者之和恒为 100%
Win Rate = Wins / Total
Loss Rate = Losses / Total
Tie Rate = Ties / Total
└─ 所以单独报一个没有意义，三个必须一起报
┌── 显著低于 50%
│ └─ 生成题目质量不如真题，需要优化生成策略
理想值 50% ─────┤
（接近真题） └── 显著高于 50%
└─ 可能真的是更好，
也可能只是评估标准有偏差
「显著高于 50% 要怀疑自己」这一条值得单独记
一个自动化评测系统报出「我的合成数据比人类真题好」时，
更可能的解释是评测本身有问题 ——
比如 judge 偏好生成长度与风格
（那六种偏差里的长度偏差和风格偏差正好都会朝这个方向偏）。
判据可以写成一句：评测的上限是评测本身的可信度。
一个没有校准过的 judge 给出的「超越人类」结论，不构成证据。
设计动机：绝对评分能说清质量高低，但说不清离人类真题还差多远。
Win Rate 用成对对比补这一块 ——
相对比较比绝对评分更符合人类的判断习惯。人工验证：不能省的那一环
为什么不能全自动：数学题需要严格逻辑推理，人工要验证答案的准确性、解答步骤的完整性、数学推理的严密性。而且自动化评估会遗漏主观因素——题目的创新性、趣味性这类东西，模型判不出来。
流程：读题目/答案/解答 → 按四个维度打分（1–5）→ 标注状态 → 加评论。
状态用三值而不是二值：
| 状态 | 含义 |
|---|---|
approved | 通过 |
rejected | 拒绝 |
needs_revision | 需修改 |
needs_revision 这个中间态是关键——只有通过/拒绝两值时，标注者面对「方向对但细节要改」的样本只能二选一，要么放过瑕疵、要么丢掉可用的数据。三值把这类样本识别出来，让它们能回到生成环节重做而不是直接废弃。
工程细节：人工验证通常要配一个 Web 界面（书里用的是 Gradio），让验证者能浏览、评分、标注、评论。这不是锦上添花——它直接决定了人工环节的吞吐量，而人工环节是整条链路的瓶颈。
这套方法落在哪里
整条链路上的位置：
数据生成 → 【题目质量：LLM Judge + Win Rate】→ 【答案质量：人工验证】→ 可用数据集三个阶段各自解决一个不同的问题（够不够格 / 差多远 / 有没有错），缺任何一个都会漏掉一类问题：
| 只做 | 会漏掉 |
|---|---|
| 只做 LLM Judge | 不知道离人类水平有多远，也不知道答案对不对 |
| 只做 Win Rate | 不知道绝对质量分布——胜率 50% 既可能是「两边都好」，也可能是「两边都差」，成对对比给不出这个信息 |
| 只做人工 | 吞吐量撑不住规模，而且人力成本随数据量线性增长 |
相关
- LLM Evaluation 与反馈闭环 —— judge 的六种偏差、校准流程、聚合指标会骗人
- 06-缩放法则 —— 数据墙与合成数据成为缩放杠杆的背景
- AI 生成代码的质量保障 —— 同一条「生成很快、验证很慢」的张力的另一处表现
参考
- 《Hello-Agents》第十二章 §12.4
- 见 LLM Evaluation 与反馈闭环 及其参考
YJ