RAG是如何产生幻觉的

先看一个在实际系统中非常典型的场景。用户提问：“BM25 和 TF-IDF 的主要区别是什么？”系统返回了一段看似专业的回答，但其中出现了这样的描述：“BM25 在计算词频时采用平方项增强高频词的重要性”。从语言上看，这段回答没有明显问题，但如果你熟悉BM25算法，会立刻发现这句话是错误的。这类现象正是RAG系统中最典型的幻觉表现：答案并非胡编乱造，而是建立在某些真实信息基础上的“合理错误”。这种错误往往更具迷惑性，因为它不像明显的胡说八道那样容易被识别，而是在细节上偏离事实。

要理解问题的根源，需要先把RAG系统的处理流程拆开来看。一个典型的RAG pipeline可以抽象为：用户Query首先进入检索模块，从向量数据库或文档库中召回若干候选片段；这些片段随后被拼接、筛选并组织成上下文；最后，大模型基于这些上下文生成最终答案。在这个过程中，信息经历了多次转换与压缩，每一次处理都会带来一定的信息损失或偏差。

关键在于，这条链路是“串联”的，而不是“独立”的。也就是说，一旦前面的环节出现问题，后面的模块不仅无法纠正，反而可能进一步放大错误。例如，如果检索阶段召回了部分不准确的文档，而上下文构建阶段没有有效过滤，那么这些错误信息就会直接进入模型输入，从而影响最终生成结果。

因此，RAG幻觉的本质并不是某一个模块的问题，而是信息在系统链路中逐步偏移的结果。它既不是单纯的检索问题，也不是单纯的生成问题，而是一个典型的“系统性误差累积”。从工程角度看，这意味着我们不能通过单点优化来彻底解决幻觉问题，而必须对整条链路进行系统化分析与优化。这也是本文的核心思路：从链路出发，逐层定位问题，并针对性地给出优化策略。

RAG幻觉的本质与类型

什么是RAG幻觉

在定义层面，可以将RAG幻觉理解为：模型生成的内容与其所依据的检索证据不一致。这一定义强调了"证据一致性"——即答案是否能够被上下文支撑。从系统架构的角度看，RAG本质上是在做"受约束的生成"，模型的输出理应受到检索结果的严格限制。然而在现实中，这种约束往往并不牢固，模型仍会在一定程度上依赖自身的预训练知识，从而产生偏离。

与传统大模型的幻觉相比，RAG幻觉呈现出独特的"隐蔽性"特征。传统幻觉往往是模型在缺乏信息时"无中生有"，而RAG幻觉则是在"有信息"的情况下"有中生错"——模型基于不完整、不准确或被误解的检索证据生成错误内容。这种差异使得问题更难定位：很多人在直觉上会把幻觉归因于大模型本身，但在RAG系统中，更准确的理解是：幻觉是信息在系统中传播时逐步偏移的结果。从检索到生成的整个链条中，任何环节的信息失真都可能导致最终输出的偏差，这正是RAG幻觉复杂性的根源所在。

幻觉类型

从RAG系统的处理链路角度来看，幻觉大致可以分为四种类型：

• 检索型幻觉，即系统召回了错误或不相关的文档，导致后续全部建立在错误基础之上（garbage in，garbage out）

• 上下文型幻觉，即检索结果本身正确，但在拼接过程中关键信息被截断或被噪声淹没。

• 生成型幻觉，即模型没有正确利用上下文，而是依赖自身预训练知识进行补全。

• 推理型幻觉，即上下文是正确的，但模型在逻辑推导过程中出错。

这四类问题对应着RAG系统的四个关键阶段：检索、上下文构建、生成与推理。

如果用一条链路来表示，可以抽象为：Query->Retrieval->Context->LLM->Output

在这条链路中，每一个模块都会对信息进行加工，而这种加工往往不是完全保真的。随着信息不断传递，误差会逐渐积累，最终在生成阶段被“显性化”。这也是为什么很多幻觉问题在表面上看是生成错误，但实际上根源可能在更早的阶段。幻觉并不是突然出现的，而是在这条链路中逐步积累的偏差。

