130 秒速览

130-Second Overview

一句话定位:传统指标(精确匹配、BLEU/ROUGE)只能比对字面相似,人工评审又慢又贵;模型裁判坐在两者中间——够便宜可以大规模跑,又足够「懂语义」能判断回答是否切题、是否有依据、任务是否完成。DeepEval 官方文档把它总结为:大多数 LLM 应用的失败「不是二元的对错」,而恰恰是传统指标漏掉的那些灰色地带。

Positioning in one sentence: traditional metrics (exact match, BLEU/ROUGE) can only compare surface similarity, while human review is slow and expensive; an LLM judge sits in between — cheap enough to run at scale, yet semantic enough to judge whether an answer is relevant, grounded, and whether the task was completed. The DeepEval docs put it this way: most LLM application failures "are not binary right-or-wrong," and those grey areas are exactly what traditional metrics miss.

2为什么需要它:评测的三难困境

2Why It Exists: The Evaluation Trilemma

先说痛点。你上线了一个客服机器人或者代码 Agent,想知道「这次改 prompt 之后有没有变差」。你有三个老办法,各有致命伤:

Start with the pain. You ship a support chatbot or a coding agent and want to know "did my latest prompt change make things worse?" You have three classic options, each with a fatal flaw:

举个具体例子(来自 DeepEval 文档):一条客服回答可以「事实全对但含糊到没用」;一条 RAG 回答可以「读起来流畅但在编造」;一个 Agent 可以「每个工具都调对了但没解决用户的事」。这三种失败,上面三个老办法全都抓不住——而这正是模型裁判的用武之地。这个思路在 2023 年由 MT-Bench / Chatbot Arena 论文(Zheng et al., arXiv:2306.05685)系统化提出,如今已是评测领域的标准工具。

A concrete example (from the DeepEval docs): a support answer can be "factually correct but too vague to help"; a RAG answer can "sound fluent while hallucinating"; an agent can "call every tool correctly and still fail the user's task." All three failures slip past all three classic approaches — and that is exactly where LLM judges earn their keep. The idea was systematized in 2023 by the MT-Bench / Chatbot Arena paper (Zheng et al., arXiv:2306.05685) and is now a standard tool in evaluation.

3核心概念:四个必须分清的维度

3Core Concepts: Four Distinctions That Matter

① 单输出打分 vs 成对比较

① Single-output scoring vs pairwise comparison

单输出打分:一次评一条输出,返回 0–1 的分数——适合回归测试和生产监控。成对比较(pairwise):把两个候选输出放一起选胜者——适合「prompt v1 和 v2 哪个更好」「模型 A 换 B 值不值」这类相对比较。DeepEval 里分别对应 GEval/DAGMetric 和 ArenaGEval。

Single-output scoring evaluates one output at a time and returns a 0–1 score — best for regression tests and production monitoring. Pairwise comparison puts two candidates side by side and picks a winner — best for relative questions like "is prompt v2 better than v1" or "is switching model A for B worth it." In DeepEval these map to GEval/DAGMetric and ArenaGEval respectively.

② 有参考 vs 无参考

② Reference-based vs referenceless

有参考(reference-based):裁判手里有标准答案(expected_output)、真值上下文或预期工具调用,对照着打分。无参考(referenceless):只看输入和输出本身,判断「有没有帮助、是否切题、语气对不对」。关键实践点:线上生产流量没有标准答案,所以生产监控几乎只能用无参考指标——这决定了你的指标设计。

Reference-based: the judge holds a gold answer (expected_output), ground-truth context, or expected tool calls, and scores against them. Referenceless: the judge sees only the input and output and asks "is this helpful, relevant, in the right tone?" The key practical point: production traffic comes without gold answers, so production monitoring is almost always referenceless — which shapes your metric design.

③ rubric:裁判的「量刑标准」

③ The rubric: the judge's sentencing guidelines

rubric 就是写给裁判的打分细则。「给 helpfulness 打 1–10 分」是烂 rubric;好 rubric 要:给指标下定义(「groundedness = 每条事实性断言都要有上下文支持」)、规定输出格式(返回 JSON {"score":0-1,"reasoning":"…"})、给正反例子、列边界情况(「上下文为空时,只要输出还敢下事实断言就打 0」)。Future AGI 的原话:「模糊的 rubric 产出模糊的裁判」。

The rubric is the scoring guideline you write for the judge. "Rate helpfulness 1–10" is a bad rubric; a good one defines the metric ("groundedness = every factual claim must be supported by the provided context"), fixes the output format (return JSON {"score":0-1,"reasoning":"…"}), gives positive and negative examples, and lists edge cases ("if the context is empty, score 0 if any factual claim is made"). As Future AGI puts it: "a vague rubric produces a vague judge."

