RAG入门：让大模型「看见」你的知识

RAG入门：让大模型「看见」你的知识

当你向ChatGPT询问“公司去年第四季度的营收情况”时，它给出了一个看起来非常专业、逻辑严密的回答——然后你发现，这些数字完全是它自己编造的。这就是大模型最令人头疼的问题：一本正经地胡说八道。

这不是ChatGPT独有的缺陷，而是所有大语言模型（Large Language Model, LLM）的通病。GPT-4、Claude、Llama、文心一言、通义千问，无论参数规模有多大、训练数据有多丰富，只要它们是基于纯文本训练的神经网络，就天然存在产生“幻觉”（Hallucination）的倾向。

这个问题在企业级应用中尤为致命。当员工需要基于公司内部文档回答业务问题时，我们不能让AI信口开河。当律师需要引用法律条文时，错误的引用可能导致严重的法律后果。当医生参考医学文献时，编造的数据可能危及患者生命。

检索增强生成（Retrieval-Augmented Generation, RAG）正是为了解决这一问题而生的技术框架。它不是要训练一个全新的模型，而是为大模型配备一个“外脑”——一个可以实时查询、确保答案基于真实文档的知识库。当用户提问时，RAG系统首先从知识库中检索相关文档，再将这些文档作为上下文交给大模型，最终生成的回答就有了事实依据，不再是空中楼阁。

本章将从大模型的幻觉问题出发，深入剖析为什么LLM会胡说八道，进而介绍RAG的核心思想和三步工作流程，对比RAG与模型微调的适用场景，最后带你搭建一个最简单的RAG演示系统。通过本章的学习，你将理解RAG的基本原理，能够判断一个业务场景是否适合引入RAG，并为后续深入学习打下坚实基础。

---

1.1 大模型的幻觉问题：一个无法回避的现实

1.1.1 什么是幻觉？

在AI领域，“幻觉”这个术语可能让普通读者感到困惑。我们日常语境中的幻觉通常与感官欺骗有关，但在机器学习的语境下，大模型幻觉指的是模型生成的内容与客观事实不符，或者与用户输入的上下文毫无关联，却表现得像是在陈述可靠事实。

举个具体的例子。当你问GPT-4：“特斯拉Model S的续航里程是多少？”时，它可能会回答：“根据EPA标准，特斯拉Model S的续航里程为405英里。”这个答案看起来非常专业，还带上了具体的认证机构。但问题在于，这个数字可能是不准确的——EPA实际测试的结果可能是375英里，或者405英里这个数字在某个时间点是正确的，但现在已经被更新了。大模型无法告诉你这个数字是否是最新的，也无法保证它的可信度。

更严重的幻觉发生在模型完全“编造”内容的时候。比如当你问：“张三在2023年发表的关于量子计算的论文主要观点是什么？”模型可能自信满满地给出一段详细的论文摘要、作者信息、发表期刊，而你完全无法判断这篇论文是否真实存在——事实上，模型很可能是根据它的语言模式“生成”了这篇并不存在的论文。

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

要理解幻觉产生的原因，我们需要稍微了解一下大模型的工作原理。大语言模型本质上是一个基于统计规律的文本预测机器。在训练阶段，模型学习了海量文本中词语之间的关联模式——什么样的词更可能出现在什么样的上下文之后。当我们给模型一个输入时，它会基于这些学习到的模式，预测下一个词应该是什么，然后逐词生成回复。

这个过程有三个关键问题：

第一，训练数据的时效性。 大模型的训练需要消耗大量计算资源，训练一次可能需要数周甚至数月。这意味着模型的知识是有“截止日期”的——GPT-4的知识截止到2023年4月，Claude的知识截止到2023年8月，等等。当用户询问截止日期之后发生的事件时，模型只能靠“合理推断”而不是确切知识来回答。在快速变化的商业环境中，这个限制几乎是致命的——公司的产品手册在更新，竞争对手在发布新品，行业法规在调整，但模型对此一无所知。

第二，模型不知道自己不知道什么。 这是更根本的问题。大模型没有“元认知”能力——它无法判断自己的回答是否正确，无法说“我不知道”，也无法区分自己确信的内容和随意编造的内容。当模型遇到训练数据中很少出现的问题时，它会倾向于生成听起来合理但实际错误的答案，因为它的语言模型已经学会了如何让任何陈述听起来都很专业、很可信。

第三，知识与能力的边界模糊。 大模型的知识不是以结构化形式存储的——我们不能像查询数据库一样精确地“提取”某个事实。模型的“知识”实际上是分布在数以万亿计的参数中的模式。这种分布式存储方式使得模型能够灵活地组合和泛化，但同时也意味着它无法提供可验证的事实性保证。

