Why RAG: The Real Reason LLMs Need a Memory Subsystem

第一章：Why RAG——LLM 为什么需要一个"记忆子系统"

打开一本讲 RAG 的书，第一章如果不回答"为什么"，后面所有的工程细节都会变成空中楼阁。所以让我们从一个具体的、可能会让你血压升高的场景开始。

一个让你血压升高的场景

周五下午 5 点，你负责的 SaaS 平台刚刚发布 v3.2 版本，其中 SDK 的 `Client.start()` 方法从同步签名改成了异步签名，同时新增了流式响应支持。周五晚上和周末，你和团队轮班处理了几个 P0 bug，然后——

周一早上 9:03，一位企业客户在集成群里 @ 了你们的 AI 助手机器人：

> "你们 v3.2 那个 SDK 怎么接入？是不是还是先 `client = new Client()`，然后 `client.start()` 就开始订阅了？支持流式响应吗？"

你的 AI 助手的训练数据截止于 2024 年 1 月。它不仅不知道 v3.2 的存在，它甚至不知道你们这个产品的存在过——如果你用的是通用基础模型（foundation model），比如 GPT-4 的某个早期 snapshot，模型甚至不知道自己扮演的是"你们公司"的客服。它冷静地、自信的、带着一丝礼貌的语气回答：

> "是的，您可以使用 `client.start()` 启动客户端，它默认支持流式响应。以下是一个示例代码……"

这就是一次典型的 hallucination（幻觉）——而且是最要命的那种：答案看起来合理，结构完整，甚至连代码示例都"长得对"，但每一行都是错的。客户拿去跑，会得到一个完全不同的报错。然后客户截图、@ 销售、@ 你，发一条措辞不善的工单。

更糟糕的还在后面：客户不知道这答案"为什么错"。模型给不出一个"我基于文档 § 4.2 节回答"的引用，因为模型根本没有读过你的文档——它在编。

这就是 LLM（Large Language Model，大语言模型）在企业场景里"裸奔"的三个核心症状：

1. 知识静态（Stale Knowledge）——training cutoff 之后发生的事，模型一无所知； 2. 幻觉（Hallucination）——模型会"补全"它不知道的内容，而且补得很自信； 3. 不可追溯（Non-traceability）——你问它"你为什么这么答？"，它只能给你一段话术性的解释（"根据我的训练数据……"），而不是一份可点击的原文引用。

在企业应用里，这三个症状都不是"小瑕疵"，而是致命的合规与信任问题。医生不会在不确定手术流程时给病人开刀，律师不会基于一段想象的判例给客户出意见，企业的 AI 助手也不应该基于"模型觉得合理"的幻觉来回答客户关于生产环境的问题。

所以我们需要一种工程方案，给 LLM 接上一个外接的、可更新的、可追溯的"记忆子系统"。这就是 RAG（Retrieval-Augmented Generation，检索增强生成）。

但在我们深入 RAG 之前，我们必须诚实地面对一个前置问题：RAG 是唯一方案吗？ 我们手里其实有三个候选——把文档塞进 prompt 里（Long Context Prompting）、给模型做 Fine-tuning（微调）、以及 RAG。本章的核心任务，就是把这三个方案的真实工程代价摆到桌面上，让你看清楚在哪些场景里 RAG 是甜区，在哪些场景里 RAG 是个错误选择。

---

LLM 的三大固有限制：为什么"裸 LLM"在企业里不够用

我们先把这三个固有限制讲透。不要觉得这是"已知知识"——很多团队在 2023 年都跳过这一步直接上 fine-tuning，结果第二年就被幻觉问题打回来了。

1.1 知识静态：training cutoff 之后，世界变了

LLM 的"知识"全部来自于它训练那一刻的语料快照。这个快照是被动的、凝固的。模型本身没有任何机制去感知"今天是 2025 年 7 月"——它甚至不能告诉你"现在几点了"，更不用说读最新的 changelog。

我用一组真实数字让你感受一下这个滞后有多严重：

• GPT-4 (2023-03 snapshot) 的 training cutoff 是 **2021 年 9 月**；
• Claude 3 Opus 的 cutoff 是 **2024 年 2 月**；
• Llama 3 70B 的 cutoff 是 **2023 年 12 月**。

