让模型当裁判前，先校准它的误判率

“LLM-as-judge” 已经悄然成为基础设施。我们用一个模型给另一个模型的回答打分，判断测试是否真的通过，评估 RAG 相关性，审核内容，以及排序。它成本低、速度快，还能处理人类根本无法企及的任务量。

但它也是一种测量工具，而大多数团队在部署它之前，从未检查过这把尺子是否准确。下面是一份实用清单，供你在让 LLM 评判任何重要事项之前逐项核对。（补充一点上下文：我搭建了一个小型测试框架，让本地 LLM 担任测试评审，并根据 ground truth，也就是已知的真实结果，评估它的表现。下文的一些数字就来自这次实验。）

1. 至少用 ground truth 衡量一次

没有测量，就无从管理。整理一组你明确知道正确判定的案例，标注为正确或错误，再让评审模型逐一判断。你需要关注：

• 误通过率：在它判定通过的所有结果中，实际有多少是错的？（这是危险的那一面。）
• 漏检率：在真正错误的结果中，有多少被它放行了？
• 误报率：它拒绝正确结果的频率有多高？（这是令人烦恼的那一面。）

在我的实验中，一个能力不错的开放模型漏掉了 26% 的错误输出，也就是说，四分之一的真实失败被判定为通过。在依赖评审模型之前，你需要先知道它在你自己的任务上的这个数字。

2. 检查校准程度，别只看准确率

让评审模型给出置信度，然后检查这个置信度是否有实际意义。一个校准良好的评审模型，如果说自己“有 90% 的把握”，那么它的判断就应该有大约 90% 是正确的。可以用 Expected Calibration Error（ECE，预期校准误差）来衡量。

常见的问题是：模型过度自信。我的模型几乎每次判断都给出约 100% 的置信度，包括判断错误的时候（ECE ≈ 0.31）。如果置信度始终都是“非常确定”，它就无法提供有效信号，你也就没法据此把难以判断的案例转交给人工。

3. 固定所有要素，并做好版本管理

如果 LLM 评审的模型、prompt 或 temperature 不断变化，就像一把长度会变的尺子。需要固定：

• 确切的模型及其版本。
• temperature（评分时使用 0：你需要的是确定性，而非创造性）。

开放权重模型在这方面很有帮助：你可以固定本地模型，确保它不会在你不知情的情况下发生变化。而托管 endpoint 背后的模型可能被悄悄替换。

4. 留意已知偏差

LLM 评审存在一些已有文献记录、且可以复现的偏差：

• 位置偏差：在两两比较时，更偏爱第一个或最后一个选项。缓解方法是按两种顺序分别评判，再取平均值。
• 篇幅偏差：不论内容是否正确，都会给更长的回答更高的分数。
• 自我偏好：模型往往更喜欢那些看起来像自己生成的内容。
• 宽松倾向：许多评审模型在不确定时，会默认给出“PASS”。

如果你的评估结果决定排行榜名次或是否发布，这些偏差就会成为你的决策偏差。

5. 绝不要让它成为唯一关卡

安全的做法不是“模型判定通过，就发布”，而是：

• 把评审模型用作成本低廉的初步筛选工具，而非最终裁决者。
• 保留基于 ground truth 的抽样兜底机制，持续抽查评审模型，而不是只检查一次。
• 将低置信度或事关重大的案例交给人工，或采用更严格的检查。
• 将 PASS 理解为“可能没问题”，而不是“已经验证无误”。

LLM 评审速度快、成本低，但有偏差，也过度自信。它判断正确的次数足以让它发挥作用，判断错误的次数也足以让它带来危险。衡量它、固定它、减少它的偏差，并保留人工兜底，它就会成为一个很好的工具。盲目信任它，它就可能带着十足的自信，悄悄放行你最严重的 bug。

你在生产环境中使用 LLM-as-judge 吗？拿 ground truth 检验它时，你发现了什么？还是说，你还没有检查过？

我是 Krishnasai Rollamadugu，一名测试自动化架构师，正在研究 AI 驱动的软件测试中的信任与测量问题。相关项目：衡量本地 LLM 评审表现的开放实验——trust-judge。

如果需要进一步处理，你可以考虑屏蔽此人和／或举报滥用行为。