1.1.3 幻觉问题的实际影响

在消费级应用中，幻觉可能只是带来一些不便。但在企业级场景中，幻觉的代价可能是灾难性的。

想象一下这样的场景：一家制药公司的研发团队使用AI助手来检索文献，AI“引用”了一篇不存在的临床试验报告，团队据此做出了研发方向决策，半年后才发现那篇文献是编造的。这样的错误浪费的不只是时间和资金，更可能错过市场窗口期。

在法律行业，律师使用AI准备诉讼材料，AI“引用”了不存在的判例法，律师在法庭上援引时被对方律师当场指出，这不仅是专业上的耻辱，更可能影响案件结果。

在金融行业，客户询问某只基金的费率结构，AI给出了一个过时的数据，客户据此做出投资决策后发现实际费率完全不同——这可能引发合规问题和客户投诉。

这些场景有一个共同特点：答案需要有据可查。不是“听起来正确”就可以，而是必须基于真实存在的文档、条款、数据。大模型的“概率性生成”机制无法满足这种需求，我们需要一种新的架构来确保AI的回答有真实来源。

---

1.2 RAG的核心思想：让模型“看见”真实文档

1.2.1 从“记忆型”到“检索型”

人类在回答问题时有两种主要模式。一种是直接调用记忆中的知识——当你问“我最好的朋友叫什么名字”时，我可以直接从记忆中提取答案。另一种是检索外部信息——当被问及“《中华人民共和国公司法》第三十二条的具体内容”时，即使你是法律专业人士，也很可能需要查阅原文来给出准确答案。

大模型的“幻觉”问题部分源于它试图用第一种模式（记忆型）处理所有问题。它把海量的训练数据压缩进模型参数中，然后在回答任何问题时都试图从这个“压缩包”里“解压”出答案。但这种压缩是有损的——细节丢失了，知识过时了，不同来源的信息可能互相冲突。

RAG的核心思想很简单：对于需要事实准确性的问题，切换到“检索型”回答模式。不是让模型自己“记住”所有知识，而是在回答时实时从可信的知识库中检索相关文档，让模型基于这些真实文档来组织回答。

这就好比一个人类专家——一位经验丰富的律师并不需要背诵所有法律条文，他知道在哪里可以找到需要的信息。当被问到具体法条时，他会查阅法典；当需要引用判例时，他会检索案例数据库。RAG正是为大模型赋予这种“查阅能力”的技术框架。

1.2.2 RAG的工作原理：一个比喻

让我们用一个生活化的比喻来理解RAG。假设你是一家大型律师事务所的新员工，老板让你回答客户关于某项商业合同的法律问题。

没有RAG的情况相当于你完全依靠自己培训时学到的知识来回答。你可能记得合同法的一些基本原则，但具体的条文编号、过时的规定、法院的最新解释，你都无法确定。你的回答可能听起来很专业，但很可能是片面的、过时的，甚至是自己“编造”的。

有RAG的情况相当于你手边有一台可以联网的电脑。当你接到问题时，你首先打开法律数据库，检索相关的法条和判例，找到最相关的几份文件，仔细阅读后，用自己的语言向客户解释。你的回答不是“凭记忆”，而是“基于这份刚刚查阅的文件”。如果数据库中没有相关信息，你可以诚实地说“这个问题涉及的知识超出了我目前查阅的范围”。

RAG系统的工作流程与此完全一致：用户提问 → 系统检索相关文档 → 将文档作为上下文 → 大模型基于上下文生成回答。回答的每一条陈述都可以追溯到具体的源文档，而不是模型的“记忆”。

1.2.3 RAG相比纯LLM的优势

为什么RAG能够有效解决幻觉问题？我们来分析它的核心优势：

事实锚定（Grounding）。 RAG生成的每个答案都基于检索到的文档，这提供了可验证的事实基础。如果用户质疑答案的准确性，可以直接查阅源文档进行核实。这种“可追溯性”是企业应用的基础需求。

知识时效性。 当企业更新了产品文档、发布了新政策、调整了组织架构时，只需要更新知识库中的文档，RAG系统立即能够基于最新信息回答问题。不需要重新训练模型，也不需要等待模型的知识更新周期。

领域适配性。 每家企业都有自己独特的知识库——内部流程、产品规格、历史决策记录。这些信息不可能出现在通用大模型的训练数据中（因为是私有的），也不可能通过公开数据训练获得。RAG允许企业将自己的知识库接入AI系统，实现真正的“懂你的业务”。

可解释性。 RAG系统可以展示它基于哪些文档生成了答案，这种可解释性对于需要审计和合规的场景至关重要。用户可以判断引用的文档是否权威、是否相关、是否有时效性问题。

