RAG 评估的 LLM-as-Judge：用模型评模型的检索质量

人工标注跟不上迭代速度

RAG 评估的三层与人工的瓶颈

RAG 系统每次迭代——换嵌入模型、调切块策略、改重排参数、动提示词——都需要回答同一个问题：「变好还是变坏？」评估要覆盖三层：检索层（对的片段进没进候选池、排得高不高）、生成层（答案忠实于检索内容吗、切题吗）、端到端（用户的问题被解决了吗）。三层里的检索层指标（Recall、MRR）有标注答案就能程序计算，但生成层与端到端层没有程序可算的指标：答案的忠实度、完整性、措辞合理性，本质上都是质量判断。

传统解法是人工标注，瓶颈立刻显形：一次中等规模的评估集（两百条）跑人工打分，熟练标注员需要两到三天；RAG 团队一周迭代两三次，评估永远追不上迭代，最后退化成「改完自己看几条感觉还行就上线」——这是绝大多数 RAG 团队的真实状态。LLM-as-Judge 就是为这个瓶颈生的：用强模型按评分标准（rubric）替代人工，把评估成本压到人工的百分之一量级、时延压到分钟级，让「每次迭代都跑全量评估」从愿望变成流程。

先说清它的定位：LLM-as-Judge 不是替代人工标注，而是替代绝大部分日常评估的人工量。人工标注的职能上移——建小而准的金标集（Judge 用来校准的那份）、复核 Judge 的高风险误判、评估 Judge 自身的漂移。人从评分员变成质检员，这个分工是整个方法论的骨架。

评分式与对比式：两种裁判形态

裁判有两种出题方式，各有适用场景。评分式（pointwise）：给裁判一个查询、检索片段、生成的答案，按 rubric 打 1-5 分或逐维度打分（忠实度、相关性、完整性、简洁性各自独立打分）。适合需要绝对分数的场景：回归测试看分数涨跌、监控看分布漂移、按分数段统计通过率。

对比式（pairwise）：给裁判同一个查询下的两份答案（A 方案 vs B 方案），让它选出更好的那个。对比是模型更擅长的判断形态——人类评估者做绝对打分时标准漂移严重，做相对比较时一致性好得多，模型同样如此。MT-Bench（Zheng 等，NeurIPS 2023）的验证结论：对比式裁判与人工偏好的一致率显著高于评分式。所以迭代选型的 A/B 场景用对比式，回归与监控用评分式，两者不互相替代。

裁判的编写：rubric 与 CoT 评分

rubric 是裁判的灵魂

裁判模型的输出质量上限由评分标准（rubric）决定，这里最值得投入。rubric 编写有四条实战纪律：

每档给行为化描述，不给形容词。「4 分 = 答案直接回答了问题的所有子项，每个关键断言有对应检索片段支撑；2 分 = 回答了部分子项或存在无出处的断言」是可执行的；「4 分 = 较好，3 分 = 一般」是废纸。裁判按行为对号入座，才不会把个人的风格偏好带进分数。

逐维度拆分，禁止总分制。「整体质量打一分」的分数不可解释也不可回归——分数涨了不知道是忠实度涨了还是话术变好了。按维度独立打分（忠实度、相关性、完整性各一列），每次迭代看的是「忠实度持平、完整性 +0.3」这样的归因。

忠实度的 rubric 要定义「忠实」的可判定条件：答案中每个事实性断言都能在给定的检索片段中找到文本依据；与检索内容矛盾的表述扣重分；检索片段不支持也不矛盾的一般常识表述不算违反——这条边界不写清，裁判会把「正确但不在检索里的答案」误判为不忠实，这是新手最常踩的 rubric 坑。

负面清单比正面描述更能稳定输出。把历年误判案例写成「不得因此扣分 / 必须因此扣分」的条目喂给裁判，裁判分数的方差显著收窄。rubric 是个持续生长的资产，每次发现裁判误判，先问「rubric 能不能改到让它不误判」，改不动再考虑换模型。

