RAG是什么？——给大模型配个'外置大脑'

第 1 章：RAG 是什么？——给大模型配个"外置大脑"

1.1 一个让人头大的问题：为什么 ChatGPT 会"一本正经地胡说八道"？

想象一下这个场景：你正在赶一篇关于"黑洞"的物理作业，兴奋地打开 ChatGPT，问它："霍金在 2015 年关于黑洞信息悖论提出了什么新观点？"

ChatGPT 思考了几秒钟，给你输出一大段关于霍金辐射、事件视界、量子引力的内容。看起来很专业，对吧？

但如果你去查证，会发现 ChatGPT 可能把 2012 年的 BBC 采访内容和 2018 年的某次会议混在一起，甚至杜撰了一个根本不存在的论文标题。它看起来很自信，语气很"权威"，但内容是错的。

这种现象在 AI 圈有个专门的名字——幻觉（Hallucination）。它是当下所有大语言模型（Large Language Model，简称 LLM）的"通病"。

为什么会这样？核心原因只有一个：大模型的所有"知识"，都来自于它的训练数据。

就像一个学生，只被允许读一本教材，然后就要去参加一场无限范围的考试。当问题超出教材范围时，他只能瞎猜——但因为已经"读"过很多内容，他的"瞎猜"听起来非常像模像样。这就是大模型产生"幻觉"的本质。

更进一步说，主流大模型（比如 GPT-4、Claude、Llama、文心一言等）的训练数据都有一个截止日期（cutoff date）。比如某个模型的知识截止到 2024 年 4 月，那么在 2024 年 5 月发生的事情，它就一无所知。

还有更糟糕的情况：很多知识是私有的——公司内部的产品手册、未公开的研究报告、个人的笔记……这些数据根本不可能出现在公开的训练集里。

所以问题来了：

> 有没有一种方法，能让大模型在回答问题时，"临时"去查资料，就像一个学生可以"开卷考试"一样？

有。这就是我们要聊的主角——RAG。

1.2 RAG 拆开看：三个字母背后的工程哲学

RAG 是 Retrieval-Augmented Generation 的缩写，中文翻译过来是检索增强生成。

我们把三个单词一个一个拆开看：

R：Retrieval（检索）

检索这个词你在图书馆用过——你走进图书馆，要找一本关于"量子力学入门"的书，图书管理员会根据你的需求，从成千上万本书里挑出最相关的那几本交给你。

在 RAG 里，"图书馆"是外部知识库（External Knowledge Base），可以是一堆文档、一组网页、一个数据库，甚至是公司内部的 Confluence 页面。"图书管理员"是一个搜索引擎（更专业一点说，是一个向量检索系统）。当你提问时，这个系统会从海量资料中，找出与你问题最相关的内容片段。

举个例子：你问"我们公司的年假是几天？"

• 没有 RAG 时：大模型只能瞎猜（因为公司政策不在它的训练数据里）
• 有 RAG 时：系统会先从你公司的《员工手册》文档里，找出关于"年假"那一段

这一步的核心任务是"找资料"。用什么找？从哪里找？怎么衡量"相关"？这些问题我们后面章节会展开讨论。

A：Augmented（增强）

Augmented 这个词的意思是"增强、扩充"。它指的不是别的，正是把检索到的"参考资料"，塞进给大模型的提示词（Prompt）里。

你可以理解为：大模型本来要"裸考"，现在有人递给它一张"小抄"（cheat sheet），上面写着可能相关的资料片段。

举个例子，提示词可能是这样的：

```text 你是公司问答助手。请基于以下参考资料回答用户问题。 如果参考资料里没有答案，就老实说"不知道"，不要瞎编。

【参考资料】 关于年假的规定如下：入职满1年的员工，每年享有10天带薪年假……

【用户问题】 我们公司的年假是几天？

【你的回答】 ```

看到了吗？这就是"增强"——原本只有用户问题，现在多了一段参考资料。

这一步看起来简单，但它背后藏着不少工程细节：参考资料放多长合适？放几条合适？是放在问题前面还是后面？要不要标注来源？这些都会影响最终答案的质量。

G：Generation（生成）

最后一步，大模型根据"用户问题 + 检索到的资料"，生成最终的回答。这一步和传统的 LLM 对话几乎一样，只不过输入里多了参考资料。

大模型真正发挥作用的，是它的语言组织能力——它能把零散的资料整理成一段通顺、得体的回答。这恰恰是 LLM 最擅长的事情。

