从 RAG 技术到 RAG 思想

引言#

到了 2026 年，RAG 是一个略显过时的技术概念。

而三年前，它还被视作让大模型应用真正落地的默认工程方案。

大模型基础能力和工程方案的快速进化，使得如果你没有及时学习一个概念，拖了一段时间后，似乎就没必要学习这个概念了。

我就是那个拖了很长一段时间才去学习的人。

现在学习 RAG，不是为了了解详细的 RAG 流程和原理，而是从现在的视角回望，RAG 为什么会出现，它解决了什么问题，它给我们留下了什么。

这篇文章我计划从三个维度来讲我理解中的 RAG，历史维度、工程维度和思想维度。

一句话来概括 RAG：在恰当的时刻，把恰当的信息，放到恰当的位置

一、两条技术线的汇合：RAG 的历史前提#

RAG 并不是某一个单点技术的突然发明。

如果把它放回大模型技术的发展史中看，它更像是两条技术线自然汇合的结果。一条线是大模型本身：模型越来越擅长理解语言、遵循指令，并基于上下文生成结果。另一条线是知识管理与信息检索：自然语言越来越能够被表示、比较、召回，并作为外部知识被系统化管理。

前者让机器“会生成”，后者让机器“会查找”。 RAG 正是在这两种能力都逐渐成熟之后出现的。

1.1 生成能力线：Transformer 到 GPT-3#

要理解 RAG 为什么会出现，首先要看大模型生成能力的变化。

早期的自然语言处理系统往往围绕具体任务构建。机器翻译、文本分类、问答、摘要，通常需要针对不同任务设计不同模型或训练流程。模型可以完成任务，但很难被自然语言灵活调度。

Transformer 改变了这一点。

它通过自注意力机制，让模型能够在更大范围内捕捉文本中的依赖关系，也让大规模并行训练成为可能。此后，语言模型不再只是处理局部上下文，而是能够在更长文本中建模词语、句子和段落之间的关系。

GPT 系列进一步把这种能力推向了“生成”。

通过大规模预训练，模型先在海量文本中学习语言规律、知识模式和表达方式；再通过 prompt，把原本固定的任务转化为自然语言输入。于是，模型不再只是完成某个预设任务，而是可以根据用户给出的指令、示例和背景材料临时组织答案。

到了 GPT-3，一个关键变化变得更加清楚：模型开始表现出较强的上下文学习能力。

所谓上下文学习，指的是模型不一定需要修改参数，也可以仅仅通过输入中的示例、资料和指令来完成新的任务。用户把信息放进上下文，模型就能在当前对话中临时使用这些信息。

如果把 GPT-1 到 GPT-3 放在一起看，这个变化会更直观：模型规模扩大以后，zero-shot 和 few-shot 场景下的任务表现开始明显拉开。尤其是 GPT-3，它让“把任务说明和少量示例直接放进上下文”变成了一种可用的交互方式。

这对 RAG 非常关键。

因为 RAG 并不要求每次都重新训练模型。它的基本思路是：当模型需要某些外部知识时，系统先把这些知识取回来，再放进模型当前可见的上下文中，让模型基于这些信息生成答案。

换句话说，如果大模型只能依赖参数内部的知识，而不能有效利用输入中的临时信息，那么 RAG 就很难成立。正是因为模型已经具备了“基于上下文生成”的能力，外部检索到的知识才有可能在不改动模型参数的情况下，参与当前任务。

GPT-3 之前的大模型发展，为 RAG 提供了生成侧的前提：

模型不仅要会说，还要能读懂当前给它的材料，并基于这些材料组织答案。

1.2 检索 / 知识管理线：Word2Vec 到向量数据库#

另一条技术线，则来自语义表示、信息检索和知识管理的发展。

传统搜索主要依赖关键词匹配。用户输入一个查询，系统根据词项重合、倒排索引和相关性排序找到文档。这种方式在很多场景下非常有效，但它也有明显局限：如果用户使用的词和文档中的词不一致，即使语义相关，系统也可能难以召回。

RAG 面对的通常不是简单的关键词匹配。

用户问的是一个自然语言问题，知识库里存放的是文档、段落、代码、笔记或网页。系统要做的，是找到语义上真正相关的内容，而不只是包含同一个词的文本。

这就需要文本表示方式的变化。

Word2Vec 的重要意义在于，它让“语义可以被表示为向量空间中的关系”这件事变得直观。词不再只是离散符号，而可以被映射到连续向量空间中。语义相近的词，在向量空间中的位置也往往更接近。

