Agentic RAG

参考：《AGENTIC RETRIEVAL-AUGMENTED GENERATION: A SURVEY ON AGENTIC RAG》

Agentic RAG 将 AI Agent 融入了 RAG，采用了 Agent 中的思想，例如 Reflection（反思）、Planning（规划）、Tool Use（工具使用）、Multi-Agent（多智能体协作）等，在以下方面都表现出卓越的性能：

多领域知识检索。
以文档为中心的实时工作流程。
可扩展、自适应且合乎道德的 AI 系统。

RAG 发展历程

Naive RAG

Naive RAG 是最基础的一种架构，用于结合检索和生成来处理复杂的任务。下图中的示例依赖于基于关键词的检索技术，如 TF-IDF 和 BM25，从静态数据集中获取文档，用于增强模型的生成能力。（Naive RAG 也支持向量检索）

Naive RAG 容易实现，适用于简单的事实查询或上下文复杂性低的任务，但存在以下缺陷：

缺乏上下文意识：由于依赖词汇匹配而非语义理解，检索到的文档往往无法捕捉查询的语义细微差别。
输出碎片化：缺乏数据预处理或上下文整合，往往导致回答不连贯或过于通用。
可扩展性问题：基于关键词的检索技术在处理大型数据集时存在困难，往往无法识别最相关的信息。

Advanced RAG

Advanced RAG 融入语义理解和增强的检索技术。使用密集检索模型（如 Dense Passage Retrieval，DPR）和神经排序算法来提高检索精度。

Advanced RAG 的核心特性包括：

密集向量搜索：查询和文档以高维向量空间表示，从而实现用户查询和检索到的文档之间更好的语义对齐。
上下文重新排序：神经模型重新对检索到的文档进行排序，以优先考虑最相关的上下文信息。
迭代检索：Advanced RAG 引入了多跳检索机制，使得在复杂查询中可以跨多个文档进行推理。

Advanced RAG 适用于需要高精度和细致理解的应用，例如研究综述和个性化推荐。然而，仍然存在一些挑战，比如计算开销和有限的可扩展性，特别是在处理大型数据集或多步查询时。

Modular RAG

Modular RAG 强调灵活性和定制性。将检索和生成流程分解为独立、可重用的组件，从而实现领域特定的优化和任务适应性。下图展示了 Modular RAG 的架构，展示了混合检索策略、可组合的流程和外部工具集成。

Modular RAG 的关键创新包括：

混合检索策略：将稀疏检索方法（例如稀疏编码器-BM25）与密集检索技术（例如 DPR - Dense Passage Retrieval）相结合，准确性更高（就是 BGE 里的混合检索）。
工具集成：将外部 API、数据库、计算工具等功能纳入系统，用于处理特定任务，如实时数据分析或领域特定计算。
可组合的流程：Modular RAG 使得检索器、生成器和其他组件可以独立替换、增强或重新配置，从而实现对特定用例的高度适应性。

例如，一个专为金融分析设计的 Modular RAG 系统可以通过 API 获取实时股票价格，利用密集检索分析历史趋势，并通过定制的语言模型生成可操作的投资见解。这种模块化和定制性使得 Modular RAG 非常适合处理复杂的、多领域的任务，既具有可扩展性又具有精确性。

Graph RAG

Graph RAG 整合基于图的数据结构扩展了传统的检索增强生成系统，利用图数据中的关系和层次结构，增强了多跳推理和上下文丰富性。通过引入基于图的检索，Graph RAG 能够实现更丰富、更准确的生成输出，特别是在需要关系理解的任务中。

Graph RAG 的特点包括：

节点连接性：捕获并推理实体之间的关系。
层次知识管理：通过基于图的层次结构处理结构化和非结构化数据。
上下文丰富：通过利用基于图的路径添加关系理解。

然而，Graph RAG 也有一些局限性：

