LLM-as-Judge 工程化

LLM-as-Judge 的价值不是让另一个模型替团队“拍脑袋”，而是把原本只能人工逐条看的质量判断，扩展成可重复、可抽检、可校准的评估流程。

它适合判断语义质量、证据支持、引用准确性、工具调用理由和 Agent 轨迹问题。但它也会偏、会漏、会被答案风格影响。没有人工标注和 rubric 校准的 judge，本身就是新的不确定性来源。

提出问题：为什么自动评分既需要也危险

假设一个企业知识助手每天产生 3 万条回答。团队希望每次改模型、prompt、检索参数前，都能知道答案质量有没有下降。

人工专家可以判断答案是否准确，但无法每天看几千条；规则可以检查 JSON schema、引用 ID 是否存在，却无法判断“引用是否真的支撑这句话”。这时团队自然会想到用 LLM-as-Judge。

问题在于：如果 judge 只是收到“请给这个答案打 1 到 5 分”，它可能更偏好长答案、礼貌语气或看起来完整的解释；也可能用自身常识补足缺失证据，把不该通过的答案判为通过。

所以 LLM-as-Judge 要被当作评估系统来设计，而不是一个额外 prompt。

分析问题：Judge 应该评什么，不应该评什么

LLM-as-Judge 适合处理需要语义判断的部分，不适合替代确定性校验。

判断对象	适合 Judge 的部分	应由程序处理的部分	人工必须介入的部分
答案质量	是否覆盖要点、是否自洽、是否符合口径	schema、长度、敏感词、必填字段	高风险业务承诺
RAG Faithfulness	claim 是否被证据支持	引用 ID 是否存在、权限过滤	争议证据、法规合同样本
Citation Accuracy	引用是否支撑对应句子	引用格式、文档版本	高影响引用错误
Tool Eval	工具选择理由是否合理	工具名、参数类型、权限、幂等	写入动作、退款、删除
Agent Eval	是否目标漂移、是否循环、恢复是否合理	步数、预算、timeout、重复调用计数	事故轨迹和边界定义

收益是扩展评估规模、降低人工成本、快速发现回归；风险是 judge 偏差、标准漂移、幻觉补全、对模型家族过拟合和被待评答案影响。

因此，Judge 的输出应该是结构化判断，而不是自由评论。它要给出标签、理由、证据定位和置信度，并接受人工抽检。

列举方案：从规则到校准后的 Judge

第一层，优先用确定性校验。

如果问题是 JSON 是否合法、字段是否缺失、工具参数类型是否正确、引用 ID 是否存在，就不需要 judge。程序校验更稳定、更便宜、更可解释。

第二层，使用 rubric 评分。

rubric 要把“好答案”拆成明确维度，例如：

维度	通过标准	不通过标准
正确性	关键结论与标准答案或证据一致	与证据矛盾、遗漏关键限制
完整性	覆盖必须要点	漏掉风险提示、审批条件或下一步
Faithfulness	每个关键 claim 都能被证据支持	使用证据外信息补充事实
引用准确性	引用支撑对应句子	引用只主题相关但不支撑结论
安全边界	该拒答时拒答，该转人工时转人工	越权回答或直接承诺高风险动作

第三层，使用结构化 Judge 输出。

{
  "verdict": "fail",
  "dimensions": {
    "faithfulness": "fail",
    "citation_accuracy": "pass",
    "completeness": "partial"
  },
  "unsupportedClaims": [
    {
      "claim": "年付客户可以自动退差价",
      "reason": "证据只说明需要财务审批，没有说明自动退款"
    }
  ],
  "confidence": 0.82
}

第四层，做人工校准。

校准流程建议是：

先由人工标注一批基准样本。
用 judge 对同一批样本评分。
比较 judge 与人工的一致率、误杀率和漏放率。
修改 rubric、prompt 和输出 schema。
固定 judge 版本，进入回归评估。
按风险等级抽检线上 judge 结果。

第五层，按评估对象拆 judge。

RAG Judge 只能基于给定证据判断，不允许使用常识补全。Tool Judge 要看用户意图、工具契约、参数来源和权限结果。Agent Judge 要看完整 trace，包括目标、计划、观察、工具调用、恢复和停止条件。

不要用一个“全能评分 prompt”同时评答案、检索、工具和 Agent。它会让评分看起来统一，但失去定位能力。

决策判断：什么时候可以信任 Judge

场景条件	推荐方案	不推荐方案	判断理由	额外成本
格式、schema、权限、超时	程序校验	LLM-as-Judge	确定性问题不需要语义判断	规则维护
低风险文案质量	Judge + 少量人工抽检	全量专家审核	语义判断多，失败代价低	rubric 和抽检
RAG 证据忠实性	Evidence-bound Judge + 人工校准	让 judge 自由判断事实	必须限制在证据内	claim 拆分、证据输入
Tool 调用质量	规则校验 + Judge 解释判断	只看工具返回成功	工具成功不代表该调用	工具契约和轨迹记录
Agent 轨迹质量	Trace Judge + 人工复盘	只评最终答案	过程风险需要轨迹判断	trace 存储和抽检
高风险合规、财务、医疗	Judge 初筛 + 专家终审	自动 judge 直接放行	失败代价高，责任不能外包	专家队列和仲裁

明确判断是：Judge 可以成为评估流水线的一部分，但不能成为唯一质量来源。越接近事实、权限、执行和高风险承诺，越需要程序校验和人工确认共同参与。

常见反模式包括：

让 judge 直接给总分，却没有维度和失败原因。
judge prompt 没有证据边界，导致它用常识替答案补洞。
待评答案和参考答案顺序固定，造成位置偏差。
用同一个模型生成答案又评答案，未做人工校准。
judge 结果直接作为上线门禁，却没有误杀、漏放和抽检记录。

结论收束：Judge 要被评估，才能评估别人

LLM-as-Judge 的推荐用法是：先用规则处理确定性问题，再用 rubric-bound judge 处理语义问题，最后用人工标注持续校准。它不是人工标注的替代品，而是人工标准的放大器。

上线前检查清单：

Rubric：是否定义清楚每个维度的通过、部分通过和失败标准。
输入边界：RAG judge 是否只看到允许证据，Tool judge 是否看到工具契约，Agent judge 是否看到完整 trace。
输出结构：judge 是否返回标签、理由、证据定位、置信度和失败类型。
人工校准：是否有人类基准集、一致率、误杀率和漏放率统计。
抽检机制：是否按风险等级抽检 judge 结果。
版本管理：judge prompt、模型、参数和 rubric 是否可追溯。
门禁策略：judge 失败是否进入阻断、降级、人工审批或豁免流程。
反馈闭环：线上争议样本是否回流校准 judge。

当任务低风险且主观质量占主导时，可以更依赖 judge。只要判断涉及事实、证据、权限、工具执行或业务责任，就必须让 judge 和规则、人工、日志一起工作。

#LLM-as-Judge 工程化

#提出问题：为什么自动评分既需要也危险

#分析问题：Judge 应该评什么，不应该评什么

#列举方案：从规则到校准后的 Judge