RAG入门：从“为什么”到“是什么” / RAG Fundamentals: From Why to What

第 1 章：RAG 入门：从“为什么”到“是什么”

大模型的“幻觉”问题：一场信任危机

让我们从一个真实的场景开始。2023 年，一家金融科技公司的产品经理向公司内部部署的大语言模型（LLM）提问：“我们公司去年第四季度的毛利率是多少？”模型迅速给出了几个百分比数字，看起来信心满满。然而，当产品经理去财务部门核实时，发现这些数字完全是捏造的——模型既不知道真实数据，也不懂得说“我不知道”，而是流畅地编织出了一套自洽的“答案”。

这并非个例。在过去两年间，无数用户报告了类似的现象：大模型会一本正经地介绍不存在的法律条文、杜撰从未发表的学术论文、描述虚构的历史事件细节，甚至在被明确指出错误后，仍可能坚持自己的“错误记忆”。这种现象被业界称为幻觉（Hallucination），它正在成为大模型落地企业场景的最大障碍之一。

为什么会这样？要回答这个问题，我们需要理解大模型的知识究竟从何而来，以及这些知识存在怎样的根本性局限。

1.1 大模型为什么会产生幻觉？

1.1.1 知识的两个来源：参数化知识与上下文知识

要理解幻觉的根源，我们首先需要了解大模型拥有知识的两种方式。

参数化知识（Parametric Knowledge） 是指模型在训练阶段从海量文本数据中学习到的知识，这些知识被编码在模型的数十亿个神经网络权重之中。当我们与模型对话时，它完全依赖这些“记忆”来回答问题。这种方式的优点是模型能够进行复杂的推理和生成连贯的文本，缺点是这些知识是静态的、模糊的、难以直接访问和验证的。

上下文知识（In-context Knowledge） 是指在每次对话中通过提示词（Prompt）提供给模型的信息。这种知识是动态的、精确的，但受限于模型的上下文窗口大小。例如，如果你告诉模型“我家里有两只猫”，模型可以在当前对话中记住这个事实，但这个信息不会自动进入模型的“长期记忆”。

大模型的幻觉问题，主要源于参数化知识的三重困境。

1.1.2 困境一：知识的时间性——训练数据的截止日期

大模型的知识有明确的“保质期”。以 GPT-4 为例，它的知识截止到 2023 年 12 月，这意味着在此之后发生的任何事件——公司并购、新产品发布、政策法规变化、重大新闻——对模型来说都是不可见的。你问它“今天有什么科技新闻”，它无法给出真实答案，因为它根本不知道“今天”是哪一天。

这在快速变化的商业环境中尤为致命。想象一个法律顾问场景：用户询问某条法规的最新修订内容，而模型脑海中只有三年前的版本。即便法规已经被废止或大幅修改，模型仍会信誓旦旦地引用旧法规。这种“知识过时”问题不是模型的“失误”，而是其架构的固有局限。

1.1.3 困境二：知识的模糊性——从统计模式到“记忆”

大模型是如何“记住”知识的？这与传统数据库的精确存储截然不同。当模型在训练数据中反复看到“北京是中国的首都”这句话时，模型会调整其数十亿个参数，使得在遇到相关上下文时能够生成“北京是中国的首都”这个输出。但这种“记忆”是分散的、概率性的——它不是一条可以精确查询的数据库记录，而是一种对语言模式的深度编码。

这就解释了为什么模型有时会混淆细节。一个模型可能正确知道“爱因斯坦提出了相对论”，但可能会把相对论的具体年份搞错，或者将其他物理学家的贡献误植到爱因斯坦身上。这是因为知识不是以“事实-值”的形式存储的，而是以复杂的神经网络权重分布存储的，模型在生成时会进行“插值”和“组合”，这可能导致细节的漂移。

1.1.4 困境三：知识的边界——何时说“我不知道”？

大模型的第三个困境是它缺乏可靠的自我认知边界。当模型遇到它完全不知道的问题时，它通常不会说“我不知道”，而是会尝试根据训练数据中的模式“猜”一个答案。这是因为模型的训练目标是生成“看起来正确”的文本，而不是判断“这个答案是否正确”。

训练数据中包含了大量的问答对，其中很多问题的答案是“我不知道”或信息不足。但模型学到的是如何生成“合理”的回答，而不是“诚实”的回答。在实际部署中，我们发现模型倾向于表现得像“万事通”，即便它的知识存在明显空白。这种过度自信（Overconfidence）使得用户难以判断何时可以信任模型的输出。

1.1.5 幻觉的深层机制：概率生成的本性

从技术角度看，大模型的本质是一个概率文本生成器。给定一段前缀文本，模型会计算所有可能的后续词汇的概率分布，然后从中采样生成下一个词。这个过程重复进行，就产生了我们看到的连贯回答。

