RAG彻底爆了！一文读懂其架构演进及核心要点

显示全部楼层

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(34, 34, 34);visibility: visible;">👉目录

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(34, 34, 34);visibility: visible;">

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(34, 34, 34);visibility: visible;">1引言

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;visibility: visible;">2RAG演变流程

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;visibility: visible;">3 总结

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;visibility: visible;">4 一些思考

本文系统梳理了检索增强生成（RAG）架构的演进历程，从基础架构到智能化解决方案的迭代路径。文章通过对比Naive RAG、Advanced RAG、Modular RAG和Agentic RAG四代架构的核心特点与技术突破，揭示了RAG技术如何通过模块化设计、智能体协同等创新解决知识更新、语义对齐和复杂任务处理等关键问题，为LLM应用落地提供重要参考。由于作者水平有限，若相关理解有误请以实际为准。

关注腾讯云开发者，一手技术干货提前解锁👇

鹅厂程序员面对面直播继续，每周将邀请鹅厂明星技术大咖讲解AI 时代下的“程序员护城河”。更有蛇年公仔等精美周边等你来拿，记得提前预约直播～👇

01

引言

1.1 什么是RAG（维基）

检索增强生成（英语：Retrieval-augmented generation, RAG ) 是赋予生成式人工智能模型信息检索能力的技术。检索增强生成优化大型语言模型(LLM) 的交互方式，让模型根据指定的一组文件回应用户的查询，并使用这些信息增强模型从自身庞大的静态训练数据中提取的信息。检索增强生成技术促使大型语言模型能够使用特定领域或更新后的信息。应用案例，包括让聊天机器人访问公司内部资料，或来自权威来源的事实信息。

简易RAG流程

元宝 RAG示例

1.2为什么需要RAG

1、LLM的已知问题

知识有限：LLM训练是离线的，其模型知识仅限于训练数据所覆盖的知识范围，模型不具备新知识或未训练知识，如没有实时数据或私有数据。
容易产生幻觉：没有答案的情况下可能会提供虚假信息。

RAG是解决上述问题的一种比较轻量的解决方案。

2、RAG优点

轻量，成本更低，灵活：相比组织特定领域信息重新训练基础模型，RAG是将新数据引入LLM成本更低的方法。
支持实时数据更新：可以通过工具实时检索最新信息，并利用LLM的整合推理能力更准确回答实时问题。
可解释性，可溯源：答案来源可追溯到具体检索库以及检索内容，用户可验证准确性。

3、RAG缺点

依赖知识库质量及系统设计：系统回答的效果与外部知识库质量和整体系统设计有较大关系，若设计不合理可能导致答案偏差。
系统复杂度增加，增加计算开销：大规模的知识库检索会让整体系统更加复杂，并且会延长系统性响应时间，对耗时敏感的业务可能产生性能瓶颈。研究表明，检索环节占RAG总耗时的60%以上。

02

RAG演变流程

Navie RAG -> Advanced RAG -> Modular RAG -> Agentic RAG

2.1Navie RAG

2.1.1来源

最早由meta在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出，提出的原因为: 大规模预训练语言模型（LLM）虽在下游任务上表现优异，但由于知识存储在参数中，无法及时更新且易出现“幻觉”（hallucination）；为此，引入外部可检索的非参数化记忆（如 Wikipedia 向量索引），并将检索结果与生成模型结合，从而提升知识密集型任务的准确性与可追溯性。

2.1.2介绍

最简单的架构，只包含3个阶段：Indexing -> Retrieval -> Generation.

流程

1、索引构建(离线)

数据加载：从各个来源整合数据。
文档切块：按照一定策略切块文档，如固定大小，语义分块等。
向量化与存储：使用Embedding模型（bge系列等）将文档转换成向量，将向量即文档信息存储到向量数据库（腾讯云，Milvus，Faiss）等。

2、在线检索（在线）

检索：使用相同Embedding模型转换用户输入，并从向量数据库检索相似TopK文档（余弦相似度或者欧氏距离）。
生成：将用户输入与检索到的toK文档组织成Prompt，输入LLM生成回答。

