RAG评估与幻觉护栏：如何检测和阻止AI幻觉

RAG（检索增强生成）流水线很强大，但它引入了新的失败点。模型的表现完全取决于你喂给它的内容，而当它拿到错误的内容时，它不会说"我搞混了"——它会自信地给出答案。

用个通俗的比喻：开卷考试只有在学生翻对了书的情况下才有效。给他错误的章节，他照样能写出一份流畅、有说服力但完全错误的答案。

更关键的是，如果检索步骤拉取了错误的文档，LLM仍然会基于它写出流畅的回答。结果是自信且错误的——这意味着幻觉可能始于检索环节，而非模型本身。

分开衡量两个环节

评估RAG系统时，需要分别给它的两个环节打分，因为它们以不同的方式失败。

上下文相关性 考察的是检索到的文档是否真正包含用户问题的答案。这检验的是检索步骤。

忠实度 考察的是生成的回答是否严格来源于检索到的上下文，还是模型引入了外部信息。这检验的是生成步骤。

这两项指标之所以要分开看，是因为一个RAG系统的失败模式截然不同：检索失败意味着"书翻错了"，生成失败意味着"书翻对了但答案编造了"。混在一起评估，你根本不知道问题出在哪一环。

上下文相关性与信息检索领域经典的召回率（Recall）、**精确率（Precision）**相关但不完全相同。召回率衡量"答案所需的文档是否被检索到"，精确率衡量"检索到的文档有多少是相关的"，而上下文相关性更接近一个综合判断：检索结果整体是否足以回答用户问题。在实践中，召回率不足往往导致回答"缺料"，而精确率不足则会让大量无关噪声进入上下文，干扰生成模型。

忠实度则对应**事实一致性（Faithfulness / Factual Consistency）**这一概念，在自然语言生成评估中被广泛研究。它与"真实性（Truthfulness）"有微妙区别：真实性指回答是否符合客观世界事实，忠实度只要求回答不超出给定上下文。一篇上下文本身就错误的文档，模型忠实复述它时忠实度是高的，但真实性是低的。因此在RAG场景下，忠实度是更可度量、更可控的指标，而真实性还依赖检索源本身的可靠性。

识别不忠实的回答

忠实度检查是逐条声明（claim by claim）进行的。

举个例子：如果上下文说REIT在Q3支付了股息，而回答中额外提到它的收益率为7.4%，那么第二条声明并不在上下文中。它是被编造出来的——这就是幻觉，即使它听起来完全合理。

这种逐条比对的方式，比整体打分更精确。一个回答可能90%的内容有据可查，但混入了10%的编造信息，整体看起来"还不错"，但那10%的幻觉足以误导用户做出错误决策。

护栏：用LLM做裁判

这种检查可以自动化。一个辅助的小型LLM在流水线中充当裁判角色。在最终答案到达用户之前，裁判将它与检索到的文本进行比对，决定是放行还是拦截。

当检查不通过时，你可以选择重试检索，或者直接返回"我不知道"。

这里有一个简短的Python示例。llm_judge函数代表调用一个小模型，通过提示词让它比对答案和上下文：

def guarded_answer(question: str) -> str:
    chunks = search(embed(question), top_k=3)
    answer = generate(question, chunks)

    # 裁判：答案中的每条声明是否都被检索文本支持？
    verdict = llm_judge(
        "Reply SUPPORTED or UNSUPPORTED. Is every claim in the answer "
        "backed by the context?\n\n"
        f"Context: {chunks}\n\nAnswer: {answer}"
    )
    if verdict.strip().upper().startswith("SUPPORTED"):
        return answer
    return "I could not find a reliable answer in the documents."

核心逻辑很清晰：检索→生成→裁判审核→放行或拦截。裁判返回"SUPPORTED"则输出答案，否则返回兜底话术。

裁判本身也可能出错，所以要对其决策进行抽样审查。这一点常被忽略——很多团队部署了裁判机制后就默认它永远正确，但实际上裁判模型同样需要评估和校准。

用LLM充当裁判的做法通常被称为 LLM-as-a-Judge，其核心假设是：强大的语言模型在给定明确标准和上下文时，判断质量可以接近人类标注者，同时成本远低于人工。它已被用于评估摘要质量、对话有用性等多种任务。

但这一方法存在已知偏差：裁判模型可能偏好更长的回答、与自己风格相似的输出，或在位置排列上偏向先出现的选项。因此在实际部署中，通常需要固定提示词模板、随机化选项顺序、定期与人工标注做对比校准。常见的可靠性指标包括裁判与人类判断的一致率（agreement rate），一致性过低时应考虑换用更强的裁判模型或增加人工复核比例。这些细节决定了护栏是真护栏还是摆设。

建立回归测试集

维护一个小型测试集，包含真实问题和已知答案，每次修改分块策略、嵌入模型或提示词时都运行一遍。

这是在上线前发现回归问题的方法。RAG系统的参数调整往往牵一发动全身——改了分块大小可能影响检索质量，换了嵌入模型可能改变相似度排序，调整提示词可能影响生成风格。没有回归测试，你就是在拿用户当测试对象。

测试集不需要很大，但要覆盖典型场景和边界情况。关键是每次变更都跑，形成习惯。

回归测试集本质上是一套黄金数据集（Golden Dataset），即一组带有标准答案或标准判断的输入样本，用于在系统变更后快速验证行为未退化。它与单元测试的思路一脉相承：不追求覆盖率，而追求对关键路径的持续守护。

在RAG场景中，测试集通常需要覆盖三类情况：正常问题（验证基本能力）、边界问题（如多跳推理、需要跨文档综合的问题）、对抗性问题（如检索源中本就缺少答案、或存在干扰文档的情况）。后两类最容易暴露检索与生成的协同缺陷。建议为每个测试样本同时记录"期望检索到的文档"和"期望答案"，这样一次运行就能同时评估上下文相关性与忠实度两项指标，让回归信号更完整。

核心要点

RAG系统的幻觉防治需要从两个维度入手：分开评估检索和生成环节，用上下文相关性和忠实度两个指标定位问题；通过LLM裁判实现自动化的幻觉护栏，在答案到达用户前进行拦截；持续维护回归测试集，确保系统变更不会引入新的问题。

背景补充

在工程实践中，还可引入 RAGAS、TruLens 等开源评估框架，它们把上下文相关性、忠实度、答案相关性等指标封装为可调用的评估函数，减少从头搭建度量逻辑的成本。同时，把评估与护栏做成流水线中的固定环节（如 CI 流程），可以让"每次改动都跑测试"从人工习惯变成自动约束，进一步降低回归风险。