初识RAG：大模型缺的不是智能，而是知识

第1章：初识RAG：大模型缺的不是智能，而是知识

1.1 聪明的"百科全书"：大模型的尴尬时刻

想象这样一个场景：你的老板突然问你："小王，把我们公司新推出的智能手表的核心卖点整理一下，下午开会要用。"你信心满满地打开ChatGPT，输入"我们公司的智能手表有什么优势"。然而，ChatGPT给出了一段关于智能手表的一般性介绍——提到长续航、健康监测、防水等功能，看起来头头是道，却唯独没有提到你们公司真正引以为傲的"独家睡眠分析算法"和"72小时续航"这两个核心卖点。

这还不是最尴尬的。更常见的情况是，你问ChatGPT："昨天苹果公司的股价是多少？"它会礼貌地告诉你："我的知识截止到2024年6月，无法提供实时股价信息。"

这就是大模型的"知识困境"。它们确实聪明——能写诗、讲量子物理、编写代码、做翻译——但它们的"知识"是固定的、被定格在某个时间点的训练数据里。就像一个记忆力超群的学生，把课本背得滚瓜烂熟，却不知道今天发生了什么事，更不知道你公司内部的机密资料。

让我们再深入一点。你有没有想过，当ChatGPT回答"量子力学的基本原理"时，它是怎么做到的？它并不是从某个数据库里查到了这个答案，然后给你展示。相反，它是在根据训练时学到的"语言模式"和"知识表示"，"生成"了一个看起来正确的回答。

这意味着什么？意味着它回答的质量取决于两件事：训练数据里有没有这些知识，以及训练数据里的知识是否准确。一旦你问的是训练数据里没有的东西——比如你公司的产品手册、你写的内部技术文档、你整理的客服话术——它就会开始"编造"或者直接说不知道。

这就是RAG（检索增强生成）技术要解决的核心问题：如何让大模型获取并准确使用它训练数据之外的知识？

1.2 什么是RAG：给大模型配一个"外脑"

RAG的英文全称是Retrieval-Augmented Generation，中文翻译是"检索增强生成"。听起来很技术化，但它的核心思想非常朴素：让大模型在回答问题之前，先去查一查相关的资料。

你可能觉得，这不是理所当然的吗？但在大模型出现之前，这是很难实现的技术。传统的信息检索系统（比如搜索引擎）只能返回一堆文档，需要你自己阅读理解；传统的大模型虽然能理解和生成，但知识受限。RAG把这两者结合起来：大模型不再只是"背答案"，而是学会"查资料后回答"。

还是用学生考试来类比。传统的大模型就像一个参加闭卷考试的学生——它只能依靠记忆中的知识作答。而RAG系统就像一个被允许翻书参加开卷考试的学生——遇到不确定的问题，可以翻开参考资料，找到相关信息后再给出答案。

关键的区别在于： 开卷考试的学生不是简单地把书上的内容抄一遍，而是理解了问题后，在参考资料中定位到相关信息，然后用自己的话组织出答案。这正是RAG的工作方式。

让我们更具体地看看RAG是如何工作的：

```mermaid graph LR A[用户提问] --> B[检索模块] B --> C[从知识库中获取相关文档] C --> D[将问题+相关文档组合成提示] D --> E[大语言模型生成答案] E --> F[返回最终回答] ```

这个流程图展示了RAG的基本工作流程。当用户提出问题时，系统首先会从知识库中检索出与问题相关的文档，然后将用户的原始问题与检索到的相关文档一起交给大模型。大模型根据这些"上下文信息"来生成答案，而不是仅凭自己的"记忆"。

你可能会问：为什么不直接把知识库里的内容告诉大模型？这就涉及到一个关键的技术细节——上下文长度限制。大模型每次能处理的文本长度是有限的（称为"context window"或"上下文窗口"），通常从几千到几十万token不等。如果知识库有100万条文档，你不可能一次性全部塞给大模型。RAG的精妙之处在于，它只把与当前问题最相关的少量文档检索出来，让大模型在有限的上下文中"看到"最需要的知识。

这就引出了RAG的第二个核心能力：精准检索。系统需要判断用户的问题在问什么，然后从海量知识中找出真正相关的那几条文档。这听起来简单，实际上涉及到复杂的语义理解技术——用户可能用各种方式表达同一个意思，系统需要理解语义而不是做简单的关键词匹配。

所以，RAG不仅仅是"给大模型一堆资料"，而是一个完整的系统工程：如何组织知识让检索更高效？如何让检索结果既相关又不冗余？如何把检索到的信息和原始问题组合成最佳的提示？ 后续章节我们会逐一深入探讨这些问题。

