RAG 原始论文精读：我为什么把它看成外部知识系统的起点

我前面已经写过一篇偏系统综述的 RAG 文章，也把 Self-RAG 这种后续工作放进了 Agent 学习主线里。但我后来越来越觉得，如果只看这些“后来者”，很容易把 RAG 理解成一套已经被工程常识消化完的东西，比如：

• 向量库检索
• Top-K 召回
• 拼接上下文
• 让模型回答

这样理解不能说错，但会让我看不见原始论文真正值钱的地方。

所以这次我又回去重新读了 Lewis 等人的 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。我想弄清楚的不是“RAG 怎么做”，而是下面这几个更根上的问题：

• 在这篇论文出现之前，大家默认是怎么想知识增强这件事的；
• 原始 RAG 到底改写了哪条架构假设；
• 这篇论文真正提出的是“外挂知识库”，还是一种新的知识访问范式；
• 为什么它后来会一路演化到今天的 Advanced RAG、Modular RAG 和 Agentic RAG。

我这篇精读会尽量按这个方向拆。对我来说，它不是一篇“经典论文打卡”，而更像是一篇让我重新校准工程直觉的基础文献。因为我越做 Agent 越能感觉到，很多今天看起来顺理成章的设计，其实都能往回追到这篇论文改掉的那个前提：模型不应该只靠参数记忆完成知识密集任务。

一、我先抓住这篇论文真正要解决的问题#

我第一次认真读原始 RAG 论文时，最先冒出来的一个感受是：它讨论的重点，其实不是“生成”，而是“知识怎么被访问”。

如果把问题说得更直接一点，原始论文真正盯住的是这个矛盾：

大模型参数里确实压了很多知识，但这些知识静态、难更新、难追溯，也不适合精确访问；而真实世界里的知识却是动态变化、可版本化、可外置管理的。

这也是我觉得这篇论文特别重要的原因。它不是在做一次小优化，而是在改软件系统对“知识属于哪里”的默认理解。

以前的常见直觉是：

知识主要在模型参数里
→ 模型越大，知道得越多
→ 任务表现取决于参数里记住了多少

原始 RAG 其实把它改成了另一条路：

知识不必都在参数里
→ 参数负责通用语言能力
→ 外部索引负责知识访问
→ 生成过程可以显式读取外部证据

我会把这件事理解成一种非常关键的职责重分配。

在这个重分配里：

• 参数记忆不再独自承担知识存储；
• 外部非参数记忆开始进入主舞台；
• 生成系统不再只是在“想答案”，而是在“访问知识并组织答案”。

这也是为什么我现在回头看这篇论文，会觉得它和今天的 Agent 关系比很多人想得更近。因为 Agent 最核心的能力之一，本来就不是“知道所有事”，而是“知道什么时候该去外部环境拿信息”。

二、我怎么理解论文里的 parametric memory 和 non-parametric memory#

原始 RAG 论文最经典的一层表达，是把知识分成两类：

• parametric memory
• non-parametric memory

这两个词现在大家都很熟了，但我第一次读的时候，其实没有立刻体会到它的分量。后来我才慢慢意识到，这个划分不是术语装饰，而是整篇论文真正的结构骨架。

2.1 为什么我要特别重视 parametric memory#

所谓 parametric memory，就是模型参数里已经学进去的知识。

这类知识的优点很明显：

• 访问快
• 不需要外部查询
• 可以和语言生成天然耦合

但它的问题也同样明显：

• 更新成本高
• 无法精确知道知识来自哪里
• 对长尾事实和动态事实不稳定
• 很难做版本管理和权限控制

我对这一层最强烈的工程联想其实很简单：把所有知识都塞进参数，某种程度上就像把所有业务规则都编译进二进制。能跑，但一旦知识频繁变化、需要追溯、需要隔离、需要审计，问题就会很快暴露。

2.2 为什么 non-parametric memory 会变成今天这么重要#

论文里的 non-parametric memory，本质上就是外部文档索引。原始论文使用的是 dense vector index 上的 Wikipedia 文档。

这一层的关键价值在我看来有四个：

• 可以更新
• 可以扩展
• 可以显式检索
• 可以带来源