当然，现代 RAG 并不是直接建立在 Word2Vec 之上。真正支撑 RAG 的，是后来的句向量、文档向量、embedding model、密集检索和向量数据库。但如果从思想脉络上看，Word2Vec 提供了一个重要起点：文本可以被向量化，语义相似性可以在一定程度上转化为空间距离。

这一思想后来不断扩展。

从词向量到句向量，从句向量到段落向量，再到面向检索任务训练的 embedding model，文本逐渐变成了可以被机器比较和召回的语义对象。用户的问题可以被编码成一个向量，知识库中的文档片段也可以被编码成向量。两者之间的相关性，就可以通过向量相似度来衡量。

向量数据库则进一步把这种能力工程化。

它负责存储大量文本片段的向量表示，并支持高效的近邻搜索。这样，当用户提出一个问题时，系统就可以先把问题向量化，再从向量数据库中召回语义上最接近的文档片段。

这就是传统 RAG 检索侧的基础。

不过，向量数据库不是普通的存储组件。它背后代表的是一种知识管理方式的变化：外部知识从文件、网页或数据库记录，变成了被切分、编码、索引、随时准备被模型调用的材料。

知识管理线为 RAG 提供了检索侧的前提：

系统不仅要保存知识，还要能在具体任务发生时，把相关知识找出来。

1.3 汇合点：为什么 RAG 在那个阶段成为自然方案#

当这两条线分别发展到一定阶段，RAG 的出现就变得非常自然。

一方面，大模型已经具备了较强的上下文理解和生成能力。它能够阅读用户问题、理解指令、吸收临时提供的背景材料，并基于这些材料组织回答。

另一方面，语义检索和向量数据库已经让外部知识变得可以被机器召回。文档可以被切分成片段，片段可以被编码成向量，用户问题也可以被编码成向量，系统可以通过相似度搜索找到相关内容。

此时，大模型自身又暴露出一个无法忽视的问题：它的参数知识并不等于可靠、实时、可追溯的知识库。

模型训练完成之后，新知识不会自动进入参数；企业内部文档、个人笔记、项目代码等私有信息，也不会天然存在于模型内部。即使某些知识曾经出现在训练数据中，模型也未必能在具体任务中稳定调用。更重要的是，当模型缺少依据时，它仍然可能生成一个流畅但错误的答案。

于是，一个自然的系统方案出现了：

不要试图把所有知识都压缩进模型参数，而是在模型需要回答具体问题时，从外部知识源中检索相关信息，把它放入当前上下文，再让模型基于这些信息生成答案。

这就是 RAG。

它把两种原本相对独立的能力连接了起来： 检索系统负责从外部世界找到相关知识，大模型负责基于这些知识完成理解、组织和表达。

因此，从历史上看，RAG 是大模型技术线与知识管理线的汇合；从机制上看，它是生成能力与检索能力的结合。

如果说大模型的发展解决了“如何生成”的问题，语义检索的发展解决了“如何找到相关知识”的问题，那么 RAG 试图解决的就是两者之间的连接问题：

知识如何从外部系统进入模型当前的生成过程？

这个问题，也正是理解传统 RAG 架构的入口。

二、传统 RAG 架构：让外部知识进入生成系统#

这一章先回到传统 RAG 的工程形态，看看外部知识具体是如何进入生成系统的。最基础的 RAG 可以拆成三个动作：检索相关信息，增强当前上下文，再由模型基于增强后的上下文生成答案。

一个最小化的 RAG：羊肉串问题#

假设你问一个大模型："我想买十串羊肉串，要花多少钱？"

大模型不知道你家楼下烧烤摊的价格。它的参数里可能有"羊肉串"这个词，但没有"你家楼下烧烤摊的羊肉串卖 2 元一串"这个具体知识。所以它只能猜："一般来说，羊肉串的价格在 3 到 5 元之间，十串大概 30 到 50 元。"——这是一个看似合理、但实际上可能完全错误的回答。

解决办法很简单：你不需要重新训练模型，只需要在 prompt 里加一句话，"已知一串羊肉串 2 元。"然后再问"十串多少钱？"模型立刻就能准确回答："20 元。"

这就是一个最小化的 RAG。只不过这里的检索（Retrieval）是由你的人脑完成的——你从烧烤摊的价目表上看到了价格；增强（Augmentation）是把这条信息写进 prompt 里；生成（Generation）是模型基于 prompt 算出总价。RAG 的三个核心环节，在这个极简场景里全部出现了，只是检索环节由人完成。

RAG 的诞生：从论文到工程#

2020 年，Facebook AI Research 的 Lewis 等人在 NeurIPS 上发表了一篇论文——Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。这篇论文首次系统性地提出了 RAG 这个框架，把预训练的稠密检索器（Dense Passage Retrieval）和预训练的序列到序列生成器（BART）结合起来，做端到端的联合微调。

