LLM-as-Judge / G-Eval 与企业 AI Evaluation

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

• G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment（2023-03）
• G-Eval EMNLP entry: ACL Anthology（EMNLP 2023 收录；访问日期: 2026-07-01）
• MT-Bench / Chatbot Arena: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（2023-06）
• OpenAI Evals: openai/evals（访问日期: 2026-07-01）
• NIST AI RMF: AI Risk Management Framework（访问日期: 2026-07-01）

核心导读

LLM-as-Judge 的原理是用强语言模型按照明确 rubric、输入证据和结构化返回格式，对开放式回答做 pointwise scoring、pairwise comparison 或维度化判断。G-Eval 说明评估可以由 criteria 和 evaluation steps 驱动，MT-Bench / Chatbot Arena 则展示了强模型 judge 在部分偏好评估中的可扩展性。

它的价值不是让另一个模型成为“最终裁判”，而是把开放式 AI 输出的质量判断规模化、结构化、可回归。团队可以用它比较 prompt、RAG、模型和工具版本，发现 unsupported claim、missing exception、unsafe action、wrong tone 等失败类型，并把失败 taxonomy 接入发布门禁和修复 backlog。

治理边界必须清楚：LLM judge 会有位置偏差、冗长偏好、自我偏好、领域无知和分数漂移。金融零售系统需要 hybrid eval stack，由确定性检查、证据校验、LLM judge、专家抽检、线上监控和 release gate 共同组成证据链。Judge score 只能作为风险证据的一部分，不能替代政策 owner、合规责任或高风险人工复核。

核心问题

传统软件测试依赖明确断言。 按钮点击后是否创建记录。 无效输入是否返回错误。 接口是否按 schema 返回字段。 AI 产品的质量要求更像这样：

• 回答要准确。
• 摘要要完整。
• 解释要清晰。
• 语气要专业。
• 不得越权。
• 建议要安全。
• 引用要支持结论。

这些要求没有单一标准答案。 如果团队只靠人工试用几个例子，就无法比较版本、无法发现回归、无法证明上线风险可控，也无法向审计或监管解释质量证据。 LLM-as-Judge 回答的问题是： 能否用强语言模型对开放式输出进行可扩展评估，并把“感觉不错”转成可重复的评价流程？ 答案是可以，但必须带着限制使用。 LLM judge 是证据工具，不是事实真理。

论文和技术贡献

G-Eval 的贡献是把 GPT-4 这类强模型用于自然语言生成评估。 它强调用明确 criteria、evaluation steps 和 structured form 来评价摘要、对话等开放式任务，并报告与人类判断更高的一致性。 这给企业 AI 的启发是：质量评估可以由 rubric 驱动，而不是由评审者凭感觉打分。 MT-Bench 和 Chatbot Arena 的贡献是展示用 LLM judge 进行聊天助手比较评估的可行性，并系统讨论了 judge 与人类偏好的关系和偏差。 它们让社区看到，强模型 judge 可以在一定范围内扩大开放式评估规模。 同时也让团队必须面对 position bias、verbosity bias、self-enhancement bias 等问题。 OpenAI Evals 等工程化工具的启发是把评测样本、运行器、模型配置、指标和回归报告组织成可执行资产。 对企业而言，eval 不是论文实验最后一步，而是需求、开发、发布、监控和事故复盘的贯穿机制。

Eval Stack 的系统位置

一个生产级 AI eval stack 通常包括：

flowchart TB
    REQ[Business requirement] --> RUB[Rubric and quality criteria]
    RUB --> DATA[Golden / challenge dataset]
    DATA --> DET[Deterministic checks]
    DATA --> JUDGE[LLM-as-Judge]
    DATA --> EXP[Expert review]
    DET --> RES[Eval result store]
    JUDGE --> RES
    EXP --> RES
    RES --> GATE[Release gate]
    GATE -->|Pass| REL[Release]
    GATE -->|Fail| FIX[Fix prompt / RAG / workflow / model / controls]
    REL --> MON[Production monitoring]
    MON --> DATA

Eval 应从需求阶段开始。 如果需求写“回答必须准确”，它还不够工程化。 更好的写法是：

• 每个事实 claim 必须有 evidence id。
• 不得承诺 fee waiver。
• 如果缺少客户风险等级，必须触发人工复核。
• 支付 return code 与账户状态冲突时，必须输出 unknown 并升级。
• 高风险客户通知必须通过 compliance rubric。

这些要求才能被评测、回归和审计。

LLM-as-Judge 的基本模式

Pointwise Scoring

Pointwise scoring 让 judge 对单个回答按维度打分。 适合评估 groundedness、tone、completeness、format adherence 和 policy compliance 初筛。 它的风险是分数漂移。 不同 judge model、prompt、温度、rubric 版本都可能改变分数。 因此，pointwise score 不能脱离版本和校准记录使用。