缺点

检索质量不佳：存在检索精度低和召回率低的问题，可能导致无关或过时信息被召回，影响生成答案的准确性。
生成内容缺陷：模型容易产生幻觉（信息不足）。

2.2Advanced RAG

2.2.1 来源

没有明确的提出者，在Navie RAG架构之后由多方逐步演进得到，如微软研究院提出HyDE，谷歌引入Rerank，以及如Elastic和Cohere公司提出的各种优化技术等，由多方共同构成Advanced RAG技术体系. 这些优化技术提出的动因，主要是由于Navie RAG仍存在一系列问题，如

检索精度不足：Navie RAG依赖关键词匹配（如BM25）或简单向量检索，导致语义偏差问题。
多上下文割裂：Navie RAG直接将检索到的上下文直接拼接Prompt输入LLM，没有做post-retrieval处理，文档容易出现冗余或矛盾。
无法处理复杂场景：Navie RAG工作流比较简单，没有针对性优化，系统表现上限有限。

2.2.2 介绍

基于Navie Rag增加两个步骤，包含5个阶段：Indexing -> Pre Retrieval -> Retrievel -> Post Retrievel -> Generation，旨在解决文档召回的质量和准确率。Navie RAG属于Advanced Rag的一个特化，即Pre Retrievel和Post Retrievel为空。

1、Pre-Retrieval

预检索处理: 侧重数据索引优化。

索引数据优化

增强数据密度：如利用LLM清洗冗余信息，元数据增强（条件过滤等）。

增强索引语义:如预生成chunk快的假设性问题，提升检索对称性，建立如关键词搜索（BM25），向量检索或图数据库。尝试多种chunk分块策略（固定大小，递归，语义分块）。

Embeddings模型优化:针对特定领域数据对模型进行微调，提升语义匹配精度。

Query增强

Query translation:query转换，用于用户的不确定性，用户可能会输入模糊表达，或query与index文档不在一个语义空间，或query过于复杂的情况，因此需要query转换。如query-rewrite,query-expansion等。

Query enhancement:query增强，增强或者扩大用户输入的query语义，如: HyDE(假设文档增强)，Step-Back Prompting(回退一步prompt)。

Query decomposition:query分解，把用户的复杂query分解成多个可管理的子问题，引导模型逐步解决各个子问题。如Answer Recursively（递归回答，迭代），Answer Individually（独立回答，分解后并行回答）。

2、Post-Retrievel

后检索处理: 侧重数据结果的二次加工&过滤

重排序Rerank
对检索出的文档做更精细的评估，将真正最匹配意图的文档排列到前面，尽可能减少噪声
上下文压缩Prompt Compression
若检索出大量文档，在输送给LLM之前可能还需要对文档做裁切，仅保留最关键核心的内容

2.3Modular RAG

2.3.1来源

Modular RAG 最早由 Yunfan Gao 等人在 2024 年 7 月的论文《Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks》中首次系统化提出。提出的动因有:

RAG系统日渐复杂：传统RAG线性结构难以应对更复杂的需求，需要合理抽象及规划，否则系统维护困难。
提升可重用性及维护，快速迭代：将各个环节抽象成一个个的可插拔模块，便于RAG系统引入新的算法或计算策略。

对比Advanced RAG架构，该框架将系统各个部分抽象单独的模块与算子，实现模块可复用，易扩展及维护的RAG架构。

2.3.2介绍

Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks

模块化RAG，将 RAG 系统分为Module Type、Module和Operators三层结构。每个 Module Type 代表 RAG 系统中的一个核心流程，包含多个功能模块。每个功能模块反过来都包含多个特定的运算符。整个 RAG 系统变成了多个模块和相应运算符的排列组合，形成了我们所说的 RAG Flow。整体有7个部分：Indexing, Pre Retrieval, Retrievel, Post Retrievel, Memory, Generation,Orchestration.这种范式在基于Advanced RAG的横向架构上引入了纵向的结构，即Module和Operators。