所以，RAG 的完整定义是：

> RAG = 先检索（Retrieval）相关资料，再把资料增强（Augmented）到提示词中，最后由大模型生成（Generation）答案的一种技术框架。

整个过程可以浓缩成一句话：

> 让大模型"开卷考试"，而不是"闭卷瞎蒙"。

三个字母的深层逻辑

注意，这三个字母不是随机拼凑的，它体现了一种分而治之（Divide and Conquer）的工程哲学：

| 字母 | 任务 | 谁来做 | 类比 | |------|------|--------|------| | R - Retrieval | 信息检索 | 搜索引擎 / 向量数据库 | 图书管理员 | | A - Augmented | 信息整合 | Prompt 工程 | 把书递给考生 | | G - Generation | 语言生成 | 大语言模型 | 考生作答 |

为什么这个分工很聪明？ 因为每一种工具都用在了它最擅长的地方：

• 检索系统擅长"找得快、找得准"
• 大模型擅长"读懂问题、组织语言"

把它们组合起来，比让一个工具干所有事情，效果要好得多。这就像一支足球队：前锋负责进攻，后卫负责防守，门将负责扑救——每个位置各司其职，整体战斗力才强。

1.3 开卷考试 vs 闭卷考试：RAG 如何解决"幻觉"问题

为了让你更直观地理解 RAG 的价值，我们来做一个详细的对比。

场景设定

假设你正在做一道题："请解释爱因斯坦在 1905 年提出的光电效应理论。"

闭卷考试模式（传统 LLM）

大模型的"内心独白"是这样的：

1. 用户问了一个 1905 年的物理学问题 2. 我在训练数据里见过"光电效应"这个关键词 3. 我记得一些相关概念：爱因斯坦、光子、能量、波粒二象性 4. 我把这些概念拼起来，组织成一段通顺的话 5. 输出

问题出在哪？大模型其实并不"知道"光电效应的具体内容，它只是根据语言规律，预测"光电效应"后面最可能出现的文字。

如果它运气好，训练数据里有大量关于光电效应的准确描述，那么输出也会相对准确。 如果它运气不好，训练数据里关于光电效应的描述有错、或者描述不充分，那么输出就会出现"幻觉"。

更糟糕的是，大模型不知道自己不知道。它会像模像样地用"爱因斯坦提出……"、"实验表明……"这样的句式，给出一个听起来很权威、但实际上是编造的回答。

这种"自信地胡说"的现象，是大模型在工程应用中最大的隐患之一——尤其是在医疗、法律、金融这些容错率极低的领域。

开卷考试模式（RAG）

现在，加上 RAG 之后，流程变成：

1. 用户提问："光电效应" 2. 检索系统从知识库（可能是维基百科、教科书、论文）中找出最相关的段落 3. 系统把段落塞进提示词："请基于以下内容回答问题：……（找到的段落）……" 4. 大模型读到这些真实资料，然后生成答案 5. 输出

这种情况下，大模型的"幻觉"会大幅降低，因为它有了外部事实依据。即使大模型想"胡编"，也要看提示词里的资料是否支持它胡编。

打个比方：传统 LLM 像一个自圆其说的骗子，无论问什么都能给你编一个听起来合理的答案；RAG 模式下的 LLM 像一个有据可查的助理，它的回答必须基于提供的资料。

用一张图看清楚区别

```mermaid flowchart LR subgraph ClosedBook["传统 LLM：闭卷考试"] A1[用户问题] --> B1[大模型<br>闭卷答题] B1 --> C1[可能胡编] end

subgraph OpenBook["RAG：开卷考试"] A2[用户问题] --> B2[检索系统<br>翻书找资料] B2 --> D2[相关资料] D2 --> E2[大模型<br>结合资料答题] A2 --> E2 E2 --> F2[基于事实的答案] end ```

RAG 带来的三大好处

第一，减少幻觉。 答案有据可查，不是凭空编造。即使资料不全，大模型也会更倾向于说"我不知道"，而不是硬编一个。

第二，知识可更新。 你想让大模型了解 2024 年 5 月发生的事？只需要把相关资料加进知识库，不用重新训练模型。这对于新闻、法律、电商这些"日新月异"的领域特别重要。

第三，保护隐私和专有数据。 公司可以把内部文档作为知识库，大模型本身不需要"知道"这些内容，只需要会"读资料"。这意味着你可以用通用大模型 + 公司私有数据，而不用担心数据泄露给大模型厂商。