Pairwise Comparison

Pairwise comparison 让 judge 比较答案 A 和 B 哪个更好。 它适合模型选择、prompt 改版和 RAG 策略比较。 在细小差异上，pairwise 往往比绝对打分更稳定。 但它容易出现位置偏差。 答案放在 A 或 B 的位置会影响判断。 严肃评测需要随机顺序、双向比较和一致性检查。

Rubric-Based Evaluation

Rubric-based evaluation 更适合企业。 它把一个模糊质量判断拆成多个维度。 例如客服政策回答可以拆成：

这种结构比让 judge 回答“好不好”更可靠。

Hybrid Evaluation

金融零售不应只依赖 LLM judge。 更稳妥的是 hybrid eval：

• JSON schema 和字段完整性用确定性检查。
• 禁止词、禁止动作、权限字段用规则检查。
• 引用是否存在、证据版本是否当前，用检索和元数据检查。
• 开放式质量、语气、完整性、解释清晰度由 LLM judge 初筛。
• 高风险样本由专家复核。
• 上线后用人工覆盖、投诉、申诉、事故和业务结果持续回流。

LLM judge 擅长评语言质量和部分开放式维度。 它不应单独判断法律结论、信贷最终决定、制裁命中处置或客户权益影响动作。

Judge Prompt 的结构

一个可用 judge prompt 应短、明确、结构化。 它需要知道任务、证据、候选输出、评估维度和返回格式。

You are evaluating an AI assistant output for a financial services workflow.

Input:
- User request: ...
- Retrieved evidence: ...
- Assistant output: ...

Evaluate:
1. Factual grounding: every factual claim must be supported by evidence.
2. Policy compliance: no unauthorized promise or prohibited advice.
3. Completeness: answer covers required exceptions and next steps.
4. Action safety: no action beyond user role or approval state.

Return JSON with:
- score or pass/fail per dimension
- failure_tags
- evidence references
- critical_failure
- short explanation

Judge prompt 不能把评估责任全部外包给模型。 Rubric 要由业务、风险、合规、运营和技术共同定义。 每个 failure tag 应能进入 backlog、控制库或 release gate。

Golden Set 与 Challenge Set

没有高质量样本集，LLM-as-Judge 只是在自动化主观判断。 Golden set 应覆盖代表性正常样本。 Challenge set 应覆盖高风险边界和系统容易失败的情形。 金融零售常见样本类型包括：

• common case。
• edge case。
• missing-data case。
• policy-conflict case。
• outdated-policy case。
• adversarial prompt case。
• high-risk customer impact case。
• protected-class or proxy-risk case。
• evidence contradiction case。
• escalation-required case。

每条样本至少包含：

• user input。
• evidence/context。
• expected behavior。
• unacceptable behavior。
• rubric。
• severity。
• owner。

这样 eval 才能支持回归，而不是一次性验收。

为什么 LLM Judge 有用

LLM judge 有用，是因为开放式输出的很多质量维度本身是语言和语义判断。 例如摘要是否完整、解释是否清晰、回答是否过度承诺、语气是否尊重、是否遗漏下一步。 这些维度很难只用字符串匹配完成。 强模型可以在给定 rubric 和证据的情况下，快速处理大量候选输出。 它让团队能：

• 快速比较 prompt 改版。
• 比较 RAG chunking 和 reranking 策略。
• 发现高频失败类型。
• 做发布前回归。
• 对生产样本做抽样质量监控。

LLM judge 的最大价值不是给一个分数，而是形成 failure taxonomy。 如果系统知道失败主要来自 unsupported claim、missing exception、wrong tone 或 unsafe action，团队就能有针对性修 prompt、RAG、规则或工作流。

LLM Judge 的偏差和失败模式

Position Bias

Pairwise 评估中，judge 可能偏好先出现或后出现的答案。 缓解方式是随机 A/B 顺序，运行双向比较，并检查结果一致性。

Verbosity Bias

Judge 可能偏好更长、更像认真回答的答案。 这在金融场景很危险。 冗长解释可能包含更多 unsupported claims。 Rubric 应明确 concise、evidence-supported 和 no unnecessary speculation。

Self-Enhancement Bias

Judge 可能偏好同模型家族生成的答案。 模型选型评估不能只用候选模型的同族 judge。 关键发布应有跨模型 judge、人工校准或专家复核。

Domain Ignorance

通用 judge 不懂内部政策、系统状态和最新监管要求。 如果不给 evidence，它可能用常识替代事实。 专业事实应由数据库、规则、检索证据和专家复核支撑。

Overtrust

团队可能把 judge 分数当成上线许可。 这是治理失败。 Judge score 只是 release evidence 的一部分。 上线还要看 critical failure、专家 review、事故预案、SLO、成本、人工流程和风险接受。