问题是：这个生成过程没有内置的“真实值检验”机制。模型不知道也不关心它正在生成的文字是否与现实世界对应。它只是在执行一个优化目标：生成与训练数据风格相似、语法正确、语义连贯的文本。当训练数据中存在某种模式时，模型会倾向于复现这种模式，即便这种模式与当前查询的真实答案不符。

举一个具体的例子：假设训练数据中有这样一段话：“2022年，特斯拉公司的市值超过了1万亿美元。”模型学到的是“特斯拉”和“市值”、“1万亿美元”这些词之间的强关联。当你问“特斯拉的市值是多少”时，模型很可能输出类似“超过1万亿美元”的答案——即便现在已经是2025年，即便特斯拉的市值早已跌破这个数字。模型不是在“回忆”事实，而是在“复现”训练数据中的常见表述模式。

1.1.6 总结：幻觉不是bug，而是LLM架构的固有特征

通过以上分析，我们可以得出一个关键结论：大模型的幻觉问题不是模型能力不足导致的“错误”，而是其架构设计的必然结果。参数化知识的静态性、模糊性和不可验证性，共同构成了幻觉产生的温床。

这是否意味着大模型无法被信任？答案当然是否定的。大模型在语言理解、代码生成、创意写作等任务上展现出惊人的能力。但如果我们希望将大模型应用于需要事实准确性的场景——法律咨询、财务分析、医疗诊断、产品说明——我们就必须找到一种方法来弥补参数化知识的这些缺陷。

这正是 RAG（检索增强生成）技术被提出的背景。

1.2 RAG的定义与工作原理

1.2.1 什么是RAG？

RAG（Retrieval-Augmented Generation，检索增强生成） 是一种将信息检索系统与语言模型生成能力相结合的技术框架。其核心理念是：在模型生成回答之前，先从外部知识库中检索与用户问题相关的信息，然后将这些信息作为上下文提供给模型，使其能够基于真实的、可验证的数据来生成回答。

用一句话概括 RAG 的工作方式：“先查后生成，用真实资料说话。”

这个概念最早由 Facebook AI Research（现 Meta AI）在 2020 年的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出。论文的作者们意识到，对于需要丰富知识储备的任务（如开放域问答），单纯依靠模型的参数化知识存在明显瓶颈。他们提出的解决方案是：为模型配备一个“外脑”——一个可以按需查询的知识库，让模型在生成回答时参考最新的、最准确的信息。

1.2.2 RAG的工作流程

RAG 的完整工作流程可以分解为以下五个核心步骤：

第一步：用户提问。 用户向系统提交一个自然语言问题，例如“公司2023年的营收同比增长了多少？”

第二步：查询编码。 系统将用户的问题转换为一个向量表示（embedding）。这个向量捕捉了问题语义上的关键信息，使得系统能够找到与问题在语义上相关的内容。

第三步：知识检索。 系统在外部知识库（通常是向量数据库）中搜索与问题向量最相关的文档或文档片段。这个检索过程是语义层面的——它寻找的是与问题含义相近的内容，而不仅仅是关键词匹配。

第四步：上下文组装。 系统将检索到的相关文档（或文档片段）与原始问题组合成一个“扩展后的提示词”，这个提示词包含了问题答案所需的关键信息。

第五步：生成回答。 语言模型接收这个扩展后的提示词，基于其中提供的真实信息生成最终回答。由于模型现在有了明确的参考资料，它的回答将更准确地反映这些资料的内容，而非依赖其参数化知识中可能过时或不准确的部分。

下面这张流程图展示了整个 RAG 系统的工作过程：

```mermaid graph TD A[用户查询<br>User Query] --> B[查询编码<br>Query Encoding] B --> C[向量数据库检索<br>Vector Search] C --> D[相关文档<br>Relevant Documents] D --> E[上下文组装<br>Context Assembly] E --> F[LLM生成<br>LLM Generation] F --> G[最终回答<br>Final Answer]

H[(知识库<br>Knowledge Base)] -.-> C ```

这个流程的核心洞察是：让模型从“知识的持有者”转变为“知识的整合者”。模型不再需要从自己的参数中“回忆”答案，而是可以引用外部资料的精确内容来构建回答。这从根本上改变了知识与模型之间的关系。

1.2.3 一个具体的例子

让我们通过一个具体例子来理解 RAG 的价值。假设用户问：“《中华人民共和国个人信息保护法》对生物识别信息的处理有什么特别要求？”

不使用 RAG 的传统方式：模型基于其训练数据中关于《个人信息保护法》的文本进行回答。模型可能准确也可能不准确；可能引用了已经修改的条款，也可能遗漏了最新的司法解释。用户无法验证模型回答的准确性。

