考察点
LLM-as-Judge 是现在大模型应用评测的事实标准，面试官问这个是在探你评测体系的成熟度：知道「拿 GPT 打分」只是入门，知道打分本身会系统性出错、并且知道怎么校正，才算做过真评测。追问常落在「怎么验证 judge 本身准不准」和「judge 成本和覆盖率怎么平衡」。
参考答案
Judge 的偏差是系统性的，不是随机噪声
用人评分的直觉去套 LLM 评分会踩坑。LLM-as-Judge 的偏差是方向固定的系统性偏差，不校正的话评估结论可能整个是反的。常见的几类：
- 位置偏差：成对比较时偏向放在前面（或后面，视模型而定）的那个答案。实测中换序后结论翻转的比例经常超过 10%。
- 冗长偏差：更长、结构更华丽（分点、加粗、表格）的回答容易得高分，哪怕核心内容一样甚至更差。
- 自我偏好：模型倾向给和自己同系列模型生成的答案打更高分。用 GPT 评 GPT 系应用、用 Claude 评 Claude 系应用都会虚高。
- 宽容偏差（分数膨胀）：让打 1-5 分，分布会挤在 3.5-4.5，区分度很差；开放生成任务上尤其明显。
- 事实盲区：judge 没有 ground truth 时，会把「看起来流畅但事实是错的」答案评成好答案，judge 自己也会幻觉。
偏差控制的工程手段
第一，任务设计层面降自由度。 能二选一就不打分。成对比较（A/B 哪个好）的稳定性远好于绝对评分，因为比较消除了「什么算 4 分」的标尺问题。必须打分时，把 1-5 分改成更细的 0/1 判定清单：「是否包含 X」「是否引用了给定文档」「是否泄露敏感信息」，逐项判定后汇总，比让模型拍一个总分可靠得多。
第二，rubric 写到可执行。 差的 rubric：「回答是否准确」。好的 rubric：「回答包含且仅包含文档中的三个要点，每命中一点得 1 分，出现文档以外的事实性陈述扣 1 分」。rubric 里给正反例（few-shot），judge 的一致性会明显提升。关键维度拆成多次独立调用去评，一次只问一个问题，比一个大 prompt 问五个维度更稳。
第三，随机化消除位置效应。 成对比较时 A/B 顺序随机，正式评估时每个 pair 正反序各评一次，两次结论一致才采纳，不一致标记为争议样本送人工。成本翻倍，但这笔钱不能省。
第四，judge 选型上回避自我偏好。 评测对象的模型和 judge 用不同厂商/不同系列，有条件就用明显强一档的模型当 judge（评 7B 应用用旗舰模型）。同一个评估报告里固定 judge 不变，跨版本对比才有意义——judge 换了，历史分数就不可比了。
第五，防事实盲区靠喂上下文。 评 RAG 类应用时，把检索到的文档原文连同问题、答案一起给 judge，明确要求「只依据提供的文档判断」，而不是让 judge 用自己的参数知识。能解析出结构化事实的场景，优先用程序校验而不是 judge。
Judge 本身的可信度怎么度量
核心做法是人工校准集：固定抽 100-300 条样本由人仔细标注作为金标准，定期算 judge 与人工的一致率（Cohen's Kappa 或简单 agreement）。一致率低于阈值（经验上 80% 以下就要警惕）就停下来调 rubric、换 judge，而不是继续用不可信的分数做决策。judge 的 prompt 也要进版本管理，每次改动都在校准集上重测——把 judge 当成一个需要回归测试的模型组件。
另一个实用技巧是对抗抽检：故意构造一些有明确错误但写得漂亮的答案混进评测流，看 judge 能不能抓住。抓不住的维度就是盲区，要么补 rubric，要么这个维度改回人工评。
成本与覆盖率
全量人工评不起，全量 judge 也贵。常见配比：离线评测集全量 judge（几百到几千条，成本可控）；线上流量按 1%-5% 抽样 judge，再按 0.5% 抽样人工校准。judge 调用本身可以批处理、用小一号模型做初筛（明显的满分/零分快速过）、只把中间分段送强 judge，成本能压一个数量级。
可能的追问
- 为什么不直接全用人工评？ 答：成本和周期。一次 prompt 迭代要评几百条，人工要好几天，judge 几小时跑完；且人工标注员之间本身也有一致性问题（经验上人对人的一致率也就 85% 上下），人不是金标准，只是参照物。
- judge 和人工一致率已经 90% 了，是不是可以放心全自动？ 答：小心幸存者偏差——校准集往往是早期采的，分布会漂。要持续从线上新流量里补充校准样本，尤其模型或 prompt 大改之后必须重新校准，旧的一致率结论不自动延续。
- 多维度评分（准确性/流畅性/安全性）怎么聚合？ 答：别加权平均成一个总分，安全类一票否决，其余维度分开报告。聚合会掩盖信息：安全 0 分、其他满分的回答平均分 4，看起来像个好答案。