可扩展性有限：依赖图结构可能会限制可扩展性，特别是在数据源广泛时。
数据依赖性：高质量的图数据对于有意义的输出至关重要，限制了其在非结构化或注释不佳的数据集中的适用性。
集成复杂性：将图数据与非结构化检索系统集成增加了设计和实现的复杂性。

Graph RAG 适用于医疗诊断、法律研究等需要对结构化关系进行推理的应用领域。更详细描述见 3.6 GraphRAG。

传统 RAG 面临的问题

上下文整合：通常难以将 RAG 检索到的内容无缝地融入生成的响应中，检索是静态的，缺乏上下文意识，导致输出结果零散、不一致或者过于通用。
多步推理：复杂的查询需要多步查询和推理，传统的 RAG 系统往往无法根据中间洞察或用户反馈来优化检索，导致响应不完整或不连贯。
可拓展性和高延迟：随着数据源的增多，查询将需要更大的计算资源，导致了显著的延迟。

Agentic RAG

Agentic RAG 引入了具有动态决策能力和工作流优化能力的自主代理，实现了范式转变。与静态系统不同，Agentic RAG 采用迭代改进和自适应检索策略来应对复杂、实时和多领域查询。这种范式利用了检索和生成过程的模块化，同时引入了基于代理的自治性。

Agentic RAG 的关键特性包括：

自主决策：代理根据查询的复杂性独立评估和管理检索策略。
迭代改进：引入反馈循环以提高检索准确性和响应相关性。
工作流优化：动态编排任务，实现实时应用的高效性。

Agentic RAG 面临的挑战：

协调复杂性：管理代理之间的交互需要复杂的编排机制。
计算开销：使用多个代理增加了复杂工作流的资源需求。
可扩展性限制：虽然具有可扩展性，但系统的动态性可能会对高查询量的计算资源造成压力。

Agentic RAG 在客户支持、金融分析和自适应学习平台等领域表现出色，其中动态适应性和上下文精确性至关重要。

Agentic RAG 实现框架

核心架构

Agentic RAG 的核心架构包含以下层次：

┌─────────────────────────────────────────────────────────┐
│                    用户查询层                             │
├─────────────────────────────────────────────────────────┤
│                    智能体编排层                           │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │ Router  │  │ Planner │  │Executor │  │Evaluator│    │
│  │ Agent   │  │ Agent   │  │ Agent   │  │ Agent   │    │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘    │
├─────────────────────────────────────────────────────────┤
│                    工具与知识层                           │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │Vector DB│  │Graph DB │  │  APIs   │  │ Tools   │    │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘    │
├─────────────────────────────────────────────────────────┤
│                    生成与输出层                           │
│  ┌─────────────────────────────────────────────────┐    │
│  │              LLM Generation                     │    │
│  └─────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘

组件详细说明

1. Router Agent（路由智能体）

功能：接收用户查询，分析查询意图，将查询路由到最合适的处理流程。

实现要点：

意图识别：使用分类模型或 LLM 识别查询类型（事实查询、推理查询、总结查询等）。
路由策略：根据查询类型选择合适的检索策略（向量检索、图检索、混合检索等）。
负载均衡：在多个处理路径之间分配查询，优化系统整体性能。

python

class RouterAgent:
    def __init__(self, llm, routing_rules):
        self.llm = llm
        self.routing_rules = routing_rules
    
    def route_query(self, query):
        # 分析查询意图
        intent = self.analyze_intent(query)
        
        # 根据意图选择路由
        if intent == "factual":
            return "vector_retrieval"
        elif intent == "reasoning":
            return "graph_retrieval"
        elif intent == "summarization":
            return "hybrid_retrieval"
        else:
            return "default_retrieval"
    
    def analyze_intent(self, query):
        # 使用 LLM 分析查询意图
        prompt = f"分析以下查询的意图：{query}"
        intent = self.llm.generate(prompt)
        return intent

2. Planner Agent（规划智能体）

功能：将复杂查询分解为子任务，制定执行计划。

实现要点：