这意味着，任何发生在 cutoff 之后的事件——新模型发布、法规变更、新冠疫苗第四针、你们公司新签的并购协议——对模型来说都是不存在的。

企业里最经典的痛点之一：产品规格变更。我们刚才客服场景就是典型。再举几个：

• **金融行业**：央行调整了 LPR（贷款市场报价利率），客户问 AI 客服"现在房贷利率多少？"，模型只能给出旧利率；
• **法律行业**：2024 年生效的新公司法，模型如果没更新过，会引用已经废止的条款；
• **医疗行业**：新药上市、新指南发布，模型如果只能"凭印象"回答，临床决策的风险是致命的。

有一种"看似能解决"的方案是：每次更新都重新训练模型。但全量预训练（pre-training from scratch）的成本是以千万美元为单位的，即使是增量继续训练（continued pretraining），单次成本也在六到七位数美元之间，时间周期以周计。这在企业场景里几乎不可能作为常规操作。

所以，"让模型自带的知识保持新鲜"这条路，工程上是走不通的。你必须把"知识"从模型内部剥离出来，放到一个外挂的、可廉价更新的存储系统里——这是 RAG 整个范式的第一性原理（first principles）。

1.2 幻觉：模型不知道自己在"补全"

幻觉的本质是：LLM 是一个"下一个 token 预测器"（next-token predictor），不是一个"事实查询器"。当你问它"我们公司的退款政策是什么？"，它没有"去查"这个动作，它只是根据 prompt 的语境，预测一个"听起来像退款政策"的文本序列。

这个区别听起来学术，但在工程上影响巨大。一个事实查询器（哪怕是个有 bug 的查询器）出错时，通常是"返回 null"或者"返回错值"——这两种都是工程上可控的失败模式。但一个"补全器"出错时，它会返回一个看起来像答案、但其实完全虚构的内容——这就是 hallucination。

我特别想强调一个反直觉的点：幻觉不是 bug，它是 LLM 的 feature。模型被训练的目标就是"流畅地、自洽地、符合语境地把句子补全"。你没法通过"加大模型尺寸"来消除幻觉——研究界已经反复证明，模型越大，它在"不知道的内容"上补全得越像真实答案，换句话说，大模型的幻觉更难被用户察觉。

企业场景里，幻觉的成本是分级的：

• **低风险场景**：写营销文案、头脑风暴、生成代码骨架——幻觉可接受，甚至有时是 feature；
• **中风险场景**：写文档、回答通用知识问题——幻觉可控，用户有判断力；
• **高风险场景**：合规问答、医疗建议、法律条款、客服具体业务咨询——幻觉**不可接受**，必须可追溯。

RAG 在幻觉问题上做的事情，本质上是把模型的"输入空间"从"它训练时的全人类语料"约束到一个有界、可控、有据可查的知识子集——你给它什么文档，它就基于这些文档回答，问到知识库外的问题，它应该回答"我不知道"（这个能力可以通过 prompt engineering 进一步强化，后面章节会讲）。

虽然 RAG 不能 100% 消除幻觉（它只是降低了幻觉的发生概率和扩大了幻觉的检测面），但它把幻觉从"暗处的危险"变成了"明面上的工程问题"——这件事本身就是巨大的进步。

1.3 不可追溯：你的 AI 助手为什么这么答？

我做过一些企业 AI 项目的咨询，最常被问到的两个问题之一就是：

> "我们的 AI 给客户/医生/律师/法务回了这封信。它为什么这么答？依据是什么？"

第二个常被问到的问题（你可以猜到）是：

> "我能不能让它不要这么答？"

这两个问题都指向同一个核心需求：可解释性与可审计性（explainability & auditability）。

LLM 的回答是一个 1024 维（或更高维）向量经过几十层 transformer 计算后产生的 token 序列。即使你能拿到这个向量，你也解释不了"为什么是 '是' 而不是 '否'"。现代 AI 解释性研究（mechanistic interpretability）虽然在进展，但对于"一个生产环境部署的 AI 助手为什么回了某个答案"这个问题，仍然没有工程上可用的解。

但在大多数企业场景里，业务方要的"可解释性"其实非常具体：要的是"这个答案是基于哪份文档的第几页回答的"。这个需求，RAG 可以完美满足——因为 RAG 的整个流程就是"先检索，再生成"，检索环节天然就把答案的来源锁定到具体的 chunk / document / page。