与此前"先检索、再拼接进 prompt"的简单做法不同，这篇论文的关键创新在于把检索到的文档作为生成模型的条件输入，并在生成时对不同检索文档进行联合建模。检索结果不是简单地被贴在问题前面，而是参与到生成过程之中。这意味着模型在生成答案时，可以基于外部文档提供的证据进行表达。

实验结果令人印象深刻：在开放域问答（Natural Questions、TriviaQA）和事实验证（FEVER）等知识密集型任务上，RAG 不仅超越了纯参数化的生成模型，也胜过了"检索+拼接"的两阶段基线。这篇论文的价值不只是提出了一种新模型，它证明了一件事：检索和生成可以作为一个统一的系统来训练，而不是两个割裂的模块。

此后三年，RAG 从学术研究迅速扩散到工业界。LangChain 的 Retrieval 模板、LlamaIndex 的索引框架，以及各类面向企业知识库和文档问答的应用，都延续了检索增强生成的工程范式。RAG 不再只是一个模型架构，而变成了一套可复用的系统设计模式。

RAG 的两面：索引侧与检索侧#

一个 RAG 系统通常可以拆成两侧：索引侧负责在离线阶段处理知识，检索侧负责在在线阶段响应问题。两侧解耦，系统才能分别优化知识准备和问答生成。

从技术角度看，索引侧（Indexing） 负责离线数据准备：原始文档经过清洗、分块、嵌入，最终变成向量数据库中的可检索条目。这是一个"写"的过程，关注的是如何把知识以机器能理解的方式组织起来。

检索侧（Retrieval / Query） 负责在线问答生成：接收用户问题，执行查询处理、向量检索、结果重排序，将检索内容与用户问题组装成增强 prompt，最终交由 LLM 生成答案。这是一个"读"的过程，关注的是如何在恰当的时机找到并呈现最相关的信息。

这种划分并非只是为了概念清晰——在工程实践中，两侧的技术栈、优化目标和团队分工往往截然不同。索引侧关心的是嵌入质量、分块策略和存储效率；检索侧关心的是查询改写、召回率和生成效果。理解了这一分野，才能有的放矢地调优一个 RAG 系统。

索引侧：从原始文档到可检索的向量#

① 知识库与索引：价格信息存在哪里？

羊肉串的价格不能凭空出现，它必须被记录在某个地方——一张价目表、一份菜单、一个数据库。在 RAG 系统中，这叫做知识库。真实场景中，知识库可能是产品手册、技术文档、论文库、法规条文，或者企业的内部资料。

但机器不能直接"阅读"原始文档。一篇 PDF 菜单可能包含页眉页脚、排版噪音、扫描图像。所以首先需要做数据清洗，去掉无用信息，保留有效内容。然后要做文档分块（Chunking），把长篇文档切成小段——比如"羊肉串 2 元/串"就是一个独立的 chunk。接下来，每个 chunk 要通过嵌入模型转换成向量，存入向量数据库。这样，"羊肉串 2 元/串"就从一个字符串变成了高维空间中的一个点。

检索侧：从用户问题到生成答案#

② 检索：怎么找到正确的 chunk？

用户问"十串羊肉串多少钱"，系统需要在向量数据库中找到最相关的 chunk。这个过程叫检索。

但用户不会总是按标准格式提问。有人可能说"来十个串儿带劲儿的那种多少钱"，有人可能问"烤羊肉串十串价格"。这时候需要查询处理——系统会改写用户的查询，用更标准、更丰富的表达去匹配知识库，提升召回正确 chunk 的概率。

检索本身也有多种策略。最基本的向量检索是把用户问题也变成向量，找空间中距离最近的 chunk。但纯向量检索可能漏掉关键词精确匹配的场景（比如"2 元"这个具体数字）。所以成熟的系统会采用混合检索——同时做向量检索和关键词检索，再把两路结果融合。

③ 重排序：找到一堆结果，哪个最准？

检索通常会召回几十个候选 chunk，但它们的相关性参差不齐。有些可能完全无关（比如"烤茄子 8 元"），有些部分相关。这时候需要重排序（Reranking）——用一个更精确的模型对候选结果二次打分，把"羊肉串 2 元/串"排在最前面，把无关内容过滤掉。

④ 增强与生成：把检索结果喂给模型

找到了"羊肉串 2 元/串"这个 chunk，接下来要把它和用户的问题组合成一个完整的 prompt，这个过程叫上下文组装。典型的模板结构是：角色定义 + 已知信息（检索结果）+ 用户问题 + 约束条件。然后 LLM 基于这个增强后的 prompt 生成答案。