RAG幻觉问题的逐层诊断与优化

检索阶段：错误是如何被引入的

在实际系统中，检索质量往往决定了RAG的上限。如果检索阶段无法召回正确答案，那么后续再复杂的生成策略也无济于事。常见的问题包括召回不相关内容、遗漏关键文档，以及chunk划分不合理。例如，当chunk过大时，会混入大量无关信息；当chunk过小时，则会破坏语义完整性，使得模型难以理解上下文。

在诊断层面，可以通过Recall@K来判断Top-K结果中是否包含正确答案，通过MRR评估排序质量。同时，一个非常有效的方法是对Top-K结果进行人工抽样分析，这往往能快速发现问题模式，例如是否存在系统性偏差（如总是偏向某类文档）。

优化策略通常从三个方向入手。首先是文档预处理，例如采用语义分块而不是固定长度切分，并结合标题或段落结构进行划分。其次是检索策略优化，例如将BM25与向量检索结合，兼顾关键词匹配与语义匹配。最后是引入重排序模型，对候选结果进行精排，从而提升Top-K的整体质量。在这一阶段，一个常见但容易被忽视的问题是embedding模型与领域不匹配，这在专业领域中尤为明显。

上下文构建：信息是如何被污染的

即使检索阶段表现良好，如果上下文构建不合理，仍然会导致最终结果出现偏差。最典型的问题是噪声信息的引入，例如Top-K结果中包含部分低相关片段，而这些片段在拼接后会干扰模型判断。此外，token长度限制也可能导致关键信息被截断，或者多文档之间存在冲突信息。

诊断这一阶段，可以从信息密度的角度入手，例如分析上下文中真正与问题相关的内容占比，以及关键答案是否完整出现。同时，也可以观察模型输出是否引用了错误片段，从而反推上下文质量。

优化的核心在于“信息选择与组织”。具体来说，可以通过相似度阈值过滤低质量片段，或者基于rerank结果动态选择上下文，而不是固定使用Top-K。此外，对信息进行结构化组织（例如分组呈现、标注来源）往往比简单拼接更有效。本质上，这一步是在做信息编排，而不是简单的数据拼接。

生成阶段：模型为什么无视证据

在很多情况下，即使上下文中已经包含正确答案，模型仍然可能输出错误内容。这种现象通常来源于模型的“先验偏置”，即模型倾向于使用自身训练数据中的知识，而不是严格依赖输入上下文。

诊断这一问题，可以通过分析答案与上下文的对应关系来实现，例如检查答案中的关键信息是否可以在上下文中找到来源。如果发现模型经常“脱离上下文”，说明生成约束不足。

在优化层面，关键在于增强约束。可以通过Prompt明确要求模型仅基于上下文回答，并在无法确定时返回“不知道”。同时，通过降低temperature可以减少随机性，使输出更加稳定。此外，结构化输出（例如要求附带证据）可以显著提升模型对上下文的依赖程度。这些方法的共同目标，是将生成过程从“自由生成”转变为“受控生成”。

推理与验证：如何减少看似合理的错误

即使前面三个阶段都处理得较好，模型仍可能在推理过程中出现错误。这类错误往往最难发现，因为其上下文和表达都没有明显问题。

为了解决这一问题，可以引入自验证机制。例如，在生成答案后，让模型再次判断该答案是否被上下文支持，或者要求其指出证据来源。另一种方法是进行二次检索验证，即针对生成结果中的关键结论重新检索，以确认其正确性。此外，在系统设计中允许模型表达不确定性（例如返回“无法确定”）也是非常重要的，这比输出错误信息更安全。

结语：RAG的本质是信息工程，而不是提示工程

RAG 并不是简单地把检索结果塞给大模型，而是一个涉及信息获取、筛选、组织和利用的系统工程。幻觉问题无法完全消除，但可以通过工程手段显著降低。真正的优化关键在于减少不确定性在系统中的传播路径，从而让模型在“可控范围内”生成结果。与其不断调 prompt，不如从系统层面重新审视信息流动的每一个环节，这才是构建可信赖 RAG 系统的根本方法。