Orchestration是Modular RAG区分Advanced RAG的一个重要部分，而Memory模块虽然在原论文没有提及，但笔者认为也是Modular RAG的一个重要组成部分，用于赋予RAG系统的长期记忆能力

Module Type: RAG系统中的模块分类，即Indexing, Pre Retrieval, Retrievel, Post Retrievel, Memory, Generation, Orchestration模块，可以理解是函数接口。
Module: RAG系统中的具体功能组件，每个模块负责完成某个子任务，如Retrievel中可以是VectorRetriever（向量检索），HybridRetriever（混合检索）。可以理解是函数接口的实现类
Operators: 每个模块的具体实现，可以理解是接口实现类内部的核心算法完整功能的代码片段，如VectorRetriever里有如下余弦相似度算法

def_cosine_similarity(query_vec,doc_vec):#操作符returnnp.dot(query_vec,doc_vec)/(np.linalg.norm(query_vec)*np.linalg.norm(doc_vec))

关键区别

Modular RAG的模块间通过数据流而非单纯函数调用交互（如检索模块输出文档列表给生成模块）。
操作符可以跨模块复用（如相似度计算操作符可能被多个检索模块共享）。

Modular Rag 举个例子

1、代码示例，使用haystack官方示例。

Haystack是一个开源框架，用于边界构建LLM应用程序，框架整体采用“节点+流水线”架构，允许开发者通过自由组合预构建组件（如检索器、生成器、评估器）构建定制化管道工作流。

#####################0.组件定义#####################fromhaystackimportDocument,Pipelinefromhaystack.document_stores.in_memoryimportInMemoryDocumentStorefromhaystack.components.embeddersimportSentenceTransformersTextEmbedderfromhaystack.components.retrievers.in_memoryimportInMemoryEmbeddingRetrieverdocument_store=InMemoryDocumentStore(embedding_similarity_function="cosine")text_embedder=SentenceTransformersTextEmbedder()retriever=InMemoryEmbeddingRetriever(document_store=document_store)#####################1.添加组件#####################query_pipeline=Pipeline()query_pipeline.add_component("component_name",component_type)#Hereisanexampleofhowyou'daddthecomponentsinitializedinstep2above:query_pipeline.add_component("text_embedder",text_embedder)query_pipeline.add_component("retriever",retriever)#Youcouldalsoaddcomponentswithoutinitializingthembefore:query_pipeline.add_component("text_embedder",SentenceTransformersTextEmbedder())query_pipeline.add_component("retriever",InMemoryEmbeddingRetriever(document_store=document_store))#####################2.连接组件######################Thisisthesyntaxtoconnectcomponents.Hereyou'reconnectingoutput1ofcomponent1toinput1ofcomponent2:pipeline.connect("component1.output1","component2.input1")#Ifbothcomponentshaveonlyoneoutputandinput,youcanjustpasstheirnames:pipeline.connect("component1","component2")#Ifoneofthecomponentshasonlyoneoutputbuttheotherhasmultipleinputs,#youcanpassjustthenameofthecomponentwithasingleoutput,butforthecomponentwith#multipleinputs,youmustspecifywhichinputyouwanttoconnect#Here,component1hasonlyoneoutput,butcomponent2hasmulitipleinputs:pipeline.connect("component1","component2.input1")#Andhere'showitshouldlooklikeforthesemanticdocumentsearchpipelinewe'reusingasanexample:pipeline.connect("text_embedder.embedding","retriever.query_embedding")#BecausetheInMemoryEmbeddingRetrieveronlyhasoneinput,thisisalsocorrect:pipeline.connect("text_embedder.embedding","retriever")

2、可视化示例，使用LangFlow。

Modular RAG下的RAG流

各个模块之间的协作，可以有类似以下的工作流模式串联

1、线性编排(Linear Pattern)

整个RAG流由各个Module线性串联起来，为最简单的模式。

2、条件编排(Conditional Pattern)

RAG流中会添加一些Route条件判断，增强系统的灵活性。

3、分支(并行)编排(Branching)

RAG流中存在多个并行的分支，各自处理后随之合并到一起，这种情况多用于要增加生成结果的多样性而引入

4、循环编排(Loop Pattern)

