RAG导论：为什么大模型需要外挂大脑

第 1 章　RAG 导论：为什么大模型需要外挂大脑

大语言模型（Large Language Model, LLM）的"知识"不是无限的，它有三条硬边界：训练数据的截止日期、训练数据的覆盖范围、以及对私有数据的一无所知。当我们把这三条边界放在一起看，就会立刻明白为什么把整本《公司技术规范》直接贴进对话框并不能解决真正的企业知识问答——因为在 Context Window、调用成本、数据隐私这些工程约束之下，"把所有资料塞进 Prompt"本身就是一种脆弱的临时方案。RAG（Retrieval-Augmented Generation，检索增强生成）正是为了系统性地突破这些约束而诞生的工程范式。本章我们先建立"问题感"，看清 LLM 究竟不擅长什么，再看清 RAG 想解决什么，最后用一个 30 行代码的 Demo 让一切落地。

---

1.1 三个字讲清楚 LLM 的"知"与"不知"

要把 LLM 的局限性讲透，必须先澄清一件容易被外行混淆的事：LLM 不是数据库，它是一个"下一个 token 预测器"。它的"知识"并不是像 MySQL 那样被显式索引和查询，而是在训练阶段以数十亿次的梯度更新，被压缩进了 1750 亿（GPT-3 规模）或更多参数构成的巨大矩阵里。当我们问它一个问题时，它做的事其实是"在当前上下文的条件下，最有可能接出来的下一段文本是什么"——而不是"在某个知识库里查到了什么"。

这件事直接导致了三类系统性的局限，我们用一组对照表来先建立直观印象，后面的小节会逐一拆解：

| 局限类型 | 一句话描述 | 典型表现 | | --- | --- | --- | | 知识截止（Knowledge Cutoff） | 模型的"记忆"停在训练数据收集的那一刻 | 询问昨天发生的事会被礼貌告知"我不知道" | | 幻觉（Hallucination） | 模型会在不确定时自信地编造 | 编造不存在的论文标题、API 参数、法律条文 | | 私有数据盲区 | 模型从未见过你公司的任何文档 | 询问内部规范只能给出通用行业惯例 |

下面，我们逐条拆开来看。

---

1.2 知识截止：模型被冻结在某个时间点

1.2.1 什么是知识截止

每当一个 LLM 发布时，官方都会披露一个明确的"训练数据截止日期（training data cutoff）"。例如 GPT-4 的初始版本截止于 2021 年 9 月，GPT-4 Turbo 截止于 2023 年 4 月，Claude 3 系列、Gemini 系列也都有自己的截止日期。这意味着在截止日期之后发生的事，模型原则上是不"知道"的——哪怕它装得再像，它也只能根据语言模式做猜测。

工程上，我们必须记住一个根深蒂固的事实：模型权重是静态的。发布之后即使发现错误，也不会"自我反省后改正"。要让模型认知新事实，只有三条路： 1. 重新训练或继续训练（pre-train / continue-train）：成本极高，每次动辄数百万美元，且仍然受限于训练时间窗口。 2. 微调（Fine-tuning）：把新知识烧进 LoRA 适配器，相对便宜但更新滞后，且会让基础能力受到侵蚀（catastrophic forgetting）。 3. 检索（Retrieval）：在回答生成时实时引入新文档——这正是 RAG 的核心思路。

1.2.2 一个会让人吃亏的真实场景

设想这样的对话： > 用户：我公司的差旅报销政策最近更新了什么？ > > GPT-4：抱歉，我的训练数据截止于 2021 年 9 月，无法确认最近的政策更新。建议你咨询公司 HR 或查阅最新的员工手册。

表面上看这个回答没问题，但仔细想想——企业里几乎所有"知识"都是持续变化的：产品规格每周更新、规章制度每月修订、行情数据每日刷新、研究文献每小时涌现。对于一个企业级问答系统而言，"知识截止"不是偶发的小麻烦，而是结构性的缺陷。

更有迷惑性的是另一种情况：模型在截止日期之后的信息上编造得头头是道。比如你问它"2024 年图灵奖得主是谁"，它可能会一本正经地告诉你一个根本不存在的名字。这就是我们马上要讲的第二类问题：幻觉。

---

1.3 幻觉：当模型以 99% 的自信生成 100% 的错误

1.3.1 幻觉的三种形态

"幻觉（Hallucination）"这个词借自医学——病人看到不存在的东西。在 LLM 语境下，它指模型生成了语法流畅、看似合理，但与事实不符的内容。学术界通常把幻觉分为三类：

