👉目录
1 引言
2 RAG演变流程
3 总结
4 一些思考
检索增强生成（英语：Retrieval-augmented generation, RAG ) 是赋予生成式人工智能模型信息检索能力的技术。检索增强生成优化大型语言模型(LLM) 的交互方式，让模型根据指定的一组文件回应用户的查询，并使用这些信息增强模型从自身庞大的静态训练数据中提取的信息。检索增强生成技术促使大型语言模型能够使用特定领域或更新后的信息。应用案例，包括让聊天机器人访问公司内部资料，或来自权威来源的事实信息。
简易RAG流程
元宝 RAG示例
1、LLM的已知问题
知识有限：LLM训练是离线的，其模型知识仅限于训练数据所覆盖的知识范围，模型不具备新知识或未训练知识，如没有实时数据或私有数据。
容易产生幻觉：没有答案的情况下可能会提供虚假信息。
RAG是解决上述问题的一种比较轻量的解决方案。
2、RAG优点
轻量，成本更低，灵活：相比组织特定领域信息重新训练基础模型，RAG是将新数据引入LLM成本更低的方法。
支持实时数据更新：可以通过工具实时检索最新信息，并利用LLM的整合推理能力更准确回答实时问题。
可解释性，可溯源：答案来源可追溯到具体检索库以及检索内容，用户可验证准确性。
3、RAG缺点
依赖知识库质量及系统设计：系统回答的效果与外部知识库质量和整体系统设计有较大关系，若设计不合理可能导致答案偏差。
系统复杂度增加，增加计算开销：大规模的知识库检索会让整体系统更加复杂，并且会延长系统性响应时间，对耗时敏感的业务可能产生性能瓶颈。研究表明，检索环节占RAG总耗时的60%以上。
Navie RAG -> Advanced RAG -> Modular RAG -> Agentic RAG
最早由meta在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出，提出的原因为: 大规模预训练语言模型（LLM）虽在下游任务上表现优异，但由于知识存储在参数中，无法及时更新且易出现“幻觉”（hallucination）；为此，引入外部可检索的非参数化记忆（如 Wikipedia 向量索引），并将检索结果与生成模型结合，从而提升知识密集型任务的准确性与可追溯性。
最简单的架构，只包含3个阶段：Indexing -> Retrieval -> Generation.
流程
1、索引构建(离线)
数据加载：从各个来源整合数据。
文档切块：按照一定策略切块文档，如固定大小，语义分块等。
向量化与存储：使用Embedding模型（bge系列等）将文档转换成向量，将向量即文档信息存储到向量数据库（腾讯云，Milvus，Faiss）等。
2、在线检索（在线）
检索：使用相同Embedding模型转换用户输入，并从向量数据库检索相似TopK文档（余弦相似度或者欧氏距离）。
生成：将用户输入与检索到的toK文档组织成Prompt，输入LLM生成回答。
缺点
检索质量不佳：存在检索精度低和召回率低的问题，可能导致无关或过时信息被召回，影响生成答案的准确性。
生成内容缺陷：模型容易产生幻觉（信息不足）。
没有明确的提出者，在Navie RAG架构之后由多方逐步演进得到，如微软研究院提出HyDE，谷歌引入Rerank，以及如Elastic和Cohere公司提出的各种优化技术等，由多方共同构成Advanced RAG技术体系. 这些优化技术提出的动因，主要是由于Navie RAG仍存在一系列问题，如
检索精度不足：Navie RAG依赖关键词匹配（如BM25）或简单向量检索，导致语义偏差问题。
多上下文割裂：Navie RAG直接将检索到的上下文直接拼接Prompt输入LLM，没有做post-retrieval处理，文档容易出现冗余或矛盾。
无法处理复杂场景：Navie RAG工作流比较简单，没有针对性优化，系统表现上限有限。
基于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之前可能还需要对文档做裁切，仅保留最关键核心的内容
Modular RAG 最早由 Yunfan Gao 等人在 2024 年 7 月的论文《Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks》中首次系统化提出。提出的动因有:
RAG系统日渐复杂：传统RAG线性结构难以应对更复杂的需求，需要合理抽象及规划，否则系统维护困难。
提升可重用性及维护，快速迭代：将各个环节抽象成一个个的可插拔模块，便于RAG系统引入新的算法或计算策略。
对比Advanced RAG架构，该框架将系统各个部分抽象单独的模块与算子，实现模块可复用，易扩展及维护的RAG架构。
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): # 操作符 return np.dot(query_vec, doc_vec) / (np.linalg.norm(query_vec)*np.linalg.norm(doc_vec))
关键区别
Modular RAG的模块间通过数据流而非单纯函数调用交互（如检索模块输出文档列表给生成模块）。
操作符可以跨模块复用（如相似度计算操作符可能被多个检索模块共享）。
Modular Rag 举个例子
1、代码示例，使用haystack官方示例。
Haystack是一个开源框架，用于边界构建LLM应用程序，框架整体采用“节点+流水线”架构，允许开发者通过自由组合预构建组件（如检索器、生成器、评估器）构建定制化管道工作流。
##################### 0. 组件定义 #####################from haystack import Document, Pipelinefrom haystack.document_stores.in_memory import InMemoryDocumentStorefrom haystack.components.embedders import SentenceTransformersTextEmbedderfrom haystack.components.retrievers.in_memory import InMemoryEmbeddingRetrieverdocument_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)# Here is an example of how you'd add the components initialized in step 2 above:query_pipeline.add_component("text_embedder", text_embedder)query_pipeline.add_component("retriever", retriever)# You could also add components without initializing them before:query_pipeline.add_component("text_embedder", SentenceTransformersTextEmbedder())query_pipeline.add_component("retriever", InMemoryEmbeddingRetriever(document_store=document_store))##################### 2. 连接组件 ###################### This is the syntax to connect components. Here you're connecting output1 of component1 to input1 of component2:pipeline.connect("component1.output1", "component2.input1")# If both components have only one output and input, you can just pass their names:pipeline.connect("component1", "component2")# If one of the components has only one output but the other has multiple inputs,# you can pass just the name of the component with a single output, but for the component with# multiple inputs, you must specify which input you want to connect# Here, component1 has only one output, but component2 has mulitiple inputs:pipeline.connect("component1", "component2.input1")# And here's how it should look like for the semantic document search pipeline we're using as an example:pipeline.connect("text_embedder.embedding", "retriever.query_embedding")# Because the InMemoryEmbeddingRetriever only has one input, this is also correct: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的比较：
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: 即检索器+生成器微调。
最早Chidaksh Ravuru 等人于 2024 年 8 月 18 日在 arXiv 上发表的论文《Agentic Retrieval-Augmented Generation for Time Series Analysis》中正式提出。 提出动因：
多层次依赖难以捕捉：传统 RAG 将检索和生成视为线性流水线，对于具有季节性、趋势性及突发事件的时序数据，单一向量检索器难以兼顾各类模式，导致预测准确性不足。
分布漂移与模型失效：历史训练数据与实时数据分布常出现偏差，若依赖静态文档库，容易陷入“信息孤岛”，降低时序分析的可靠性。
对比传统RAG, Agentic RAG将能力依托于智能体，提升了RAG系统的灵活性及扩展其应用边界。
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在检索中引入了图检索，合并图数据及其他检索数据增强检索效果
| Naive RAG | - 一体化端到端微调（RAG-Sequence & RAG-Token） - 减少参数化模型的幻觉，提升开放域 QA 准确率 | |
| Advanced RAG | - 检索(Retrieval)：语义向量检索 - 后检索(Post Retrieval)：结果重排序、摘要压缩 | |
| Modular RAG | - 将检索、重排序、压缩、生成等拆分为可插拔模块 - 引入路由、调度、融合算子 - 模块化设计，灵活扩展，支持多种 RAG 模式（线性、条件、分支、循环） | |
| Agentic RAG | - 动态决策：自主判断何时检索、何时生成 - 支持多轮迭代、任务自校正，提高复杂任务的适应性与鲁棒性 |
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让其优化回答效果）。
