RAG是如何产生幻觉的

先看一个在实际系统中非常典型的场景。

用户提问：“BM25 和 TF-IDF 的主要区别是什么？”

系统返回了一段看似专业的回答，但其中出现了这样的描述：

“BM25 在计算词频时采用平方项增强高频词的重要性”。

从语言表达上看，这段回答没有明显问题，看起来也很专业，但如果你熟悉BM25算法，会立刻发现这句话是错误的。BM25 并不是通过平方项放大高频词，而是通过一种词频饱和机制限制高频词的边际收益，避免某个词因为重复出现过多而被过度放大。

这类现象正是RAG系统中非常典型的幻觉表现：答案并非胡编乱造，而是建立在某些真实信息基础上的“合理错误”。这种错误往往比明显的胡说八道更具迷惑性，因为它通常语言流畅、结构完整、术语正确，却在关键细节上偏离事实。

要理解这类问题的根源，不能只盯着LLM本身，需要先把RAG系统的处理流程拆开来看。

一个典型的RAG pipeline可以抽象为：

Query -> Retrieval -> Context -> LLM -> Output

用户Query首先进入检索模块，从向量数据库或文档库中召回若干候选片段；这些片段随后被筛选、拼接并组织成上下文；最后，LLM基于这些上下文生成最终答案。

在这个过程中，信息并不是原封不动地流动，而是在每一个环节中被加工、压缩、选择和重组。每一次处理都可能引入信息损失、语义偏移或噪声污染。

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

因此，RAG幻觉的本质并不是某一个模块的孤立问题，而是信息在系统链路中逐步偏移的结果。它既不是单纯的检索问题，也不是单纯的生成问题，而是一个典型的“系统性误差累积”。

从工程角度看，这意味着不能通过单点优化来彻底解决幻觉问题，而必须对整条链路进行系统化分析与优化。这也是本文的核心思路：从RAG的信息流动链路出发，逐层定位问题，并针对不同阶段给出相应的优化策略。

RAG幻觉的本质与类型

什么是RAG幻觉

在定义层面，可以将RAG幻觉理解为：

模型生成的内容与其所依据的检索证据不一致。

这一定义强调了"证据一致性"——即答案是否能够被上下文支撑。

从系统架构的角度看，RAG本质上是在做"受约束的生成"。模型不应该完全依赖自身预训练知识自由发挥，而应该基于检索结果进行回答。换句话说，RAG 的目标不是让模型“知道更多”，而是让模型“依据给定证据回答”。

但在现实系统中，这种约束往往并不牢固。即使提供了上下文，模型仍然可能受到自身预训练知识、语言模式和推理习惯的影响，从而生成与证据不一致的内容。

这也使得 RAG 幻觉与传统大模型幻觉有所不同。

传统大模型幻觉更多发生在信息缺失的情况下，模型为了补全回答而“无中生有”。而 RAG 幻觉通常发生在“有信息”的情况下：系统确实检索到了内容，但这些内容可能不完整、不准确、相互冲突，或者被模型错误理解。最终结果不是“无中生有”，而是“有中生错”。

这类错误更加隐蔽，也更难定位。很多时候，表面上看是模型生成错了，但真正的问题可能早在检索、分块、排序或上下文组织阶段就已经出现。

幻觉类型

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

这四类幻觉对应着RAG系统的四个关键阶段：

Query -> Retrieval -> Context -> LLM -> Output

检索 上下文构建 生成 输出

在这条链路中，每个模块都会对信息进行加工，而这种加工并不总是保真的。随着信息不断传递，误差会逐层积累，并最终在生成阶段被显性化。

这也是为什么很多 RAG 幻觉在表面上看是“模型回答错了”，但根因往往出现在更早的环节。幻觉并不是突然发生的，而是在信息链路中逐步形成的。

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

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

在 RAG 系统中，检索质量往往决定了答案质量的上限。如果检索阶段无法召回正确证据，那么后续再复杂的 Prompt、再强的模型，也很难生成可靠答案。