使用 RAG 的方式：系统首先从法律数据库中检索《个人信息保护法》的相关条款，特别是涉及生物识别信息的第二十八条到第三十二条。然后，系统将检索到的法条内容作为上下文提供给模型。模型基于这些真实的法条内容生成回答，引用具体的条款编号和内容要点。用户可以追溯到具体的法条来源进行核实。

这个对比揭示了 RAG 的核心价值：从“记忆回答”转变为“参考文献回答”。模型的职责从“存储知识”变为“理解和整合知识”，而知识的准确性和时效性则由外部知识库来保障。

1.2.4 RAG与微调的区别

在讨论 RAG 时，一个常见的混淆是将其与模型微调（Fine-tuning）进行对比。虽然两者都旨在提升模型在特定任务上的表现，但它们解决问题的方式截然不同。

微调是通过在特定领域的数据上继续训练模型，来调整模型的参数，使模型“记住”更多特定知识。微调的优点是模型的推理速度不会受影响，回答风格可以定制化。缺点是知识仍然以参数形式存储，存在更新困难、可能产生幻觉、无法提供可追溯来源等问题。

RAG 则采取了完全不同的路径：它不修改模型参数，而是在推理时动态引入外部知识。优点是知识库可以独立更新（无需重新训练模型）、回答可追溯、透明可控。缺点是需要维护额外的检索系统、推理延迟可能增加、检索质量直接影响回答质量。

用一个比喻来说明：如果把大模型比作一个知识渊博但记忆有时模糊的专家，微调相当于送这个专家去参加专业培训，让他记住更多知识；RAG 则相当于给这个专家配备一个随身资料库，让他在回答问题前先查阅最新的资料。

在实践中，两种方法并非互斥，而是可以互补使用。对于需要模型深刻理解领域逻辑和表达风格的任务（如客服对话风格），微调更为适合；对于需要频繁更新知识、强调答案可追溯性、追求最大准确性的场景（如法律咨询、产品问答），RAG 是更优选择。

1.3 RAG的三大核心优势

通过上述分析，我们可以清晰地看到 RAG 相对于纯参数化模型的核心优势。这些优势并非技术上的偶然，而是 RAG 架构设计的必然结果。

1.3.1 优势一：实时性——知识库与模型能力的解耦

传统大模型的知识更新是一个痛苦的过程。由于知识被编码在数十亿个参数中，每次更新都需要收集新的训练数据、进行昂贵的重新训练或微调，这通常需要数周到数月的时间。在此期间，模型的知识会逐渐过时。

RAG 彻底改变了这一困境。由于知识存储在独立的外部知识库中，更新知识只需要更新知识库本身——这就像更换一个文件夹那么简单。一个企业可以每天更新其产品文档、新闻动态、政策法规，而无需触碰模型本身。

这种知识与模型的解耦带来了几个关键好处。首先，知识更新可以做到准实时——从新产品发布到系统响应可能只需要几分钟。其次，多个不同的应用可以共享同一个知识库，避免了为每个应用单独微调模型的资源浪费。第三，当发现知识错误时，修正成本极低——只需要修改知识库中的相应文档。

考虑一个电商场景：某品牌在“双十一”期间推出了限时促销活动。如果使用传统方式，系统可能需要提前数周将促销信息注入模型，而促销结束后又要防止模型继续提及这些活动。使用 RAG 的话，促销活动文档可以在活动开始前几分钟上传到知识库，活动结束后直接移除即可。这种灵活性是参数化知识无法实现的。

1.3.2 优势二：可解释性——答案的来源可追溯

当用户问一个关键问题并收到回答时，他们自然想知道：这个回答的依据是什么？传统大模型无法回答这个问题——它的回答源自数十亿参数的复杂交互，没有办法解释“第 5376421 个参数决定了答案是这样的”。

RAG 改变了这一局面。由于每个回答都基于检索到的具体文档，理论上我们可以说：“这个答案的依据是某某文档的第几页”。这种答案的透明性和可追溯性对于许多应用场景至关重要。

在法律领域，律师需要确保引用的法条是准确的；在医疗领域，医生需要能够向患者解释诊断依据；在金融领域，分析师的报告需要能够经受审计。这些场景都要求对答案来源的精确把控，而 RAG 提供了这种能力。

更进一步，一些 RAG 系统会显式地在回答中引用来源文档，甚至标注出回答的哪个部分对应哪个文档片段。这种“带注释的回答”不仅增强了用户信任，也为用户提供了验证和深入学习的路径。

1.3.3 优势三：可控性——知识边界与质量的主动管理

RAG 的第三个优势是对知识边界和质量的精细控制。使用纯参数化模型时，我们很难精确控制模型在某个话题上“知道什么”和“不知道什么”。模型可能会在我们不希望的领域信口开河，也可能在核心领域缺乏深度。