Interative retrieval(循环检索):单次检索和生成无法有效解决需要大量知识的复杂问题，每次循环后会把当前Generate的输出作为匹配源再去检索内容,直到循环结束，整体类似HyDE检索增强方法。ITER-RETGEN是一种实现循环检索的架构。

核心: 在每次迭代中，ITER-RETGEN 利用上一次迭代的模型输出作为特定上下文来帮助检索更多相关知识。

HyDE(Hypothetical Document Embeddings), 即预先让LLM生成用户问题的答案，然后再用答案去知识库检索更大范围内的内容，即提升query的泛化性
如: query: 如何提高睡眠质量, 但知识库为“不喝咖啡，睡前不玩手机等”内容，此时可以用LLM先生成简单的答案，可能未“提升睡眠质量要避免咖啡因和电子设备等…”，此时可以检索到对应文档

rescursive retrieval(递归检索):与循环检索类似，但更明确的指出依赖前一步的各个内容（如利用上一次的query改写内容），不断深化检索，不断明确用户查询（消除歧义），有更明确的退出循环的条件。TOC RAG流是一种实现，关键在Tree of Clarification中，通过澄清树结构，在不断迭代中消除用户输入的歧义。

澄清树:当初始查询不明确时，通过递归迭代不断生成多层子问题。
每次迭代检索，会基于上一次迭代的输入，检索结果和生成内容，重新文档rerank，生成新的节点插入到树中，达到一定深度或者节点树后合并成一个全面的答案。

TOC RAG流，一种rescursive retrieval的实现

Tree of Clarification

Interative和rescursive的比较：

维度	Interative	rescursive
核心	在检索和生成之间交替执行，多次循环逐步迭代出更优结果	不断将复杂问题拆解成简单子问题，并逐层整合子答案生成最终结果
场景	需要逐步细化答案的开放性问题（如模糊查询、多意图混合问题）	需多跳推理的复杂问题（如技术文档分析、法律条款追溯）

Adaptive retrieval(自适应检索)：引入LLM Agent概念，在系统关键环节使用LLM判断是否应该怎么行动。如可以在pre-retrieval环节使用LLM判断是否需要去检索外部知识。同Adaptive Agentic RAG。

tuning模式
RAG系统在各个Module都可能使用了LLM技术，使用数据微调以优化各个LLM组件的表现，包括：

retriever fine-tuning: 检索器微调。

generator fine-tuning: 生成器微调。

dual fine-tuning: 即检索器+生成器微调。

2.4AgenticRAG

2.4.1来源

最早Chidaksh Ravuru 等人于 2024 年 8 月 18 日在 arXiv 上发表的论文《Agentic Retrieval-Augmented Generation for Time Series Analysis》中正式提出。提出动因：

多层次依赖难以捕捉：传统 RAG 将检索和生成视为线性流水线，对于具有季节性、趋势性及突发事件的时序数据，单一向量检索器难以兼顾各类模式，导致预测准确性不足。
分布漂移与模型失效：历史训练数据与实时数据分布常出现偏差，若依赖静态文档库，容易陷入“信息孤岛”，降低时序分析的可靠性。

对比传统RAG, Agentic RAG将能力依托于智能体，提升了RAG系统的灵活性及扩展其应用边界。

2.4.2 介绍

Agentic RAG：架构上引入Agent的思路，实现动态决策（如是否检索、工具调用）和多轮迭代优化。相比上述提到的几种RAG，Agentic RAG将实际输入处理的多样性交给LLM处理，可以解决更复杂的问题。

Agent的核心部件：LLM + Memory + Planning + Tools

如何运作?

从Modular RAG的架构来看，只要是涉及LLM的模块理论上都可以使用Agent来增强，但在该Agentic RAG架构中更多强调的是在retrievel模块中使用。在检索阶段，不同数据源可以视作不同的tool，然后由检索Agent集成这些tool动态检索内容

一些Agent Agentic RAG架构

Single-Agent Agentic RAG
该框架核心是一个系统决策中心的Router Agent，该Agent动态处理信息检索，集成操作，类似上述Modular RAG中提到的条件编排的Agent代理版本，比较适用于多检索源的简单问答场景。

