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

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

正确的问题不是“怎样让 LLM 完全确定”，而是“这次变化来自哪一层，证据足不足以改变发布决定”。把裁判模型当作测量仪器，而不是答案机器，评测才有机会成为工程控制。

先画清楚两个随机层

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

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

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

因此需要两种不同的复跑：

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

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

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

这不只是省钱。确定性检查把故障定位到明确合同，避免裁判用“整体感觉不错”掩盖硬错误。OpenAI 当前的评测最佳实践同样建议采用任务相关的评测、持续评测，并用人工反馈校准自动评分；其 Graders 指南也把字符串检查、相似度检查和模型评分区分为不同工具。

一个实用的评分合同可以先拆成三层：

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

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

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

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

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

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

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

另一项公平裁判研究展示了仅改变候选答案的出现顺序就可能改变排名，并提出多证据、平衡位置与人工介入的校准方法。随后一项覆盖 12 个裁判、22 类任务和十万余次评测的位置偏差系统研究进一步表明，偏差会随裁判和任务而变化。换句话说，“这个模型很强”不能替代对你自己的任务进行验证。

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

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

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

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

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

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

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

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

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

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

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

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

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

校准不是把均值调到一致

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

校准记录至少要回答：

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

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

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

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

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

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

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

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

2026 年的预印本 Who Drifted: the System or the Judge?把这种归因问题形式化：让当前裁判持续重评固定的人工标注锚点，并把裁判相对人工的差距与生产监控分开。论文的具体检测率和成本来自其设置，不是部署保证；但“只有裁判变化才会改变固定锚点上的裁判差距”是非常有用的工程识别思路。

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

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

一个可靠门禁不应写成“新版本平均分大于旧版本就通过”。它需要先完成证据路由：

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

最终状态可以是：

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

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

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

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

OpenAI 的一篇历史复现示例说明，在当时支持的 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 裁判最适合扩大人工判断，而不是取代事实标准。保存两条证据流、持续校准，并允许不确定性进入发布决策，分数才从一个漂亮数字变成可管理的测量结果。