通过 RAG，我们可以精确地定义模型的知识边界：哪些文档是它应该参考的，哪些文档是它不应该使用的。对于敏感话题，我们可以通过访问控制确保模型只能检索经过审核的内容。对于不同用户群体，我们可以配置不同的知识库——例如，向内部员工开放的内部文档不会出现在面向外部用户的检索结果中。

此外，RAG 还允许我们进行多层次的质量控制：我们可以通过选择更权威的知识来源来提升回答质量；可以通过设置相关性阈值来过滤低质量的检索结果；可以通过后处理策略来过滤或修改模型的输出。这种端到端的可控性是 RAG 在企业级应用中广受欢迎的重要原因。

1.3.4 三大优势的协同效应

值得强调的是，实时性、可解释性和可控性并非孤立的优势，它们相互强化，共同构成了 RAG 在企业场景中的核心价值。

实时性确保了系统能够反映最新情况；可解释性让用户能够验证和信任这些最新信息；可控性则确保了这些信息的安全性和合规性。三者缺一不可——仅有实时性而无控制，系统可能成为错误或有害信息的传播渠道；仅有可解释性而无实时性，回答可能因过时而误导用户；仅有可控性而无实时性，系统的价值将大打折扣。

正是这种三位一体的优势组合，使得 RAG 成为将大模型落地企业应用的主流技术选择。

1.4 RAG工程的技术全景图

了解了 RAG 的价值和原理之后，我们需要对 RAG 工程的全貌有一个系统的认识。RAG 不仅仅是一个算法概念，它是一个涉及多个技术组件的完整工程体系。

1.4.1 RAG系统的四大组件

一个完整的 RAG 系统可以分解为以下四个核心组件：

数据处理与知识库构建组件。这个组件负责将原始文档（PDF、Word、网页、数据库记录等）转换为可检索的知识单元。典型的处理流程包括：文档解析（提取文本内容）、文本分块（将长文档切分为适合检索的小片段）、向量化（将文本片段转换为向量表示）、索引构建（在向量数据库中建立高效的索引结构）。这一组件通常被称作Ingester（摄取器）或Indexing Pipeline（索引管道）。

检索与查询组件。这个组件负责接收用户查询、找到最相关的知识片段。核心功能包括：查询编码（将用户问题转换为向量）、相似度搜索（在向量数据库中找到最近的邻居）、重排序（对初步检索结果进行更精细的排序）、查询扩展（通过改写或分解来丰富查询表达）。这一组件是 RAG 系统质量的关键瓶颈。

上下文组装与提示工程组件。这个组件负责将检索结果转化为适合语言模型消费的格式。核心任务包括：上下文选择（决定向模型提供多少和哪些检索片段）、提示模板设计（如何组装检索结果与原始问题）、指令设计（如何指导模型基于给定上下文回答）。这一组件通常与提示工程（Prompt Engineering）密切相关。

生成与后处理组件。这个组件负责调用语言模型生成最终回答，并进行必要的后处理。功能包括：模型调用（与 LLM API 或本地模型交互）、输出解析（从模型响应中提取最终答案）、质量过滤（检查回答是否与上下文一致）、来源标注（在回答中添加引用信息）。这一组件直接影响用户体验和系统的可靠性。

1.4.2 RAG技术栈的层次结构

从技术实现的角度，RAG 系统涉及以下技术层次：

基础设施层：包括计算资源（GPU/TPU 用于推理）、存储资源（向量数据库、文件存储）、网络资源（API 网关、安全传输）。这一层是整个系统的物理基础。

数据层：包括原始文档存储、清洗后的文本库、向量索引、索引元数据。数据层的质量直接决定了检索效果的上限。

模型层：包括 embedding 模型（用于将文本转换为向量）、reranker 模型（用于对检索结果进行二次排序）、大语言模型（用于最终生成）。模型的选择和组合对系统性能影响巨大。

框架层：包括 RAG 框架（如 LangChain、LlamaIndex、Haystack）和 LLM 框架（如 vLLM、 Ollama）。框架提供了快速构建 RAG 系统的工具和抽象。

应用层：包括前端交互界面、API 服务、业务逻辑集成、监控与日志。应用层直接面向终端用户。

在本书的后续章节中，我们将逐一深入探讨每一层的关键技术、常见挑战和最佳实践。

1.4.3 RAG的工程挑战

尽管 RAG 的概念相对直观，但在实际工程落地中会面临一系列挑战：

数据质量挑战：garbage in, garbage out——如果知识库中充满错误、过时或噪声内容，检索效果再好也无法产生高质量回答。数据清洗、来源验证、版本管理成为关键能力。

检索质量挑战：找到“相关