④ 裁判的三种角色分工

④ Three roles for three judges

生产打分(大流量、抽样)用蒸馏小裁判——成本比前沿模型低 10–50 倍;校准锚点(小流量、高保真)用前沿大模型评黄金集;领域专属 rubric 用在自家标注数据上微调过的裁判。大多数生产系统是「蒸馏裁判跑量 + 前沿裁判定期校准」的组合。

Production scoring (high volume, sampled) uses a distilled small judge — 10–50x cheaper than frontier models; the calibration anchor (low volume, high fidelity) uses a frontier model on the gold-set; workload-specific rubrics use a judge fine-tuned on your own labeled data. Most production stacks combine a distilled judge for volume with a frontier judge for periodic calibration.

4三种主流裁判技术:G-Eval、DAG、QAG

4Three Judge Techniques: G-Eval, DAG, QAG

「用 LLM 打分」不是一种做法,而是一个技术族。DeepEval 把单输出裁判归纳为三种,各有明确的适用场景:

"Score with an LLM" is not one method but a family. DeepEval organizes single-output judges into three techniques, each with a clear fit:

G-Eval:用自然语言写评分标准,框架自动生成评估步骤。原型阶段用 criteria 一句话起步;要进 CI/CD 时改成显式的 evaluation_steps,更稳定可控。DAG:把一个大判断拆成决策树——比如「先判断输出是不是合法 JSON,不是直接 0 分;是,再进入主观质量评分」,每条路径的分数是确定的、可追溯的。QAG(question-answer generation,问答生成):把宽泛判断分解成一串封闭式小问题再合成分数,DeepEval 的内置 RAG/Agent 指标(忠实度、切题度、工具正确性、任务完成度)大多用这个算法,拿来即用。代码示例(来自 DeepEval 官方文档):

G-Eval: write the criterion in natural language and the framework auto-generates evaluation steps. Prototype with a one-line criteria; switch to explicit evaluation_steps before it enters CI/CD, for stability and control. DAG: split one broad judgment into a decision tree — e.g. "first check the output is valid JSON, score 0 if not; if yes, proceed to subjective quality" — every path yields a deterministic, traceable score. QAG (question-answer generation): decompose a broad judgment into closed-ended sub-questions and compute the score from the answers; DeepEval's built-in RAG/agent metrics (faithfulness, relevancy, tool correctness, task completion) mostly use this algorithm, ready out of the box. Code example (from the DeepEval docs):

from deepeval import evaluate
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, SingleTurnParams

correctness = GEval(
    name="Correctness",
    evaluation_steps=[
        "Check whether the actual output contradicts the expected output.",
        "Penalize missing eligibility conditions that change the meaning.",
        "Do not penalize harmless wording differences.",
    ],
    evaluation_params=[SingleTurnParams.ACTUAL_OUTPUT,
                       SingleTurnParams.EXPECTED_OUTPUT],
)
evaluate(test_cases=[test_case], metrics=[correctness])

5五大系统性偏见:裁判为什么会冤判

5Five Systematic Biases: Why Judges Misjudge

这是本主题最重要的一节。模型裁判的偏见不是随机噪声,而是系统性的、方向一致的——不治理它,你的所有评测结论都会朝同一个方向歪。Future AGI 与多篇研究归纳出五种反复出现的偏见,每种都有已知的缓解手段:

This is the most important section. Judge biases are not random noise — they are systematic and directional. Left untreated, every conclusion you draw from evals tilts the same way. Future AGI and multiple studies converge on five recurring biases, each with a known mitigation:

6怎么用:工程落地十步

6How to Use It: Ten Steps to Production

下面是 Future AGI 给出的生产部署清单(原文为 10 步,此处完整保留),核心思想一句话:裁判本身也是一个需要被评测和监控的模型。

Below is Future AGI's production deployment checklist (10 steps in the original, kept in full). The core idea in one line: the judge is itself a model that must be evaluated and monitored.