不过，检索到的内容未必都相关，全部塞进 prompt 会浪费上下文窗口。所以需要上下文压缩——识别并保留关键信息，去掉冗余。此外，系统还可以加入Few-shot 示例来引导模型输出格式。

⑤ 评估：回答得对吗？

系统上线后，怎么知道它回答得好不好？需要一套评估体系。比如忠实度（Faithfulness）——答案是否基于检索到的内容？有没有编造？上下文精确率（Context Precision）——检索到的 chunk 是否都相关？答案相关性（Answer Relevancy）——生成的答案是否切题？

这些指标帮助开发者持续调优——换更好的嵌入模型、调整分块大小、优化查询改写策略。

把以上环节串联起来，就是一个完整的 RAG 系统数据流：

上图展示了一个现代 RAG 系统的核心链路。从用户查询输入开始，系统通常会并行或串行地执行查询改写、向量检索与关键词检索，随后通过重排序模块对召回结果进行精排，再由上下文构建模块将检索结果组织成适合大模型理解的格式，最终交由 LLM 生成带引用的回答。

这个流程并非一成不变——根据业务场景的不同，某些节点可以被裁剪、替换或增强。例如：

• 简单场景：用户查询 → 向量检索 → 上下文构建 → LLM 生成 → 输出
• 高精度场景：增加查询改写（HyDE）和重排序（Cross-Encoder）环节
• 混合检索场景：同时引入向量检索与关键词检索，结果融合后重排

到这里，传统 RAG 的组件链路已经比较清楚。但真正值得追问的是：这些组件为什么会不断演化？答案不只在检索算法里，也在大模型工程范式的变化里。RAG 后来的演进，本质上是外部信息进入模型上下文的方式不断被重新设计。

三、大模型工程范式演进：Prompt、Context 与 Harness#

上一章把传统 RAG 拆成了索引、检索、重排序、上下文构建和生成等组件。这个视角能解释 RAG 最基础的工作方式，但它仍然是静态的：像是在描述一条已经固定好的数据流水线。

如果只停留在组件层面，就很难解释 RAG 后来的演进。

随着大模型应用变得复杂，RAG 面对的问题重心也在不断上移。

最初，人们关心的是如何把检索到的内容放进 prompt，让模型能够读到并依据这些材料回答问题。这个阶段对应的是 Prompt Engineering。

随后，人们逐渐意识到，问题不只是 prompt 怎么写，而是模型当前到底应该看到什么。检索结果并不会自动变成高质量上下文，相关性、完整性、冲突、噪声和结构都会影响最终回答。这个阶段对应的是 Context Engineering。

再往后，当大模型应用开始接入工具、记忆、工作流和多轮任务时，RAG 也不再只是一个固定的检索步骤。系统需要判断什么时候检索，检索哪里，是否继续检索，是否调用工具验证，以及是否把结果写回知识库。这个阶段对应的是 Harness Engineering。

因此，从 Prompt 到 Context，再到 Harness，RAG 的演进不是把几个工程技巧并列摆开，而是体现了大模型工程关注重心的递进：从提示词组织，到上下文构造，再到系统调度。

3.1 Prompt Engineering：从“检索到”到“放得对”#

在 Prompt Engineering 阶段，人们最关心的是如何通过提示词让模型给出更好的回答。

早期 RAG 也常常以这种方式出现。系统先从知识库中检索出几段相关文本，然后把它们和用户问题一起拼接进 prompt 中：

请根据以下资料回答问题。

资料：
...

问题：
...

这个过程看起来很简单，但它已经触及了 RAG 的第一个关键问题：信息被检索出来以后，还要放到模型能够理解和使用的位置。

同样一段检索结果，放在 prompt 中的不同位置，效果可能完全不同。它可以被当作背景资料，也可以被当作唯一依据；可以放在用户问题前，也可以放在用户问题后；可以原样放入，也可以先整理成要点、表格或引用片段。

如果 prompt 没有明确告诉模型如何使用这些材料，模型可能只是把它们当作普通上下文参考；如果 prompt 没有约束模型必须依据资料回答，模型仍然可能调用参数中的旧知识；如果 prompt 没有定义资料不足时的行为，模型也可能在证据不足时继续编造。

很多早期 RAG 问答失败都出在这里。系统明明找到了正确的段落，答案却仍然泛泛而谈，因为 prompt 只写了“参考以下资料”，没有告诉模型这些资料是唯一依据。另一种常见情况是，资料里有两段互相冲突的产品说明，一段来自 2022 年旧文档，一段来自 2024 年更新日志，如果 prompt 没有要求优先使用新来源，模型很可能把两段混在一起。

