模型当裁判 LLM-as-a-Judge
所属：01-fundamentals / 05-agent-evaluation
面试权重：★★★
来源：通用领域知识；未做一手考证
相关项目：Own — HKGAI LLM（评测侧，见过人工标注的代价）、QueWI（生成质量需要离线评测）→ 见02-interview/projects/hkgai-llm.md
一句话#
LLM-as-a-Judge 是用一个（通常更强的）LLM 给模型输出打分或做两两比较，把「人肉评测」变成可编程、可扩展的自动流程。它不是 ground truth，而是一个有偏置的代理指标 —— 只有当它被人工标注校准过，才有资格当指标用。
为什么重要（面试角度）#
这是评测题的入口题。答「用 GPT-4 打分就行」会立刻暴露评测素养的缺失。面试官想听的是：
- 为什么不用 BLEU / ROUGE / EM —— 以及它们具体在哪里失效
- pairwise 和 pointwise 各自什么时候用，为什么榜上多用 pairwise
- 能点名偏置：position bias、verbosity bias、self-preference，并说出各自的缓解手段
- 最关键的一问：「你怎么知道裁判打得分是对的？」 —— 这题答不上，前面全废
你在 HKGAI 做评测时见过人工标注的开销，这个「用模型替代人工到底靠不靠谱」的张力你有第一手体感，要讲出来。
核心内容#
为什么需要它#
评测的三种手段，成本与覆盖面对比：
| 手段 | 成本 | 可扩展性 | 对开放式生成的有效性 |
|---|---|---|---|
| 人工标注 / 人工偏好 | 极高 | 差（几十到几百条量级就吃力） | 高，但是金标准，也是噪声源（标注者之间本身就不一致） |
| 参考指标（EM / BLEU / ROUGE 等） | 低 | 好 | 差 —— 需要标准答案，且措辞不同就判错，与人类偏好相关性低 |
| LLM-as-a-Judge | 低–中 | 好 | 较好（在多种任务上与人类偏好有可观一致性） |
核心矛盾：开放式生成没有唯一正确答案，所以精确匹配类指标天然不适用；而人工评测的成本与标注者不一致性让它无法支撑高频迭代。LLM judge 是这两者之间的折中。
打分形态：pointwise vs pairwise#
| 维度 | Pointwise（绝对打分 / rubric） | Pairwise（两两比较） |
|---|---|---|
| 输出 | 分数（如 1–5）或 rubric 各项判定 | 「A 更好 / B 更好 / 平局」 |
| 可扩展性 | 好，每条独立，O(n) | 差，两两组合 O(n²) |
| 跨批次可比性 | 差 —— 分数标尺会漂移，不同批次/不同 prompt 的分不可直接比 | 好 —— 只做局部比较，不需要绝对标尺 |
| 稳定性 | 差，裁判对量表锚点敏感 | 相对更稳 |
| 适合场景 | 需要绝对阈值卡门（如「faithfulness ≥ 4 才上线」） | 模型 A/B、版本对比、构造偏好数据 |
| 主要风险 | 分数聚集（都打 4 分）、锚定效应 | position bias；需要聚合（Elo / Bradley-Terry 之类）才能得到全序 |
还有两类常见变体值得知道：
- listwise / ranking：一次给多个候选排序。信息密度高，但裁判对位置和数量的敏感性更强，实际不如 pairwise 稳。
- reference-based vs reference-free：给不给参考答案。给参考能显著提升可靠性（相当于把「对不对」外包给参考答案），但前提是你有 gold answer；reference-free 更通用但更容易被文风带偏。
实用结论：要排行榜/做 A/B → pairwise；要门禁阈值 → pointwise 但要带 rubric 且定期重校准。
偏置：必须能点名的那种#
| 偏置 | 表现 | 缓解 |
|---|---|---|
| Position bias（位置偏置） | 同样两个答案，交换顺序后裁判改判；常见是偏向第一个或最后一个 | 交换顺序各评一次再聚合（要求两次一致才采纳，不一致记平局），或随机化顺序；不要在 prompt 里暗示位置 |
| Verbosity bias（长度偏置） | 倾向给更长的答案更高分，哪怕更长只是啰嗦 | rubric 明确「简洁不加分、冗余要扣分」；控制长度做对照实验；统计裁判打分与长度的相关性 |
| Self-preference / 自偏好 | 裁判偏好自己（或同家族模型）产出的文本 | 裁判模型与生成模型用不同家族；多裁判投票；用人工标注检验是否存在系统性自偏好 |
| Sycophancy / 权威偏置 | 偏向语气自信、有「引用」、有格式的答案 | rubric 强调只评内容正确性；剥离格式变量做对照 |
| Format / 呈现偏置 | 被 markdown、标题、加粗带跑 | 统一格式后再评 |
| 刻度聚集（central tendency） | 大量分数堆在中间档，区分度丢失 | 用 pairwise；或定义清晰的 1/3/5 锚点（few-shot 给打分范例） |
| Distractibility（被无关内容干扰） | 参考文档里的无关段落让裁判改判 | 只在必要时给上下文；context 相关性与 faithfulness 分开评 |
记忆抓手：任何一个 LLM judge 上线前，都应该跑一遍「交换顺序」「长度相关性」「跨家族」这三项体检。
怎么和人工标注校准（最核心的一节）#
裁判的合法性只能来自与人工标注的一致性。流程：
- 建校准集：人工标注一批样本（pairwise 判断或分级评分）。规模没有硬性标准，几十到几百条量级即可给出方向性结论，但任务越难、要区分的差异越小，需要的样本越多。样本要覆盖你关心的难度与类别分布，不要只抽简单样本。
- 选一致性指标：
- pairwise：原始一致率（简单直观，但没扣掉瞎猜的部分）+ Cohen's kappa（扣掉随机一致）
- 分级评分：Spearman / Kendall 秩相关（关注排序而非绝对分数）
- 参考上限：标注者之间的一致性。如果人和人之间也就 70% 一致，那裁判追平这个数字就已经是实用上限了 —— 要求裁判 95% 一致是没意义的。
- 迭代裁判 prompt：加 rubric、加打分锚点范例、要求先写推理再给结论（CoT-then-verdict）、明确允许「平局」。每改一版重跑一致性。
- 报告与门禁：把「裁判 vs 人工一致性」写进评测报告。只有一致性可接受，裁判分才允许用于卡门禁。 阈值（如「分数 ≥ X 算通过」）要按校准结果定，不要拍脑袋。
- 持续维护：
- 裁判模型换版本要重新校准（一致性可能变化）
- 生成模型升级后，评测分布会漂移，校准集要补充
- 保留人工抽检（比如按固定比例抽样复核），防止裁判悄悄漂走
必须能主动说出的边界：
- 裁判在某个任务上被校准过，不代表在别的任务上有效。judge validity 是任务特定的。
- 校准集本身若与被测模型共享数据来源，会带来污染风险。
- 裁判不是 oracle；它是降低标注成本的代理，不是消除标注需求。
工程实践清单#
- 裁判 prompt 要显式：评什么维度、什么是好、允许平局、先推理后裁决。
- 不要给裁判看模型身份（A/B 标签要用中性代号）。
- 多裁判投票 / 集成能提升稳定性，但成本和延迟都上去，按场景取舍。
- 温度设 0，但要知道 LLM 输出仍有非确定性（批处理、内核差异），同一输入可能给出不同判定 —— 方差要纳入考量。
- judge 的调用要进 trace：prompt、原始输出、解析后的分数都要留，否则评测结论无法复现（→ 见
06-agent-infra/observability.md）。 - 解析要健壮：让裁判输出结构化（如 JSON）比自由文本更容易解析，但结构化本身可能诱导裁判，二者要权衡。
常见面试问法#
Q：为什么不用 BLEU / ROUGE 评测生成质量？ A：它们基于 n-gram 重叠，需要参考答案，且假设「措辞相似 = 质量相似」。开放式生成里措辞差异巨大 —— 两个都对但用词不同的答案，重叠度可能很低；反过来，抄了参考答案的 n-gram 但逻辑错误的答案可能得分很高。它们与人类偏好的相关性通常不足以支撑决策。
Q：pointwise 和 pairwise 怎么选？ A：要绝对阈值做门禁 → pointwise（但要 rubric 且定期重校准，因为它有标尺漂移）；要模型/版本对比、做排行榜或造偏好数据 → pairwise（不需要绝对标尺，更稳，但 O(n²) 且要处理位置偏置）。榜上多用 pairwise 就是因为跨批次可比性。
Q：LLM judge 有哪些已知偏置？ A：position bias（交换顺序会改判）、verbosity bias（偏好长答案）、self-preference（偏好自己/同家族的输出）、权威/自信偏置、格式偏置、刻度聚集。缓解分别是换序聚合、长度对照、跨家族裁判、只评内容、统一格式、改用 pairwise。
Q：你怎么证明你的 judge 是可信的？ A：建人工标注的校准集，测裁判与人工的一致率（pairwise 用 raw agreement + kappa；分级用秩相关），并以标注者之间的一致性作为实用上限参照。迭代 prompt 到一致性可接受，报告一致性数字，并保留人工抽检与定期重校准。不声称裁判是 ground truth。
Q：裁判和生成模型是同一个模型，有什么问题？ A：self-preference 会让它系统性偏高评价自己的输出，模型比较结论失真（尤其在比较不同家族模型时）。应使用不同家族的裁判模型，并用人工标注验证是否存在系统性自偏好。
易错点#
- ❌ 说「用 GPT-4 打分就行」—— 没有提校准、偏置、一致性，等于把评测当成免检工具。
- ❌ 把 LLM judge 的分数当 ground truth 汇报，不报告它与人工的一致性。
- ❌ 用同一个模型既生成又评判，还拿它做模型对比结论。
- ❌ 忽略 position bias，只评一次顺序。
- ❌ 用 pointwise 绝对分跨批次比较（标尺漂移会让比较失效）。
- ❌ 以为校准过一次就永久有效 —— 裁判模型换版本、被测模型分布漂移都要重校。
- ❌ 只校准简单样本，到真实难样本上一致性崩掉。
- ❌ 忘记记录 judge 的原始 prompt 与输出，导致结论无法复现。
自测#
1. 面试官问「你说 LLM judge 能用，你怎么证明它打得对？」——给出完整回答。
答案
建一个人工标注的校准集（覆盖目标任务的难度与类别分布），测裁判与人工的一致性：pairwise 用原始一致率 + Cohen's kappa，分级评分用 Spearman/Kendall 秩相关；把标注者之间的一致性当作实用上限参照。迭代裁判 prompt（rubric、打分锚点、CoT-then-verdict、允许平局）直到一致性可接受，然后在报告里公开这个一致性数字，并保留人工抽检。核心立场：裁判是成本更低的代理指标，不是 ground truth；且它的有效性是任务特定的，不能跨任务迁移。
2. 你做了个 A/B：模型新版本在 LLM judge 下胜率 55%，直接上线吗？
答案
不够。① 55% 的差距在几百条样本上通常落在统计噪声内，需要算置信区间（并按任务难度分层看，而不是只看总体）—— 公式、样本量口径与配对检验见 05-statistical-significance.md。② 要排除长度偏置（新版是不是只是更长）和位置偏置（交换顺序后胜率是否翻转）的混淆。③ 要确认这个 judge 在本任务上做过人工校准。④ 还要看分桶结果 —— 总体持平或微升可能掩盖某类请求的严重退化。所以：先补样本量、做换序与长度对照、看分桶，再决定。
3. 为什么 pairwise 比 pointwise 更可靠？它自己的代价是什么？
答案
更靠谱是因为它不需要绝对标尺：只要求裁判在两个候选间做局部判断，避开了「4 分和 5 分的界限在哪」这种量表校准问题，因此跨批次、跨时间可比性好得多。代价：两两组合是 O(n²) 的调用量（n 个模型要评全序时更明显），需要聚合（Elo / Bradley-Terry 之类）才能得到全局排名，且对 position bias 敏感，必须换序或随机化。
4. 裁判在通用对话任务上校准得很好，能直接拿去评代码生成吗？
答案
不能。judge validity 是任务特定的：代码任务的「对不对」依赖可执行性、边界条件、风格规范，与对话任务的评判维度完全不同；同一个裁判在不同任务上和人类的一致性可能差很多。正确做法是在目标任务上重建校准集、重测一致性、重写 rubric。更好的做法是代码类任务尽量用可执行验证（跑测试）而不是裁判打分，裁判只用来评风格、可读性这类无法自动验证的维度。
5. 列出至少四种缓解 LLM judge 偏置的具体做法。
答案
① 换序评估并聚合（消除 position bias）；② 裁判模型与生成模型用不同家族，或用多裁判投票（消除 self-preference）；③ rubric 明确「长度不加分、冗余扣分」并统计打分与长度的相关性（消除 verbosity bias）；④ 统一答案格式、隐藏模型身份后再评（消除格式与品牌偏置）；⑤ 允许并统计「平局」、给出打分锚点范例（缓解刻度聚集）；⑥ 用人工标注做回归抽检、定期重校准（防漂移）。