Multi-Agent Agentic RAG
为Single-Agent Agentic RAG架构的演进版本，用多个专用代理来细化更复杂的工作流和不同的查询类型。核心Router Agent下又挂接了多个检索Agent, 如Agent1用于查询结构化数据(Mysql)，Agent2用于查询非结构化数据，Agent3用于Web查询或专用API查询等。

Hierarchical Agentic RAG

分层代理RAG，为Multi-Agent Agentic RAG架构的拓展，将整个系统分为多个层级的Agent，由顶级Agent驱动子Agent，并聚合子Agent的结果。

Agentic Corrective RAG

Corrective RAG的核心是他可以动态评估检索到的文档并纠正查询，提升检索文档的质量。

Agentic Corrective RAG系统建立在5个关键Agent上。

Context Retrieval Agent:负责从数据库中检索相关上下文。
Relevance Evaluation Agent:负责评估检索到的文档的相关性，并标记出不相关或不明确文档并采取纠正措施。
Query Refinement Agent:重写query增强检索的Agent。
External Knowledge Retrieval Agent:当Context Retrieval Agent检索的上下文不足时，从其他备用数据源检索数据(如Web 检索)。
Response Synthesis Agent:组织响应Agent。

Adaptive Agentic RAG

自适应Agent RAG, 与上述Modular RAG中的Adaptive retrieval一样，语义上都是在各个环节引入了LLM判断，并在引入LLM评测实现Loop自迭代。

Graph-Based Agentic RAG

Graph-Based Agentic RAG在检索中引入了图检索，合并图数据及其他检索数据增强检索效果

03

总结

架构	提出动因	主要特点
Naive RAG	LLM 容易“幻觉”，参数化知识难更新；需外部检索补充知识并提供可追溯的证据。	- 三步流程：文档切块 → 向量检索 → 拼接提示生成 - 一体化端到端微调（RAG-Sequence & RAG-Token） - 减少参数化模型的幻觉，提升开放域 QA 准确率
Advanced RAG	用户查询与知识库语义不对齐；Naive RAG 检索噪声多、生成质量有限。	- 预检索(Pre Retrieval)：查询重写/扩展 (Rewrite) - 检索(Retrieval)：语义向量检索 - 后检索(Post Retrieval)：结果重排序、摘要压缩
Modular RAG	随着检索器、LLM 等组件飞速迭代，传统管道难快速集成新功能、维护成本高。	-七大模块: Indexing, Pre Retrieval, Retrievel, Post Retrievel, Memory, Generation, Orchestration - 将检索、重排序、压缩、生成等拆分为可插拔模块 - 引入路由、调度、融合算子 - 模块化设计，灵活扩展，支持多种 RAG 模式（线性、条件、分支、循环）
Agentic RAG	需处理复杂多步任务、多轮决策，单轮静态流程不够；希望结合检索与规划能力。	- 多智能体架构：主智能体协调子智能体 - 动态决策：自主判断何时检索、何时生成 - 支持多轮迭代、任务自校正，提高复杂任务的适应性与鲁棒性

04

一些思考

Generation模块(LLM回答)的前后处理
在Advanced RAG中，为了提升最终回答效果从而引入了Pre-Retrieval和Post-Retrieval两个流程，或对回答LLM进行微调。从 “garbage in garbage out”理论来看，实际落地时，需要充分考虑业务属性，提升输入LLM的数据质量。
RAG系统设计的模块化&可插拔
由于RAG系统的不确定性（引入LLM），在构建自己的RAG系统时，可参考Modular RAG思维使用模块化设计，便于快速切换某环节中的Module后验证整体系统效果。
Agent的不稳定，实际业务落地存在不确定性
当前由于模型能力的瓶颈，Agent系统存在极大的不确定性，在Agentic RAG系统中，在大的层面引入Agent对实际业务落地不太可取，可考虑在某个小环节中引入，如Generation问答补充（在基于检索出的文档后，动态给定一些tools让其优化回答效果）。