在 Prompt Engineering 的视角下，RAG 的核心问题是：

检索到的信息，如何以模型能够理解、遵守、引用和推理的方式进入 prompt？

这也是为什么许多早期 RAG 系统的瓶颈并不在向量数据库，而在 prompt 组织。资料明明召回了，但模型不知道哪些信息是事实依据，哪些信息只是背景补充；不知道应该优先使用哪一段，也不知道在资料不足时应该承认不知道。

在这个阶段，RAG 的工程重点是“放置”。

所谓放置，不是把文本插入 prompt 的某个位置就结束了，而是把外部知识转化为模型当前任务中的有效输入。它要求开发者设计指令、边界、引用格式和回答规则，让模型知道如何处理检索结果。

这个阶段的 RAG，重点在于把检索到的信息放到模型可读、可用、可约束的位置。

3.2 Context Engineering：从“放进去”到“准备好”#

随着 RAG 系统变得更复杂，人们逐渐意识到，prompt 写得再清楚，也无法弥补上下文材料本身的问题。模型当前到底应该看到什么，开始变成更关键的问题。

这就是 Context Engineering 的问题。

Prompt Engineering 关注“如何表达给模型”，Context Engineering 则关注“给模型准备什么工作材料”。在这个视角下，RAG 参与的是当前上下文的构造，而不是最后一步的文本拼接。

这个变化非常重要。

在传统想象中，RAG 的目标似乎是尽可能多地找回相关资料。只要检索结果足够多，模型就能从中找到答案。但在实际系统中，信息并不是越多越好。过多、重复、过期、冲突或质量低的信息，都会污染上下文。

模型虽然能处理长文本，但它并不一定能自动判断哪些材料最重要、哪些最可靠、哪些应该被忽略。上下文窗口越大，问题也不一定越简单，因为窗口中装入的信息越多，组织成本、筛选成本和冲突处理成本也越高。

因此，RAG 的重点开始从“召回”转向“选择与组织”。

一个很典型的例子是企业内部知识库问答。用户问：“我们现在的退款规则到底是按订单创建时间，还是按支付完成时间算？”检索系统可能召回客服 SOP、财务规则、一次历史事故复盘、两条产品更新公告。它们都相关，但不能直接塞给模型。SOP 可能过期，事故复盘只是个例，产品公告才是最新规则，财务规则又定义了例外条件。上下文工程要做的事情，是把这些材料整理成一个有优先级、有时间线、有来源的任务现场。

一个高质量的 RAG 上下文，至少需要满足几个条件。

首先，它要相关。检索结果必须服务于用户当前的问题，而不是只在关键词层面相似。用户问“为什么我的 RAG 回答很泛”，需要的通常不是 RAG 定义，而是 chunk 切分、召回质量、rerank、prompt 约束和答案评估等信息。

其次，它要充分。很多问题不能靠单个片段回答，而需要多个信息源之间的组合。系统需要判断当前检索结果是否覆盖了问题所需的关键维度，不能只找出几段看似相似的文本。

再次，它要干净。重复信息会浪费上下文窗口，低质量信息会干扰模型判断，互相矛盾的信息如果不加标注，可能导致模型生成混乱答案。

最后，它要可用。原始文档不一定适合直接放进上下文。很多时候，系统需要先对文档进行切分、摘要、去重、排序、结构化，甚至标注来源、时间和可信度，再交给模型使用。

所以，Context Engineering 阶段的 RAG，不再是简单的：

retrieve → stuff → generate

而更接近：

retrieve → select → clean → organize → inject → generate

这里的关键已经从“把信息放进去”变成了“为当前任务构造一个合适的知识现场”。

Advanced RAG 真正值得关注的地方也在这里。query rewrite、hybrid search、rerank、多路召回这些模块当然重要，但它们背后的工程重心已经变了：系统开始承认上下文本身需要被设计。

在这个阶段，RAG 的核心问题变成：

当前任务需要什么信息？这些信息应该如何被筛选、压缩、排序和组织，才能真正增强模型的判断？

Context Engineering 阶段的 RAG，目标是为模型当前任务准备恰当的信息，而不是简单提供更多的信息。

3.3 Harness Engineering：从“准备上下文”到“调度系统”#

当系统继续复杂化，RAG 又会进入第三个层面：Harness Engineering。

如果说 Prompt Engineering 关注一条 prompt，Context Engineering 关注一次上下文构造，那么 Harness Engineering 关注的是整个系统如何运行。

Harness 可以理解为模型外部的运行框架。它负责调度模型、检索、工具、记忆、工作流和外部环境，让它们在一个完整任务中协同工作。

在这个范式下，RAG 从一个固定步骤，变成了可以被动态调用的能力。