1.3 为什么需要RAG：知识受限不只是个例

你可能觉得，大模型的知识受限只是一个"小问题"——大不了让用户自己去搜索嘛。但实际上，这个问题的严重程度远超你的想象。

第一，私有知识是企业的核心资产。

每个企业都有大量"只存在于企业内部"的知识：产品手册、技术文档、内部流程、客户数据、客服记录、员工培训材料……这些东西从来不会出现在公开的互联网上，因此永远不会被大模型的训练数据覆盖。但恰恰是这些知识，才是企业最需要让AI来处理的。

想象一个客服场景。用户问："你们家打印机的墨盒型号是什么？原装和兼容的区别是什么？"通用大模型可能给你一个泛泛的回答，告诉你"墨盒是打印机的重要耗材"。但如果企业有完整的产品知识库，RAG系统可以检索到具体的型号对比表、兼容性说明、价格信息，然后给出精准的、针对该企业产品的回答。这就是"知识增强"的直接价值。

第二，知识的时效性是大模型的永恒痛点。

大模型的训练是一个耗时数月、花费数百万美元的过程。即使今天训练出一个完美的大模型，它的知识也会在下一秒开始"过时"。股市行情、天气预报、新闻事件、政策法规、学术研究进展——这些每时每刻都在变化的信息，大模型根本无法实时掌握。

一个极端的例子是：2024年，某知名大模型被问及"2024年美国总统大选结果"时，仍然给出"拜登已宣布退选"这样的过时回答。类似地，当企业推出新产品、更新定价策略、调整组织架构时，通用的AI助手无法及时响应这些变化。但有了RAG系统，企业可以随时更新知识库，让AI立即"知道"最新的信息。

第三，幻觉问题是企业应用的致命风险。

大模型有一个臭名昭著的特性——"幻觉"（hallucination）。它会自信满满地编造听起来正确但实际错误的信息。在开放域的闲聊中，这可能只是个小麻烦；但在企业应用场景中，一句错误的报价、一条失准的产品规格、一段编造的法规解读，都可能带来严重的业务损失和法律风险。

RAG为什么能缓解这个问题？因为RAG生成的每个答案都有"据可查"。系统检索出来的文档就是答案的依据，大模型在生成时会参考这些真实内容，而不是凭空编造。即使大模型"想"胡说八道，它也需要在检索到的文档基础上进行整合，客观上降低了胡说八道的可能性。

第四，微调不是万能解药。

有的读者可能知道，给大模型注入新知识的另一种方式是"微调"（Fine-tuning）——用特定领域的数据继续训练模型，让模型"记住"这些知识。那为什么不直接用微调呢？

这里有一个常见的认知误区：微调和RAG解决的是不同层面的问题。微调改变的是模型的"能力"——比如让它学会某种说话风格、某个领域的专有名词、某种推理模式。微调不是为模型"添加知识"的最优方式，原因有三：

1. 成本高昂：微调一次大模型需要大量GPU算力和时间，普通人根本无法承担。 2. 更新困难：微调后的模型知识是"固化"的，如果要更新知识，需要重新微调。 3. 容易遗忘：用新数据微调可能导致模型"遗忘"之前学到的知识。

相比之下，RAG的知识更新只需要更新知识库文档，无需重新训练模型。明天你的产品手册改了？直接把新文档上传到知识库，AI就能立刻回答新问题了。

下面这张表总结了RAG和微调的适用场景对比：

| 维度 | RAG | 微调 | |------|-----|------| | 知识更新 | 实时更新，只换文档 | 需要重新训练模型 | | 成本 | 相对较低 | 成本高昂 | | 可解释性 | 答案可追溯到源文档 | 知识融入模型权重，难追溯 | | 适用场景 | 知识密集型、需实时更新 | 能力塑造、风格迁移 | | 幻觉风险 | 较低，有外部知识约束 | 较高，仍可能编造 |

本书的核心主题就是RAG，我们会系统讲解如何从零搭建一个企业级RAG系统、如何优化检索和生成效果、如何评估和监控系统。但在此之前，你需要先理解RAG的完整架构，这就是下一节要介绍的内容。

1.4 RAG的三大核心模块：检索、生成、评估

一个完整的RAG系统通常由三个核心模块组成：检索模块（Retrieval）、生成模块（Generation）和评估模块（Evaluation）。理解这三个模块的作用和它们之间的配合，是掌握RAG技术的基础。

