RAG Paradigm: Why Knowledge-Augmented LLMs Win / 第一章 RAG 范式：为什么知识增强的大模型会赢

RAG Paradigm: Why Knowledge-Augmented LLMs Win / RAG 范式：为什么知识增强的大模型会赢

1.1 知识的"半衰期"困境：参数化 LLM 的固有缺陷

2024 年 1 月，某大型银行把内部合规文档（约 12 万页 PDF）交给一个 70B 的开源 LLM 做闭卷问答。基线准确率是 31%。两个月后，合规部门发布了 200 多页的修订。把这些修订合并后再次评估，准确率掉到 19%。这不是模型变笨了——它的参数没动过一根毫毛——而是它所"记得的世界"已经过时。这个现象揭示了大模型在工业落地中最尖锐的问题：参数化知识的半衰期问题。

从第一性原理看，一个 LLM 所掌握的全部知识来自三类来源：

1. 预训练参数（Parametric Memory）：通过海量文本的 next-token prediction 内化在权重中的统计规律。这部分知识规模巨大，但更新代价是「再训练一次」级别的算力开销。 2. 上下文窗口（Working Memory）：推理时通过 prompt 输入的事实、指令与示例。它的容量受限于模型的 context length，且每多一个 token 都对应着真实的注意力计算成本 $O(n^2)$（标准 Transformer）。 3. 外挂知识库（External Memory）：以可检索的形式独立存储的知识，通过 retrieval mechanism 注入到推理上下文。这正是 RAG 所定义的第三类供给。

我们可以用一张"知识供给光谱"来观察这三者之间的权衡：

| 维度 | 预训练参数 | 上下文窗口 | 外挂知识库 | |------|-----------|-----------|-----------| | Knowledge Freshness 知识新度 | 极差（按月/年级别滞后） | 中等（按请求更新） | 优秀（实时） | | Domain Specialization 领域专业性 | 差（依赖预训练分布） | 中等（依赖 prompt 长度） | 优秀（独立语料） | | Interpretability 可解释性 | 极差（黑盒权重） | 中等（prompt 可审计） | 优秀（可引用原文） | | Latency 推理延迟 | 低（纯前向计算） | 中等（长 prompt 增加 cost） | 中等（多一次检索） | | Cost per Query 单次成本 | $c_\theta$（推理） | $c_\theta \cdot L_\text{prompt}$ | $c_\text{retrieval} + c_\theta \cdot (L_\text{prompt}+k\bar{d})$ | | Capacity 容量上限 | 数十 GB 权重 | $4\text{K} \sim 2\text{M}$ tokens | 无限（受存储约束） |

第三行是关键——可解释性。在金融、医疗、法律场景中，"模型为什么这么回答"的可追溯要求，往往比"回答得多准"更刚性。一个仅靠参数记忆回答"某药品副作用是什么"的医生助手是不可上线的；它必须能给出引用源，而 RAG 天然满足这一点。

但问题不止于"过时"。更深层的问题在于：参数化记忆对长尾知识（long-tail knowledge）极其不友好。一个 7B 模型在 2T tokens 上训练，平均每个 token 见过 0.0035 次，对于出现频率低于 $10^{-5}$ 的事实，准确率会急剧下降，这被学界称为 the curse of rarity。RAG 把这类长尾知识从"必须记住"降维成"必须找到"，对模型权重几乎不构成压力。

最后还有一个经常被忽视的工程事实：参数化记忆难以撤销。如果你的领域知识里存在需要动态"遗忘"的内容（例如某条已被撤回的法规），SFT / continued pretraining 会把这个事实"焊死"在权重里；而 RAG 只需要把对应 chunk 从索引中删除即可。这种可逆性（reversibility）是合规审计场景下的硬需求。

1.2 LLM 知识的四种供给方式与决策矩阵

把 1.1 的三分类扩到四象限，把「长上下文」单列出来——因为 2024 年起 Gemini 1.5 Pro（1M tokens）、Claude 3（200K）、GPT-4 Turbo（128K）已经把"把所有文档塞进 context"变成一种严肃选项。这构成了 LLM 知识的四种供给方式：

