LLM评委分数漂移：夜间评测门禁为何误报

一位开发者维护的客服Agent每天夜间会针对一万条历史工单进行自动评测。某天早晨，运行结果变红。没有合并任何Prompt变更，模型版本被固定，检索索引也未重建。排查配置差异无果后，答案出现在评委日志里：同一张工单的同一回复，前一晚得分0.7，当晚得分0.6，而通过线恰好是0.7。Agent两晚完全一致，但评委对相同输入给出了不同评分。

这并非孤例。LLM评委每次运行都会给出略有差异的分数，当门禁评估数千个用例时，部分红色警报其实是评委在“自我分歧”。

回归门禁需要可重复的判定

LLM-as-a-judge在评判复杂输出时表现优秀：给强模型一份评分标准，它返回分数并附上一句解释，这句解释在调试单个Bad Case时极为有用，可以阅读、质疑并记录。

但门禁要求的是另一回事：对相同输入每次必须返回相同判定，这样失败用例才意味着Agent真正退化。代码检查和语义校验器天然满足这一要求，可以独立支撑门禁。而LLM评委需要变通方案，比如对重要用例平均多次评委运行结果，但这会成倍增加最慢、最昂贵检查的成本。

LLM评委的方差从何而来。 即便推理服务商把温度参数设为0，多路并发下的输出仍可能有细微差异——这不是Bug，而是当前推理栈的常态。原因之一是浮点运算的非确定性：GPU并行归约、算子融合顺序、批量大小不同都会让同一输入落入不同的累加路径。原因之二是批次效应：评委在同一批里看到的其他用例会通过注意力机制间接影响当前用例的对数概率分布，因此单独跑和连着跑可能得到不同分数。原因之三是服务端版本漂移：权重虽被固定，但推理内核、量化方式、上下文分块策略都可能在供应商侧静默更新，用同一API字符串调用的其实不是同一套计算。三者叠加，就产生了“模型版本被固定、索引未重建，分数却变了”的现象。要诊断，可对同一批输入连续跑五到十次，观察分数分布是否重叠在通过线两侧——若重叠，说明该阈值无法区分真实退化与噪声。

类型化评委的取舍

据“JEV-as-a-Judge: Accept When Confident, Escalate When Unsure”论文，JEV是TypeSafe AI推出的类型化评估器，定位为快速直觉打分的“System One”模型。其最显著区别在于输出：JEV返回类型化判定（是/否、多项选择或有序刻度上的点）并附带校准概率，完全不写推理过程。

论文数据显示，JEV中位延迟0.15秒，成本仅为最强对比模型费用的0.36%；当判定可直接从给定文本读取时，与GPT-6的差距在三个百分点以内。但在数学、代码、逻辑等需要推导的任务上，差距会拉大。这些数据基于论文的基准设置，实际流量表现需自行测量。

JEV用放弃书面推理换取可重复性。对于每晚运行的回归套件，这个取舍值得。

什么是“类型化”评估器。 “类型化”指输出落在预先定义好的取值集合里：布尔、固定选项、或离散刻度上的点，而不是一段自由文本。这带来两个工程好处。其一，判定可被程序直接消费，无需再解析自然语言——解析本身就是一次潜在错误来源。其二，取值空间有限意味着概率分布可用，模型可同时给出“选此项”和“有多大把握选此项”，即校准概率。所谓校准，是指模型声称80%把握时，长期看其中约80%是对的；未校准的分数只是相对大小，不能当阈值使用。类型化评委把这套机制压缩成一次前向传播：无推理链、无自回归解码，因此延迟可低至亚秒级、成本按调用量线性可比。代价是它无法处理需要多步推导的任务，因为那些任务的答案不在给定文本里，而在文本推导之后。

概率是最高频使用的部分

校准概率改变了评委的接入方式：高置信度时直接接受判定，低置信度时路由给更强的推理评委或人工处理，使类型化评委成为昂贵检查前的分诊步骤。

阈值需自行设定，并先在自己标注的用例上验证，因为照搬他人基准的截断值只描述他们的数据。

一个Agent，四种检查，四种方法

根据检查内容选择方法，在客服Agent上分为四类：

格式检查：回复是否为含必填字段的合法JSON，由代码检查负责，确定、即时、免费。

参考一致性：回复是否匹配该工单的已知解决方案，用语义校验器低成本处理。嵌入回复与参考后取余弦相似度，超过阈值即通过。轻量模型如all-MiniLM-L6-v2可本地运行，阈值从0.75起调，太低会放过错误答案的转述，太高会漏掉措辞不同的正确答案。

语气判断：礼貌与品牌调性属于主观判断，LLM评委在此体现价值。采用点式评分，单答案对照阈值。需要排序时切换成对比较并运行两个顺序，因为模型倾向偏爱先读到的答案。

大批量门禁：每晚一万条历史工单的高通量门禁，正是类型化判定的用武之地。

为什么四种方法不能合并成一种。 每种检查的“答案空间”不同，决定了它天然适合哪种实现。格式检查的答案是预定义的合法与否，属于有限状态判定，代码在纳秒级完成且绝对可复现。参考一致性的答案是“语义是否等价”，本质是连续空间中的距离比较，语义校验器把它降维成余弦相似度这一标量。语气判断的答案是“是否符合主观标准”，没有可精确书写的规则，只能由能理解自然语言的模型来近似。大批量门禁的答案是“这批里哪些退化”，需要在固定预算下对一万条逐条给出可复现的通过或失败。把这四种塞进同一个LLM评委，等于让一个擅长主观判断的组件去承担它最不擅长的确定性任务，既浪费成本又引入方差。反过来，把语气判断交给正则表达式，则会漏掉所有措辞不同但真正礼貌的回复。

仍需推理段落与人工介入的场景

两类场景保留推理评委或人工介入：

推导类任务。判定依赖检查数学、代码或多步论证时，类型化评委差距扩大，这类情况默认升级。

对抗性输入。类型化和生成式评委都会读取被评分内容，而内容可能携带针对评委的指令。书面推理无法可靠暴露Prompt注入，类型化判定事后可调查的信息更少。当评委参与安全或审核决策时，应视其输入为不可信，隔离评估指令，测试对抗样本，在策略可精确书写处使用确定性规则，并将不确定案例转人工审查。

给红警报早晨之前的自己的建议

• 用有方差的评委做门禁：无法复现的红色构建可能是评委方差，门禁应使用低方差检查。
• 将相似度当作真相：“巴黎是法国首都”和“巴黎不是法国首都”相似度极高。翻转一个词即改变判定的场景，需搭配规则或评委。
• 借用置信阈值：先在自己标注上校准。
• 让一个评委评所有东西：格式、参考、语气和数量各有适配方法，多数生产Agent需三到四种并行。

完整的对比、决策表以及语义校验器和LLM评委模式的Python示例可参考原文链接。

你的套件中哪个检查在毫无变化时变红？对这位开发者而言是夜间回归门禁，修复方案是交给一个几乎每次给出相同答案的检查。