当然，RAG 也不是万能的。它有自己的问题（比如检索不准、答案可能不完整、参考资料可能带偏见），我们后续章节会详细讨论。但作为入门理解，RAG 的核心价值就是：让大模型从"凭记忆回答"升级为"翻资料回答"。

1.4 RAG vs Fine-tuning vs Long Context：三种"补课"方式的较量

当你遇到"大模型不懂某个领域的知识"这个问题时，工程上有三种主流解决方案：RAG（检索增强生成）、Fine-tuning（微调）、Long Context（长上下文）。

它们都能让大模型"补课"，但补课的方式完全不同。

三种方式的对比表

| 维度 | RAG | Fine-tuning | Long Context | |------|-----|-------------|--------------| | 核心思路 | 考试时翻书 | 把书背下来 | 直接把书放在桌上 | | 类比 | 开卷考试 | 提前背诵全文 | 把所有资料贴在考卷旁边 | | 知识时效性 | 实时更新（加新文档就行） | 训练完后固定（需要重新训练） | 每次都要重新输入 | | 成本 | 低（建索引） | 高（需要 GPU 训练） | 中（每次推理成本高） | | 适合场景 | 知识库问答、客服助手 | 风格转换、专业术语适配 | 单次超长文档分析 | | 幻觉率 | 较低（除非检索出错） | 仍可能存在 | 较低，但内容过多时也会"走神" | | 回答的可解释性 | 高（可告诉用户"答案来自哪份文档"） | 低 | 中 |

详细解释一下每种方式

Fine-tuning（微调）

微调就像让大模型去"培训班"——你用特定领域的数据集，继续训练它。比如，你有一万条医疗问答数据，就用这些数据"调教"模型，让它学会用医学术语回答问题。

微调的优势是：模型可以学到深层的领域知识和风格。比如你希望模型用"亲切的客服小姐姐"语气回答问题，微调是最直接的方式。

微调的劣势是：

• 成本高（需要 GPU，需要时间，需要电力）
• 知识固化（训练完后，想加新知识必须重新训练）
• 数据需求大（几千几万条起步）
• 容易"灾难性遗忘"（学了新东西，忘了旧东西）

Long Context（长上下文）

2023 年以来，主流大模型的上下文窗口（Context Window）越来越大，从最初的 4K tokens，扩展到 32K、128K，甚至 200 万 tokens（注意 tokens 不是字符，1 个 token 大约对应 1.5 个英文单词或 1 个汉字）。

长上下文的意思是：你可以一次性把一本几十万字的书塞给大模型，让它"读完整本书"再回答问题。

这种方式的优势是：实现简单，不用额外的检索系统。 劣势是：

• **成本爆炸**——200 万 tokens 的输入，每次推理都要花很多钱（API 调用是按 token 收费的）
• **"迷失中间"问题**——研究表明，大模型对位于中间位置的内容理解能力较弱（开头和结尾的内容记得最清楚）。就像一个人读一本超厚的书，往往对开头和结尾的章节印象最深，中间的细节容易"略过"
• **不能跨文档**——如果你有 1 万份文档，没办法都塞进上下文
• **响应速度慢**——输入越长，处理时间越长

RAG（检索增强）

RAG 的思路介于两者之间：它不要求模型记住所有知识，也不要求把所有资料都塞进去，而是按需检索——用的时候才去找相关的那部分。

这也是为什么 RAG 在企业应用中特别受欢迎：成本可控、知识可更新、答案有据可查。

一个生动的比喻

把这三种方式想象成三种学生：

• **Fine-tuning** 像是一个**死记硬背型的学霸**：他把整本字典背下来了，考试时不需要翻书，但缺点是新词出现后他不会。
• **Long Context** 像是一个**桌上堆满参考书的考生**：考试时旁边放着 100 本书，他可以随时翻阅，但缺点是 100 本书很难快速翻到他想要的那一页。
• **RAG** 像是一个**会使用索引卡的好学生**：他自己不背书，但有一张精准的索引卡，能告诉他"这道题的答案在第 3 本书的第 87 页"。

RAG 的精髓在于：把"记忆"和"理解"这两件事分开。

大模型负责"理解"和"表达"，检索系统负责"记忆"。专业的事交给专业的工具。

实际工程中如何选择？

一般而言：

• 如果你的需求是**让模型用某种特定风格说话**（比如客服语气、医生诊断风格），首选 **Fine-tuning**
• 如果你的需求是**分析一份很长的文档**（比如让它读一份 100 页的报告然后写摘要），用 **Long Context**
• 如果你的需求是**让模型基于一个不断更新的知识库回答问题**（比如公司客服、法律咨询），用 **RAG**

