LLM裁判有偏见？三个校准步骤让评测可信

用 LLM-as-a-Judge 给 AI 功能打分，仪表盘显示质量提升了 12%，你安心上线。结果用户反馈新版本更差。问题往往不在你的应用模型，而在裁判本身——它在测量错误的东西。LLM 裁判有用，但存在可预测的偏见；如果不针对性地设计评测，你的评估体系会悄悄奖励错误答案。

核心原则只有一条：把 LLM 裁判当作生产环境里的另一个模型来对待，信任它之前先测试它。

LLM裁判偏见评测示意图

三类最常见的裁判偏见

MT-Bench / Chatbot Arena 论文（Zheng et al., 2023）发现，GPT-4 这类强裁判与人类偏好的一致率可超过 80%，大致相当于人类彼此之间的一致水平。同一篇论文也记录了失效模式：

位置偏见：成对比较时，裁判倾向于偏爱某个位置上的答案，通常是第一个。Wang et al. 的研究表明，仅仅交换候选答案的顺序就能翻转排名。
冗长偏见：更长、看起来更详细的答案会得到更高评分，即使它并不更正确。
自我偏好：模型倾向于给自己的输出（或风格相似的输出）打高分。Panickssery et al. 发现 LLM 评估器能识别自己的生成内容并予以偏爱。

这些发现并不意味着"不要用 LLM 裁判"，而是说默认配置——"这里有两个答案，哪个更好？"——还不能算一个合格的评测。

MT-Bench（Multi-Turn Benchmark）是 Zheng et al. 在 2023 年提出的多轮对话评测基准，包含 80 个多轮问题和 160 个单轮问题，覆盖写作、角色扮演、推理、编码等八个类别。Chatbot Arena 则是一个众包对战平台，用户对两个匿名模型的回答进行投票，累积超过百万次人类偏好数据。该论文利用这些数据验证了 GPT-4 作为裁判与人类偏好的一致率，并系统性地识别了位置偏见、冗长偏见和自我偏好等失效模式，为后续 LLM-as-a-Judge 研究奠定了基础。

修复一：交换顺序，裁判两次

针对成对比较，把候选答案交换位置后让裁判跑两遍。只有两种顺序下结论一致时才计为胜出；不一致就视为平局，或者交给人工处理。

from openai import OpenAI

client = OpenAI()

JUDGE_PROMPT = """You are grading two answers to the same question.
Question: {question}
Answer 1: {a}
Answer 2: {b}
Which answer is more correct and more helpful? Ignore length.
Reply with exactly one token: 1, 2, or TIE."""

def judge_once(question, a, b, model="gpt-4o-mini"):
    r = client.chat.completions.create(
        model=model,
        temperature=0,
        messages=[{"role": "user", "content": JUDGE_PROMPT.format(question=question, a=a, b=b)}],
    )
    return r.choices[0].message.content.strip()

def judge_pair(question, old, new):
    first = judge_once(question, old, new)   # old in slot 1
    second = judge_once(question, new, old)  # new in slot 1
    if first == "2" and second == "1":
        return "new"
    if first == "1" and second == "2":
        return "old"
    return "tie"  # 顺序一变裁判就改主意了

额外追踪"因分歧产生的平局"比例。如果这个比例很高，说明裁判主要在对位置做出反应，它此前给出的分数参考价值有限。

修复二：按书面评分标准判定通过/失败，先写理由

1 到 10 的分数看起来很精确，但裁判（以及人类）对 6 分和 7 分的界限并不一致。Hamel Husain 的 LLM 裁判指南建议改用二元的通过/失败判定，并附带书面评语，评分标准由领域专家共同定义。

评分标准本身也能对抗冗长偏见，因为裁判检查的是具体条目而非整体印象：

RUBRIC = """Grade the answer to the customer's question.
PASS only if ALL are true:
- It states the correct refund window from the policy below.
- It does not promise anything the policy does not allow.
- It answers in under 120 words.
Policy: {policy}
Question: {question}
Answer: {answer}

First write one sentence of reasoning. Then on a new line write PASS or FAIL."""

要求裁判在给出结论前先写一句简短理由，还能在你调试裁判时提供可读的线索。

修复三：用人工标注衡量裁判

这是大多数团队会跳过的一步。在让裁判决定发布之前：

取 50 到 100 个真实样本。
让一位懂业务的人为每个样本标注 PASS 或 FAIL。
在同一批样本上运行裁判。
对比结果。

from sklearn.metrics import cohen_kappa_score, confusion_matrix

human = ["PASS", "FAIL", "PASS", ...]   # 专家标注
judge = ["PASS", "PASS", "PASS", ...]   # 裁判判定

print(confusion_matrix(human, judge, labels=["PASS", "FAIL"]))
print("kappa:", cohen_kappa_score(human, judge))

要看混淆矩阵，而不是只看一个数字。如果 90% 的样本本来就是好答案，一个全部判通过的裁判也能显示"90% 准确"。真正重要的是它能否抓住失败样本。逐条阅读每一处分歧，收紧评分标准，重新运行，直到它在关键案例上值得信任。

Eugene Yan 对 LLM 评估器研究的综述值得一读：裁判在某些任务上表现好，在另一些任务上表现差，要判断你的任务属于哪种，唯一的办法就是实测。

Cohen's kappa 是衡量两个标注者之间一致性的统计量，它校正了随机一致的概率。计算公式为 (\kappa = (p_o - p_e) / (1 - p_e))，其中 (p_o) 是观察到的致性，(p_e) 是期望的随机一致性。kappa 值通常解释为：低于 0 表示不如随机，0-0.20 轻微，0.21-0.40 一般，0.41-0.60 中等，0.61-0.80 高度一致，0.81-1.00 几乎完全一致。在 LLM 裁判场景中，kappa 能揭示准确率掩盖的偏差——例如裁判全部判 PASS 时准确率可能很高，但 kappa 会接近 0，提示裁判没有区分能力。

几个额外的好习惯

让裁判使用不同的模型家族，尽量不要与生成答案的模型同源，以降低自我偏好。
固定裁判的模型版本和温度。悄悄变化的裁判就是一把移动的尺子。
每次修改裁判提示词或裁判模型后重新检查一致率，就像重构代码后要重跑测试一样。
在每次评测中保留几个已知的坏样本。如果裁判让它们通过了，这次评测就是无效的。

要点回顾

LLM 裁判是一个对质量做预测的模型。给它清晰的评分标准，消除顺序、长度、自我偏好这些容易处理的偏见，并在它决定什么能上线之前，用人工标注衡量它的表现。

最后留一个问题给你的团队：你们现在用的是成对比较、1 到 10 打分，还是通过/失败判定？换一种方式重新校准，可能会发现此前被掩盖的真实质量变化。

参考资料

Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (2023)
Wang et al., Large Language Models are not Fair Evaluators (2023)
Panickssery et al., LLM Evaluators Recognize and Favor Their Own Generations (2024)
Hamel Husain, Using LLM-as-a-Judge For Evaluation: A Complete Guide
Eugene Yan, Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge)
scikit-learn, cohen_kappa_score