成本可控性。 训练一个大模型需要数百万美元，而RAG可以在现有开源模型的基础上构建，成本主要是知识库的构建和维护。对于很多中小型企业来说，这是更现实的选择。

---

1.3 RAG三步流程：检索、增强、生成

1.3.1 整体架构概览

RAG的全称是“检索增强生成”（Retrieval-Augmented Generation），这三个词恰好对应了它的三个核心步骤：

```mermaid graph TD A[用户提问] --> B[检索 Retrieval] B --> C[增强 Augmentation] C --> D[生成 Generation] D --> E[返回回答]

B --> F[向量数据库] F --> G[相关文档]

G --> C ```

让我们详细拆解每一步。

1.3.2 第一步：检索（Retrieval）

检索是RAG流程的起点。当用户输入一个问题时，系统需要在知识库中找到与该问题最相关的文档。

这个过程看似简单，实际上涉及多个技术环节。首先是向量化（Embedding）——将文本转换为数学向量。在这一步，文本被送入一个预训练的嵌入模型（如OpenAI的text-embedding-ada-002，或者开源的sentence-transformers），输出是一个高维向量，可以理解为文本的“语义指纹”。语义上相近的文本，其向量在向量空间中的距离也相近。

然后是相似度搜索。用户的问题同样会被向量化，然后在向量数据库中搜索与之距离最近的N个文档。向量数据库是专门为这种高维向量检索优化的系统，常见的选择包括Milvus、Pinecone、Weaviate、Chroma等。

举个例子，当用户问“公司年假政策是如何规定的？”时，系统会：

1. 将这个问题转换为向量 2. 在向量数据库中搜索语义最相似的文档 3. 返回可能是《员工手册》中关于年假政策的章节、《HR政策文档》、甚至是某封关于年假调整的公司邮件

检索的质量直接影响最终答案的质量。 如果检索不到相关文档，系统就无法提供有依据的回答；如果检索到的文档不相关，生成的回答也会跑偏。优化检索环节是RAG系统开发中最重要的工作之一。

1.3.3 第二步：增强（Augmentation）

增强阶段将检索到的文档与用户原始问题整合，形成一个结构化的“提示”（Prompt）。

这个过程不是简单地把文档拼接在问题后面。一个精心设计的增强策略会考虑：

上下文窗口限制。 大模型的输入有长度限制（通常是4K到128K tokens不等）。当检索到多篇长文档时，可能需要截断、压缩或重新组织内容，以确保最重要的信息能够进入上下文。

信息优先级。 如果多篇文档提供了相似的信息，保留最相关、最权威、最新的版本。如果文档之间存在矛盾（这种情况在现实中很常见），可能需要在提示中特别标注，或者选择只使用最权威的来源。

元信息注入。 除了文档正文，增强信息通常还包括文档的来源、日期、相关性评分等元数据。这些信息帮助大模型判断如何使用这些文档。

一个典型的增强后提示可能长这样：

``` 用户问题：2023年公司发布的最新年假政策是什么？ --- 【文档1】来源：员工手册2023版，日期：2023-01-15 根据2023年1月修订的《员工手册》第四章第七条：

• 工作满1年不满10年的员工，年休假5天
• 工作满10年不满20年的员工，年休假10天
• 工作满20年的员工，年休假15天

--- 【文档2】来源：HR部门通知，日期：2023-03-01 补充说明：考虑到公司业务特点，研发部门员工额外享有2天弹性年假。 相关性评分：0.92

请基于以上文档回答用户问题。如果文档中没有涵盖的信息，请明确指出。 ```

1.3.4 第三步：生成（Generation）

生成阶段是大模型发挥的时刻。它接收增强后的提示，基于其中的文档内容生成最终回答。

这一步的核心挑战是忠实于检索结果。大模型有时会“过度发挥”——即使提供了文档，它也可能忽略文档内容，凭自己的“记忆”生成答案。解决这一问题的方法包括：

提示工程（Prompt Engineering）。 在提示中明确要求模型“仅基于提供的文档回答”、“如果文档中没有相关信息，请明确说明”、“不要编造文档中不存在的内容”。

后处理验证。 对模型生成的回答进行自动检查，识别其中可能超出检索文档范围的陈述，并提示用户注意。

特定任务微调。 针对“基于文档问答”这一特定任务对模型进行微调，增强其忠实于上下文的倾向。

最终，用户收到的回答不仅是流畅的、专业的，而且每一条陈述都能追溯到具体的源文档。幻觉问题在很大程度上得到了解决。

---

1.4 RAG vs. Fine-tuning：何时选择哪种方案

1.4.1 两条不同的技术路线

