做 Agent 的团队迟早会撞上同一个问题：改了提示词、换了模型、调了检索参数，这版到底是变好了还是变差了？人工看几十条还行，上千条就看不过来；让写提示词的人自己评，又容易「看我孩子多漂亮」。于是越来越多人开始让大模型来当裁判，也就是常说的 LLM-as-Judge。
但它不是万能药。评分器本身也会偏——偏爱长答案、偏爱靠前的选项、偏爱跟自己风格接近的输出。用一把歪的尺子量东西，量得越多，错得越稳。这篇把评分器从设计到校准的六步讲清楚，包括哪些事根本不该交给大模型打分。
先分清：哪些检查不该用大模型
这是最容易走弯路的地方。很多团队一上来就用大模型评一切，结果又慢又贵还不稳定。其实检查项应该按「能不能客观判定」分工：
- 规则能判的，别用模型。格式对不对、字段有没有缺、JSON 能不能解析、链接是不是能打开、金额算得对不对——这些用代码判断是确定的，交给模型反而引入随机性。
- 检索类可以半自动。答案里出现的数字是否来自给定资料，可以先做「原文命中校验」这种偏规则的检查。
- 只有主观质量才交给大模型。回答是否切题、语气是否合适、有没有答非所问、结构是否清晰，这类没有唯一答案的判断，才是 LLM-as-Judge 的主场。
换句话说：能用程序断言的，用断言；只能靠人感觉判断的，才请模型代判。这条线划不清，评分系统第一步就烂了。行业里已经有人把评分器和评测集一起当成上线门槛的一部分（Agent 评测正在进入工程日常），但门槛内部怎么造，还得自己动手。
LLM-as-Judge 的四种评分形态，别只会一种
很多人只用「打 1 到 5 分」这一种，结果分数全挤在 4 分，区分度几乎为零。其实有四种形态，用途完全不同：
（1）单点打分。给一条答案和一份标准，让模型给分并说明理由。优点是能横向比较不同批次，缺点是最容易发生「分数通胀」，模型倾向于给安全的中高分。
（2）成对比较。同一个问题给 A、B 两版答案，让模型选哪个更好。这是区分度最高的一种，适合做 A/B 对比实验，缺点是没法直接给出绝对质量。
（3）多维度 rubric 打分。把「好不好」拆成 4 到 6 个独立维度分别打分，比如准确性、完整性、可执行性、引用是否到位、格式合规、有无越权承诺。这是生产环境最实用的形态，因为出问题时你能定位到具体是哪个维度塌了。
（4）绝对判断。只回答「通过与不通过」「能不能直接发给客户」，适合红线类检查，比如有没有编造数据、有没有泄露不该出现的字段。
实操建议是组合使用：成对比较做版本选择，多维度 rubric 做日常监控，绝对判断守红线。评测的整体框架和指标怎么搭，站内 AI Agent 评测怎么做 有完整拆解；本文只往下钻评分器这一层。
第一步：把评分标准写成「可判定」的样子
评分不准，八成是 rubric 写得太虚。像「回答要有帮助」这种标准，模型只能靠感觉发挥，不同批次自然飘。可判定的 rubric 需要三样东西：
- 能观察的具体特征。不要写「专业」，要写「引用了给定资料中的字段名和数值」「给出了可执行的下一步动作」「明确说明了数据来源」。特征必须能在这段文本里指出来。
- 每一档的正反例。同一维度下，5 分长什么样、3 分长什么样、1 分长什么样，各配一句真实例子。这是提升一致率最有效的一招。
- 明确不扣分的情况。写清「不影响评分」的情形，比如长度、口语表达、标点习惯。不写清楚，模型就会自己脑补标准。
还有一个细节：维度不要贪多。超过 6 个维度，模型注意力会被稀释，一致性反而下降。宁可先把 3 个核心维度跑顺，再逐步加。
第二步：三类偏差，必须提前处理
这是 LLM-as-Judge 最实的部分，处理不好前面全白做。
（1）位置偏置。成对比较时，模型容易偏向先看到的那一个（也可能偏向后看到的，取决于模型）。对策简单也有效：同一个对比跑两次，两次把 A、B 顺序对调，只采纳结论一致的样本；顺序一换结论就翻的，记为「平局」或转人工，别硬算。
（2）长度偏置。模型普遍偏向更长的答案。对策有两个：把长度写进 rubric 明确为「不评分项」；以及在样本构建阶段控制长度分布。评测样本该怎么覆盖失败边界而不是只堆长答案，评测样本怎么建 里有具体做法。
（3）自我偏好。用同一个模型既生成答案又当裁判，它会偏爱自己的输出。生产环境要尽量让裁判模型和选手模型不是同一个；退一步，也要避免使用同一系列的同一代模型。
除此之外还有个高频问题：分数集中。如果九成样本都落在同一个分数，说明 rubric 没有区分度，此时宁可切成对比较，或者改成「有/无」这类更硬的判断。
第三步：先跟人工对齐，再谈放量
评分器写完不要直接上生产线，先做一次校准：
- 从真实样本里抽 50 到 100 条，覆盖好、中、差三档，也要包含几条「边界争议」的。
- 让至少两个人独立打分，先把人跟人之间的分歧解决掉——人都不一致，就没资格要求模型一致。
- 让评分器打同一批，算一致率（分类场景看 Kappa，成对比较看同向率）。
- 达不到目标就先改 rubric，不要去调模型温度来「凑分数」。一致率不达标就把评分器放出去，等于给自己造了一堆没法解释的数据。
这里有个容易忽略的点：人工结果也不是真理，只是当前的参照物。人工打分同样会飘，所以校准要定期重做，而不是做一次就永久生效。站内 人工复核抽检怎么做 讲的正是同类思路的落地方式。
第四步：评分器本身也要版本管理
这条经常被忽略，但事故往往出在这里。你改了 rubric、换了裁判模型、动了提示词，等于换了一把尺子。这时候拿新分数跟历史分数直接比，得出的「提升了 12%」其实是假的。
做法是：给评分器一个版本号，把 rubric 文本、裁判模型与版本、解码参数一起记录；分数落库时带上评分器版本；跨版本比较只能看趋势方向，不能看绝对值。这和 模型版本管理 是同一套思路——两边都变了，就必须用同一批样本回放一遍才能讲因果，具体玩法见 回放评测怎么跑。
第五步：用抽检和门禁兜住最后一公里
自动评分再准也只是抽样，上线前该守的门还是要守：
- 红线项走绝对判断，任何一条不通过直接拦下来，不进平均分。
- 分数只作准入参考，不能替代 质量门禁 里的硬检查。
- 按维度做分层抽检：低分样本、分数突变样本、新出现的意图类型这三类必看；高分样本按比例随机看。抽检结论要能回流到 rubric，否则等于白看。
- 保留原始材料。评分时用的输入、答案、评分理由一起留档，事后有争议才有得查，可参考 变更后验证清单 的留痕思路。
四个常见误区
误区一：把评分器当真理。它是快速近似，不是裁判文书。有争议时以人工判断为准。
误区二：只看平均分。平均分从 3.8 涨到 3.9，可能是一批原本很差的样本变好了，也可能是高分样本被稀释。一定要同时看分布、看分维度、看最低的那 10%。
误区三：用同一批样本反复调 rubric。这等于拿测试集当训练集，分数会一路好看，真实效果不动。调 rubric 用的样本和最终验收的样本要分开，这也和 用真实失败样本建评测集 的原则一致。
误区四：只测不改。评分器评出来的问题如果没人跟进，它就只是个昂贵的仪表盘。分数要和具体修改动作绑起来：谁改、改完再跑哪批样本，都写清楚。
适合谁用，不适合什么
适合：有稳定评测样本、每天有几十到上千条输出需要判断、正在做提示词或模型迭代的团队；需要持续监控线上回复质量的客服、写作、助手类 Agent。
不适合：样本只有十几条的小项目——人工看完更准也更省；以及没有明确定义「什么算好」的场景——标准都说不清，让模型去猜只会放大混乱。
一句话总结：评分器不是让机器替你做决定，而是把「什么是好」这件事写下来，然后让机器帮你反复核对。写不下来的标准，交给谁都评不准。