1. 事实性幻觉（Factual Hallucination）：陈述与客观世界不符。例：把"爱因斯坦 1879 年出生"说成"1889 年"。 2. 忠实性幻觉（Faithfulness Hallucination）：与用户提供的上下文不符。例：你给了一段产品手册，模型回答时却引用了不存在的章节。 3. 推理幻觉（Reasoning Hallucination）：逻辑链条本身出错。例：在数学题中正确读了数字但算错，或者在链式推理中途"跳步"。

对于企业应用来说，任何一种幻觉都是不可接受的。一个虚构的 API 参数名、一个不存在的法院判例、一条被改写的合同条款，都可能在生产环境引发真实损失。

1.3.2 为什么 LLM 必然会幻觉

要理解幻觉为什么会发生，必须理解 LLM 的训练目标：给定上下文 $C$，最大化下一个 token $y$ 的对数似然

$$\mathcal{L} = -\sum_{t=1}^{T} \log p_\theta(y_t \mid y_{<t}, C)$$

这个目标函数只关心"像不像训练分布"，不关心"是不是事实"。当模型被问到训练数据从未覆盖的问题时，它并不会回答"我不知道"——因为训练目标里压根没有"承认无知"这个奖励。它只能选一个"看起来最像正确答案"的 token 序列输出。这就是幻觉的数学根源。

一个更形象的类比：LLM 像一个准备开卷考试但没带任何资料的学生。他必须写点什么，于是他凭借"题目应该长什么样"的直觉，编造了一份看起来很专业的答案。这个学生——也就是 LLM——并不知道自己编的内容是假的，因为"知道什么"与"像什么"在它的训练目标里从来就不是一回事。

1.3.3 幻觉不是 bug，是 feature 的副作用

值得强调的是：在统计意义上，幻觉是当前生成范式的固有属性，而非一个可被简单修补的 bug。Vectara 在 2024 年发布的 Hallucination Leaderboard 给出了一个让人警醒的数字：即便是顶级模型，在摘要任务上的幻觉率也在 3%—5% 之间，更复杂的问答任务可达 10%—27%。换句话说，无论你怎么切换 Prompt、怎么调节 temperature，在缺乏事实锚点的场景下，幻觉都难以彻底消除。

既然无法靠模型自身消灭幻觉，工程上的解法就变成了：在生成阶段引入可验证的事实依据。这就是 RAG 想做的事——把模型从一个"凭直觉答题的学生"，变成一个"开着资料答题的研究员"。

---

1.4 私有数据盲区：你公司的规范从来没进过训练集

1.4.1 通用预训练数据的覆盖盲点

大模型的训练语料虽然庞大——Common Crawl、Wikipedia、GitHub、ArXiv、新闻语料……合起来可达数万亿 token——但相对于每一家企业、每一个团队的内部知识，仍然是沧海一粟。一家中等规模 SaaS 公司的产品文档可能有 2,000 篇；一家制造业龙头的工艺手册可能有 10 万页；一个律所的历史判例数据库可能上亿条。这些数据：

• **从未公开爬取过**，自然不会进入预训练语料。
• 即便在公开语料里出现，也只是**零散的、对该企业无意义的引用**。
• 很多出于合规要求被严格保护，**根本没有可能流向第三方**。

结果是：你问任何通用 LLM 关于"贵公司订单系统订单号为 8 位字符串、前缀为 O 而不是 0"，它都只能给出一个通用行业惯例，而无法告知你的真实规则。

1.4.2 合规与隐私的双重约束

更棘手的是合规。即使技术上可以把内部文档丢进 Prompt，企业仍然要面对：

• **数据出域问题**：把客户合同、源代码、财务数据发给 OpenAI / Anthropic 的 API，可能违反 GDPR、SOC2、HIPAA、以及公司内部的"数据不出内网"红线。
• **数据留存风险**：第三方 API 是否会留存输入用于训练？即便有"opt-out"选项，企业法务通常要求"物理隔离"。
• **审计追溯困难**：当 LLM 给出了一个错误答案导致业务损失，谁来为这个答案负责？是模型、是 Prompt 工程师、还是把资料贴进去的业务人员？

这些约束意味着：即便不考虑成本，"把私域资料贴进通用 LLM"在大多数企业里既不被允许，也不可持续。

---

1.5 Prompt Engineering 的边界：把资料塞进上下文只是临时解

