让一个大模型充当裁判去评估另一个大模型的输出，这条 LLM-as-Judge 路线已经成为大模型能力评测和 AI 应用上线评估的常见替代人工方案。一个强模型对候选回答打分、做对比或排序，相比人类标注有数量级成本优势，但研究反复证实它会复现位置偏差、长度偏差、自我偏好偏差、风格偏差和提示注入脆弱性。生产评估中通常用多模型裁判集成、随机化候选顺序、对抗样本校验来校准。
一、LLM-as-Judge 的工作链路
LLM-as-Judge 思路下的裁判模型，输入是问题 + 一个或多个候选回答 + 评分准则；输出是分数、胜出者或排序。常见三种范式：单点打分（Pointwise）、成对比较（Pairwise）、列表排序（Listwise）。经验上 Pairwise 比 Pointwise 更稳定，因为模型对”哪个更好”的相对判断比对”这个 7 分还是 8 分”的绝对判断要准。
下面是一段可直接复用的裁判 Prompt 骨架：
你是一位严格的评审。请阅读问题与两个候选回答，从
准确性、完整性、清晰度三个维度独立打分（1-10）。
先逐项打分，再输出"更优者 = A/B/平局"，最后给 1-2 句理由。
- 不要因为长度更长就加分；
- 不要因为出现 Markdown 列表就加分；
- 如果两个回答水平接近，必须允许"平局"选项。
问题：{question}
回答 A：{answer_a}
回答 B：{answer_b}骨架里三个反偏差指令是经验上最关键的部分：禁长度、禁格式偏好、强制平局出口。
二、主流偏差类型与缓解手段
裁判模型的偏差不是单点 bug，而是一组系统性问题，评估管线必须显式对抗。下面这张表对照看每种偏差的成因、表现与缓解方式：
| 偏差类型 | 典型表现 | 量化影响 | 缓解手段 |
|---|---|---|---|
| 位置偏差 | 倾向选 A（先出现的候选） | 仅交换 A/B 顺序，分数漂移可达两位数百分比 | 随机化顺序 + 双向评估取均值 |
| 长度偏差 | 越长越好，与质量不相关 | 简单加段套话即可拉高分数 | 在评分准则中明确”简洁优于冗余” |
| 自我偏好 | GPT-4 类裁判偏向 GPT-4 系输出 | 同族模型的胜出率系统性偏高 | 引入异源裁判 + 裁判盲测 |
| 风格偏差 | 偏好 Markdown 列表、emoji、礼貌语气 | 套用模板的回答得分虚高 | 先剥离格式再做内容对比 |
| 提示注入 | 在回答里塞”忽略前文指令”等提示词 | 对决策类裁判攻击成功率可观 | 对候选做净化、用结构化字段而非自由文本 |
上表是经验性总结，数字量级与具体任务的提示工程细节强相关，不要把”两位数百分比”当成通用值。
2.1 位置偏差为什么最难缠
位置偏差无法靠”加一句注意顺序”就消除，因为它来自预训练阶段的序列续写偏好——模型对”先看到的”内容有先验注意力。单一裁判 + 单次评估的方案在 CodeJudgeBench 这类基准上，胜出者仅因顺序调换就发生明显翻转。对抗方法是双向评估：先 A→B 评一次，再 B→A 评一次，取均值或投票。这样位置噪声被抵消，但调用成本翻倍。
2.2 自我偏好的隐蔽性
同族偏好（Self-preference）即使在”已经过指令微调”的裁判上仍然存在。生产上的常见做法是引入至少一个异源裁判（比如主裁判是闭源商用模型，再叠加一个开源模型或不同厂商模型），用异源投票打破同族一致性。开源社区常见的组合是：商用强模型 + 一个开源大模型 + 一个领域专用小模型。
三、评估管线的工程化步骤
把 LLM-as-Judge 真正落到生产评估管线，遵循以下 5 步。每一步都不是可选项，缺一就会让评估结论不可信。
- 抽取样本集：从线上真实流量中分层抽样，覆盖高频、中频、长尾、敏感场景；
- 双轨标注：人类专家标注一份小子集作为黄金集，裁判模型在同子集上跑一遍；
- 计算一致性：用 Cohen’s κ、Spearman 相关、Kendall τ-b 等指标衡量人机一致性；
- 偏差审计：随机化候选顺序、加入同长度对照组、对回答做格式剥离后复评，量化偏差幅度；
- 持续监控：把裁判输出纳入数据看板，跟踪一致性指标和偏差指标随时间漂移。
第 3 步里 Cohen’s κ 是一致性度量里最稳的一个，因为它扣除了随机一致的概率。公式上是 κ = (Po - Pe) / (1 - Pe)，Po 是观测一致率，Pe 是随机一致率。κ > 0.7 通常被认为是”较好”的一致性水平，但具体阈值要看任务复杂度。
四、几类常见裁判方案的对比
| 方案 | 调用成本 | 偏差鲁棒性 | 适用阶段 | 典型实现 |
|---|---|---|---|---|
| 单裁判 Pointwise | 低 | 弱 | 快速冒烟 | GPT-4o 直评 |
| 单裁判 Pairwise | 中 | 中 | 内部回归 | Claude 做对比 |
| 多裁判集成 | 高 | 强 | 上线前评估 | 3 个异源模型投票 |
| 裁判 + 量化回归 | 中高 | 强 | 高价值场景 | LLM 出解释 + 回归器出分 |
| 人机混合 | 最高 | 最强 | 关键决策 | 人类终审 + LLM 预筛 |
多裁判集成在生产评估里几乎是事实标准，因为它对单模型的偏差有”投票稀释”效果。代价是延迟和成本——三个强模型集成对一份千条规模样本进行评估，可能比单模型慢数倍、贵数倍，所以要按业务价值分层使用。
五、落地时的两个易错点
把 LLM 当万能裁判是最常见的误区。代码生成、数学证明这类有客观对错的场景，应该优先用单元测试、形式化校验、可执行用例，而不是让 LLM 评 LLM。LLM-as-Judge 真正擅长的是”质量、风格、相关性、安全性”这类主观维度，强行用在客观任务上只会让评估噪声放大。
另一个坑是把”和人类一致”当成终极目标。生产评估关心的是”能不能稳定区分好坏”，而不是”和某个具体人像不像”。一致性指标是手段不是目的；更值得关注的是排序稳定性——同一组候选，裁判给出的相对顺序在不同时间、不同流量切片下是否保持稳定。
常见问题（FAQ）
Q1：LLM-as-Judge 完全不需要人工吗？
不是。关键决策仍需人机混合，LLM 适合预筛与一致性检查。
Q2：开源小模型能当裁判吗？
可用但需谨慎。小模型偏差更明显，建议仅在点wise 冒烟或与强模型集成时使用。
Q3：如何判断裁判结果是否被提示注入污染？
对候选文本做脱敏与结构化字段化，避免把自由文本直接喂给裁判。
