LLM-as-a-Judge

LLM-as-a-Judge 是用一个更强的 LLM 来评估 Agent 回答质量的方法。它比人工评估快,比规则评估灵活。

#type / concept #status / evergreen #tech / ai

[!info] related notes

LLM-as-a-Judge

一句话定义

LLM-as-a-Judge 是用一个更强的 LLM 来评估 Agent 回答质量的方法。让 GPT-4 评估 GPT-4-mini 的回答,比人工评估快,比规则评估灵活。

核心原理

评估 Prompt

JUDGE_PROMPT = """
你是一个评估专家。请评估以下回答的质量。

用户问题: {query}
Agent 回答: {answer}
参考答案: {reference}

请从以下维度评分 (1-5):
1. 正确性: 回答是否事实正确
2. 完整性: 是否覆盖了问题的所有方面
3. 相关性: 回答是否与问题相关
4. 有用性: 回答是否对用户有帮助

输出 JSON:
{{"correctness": N, "completeness": N, "relevance": N, "usefulness": N, "reason": "..."}}
"""

Python 实现

class LLMJudge:
    def __init__(self, judge_llm):
        self.judge_llm = judge_llm

    async def evaluate(self, query: str, answer: str, reference: str = "") -> dict:
        prompt = JUDGE_PROMPT.format(
            query=query,
            answer=answer,
            reference=reference or "无参考答案",
        )
        result = await self.judge_llm.chat(prompt)
        return json.loads(result)

批量评估

async def batch_evaluate(dataset, agent, judge):
    scores = []
    for case in dataset.cases:
        response = await agent.run(case.query)
        score = await judge.evaluate(case.query, response.text, case.expected_answer)
        scores.append(score)

    # 汇总
    avg_scores = {
        dim: sum(s[dim] for s in scores) / len(scores)
        for dim in ["correctness", "completeness", "relevance", "usefulness"]
    }
    return avg_scores

Rule First,Judge Last

LLM Judge 最适合处理无法稳定写成 deterministic rule 的模糊语义质量,例如回答是否过度确定、推理是否合理处理了矛盾、解释是否遗漏关键语义。

更可靠的 evaluator 分层是:

能 deterministic 判断?
→ schema / Python / exact rule

能由结构化 oracle 判断?
→ structured semantic validator

必须理解复杂语义?
→ LLM-as-a-Judge

例如 evidence ID 是否真实、是否调用了必需工具、某个禁止字段是否出现,都不应该浪费 Judge 来猜。

Judge 不是 Safety Authority

Judge 的正面评分不能覆盖 deterministic hard blocker。特别是:

critical evidence gap = OPEN
或 case 已超出已批准 Safety Envelope

即使 Judge 认为回答“看起来合理”,也不能据此把原本不允许的 AUTO 变成允许。

原则:

Judge 是评估信号,不是绕过 hard contract 的授权者。

这也是 Deny-Overrides Policy Composition 的核心边界。

Judge Calibration

Judge 本身也需要用 human-labeled benchmark 校准,至少观察:

  • recall;
  • precision;
  • false positive;
  • false negative;
  • 在不同 risk slice 上的稳定性。

Safety screener 往往优先高 recall;如果后面再接高 precision adjudicator,也不能未经验证就让第二阶段随意撤销第一阶段的 safety warning。

常见坑

  1. Judge 模型有偏见: 可能偏好某种回答风格
  2. 不做校准: Judge 的评分标准不一致
  3. Judge 比 Agent 弱: 用小模型评估大模型
  4. 让 Judge 覆盖 deterministic contract: 把本可稳定验证的 hard rule 降级成概率判断
  5. 把 Judge 分数当成 Safety Proof: 高分不能自动扩张 Safety Envelope

参考资料

创建于 2026/6/30 更新于 2026/8/19