检索阶段常见的问题包括：

• 召回了不相关内容；
• 遗漏了关键文档；
• Top-K 排序不合理；
• chunk 划分破坏语义完整性；
• embedding 模型与业务领域不匹配；
• 查询改写不准确，导致检索方向偏移。

其中，chunk 划分是一个非常容易被低估的问题。

如果 chunk 过大，一个片段中会混入大量无关信息，降低上下文的信息密度；如果 chunk 过小，又可能切断完整语义，使模型无法理解上下文之间的关系。例如，一个技术概念的定义、条件和例外说明被切到不同片段中，模型可能只看到其中一部分，从而生成片面的结论。

这一阶段可以通过以下方式诊断：

• 使用 Recall@K 判断 Top-K 结果中是否包含正确答案；
• 使用 MRR 或 NDCG 评估排序质量；
• 对 Top-K 结果进行人工抽样分析；
• 检查系统是否总是偏向某类文档、某类格式或某些高频但低价值内容；
• 对失败案例进行归因，判断是“没召回”还是“召回了但排序靠后”。

优化策略通常可以从三个方向入手。

首先是文档预处理优化。与其简单按照固定长度切分，不如结合标题、段落、列表、代码块和语义边界进行分块。对于结构化文档，还可以保留标题层级、章节路径和元数据，帮助后续检索更准确地理解片段语境。

其次是检索策略优化。单纯依赖向量检索，可能会在关键词精确匹配场景下失效；单纯依赖 BM25，又可能无法处理语义相近但表达不同的问题。因此，在很多实际系统中，可以采用混合检索策略，将 BM25 与向量检索结合起来，兼顾关键词匹配和语义匹配。

最后是引入重排序模型。初始召回阶段可以尽量提高覆盖率，而在候选结果召回后，再使用 reranker 对结果进行精排，提高真正相关片段在 Top-K 中的排名。

检索阶段的核心目标不是“召回更多内容”，而是“召回更可靠、更相关、排序更合理的证据”。

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

即使检索阶段已经召回了正确内容，如果上下文构建不合理，最终结果仍然可能出现偏差。

RAG 系统中一个常见误区是：只要把 Top-K 检索结果全部塞进 Prompt，答案就会更准确。但事实往往相反。上下文不是越多越好，低质量上下文反而会干扰模型判断。

上下文构建阶段常见的问题包括：

• Top-K 中混入部分低相关片段；
• 关键答案被截断；
• 多个片段之间存在冲突信息；
• 文档来源、时间或版本信息缺失；
• 上下文拼接顺序不合理；
• 模型无法区分主信息与背景噪声。

例如，一个问题的正确答案可能出现在第三个片段中，但前两个片段包含大量相似但不完全相关的内容。模型在生成时可能会优先利用前面的内容，从而得出偏离事实的结论。

这一阶段可以从“信息密度”的角度进行诊断：

• 上下文中真正与问题相关的内容占比是多少；
• 关键答案是否完整出现；
• 是否存在多个相互冲突的片段；
• 模型输出中的错误信息是否能追溯到某个低质量片段；
• 上下文排序是否影响最终答案。

优化的核心在于信息选择与信息组织。

首先，可以通过相似度阈值过滤低相关片段，而不是机械地使用固定 Top-K。对于一些简单问题，可能只需要 2 到 3 个高质量片段；对于复杂问题，则需要更多证据进行交叉验证。

其次，可以基于 rerank 结果动态选择上下文，将最相关、最完整、最权威的片段优先放入 Prompt。这里的重点不是把所有信息都放进去，而是让模型看到最应该看到的信息。

再次，可以对上下文进行结构化组织。例如，为每个片段标注来源、标题、时间、版本和相关度；对于多个来源的信息，可以按主题分组，而不是简单拼接。结构化上下文通常比无序堆叠更容易被模型正确利用。

本质上，上下文构建不是简单的数据拼接，而是在做信息编排。这一阶段的目标，是让模型在有限上下文窗口内看到高密度、低噪声、可追溯的证据。

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

