不少团队把LLM-as-a-Judge后面再接一层人工复核原本想补模型评分盲区最后却出现更难解释的结果同一条回答上午判通过下午换个评审人就被打回。⚠️ 线上投诉一来团队才发现离线均分不低失控的却是判分一致性。更麻烦的是这类波动很容易被误判成“评审人不够专业”。 实际上问题常不在人而在评分规则没冻结、边界样本没锚点、模型评委和人工评委也不在同一把尺子上。 一旦评测集开始服务上线门禁这种漂移就会把高分样本送进错误发布窗口。图 1平均高分不等于判分稳定 为什么人工复核一接进来反而更容易高分低一致第一层误区是把 rubric 当成描述性文档而不是执行协议。 很多表述像“基本正确”“可接受误差”“轻微幻觉”看似清楚到边界样本上却会被不同评审人各自解释。模型评委还能靠固定 prompt 勉强维持尺度人一多隐含标准就开始漂。第二层误区是只看平均分不看分歧面。 两个宽松评审加一个严格评审均分可能仍然漂亮但真正决定上线风险的是同一样本能否稳定落到同一档。若没有版本化 rubric 和升级规则团队拿到的不是评测结论而是一组无法审计的意见。评测方案人工复核一致率边界样本改判率线上误放风险只看平均分61%19%高rubric 冻结76%9%中锚点样本与校准88%3%低图 2分歧常来自规则漂移️ 一组回放把瓶颈定位到 Rubric Freeze 与 Rater Calibration在一组1200条生产回放里样本覆盖问答、工具调用和拒答场景。 基线组允许评审人直接按经验判分第二组引入rubric_version和60条锚点样本第三组再加每周校准会、分歧升级和模型评委预排序。结果不是分数涨了多少而是Cohens kappa从0.47拉到0.83误放率从14%压到2%。✅真正起作用的不是多找几个人复核而是先把“什么叫正确”冻结再把“谁在什么条件下能改判”写进流程。 当边界样本先对齐人工复核才像控制面否则它只会把主观差异扩散到整个评测集。对上线门禁来说可升级的争议样本比漂移分数更有价值。defreview_decision(llm_score,human_scores,rubric_version,anchor_hit):spreadmax(human_scores)-min(human_scores)ifspread2ornotanchor_hit:return{action:escalate,rubric_version:rubric_version}final_scoreround((llm_score*0.3)(sum(human_scores)/len(human_scores))*0.7,1)return{action:accept,score:final_score,rubric_version:rubric_version}review_pipeline:rubric_version:v2026-05-11anchor_set_size:60disagreement_threshold:2llm_judge_role:pre_rank_onlyescalate_when_anchor_missing:trueweekly_calibration:true图 3先对齐边界样本再谈人工复核 真正该治理的是评分协议不是继续堆评审人数很多团队一看到分歧就继续加评审人、加复核轮次觉得样本看得越多越稳。 但只要 rubric 还在漂人数越多只会把分歧面铺得更大。系统更该记录rubric_version、评审人 id、改判原因、锚点覆盖率以及哪些样本被升级到仲裁层。 这些字段一旦缺失后续再拿评测集做训练回流噪声会直接写回数据资产。笔者认为模型评测现在最缺的不是更多分数而是让不同分数可以互相对账的协议层。LLM-as-a-Judge适合做预排序和筛查人工复核适合处理边界和高风险切片但两者之间必须有冻结 rubric、锚点样本和校准节奏。 否则所谓“高分”只是在平均值上好看真正的上线质量并没有被稳定度量。图 4可追溯改判评测才能进生产 未来 3 到 6 个月更值得补的评测能力接下来3到6个月评测平台大概率会把 rubric 版本管理、锚点样本回放、评审人校准面板和分歧升级队列做成一等能力。⭐ 谁先把“一致率、改判率、误放率”放到同一块控制面里谁就更容易把模型升级从经验判断改成可审计流程。 你们现在的复核链路保存的是意见还是能复用到下一轮发布的评分协议