【智能体测评-05】LLM-as-Judge的可靠性问题：让模型当裁判到底靠不靠谱

为什么需要 LLM-as-Judge

在讲“靠不靠谱”之前，先说清楚为什么我们需要它。

Agent 任务的评分可以分成三类：

第一类：有客观对错的。 代码能不能通过测试、API 调用参数对不对、最终状态是否符合预期。这类用规则或测试用例判分，SWE-bench 和 WebArena 属于这一类。不需要 LLM 当裁判。

第二类：没有唯一答案但有明确标准的。 “帮我写一封商务邮件”——好邮件和差邮件的区别是真实存在的，但你没法写一个正则表达式来判定。“总结这篇文章的核心观点”——全面和片面、准确和歪曲之间有清晰的质量梯度，但没有标准答案。这类任务必须有人（或模拟人的模型）来判断。

第三类：标准本身就是主观的。 “这个回复友不友好”“这个建议有没有用”——不同用户可能给出不同评价。这类任务的“金标准”只能是多人的主观评分聚合。

后两类是 Agent 在真实应用中最常面对的任务类型，也是 LLM-as-Judge 被广泛使用的原因。相比人工评审，它有三个明显优势：

• 快：几百条 case 几分钟判完，人工可能要几天
• 便宜：一次 API 调用几分钱，人工评审一条可能几十块
• 可复现：给定相同的 prompt 和模型版本，输出基本一致（虽然不是完全确定）

问题在于：快、便宜、可复现，不等于准确。

裁判的四种典型偏见

LLM-as-Judge 的可靠性问题不是“模型不够聪明”——GPT-4 级别的模型已经能做很多复杂的判断了。真正的问题是系统性的偏见（bias），这些偏见在特定条件下会让裁判的评分严重偏离“真实质量”。

1. 位置偏见（Position Bias）

当裁判被要求比较两个答案 A 和 B 哪个更好时，它会系统性地偏好某个位置的答案——通常是先出现的那个，有时是后出现的那个，取决于具体模型。

这不是小问题。在一项被广泛引用的研究中，研究者把同一对答案交换位置后让 GPT-4 重新评判，结果有相当比例的 case 出现了“交换前选 A、交换后选 B”的反转——不是因为答案变了，仅仅因为位置变了。

位置偏见在 pairwise comparison（两两对比）模式下最严重，在 pointwise scoring（单独打分）模式下相对弱一些，但并没有完全消失。

缓解方法：

• 每次评判时随机化答案顺序
• 对同一对答案跑两次（交换位置），只有两次结论一致才采纳
• 优先用 pointwise 打分而非 pairwise 对比，尤其当两个答案质量接近时

2. 长度偏见（Verbosity Bias）

裁判模型强烈偏好更长的回答。一个啰嗦但平庸的答案，经常比一个简洁但精准的答案得到更高分。

这个偏见的根源不难理解：在训练数据中，“详细的回答”和“好的回答”高度相关。模型学会了“长 = 好”这个启发式，但它无法区分“有信息量的长”和“注水的长”。

在 Agent 测评中，长度偏见尤其有害——一个绕了 20 步、生成了大量中间推理的低效 Agent，可能比一个 5 步解决问题的高效 Agent 得到更高的“过程质量”评分。这直接和我们在第 3 篇讲的 L2 轨迹测评目标矛盾。

缓解方法：

• 在 rubric 中明确说明“简洁性是评分维度之一，冗长不应被奖励”
• 对超长输出做截断或摘要后再评分（但要注意不能截掉关键信息）
• 用“信息密度”而非“绝对长度”作为评估指标
• 如果可能，把输出长度作为一个独立的、需要被惩罚的指标单独统计

3. 自我偏好（Self-Preference Bias）

当裁判模型和被评模型是同一个模型（或同一家族的模型）时，裁判会系统性地给自己“家”的输出更高分。

这个偏见在多个独立研究中被验证过：GPT-4 当裁判时偏好 GPT-4 的输出，Claude 当裁判时偏好 Claude 的输出，Llama 当裁判时偏好 Llama 的输出。即使输出质量客观上相同，这种偏好也存在。