当然，最强的方案往往是组合拳：用 RAG 提供事实依据，用 Fine-tuning 调整回答风格，用 Long Context 处理超长文档的边角情况。

1.5 一个真实故事：某公司问答机器人的"翻车与救赎"

光讲理论太抽象，我们来看一个真实场景（基于常见案例改编）。

场景背景

假设你加入了一家叫做 AcmeAI 的创业公司。公司有一个内部问答机器人"小 A"，员工可以问它：

• "年假怎么请？"
• "报销流程是什么？"
• "VPN 怎么连？"
• "附近哪家外卖好吃？"（老板强烈要求删掉这个问题，但机器人总是答得很起劲）

最初，公司直接用 GPT-4 的 API，加上 system prompt："你是 AcmeAI 的 HR 助手，请友好地回答员工问题。"

第一阶段：翻车现场

上线第一天，机器人就开始胡说了：

员工问："咱们公司能在家办公几天？" 机器人答："根据公司政策，员工每月可以申请 5 天远程办公。需要提前一周申请，由直属领导审批……"

听起来很专业对吧？但实际上，AcmeAI 的政策是"每周可以远程办公 2 天"。这个"每月 5 天"完全是 GPT-4 自己编的——它见过太多 HR 政策文本，所以"自动脑补"了一个看起来合理的版本。

更糟糕的是：

员工问："我的电脑蓝屏了找谁？" 机器人答："请联系 IT 部门，邮箱是 it@acme.com……"

邮箱看起来很正常，但 IT 部门的真实邮箱是 support@acmeai.com。这种细节错误最致命，因为员工真的会用错邮箱发邮件，然后 IT 收不到，问题就石沉大海。

还有更离谱的：

员工问："公司的晋升机制是怎样的？" 机器人答："公司每年 6 月和 12 月进行两次晋升评估。晋升分为 P5、P6、P7 三个职级……"

但实际上，AcmeAI 是一家成立不到一年的小公司，根本就没有成文的晋升机制。机器人凭空"创造"了一个听起来很合理的晋升体系。

第二阶段：领导发火了

CTO 把你叫过去："我们的问答机器人在制造麻烦，员工已经开始不信任它了。给我想个办法，要么修好，要么下线。"

你心想：GPT-4 这么强大，怎么会连公司政策都搞不定？问题出在哪？

你意识到两个关键事实：

1. 公司政策不在 GPT-4 的训练数据里——GPT-4 在 2023 年训练完成时，AcmeAI 还没成立。 2. 即使政策在训练数据里，GPT-4 也无法准确回忆——它的训练数据是海量的，公司政策这种小众内容，根本不可能被精确记住。

更深入地想，你意识到：GPT-4 的"知识"是模糊的统计印象，而不是精确的事实。 它"知道"公司通常有年假政策，但不知道 AcmeAI 的年假政策具体是几天。

第三阶段：RAG 登场

你决定引入 RAG。方案如下：

步骤 1：收集资料

你把公司所有相关文档整理出来：

• 《员工手册.pdf》
• 《IT 支持手册.docx》
• 《财务报销流程.md》
• 《远程办公政策.pdf》
• 《晋升评估办法（草案）.docx》

等等，总共 30 多份文档。

步骤 2：建立索引

你用了一个工具组合（LangChain + OpenAI Embeddings + 向量数据库 Chroma），把这些文档切成小段（每段大约 500 字，叫做 chunk），然后把每段转换成一串数字（这串数字叫做向量 embedding，你可以把它理解为"这段文字的数学指纹"），存到向量数据库里。

> 关于 embedding 的原理，我们后面章节会详细讲。这里你只需要知道：意思相近的文字，它们的向量也相近。

打个比方：如果"猫"和"狗"的向量距离很近，"猫"和"汽车"的向量距离很远，那么向量检索系统就能根据这个"远近"找到最相关的段落。

步骤 3：改造问答流程

当员工提问时，新流程是这样的：

1. 员工输入问题："年假怎么请？" 2. 检索阶段：系统把问题也转换成一个向量，然后在向量数据库里搜索，找出和这个问题"意思最接近"的 5 个段落。 3. 增强阶段：系统把这 5 个段落连同问题，组装成一个新的提示词。 4. 生成阶段：把提示词发给 GPT-4，让它基于这些资