任务分解：将复杂查询分解为可管理的子任务。
依赖分析：分析子任务之间的依赖关系。
执行顺序：确定子任务的执行顺序和并行策略。

python

class PlannerAgent:
    def __init__(self, llm):
        self.llm = llm
    
    def create_plan(self, query):
        # 分解任务
        subtasks = self.decompose_query(query)
        
        # 分析依赖
        dependencies = self.analyze_dependencies(subtasks)
        
        # 生成执行计划
        plan = self.generate_execution_plan(subtasks, dependencies)
        
        return plan
    
    def decompose_query(self, query):
        # 使用 LLM 分解查询
        prompt = f"将以下查询分解为子任务：{query}"
        subtasks = self.llm.generate(prompt)
        return subtasks

3. Executor Agent（执行智能体）

功能：执行具体的检索和生成任务。

实现要点：

工具调用：根据任务需求调用相应的工具（向量数据库、图数据库、API 等）。
结果整合：整合多个工具的检索结果。
错误处理：处理执行过程中的异常情况。

python

class ExecutorAgent:
    def __init__(self, tools):
        self.tools = tools
    
    def execute_task(self, task):
        # 根据任务类型选择工具
        tool = self.select_tool(task)
        
        # 执行检索
        results = tool.search(task.query)
        
        # 整合结果
        integrated_results = self.integrate_results(results)
        
        return integrated_results
    
    def select_tool(self, task):
        if task.type == "vector_search":
            return self.tools["vector_db"]
        elif task.type == "graph_search":
            return self.tools["graph_db"]
        elif task.type == "api_call":
            return self.tools["api"]

4. Evaluator Agent（评估智能体）

功能：评估检索和生成结果的质量，提供反馈。

实现要点：

质量评估：评估检索结果的相关性和完整性。
反馈生成：生成改进建议和反馈。
迭代优化：根据评估结果调整检索策略。

python

class EvaluatorAgent:
    def __init__(self, llm):
        self.llm = llm
    
    def evaluate_results(self, query, results):
        # 评估相关性
        relevance_score = self.calculate_relevance(query, results)
        
        # 评估完整性
        completeness_score = self.calculate_completeness(query, results)
        
        # 生成反馈
        feedback = self.generate_feedback(relevance_score, completeness_score)
        
        return feedback
    
    def calculate_relevance(self, query, results):
        # 计算相关性分数
        # 可以使用语义相似度、关键词匹配等方法
        pass

工作流程

Agentic RAG 的典型工作流程如下：

查询接收：接收用户查询。
意图分析：Router Agent 分析查询意图。
任务规划：Planner Agent 制定执行计划。
任务执行：Executor Agent 执行检索和生成任务。
结果评估：Evaluator Agent 评估结果质量。
反馈优化：根据评估结果进行迭代优化。
结果输出：返回最终结果。

Agentic RAG 与传统 RAG 对比

特性	传统 RAG	Agentic RAG
决策能力	静态，预定义流程	动态，自主决策
查询处理	单步检索	多步推理和迭代优化
工具使用	有限，主要是向量检索	丰富，支持多种工具和 API
适应性	固定策略	自适应策略
可解释性	中等	较高，通过决策过程展示
复杂性	较低	较高，需要智能体编排
性能	适合简单查询	适合复杂查询
资源需求	较低	较高，需要多个智能体

核心差异分析

决策模式：传统 RAG 采用静态的检索-生成流程，而 Agentic RAG 引入了自主决策能力，能够根据查询特点动态调整策略。
推理能力：传统 RAG 主要进行单步检索，而 Agentic RAG 支持多步推理和迭代优化，能够处理更复杂的查询。
工具集成：传统 RAG 主要依赖向量检索，而 Agentic RAG 可以集成多种工具和 API，扩展了系统的功能。
适应性：传统 RAG 采用固定策略，而 Agentic RAG 能够根据查询反馈动态调整策略，提高系统性能。

Agentic 样式