自我偏好的机制可能包括：风格相似性（模型更“喜欢”和自己行文风格一致的文本）、训练数据中的自我增强、以及对自身输出格式的熟悉度。

缓解方法：

• 永远不要用和被评模型同一个模型当裁判。 这是一条硬规则。
• 如果条件允许，用多个不同家族的模型当裁判，取平均或投票
• 人工评审作为最终校准，检查裁判是否存在系统性的家族偏向

4. 指令服从偏见（Instruction-Following Bias）

裁判模型会被 prompt 的措辞强烈影响。如果评分标准里写“重点考察准确性”，裁判会给看起来更“学术”的答案高分；如果写“重点考察实用性”，裁判会偏好更“口语化、可操作”的答案。这些倾向有时是合理的（你告诉它重点是什么，它就关注什么），但有时会导致过度矫正——裁判为了“表现出在遵循指令”，会在被强调的维度上给出极端分数。

更隐蔽的问题是 few-shot 示例的暗示。如果你在 prompt 里给了一个“高分示例”，裁判会倾向于给和示例风格/结构/长度相似的答案高分，即使那个示例只是你随手写的。

缓解方法：

• 仔细审查 prompt 措辞，避免使用带有倾向性的形容词
• few-shot 示例要覆盖不同质量等级（好/中/差各一个），而不是只给好答案的例子
• 定期跑“空白对照”：用一个中性 prompt 评分，和正式 prompt 的结果对比，看是否有系统性偏移

除了偏见，还有可靠性问题

偏见是“系统性地往一个方向偏”，但 LLM-as-Judge 还有另一类问题：不一致性（inconsistency）。

温度导致的随机波动

即使 prompt 完全相同、模型完全相同，temperature > 0 时两次评分可能不同。大部分时候差异很小（±1 分），但在边界 case 上可能导致“及格/不及格”的翻转。

缓解： 评分时设 temperature=0，或者对同一条 case 跑 3 次取多数/平均。

格式不遵循

裁判模型有时不按你要求的格式输出——你让它返回 JSON，它返回一段自然语言；你让它在 1-5 分之间打分，它给了个 7 分。这类问题在小模型上更频繁，大模型也偶尔发生。

缓解： 用 structured output / JSON mode；后处理时加格式校验和重试逻辑；不要假设模型一定会遵循指令。

推理能力不足导致的误判

有些质量判断需要真正的理解和推理。比如“这段代码有没有内存泄漏”“这个数学证明的第 3 步是否成立”“这个搜索结果是否真的回答了用户的问题”——如果裁判模型本身的推理能力不够，它可能给一个“看起来合理但实际上有误”的答案高分。

这是最难解决的问题，因为你没法靠 prompt 工程让一个不够聪明的模型变聪明。

缓解：

• 裁判模型应该用比被评模型更强或同等水平的模型。让弱模型当强模型的裁判，结果不可信。
• 对需要专业知识的领域，用领域专用模型或加领域专家人工抽检
• 把“可验证的部分”和“需要主观判断的部分”分开——前者用规则，后者用 LLM

匹配错误

裁判有时会“张冠李戴”：把 A 答案的特征归到 B 上、遗漏了答案中的关键缺陷、或者自己产生幻觉认为答案里有某个内容但其实没有。

在长文本评分和多轮对话评分中，匹配错误尤其常见——裁判的“注意力”也是有限的。

缓解： 让裁判在打分前先做“事实摘录”（列出答案中的关键论点和证据），再基于摘录评分。这不仅减少匹配错误，还能让评分过程可审计。

怎么设计一个靠谱的 Rubric

Rubric（评分标准）是 LLM-as-Judge 的灵魂。一个好的 rubric 让评分一致、可解释、可复现；一个差的 rubric 等于让模型自由发挥。

好 rubric 的四个特征

1. 维度正交。 把“质量”拆成几个互不重叠的维度，而不是笼统地问“这个答案好不好”。常见的维度包括：

• 准确性（事实是否正确）
• 完整性（是否覆盖了所有要点）
• 相关性（是否回答了被问的问题）
• 逻辑性（推理是否连贯）
• 简洁性（是否有不必要的冗余）
• 安全性（是否有有害内容或越权操作）

不是每个任务都需要所有维度——根据场景选 3-5 个核心维度。

2. 每级有锚点描述。 不要只写“1-5 分，1 最差 5 最好”。每个分数级都应该有具体的行为描述，比如：

5 分：准确回答了所有问题，推理过程清晰，无事实错误，可能有极小的表述瑕疵 4 分：核心问题回答正确，但有一个非关键性遗漏或表述不够精确 3 分：回答了部分问题，但有明显的信息缺失或一个中等程度的事实错误 2 分：大部分问题未回答，或存在严重事实错误 1 分：完全未回答问题，或答案与问题无关

锚点描述让不同 case、不同时间的评分有统一参照。

3. 指令明确无歧义。 避免“适当”“合理”“较好”这类模糊词。用“必须”“不得”“至少包含”这类明确表述。

4. 可验证。 每个评分维度最好能给出“为什么打这个分”的理由。要求裁判在给分的同时输出一段解释，这既能让评分过程可审计，也能提高评分质量（模型在“解释”时会更认真地思考）。

Rubric 设计的常见错误

• 维度太多。 超过 7 个维度后，裁判对每个维度的注意力会下降，评分质量反而变差。3-5 个维度是甜点区。
• 权重不清。 如果不同维度的重要性不同，要明确写出来（“准确性占 50%，完整性占 30%，表达占 20%”），不要让裁判自己猜。
• 把“风格”当“质量”。 “用了专业术语”不等于“答案好”。除非你的场景明确要求某种风格，否则风格偏好不应进入 rubric。
• 从不迭代。 Rubric 第一版一定不完美。跑 50 条 case、看看和人工评分的偏差在哪里、针对性调整——这是必经之路。

校准：你怎么知道裁判准不准

光有 rubric 不够，你还需要校准（calibration）——用人工评分作为“金标准”来验证裁判的准确性。

核心指标

1. 一致率（Agreement Rate）

在分类/打分类任务中，裁判评分和人工评分完全一致的比例。

• 对于二分类（通过/不通过），>85% 是基本可用，>90% 是良好
• 对于 5 分制打分，“完全一致”通常偏低，更常用“相邻一致”（±1 分以内算一致），>80% 可接受

2. Cohen’s Kappa / Kendall’s W

一致率的问题是它没有排除“碰巧一致”的可能性。Cohen’s Kappa（二分类/多分类）和 Kendall’s W（序数打分）考虑了随机一致性，是更严谨的指标。

• Kappa 0.6-0.8 表示“实质性一致”
• Kappa >0.8 表示“几乎完全一致”
• Kappa <0.4 说明裁判基本不可靠，需要重新设计 rubric 或换模型

3. 偏差方向（Bias Direction）

裁判是系统性偏高还是偏低？计算“裁判分 - 人工分”的均值：

• 正值：裁判偏宽松
• 负值：裁判偏严格
• 接近 0 但一致率低：裁判没有系统偏差但噪声大（不一致问题）

这个分析能告诉你该调 rubric 的什么地方——如果裁判总是偏高，可能需要在 rubric 里强化扣分标准；如果时高时低，可能是温度或格式问题。

4. 混淆矩阵（Confusion Matrix）

看看裁判在哪两类评分之间最容易混淆。比如它经常把“3 分”判成“4 分”（偏宽松），还是经常把“2 分”判成“3 分”（对低质量不敏感）？混淆模式能指导 rubric 的精细化。

校准流程

1. 随机抽 100-200 条 case，让人工打分（最好 2-3 人独立打，取平均，计算人间一致率作为上限基准）
2. 用 LLM judge 跑同样的 case
3. 计算上述指标，分析偏差
4. 根据偏差调整 rubric 和 prompt
5. 重新跑，直到裁判和人工的一致率达到可接受阈值
6. 之后每季度或每次换模型版本后重新校准一次

一个常见的误区是：不做校准就直接用。 很多团队接了个 GPT-4 当裁判，跑了几百条 case，看了两三条结果“感觉还行”就全量上线了。这和没写测试就上线代码一样危险。

三层评分架构：什么时候用什么

不是所有评分都需要 LLM。在实践中，最靠谱的方案是三层组合：

graph TB
    A["规则校验<br/>自动 · 零成本 · 100%客观"] --> B["LLM-as-Judge<br/>半自动 · 低成本 · 需校准"]
    B --> C["人工抽检<br/>人工 · 高成本 · 金标准"]

    A -.->|"能规则判的<br/>绝不留给LLM"| R["最终评分"]
    B -.->|"开放性维度<br/>用模型判"| R
    C -.->|"抽样校准+争议裁定<br/>10-20%"| R

    style A fill:#e8f5e9,stroke:#2e7d32
    style B fill:#fff3e0,stroke:#e65100
    style C fill:#e3f2fd,stroke:#1565c0
    style R fill:#f5f5f5,stroke:#616161

第一层：规则校验。 能用规则判的，绝不用 LLM。格式是否正确、必填字段是否存在、数值是否在合理范围内、是否包含了必须提及的关键词——这些 100% 客观的判断交给代码，又快又准。

第二层：LLM-as-Judge。 规则判不了的开放性维度（准确性、完整性、逻辑性、有用性），用校准过的 LLM 裁判评分。这是主力层，处理 70-80% 的 case。

第三层：人工抽检。 从 LLM 评分结果中抽 10-20% 做人工复核。抽检的目的不是替代 LLM，而是：

• 校准裁判的准确性（发现漂移）
• 处理争议 case（LLM 自评置信度低、或两个裁判打分不一致）
• 发现 rubric 的漏洞（出现了 rubric 没覆盖的质量问题）
• 为 rubric 迭代提供依据

三层组合的优势是：既不是“全靠人工”（贵且慢），也不是“全靠模型”（不可控），而是用模型做大规模初筛、用人工做质量锚定。 这也是总纲里说的“规则 + LLM + 人工三层判定”的具体落地方式。

一个实操清单

如果你准备在自己的 Agent 测评中引入 LLM-as-Judge，按这个清单走：

1. 确定哪些维度需要 LLM 判。 先列出所有评分维度，能规则判的划出去，剩下的才交给 LLM。
2. 选裁判模型。 用比被评模型更强的模型；不要用同一个模型既当选手又当裁判。
3. 写 rubric 初稿。 3-5 个正交维度，每个维度 1-5 分，每级有锚点描述。
4. 设计 prompt。 明确任务、评分维度、锚点、输出格式（要求 JSON + 理由），避免倾向性措辞。
5. 小规模试跑。 先跑 20-50 条，人工检查每条评分和理由，发现明显问题就改 rubric。
6. 校准。 100-200 条人工标注，计算一致率、Kappa、偏差方向，迭代到指标达标。
7. 设置防护。 temperature=0、结构化输出、格式校验重试、多裁判投票（高风险场景）。
8. 持续抽检。 上线后每批抽 10-20% 人工复核，监控裁判漂移。
9. 定期重新校准。 换模型版本、改 rubric、或发现指标波动时，重新跑校准流程。
10. 记录版本。 裁判模型版本、prompt 版本、rubric 版本都要记录，否则历史分数不可比。

小结

LLM-as-Judge 不是银弹，但也不是垃圾。它是一个强大但有已知缺陷的工具——用对了可以把测评成本降低一个数量级，用错了会让你在错误的数字上自我感觉良好。

这篇的核心结论：

• LLM 裁判有四种系统性偏见：位置偏见、长度偏见、自我偏好、指令服从偏见。每种都有对应的缓解方法，但没有一种能被完全消除。
• 除了偏见，还有不一致性问题：温度波动、格式不遵循、推理能力不足、匹配错误。
• Rubric 是裁判可靠性的核心：维度正交、每级有锚点、指令明确、可验证。
• 必须做校准：用人工评分当金标准，算一致率和 Kappa，分析偏差方向，持续迭代。
• 最靠谱的方案是三层组合：规则 + LLM + 人工，而不是把所有评分都交给模型。

下一篇《轨迹测评：不只看“做没做成”，还要看“怎么做的”》，我们会回到 L2 层，详细讲怎么评估 Agent 的执行过程——步数、工具调用、回溯、成本、路径效率，以及怎么用轨迹数据做 A/B 对比。