直觉上，很多人解决"知识盲区"的第一反应就是 Prompt 工程：把相关资料复制粘贴到 System Prompt 里。但这招在工程上是脆弱的。下面从四个维度看它的边界。

1.5.1 Context Window 的硬约束

Context Window（上下文窗口）是模型一次推理能"看见"的 token 总数。从最早的 GPT-3 的 4K，到 GPT-4 的 8K / 32K，再到 Claude 2 的 100K、Claude 3 的 200K，以及 Gemini 1.5 Pro 宣称的 1M，看似不断增长，但仍然面临三类工程问题：

1. Lost-in-the-Middle 现象：Liu 等人 2023 年的研究 *Lost in the Middle* 表明，当关键信息放在长上下文的中间时，模型的引用准确率明显下降，只有放在首尾时最稳。这意味着即便你能塞进 200K token，也不等于模型能稳定地"找到"你塞进去的关键事实。 2. 成本随长度近线性甚至超线性增长：Transformer 的自注意力计算复杂度是 $O(n^2)$，输入越长，时延和单价都显著上升。 3. 延迟与并发的不友好：把 100K token 的输入铺到 Prompt 里，单次推理可能需要十几秒甚至几十秒，无法支撑客服等实时场景。

用一个具体数字让你有感觉：以 GPT-4 Turbo 当前报价为例，输入 100K token 的一次请求，单价就达到 \$0.10 量级。如果一个企业每天有 10,000 次类似调用，仅输入成本就是每月 30,000 美元起步——还远没算上输出 token。

1.5.2 成本曲线：边际收益递减

更深层的问题是：把全部资料塞进 Prompt，是负向 ROI 的做法。假设公司有 1000 篇规范文档，平均每篇 2K token。全部塞进 Prompt 意味着每次请求都喂 2M token，而 99% 的问答只需要其中 5—10 篇相关文档。99% 的输入其实在为那 1% 的潜在相关性买单。

更糟的是，长 Prompt 还会让模型"分心"。当无关段落远多于相关段落时，模型甚至会更倾向于"自己编一个答案"——这在直觉上违反常识，但实验上反复验证：上下文越长、噪声越多，幻觉率反而越高。这与上一节"幻觉"叠加起来，是一个会自我放大的坏循环。

1.5.3 隐私：把数据发给第三方

如上一节所述，把客户名单、源代码、未公开财报直接拼进通用 LLM 的 Prompt，是大多数企业法务无法接受的。即便服务商提供"数据不用于训练"的承诺，企业通常仍要求内部自建部署或专有云隔离。

1.5.4 维护性：知识更新即代码重新发布

最后一个边界是工程维护性。每次公司政策一更新，团队就要：

• 修改 System Prompt 或 Few-shot 示例；
• 重新发布对应版本；
• 让所有使用者重新加载。

这与"知识库应当持续演进"的常识相悖。我们希望的是，改了文档就生效，不需要任何应用层改动。这正是 RAG 数据流的天然形态。

| 维度 | 把全部资料塞进 Prompt | RAG | | --- | --- | --- | | Context Window | 受限且有 Lost-in-the-Middle 风险 | 只塞入 Top-K 相关片段 | | 单次成本 | 与总知识量线性相关 | 与检索量线性相关，与知识总量无关 | | 数据隐私 | 数据出境 / 出域 | 数据可保留在私域 | | 知识更新 | 修改 Prompt、重发版本 | 更新知识库即可，零应用层改动 | | 幻觉率 | 噪声越多越高 | 由检索结果锚定，显著下降 |

理解了这些，我们才能真正看清 RAG 想做什么。

---

1.6 RAG 核心思想：用检索为生成提供事实依据

1.6.1 一句话定义

RAG（Retrieval-Augmented Generation，检索增强生成）是一种把"信息检索"与"文本生成"流水线化结合的架构。它让 LLM 在生成回答之前，先从一个外部知识库中自动检索与用户问题相关的若干片段，再把这些片段连同原始问题一起喂给 LLM，让 LLM 基于这些"事实锚点"作答。

用一个公式来表达：

$$\text{Answer} = \text{LLM}\bigl(\text{Query};\ \text{Retrieve}(\text{Query},\ \mathcal{K})\bigr)$$

其中 $\mathcal{K}$ 是外部知识库（Knowledge Base），$\text{Retrieve}(\cdot)$ 是检索器，$\text{LLM}(\cdot)$ 是生成器。检索结果作为附加上下文（context）拼到 Prompt 里，让生成有"事实依据"。