如果你用 fine-tuning 来"灌输"知识，你面对的局面是这样的：模型的权重（weights）里确实"沉淀"了一些信息，但这些信息散布在数十亿个参数中，你无法定位、无法编辑、无法审计——它几乎是黑的。

而 RAG 的检索痕迹天然就是审计日志：哪个 query 命中了哪几个 chunk，每个 chunk 的相似度分数多少，最后生成环节引用了哪几段——这些全都可以被记录、被回放、被合规审查。

对于企业级 AI 部署，"可追溯"几乎和"答案准确"同等重要。 一个有引用的错误答案，远比一个没引用的正确答案更让业务方安心——因为前者是可修复的（去改文档或检索逻辑），后者是灵异事件。

---

三种候选方案的工程代价：把选项摆上桌

现在我们已经清楚地知道，LLM 裸奔有三个致命问题。接下来就要回答一个工程上的核心问题：怎么解决？

我们手里有三个看起来都能解决这些问题的工具：

| 方案 | 基本思想 | 关键词 | |------|---------|--------| | Prompt Engineering + Long Context | 把所有相关文档塞进 prompt | 128K context, all-in-prompt | | Fine-tuning | 用领域数据继续训练模型 | PEFT, LoRA, QLoRA | | RAG | 把检索系统接到 LLM 上 | vector DB, retrieval, grounding |

很多人第一次接触 RAG 时，会觉得"为什么不直接 fine-tune？""为什么不用 long context？"。这是合理的疑问——如果我们不正面回答这个疑问，整本书后面所有的内容都会被质疑。

让我们诚实地、带着工程现实地把这三个方案的真实代价放在同一张桌子上对比。

2.1 Prompt Engineering / Long Context Stuffing

基本思想：把用户的问题 + 所有相关知识，拼成一个超长 prompt，送给一个支持 128K 甚至 1M tokens context window 的模型，让模型"看完再答"。

优势：

• **零基础设施**：不需要训练，不需要向量库；
• **实现最简单**：就是拼字符串；
• **答案天然有"出处"（某种意义上）**：你塞进去的文档就是 prompt 的一部分，可以引用。

真实的工程代价：

把文档塞进 prompt，听起来像"白嫖"长 context——但代价并不像宣传材料里那么美好。我来拆解一下：

代价 1：Tokens 成本是非线性增长的

Claude 3.5 Sonnet 的 input tokens 定价是 $3 / million tokens（截至 2024 年年中）。一个 100K token 的 prompt，单次调用成本就是 $0.30。如果你的应用每天有 10 万次问答，光 input cost 就是 $30,000/月。这还没算 output。

更要命的是：大多数 RAG / Long Context 应用的输入/输出比是 50:1 甚至 100:1——你喂 100K token 进去，模型可能只回 500 token。input cost 是大头。

代价 2：Lost-in-the-Middle 问题

这是 2023 年 Liu 等人的经典研究（NILOCS, "Lost in the Middle"）揭示的现象：LLM 对 context 中间部分的注意力显著弱于首尾。即使你塞了 128K tokens，模型对中段的内容"读取质量"是下降的。

这意味着：当你把所有相关文档都塞进去，真正被模型"看到"的，可能只有前面 20% 和最后 20%。中间大量 token 是"浪费"的——你既花了钱，又没拿到效果。

代价 3：延迟（Latency）

Context 越长，prefill 阶段（读取所有 input tokens）越慢。对于一个 100K token 的 prompt，prefill 可能要 3-5 秒。加上 generation，总延迟很容易突破 10 秒。企业级对话应用的"可接受延迟"通常在 2-3 秒以内。10 秒延迟直接破坏了 UX。

代价 4：无法扩展（Scaling Cliff）

如果你的知识库真的非常大——比如一个 50 万份合同、100GB 文本的法律数据库——long context stuffing 物理上就不可能，无论 context window 多大。

代价 5：失去了"选择性上下文"

Long context 把所有东西都喂给模型，模型自己去做"哪些相关、哪些不相关"的判断。这个判断 LLM 做得并不好——它倾向于"试图回答所有看起来相关的内容"，而不是"聚焦最相关"。RAG 在检索阶段就已经做了一层过滤，LLM 只需要回答"被检索到的相关文档"。