在很多情况下，即使上下文中已经包含正确答案，模型仍然可能输出错误内容。这类问题通常来自模型的“先验偏置”。

所谓先验偏置，是指模型倾向于使用自身预训练过程中学到的知识、表达模式和常见说法，而不是严格依据当前输入上下文回答。尤其当上下文表达不够明确，或者问题涉及模型训练中常见概念时，模型很容易自动补全出一个“看起来合理”的答案。

这也是 RAG 中很常见的一类幻觉：证据已经给出，但模型没有真正使用证据。

这一阶段可以通过以下方式诊断：

• 检查答案中的关键事实是否能在上下文中找到明确来源；
• 分析模型是否引入了上下文之外的新概念；
• 对比不同 Prompt 下模型是否稳定引用同一证据；
• 检查模型是否在证据不足时仍然给出确定性结论；
• 观察模型是否存在“过度概括”或“自动补全”的倾向。

优化生成阶段的关键在于增强约束，让模型从“自由生成”转向“受控生成”。

常见方法包括：

• 在 Prompt 中明确要求模型仅基于上下文回答，不要使用外部知识进行补充。
• 要求模型在证据不足时返回“无法确定”或“根据当前资料无法回答”，而不是强行生成完整答案。
• 降低 temperature，减少输出随机性，提高回答稳定性。
• 引入结构化输出，例如要求模型按照“结论—依据—来源”的格式回答。这样可以迫使模型在生成结论时同时考虑证据支撑。
• 在答案中加入引用或证据标注，让每个关键结论都能追溯到具体片段。

生成阶段的目标不是让模型回答得更流畅，而是让模型回答得更可控、更可验证。

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

即使检索、上下文和生成阶段都处理得较好，模型仍然可能在推理过程中出错。

这类错误往往最难发现，因为它们通常不是事实层面的明显错误，而是逻辑推导、比较判断或多步归纳中的偏差。例如，上下文中分别说明了两个算法的特点，模型在总结区别时却错误地合并了两者的机制，最终生成一个听起来合理但实际上不准确的结论。

推理型幻觉常见于以下场景：

• 多文档综合；
• 技术概念对比；
• 复杂规则判断；
• 数值计算；
• 条件推理；
• 因果归纳。

解决这类问题，需要在生成之后增加验证机制。

• 自验证：在模型生成答案后，让模型再次判断答案中的每个关键结论是否被上下文支持，并指出对应证据。如果某个结论找不到证据，则要求模型修改或删除。
• 二次检索验证：针对答案中的关键结论重新发起检索，检查是否存在支持证据或反例。这种方式尤其适合对事实准确性要求较高的场景。
• 答案分解机制：对于复杂问题，不直接生成最终答案，而是先拆解为若干子问题，分别检索和验证，再进行汇总。这样可以降低模型在单次生成中承担过多推理负担。

此外，系统设计中应该允许模型表达不确定性。对于证据不足、文档冲突或推理链条不完整的情况，返回“无法确定”往往比生成一个看似完整但错误的答案更安全。

推理与验证阶段的核心目标，是让答案不仅“看起来合理”，还要“经得起证据检查”。

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

RAG 并不是简单地把检索结果塞给大模型，而是一个涉及信息获取、筛选、组织、生成和验证的系统工程。

幻觉问题很难被彻底消除，但可以通过工程手段显著降低。真正的优化关键，不是不断微调 Prompt，而是减少不确定性在系统中的传播路径，让模型始终在可控、可验证的证据范围内生成答案。

从这个角度看，RAG 的核心能力不是“让模型更会说”，而是“让系统更会管理信息”。

一个可信赖的 RAG 系统，需要的不只是更强的大模型，还需要更好的检索、更干净的上下文、更严格的生成约束，以及更完善的验证机制。

也就是说，RAG 的本质不是提示工程，而是信息工程。只有从系统层面重新审视信息如何进入、流动、组织和被使用，才能真正降低幻觉，构建更加可靠的智能问答系统。