更新一版提示词，生成新答案，再让另一个大模型打分。分数从 7/10 跳到 9/10。看起来是进步。但真正变好的是答案的正确性、表达方式，还是它讨好评估器的能力？对 AI 工程师来说，评估流水线值得和应用程序本身投入同样的注意力。

所谓 LLM-as-a-Judge（用大模型当裁判），就是让一个语言模型去评估另一个模型的输出。你提供问题、候选答案和评估标准，也可以附上源文档或参考答案，裁判随后打分或选出更好的那个答案。这能让评估规模化，但裁判本身也有局限。

论文《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》考察了这类局限，包括位置偏见、冗长偏见和推理错误。这些都是评估流水线里值得测试的失效模式。

  • 位置偏见：候选答案的先后顺序会影响裁判的偏好。
  • 冗长偏见：更长的答案可能拿到更多分，哪怕多出来的细节价值不大。
  • 推理错误：裁判可能接受一段听起来有说服力、实则包含事实或逻辑错误的解释。

一份详细的评估说明有助于人工检查，但它并不能证明这个判断是对的。

看一个虚构的退订政策例子：客户可在购买后 14 天内取消，政策不设例外。问题是：购买 20 天后还能取消吗？

候选答案 A 说：不能，政策允许 14 天内取消，20 天已超出这个窗口。候选答案 B 说：可以，虽然标准窗口是 14 天，但客户可以联系客服申请延长到 30 天。B 听起来更贴心，却凭空发明了一个例外。

设想裁判给出不同结果：问题、证据和候选答案都没变，被偏好的答案却变了，这就暴露出顺序敏感性。这里要追踪的是底层候选答案本身，而不是它显示的位置，否则调换标签会让一致的判断看起来前后矛盾。

怎么搭一套更可靠的评估？

  1. 定义具体标准。“给这个答案打 1 到 10 分”留了太多解释空间，应拆成独立维度分别打分。分开的分数能暴露取舍：一个答案可以既相关又好读，同时包含没有依据的说法。
  2. 提供证据并做直接校验。基于文档的问题，把相关源文本交给裁判；涉及计算，尽量用代码核对结果；结构化输出，直接校验 schema。把模型判断留给需要解释的方面，与能精确验证具体属性的检查并用。
  3. 测试答案顺序敏感性。准备 20 个问题，每题一对候选答案，每对按两种顺序各评一次，20 组配对比较共产生 40 次判断。把每个结论映射为三种结果之一：A 胜、B 胜、平局。顺序变化率定义为：映射结果发生变化的配对数 ÷ 总配对数。按这个定义，A→B、A→平局、平局→B 都算变化，平局→平局不算。也可以单独报告严格反转，即只有 A→B 或 B→A。保留平局能让指标更容易解读。
  4. 与人工复核的样例对比。建一个小评估集，包含正确、错误、不完整和无依据的答案，让评审者用同一套评分标准和支撑证据，再检查他们与模型裁判的分歧。人工复核同样需要质量控制：标准含糊或参考判断有误，都会让一致性变得具有误导性。在把那些标签当作可靠基线之前，先解决不清楚的案例。

这些防护措施证明不了什么？裁判可以始终偏好同一个答案，却依然是错的。顺序一致性衡量的是在某一项变化下的稳定性，本身并不衡量事实准确性。同样，与人工评审者的一致只有在他们的判断可靠时才有用。这些检查提供的是不同侧面的证据，没有任何单一分数能证明评估器在所有任务上都可靠。

工程上的结论是：在把更高的评估分数当作改进之前，先检查评分标准、支撑证据、顺序敏感性和与可靠人工判断的一致性。当一个大模型在评判你的应用时，这个裁判就成了另一个你需要评估的组件。