传统 RAG 往往默认每次用户提问都要检索：用户输入问题，系统检索知识库，把结果拼进上下文，然后模型回答。但在真实应用中，有些问题不需要检索，有些问题不能只检索一次，也有些问题要先澄清任务边界。

有些问题可以直接由模型回答。 有些问题必须检索企业文档。 有些问题需要查网页获取最新信息。 有些问题需要搜索代码仓库、阅读多个文件、再结合运行结果判断。 有些问题需要先向用户追问，明确任务边界后再检索。 有些问题则需要多轮检索、交叉验证、再生成答案。

这时，RAG 的关键问题就从“如何检索”变成了“何时检索、检索哪里、检索几次，以及检索之后做什么”。

比如在代码审查里，用户问：“这个 PR 会不会影响登录流程？”一个固定 RAG 管道可能只会拿 PR 描述去搜几段相关文档，然后给出笼统判断。更像 Harness 的做法会先读 diff，发现改动触及 auth/session；再查登录流程文档；接着搜索调用这个模块的页面；必要时运行相关测试；如果测试失败，再回到具体文件定位原因。这里的“检索”不是开始前的一次动作，而是任务推进过程中的多次信息调度。

这正是 Agentic RAG 试图解决的方向。

在 Agentic RAG 中，检索被纳入模型或系统的规划过程。系统可以先理解任务，再决定是否需要外部信息；可以根据第一次检索结果判断是否继续检索；可以改写查询；可以调用不同工具；可以在生成过程中发现证据不足，再返回检索；也可以在任务完成后，把新的结果写回记忆或知识库。

这意味着 RAG 从一个“问答前置步骤”，变成了智能系统中的信息调度机制。

它要解决的已经不只是“给模型什么资料”，还包括：

什么时候应该相信模型参数中的知识？ 什么时候必须转向外部知识源？ 什么时候需要验证？ 什么时候需要重新检索？ 什么时候需要把结果沉淀为长期记忆？

在这个阶段，RAG 已经超出了传统“向量数据库 + LLM”的想象。它开始与工具调用、记忆系统、工作流编排、多智能体协作等能力交织在一起，成为大模型应用运行框架的一部分。

Harness Engineering 阶段的 RAG，关注的是在恰当的时候调度知识、工具和模型，让外部信息参与系统的行动过程。

从 Prompt 到 Context，再到 Harness，RAG 的含义也随之扩展。

在 Prompt 阶段，RAG 关心的是信息如何被放进提示词。 在 Context 阶段，RAG 关心的是哪些信息应该进入当前上下文。 在 Harness 阶段，RAG 关心的是系统什么时候、通过什么路径调用外部知识。

这三个阶段不是互相替代的关系，而是层层叠加。

一个好的 RAG 系统，既需要好的 prompt 组织，也需要好的上下文构造，还需要好的系统调度。只有把这三层合在一起看，才能理解 RAG 为什么会从一个检索增强问答架构，逐渐演变为大模型工程中的信息流组织方法。

四、从 RAG 技术到 RAG 思想：信息流的组织#

经过前面的讨论，RAG 已经不再只是一个由检索器、向量数据库和大模型组成的工程架构。

在传统 RAG 中，我们看到的是一个清晰的技术回路：外部知识被切分、向量化、存储；用户提问时，系统从知识库中召回相关片段；这些片段被放入上下文，再由大模型生成回答。

但随着大模型工程从 Prompt Engineering 走向 Context Engineering，再走向 Harness Engineering，RAG 的含义也在不断扩展。

在 Prompt Engineering 阶段，它关心的是信息如何被放进模型可以使用的位置；在 Context Engineering 阶段，它关心的是哪些信息应该进入当前任务；在 Harness Engineering 阶段，它关心的是系统什么时候应该调用外部知识、工具和工作流。

这三层变化最终指向同一个问题：

信息如何在需要的时候，进入模型的当前工作现场？

因此，RAG 的核心可以概括为一句话：

在恰当的时刻，把恰当的信息，放到恰当的位置。

这句话不只是对传统 RAG 流水线的总结，也是在描述大模型系统如何使用知识。

检索只是手段，生成只是结果，真正关键的是中间的增强过程：外部信息如何被选择、组织、放置，并转化为模型当前可用的上下文。

从这个角度看，RAG 更接近一种信息流工程。

它关心知识如何流动，召回结果如何进入任务现场，生成是否建立在恰当的信息基础上。向量数据库、重排序、长上下文、工具调用，都是围绕这个问题展开的不同手段。

如果只把 RAG 理解成“向量数据库 + LLM”，那么它只是一种问答系统架构。但如果从信息流的角度重新理解 RAG，就会发现它已经开始进入更广义的知识系统之中。