Agent 通常由四部分组成：

LLM：作为代理的主要推理引擎和对话接口，负责解释用户查询，生成响应，并保持连贯性。
记忆（短期和长期）：在交互过程中捕捉上下文和相关数据。短期记忆跟踪即时对话状态，而长期记忆存储积累的知识和代理经验。
规划（反思和自我批评）：通过反思、查询路由或自我批评指导代理的迭代推理过程，确保有效地拆分复杂任务。
工具（向量搜索、网络搜索、API 等）：扩展代理的能力，使其不仅限于文本生成，还能够访问外部资源、实时数据或专门的计算。

更多关于 Agent 的知识见 4 Agent 篇

Reflection

代理迭代地评估和改进其输出，以识别和解决错误、不一致性和改进空间，提高在代码生成、文本生成和问题回答等任务中的性能。在实际应用中，反思涉及促使代理对其输出进行正确性、风格和效率的批判，并将这些反馈纳入后续的迭代中。外部工具如单元测试或网络搜索，可以进一步增强这个过程，验证结果并突出差距。

通过不断地迭代精炼，可以提高多步骤推理任务的准确性。在多代理系统中，反思可以涉及不同的角色，例如一个代理生成输出，而另一个代理对其进行批判，促进协作改进（类似强化学习的 Actor-Critic 算法）。例如，在法律研究中，代理可以通过重新评估检索到的案例法来迭代地改进回答，确保准确性和全面性。

Planning

规划使代理能够自主地将复杂任务分解为更小、可管理的子任务，创建结构化的工作流程和任务序列，高效地解决问题。目标在于通过分解任务促进多步骤推理，通过优化任务优先级减少计算开销。例如，一个财务分析系统规划数据检索任务，以评估风险并提供建议。与反思等确定性工作流程相比，规划可能产生较不可预测的结果。

Tool Use

代理与外部工具、API 和知识库互动来扩展其能力。目标在于将系统功能扩展到预训练知识之外，通过集成外部资源实现特定领域的应用。通过将工具动态集成到工作流程中，代理可以适应复杂任务并提供更准确和与上下文相关的输出。例如，法务助理代理人从合同数据库中检索条款，并应用特定领域的规则进行合规性分析。

Multi-Agent

多个代理协同工作以解决复杂任务，代理之间进行通信和共享中间结果，确保整体工作流程高效和连贯。通过将子任务分配给专门的代理，这种模式提高了复杂工作流程的可扩展性和适应性。每个代理都有自己的记忆和工作流程，可以包括使用工具、反思或规划，实现动态和协作的问题解决。例如，在软件开发中，不同代理分别负责前端、后端、测试、算法。

提升 Agentic 性能的方法

Prompt Chaining：将复杂任务分解为多个步骤，每个步骤都建立在前一个步骤的基础上。这种结构化方法通过在继续前进之前简化每个子任务来提高准确性。然而，由于顺序处理，它可能会增加延迟。该方法适用于逐步推理，每个子任务都对最终输出有贡献的场景，例如数学推理。
Routing：对输入进行分类，并将其引导到适当的专门提示或处理过程。这种方法确保不同的查询或任务被单独处理，提高了效率和响应质量。适合不同类型的输入需要不同处理策略的场景，确保每个类别的最佳性能，例如智能客服。
Parallelization：并行化将一个任务分解为同时运行的独立的进程，从而减少延迟并提高吞吐量。它可以分为分段（独立子任务）和投票（多个输出以提高准确性）两种类型，例如内容审核。
Orchestrator-Workers：利用中央协调模型动态地将任务分解为子任务，分配给专门的工作模型，并编译结果。与并行化不同，它能够适应不同的输入复杂性。
Evaluator-Optimizer：评估器-优化器工作流程通过生成初始输出并根据评估模型的反馈进行改进，迭代地提高内容质量。例如 Actor-Critic 算法。

Agentic RAG 分类

Single-Agent Agentic RAG

