# LLM 评测分数为什么会漂：把裁判模型校准成可用的测量工具

> 同一批输出为何会得到不同分数？拆开生成波动、裁判波动与裁判漂移，用人工标注样本和重复评分校准裁判，把不确定性纳入发布判断。

- Source: https://www.aifreeapi.com/zh/posts/llm-judge-drift-calibration
- Language: zh
- Published: 2026-08-31
- Updated: 2026-09-12
- Publisher: AI Free API (https://www.aifreeapi.com)

同一条输入、同一个被测版本，今天得 0.82，明天只有 0.76。最危险的解释是直接把这 0.06 当成产品退化。LLM 评测管线里至少有两个会波动的模型：一个生成候选结果，另一个负责打分。候选结果变了、裁判重复性不足、裁判模型或评分规则发生变化，都会让看板上的分数变化。

正确的问题不是“怎样让 LLM 完全确定”，而是“这次变化来自哪一层，证据足不足以改变发布决定”。把裁判模型当作测量仪器，而不是答案机器，评测才能为上线决策提供依据。

## 先画清楚两个随机层

设被测系统为 S，裁判为 J。一次端到端评测可以简化成：

~~~text
输入 x ──> 系统 S ──> 候选输出 y ──> 裁判 J ──> 分数 z
~~~

重复整条链路时，y 和 z 都可能变化。只看最终分数，无法判断是系统输出的差异，还是裁判对同一输出的判断不稳定。

因此，可以按目的分别安排复跑：

| 要回答的问题 | 固定什么 | 重跑什么 | 观察结果 |
|---|---|---|---|
| 裁判评分能重复得到一致结果吗 | 输入、候选输出、规则、裁判配置 | 只重跑裁判 | 同一输出的分数分布和判定翻转 |
| 整体体验稳定吗 | 输入集、系统与裁判版本 | 重新生成并重新评分 | 生成波动与评分波动叠加后的分布 |
| 产品真的变好了吗 | 同一输入集、同一套裁判评分规则 | 比较候选版本 | 差值及其不确定性，而非单点均值 |
| 裁判是否漂移 | 人工标注的固定锚点 | 用当前裁判持续重评 | 裁判与人工标签的差距是否移动 |

![分数下降归因图，区分生成波动、裁判重复性不足、裁判漂移和真实产品退化，并给出实验拆分与发布决策](https://www.aifreeapi.com/posts/zh/llm-judge-drift-calibration/img/score-attribution-map.webp)

如果团队没有保存候选输出，就无法在事后只重跑裁判。这也是为什么评测记录至少要保留输入 ID、系统版本、生成参数、候选输出、裁判模型、裁判规则版本、评分结果和时间戳。隐私或合规不允许保存原文时，也要设计经过批准的脱敏存储或受控重放方案。哈希只能核对内容是否一致，不能恢复原文供裁判重新评分；不能用“看板有历史”替代可归因的证据。

## 能写成断言的条件，不要交给裁判猜

LLM 裁判适合处理忠实度、清晰度、语气是否合适等开放判断，不适合替代本来就能确定计算的条件。JSON 能否解析、必填字段是否存在、工具名是否正确、金额是否相等、引用 URL 是否在允许列表，都应该先用代码检查。

这不只是省钱。确定性检查能定位具体规则是否满足，避免裁判用“整体感觉不错”掩盖硬错误。OpenAI 当前的[评测最佳实践](https://developers.openai.com/api/docs/guides/evaluation-best-practices)同样建议采用任务相关的评测、持续评测，并用人工反馈校准自动评分；其 [Graders 指南](https://developers.openai.com/api/docs/guides/graders)也把字符串检查、相似度检查和模型评分区分为不同工具。

一个实用的评分规则可以先拆成三层：

1. **硬门槛**：格式、安全、工具参数、事实引用等可计算条件，任何一项失败就进入修复。
2. **任务判定**：裁判只评价仍需语义判断的维度，而且每个维度有明确通过标准。
3. **转交人工复核**：高风险、低置信度、裁判不一致或规则本身含糊的样本交给人。

把所有条件压成一个 0–10 总分，会让失败原因消失。一个 7.4 既可能是事实错误，也可能只是文风不够简洁；两者不应触发同一种发布动作。

## 先测裁判，再让裁判测产品

裁判上线前需要自己的评测集。这个集合不是随机挑一批“正常回答”，而应包含团队真正会遇到的边界：

- 明显通过和明显失败的样本，用来验证基本区分能力；
- 专家容易分歧的临界样本，用来暴露规则歧义；
- 仅长度、顺序、格式或措辞不同但任务质量接近的对照样本；
- 事实正确但表达朴素，以及表达漂亮但关键事实错误的样本；
- 真实线上失败、投诉和人工修复案例；
- 可能诱导裁判偏爱的冗长、权威语气或自我引用样本。

这些样本由领域专家独立标注，再处理分歧。目标不是强迫所有人给出同一个数字，而是明确哪些差异属于政策，哪些属于可接受偏好，哪些必须交给人工复核。

早期研究已经说明为什么这一步不能省。[MT-Bench 与 Chatbot Arena 的 LLM 裁判研究](https://arxiv.org/abs/2306.05685)在特定任务和模型上观察到较高的人机一致度，同时记录了位置偏差、冗长偏好、自我偏好和推理限制。它提出换序复评、参考答案等缓解方法，但论文中的一致率只适用于其数据、模型与协议，不能当作你所用裁判的准确率。

另一项[公平裁判研究](https://arxiv.org/abs/2305.17926)展示了仅改变候选答案的出现顺序就可能改变排名，并提出多证据、平衡位置与人工介入的校准方法。随后一项比较多种裁判和任务的[位置偏差系统研究](https://arxiv.org/abs/2406.07791)进一步表明，偏差会随裁判和任务而变化。换句话说，“这个模型很强”不能替代对你自己的任务进行验证。

## 四组测试能把常见偏差暴露出来

### 重复性测试：固定输出，只重跑裁判

对每个冻结样本重复评分，记录每一维的完整结果，而不是只存平均分。关注三种信号：

- 同一样本是否在“通过／失败”之间翻转；
- 哪些维度的分布最宽；
- 波动是否集中在人工也认为模糊的样本上。

如果明显通过的样本频繁翻转，裁判评分规则还不能用于 CI。若波动只集中在真正模糊的边界，正确动作可能是设置“需要人工”区间，而不是硬调提示词把所有样本挤成确定答案。

### 换序测试：比较 A/B 与 B/A

成对比较时，对同一候选交换位置。保守规则是只有两个顺序都支持同一候选时才判胜；结果相反就记为不一致或平局。大规模评测也可以随机化位置，但仍要单独报告位置一致性，不能让随机化把系统性偏差藏在均值里。

### 反事实测试：只改不应影响质量的表面

给同一答案制作受控变体：改变长度、段落格式、署名、礼貌程度或模型名称，但不改变任务事实。若分数随这些表面变化大幅移动，团队看到的可能是裁判偏好，而不是产品质量。

这类测试也能发现“奖励黑客”：系统学会写得更长、更像裁判偏爱的模板，自动分数上升，人工却认为结果没有更好。公开指南建议持续把新边界案例加入裁判评测集，原因正在这里。

### 参考测试：让可验证任务携带依据

数学、事实抽取、摘要忠实度或工具调用任务，尽可能提供原始材料、参考答案或可执行检查。参考答案仍可能不完整，但它至少让裁判围绕证据判断，而不是先被候选答案带偏。

裁判的解释可以帮助排查，却不能自动证明分数正确。解释也是同一个模型生成的输出，可能流畅地为错误判定辩护。发布门禁应依赖可观察的判定与校准结果，而不是解释写得像不像专家。

![裁判模型校准与发布门禁图，包含重复性、换序、反事实、参考测试、锚点流和四类 CI 决策](https://www.aifreeapi.com/posts/zh/llm-judge-drift-calibration/img/judge-calibration-gates.webp)

## 校准不是把均值调到一致

如果裁判平均给 0.8、人工平均给 0.7，简单减去 0.1 并不叫完成校准。真正需要确认的是：裁判能否在团队关心的决策上与人工保持一致。

校准记录至少要回答：

- 在明确通过、明确失败和模糊样本上，裁判分别怎样表现？
- 哪些任务、语言、长度或风险等级的误差更大？
- 假阳性与假阴性的代价是否对称？
- 分数接近门槛时，裁判的不确定性有多大？
- 规则、示例或模型变化后，旧结论是否仍成立？

对发布门禁来说，分类结果往往比小数点后的分数更可操作：通过、失败、需要人工。团队可以继续保留连续分数用于分析，但门禁应依据校准过的决策边界和风险成本，而不是为了整齐选择 0.80。

样本数、重复次数和容忍区间没有跨任务通用答案。高风险医疗或金融文本、内部客服摘要、营销标题的错误代价完全不同。先写明可接受的漏放与误拦，再用本领域数据估计需要的样本量和复跑预算。

## 用固定锚点区分“系统坏了”与“裁判变了”

生产监控只看当前流量时，分数下降有两种竞争解释：产品变差，或裁判变严。解决方法是在生产样本流之外保留一条独立的锚点流。

锚点是经过人工确认、内容固定、覆盖关键任务和边界的样本。每次或按固定节奏，用当前裁判重评这些锚点：

~~~text
生产流：当前系统输出 ──> 当前裁判 ──> 产品质量信号
锚点流：固定人工样本 ──> 当前裁判 ──> 裁判稳定性信号
~~~

若生产流下降而锚点稳定，系统或线上分布更值得调查；若固定锚点的分数也持续沿同一方向变化，应先排查裁判模型、规则、示例、后端或解析层，并用重复评分排除随机波动；两条流都不稳定时，门禁应停止给出简单结论。

2026 年的预印本 [Who Drifted: the System or the Judge?](https://arxiv.org/abs/2606.15474)把这种归因问题形式化：让当前裁判持续重评固定的人工标注锚点，并把裁判相对人工的差距与生产监控分开。论文的具体检测率和成本来自其设置，不是部署保证；其工程意义在于：固定样本和人工标签后，锚点上的系统性变化可以帮助识别裁判行为变化；一次随机分数变化仍不足以判断漂移。

锚点集不能随每次产品改动一起重写，否则它失去参照作用。可以增加新案例，但要给集合和人工标签版本化，保留稳定核心，并记录何时、为何改变规则。

## CI 门禁要对不确定性做决定

一个可靠门禁不应写成“新版本平均分大于旧版本就通过”。它需要先回答以下问题：

~~~text
1. 硬断言是否全部通过？
2. 裁判在固定锚点上是否仍在校准范围内？
3. 冻结输出的重复评分是否足够稳定？
4. 新旧版本差值是否超过正常波动范围？
5. 变化是否集中在高风险或关键任务？
6. 是否存在需要人工裁决的冲突样本？
~~~

最终状态可以是：

- **通过**：硬门槛通过，裁判稳定，新版本证据清楚越过预设边界；
- **阻止**：明确违反必须满足的规则，或经校准的证据支持实质退化；
- **调查**：裁判锚点漂移、后端指纹变化、解析异常或生成分布变化；
- **人工复核**：差值落在不确定区间，或影响集中在高风险样本。

“调查”和“人工复核”不是失败状态，而是避免随机数字替团队做不可逆决定。

## 温度为零和 seed 只能减少变量

把温度设为零通常能降低采样变化，但不能证明整个服务确定。推理基础设施、模型别名、后端配置、提示词拼接、工具结果和解析器都可能改变。

OpenAI 的一篇[历史复现示例](https://cookbook.openai.com/examples/reproducible_outputs_with_the_seed_parameter)说明，在当时支持的 Chat Completions 预览模型上，匹配 seed、请求参数与 system_fingerprint 可以获得“多数一致”的输出，同时明确写出不保证确定性。这一能力不能外推到所有当前模型、接口或供应商。

实际应记录提供商暴露的模型版本、seed、采样参数、后端指纹、请求 ID 和规则版本。它们的作用是解释差异、缩小排查面，而不是把概率系统变成单元测试。

## 保留哪些字段，方便复查评分

无需一开始就搭建复杂平台，但每条评分最好能追溯这些字段：

~~~json
{
  "case_id": "support-summary-042",
  "dataset_version": "2026-08-31",
  "system_version": "candidate-b",
  "candidate_output_id": "sha256:...",
  "generation_config": {"model": "...", "temperature": 0},
  "judge_contract": {"model": "...", "rubric_version": "v4"},
  "grade": {"faithful": "pass", "clear": "review"},
  "run_id": "...",
  "timestamp": "..."
}
~~~

不要把敏感原文塞进日志；字段设计要服从数据保留、访问控制和脱敏规则。关键是让团队能够按候选输出、裁判评分规则和数据集版本重放，而不是只剩一条不可解释的平均曲线。

## 上线前的最后检查

在裁判开始阻止发布之前，确认以下事实：

- 客观条件已经改为确定性检查；
- 裁判评测集含明确、模糊、反事实和真实失败样本；
- 专家标签、分歧处理和规则版本可追溯；
- 冻结输出的重复性与 A/B 换序一致性已测量；
- 生产流之外存在稳定的人工锚点流；
- 模型、提示、示例、解析器和后端信号都有版本记录；
- 门禁允许“调查”和“人工复核”，而不是强迫二元结论；
- 阈值、样本量与重复预算来自本任务风险，而不是复制别人的数字。

LLM 裁判最适合扩大人工判断，而不是取代事实标准。保存两条证据流、持续校准，并允许不确定性进入发布决策，分数才从一个漂亮数字变成可管理的测量结果。