NotebookLM、Obsidian + Claude Code、LLM Wiki 这些系统，表面上看并不完全是传统 RAG，但它们都在处理同一个问题：

当一个人或一个智能系统面对当前任务时，过去积累的信息如何重新回到现场？

4.1 NotebookLM：从回答问题到重组材料#

传统 RAG 最常见的使用场景是问答。

用户提出一个问题，系统从知识库中检索相关内容，再由模型生成答案。这种形式的重点是“回答”：用户问什么，系统答什么。

但 NotebookLM 展示了另一种可能。

在 NotebookLM 中，用户会先上传或接入一组材料，例如论文、文档、网页、笔记或报告。很多时候，用户并不是为了问一句“第二篇论文讲了什么”，而是想知道这几份材料之间有什么共同问题、观点冲突在哪里、哪一段适合拿来做报告开场。

这时，RAG 的生成结果不再只是一个答案。

它可以是一份摘要，可以是一组关键观点，可以是一个学习指南，也可以是围绕资料生成的对话式讲解。外部材料不只是被动地为某个问题提供证据，而是成为模型组织内容的基础。

这意味着，RAG 的作用从“找到答案依据”扩展成了“重组已有材料”。

比如你把三篇关于 AI 编程工具的论文、一份产品评审纪要和几条用户反馈放进去，真正有价值的输出可能不是某个段落的解释，而是一份“这几份材料共同指向了什么产品机会”的提纲。系统需要从不同材料中取出证据，合并相近观点，保留分歧，再组织成一条可讲述的线索。

在传统问答场景中，用户通常已经有一个明确问题，RAG 负责找资料并回答。而在 NotebookLM 这类系统中，用户有时并不一定知道自己要问什么。用户需要模型帮助自己进入材料、理解材料，并从材料中提炼结构。

这就让 RAG 的意义发生了变化。

它服务的是理解过程。系统从知识库中取出片段以后，还要帮助用户把一组材料重新组织成可理解、可表达、可讨论的内容。

在这里，外部材料从静态文档，变成了当前理解过程中的可操作上下文。

4.2 Obsidian + Claude Code：从知识库到个人工作现场#

如果说 NotebookLM 让一组材料变成可以被模型理解和重组的对象，那么 Obsidian + Claude Code 这样的组合，则进一步把 RAG 推向个人工作现场。

在传统意义上，个人知识库主要承担存储作用。

我们把读书笔记、论文摘录、项目记录、想法碎片、会议纪要放进 Obsidian，依靠目录、标签、双链和搜索来管理它们。知识库像一个外部记忆系统，帮助我们保存过去的思考。

但在大模型进入这个环境之后，知识库的角色开始变化。

它不再只是一个供人检索的资料库，也可以成为模型参与任务的上下文来源。Claude Code 这类工具如果能够读取项目文件、笔记结构、规范文档和历史记录，就可以在当前任务中利用这些信息，帮助用户写代码、整理文章、分析项目、生成计划或维护文档。

这时，RAG 不再表现为一个单独的问答界面，而是融入了人的工作流。

用户不一定是在“向知识库提问”，而是在完成一个真实任务：写一篇文章、修改一个项目、整理一个研究方向、规划一个产品功能。知识库中的信息进入模型上下文时，常常扮演的是背景、约束、依据和素材。

比如你正在重写一篇旧文章，Claude 读到 Obsidian 里三个月前写过一段关于 Context Engineering 的笔记，又看到当前草稿里用了另一个定义。它提醒你：“这里的 Context Engineering 和旧笔记里的定义不一致，要不要统一？”这个时候，系统没有回答一个孤立问题，而是把旧知识带回了当前写作现场。

这就是从知识库到工作现场的转变。

在这个过程中，RAG 的问题也变得更复杂。

系统不仅要知道某个问题应该检索哪几篇笔记，还要理解当前任务所在的位置：用户正在写哪篇文章？这篇文章属于哪个主题？之前的观点是什么？相关材料有哪些？哪些内容已经被使用过？哪些内容应该避免重复？

也就是说，RAG 在这里不是“根据 query 找 chunk”这么单薄，而是在一个持续变化的工作环境中，帮助模型理解当前任务与历史知识之间的关系。

这也是广义 RAG 最有价值的地方。个人知识在具体工作发生时重新进入当前任务，并转化为行动、表达或决策。知识库的目标也随之变化：它不只是更好搜，还要更容易被模型带入工作流。

4.3 LLM Wiki：从检索外部知识到维护知识系统#

如果再进一步看，RAG 还可以从“使用知识”走向“维护知识”。