不应要求暴露隐藏 Chain-of-Thought

Eval 可以要求候选模型提供简洁 rationale、引用证据、decision factors、计算过程或 missing information。 但不应要求模型向用户或审计方展示完整隐藏 chain-of-thought。 审计需要的是可验证证据链。 包括 prompt id、model version、evidence id、tool call、policy version、output、reviewer action 和 approval record。 隐藏推理文本可能包含错误分支、敏感字段、系统策略和未验证推断。 把它当审计证据会增加风险。 评估 explanation faithfulness 时，应比较用户解释和真实 decision record，而不是比较解释和模型自述思路。

金融零售案例一：AML Narrative Evaluation

AML narrative 不是普通摘要。 它会影响调查质量、监管记录和后续 SAR/STR 判断。 评测维度可以包括：

LLM judge 可以初筛 narrative quality、完整性和措辞。 专家必须复核高风险 typology、SAR 判断边界和监管可接受性。

金融零售案例二：支付异常解释

支付异常解释需要 root cause correctness。 模型回答必须和 return code、账户状态、风控结果、网络响应和 cut-off time 一致。 确定性检查可以验证 return code 是否存在、状态组合是否合法、建议动作是否允许。 LLM judge 可以评估客户解释是否清晰、是否遗漏下一步、是否过度承诺。 如果工具数据冲突，期望行为不是猜测，而是输出 unknown 并升级。 Release gate 应要求 critical unsafe action 为 0。

金融零售案例三：KYC Remediation

KYC remediation 需要识别缺失资料、生成客户沟通，并避免请求不必要或未授权的数据。 评测维度包括：

• missing field detection。
• document requirement correctness。
• customer outreach tone。
• no unauthorized data request。
• privacy minimization。
• escalation when risk tier is unclear。

LLM judge 可以评估沟通质量。 规则和政策表必须决定哪些文件可请求。

金融零售案例四：Lending Underwriting Assistant

信贷场景中，eval 必须处理 fair lending、adverse action、政策引用和人工责任。 模型可以辅助摘要和解释，但不能成为最终审批者。 评测维度包括：

• policy citation correctness。
• calculation consistency。
• adverse action reason correctness。
• prohibited factor avoidance。
• proxy risk tag。
• human review trigger。

Critical failure 应包括：编造拒绝原因、提及受保护因素、承诺审批结果、忽略人工复核要求。

Release Gate 设计

发布门禁不能只写“eval pass”。 应按风险分层：

门禁失败不一定意味着项目停止。 它可能意味着只允许内部 pilot、只开放低风险 route、增加人工复核，或把失败类型进入修复 backlog。

EvalOps 架构

EvalOps 需要把评测资产和运行结果工程化管理。

flowchart LR
    REG[Dataset registry] --> RUN[Eval runner]
    RUB[Rubric registry] --> RUN
    CFG[Model / prompt / RAG config] --> RUN
    RUN --> DET[Deterministic checks]
    RUN --> J[Judge gateway]
    RUN --> HUM[Human review sample]
    DET --> STORE[Result store]
    J --> STORE
    HUM --> STORE
    STORE --> DASH[Dashboard]
    DASH --> GATE[Release gate]
    STORE --> TAX[Failure taxonomy]
    TAX --> BACK[Fix backlog]

每次模型、prompt、RAG index、tool contract、policy rule 或 adapter 变更，都应触发相关回归。 评测结果应绑定版本。 否则团队无法解释为什么同一个系统上周合格，这周不合格。

局限和误用

第一类误用是把 LLM judge 当最终真理。 它只是一个 evaluator，仍会幻觉、偏好冗长、忽略领域事实。 第二类误用是没有专家校准。 如果 judge 与专家长期分歧，就要调整 rubric、prompt、证据输入或选择其他 evaluator。 第三类误用是只评平均分。 金融场景要看 critical failures 和高风险分层。 平均 4.6 分但出现一次自动承诺退款，仍可能不能上线。 第四类误用是用通用 benchmark 替代业务 eval。 通用能力不代表内部政策、异常流程、客户权益和监管边界可靠。 第五类误用是把 eval 放在项目末尾。 如果需求没有对应 eval，就无法判断实现是否真的满足需求。

架构和产品价值

LLM-as-Judge 把 AI 产品质量从主观评审转成证据系统。 它让团队能把模糊要求拆成 rubric、dataset、judge prompt、threshold、failure tags 和 release gate。 它还让 AI 迭代更像软件工程。 每次改 prompt、改模型、改检索、改工具，都可以跑回归，比较版本差异，定位失败类型。 在金融零售中，这种能力直接连接治理。 监管问询时，团队需要证明：