我现在看很多生产系统时，都会天然把这层当成默认基础设施。可如果回到 2020 年那个时间点，这件事并没有那么理所当然。原始 RAG 真正做的，是把“外部知识库”从一个外围组件，提升成了生成系统的一部分。

这也是我特别愿意把它称为“外部知识系统的起点”的原因。它不是单纯给模型外挂一个检索器，而是让“访问外部知识”进入了主推理链路。

三、这篇论文真正提出了什么架构#

如果只说一句话，我会这样概括原始 RAG 的架构：

它把“检索到的文档”变成了生成模型条件分布的一部分。

这句话听起来有点学术，但翻成工程语言，其实就是：

用户问题
→ 检索外部文档
→ 用文档约束生成
→ 输出答案

这件事最值钱的地方不在流程图，而在它改变了生成系统的输入定义。

以前的输入更像是：

query → generator

原始 RAG 之后，输入变成了：

query + retrieved documents → generator

别小看这一步。它意味着生成器不再只依赖内部记忆，而开始把外部知识读取当成标准能力。

我读到这里时，脑子里会自动把它映射成后面很多工程演化：

• 后来的企业知识库问答
• 多源文档增强
• 引用生成
• 基于证据的回答
• Agent 检索决策

这些东西看起来很远，实际上都能从这一步推出来。

四、我怎么理解论文里的两种 RAG 形式#

原始论文里有一个很多人会提到、但不一定真的咀嚼过的点：它提出了两种生成方式。

• RAG-Sequence
• RAG-Token

我第一次读这部分时，感觉它像是论文里一个常规 ablation 设计；但后来回头看，我觉得这里其实已经埋下了后续很多系统设计分歧。

4.1 RAG-Sequence：我把它看成“整段回答共享同一批证据”#

RAG-Sequence 的直觉很清楚：先检索出一组文档，然后在整个生成序列中使用同一批检索结果。

这个模式的工程味很重，因为它更像我们后来最熟悉的那条链：

检索一次
→ 选出 Top-K
→ 拼上下文
→ 整段回答都基于这份上下文生成

它的优势是：

• 实现简单
• 路径稳定
• 容易调试
• 成本相对可控

我为什么说它重要？因为今天大量生产 RAG，本质上都还是这条思路的后裔。包括很多看起来更复杂的系统，只要在一次生成里没有动态变更证据集合，它都更接近 RAG-Sequence 这一路。

4.2 RAG-Token：我把它看成“生成过程里允许证据动态切换”#

RAG-Token 更激进。它允许每个 token 的生成条件依赖不同的检索文档。

如果翻成更直白的话，就是：

模型在生成过程中，不必始终盯着同一组证据，它可以随生成位置变化而重新依赖不同外部信息。

我读这部分时最大的感受不是“它更强”，而是“它已经开始逼近一种动态知识访问过程”。

这对我很有启发。因为它说明原始论文其实并不满足于“先查一把，再一直写”，而是已经在探索一种更细粒度的知识对齐方式。

当然，从工程角度看，它也更贵、更复杂、更难控。

所以我现在会把这两种形式理解成一条后来不断反复出现的分岔：

• 一条路追求稳定、简单、易部署
• 一条路追求更细粒度、更动态、更贴近真实知识访问

后来的 Agentic RAG、按需检索、动态 retrieval decision，其实都能看出一点 RAG-Token 这条路的影子。

五、为什么这篇论文在当时会很重要#

如果把时间拉回原始论文出来的那个阶段，我觉得它的重要性至少有三层。

5.1 它把“知识增强”从 prompt 技巧升级成了模型架构问题#

今天大家一提 RAG，会自然想到“检索增强生成”。但在那个时间点，这个问题还没有被工程界完全吃透。

原始论文最重要的一点，就是它没有把外部知识读取仅仅当作 prompt 拼接技巧，而是把它建模成生成架构的一部分。

这一点对我触动很大。因为它意味着：

• 外部知识不是附属品
• 检索不是前处理小动作
• 生成系统需要显式面对知识访问

也正因为如此，它后面才可能一路发展出 rerank、query rewrite、citation、retrieval evaluator 这些更完整的知识链路。

5.2 它给了“知识可更新”一个更像工程系统的答案#

