LLM-as-a-Judge 怎么避免自嗨：位置偏差、评分漂移和人工校准要一起测

让一个模型给回答打分，能把评测速度从人工小时缩短到分钟，但它不是客观裁判。评审模型可能偏爱更长、更像模板的回答，可能总是选择第一个候选，也可能对同家族模型更宽容。没有校准的评分表，很容易让团队优化到“讨好评审”而不是解决用户问题。

先做顺序和长度盲测

把 A/B 回答随机交换位置，观察胜率是否变化；把同一答案压缩或扩写，观察分数是否被长度影响。对事实问答、工具任务、写作和安全策略分别建样本，因为同一种评审提示词不适合所有任务。评分结果应保留评审版本、提示词版本、温度和原始理由摘要。

人工标注不是为了替代全部自动评测，而是为了建立锚点。定期抽取有争议、低置信和高影响样本，由至少两位审阅者独立标注，再比较人机一致性和人工之间的一致性。若评审模型与人工持续偏离，应修订任务定义或换评审方法，而不是强行相信自动分数。

防止评分随时间漂移

评审模型、系统提示词、工具和数据集变化后，历史分数可能不再可比。要保留固定基准集，按版本重跑；对分数突然变化的任务检查是候选模型变了、评审模型变了，还是数据分布变了。评分理由也只能作为辅助证据，不能自动当作事实。

DeepEval、PromptBench 等框架提供评测编排能力，但指标定义和人工校准仍由团队负责。工具可以让实验可重复，却不会自动消除偏见。

如果需要比较多个候选模型，可在 top-api.cc 固定请求、模型参数和样本版本，再把候选输出交给独立的评审流程。不要让同一模型既生成答案又单独决定自己是否最好。

最小评测矩阵

• A/B 位置交换后的胜率；
• 不同长度和文风的评分变化；
• 自动评分与人工评分的一致性；
• 评审模型和提示词版本漂移；
• 高风险任务的人工复核覆盖率；
• 低置信、平分和冲突样本的处理方式。

参考资料：DeepEval、PromptBench 的公开文档与 LLM-as-a-Judge 研究。分数是决策输入，不应替代明确的业务验收标准。

在 top-api.cc 保存候选调用元数据后，可以在评审结果异常时快速回放相同样本，而不会把参数变化混入结论。