• **SFT / Continued Pretraining**：把知识烘进参数
• **Prompt Engineering（含 Few-shot / CoT）**：把知识以指令或示例形式压入上下文
• **RAG**：把知识以外挂索引的方式按需检索
• **Long-Context**：把知识整段装进上下文窗口

这四者的边界并非泾渭分明，但适用场景可以用一张决策矩阵来锚定：

```mermaid flowchart LR Q[决策起点<br/>Knowledge Update Frequency?] --> F1[实时/高频更新] Q --> F2[偶尔更新] Q --> F3[几乎不变] F1 --> R[RAG] F2 --> P{上下文能装下吗?} F3 --> S{需要改变模型行为吗?} P -->|是| LC[Long-Context] P -->|否| R S -->|是| SFT[SFT / Continued PT] S -->|否| PE[Prompt Engineering] ```

（图 1-1：四象限决策流。该图是经验法则，真实决策需要叠加成本与延迟约束。）

我们把它形式化成五条经验法则（Rule of Thumb, ROT），每条都来自至少一个已发表的工业案例：

ROT 1：如果知识更新频率 ≤ 1 周，首选 RAG。RAG 把更新延迟从「一次全量再训练」（数周）压到「一次索引重建」（分钟到小时）。 ROT 2：如果知识总量 ≤ 100K tokens 且几乎不变，Long-Context 在 2024 年的成本曲线下往往更划算——省去向量库、检索器、reranker 的工程开销。 ROT 3：如果核心诉求是改变模型行为或风格（而非补充事实），SFT 比 RAG 更直接。RAG 提供事实，但不擅长重塑"怎么说话"。 ROT 4：Prompt Engineering 是兜底，不是答案。当 prompt 已经写到 8K tokens 仍装不下事实时，继续堆 prompt 是反模式，应当转入 RAG 或 SFT。 ROT 5：混合策略往往胜出。典型组合是 RAG + SFT：用 RAG 提供新鲜事实，用 SFT 注入领域语气、推理模式与格式约束。

下面这张表把每种方案在四个核心维度上的"成本/收益"做了量化估计（基于 2024 H2 的 API 价格与开源硬件成本，仅作量级参考）：

| 方案 | 单次推理成本 | 知识新度 | 可解释性 | 实施复杂度 | |------|------------|---------|---------|-----------| | Prompt Engineering | $0.0001 / 1K tokens | 分钟级 | 高（prompt 可审计） | 低 | | RAG (向量检索 + LLM) | $0.0003 / query + $0.05 / 1K tokens | 秒级 | 高（可返回引用源） | 中 | | Long-Context (1M tokens) | $0.01 ~ $0.05 / query | 分钟级 | 中（但定位困难） | 低 | | SFT / Continued PT | $5K ~ $500K / 次训练 | 按月 | 低 | 高 |

注意 Long-Context 在 1M tokens 时的成本被严重低估：很多模型的定价不是线性的，而是分段累进（caching 命中率也只对重复内容有效）。真正决定胜负的不是绝对成本，而是"每条事实被使用一次"的边际成本。RAG 在这一点上几乎不可超越——索引建好后，每条事实被 N 个 query 复用，边际成本趋近于零。

我们会在第 11 章用 Bayesian Optimization 对这四种方案的 Pareto Frontier 做完整推导。本章只需要记住：RAG 不是 LLM 的替代品，而是 LLM 知识的第四种供给方式；它与 SFT、Prompt、Long-Context 构成的能力光谱，覆盖了从"实时事实"到"行为塑造"的全部需求。

1.3 RAG 系统解剖：离线索引与在线推理的双流水线

把 RAG 当成"在 LLM 前面挂一个搜索引擎"是 90% 的初学者会产生的认知偏差。真正的 RAG 系统是一个双流水线（dual-pipeline）系统：一条在文档更新时跑、另一条在每个用户请求时跑。这两条流水线的耦合点只有一个——向量索引（或更广义的检索索引）。理解这种解耦（decoupling），是理解后续 14 章所有高级组件的前提。