1.4.1 检索模块：找到正确的资料

检索模块是RAG系统的"大脑"——它负责理解用户的问题，并在海量知识中找出最相关的内容。这一步的质量直接决定了最终答案的质量：如果检索不到正确的内容，后面再怎么生成也是"巧妇难为无米之炊"。

检索模块的工作流程通常包括以下几个步骤：

第一步：文档处理（Document Processing）。原始的文档可能是PDF、Word、网页、数据库记录等各种格式。系统首先需要把这些文档"拆解"成可以被检索的基本单元。这个基本单元通常称为"chunk"（片段）。一个chunk可能是一段文字、一个问题-答案对、或者一张表格。chunk的大小选择很有讲究——太大则包含过多无关信息，太小则可能丢失上下文。

第二步：向量化（Embedding）。为了让计算机理解文本的"语义"，需要把文本转换成一种特殊的数值表示——向量。这个过程叫做"向量化"或"Embedding"。语义相似的文本会被映射到向量空间中相近的位置。例如，"如何更换打印机墨盒"和"墨盒替换步骤"这两个问题虽然用词不同，但会被映射到相似的向量。

主流的Embedding模型有很多选择，比如OpenAI的text-embedding-ada-002、微软的text-embedding-3-small、开源的BGE系列等。选择哪个模型取决于你的具体需求、预算和对性能的要求。本书后续章节会详细介绍如何选择和部署Embedding模型。

第三步：存储和索引（Storage and Indexing）。所有文档的向量会被存储到一个特殊的数据库中，称为"向量数据库"（Vector Database）。常见的向量数据库包括Milvus、Pinecone、Chroma、Weaviate等。这些数据库专门优化了向量检索的性能，能够在海量向量中快速找到与查询向量最相似的那些。

第四步：相似度检索（Similarity Search）。当用户提问时，系统先用同样的Embedding模型把问题转换成向量，然后在向量数据库中检索，找出与问题向量最相似的Top-K个文档chunk。

```mermaid graph TD A[原始文档] --> B[文档处理：分块] B --> C[向量化：Embedding] C --> D[向量数据库存储] D --> E[索引构建] E --> F[用户查询] F --> G[查询向量化] G --> H[相似度检索] H --> I[返回Top-K相关文档] ```

整个检索流程可以用上面这张图来总结。需要强调的是，检索模块不是简单的"匹配"——它需要理解用户的真实意图，处理同义词、多义词、模糊表达等复杂语言现象。比如用户问"你们家的墨水用完了怎么办"，系统需要知道这是在问"墨盒更换"或"耗材购买"相关的信息。

1.4.2 生成模块：整合信息，生成答案

检索模块找到了相关的文档片段，接下来就轮到生成模块登场了。生成模块的核心是大语言模型（LLM），但它的工作不仅仅是"回答问题"，而是要把检索到的信息和用户的问题整合起来，生成一个连贯、准确、有用的回答。

生成模块的关键步骤是Prompt工程（Prompt Engineering）。Prompt是你给大模型的"指令"，它决定了模型如何理解和回答问题。一个典型的RAG Prompt会包含以下几部分：

1. 任务说明：告诉模型它是一个问答助手，需要基于提供的参考资料来回答问题。 2. 用户问题：原始的用户提问。 3. 检索到的上下文：从知识库中检索到的相关文档片段。 4. 回答要求：比如"仅根据提供的上下文回答"、"如果上下文不足以回答，说明不知道"等。

一个简化版的RAG Prompt可能长这样：

``` 你是一个专业的客服助手。请根据以下参考资料回答用户的问题。 如果参考资聊中没有相关信息，请直接说明你不知道。

【参考资料】 {检索到的文档1} {检索到的文档2} ...

【用户问题】 {用户的问题}

【回答】 ```

大模型会根据这个Prompt，结合它自身的语言理解和生成能力，输出一段符合要求的回答。

生成模块的设计还需要考虑几个实际问题：

• **上下文窗口限制**：大模型每次能处理的token数量是有限的。如果检索到的文档太多或太长，可能会超出模型的上下文窗口。需要合理控制检索返回的文档数量和每个文档的长度。
• **多文档融合**：有时候多个检索结果都包含部分正确答案，模型需要综合这些信息，整理出一个完整的答案，而不是简单地拼接。
• **回答风格控制**：不同场景需要不同的回答风格——客服场景需要亲切耐心，技术文档场景需要严谨准确，营销场景需要吸引眼球。Prompt的设计需要体现这些差异。