传统 RAG 默认知识库已经存在。开发者先准备文档，系统负责切分、向量化和索引；用户提问时，RAG 从这个知识库中检索相关内容，并生成答案。

但真实的知识系统并不静止。

文档会更新，代码会变化，项目会演进，团队会积累新的决策，旧的信息也会过期。一个长期运行的智能系统，不能只会从知识库中读取信息，还应该能够帮助知识库保持清晰、准确和可用。

这就是 LLM Wiki 这类思路值得关注的地方。

它关注知识库本身如何持续被整理和维护。模型可以帮助发现重复内容，合并相似条目，补充缺失说明，更新过期信息，建立概念之间的连接，甚至根据新任务沉淀新的知识页面。

想象一个团队 Wiki 里同时存在三篇“登录态说明”：一篇是两年前的设计文档，一篇是某次事故后的修复记录，还有一篇是新同事写的 onboarding 笔记。人读的时候很容易迷路，模型读的时候也会被冲突信息干扰。LLM Wiki 的价值不只是回答“登录态怎么工作”，还包括提示这三篇文档应该合并、哪一篇过期、哪些 API 名称已经改掉、哪里需要补来源。

这时，RAG 的闭环被拉长了。

它原来可能只是：

检索 → 生成

而更像是：

检索 → 理解 → 生成 → 沉淀 → 更新知识库

在这个闭环中，知识库既是模型的外部输入，也是模型输出重新进入系统的地方。

这意味着，RAG 开始具有一种自我维护的倾向：系统不仅从知识中生成答案，也从任务过程中产生新的知识，并把这些知识重新组织回长期记忆。

当然，这里需要非常谨慎。

如果模型生成的内容未经验证就直接写回知识库，系统可能会把错误、幻觉和过时信息沉淀下来，反而污染长期记忆。因此，从 RAG 走向 LLM Wiki，不能简单理解为“让模型自动写文档”。审核、引用、版本、来源和冲突处理机制都要一起设计。

但正因为如此，它更能体现 RAG 思想的扩展。

RAG 的重点从“回答当前问题”扩展到了“让知识在使用过程中被重新整理”。当前任务与长期知识系统之间开始形成循环。

知识在需要时进入现场，任务结束后又被重新沉淀和更新。这已经接近一个更完整的知识操作系统。

4.4 RAG 思想：让知识在需要时回到现场#

把 NotebookLM、Obsidian + Claude Code、LLM Wiki 放在一起看，会发现它们虽然形态不同，但底层问题是一致的。

NotebookLM 关注的是：一组材料如何被模型重新组织，帮助用户理解。 Obsidian + Claude Code 关注的是：个人知识如何进入当前工作流，帮助用户行动。 LLM Wiki 关注的是：任务过程中产生的新理解，如何重新沉淀进知识系统。

它们已经很难再用传统“检索增强问答”来概括。

它们共同指向一个更广义的问题：

知识如何在长期积累与当前任务之间流动？

这就是 RAG 从技术走向思想的关键。

在传统机器学习想象中，知识主要存在于模型参数里。模型训练完成后，知识被压缩在内部，推理时再从参数中释放出来。但 RAG 改变了这种关系。它不要求模型记住一切，而是让知识保留在外部世界中，并在需要时被检索、组织和注入。

这种变化看似只是工程上的折中，实际上却改变了我们理解智能系统的方式。

智能也不只来自模型内部，还来自模型与外部知识环境之间的关系。

一个系统是否聪明，不只取决于模型参数有多大，也取决于它能否在当前任务中找到正确的信息，能否判断哪些信息值得使用，能否把信息组织成有效上下文，能否在任务结束后把新的理解沉淀回知识系统。

因此，RAG 思想比“给大模型外挂知识库”更宽。

它强调的是：

知识不必全部存放在模型内部，重要的是系统能否在需要时让知识回到现场。

所谓“现场”，可以是一轮问答，可以是一篇文章的写作过程，可以是一个代码仓库的维护任务，也可以是一个长期知识库的演进过程。

在这些场景中，RAG 的价值主要体现在信息流的组织上。

它让过去的材料、外部的文档、个人的笔记、团队的经验、实时的事实，都有机会在当前任务中重新发挥作用。

所以，RAG 的深层意义不在于某一套固定架构，而在于它提供了一种设计原则：

不要把智能系统封闭在参数内部，而要让它能够与外部知识环境建立连接。

从这个意义上说，RAG 是大模型时代重新理解知识管理的一种方式。

它让知识不只停留在存储、搜索和归档里，也能在恰当的时刻，回到恰当的任务现场，并以恰当的结构参与生成、判断和行动。

这就是“从 RAG 技术到 RAG 思想”的含义。