我们先画出整体架构：

```mermaid flowchart LR subgraph offline[Offline Indexing Pipeline 离线索引流水线] A[Documents<br/>PDF / HTML / Markdown] --> B[Parser<br/>文档解析] B --> C[Chunker<br/>文本切块] C --> D[Embedder<br/>嵌入模型] D --> E[(Vector DB<br/>向量数据库)] end subgraph online[Online Inference Pipeline 在线推理流水线] F[User Query] --> G[Retriever<br/>检索器] E --> G G --> H[Reranker<br/>重排序] H --> I[LLM<br/>生成器] F --> I I --> J[Answer + Citations] end K[Document Update] -.触发.-> B ```

（图 1-2：RAG 系统的双流水线架构。离线侧负责把非结构化文档变成可检索的索引，在线侧负责把用户问题变成有引用的回答。两条流水线通过共享索引解耦。）

1.3.1 离线索引流水线（Offline Indexing Pipeline）

这条流水线的输入是异构文档（PDF、HTML、Confluence、Notion、Slack 消息……），输出是一个（或多个）可检索的索引。它的典型步骤如下：

1. Parsing 文档解析：把二进制/富文本变成纯文本 + 结构化元数据。难点在于表格、公式、图片、页眉页脚的还原。工具栈包括 Unstructured.io、Markitdown、Docling、LlamaParse 等。 2. Chunking 文本切块：把长文档切成 200–1000 tokens 的小块。常见策略有固定窗口、重叠窗口、递归切分、语义切分。每种策略都会在"召回率"和"上下文连贯性"之间做权衡。 3. Embedding 嵌入：用 embedding model 把每块文本映射成 $d$ 维向量（典型 $d \in \{384, 768, 1024, 3072\}$）。这是 RAG 检索效果的"地基"，会在第 2 章详述。 4. Indexing 索引构建：把向量连同元数据写入向量数据库。FAISS（本地）、Pinecone / Weaviate / Qdrant（云端）是典型选型。索引结构通常使用 HNSW 或 IVF+PQ 以获得亚线性检索复杂度。

注意：离线流水线不是"跑一次就完"的。在生产环境里，它需要应对增量更新——文档会增、删、改；向量模型会升级；切块策略会迭代。因此这条流水线必须幂等、可重放、有版本。这是初学者最容易忽视的工程债。

1.3.2 在线推理流水线（Online Inference Pipeline）

这条流水线每次用户请求都会跑一次。它包括：

1. Query Understanding 查询理解：把用户原始 query 做改写、扩展、HyDE（假设文档嵌入）等操作。这是为了弥合"用户的自然语言"和"文档里的技术语言"之间的语义鸿沟。 2. Retrieval 检索：用 query embedding 在向量库中召回 top-$k$ 个候选块（典型 $k = 20 \sim 100$）。检索质量决定了 RAG 系统回答质量的上界。 3. Reranking 重排序：用一个 cross-encoder 模型对候选块精排，取 top-$n$（典型 $n = 3 \sim 8$）。这一步能把准确率从 60% 拉到 80%，是"高级 RAG"的标志。 4. Generation 生成：把 top-$n$ 块拼进 prompt，让 LLM 基于这些上下文回答。Prompt 模板的质量（"基于以下资料回答，若资料不足请说明"）会显著影响最终效果。 5. Post-processing 后处理：格式化、引用、敏感词过滤、置信度评估。

这条流水线的每一步都对应着本书后续章节：

• 第 2 章：Embedding
• 第 3 章：Chunking 策略
• 第 4 章：向量数据库
• 第 5 章：检索与重排序
• 第 6 章：生成 Prompt 工程
• 第 7 章：评估

记住这个全景图，是后续学习任何一个组件时保持"全局观"的必要条件。

1.3.3 为什么是"双流水线"而不是"单管道"

