rag llm-as-a-judge llm-evaluation groundedness debugging

RAG故障诊断：阶段流程图与声明级真实性判断器

定位RAG流程出错的位置，然后构建一个LLM真实性判断器，该判断器可逐个核查声明，并通过卡帕系数与人类评估员的结果进行验证。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 9 分钟2046 词

来源: How to Diagnose RAG Failures with a Groundedness Judge

当RAG机器人开始给出错误答案时

部署RAG应用并不意味着任务已完成，尤其是在生产环境中。最终它会出现错误答案，而首要的挑战就是找出原因。系统中至少有七个可能引发故障的环节：分块处理、嵌入向量生成、信息检索、重排序、上下文整合、内容生成，以及连接这些环节的提示词。一个错误的最终答案几乎无法说明是哪个环节出了问题。有些工程师花费了一周时间优化生成提示词，却不知问题其实出在分块处理故障上。

有一种相当机械化的方法可用于定位故障。之后会出现第二个问题，即大规模评估信息的可靠性，因为在概念验证阶段之后，逐一查看所有文本记录已不再可行。由大型语言模型充当评估者可以完成这项工作，但评估者本身也存在故障模式，这些故障与它们本应发现的RAG错误一样容易被忽视。下文将涵盖这两方面：追溯故障的根源，以及构建值得信赖的可靠性评估工具。

先找出出问题的环节

RAG流程是一系列环节组成的链条，首要任务是在任何人编辑提示词之前确定哪个环节出现了故障。下图是一个用于定位问题的框架。它并非面面俱到，可根据特定系统和使用场景进行扩展。

这种排序是有意为之：先解决检索问题，再处理生成问题。如果上下文窗口从一开始就没有包含正确的事实，提示工程也无法弥补这一缺陷。团队们常常反其道而行之，反复修改系统提示五次，而重排器却会降低那些有用的段落的权重。那些成本低但效果显著的改进方法，比如更好的分块处理或混合搜索，应当优先于那些成本高昂的方法，例如对重排器进行微调或重新训练模型。

三种实际现象可以体现该方法的运用方式：

尽管相关文档从未涉及该主题，答案却显得十分肯定。这并非真正的检索，因为根本不存在可获取的相关内容。这是生成或回避机制的故障：模型不会将“我没有这个信息”视为可接受的回复。
该机器人提供的信息看似合理但已过时。分块问题几乎从来都不是原因。索引之所以陈旧，是因为文档发生了变化，却没人重新嵌入这些文档。
只涉及一个事实的问题能够通过，但需要从两个文档中获取两个事实的问题就会失败。这是多跳查询特有的检索失败问题，因为单次密集检索无法获取与查询特征各不相同的两个信息片段。

接下来的做法是获取某个失败案例实际检索到的上下文并先阅读它，然后再做任何修改。如果所需事实不存在，问题就出在检索环节；如果事实存在而模型仍答错，问题就出在生成环节。这一检查步骤就能节省数天的时间。

“基于现实”的含义

对于少数案例，阅读文本转录本就足够了，但面对成千上万的案例则根本无能为力。这时就需要一个大型语言模型法官介入，尤其是专门负责评估“依据性”或“忠实度”的法官。它的任务是判断答案中的每一项陈述是否都能在检索到的上下文中找到对应依据。

有一个容易被忽视的要点：依据性与正确性是两回事。一个正确的答案可能缺乏依据，比如模型是从训练数据中得知该事实而非从文档中获取的；而一个有依据的答案也可能出错，如果检索到的段落本身已经过时或不正确。在评估RAG系统时，我们更应关注依据性，因为它能反映出无论底层文档质量如何，检索功能是否真正发挥了作用。

基于陈述的评估法官

一个要求给出1到5分真实度评级的简单提示看似合理，但实际上几乎毫无用处。它只会给出一个数字而不会给出任何解释，而全篇答案评分正是大语言模型表现不一致的领域。将答案拆分成独立的陈述后再逐一核对，效果会好得多。

初始提示为模型设定了“真实度评估器”的系统角色，同时提供了问题、检索到的上下文以及生成的答案，并明确说明该任务并非判断答案整体是否正确。接着它要求提取出各项陈述，再逐一与上下文进行比对，针对每一项给出判断结果及对应的支持内容。

SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.

Do the following:

1. Decompose the ANSWER into a list of atomic claims (each claim = one
   discrete factual statement, not a compound sentence).
2. For each claim, decide:
   - SUPPORTED: directly stated or reasonably entailed by CONTEXT
   - CONTRADICTED: conflicts with CONTEXT
   - UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
   (or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).

Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.

Return valid JSON only:
{
  "claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
  "groundedness_score": 0.0,
  "num_claims": 0
}

QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}

有些设计选择需要明确说明，因为它们乍看之下并不明显：

声明级评分。单一的整体评分难以调试。针对每条声明的判定能够准确显示是哪条陈述出了问题，这在需要解决根本原因时非常重要。
强制性的证据范围。要求评估者引用支持性文本，能促使他们基于证据而非合理性来做出判定，同时也能让人工审核者快速检查判断结果，无需重新阅读全部上下文。
“无证据支持”与“与证据矛盾”。与证据矛盾与仅缺乏证据支持是两种不同的错误，需要不同的处理方式。将二者合并为单一的“错误”标签会丢失重要的诊断细节。