当企业想要让大模型“懂自己的业务”时，通常面临两条技术路线的选择：

RAG（检索增强生成） 是在推理阶段接入外部知识库，模型本身保持不变。我们可以把这种方式理解为给模型配备了一个“外脑”——模型负责理解和生成，知识库负责提供事实依据。

Fine-tuning（微调） 是通过在特定数据集上继续训练，调整模型的内部参数，使模型“记住”特定领域的知识。这种方式可以理解为给模型安装了“内置软件”——知识被编码进模型的权重中。

两种方案各有优劣，选择取决于具体的应用场景和技术约束。

1.4.2 对比分析

让我们从多个维度对比这两种方案：

| 维度 | RAG | Fine-tuning | |------|-----|-------------| | 知识更新 | 实时更新，无需重新训练 | 需要重新训练，更新周期长 | | 知识来源 | 结构化/非结构化文档 | 训练数据集 | | 可解释性 | 高，可追溯到具体文档 | 低，知识编码在参数中 | | 幻觉控制 | 强，基于真实文档生成 | 弱，模型仍可能编造 | | 计算成本 | 推理时额外检索开销 | 训练成本高，推理成本不变 | | 数据需求 | 文档集合即可 | 需要大量标注数据 | | 适用场景 | 知识密集型、事实准确性要求高 | 任务特定、风格/格式适配 |

1.4.3 何时选择RAG

RAG特别适合以下场景：

知识库频繁更新的场景。 例如新闻网站需要AI助手回答关于最新报道的问题，电商平台需要AI回答关于当前在售商品的问题。这些场景下知识的时效性至关重要，RAG的知识库可以实时更新，而微调模型需要数周甚至数月的训练周期，无法跟上变化节奏。

事实准确性要求高的场景。 如法律咨询、医疗问诊、金融分析等，错误的回答可能造成严重后果。RAG的每一条回答都可以追溯到源文档，便于核实和审计。

需要可解释性的场景。 企业需要知道AI的回答依据是什么，特别是在需要人工审核或监管合规的情况下。RAG可以直接展示源文档，而微调模型无法提供这种透明度。

私有知识场景。 每家企业都有内部知识——流程文档、内部政策、历史决策记录等。这些知识不可能出现在公开训练数据中，但可以通过RAG轻松接入。微调需要大量计算资源，且不一定能有效“灌输”这些私有知识。

1.4.4 何时选择Fine-tuning

Fine-tuning在以下场景更有优势：

需要学习特定任务模式的场景。 例如，让模型用特定的语气回复客户（正式/亲切/幽默），或者按照特定的格式输出结果（如JSON、XML）。这种“风格适配”很难通过检索来实现，但可以通过微调让模型“学会”。

推理延迟要求极低的场景。 RAG需要在推理时进行向量检索，这增加了延迟（虽然通常只有几十毫秒）。在某些对延迟极度敏感的高并发场景，微调模型可能更合适。

交互模式相对固定的场景。 如果应用场景相对封闭，任务类型比较单一（例如专门用于情感分析的模型），微调可以提供更好的专用性能。

1.4.5 两者结合：RAG + Fine-tuning

在实践中，RAG和Fine-tuning并非互斥，而是可以结合使用。

一个常见的做法是先用RAG确保知识的准确性和时效性，再用Fine-tuning优化模型的交互风格和任务适配。例如，一个法律AI助手可以：

• 用RAG接入最新的法律法规数据库，确保引用的法条准确
• 用Fine-tuning让模型学会法律专业人士的表达方式和论证逻辑

这种组合方案能够兼顾准确性和用户体验，是目前企业级RAG应用的常见选择。本书的后续章节将详细讨论这种混合架构的设计与实现。

---

1.5 RAG系统的核心评价指标

1.5.1 为什么需要评价指标

在开发RAG系统时，我们很快会面临一个关键问题：如何知道系统表现得好不好？

不同于传统的软件系统，RAG系统的输出是自然语言，难以用简单的对错来评判。一个RAG系统可能返回了一个流畅、专业的回答，但用户发现其中某个细节与事实不符；另一个系统可能返回了一个略显生硬但完全准确的回答。我们需要一套系统的评价体系来衡量RAG系统的性能。

1.5.2 检索质量指标

RAG系统的第一步是检索，检索质量直接影响最终效果。

召回率（Recall） 衡量系统能够检索到多少相关文档。假设知识库中有10篇与问题相关的文档，系统检索到了其中7篇，召回率就是70%。召回率过低意味着重要的信息被遗漏了，系统无法提供完整的答案。

精确率（Precision） 衡量系统检索到的文档中有多少是真正相关的。假设系统检索了10篇文档，但其中只有5篇