1.6.2 三阶段流水线

虽然后续章节会逐部件拆解，这里我们先用一个高层视图，让你在脑子里建起 RAG 的骨架。RAG 系统在一次请求里通常经历三个阶段：

```mermaid flowchart LR Q[用户问题 Query] --> R1[1. 检索 Retrieval] R1 -->|Top-K 文档片段| R2[2. 增强 Augmentation] Q --> R2 R2 --> R3[3. 生成 Generation] R3 --> A[最终回答 Answer] ```

1. 检索（Retrieval）：把用户的问题向量化，去知识库里找语义上最相关的若干段落。 2. 增强（Augmentation）：把检索回来的段落与原始问题组装成一个新的 Prompt。 3. 生成（Generation）：把组装好的 Prompt 喂给 LLM，让它基于这些事实依据回答。

最终用户感受到的是"我问了问题，AI 基于公司的真实文档作答"，而不是"AI 基于它那堆训练数据蒙一个答案"。

1.6.3 RAG 的关键洞察

RAG 的"魔法"其实并不复杂，它建立在两个朴素的洞察之上：

1. 检索比生成更可控：给定一个明确的查询，从语料库里找出相关段落，是一个相对容易评估、容易优化的任务——召回率、MRR、NDCG 都是成熟指标；而"让 LLM 凭空生成事实"，则是一个几乎不可控的任务。 2. 生成在给定上下文时更靠谱：当 LLM 拿到明确的上下文时，它的工作从"回忆"退化为"阅读理解 + 总结"，幻觉率断崖式下降。学术上把这种效应叫做 grounded generation（锚定生成）。

这两条洞察加在一起，就构成了 RAG 的全部哲学：把一个高难度的开放问题，拆成一个检索的子问题和一个有锚点的生成子问题。前者的可控性补足后者的随机性。

---

1.7 RAG vs. Fine-tuning vs. Long Context vs. Agent：四种方案的权衡

在 LLM 工程实践中，"给模型装上知识"并非只有 RAG 一条路。决策者经常会问：为什么不用微调？为什么不用超长上下文？为什么不让 Agent 自己查？我们逐一看。

1.7.1 微调（Fine-tuning）

微调指的是在预训练模型的基础上，用特定领域的数据继续训练，让模型的参数本身吸收这些知识。

• **优势**：能把"风格、口吻、行为模式"内化进模型——比如让模型学会用某个公司的口吻回答。
• **劣势**：知识更新慢、训练成本高、可解释性差、容易遗忘基础能力。每次知识更新都要重新训练。
• **典型场景**：让模型精通某种对话风格、固定格式的输出，而不是回答开放的事实性问题。

1.7.2 长上下文（Long Context）

长上下文指的是直接把全部资料塞进 Prompt，借超大 Context Window（100K—1M token）让模型"看见"一切。

• **优势**：实现简单，无需额外基础设施。
• **劣势**：成本高、延迟长、Lost-in-the-Middle 现象明显；不适合知识库会持续增长的场景；数据隐私仍是问题。
• **典型场景**：一次性分析长文档（如法律合同审阅、单篇论文深度阅读），而非持续演化的知识库。

1.7.3 Agent（智能体）

Agent 让 LLM 自主决定"该调用什么工具、查什么资料"，实现更复杂的多步骤工作流。

• **优势**：可以处理多步、跨数据源的复杂任务，例如"先查订单系统，再查支付系统，再写汇总邮件"。
• **劣势**：构建复杂度高、调试困难、latency 高、单次成本最高。
• **典型场景**：复杂业务流程自动化、研究助理式工作流。

1.7.4 RAG 的相对定位

RAG 是四者中的"事实层"——它专门负责"在回答前先把相关事实找出来"。它既可以独立使用（最简单的企业 FAQ），也可以作为 Agent 的一个工具（复杂工作流中的"查资料"步骤）。

| 方案 | 适用问题 | 更新成本 | 推理成本 | 数据隐私 | 工程复杂度 | | --- | --- | --- | --- | --- | --- | | Prompt / Long Context | 一次性长文档任务 | 低 | 高 | 差 | 低 | | Fine-tuning | 风格/格式内化 | 很高 | 低 | 好 | 中 | | RAG | 持续演化的知识库问答 | 低 | 中 | 好 | 中 | | Agent | 多步跨系统工作流 | 低 | 高 | 取决于工具 | 高