CoT 评分与打分范围

G-Eval（Liu 等，2023）验证了两个对裁判质量影响很大的细节。其一，让裁判先写理由再给分（CoT 评分）：理由迫使裁判把 rubric 逐条对照答案，比直接给分的准确性更高，而且理由本身就是误判排查的第一手材料——我们的评估流水线把每条低分案例的理由自动归档，人工质检只看理由异常的案例，质检效率高一个量级。其二，打分范围影响区分度：1-5 分的粒度对多数质量维度太粗（大量样本挤在 3 分），裁判在该维度上的分辨率不足；1-10 分能拉开区分度但噪声变大。我们用折中方案：rubric 描述按 5 档写，输出 1-10 分并在 prompt 里说明「5 档 rubric 对应的分数区间」，兼顾粒度与校准锚点。

已知的偏差与矫正

位置、长度与自我偏好

LLM-as-Judge 有三类已知系统性偏差，每一条都可能污染评估结论，必须逐一设防：

位置偏差：对比式裁判偏爱特定位置的答案（先出现或后出现，因模型而异）。MT-Bench 的标准矫正手法是换位重评：同一对答案以两种顺序各评一次，两次结论一致才采纳，不一致标记为平局或送人工。换位让调用翻倍，但对比式评估本身调用少（只评两份答案），这个成本值得花。

长度偏差：裁判偏爱更长的答案——写得多的显得更努力。矫正手段在 rubric 里显式声明「简洁性是加分维度，冗长重复要扣分」，并在对比评估的统计里定期检查「胜者平均长度 / 败者平均长度」的比值，比值系统性偏离 1 就是长度偏差在作祟的信号。

自我偏好：裁判偏爱自家模型的输出风格（用模型 A 评模型 A 的答案，分数虚高）。纪律是生成与评审异源：评审模型不能与被评的生成模型同款同家族。这在多方案选型时尤其致命——如果 A/B 双方之一用了和裁判同源的模型，结论直接不可信，整个评估作废重跑。

flowchart TD
    S["评估样本"] --> J["裁判：CoT 逐维评分"]
    J --> C{"对比式？"}
    C -- "是" --> SW["换位重评 → 结论一致才采纳"]
    C -- "否" --> AG["评分式：直接采纳"]
    SW --> CAL["与人工金标集比对：Kappa 校准"]
    AG --> CAL
    CAL -- "一致性达标" --> R["回归/监控/选型结论"]
    CAL -- "不达标" --> F["排查 rubric → 修订后重评"]

稳定性的两道保障

偏差矫正之外还有两道通用保障。多次采样投票：裁判对同一样本评三次（温度大于 0 时输出有波动），分数取中位数、方差过大的样本标记为「裁判拿不准」送人工——拿不准的样本恰恰是两个方案真正接近的样本，人工优先看它们性价比最高。样本去偏：评估集里各方案的输出顺序、长度分布做平衡设计，不让位置和长度成为混淆变量。

与人工标注对齐：一致性的度量

Cohen's Kappa

裁判上线前和每次大改后，都要回答一个问题：「它和人类专家一致吗？」逐样本算一致率有陷阱——两位标注员对「好答案占比 80%」的数据随手打分也有六成以上的一致率，基线太高，一致率指标会虚高。正确工具是 Cohen's Kappa：扣除随机一致后的真实一致程度，Kappa 0.6-0.8 通常视为「 substantially 一致」，裁判的 Kappa 低于 0.5 就还不上线。校准流程：抽一百到两百条样本，双人人工标注出金标，裁判盲评同一批，算 Kappa；按维度分别算——常见模式是「相关性维度 Kappa 0.7 可用、完整性维度只有 0.4 不可用」，然后针对性重写该维度的 rubric 再校准，直到各维度都过线。