1. 定义 rubric:具体、带例子、带离散输出格式。Define the rubric: specific, with examples, with a discrete output format.
2. 建黄金集(gold-set):每个业务场景 200–500 条人工标注样本,每条 2–3 人标,跟踪标注者间一致性(Cohen's kappa)。Build the gold-set: 200–500 hand-labeled traces per workload, each labeled by 2–3 humans; track inter-annotator agreement (Cohen's kappa).
3. 选裁判模型:生产用蒸馏小裁判,校准用前沿模型。Pick the judge model: distilled for production, frontier for calibration runs.
4. 避开同族偏见:裁判与生成模型用不同家族。Avoid family bias: use a different family than the generator.
5. 上线前校准:裁判跑一遍黄金集,验证与人类标注的 kappa 达标(常用门槛 0.6;Openlayer 建议高置信场景以 Krippendorff's alpha ≈0.8 为目标)。Calibrate at launch: run the judge over the gold-set and verify kappa against human labels clears the bar (0.6 is common; Openlayer suggests targeting Krippendorff's alpha ≈0.8 for high-confidence use).
6. 异步跑,别挡请求路径:抽样 5–20% 的生产流量(错误与异常 100% 抽),由异步 worker 打分并把分数挂到 trace span 上——裁判一次调用有 100ms–2s 延迟,不能让用户等。Run async, off the request path: sample 5–20% of production traffic (100% of errors and outliers), score in an async worker, attach scores to trace spans — a judge call adds 100ms–2s and users should not wait for it.
7. 建每月校准任务:每月重跑黄金集,kappa 掉了就报警。掉了怎么修:收紧 rubric → 换裁判模型 → 刷新黄金集 → rubric 里加 few-shot 例子。裁判会在 60–90 天内漂移。Build the monthly calibration job: rerun the gold-set monthly, alert on kappa drops. Fixes, in order: tighten the rubric → swap the judge model → refresh the gold-set → add few-shot examples. Judges drift within 60–90 days.
8. 成本单列:裁判成本控制在生产 LLM 成本的 10–15% 以内,超过 25% 就降抽样率或换更小的蒸馏裁判。Track judge cost as its own line: keep judge cost under 10–15% of production LLM cost; past 25%, reduce sampling or swap to a smaller distilled judge.
9. 建漂移监控:rubric 分数滚动均值,劣化即报警。Build the drift monitor: rolling-mean rubric scores, alert on degradation.
10. 季度刷新黄金集:换掉 100–200 条旧样本,保持与当前流量分布一致。Refresh the gold-set quarterly: replace 100–200 stale entries so it stays representative of current traffic.

7三个典型工作流

7Three Typical Workflows

① CI/CD 回归测试:把裁判包装成 pytest 断言,改 prompt/模型后自动挡住回归。DeepEval 里用 assert_test() + deepeval test run,不达标测试直接红。② 组件级评测:在 trace 里对检索器、生成器、工具调用步骤分别打分(@observe(metrics=[…])),定位「是检索烂还是生成烂」。③ 生产监控:对线上流量抽样跑无参考指标(切题度、任务完成度、安全性),跟踪趋势、把低分 trace 采样回测试集——注意起步只选少量高信号指标,裁判太多会「又贵又吵」。

① CI/CD regression testing: wrap judges as pytest assertions so prompt/model changes are gated automatically. In DeepEval: assert_test() + deepeval test run; failing metrics turn the build red. ② Component-level evaluation: score the retriever, generator, and tool-calling steps separately on traces (@observe(metrics=[…])) to localize whether retrieval or generation is at fault. ③ Production monitoring: run referenceless metrics (relevancy, task completion, safety) on sampled live traffic, track trends, and recycle low-scoring traces into your test sets — start with a small number of high-signal metrics; too many judges get "noisy, expensive, and hard to interpret."

from deepeval import assert_test

def test_refund_answer():
    metric = GEval(name="Correctness",
        criteria="Determine whether the actual output is correct "
                 "based on the expected output.",
        evaluation_params=[SingleTurnParams.ACTUAL_OUTPUT,
                           SingleTurnParams.EXPECTED_OUTPUT],
        threshold=0.7)
    assert_test(test_case, [metric])   # deepeval test run test_refund_answer.py

8对比与选型

8Comparison & Selection

工具生态(2026 年主流选项,信息来自 Future AGI 工具综述,含其自家产品,注意立场):

