你的 LLM Judge 存在长度偏见、位置偏见和格式偏见 —— 且无人审计你的模型

我上个季度合作的一个团队看着他们的 LLM-as-judge 分数在六周的提示词（prompt）迭代中从 78% 飙升至 91%。他们发布了产品。但用户却非常讨厌它。新的提示词产生了更长、格式更丰富、听起来更自信的回答 —— 而评委（judge）爱死了每一个回答。团队并没有构建出更智能的提示词。他们只是对评委的偏见进行了逆向工程。

这是团队中没人审计的失败模式。LLM-as-judge 有据可查的系统性偏见：无论质量如何，更长的回答得分更高；在两两比较中，第一个选项胜出的概率高于随机概率；且看起来像评委自身训练分布的输出得分高于不符的。如果你在十二个月前接入了一个 LLM 评委，且从未针对人类进行重新验证，那么你的分数就不是质量信号 —— 它们衡量的是你的提示词学会如何操纵其评估器的程度。

令人沮丧的是，捕捉这一点的审计方法很直接，防止它的校准纪律也很廉价，但几乎没有团队会执行其中任何一项。

生产环境评委中常见的三个偏见

关于 LLM 评估器的偏见文献现在已经多到令人尴尬的地步。一项 2024 年针对六个 LLM 评委和 22 个任务的位置偏见系统性研究发现，位置偏见并非随机噪声 —— 它在不同评委之间差异显著，并且在候选者之间的质量差距较小时最为明显，而这恰恰是你的评估系统要求评委进行辨别的场景。另一个对 LLM-as-judge 偏见进行编目的框架列举了十二个不同的类别。在生产环境中最致命的三个是长度、位置和格式。

长度（冗长）偏见（Length bias）。 LLM 评委更喜欢较长的回答。这种效应非常稳健，以至于 AlpacaEval 2.0 专门构建了一个基于回归的长度控制胜率来消除排行榜的偏见，而最初的 AlpacaEval 以偏向那些单纯生成更多 token 的模型而闻名。其机制部分源于训练分布 —— RLHF 往往会奖励看起来更详尽的回答 —— 部分源于表面暗示，如套话（hedging）和阐述，评委将其解读为“更严谨”。在生产环境中，这意味着一个增加了三句开场废话的提示词得分会比一个直奔主题的提示词更高。

位置偏见（Position bias）。 在两两比较（A vs. B）中，候选者在提示词中的位置会改变裁决结果。有些评委偏好第一个选项，有些偏好第二个，偏见强度取决于模型和任务。纯净的信号是顺序不对称性：运行 A-然后-B，再运行 B-然后-A，只计算两次排序结果一致的裁决。不一致率就是你的偏见底线。在势均力敌的一对比较中，你通常会看到当交换位置时，20–40% 的裁决会发生翻转，这意味着高达 40% 的“获胜”是排序产生的假象。

格式偏见（Format bias）（也称为熟悉度或自我偏好偏见）。当输出看起来像评委自己会产生的内容时，评委给出的分数更高。自我偏好偏见已被直接衡量：GPT-4 系统性地给 GPT-4 的输出打分高于人类的打分，且该效应与困惑度（perplexity）相关 —— 评委更喜欢统计学上对它们熟悉的文本。在实践中，这表现为 Markdown 偏见（格式化的列表得分高于同等的散文）、结构偏见（带编号的标题得分高于流动的论证）以及风格家族偏见（来自一个供应商的评委悄悄调低另一个供应商输出的分数，即使人类更喜欢后者）。

这些偏见单独看都很微小。但在六周的提示词迭代循环中组合起来，你就制造了一台古德哈特机器（Goodhart machine）。

一个下午就能捕捉到这些偏见的审计方法

只需运行一次三个对照实验，就足以了解你的评委是否可靠。

长度受控对（Length-controlled pairs）。 从现有的评估集中取样。对于评委选择了一个答案而非另一个答案的每一项，生成一个长度匹配的变体：将较长的回答截断到较短回答的 token 数量，或用中性填充词扩展较短的回答。重新运行评委。长度匹配后发生翻转的裁决比例就是你的长度偏见率。任何超过 10% 的结果都意味着长度是你评分中一个显著的混杂变量。解决方法不是禁止长篇回答 —— 而是让评委根据长度受控的准则进行评分，或者应用类似 AlpacaEval 的回归修正。