明确要求严格评判。大型语言模型评估者在处理边界情况时往往趋于宽松，尤其是当答案听起来合乎逻辑时，而要求严格评判可以减少这种情况。

将评估者与人类进行对比验证

这是常被忽略的步骤，但它决定了后续所有工作的价值：在信任某个评估者之前，必须先将其与人类进行对比验证。

流程很简单。选取100到200个示例，让某人独立评估其依据的充分性，然后用科恩卡帕系数计算一致性。如果大多数答案都有充分依据，仅凭原始准确率会产生误导，因为总是给出“有依据”判断的评估者虽然得分高，但实际上毫无价值。同时还需检查常见的评估者偏见：

立场偏见：如果上下文段落顺序改变，其判断结果会发生变化吗？
冗长性偏差：无论答案是否确实更有依据，评分者是否会偏爱更长的回答？
自我偏好偏差：如果评分者与生成模型属于同一模型系列，它可能会更倾向于给该系列的输出更高分。
宽容度漂移：随着评分模型或提示词版本的变化，一致性是否会在数周内悄然下降？

某一类别的卡帕值较低表明需要调整该类别的评分标准，并不意味着RAG系统在该方面出现了故障。人们常常将这两者混淆，下一节将详细阐述二者的区别。

以操作员视角解读控制面板

想象一个按查询类型划分的控制面板，正确的态度应是作为操作员去使用它，而非仅仅作为记分员旁观。

整体平均值略有下降，这可能会产生误导。逐行来看，数据情况如下。

简单事实查询在准确性和一致性方面均保持稳定且较高的水平。系统与评估者都认为它很容易完成。虽然单独来看比较乏味，但若其数值下降，则表明存在基础问题：索引、数据检索或评估者提示环节出了故障，而非推理或歧义问题。
多跳与对比的性能急剧下降。当κ=0.71时，一致性仅处于中等水平，因此对于那些难以分解的长答案，其中的噪声因素可能解释了部分问题。在判定存在回归现象之前，应选取五份失败的转录文本，查看答案所需的两个段落是否都位于上下文中。如果只出现一个段落，那就是检索-召回问题，因为单次密集检索往往无法找到两个与查询不十分相似的事实，解决之道在于对查询进行分解或采用多查询检索，而非调整提示词。如果两个段落都出现了但对比仍失败，则问题出在合成环节，其中“中间丢失”效应是主要嫌疑因素：模型过度依赖第一个段落，而给予第二个段落的权重过低。
数值与财务数据显示κ值为0.52，属于较弱的一致性，却是表格中最为显著的信号，因为这意味着目前还无法信任该法官的判断。对于大型语言模型法官而言，实现数值上的等价性实在困难：“20%”、“大约五分之一”以及“100美元的商品减20美元”其实都是同一含义的不同表达方式。合理的做法是在评分标准确定之前不要使用RAG系统，因为追求不可靠的数值只会浪费开发时间。
政策与流程方面的情况与第一行一样平稳良好，但原因不同：答案通常来自一份结构清晰的文档，无需跨多份文档进行整合。如果该指标出现下降，首先应考虑的并非推理问题，而更可能是列表被分割在多个数据块之间，导致模型只能处理1到3步的内容，而需要自行编造4和5步的内容。
超出范围项应优先得到修正，尽管其样本量n=20是所有类别中最小的。在κ=0.90的评估标准下，该类别的判断结果非常可靠，因为识别出毫无依据的编造答案远比判断那些细微的数值或多步骤推理结论要容易。正是这种高可靠性使得错误率下降显得可信，而这也是表格中最为危险的故障类型。系统从正确选择“我不知道”转变为自信地编造答案，这种情况比给出错误数值更糟糕，因为其语气与正确答案毫无区别。造成这一问题的两个可能原因：一是检索系统返回了相似度较高的内容，模型误将其视为回答的依据；二是最近的提示词调整或模型更新悄悄移除了要求保持中立的指令。应首先检查该类别的检索相似度得分。如果它们接近噪声水平而模型仍给出回答，那就说明在生成之前缺少相关性阈值筛选机制。

五步完成评估方法

整个流程可简化为以下步骤：

不要依赖整体汇总结果
在信任评分之前先验证评分者的可靠性
按类别进行划分
根据实际证据推测是哪个环节出了问题
按照严重程度与置信度的乘积来确定优先级，而非仅看哪个标准变化最大

给新评估者的实用建议

每对一个响应进行评估都需要额外调用一次大语言模型。在处理大量数据时，只需对样本进行评估，而非全部内容，并按查询类别进行分类，这样那些罕见但关键的场景（如超出范围的情况）就不会被大量简单的查询所淹没。
每当评估模型或评估提示发生变化时，都需要重新验证卡帕值。任何一种变化都会生成新的评估者。

适应了某一领域数字表达或专业术语特性的评估器并不自动适用于另一领域，因此需针对每个领域单独进行校准，而非全局统一处理。

此处所有的示例和图表仅用于说明，并非来自实际生产系统。该框架及提示词结构可作为一个合理的起点。

局限性

上述内容涵盖了故障定位方法、现实依据与正确性之间的差距、基于声明级别的评估器，以及许多人会忽略的校准步骤。但仍存在一个局限：所有方法都假定存在一段完整的检索上下文。而当系统像代理系统那样调用工具、串联检索步骤或基于自身中间结果进行推理时，这一假定就不成立。在没有单一上下文块可供比对的情况下定义现实依据，并据此重新设计评估器，则是另一个需要解决的问题。