模型参数更新太重，这是很多人都知道的事。但“知道这个问题存在”和“给出一条可以落地的路径”不是一回事。

原始 RAG 给出的答案其实很朴素：

不要只试图让模型记更多，而要让它学会访问一个可以更新的外部存储。

这在今天看起来甚至有点常识，但正是这条路，让后来的企业私有知识库、文档问答、基于版本文档的回答、知识审计这些能力有了更自然的落点。

5.3 它把来源问题带进了生成讨论#

我很在意这篇论文还有一个原因：它让“来源”这件事进入了生成系统的核心叙事。

只靠参数记忆时，我很难知道模型到底从哪里“知道”一个事实。

但一旦生成受检索文档约束，至少理论上我就可以开始问：

• 你是基于哪篇文档回答的；
• 这份文档是不是最新版本；
• 这个证据是不是可信；
• 如果回答错了，是检索错了，还是生成错了。

这一层追溯能力，对生产系统来说实在太关键了。它不只是用户体验问题，而是治理问题、审计问题、风控问题。

六、我读这篇论文时最在意的，不是效果提升，而是职责划分#

很多人读原始 RAG，会先看实验指标。我当然也会看，但我后来越来越觉得，这篇论文最值钱的地方不是“比 baseline 提升了多少”，而是它重新划了职责边界。

在我的理解里，RAG 把系统分成了两层能力：

6.1 参数层负责通用表达与推理骨架#

模型参数仍然非常重要。它负责：

• 语言建模
• 生成组织
• 跨证据整合
• 在上下文中推理

所以原始 RAG 并不是在弱化模型，而是在把模型从“全知记忆体”这个不现实的角色里解放出来。

6.2 外部索引层负责知识供给#

外部索引负责：

• 存储知识
• 更新知识
• 定位知识
• 给出可访问证据

我特别喜欢这种职责拆法。因为一旦职责清楚，后面的工程优化也就跟着清楚：

• 检索差了，先看索引和召回；
• 回答偏了，先看证据与生成对齐；
• 文档过期了，改知识源，不一定非要训模型；
• 引用错了，先追证据链而不是怪“模型太笨”。

这其实就是我今天做系统时很在意的一种可分诊性。复杂系统最怕的是所有问题都糊成一团，而这篇论文给了一个很好的拆法。

七、为什么我觉得今天很多人其实低估了原始 RAG#

我越看后来这些 RAG 工程，越觉得原始 RAG 有时候反而被低估了。

被低估不是因为它不经典，而是因为它太经典了。经典到大家很容易只记住它的“表层形式”，却忘了它当初改掉了什么。

7.1 大家容易把它误读成“向量检索 + 拼 prompt”#

这是最常见的误读。

如果只从今天的工程模版倒推回去，原始 RAG 很容易被看成：

检索
→ 拼接
→ 回答

可这只是实现层。它真正改掉的是“知识必须主要藏在参数里”这个前提。

7.2 大家容易忽略它对 Agent 的先导意义#

我现在越来越愿意把原始 RAG 看成 Agent 世界的一块底板。因为它最早把“从外部环境取知识”这件事放进了核心生成链路。

Agent 为什么离不开 RAG？

因为 Agent 的很多任务，本来就不该假设模型已经知道答案。它需要：

• 查文档
• 读代码
• 看日志
• 找配置
• 对比来源
• 基于外部事实更新行动

从这个角度看，RAG 不是 Agent 的附加组件，而是 Agent 与真实知识环境连接的一种基本方式。

7.3 大家容易忽略它带来的治理价值#

原始 RAG 最后一路能走到生产，不是因为“检索”听起来很聪明，而是因为它天然更容易被治理。

至少相比纯参数式回答，它更容易支持：

• 可更新知识源
• 证据链
• 引用
• 文档版本
• 访问权限
• 失败定位

这些东西，在论文里可能不是最热闹的表述，但在工程里非常值钱。

八、这篇论文怎样一路影响到今天的 RAG 演化#

对我来说，精读的意义从来都不是“知道原文写了什么”，而是看见它怎样长成今天的系统。

如果我把原始 RAG 往后接，我会看到这样一条线：

原始 RAG
→ Naive RAG
→ 检索质量问题暴露
→ Advanced RAG
→ 模块化治理需求上升
→ Modular RAG
→ 动态决策与多轮检索
→ Agentic RAG / Self-RAG / CRAG