位置交换对照（Position-swapped controls）。 对于每个两两比较的提示词，运行两次：A-然后-B，以及 B-然后-A。丢弃两次排序不一致的裁决。丢弃的比例就是你的位置偏见率。保留的裁决才是真实的信号。这大约会使你的评委成本翻倍并减少样本量，但对于你重视的任何两两比较来说，这是不可逾越的底线。在生产级评估中，单向的两两比较评分是一个低级失误。

去格式化比较（Format-stripped comparisons）。 通过 Markdown 清除规范化器处理每个候选回答，移除标题、列表、加粗和表格，只保留纯文本散文。针对去格式化后的版本重新运行评委。格式化版本与去格式化版本之间的分值差就是你的格式偏见贡献度。如果分值差很大，说明你的评委在奖励形式而非实质，每当你的提示词迭代增加了更多的列表或标题时，你都会看到并不存在的“进步”。

这三项审计各需要数百次额外的评委调用和几个小时的工作。它们能告诉你评估器的噪声底线。没有它们，任何低于偏见底线的提示词迭代增量在统计学上都是毫无意义的。

保持诚实的校准纪律

设置时的一次性审计是不够的。有两件事会发生偏移。

第一是裁判本身。供应商端的模型更新会改变行为——在 gpt-4o-2024-08-06 和 gpt-4o-2024-11-20 上针对同一评估集使用相同的裁判提示词，不会产生相同的分数。如果你固定裁判模型，你就要接受陈旧性。如果你让它浮动，你就要接受无声的偏移。无论哪种方式，你都需要定期的校准检查。

第二是任务。你在发布时编写的评估集反映了你当时知道的失败模式。随着产品的成熟，真实用户输入的分布会发生变化，失败模式也会随之改变。半年后，你的裁判可能针对一个不再代表工作负载的评估集进行了完美的校准。

处理这两者的纪律是建立一个预留的人类偏好小组（held-out human-preference panel），每季度刷新一次。结构很简单：

• 一个由 200–500 个示例组成的固定面板，由人工手动评分，你永远不会针对它进行训练、提示词微调或裁判微调。
• 每次校准运行时，你用当前的裁判对面板进行评分，并计算其与人类标签的一致性率。
• 一致性随时间变化的趋势线就是你的裁判健康指标。如果它向下偏移，要么是裁判发生了变化，要么是评分标准（rubric）过时了，或者面板不再代表生产流量——每种诊断都指向不同的修复方案。

强有力的裁判在正确的任务上能与人类评估者达成 80–90% 的一致性，这大致相当于人类彼此之间表现出的标注者间一致性（inter-annotator agreement）。如果你的裁判一致性低于 70% 且没有上升趋势，那么在该底线之上的任何提示词迭代都不是真实的。你是在针对噪声进行调优。

一个几乎不需要成本的补充实践：抽取 5–10% 的生产裁判裁定，并让人类重新评分。将一致性率作为一个持续指标进行跟踪。当它下降时，呼叫相关人员——不是因为模型退化了，而是因为你的测量工具可能出了问题。

架构层面的规避方案

审计告诉你裁判是否坏了。而架构决定了它默认会有多坏。

分解评分标准（Decomposed-rubric）的裁判。 单个“按有用性给这个回答打 1-10 分”的提示词会导致长度、格式和位置偏差混合成一个数字，而裁判无法告诉你哪个在起作用。将评分标准分解为独立的维度——事实准确性、指令遵循、语气、格式遵守、引用质量——并分别评分，将有用性从一个有偏差的数字转变为五个偏差较小的数字。G-Eval 模式要求裁判在评分前列出评估步骤，这进一步推进了这一点：它强制要求每个标准都有显式的推理，这在经验上减少了方差。维度级别的分数也更具可调试性：现在可以看到提升了事实准确性但损害了简洁性的提示词更改，而不是隐藏在单个有用性分数中。

跨家族的多裁判集成。 当你所有的裁判都是同一个模型时，自我偏好和格式熟悉度偏差会叠加。针对相同的评分标准运行 Claude 裁判、GPT-4 裁判和 Gemini 裁判，并采取多数投票（或要求 3 分之 2 一致），可以消除单一家族的风格偏差，因为没有两个供应商具有相同的训练分布。成本大约是裁判支出的 3 倍；好处是没有单个裁判的偏好最终会驱动你的提示词迭代。将此留给把控发布的评估——对于廉价的持续监控，单个蒸馏裁判就足够了，只要你对其进行校准。

成对比较（Pairwise）优于点分制（Pointwise）。 点分制分数（“打 1-7 分”）在不同运行之间会发生偏移，并且对评分标准的锚点措辞很敏感。成对判断（“A 是否比 B 好”）在不同运行之间更稳定，且更容易对照人类进行验证，因为人类也更擅长相对判断而非绝对判断。代价是成对比较需要双向排序以控制位置偏差，但你本来就需要这样做。对于大多数评估目的，针对一个强大的基准运行成对比较并报告胜率，而不是 Likert 量表分数。

尽可能使用基于工具（Tool-grounded）的检查。 任何你可以通过确定性方式验证的内容——JSON 模式一致性、针对已知数据库的事实查询、通过测试的代码——都不应该经过裁判。将裁判留给那些人类对答案也存在分歧的真正主观维度。上面列出的偏差只在模糊的标准上起作用；在可验证的标准上，解析器可以免费完成工作。

每个团队都会推迟到第二次事故才建立的组织产物

上述技术修复方案是众所周知的，且有完备的文档记录。团队不执行这些方案的原因是组织层面的，而非技术层面的：LLM 裁判被视为固定的基础设施。没有人拥有它。没有人对其进行版本控制。当提示词更改“将分数提高了 4 分”时，没有人询问裁判是否发生了变化。当裁判提示词本身被编辑时——它总是会被编辑，通常是为了修复演示中出现的某个特定尴尬问题——每个前期分数都变得不可比，而且没有人指出这一点。

防止这种情况发生的产物是一个带有自己变更日志（changelog）的裁判，它被视为每个依赖它的评估的版本化依赖项。最小内容包括：

• 裁判提示词、底层模型版本和评分标准，全部作为一个单一的可寻址裁判版本一起进行检查点（checkpoint）记录。
• 一个预留的校准集，带有在记录检查点时定义裁判一致性率的人类标签。
• 每次裁判更改的说明，解释发生了什么变化以及新的校准一致性是多少。
• 一项政策，规定任何跨期分数比较必须使用相同的裁判版本，否则必须明确注明版本差异。

这是枯燥的基础设施工作，它将一个知道模型是否在改进的团队与一个自以为知道的团队区分开来。如果没有它，每次有人说“我们从 72% 提高到 89%”的季度回顾都只是一张演示幻灯片，而不是一种测量。

明天该做什么

三个能在下个 Sprint 前产生实质影响的具体行动：

1. 执行三项审计——长度控制对组 (length-controlled pairs)、位置交换对照 (position-swapped controls) 以及格式剥离对比 (format-stripped comparisons)——在你现有的评估集上。这些数据能在一个下午内告诉你，你现有的评分信号中有多少是偏差，有多少是真实的。
2. 切出一份包含 200 个样本的预留人工偏好测试集 (held-out human-preference panel) 并进行一次评分。从现在起，你的评判模型 (judge) 与该测试集的一致性率就是你的“评判健康指标”。在展示评估分数的同一个仪表盘上追踪这一指标。
3. 为你的评判模型设置版本。 将提示词 (prompt) + 模型 + 评分标准 (rubric) 视为一个冻结的构件，给它一个版本字符串。要求任何对评判模型的修改都必须提升版本号，并重新进行基准校准 (re-baseline calibration)。

当经过校准时，LLM-as-judge 是真正的生产力解放工具。而当它未被校准时，它也是让你在模型质量上自我欺骗的最快方式。区别在于，你是将评判模型仅仅当作测量工具，还是将其本身也作为被测量的对象。