Single-Agent Agentic RAG 作为一个集中的决策系统，负责管理信息的检索、路由和整合，适用于有限工具或数据源的设置，可扩展性有限，对于多步推理或大型数据集表现较差。

举例：《Search-o1: Agentic Search-Enhanced Large Reasoning Models》

Multi-Agent Agentic RAG

Multi-Agent Agentic RAG 通过利用多个专门的代理来处理复杂的工作流程和多样化的查询类型。该系统不再依赖于单个代理来管理所有任务（推理、检索和响应生成），而是将责任分配给多个代理，每个代理针对特定的角色或数据源进行了优化。对于分布式、多步骤任务的性能更好，增加模块化和可扩展性。

举例：《Agentic Retrieval-Augmented Generation for Time Series Analysis》

一个电商场景下的实际案例：

上图案例的回复：

"您的美国仓直发羽绒服目前仍处于运输中（物流单号：US20240715-001，预计 3 天后抵达您所在城市）。根据《跨境电商退货管理办法》第三章第五条规定，未签收商品可申请物流拦截退货，国际段运费（$50）将从退款中扣除，关税部分需您在退货时提供原始报关单照片（上传入口：订单详情页> 退货申请 > 关税材料）。

如需立即处理，可点击此处申请物流拦截 <操作链接>，拦截成功后系统将自动生成退货单（无需签收商品）。退款预计在仓库确认商品状态无误后 15 个工作日内原路返回，关税退还流程同步启动（预计额外 3 个工作日）。

如需人工复核或修改地址，可直接回复 "转接客服"，当前客服专员已获取您的订单详情，将优先为您处理。"

这是一个电商场景的案例。

用户 Query："美国仓羽绒服未签收，退货关税怎么处理？"

意图识别模块判定为"跨境未签收退货"场景。

Router Agent 分配任务：

给跨境政策 Agent：检索《跨境电商退货管理办法》第 5 条（关税退还条件）。
给物流 Agent：调用 DHL API 获取包裹状态（运输中，可拦截）。
给财务 Agent：查询 ERP 系统中"未签收退货的关税计算规则"。
不做：不直接处理政策文本内容、物流 JSON 数据或财务公式计算，仅决定"谁该做什么"。

数据集成：三个 Agent 返回的数据格式不同（政策 PDF 段落、物流 API 的 JSON、财务系统的 SQL 结果），由独立的数据集成模块统一为：

Plain

{  
  "政策依据": "第三章第五条 未签收商品关税需凭报关单申请",  
  "物流状态": "运输中，可申请拦截（链接：XXX）",  
  "关税计算": "国际运费$50从退款扣除，关税需上传报关单"  
}

LLM 合成：根据上述结构化数据，LLM 生成自然语言 response，Router Agent 不参与内容生成，仅确保数据按正确顺序输入 LLM。

在本案例中，Agentic RAG 的优点在于：用户获得的不再是 "碎片化政策条款"，而是 "包含具体操作路径的解决方案"；系统不再是 "被动响应查询"，而是 "主动诊断场景并提供最优路径"。

不过 Agentic RAG 并非尽善尽美，依据最近阅读的论文：Why Do Multi-Agent LLM Systems Fail? 分析一下本案例可能会存在的实际问题：

不遵守任务规范

问题：Agent 未严格遵循用户查询的具体要求，导致解决方案偏离核心需求。
若用户明确要求"提供未签收商品的关税退还流程"，但跨境政策 Agent 错误引用"已签收商品退货政策"，导致回复中包含"需先签收再申请"的错误步骤，违反用户对"未签收场景"的任务规范。

不遵守角色规范

问题：Agent 越权或混淆角色职责，破坏分工协作逻辑。
财务 Agent 本应负责运费计算，却越权调用物流 API 获取包裹状态，导致物流 Agent 的职责被架空，流程混乱（如财务 Agent 错误判断"包裹已签收"，错误计算关税）。

步骤重复