• 上线前测过哪些场景。
• 哪些高风险失败被禁止。
• 哪些样本由专家复核。
• 哪些门禁通过或豁免。
• 上线后如何监控投诉、人工覆盖和事故。

LLM judge 不是为了取代人类判断，而是让人类专家把精力集中在高风险、边界和争议样本上。

学习验证

读完这篇后，应能完成以下任务：

1. 为 AML narrative 写一个 rubric，至少包含 evidence coverage、citation precision、typology coverage、unsafe recommendation 和 missing evidence disclosure。

2. 为客服政策回答写 judge prompt，要求输出 structured JSON，并包含 critical_failure。

3. 设计 20 条 payments exception golden cases，覆盖 common return code、missing data、policy conflict 和 high customer impact。

4. 为 lending assistant 定义 release gate，明确哪些 critical failures 必须为 0。

5. 做一个 judge bias test：交换 A/B 顺序，比较 judge 是否偏好位置或更长回答。

6. 设计一个 EvalOps 数据模型，包含 dataset version、rubric version、judge model、candidate system version、result 和 failure tag。

7. 写一页 release memo，说明 eval 结果、失败样本、风险严重度、缓解措施和上线建议。

关键结论

LLM-as-Judge 让开放式 AI 输出的评估可以规模化，但不能把评估责任交给模型本身。 G-Eval 说明强模型配合明确 criteria 和结构化评分，可以更好地评估自然语言生成质量。 MT-Bench 和 Chatbot Arena 说明 LLM judge 可以近似部分人类偏好，也必须管理偏差。 企业 AI 需要 hybrid eval：确定性规则、证据校验、LLM judge、专家复核、生产信号和发布门禁共同工作。 金融零售的 eval 重点不是“回答看起来好”，而是 groundedness、policy compliance、action safety、human oversight、audit evidence 和 customer harm prevention。 没有 eval 的 AI 产品只是演示。 有业务化 eval、版本化证据和发布门禁的 AI 系统，才有进入生产流程的基础。

---

SOTA 检查 (2026-07-01)

• Judge 本身已从「prompt 一个强模型」演进到专门训练的 reasoning judge：EvalPlanner（Saha et al., 2025，Meta）把评估拆成「先生成 evaluation plan、再执行、最后给 verdict」两阶段，用少量偏好对即达到 SOTA reward model 效果；JudgeLRM（arXiv 2504.00050，2025-04）用 RL + judge-wise outcome reward 训练判断专用模型，论文报告 JudgeLRM-7B 在 F1 上超过 DeepSeek-R1 约 2.79%。本篇「G-Eval 式 criteria + evaluation steps」的思路没有被推翻，而是被这些 plan-then-execute / reasoning judge 方法工程化放大。
• 本篇列的偏差清单在 2024-2026 被系统量化，仍然全部成立：self-preference bias（arXiv 2410.21819，2024-10）、CALM 偏差量化框架《Justice or Prejudice?》（arXiv 2410.02736，2024-10）、position bias 跨 15 个 judge / 约 15 万评估实例的大规模测量（Shi et al., IJCNLP 2025）。2025-2026 的新结论：frontier judge 在偏差测试中失败率仍高，meta-judge / ensemble 可抑制偏差，但 debate 式多模型互评反而会放大偏差——「随机换序 + 双向比较 + 跨供应商 judge + 人工校准」仍是被验证的缓解组合。
• 2026 年实践现状：LLM-as-Judge 已是规模化 LLM 应用评估的默认方法（practitioner 报告与人类评审一致率约 80-85%，接近人-人一致率），但对齐类数据集上最好的 judge 准确率仍低于 0.7（被测 judge 含 GPT-4 系列、DeepSeek-V2.5）——本篇「judge score 只是证据链一环、hybrid eval + 高风险人工复核」的核心结论不但成立，反而是当前公认 best practice。
• 领域综述已成型：《From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge》（arXiv 2411.16594，2024-11）与 Gu et al. 2025 的 LLM-as-a-Judge survey 系统梳理了 pointwise/pairwise/rubric 分类、偏差缓解与评估方法标准化——本篇的模式分类与这些综述框架一致。
• 不随版本过时的框架性结论：rubric 由业务/风险/合规共同定义、golden set + challenge set、failure taxonomy 进修复 backlog、按风险分层的 release gate、eval 结果绑定版本的 EvalOps、不要求暴露隐藏 chain-of-thought——这些是治理结构设计，与 judge 用哪个模型无关。
• 库内配套实践（本仓库 AIPA-120 已落地，2026-06 完成）：CI 阻断式 eval gate 见 docs/aipa/day19-blocking-ci-eval-gate.md，每日 eval runner 见 docs/aipa/day76-daily-eval-runner.md，AML SAR eval suite 见 docs/aipa/day86-sar-eval-suite.md——正是本篇 EvalOps 架构图的工程实现。