金标集还要定期滚动：每月从生产流量抽新样本补充金标、重算 Kappa，监控裁判的漂移——换了裁判模型、改了大版本 prompt、或者线上答案风格整体迁移，都可能让原本校准好的裁判悄悄失准。Kappa 曲线是裁判系统的「体检表」，这比任何单次校准都重要。

在 RAG 评估中的落地

忠实度评估的 claim 级实现

RAG 评估里最有含金量的单项指标是忠实度（faithfulness）：答案是否忠于检索到的内容。工程实现的主流方案是 claim 级分解（RAGAS，Es 等，2023 确立的范式）：第一步用模型把答案拆成独立的原子断言（claim）——「X 产品支持 Y 协议且已通过 Z 认证」拆成两条 claim；第二步逐条判定每条 claim 与检索片段的关系（支持 / 矛盾 / 无关），用 NLI 模型或轻量裁判调用；忠实度分数 = 被支持的 claim 占比。

claim 级的两步拆分比「整体问裁判『这个答案忠实吗』」准确得多：整体判断让模型在一个判断里处理多个事实，错误率高且不可归因；拆到 claim 后每步判断极简（一条短句对一段文本），可判定性强，还能定位「哪条 claim 编造了」——调试提示词、追责检索或生成都有抓手。成本上 claim 分解加逐条判定大约是整体判断的两到三倍调用，换来的是可用性与可解释性，值得。

检索层与端到端层的裁判分工

三层评估里裁判各管一段。检索层有标注就能程序算，裁判只在无标注场景补位：线上真实查询没有金标，用裁判做「检索片段与查询的相关性抽检」，监控检索质量的日常水位（这是生产监控体系里 LLM 评估最常用的形态——不是评答案，是评检索，因为检索质量劣化是答案劣化的前置信号，早发现早处理）。端到端层用对比式裁判做方案选型与回归，评分式做版本间的分数基线。三层各得其所，裁判不越界去干程序能干的活。

成本与工程

最后算账与落地。成本量级：一条样本的三维度评分式评估（生成端可复用）约等于一次中等长度的 LLM 调用，两百条的评估集跑一轮全量评估的成本大约是几元到几十元人民币级别（取决于裁判模型定价），时延分钟级——相比人工的两天，这就是「评估追上迭代」的物理基础。工程要点四条：评估任务离线批跑，与在线服务隔离（裁判调用高峰不影响线上）；裁判的输入输出全量留档（评估结论要可复核、可回放）；低分与高方差样本的自动归档分流到人工质检队列；评估结论与 RAG 版本号、参数快照绑定存档——半年后回看「为什么当时选了方案 B」，要能还原当时的裁判版本与 rubric 版本。

一条路线图收尾：不要一上来追求全自动评估闭环。第一周先人工评一小批，把 rubric 写到自己满意；第二周让裁判评同一批、算 Kappa、修 rubric；达标后再放量到常规回归。裁判系统的信任是一分一分校出来的，跳过校准直接信裁判分数的团队，最后都会在某个奇怪的数据点面前失去对整个评估体系的信心。

小结

LLM-as-Judge 解决的是 RAG 迭代速度与人工评估速度之间的数量级落差：人工从评分员上移为质检员，裁判承接日常的评分与对比。方法论的四梁：rubric 行为化、逐维度拆分并持续生长；评分式用于回归监控、对比式用于选型，后者必须换位重评对抗位置偏差；自我偏好与长度偏差靠生成评审异源与统计监控设防；上线前与滚动中的 Cohen's Kappa 校准是裁判系统的体检表。

RAG 场景的落地点上，claim 级忠实度评估（答案拆断言、逐条判支持）是含金量最高的单项，检索层用裁判做无标注场景的相关性抽检以监控质量水位，端到端用对比式做选型与回归。裁判不是真理机，它是一个需要校准、会漂移、可调试的测量仪器——把它当仪器对待（校准、留档、质检分流），它就能把评估速度提到与迭代速度同级；把它当真理对待，它会在某个你以为一切正常的日子里给你一份错得很自信的报告。