1.4.3 评估模块：持续优化系统效果

你可能会想，RAG系统搭好了，检索到文档，模型生成了回答，是不是就完事了？没那么简单。

现实中的RAG系统往往存在各种问题：检索不到真正相关的文档、检索结果太多噪音、生成的回答不准确、回答没有用到检索到的信息……这些问题需要通过评估来发现，然后不断优化。

评估模块通常关注以下几个核心指标：

检索评估指标：

• **召回率（Recall）**：在所有相关的文档中，系统成功检索到多少？召回率低意味着系统"漏掉"了重要信息。
• **精确率（Precision）**：系统检索到的文档中，有多少是真正相关的？精确率低意味着返回了太多无关内容。
• **平均精度（MAP）**：综合考虑检索结果排序质量的指标。相关的文档排得越靠前，分数越高。

生成评估指标：

• **答案准确率**：生成的答案是否与事实一致？是否符合检索到的文档内容？
• **答案相关性**：生成的答案是否切题？是否真正回答了用户的问题？
• **答案完整性**：回答是否全面？是否遗漏了重要的信息点？

评估一个RAG系统通常有两种方式：人工评估和自动评估。

人工评估是让标注人员查看系统的回答，打分或给出反馈。这种方式最准确，但成本高、速度慢。

自动评估是设计一些自动化的指标或测试用例来评估系统。常见的做法是构建一个"标准问题-答案"测试集，然后对比系统回答与标准答案的匹配程度。近年来，基于大模型的自动化评估（让另一个AI来判断回答质量）也越来越流行。

实际开发中，建议采用混合策略：在开发迭代阶段以自动评估为主，快速发现问题；在产品发布前进行人工评估，确保质量底线；在生产环境中持续收集用户反馈，识别系统弱点。

1.5 你的第一个RAG Demo：让AI读懂你的文档

理论讲够了，让我们来点实际的。这一节，我将带你搭建一个最简单的RAG系统demo。这个demo将包含最核心的组件，代码简洁明了，足以让你亲眼看到"知识库加持"后大模型发生了什么变化。

我们使用Python来编写这个demo，主要依赖以下工具：

• **LangChain**：一个流行的RAG开发框架，封装了大量RAG相关组件。
• **Chroma**：轻量级的向量数据库，适合本地开发和测试。
• **OpenAI API**：提供Embedding和GPT模型（也可以换成其他大模型API）。

首先，确保你的环境中安装了必要的Python包：

```python pip install langchain langchain-openai chromadb tiktoken ```

接下来的代码分为四个部分：

第一步：准备知识库

我们先准备一段"企业知识"。这里用一段关于公司打印机的产品介绍作为示例。实际应用中，你可以换成任何文本文档。

```python from langchain.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter

示例知识库内容

knowledge_base = """

智远科技ZP-5000彩色激光打印机

产品规格

• 打印速度：黑白35页/分钟，彩色30页/分钟
• 分辨率：1200x1200dpi
• 纸盒容量：250页标准纸盒 + 100页多功能纸盒
• 网络：支持有线网络、WiFi、蓝牙

耗材信息

• 黑色墨粉盒型号：ZT-C5000K，容量5000页，参考价格399元
• 彩色墨粉盒型号（青/黄/品红）：ZT-C5000C/Y/M，容量4000页，参考价格299元/个
• 硒鼓型号：ZT-D5000，使用寿命约10万页，参考价格899元

常见问题

Q: 打印出来颜色偏淡怎么办？

A: 1) 检查墨粉盒余量，必要时更换；2) 在驱动程序中调整浓度设置；3) 清洁激光扫描单元；4) 如果问题持续，可能是硒鼓老化，需要更换。

Q: 卡纸了怎么处理？

A: 1) 关闭电源，轻轻打开后盖；2) 沿纸张走向缓慢抽出卡纸，避免撕裂；3) 检查纸张是否平整、干燥；4) 确认纸张规格符合要求（70-105g/m²）；5) 重新放入纸张后合上所有盖板。

Q: 如何连接无线网络？

A: 1) 在打印机面板进入"设置 > 网络 > WiFi"；2) 选择您的网络名称；3) 输入WiFi密码；4) 连接成功后，面板会显示网络图标。 """

将知识库保存为临时文件

with open("knowledge_base.txt", "w", encoding="utf-8") as f: f.write(knowledge_base) ```

第二步：文档分块和向量化

接下来，我们把文档分割成小块，转换成向量，存入向量数据库。

```python from langchain_openai import OpenAIEmbeddings from langchain_community.vecto