Tooling landscape (mainstream options in 2026, per Future AGI's survey — which includes its own product, so mind the vantage point):

选型判断:测试集和 trace 存在哪、CI 用什么,比工具功能列表更重要——Future AGI 自己也承认「纪律在所有工具上都是一样的」。什么时候不该用模型裁判:输出本身可程序化验证时(代码能跑测试、JSON 能 schema 校验、数学有标准答案),用确定性检查,更便宜更准;模型裁判留给「只有语义判断能覆盖」的部分。

Selection judgment: where your test sets and traces live, and which CI you use, matter more than feature lists — Future AGI itself concedes "the discipline is the same across tools." When not to use an LLM judge: whenever the output is programmatically verifiable (code runs tests, JSON validates against a schema, math has a ground truth), use deterministic checks — cheaper and more accurate; reserve the LLM judge for what only semantic judgment can cover.

9常见坑与限制

9Pitfalls & Limitations

还有两条更根本的限制要心里有数:第一,裁判的上限是 rubric 与校准数据的质量——它不会比你的人工标注更懂你的业务;第二,合规压力正在把校准从「良好实践」变成「硬要求」:据 Future AGI 引述,EU AI Act 分阶段实施(GPAI 义务 2025 年 8 月生效,2027 年前全面执行),「与人类系统性不一致的裁判」在审计里是一条 finding,不是通过项。

Two deeper limitations to keep in mind: first, a judge's ceiling is the quality of your rubric and calibration data — it will never understand your domain better than your human annotations do; second, compliance pressure is turning calibration from good practice into a hard requirement: per Future AGI, the EU AI Act phases in (GPAI obligations applied Aug 2025, full enforcement through 2027), and "a judge that disagrees with humans in systematic ways is a finding, not a passing audit."

10前沿动态(截至 2026-08)

10Research Frontier (as of 2026-08)

为什么今天选这个主题:8 月 3 日 arXiv 上线了《Chain-of-Models: Cross-Model Auditing for Bias-Robust LLM Judges》(arXiv:2607.28636),提出用「跨模型审计链」代替单一裁判——摘要指出现有缓解手段大多依赖 prompt 层面的修补,而链式互审能在结构上对冲单个裁判的认知偏见(注:仅读到摘要,结论以论文全文为准)。同方向上,2026 年还有《Judging the Judges》(arXiv:2604.23178)系统评测各种偏见缓解策略的实际效果,以及 Openlayer 指南总结的两条重要研究线:基于校准的偏见修正与置信区间(把裁判的敏感度/特异度不完美纳入统计);把项目反应理论(IRT,教育测量学中评估「考官」质量的方法)反过来用在裁判身上。

Why this topic today: on August 3 arXiv posted "Chain-of-Models: Cross-Model Auditing for Bias-Robust LLM Judges" (arXiv:2607.28636), proposing a cross-model auditing chain in place of a single judge — the abstract argues most existing mitigations are prompt-level patches, while chained mutual auditing structurally hedges any one judge's cognitive biases (note: abstract only; defer to the full paper). In the same direction, 2026 also brought "Judging the Judges" (arXiv:2604.23178), a systematic evaluation of how well bias-mitigation strategies actually work, plus two research lines highlighted by the Openlayer guide: calibration-based bias correction with confidence intervals (accounting for imperfect judge sensitivity/specificity), and applying item response theory (IRT — the psychometric method for assessing examiners) to the judges themselves.

工程侧的三个趋势(据 Future AGI 时间线):蒸馏小裁判(Galileo Luna、turing_flash 等)让 10–20% 的抽样率在成本上可行;OpenTelemetry GenAI 的评测分数属性标准化,让「分数流可观测」成了开箱即用能力;多裁判集成从论文技巧变成文档化的工程模式。

Three engineering trends (per Future AGI's timeline): distilled small judges (Galileo Luna, turing_flash, etc.) made 10–20% sampling rates cost-tractable; OpenTelemetry GenAI standardized eval-score attributes, making score-stream observability an off-the-shelf capability; and multi-judge ensembles graduated from a paper trick to a documented engineering pattern.

11学习资源

11Resources

• MT-Bench / Chatbot Arena 论文(Zheng et al., 2023) — 领域奠基之作,先读它理解问题的由来
• The MT-Bench / Chatbot Arena paper (Zheng et al., 2023) — the foundational work; read it first to understand where the problem comes from
• DeepEval《LLM-as-a-Judge in 2026》与指标文档 — 技术分类与代码上手最全面
• DeepEval, "LLM-as-a-Judge in 2026" and the metrics docs — the most complete taxonomy and hands-on code
• Future AGI 十条最佳实践 — 校准、偏见、成本的生产纪律清单
• Future AGI's ten best practices — the production discipline checklist for calibration, bias, and cost
• Chain-of-Models(2026-08-03)、Judging the Judges(2026) — 偏见治理的最新研究
• Chain-of-Models (2026-08-03) and Judging the Judges (2026) — the latest research on bias governance
• RAGAS 文档 — RAG 场景的现成裁判指标
• RAGAS docs — ready-made judge metrics for RAG