8.1 Naive RAG 继承了它的基本范式#

今天最常见的企业知识库问答，其实就是把原始 RAG 的核心思想工程模板化了：

• 文档切分
• embedding
• 向量索引
• Top-K 召回
• 拼上下文
• 生成回答

这是原始论文最直接的产业后果。

8.2 Advanced RAG 在修它暴露出来的检索瓶颈#

原始 RAG 一旦真正落地，问题很快就会变得具体：

• query 太短
• 召回不准
• chunk 不合理
• 文档太长
• 多跳问题答不好

于是就有了后面的：

• query rewrite
• HyDE
• rerank
• hybrid retrieval
• parent-child chunk
• contextual compression

这些方法本质上都不是背叛原始 RAG，而是在补它工程化之后暴露出来的现实缺口。

8.3 Agentic RAG 在继续推进“动态知识访问”#

如果说 RAG-Sequence 更像静态证据绑定，那今天很多 Agentic RAG 就是在继续往动态知识访问推进。

系统开始问：

• 需不需要检索；
• 该检索哪个源；
• 证据够不够；
• 要不要再查一轮；
• 当前回答是否忠于证据。

我会觉得，这些东西在精神上和原始论文是一脉相承的。只是今天我们把它做得更显式、更模块化，也更贴近真实任务链路。

九、我把这篇论文带回自己系统里，会得到哪些判断#

如果我不复述论文细节，只说它对我自己的工程判断带来了什么，我会留下这几条。

9.1 不要把知识问题全推给模型参数#

这可能是最直接的一条。

只要知识是：

• 动态变化的
• 私有的
• 需要可追溯的
• 需要按权限隔离的

我就不会再天然指望模型参数单独解决它。

9.2 知识访问应该被设计成系统能力，而不是临时补丁#

很多项目里，检索层像一个“后来补上的增强器”。

但原始 RAG 反过来提醒我，外部知识访问应该从一开始就被当成架构能力去设计。否则后面一旦要加引用、加审计、加版本、加评测，就会很痛。

9.3 检索不是目的，证据约束才是目的#

我现在对 RAG 的一个核心理解是：

检索本身并不神奇，真正有价值的是它让生成受到了外部证据约束。

这也会影响我后面的实现优先级。比起一开始就追很复杂的检索花样，我更关心：

• 证据是不是相关；
• 回答是不是忠于证据；
• 引用是不是能落到具体片段；
• 检索失败时系统能不能承认失败。

9.4 RAG 的问题很多都不是生成问题，而是知识链路问题#

这篇论文给我的另一层提醒是，RAG 一旦进工程，很多问题其实出在：

• 数据源
• chunk
• 索引
• query
• rerank
• 证据选择

而不只是“prompt 不够好”。

这会让我在排障和优化时更克制，不会动不动就先去怪模型。

十、结语：我为什么还愿意反复读这篇老论文#

对我来说，原始 RAG 论文最值钱的地方，不是它提供了一套今天依然原样可抄的系统实现，而是它很早就改掉了一个后来被反复证明有问题的前提：

模型不应该被假设成知识的唯一宿主。

我很喜欢这种改变系统边界的论文。因为它们真正留下来的，不是某个局部技巧，而是一种新的架构方向。

如果要把这篇论文留成一句我会长期带着走的话，那大概就是：

RAG 的本质不是给模型外挂检索，而是把外部知识访问正式纳入生成系统。

也正因为如此，我现在再看 RAG，不会只把它当成“知识库问答组件”，而更愿意把它看成 Agent 外部知识系统的起点。后面的 Advanced RAG、Modular RAG、Self-RAG、CRAG、GraphRAG，其实都只是沿着这条线继续把“知识访问”做得更像一个真正的系统。

这也是我为什么觉得，原始 RAG 值得单独精读。它真正给我的，不只是一个经典方法名，而是一种更清晰的工程拆法：参数负责能力，外部系统负责知识，生成负责把两者接起来。

参考#

1. Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
2. Retrieval-Augmented Generation for Large Language Models: A Survey
3. Retrieval Augmented Generation (RAG) and Beyond
4. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection