第8讲：LLM as Judge

为什么要用 LLM 当裁判

评估大语言模型的输出已成为 NLP 领域最难的工程问题之一。一方面，BLEU、ROUGE、BERTScore 这类基于表层匹配的指标在开放式生成、对话、代码、推理等任务上几乎完全失灵；另一方面，人工评估虽精细却成本高、周期长、难以规模化——每迭代一版模型就重新众包打分，既贵又慢。LLM-as-a-Judge（大模型即裁判）范式正是在这条鸿沟中生长出来的折中方案：用一个能力足够强的 LLM（如 GPT-4、Claude、Qwen3-Max）去评判另一个模型的输出。Zheng 等人（NeurIPS 2023）在 MT-Bench 上的开创性工作表明，GPT-4 裁判与人类偏好的一致率可以超过 80%，与人类标注者之间的一致率相当。自此，LLM-as-Judge 从"边角应急工具"跃升为模型开发生命周期中的基础设施——用于 RLHF 偏好采集、RAG 答案质量监控、线上 A/B 对比、排行榜维护（MT-Bench、AlpacaEval、Arena-Hard）。

但 Judge 范式并不是万能灵药。它继承了 LLM 本身的所有弱点：位置偏差（偏好首项）、冗长偏差（长即好）、自偏爱（偏袒同家族模型）、格式偏差（偏好项目符号与标题）、以及偏好泄露（训练-评估循环污染）。更糟的是，Judge 在高风险场景（安全、医疗、法律）中可能被对抗样本操纵。因此，会用 Judge 和 会搭 Judge 是两件不同的事：前者是把一个 prompt 调通就能跑，后者需要理解范式选择、rubric 设计、结构化输出、偏差诊断、与人类标注的相关性分析。本讲把这条链路拆开讲清楚。

学习目标

完成本讲后，你将能够：

1. 理解 LLM-as-Judge 的动机：自动化、可扩展、与人类偏好相关但更便宜
2. 区分 单点评分（pointwise）、成对比较（pairwise）、列表排序（listwise）三类 Judge 范式，判断何时用哪一种
3. 设计 Judge 的 Prompt：包含 rubric、few-shot 示例、结构化输出、chain-of-judges
4. 识别 Judge 的典型偏差：位置偏差、冗长偏差、自偏爱、格式偏差，并掌握缓解手段
5. 对齐 Judge 与人类偏好：使用 Pearson/Spearman/Kendall 相关系数衡量
6. 独立交付 为某一任务族（翻译/摘要/代码审阅）搭建可复用的 Judge 基线

学时分配

课程内容

关键词

LLM-as-Judge · Pointwise · Pairwise · Listwise · Rubric · Position Bias · Verbosity Bias · Self-Preference · MT-Bench · AlpacaEval · Arena-Hard · Prometheus · JudgeLM