这种解耦不是工程审美，而是被以下几个物理事实逼出来的：

• **吞吐量不匹配**：文档更新是分钟级到天级的流量；用户查询是毫秒级的流量。把它们塞进同一个处理循环会让索引一致性与查询延迟互相打架。
• **失败域隔离**：离线索引重建失败，不应该影响在线查询；在线查询超时，不应该触发索引重建。解耦让两个域的 SLO 可以独立设定。
• **资源池异构**：离线需要 GPU 做 embedding 批处理，在线需要 CPU + 低延迟网络。混合部署会因为资源争抢导致雪崩。
• **可替换性**：今天的 embedding 模型是 bge-large，明天可能是 text-embedding-3-large。解耦让你能灰度切换索引而不影响在线服务。

这套架构的副作用是引入了索引一致性（index consistency）问题——离线更新期间，在线读到的可能是新旧混合的视图。生产系统需要明确选型：最终一致性 vs. 强一致性（双写 + 版本号）。这是一个属于分布式系统而非 NLP 的问题，但在 RAG 工程里它每天都会跳出来咬人。

1.4 范式演进史：从 Lewis 2020 到 Modular RAG

把 RAG 描述成"ChatGPT 之后的发明"是常见的时代误植。事实上，RAG 的学术血统可以追溯到 2020 年——比 ChatGPT 早 2 年零 2 个月。

1.4.1 起点：Lewis et al. 2020

Patrick Lewis 等人在 2020 年 5 月的 NeurIPS 论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中首次把 RAG 范式形式化。原始论文的架构简单得令人发指：

• **检索器**：DPR（Dense Passage Retrieval），一个 BERT-based 的 dual-encoder，先在 Wikipedia 上预训练
• **生成器**：BART-large，一个 encoder-decoder seq2seq
• **训练方式**：固定检索器，端到端微调生成器
• **任务**：Knowledge-intensive tasks，如 Natural Questions、TriviaQA、FEVER

论文中最具洞察力的一句话是："*Parametric memory and non-parametric memory can be combined in a principled way to improve knowledge-intensive tasks.*"——把"参数化记忆 vs 非参数化记忆"作为对立统一的范畴，奠定了 RAG 的理论基础。

但 2020 年的 RAG 是学术原型的级别：DPR 检索速度慢、BART 生成质量差、整个系统没有可观测性。它证明了范式可行，但没有证明范式可工程化。

1.4.2 密集检索的进化：REALM、Atlas、Retro

2020–2022 年是密集检索模型（dense retrieval）的研究爆发期，几个里程碑工作把 RAG 从"框架"推进到"端到端系统"：

• **REALM**（Guu et al. 2020）：首次实现**检索器与生成器的联合预训练**。它把检索过程嵌入到 MLM 的前向计算中，使得检索器能从生成任务的监督信号里学到更对齐的表示。
• **Atlas**（Izacard et al. 2022）：用 Contriever + Fusion-in-Decoder 把"小模型 + 大检索"的范式推到极限——在 Natural Questions 上，Atlas（330M 参数 + 32M 检索库）击败了 PaLM（540B 参数）。这是 RAG 历史上最戏剧性的"以小博大"。
• **Retro**（Borgeaud et al. 2022，DeepMind）：把检索做进了模型**前向计算本身**。每个 attention 层都可以 attend 到一个外部键值缓存。这是 RAG 与"原生长上下文"路线的一次正面交锋。

这些工作的共同特征是：检索器与生成器深度耦合，整个系统在实验室环境里达到了 SOTA，但训练代价巨大、推理延迟高、无法独立迭代任意一个组件。它们证明了"理论上 RAG 可以做到极致"，但没有给出"工程上可以迭代 RAG"的答案。

1.4.3 工程化浪潮：2023 年起 ChatGPT 触发的范式落地

2022 年 11 月 ChatGPT 发布，2023 年 3 月 GPT-4 发布。这两件事把 RAG 从学术议题推到了工业议事日程：

• **LangChain / LlamaIndex**（