什么场景 long context 是合理的？

• 一次性任务（比如"帮我总结这本 200 页的书"）；
• 数据量本身就小（< 30K tokens）；
• 不需要"频繁更新"（每次任务前手动拼 prompt）；
• 预算允许调用成本。

结论：long context stuffing 适合"小数据 + 一次性 + 不在乎成本"的任务。它是特定的工具，不是普适方案。

2.2 Fine-tuning（微调）

基本思想：用领域数据继续训练（continue training）一个基础模型，让模型的权重里"沉淀"领域知识。

优势：

• 推理延迟低（生成阶段不需要外部检索）；
• 模型在风格、输出格式、领域 shorthand 上能学到很深的细节；
• 推理时不需要额外基础设施。

真实的工程代价：

代价 1：知识的"凝固"成本

Fine-tuning 把知识烧进模型权重。一旦烧进去：

• 你无法定位"哪部分权重代表了这条知识"；
• 你无法删除单条知识（只能整体重新训练）；
• 你无法编辑任何一条事实而不影响其他事实。

这意味着，每次知识更新都必须重新做一次 fine-tuning。

代价 2：数据准备的隐形工作量

Fine-tuning 的数据准备比想象的要重得多。你需要：

• 高质量的 Q-A pairs（不是文档，是问答对）；
• 领域专家标注（不是任何人能标）；
• 多样性覆盖（避免模型过拟合到某个表达方式）；
• 评估集（不能只看 loss 曲线）。

一个完整的领域 fine-tuning 数据集，从准备到清洗到验证，通常需要 2-8 周——而 RAG 的数据准备可能只要几天（把文档切成 chunk）。

代价 3：灾难性遗忘（Catastrophic Forgetting）

当你在 Llama 3 上用医学数据 fine-tune，它可能在医学问答上变好了，但在通用对话、推理、代码能力上退化了。这是 continual learning 的经典难题。PEFT（Parameter-Efficient Fine-Tuning）方法比如 LoRA / QLoRA 部分缓解了这个问题，但没有完全消除。

代价 4：幻觉问题没有真正解决

Fine-tuning 对事实性幻觉几乎没有改善。Fine-tune 后的模型在它训练数据覆盖到的事实上"答得更准"，但在它训练数据没覆盖到的事实上，仍然会幻觉。Fine-tuning 教的是"风格和能力"，不是"事实"。

代价 5：审计与合规难题

模型权重里的知识是不可读的。当你合规部门来问"你的 AI 凭啥这么答？"，你拿不出答案——因为答案已经分散在几十亿个浮点数里了。

什么场景 fine-tuning 是合理的？

• 任务确实需要**改变模型行为**（比如"让它像 5 岁的孩子说话"）；
• 数据量足够大（> 10K 高质量样本）；
• 更新频率低（半年以上才更新）；
• 对延迟敏感（RAG 的检索延迟无法接受）；
• 有能力承担训练基础设施和数据准备的人力。

结论：fine-tuning 是行为改造工具，不是知识注入工具。用错它的团队，普遍是因为把"知识"和"行为"混淆了。

2.3 RAG（Retrieval-Augmented Generation）

基本思想：把知识外置到一个可检索的存储里（比如 vector database）。每次回答问题时，先检索相关知识，再把这些知识喂给 LLM，让 LLM 基于这些知识生成答案。

优势（相对于上面两个）：

• **知识更新廉价**：你更新的是文档，不是模型权重——可能只需要几秒到几分钟；
• **知识与模型解耦**：模型不变，知识库换；
• **可追溯**：每条答案都能追溯到具体 chunk；
• **冷启动友好**：哪怕只有几百条文档，也能跑起来；
• **多领域可切换**：换 prompt 或换检索索引就能服务不同领域。

真实的工程代价：

我们必须诚实——RAG 不是免费的。它有自己的代价：

代价 1：基础设施复杂度

你需要：

• Embedding model（生成 chunk 的向量）；
• Vector database / 检索系统（存储索引和查询）；
• Chunking pipeline（把文档切成合适的块）；
• Re-ranking（可选，但生产级必备）；
• 监