问题：Agent 重复执行已完成的任务，浪费计算资源并延长响应时间。
案例映射：物流 Agent 已返回"包裹运输中，可拦截"，但协调 Agent 未记录状态，再次触发物流 Agent 重复查询同一包裹状态，导致响应延迟 10 秒以上。

对话历史丢失

问题：Agent 在多轮对话中丢失关键上下文，导致逻辑断裂。
案例映射：用户补充"退货时需要保留原包装吗？"，但 Agent 因丢失前期"未签收拦截"的对话历史，错误引用"已签收退货需保留包装"的政策，导致回复矛盾。

……

诸如此类的问题仅通过改进 Prompt（如更明确的角色定义）只能部分缓解，但无法根治，需要一些结构性策略（如标准化通信协议、强化验证机制）。

分层 Agentic RAG

分层 Agentic RAG 系统采用结构化的多层次方法进行信息检索和处理，代理按层次结构组织，高级代理监督和指导低级代理。这种结构实现了多级决策，确保查询由最合适的资源处理。

Agentic Corrective RAG

Corrective RAG 引入了自我纠正检索结果的机制，迭代地改进上下文文档和响应，最小化错误并最大化相关性。

举例：《Agentic AI-Driven Technical Troubleshooting for Enterprise Systems: A Novel Weighted Retrieval-Augmented Generation Paradigm》《Corrective RAG (CRAG)》

Adaptive Agentic RAG

其思想在于根据任务需求动态调整检索策略和工作流程。工作流程为：代理评估查询及其上下文 → 基于可用数据和用户需求实时调整检索策略 → 使用动态工作流程合成响应。

Graph-Based Agentic RAG

将图知识库与非结构化文档检索相结合。通过结合结构化和非结构化数据源，利用图知识库和反馈循环动态分配任务给专业代理，提高了 RAG 系统的推理和检索准确性。

例子：《Agent-G: An Agentic Framework for Graph Retrieval Augmented Generation》

Agentic 文档工作流

Agentic Document Workflows 通过实现端到端的知识工作自动化，扩展了传统的 RAG 范式。这些工作流程协调以文档为中心的复杂过程，集成了文档解析、检索、推理和结构化输出，并与智能代理结合。

Agentic RAG ​

RAG 发展历程 ​

Naive RAG ​

Advanced RAG ​

Modular RAG ​

Graph RAG ​

Agentic RAG ​

Agentic RAG 实现框架 ​

核心架构 ​

组件详细说明 ​

1. Router Agent（路由智能体） ​

2. Planner Agent（规划智能体） ​

3. Executor Agent（执行智能体） ​

4. Evaluator Agent（评估智能体） ​

工作流程 ​

Agentic RAG 与传统 RAG 对比 ​

核心差异分析 ​

Agentic 样式 ​

Reflection ​

Planning ​

Tool Use ​

Multi-Agent ​

Agentic RAG 分类 ​

Single-Agent Agentic RAG ​

Multi-Agent Agentic RAG ​

分层 Agentic RAG ​

Agentic Corrective RAG ​

Adaptive Agentic RAG ​

Graph-Based Agentic RAG ​

Agentic 文档工作流 ​

Agentic RAG

RAG 发展历程

Naive RAG

Advanced RAG

Modular RAG

Graph RAG

Agentic RAG

Agentic RAG 实现框架

核心架构

组件详细说明

1. Router Agent（路由智能体）

2. Planner Agent（规划智能体）

3. Executor Agent（执行智能体）

4. Evaluator Agent（评估智能体）

工作流程

Agentic RAG 与传统 RAG 对比

核心差异分析

Agentic 样式

Reflection

Planning

Tool Use

Multi-Agent

Agentic RAG 分类

Single-Agent Agentic RAG

Multi-Agent Agentic RAG

分层 Agentic RAG

Agentic Corrective RAG

Adaptive Agentic RAG

Graph-Based Agentic RAG

Agentic 文档工作流