之前介绍完成 RAG 的完整链路Chunking - Embedding - Vector DB - Retriever - Rerank。这是传统的 RAG 流程这是针对一次性检索信息。但是很多时候用户的问题并不能通过一次检索就能解决而是需要多步推理计算和查询多源信息并且需要拆解问题补充说明再验证。对于传统的 RAG 面对这些情况可能会答错不全面或者是编造。Agentic RAG 是 RAG 演进的下一个阶段从“一次检索生成”到“带思考、带策略、带工具”多步检索生成。Agentic RAG 把 Agent 智能体的“思考-行动-观察”能力引入了 RAG 系统检索和生成变成了一个动态、多步、校验、有策略的过程。区别对比Traditional RAGAgentic RAG核心思想固定检索流程Agent 动态决定检索策略Query通常一次可以多次改写Retrieval固定动态选择数据源通常固定可以多个工具调用较少可以调用多个 Tool是否会反思通常不会可以判断结果是否足够多轮检索较弱强复杂问题一般更适合成本较低更高延迟较低较高系统复杂度较低较高Agentic RAGRAGAgent 控制循环检索不再是前置步骤而是接入 Agent。User Query↓Agent 推理要不要检索检索什么去哪检索↓调用工具Vector / BM25 / SQL / API / Web / KG↓观察结果相关吗够吗冲突吗↓决定直接答 / 改写查询再检 / 换数据源 / 拆子问题 / 终止↓最终生成检索次数增加了对于检索到的内容会进行相关性、充分性、冲突性评估如果是返回错误信息可以针对性重写、换源、补检、降级等决策由 LLM/Agent 运行时决策本质上从“检索管道”变成了“推理驱动的知识系统”。解决什么问题传统的 RAG 中会出现一些坑多跳问题“2024 年诺贝尔物理学奖得主的博士导师是谁”传统RAG 经过一轮检索得到的信息是“获奖者是谁”并没有拿到最终的答案。Agentic RAG先查获奖者 - 发现信息不足 - 改写为“某某”的博士导师是谁 - 重新再检一次。用户表达问题“这个退费规则改完后还能不能退”传统 RAGEmbedding 模型将问题转换成向量向量数据库根据相似度寻找相关文档。但是相关文档关于退费规则的文档有多个Embedding不会自动知道“这个”具体指哪次修改也不一定能识别用户想问的是新规则是否适用于某笔历史订单。Agentic RAG查询改写 - 实体补全 - HyDE - 子问题拆分。多数据源问题“为什么用户张三没有收到优惠券”用户信息优惠券发放记录优惠券发放规则系统日志等涉及多个数据源。传统 RAG单独查询其中一个数据源不能回答整个问题最后生成的答案可能是因为张三不符合领取条件或者优惠券已经发完。但是并没有查证张三的任何情况。Agentic RAG对问题进行拆解按照不同的问题选择不同的数据源语义问题-向量库实体关系- 知识图谱结构化统计- SQL实时信息- Web/API。Agent 负责决定查什么Tool 负责安全访问数据源RAG 负责从知识库中检索相关知识。检索质量不可信“这个退费规则改完后还能不能退”传统 RAG系统检索到的退费规则可能是旧版本的或者是检索到的内容只是部分相关LLM 根据不完整的文档生成了一个看似合理实际上错误的答案。这时候传统 RAG 只能通过程序员主动设计代码去检查质量但是并不能在证据不足的时候表达出合理的答案。Agentic RAG检索↓评估证据↓发现缺口或冲突↓分析缺少什么信息↓决定下一步行动├── 改写查询├── 更换检索方式├── 查询其他知识库├── 调用业务 API└── 询问用户或转人工↓重新评估证据↓回答、继续调查或停止Agentic RAG 常见模式Router RAG 路由型用户问不同的问题走不同的知识库/工具。一般分为两种规则路由根据预先定义的规则分发请求语义路由利用 LLM 或分类模型理解用户意图再决定处理路径。在实现上需要考虑路由置信度、默认路由、异常处理、权限检验和调用成本。一般来说企业级 Agent优先使用确定性规则处理边界明确的业务再使用语义路由处理复杂表达通过结构化输出约束可选目标。用户: 今天天气怎么样 → 路由到天气 API用户: Spring 事务怎么配置 → 路由到技术文档向量库用户: 帮我查一下订单 12345 的状态 → 路由到订单数据库架构用户问题↓RouterLLM 判断├── 技术文档 → 向量检索├── 实时信息 → 搜索引擎 API├── 业务数据 → 数据库查询└── 闲聊 → 直接回答↓生成答案代码from llama_index.core import VectorStoreIndex, SimpleDirectoryReaderfrom llama_index.core.tools import QueryEngineTool, ToolMetadatafrom llama_index.agent.openai import OpenAIAgent# 1. 建两个知识库tech_docs SimpleDirectoryReader(./tech_docs).load_data()hr_docs SimpleDirectoryReader(./hr_docs).load_data()tech_index VectorStoreIndex.from_documents(tech_docs)hr_index VectorStoreIndex.from_documents(hr_docs)tech_engine tech_index.as_query_engine()hr_engine hr_index.as_query_engine()# 2. 定义工具tech_tool QueryEngineTool(query_enginetech_engine,metadataToolMetadata(nametech_docs,description查询技术文档包括 Spring、Java、数据库等技术问题))hr_tool QueryEngineTool(query_enginehr_engine,metadataToolMetadata(namehr_docs,description查询人事制度包括请假、报销、年假等政策问题))# 3. 创建 Agentagent OpenAIAgent.from_tools(tools[tech_tool, hr_tool],system_prompt你是一个企业助手根据问题类型选择合适的知识库回答。)# 4. 使用response agent.chat(年假天数是多少)print(response)response agent.chat(Spring 事务怎么配置)print(response)适用场景多个知识库技术文档、FAQ、政策文件、产品手册需要外部工具搜索、计算、API问题类型明确定检索。Query Rewriting Loop 查询改写循环迭代式检索优化模式第一次检索结果不好系统会分析检索失败的原因利用规则或者是 LLM 改写查询重新检索并评估新一轮的结果。在实际工程中需要设置最大迭代次数、质量阈值、超时和成本预算在证据不足时允许系统停止或转向其他工具避免无限重试和无依据回答。用户: 哪个事务的坑↓第 1 次检索: 哪个事务的坑 → 结果差↓改写: Spring 事务常见问题和避坑指南↓第 2 次检索: 结果好 → 生成答案架构用户问题↓循环最多 N 次:1. 检索2. 评估检索质量LLM 判断3. 如果够好 → 退出循环4. 如果不够好 → 改写查询 → 回到 1↓生成答案代码from llama_index.core import VectorStoreIndexfrom llama_index.core.postprocessor import SentenceTransformerRerankindex VectorStoreIndex.from_documents(docs)retriever index.as_retriever(similarity_top_k5)rerank SentenceTransformerRerank(modelBAAI/bge-reranker-large, top_n3)def evaluate_retrieval(query, nodes):让 LLM 评估检索质量context \n.join([n.text for n in nodes])eval_prompt f判断以下检索结果是否能回答用户问题。问题{query}检索结果{context}如果足够回答输出 YES。如果不够输出 NO 并说明缺少什么信息。# 调用 LLM 判断return llm.complete(eval_prompt).textdef agentic_retrieve(query, max_iterations3):多轮检索循环for i in range(max_iterations):# 1. 检索nodes retriever.retrieve(query)reranked rerank.postprocess_nodes(nodes)# 2. 评估evaluation evaluate_retrieval(query, reranked)if YES in evaluation:return reranked# 3. 改写查询rewrite_prompt f原始问题{query}当前检索结果不够好因为{evaluation}请改写问题使其更容易检索到相关信息。只输出改写后的问题。query llm.complete(rewrite_prompt).textprint(f迭代 {i1}: 改写为 {query})return reranked # 达到上限返回当前结果# 使用results agentic_retrieve(哪个事务的坑)适合场景用户问题模糊/口语化检索效果不稳定需要多轮优化。Multi-Step Reasoning 多步推理模式把一个复杂问题拆成的多个相互关联的子问题逐步获取信息、分析结果再将各个步骤的结果组合起来最终完成任务。在具体实现上可以使用固定工作流、DAG 或者是状态机组织任务如果需要根据中间结果动态决策可以引入 Agent Planner 和工具调用机制。多步推理的过程中并不能自动保证正确性需要对关键证据进行校验设置最大执行步骤、超时、成本预算和明确终止条件。用户: 对比 Spring 事务和分布式事务的区别Step 1: 检索 Spring 事务的定义和特点Step 2: 检索 分布式事务的定义和特点Step 3: 检索 事务对比本地 vs 分布式Step 4: 综合所有结果生成对比答案。架构用户问题↓规划Planner: 拆成子问题↓逐个执行:Sub-query 1 → 检索 → 结果 1Sub-query 2 → 检索 → 结果 2Sub-query 3 → 检索 → 结果 3↓综合Synthesizer: 合并结果 → 最终答案代码from langgraph.graph import StateGraph, ENDfrom typing import TypedDict, Listclass State(TypedDict):query: strsub_queries: List[str]results: List[str]final_answer: strdef planner(state: State):拆解问题prompt f把以下问题拆成 2-3 个子问题逐个检索后综合回答。问题{state[query]}输出子问题列表每行一个。response llm.complete(prompt).textsub_queries [q.strip() for q in response.split(\n) if q.strip()]return {sub_queries: sub_queries}def retriever_node(state: State):逐个检索子问题results []for sq in state[sub_queries]:nodes retriever.retrieve(sq)results.append(f子问题{sq}\n答案片段{nodes[0].text[:200]})return {results: results}def synthesizer(state: State):综合答案prompt f基于以下检索结果回答原始问题。原始问题{state[query]}检索结果{chr(10).join(state[results])}请给出完整、准确的答案。answer llm.complete(prompt).textreturn {final_answer: answer}# 构建图graph StateGraph(State)graph.add_node(planner, planner)graph.add_node(retriever, retriever_node)graph.add_node(synthesizer, synthesizer)graph.set_entry_point(planner)graph.add_edge(planner, retriever)graph.add_edge(retriever, synthesizer)graph.add_edge(synthesizer, END)app graph.compile()# 运行result app.invoke({query: 对比 Spring 事务和分布式事务的区别})print(result[final_answer])适合场景对比类问题分析类问题需要多角度信息的复杂问题Agentic RAG 整体架构使用场景企业智能知识库企业内部文档分散在不同系统员工提问比较模糊传统 RAG 可能检索不到准确信息。企业内部知识库技术文档助手员工制度与流程查询客服知识库。生产故障诊断和智能运维生产环境发生异常时开发和运维需要结合日志、监控指标、系统架构、历史故障记录等多种不过信息进行排查。传统 RAG 可以检索到历史故障案例但是不会主动调用监控系统和日志平台获取当前故障信息。Agentic RAG 可以将原本需要工程师手动完成的多系统信息收集和故障分析转化为可编排的诊断流程。复杂业务问题分析传统 RAG 擅长回答一个相对明确的问题但是复杂问题涉及多个系统、多个知识来源、不同的业务规则。智能客服和售后服务客户的问题可能同时涉及产品知识、订单状态、物流信息、退款规则等不同类型的数据。Agentic RAG 可以根据问题动态选择处理路径。电商客服银行与支付客服物流售后SaaS 产品支持企业服务台。研发智能助手代码库问答代码变更影响分析线上问题排查技术方案辅助设计API 文档查询等等。法律、合规与金融风险分析要求回答能够追溯到具体证据。判断维度传统 RAG 更合适Agentic RAG 更合适问题复杂度单一、明确的问题多条件、复杂问题检索流程固定检索流程需要动态调整检索策略数据来源单一知识库多知识库、多系统工具调用不需要外部操作需要 API、数据库等工具检索失败接受返回有限结果需要改写查询、补充证据或切换数据源任务执行只需回答问题需要规划、执行和验证多个步骤系统成本希望尽可能低可以接受额外的调用与执行成本常见问题坑现象解法过度检索简单问题也拆成多步慢且贵加路由判断简单问题直接走传统 RAG循环不收敛改写来改写去永远不满意设最大迭代次数3~5 次工具选择错误该查数据库却去搜网页优化工具描述让 LLM 更容易判断上下文爆炸多步检索结果太多超窗口每步压缩最终综合时再筛选延迟太高用户等太久并行检索子问题、缓存、流式输出成本失控LLM 调用次数太多简单问题短路、缓存高频结果Graph RAG顺便介绍一下 Graph RAG负责把知识库构建成知识图谱Knowledge Graph用图结构实体-关系-实体来组织和检索信息让 LLM 能沿着关系路径找到答案。把知识从“文本块”变成“关系网”相当于将所有的知识整理成一份思维导图。知识图谱 节点实体 边关系 属性例子(张三) —[任职于]→ (技术部)(技术部) —[隶属于]→ (公司A)(张三) —[负责]→ (项目X)(项目X) —[使用技术]→ (Spring Boot)用户问张三负责的项目用了什么技术图检索路径张三 → 负责 → 项目X → 使用技术 → Spring Boot答案SpringBoot区别传统 RAG根据问题找到最相关的段落Graph RAG除了找到相关内容还利用人物、组织、事件、系统之间的关系把分散的知识关联起来。Agentic RAG根据问题决定先查什么、再查什么、调用哪个工具以及什么条件终止。Graph RAG 主要是增强知识组织和检索Agentic RAG 主要增强任务规划和动态执行。技术主要解决的问题Keyword Search如何精确找到包含指定关键词的内容Vector Search如何找到语义相关的文本RAG如何利用检索到的知识增强 LLM 的回答Knowledge Graph如何组织实体及其关系GraphRAG如何利用图结构增强知识检索与答案生成Agentic RAG如何让系统动态规划检索、工具调用和多步任务完整架构离线构建实体抽取从文档中提取实体人、组织、地点、概念、产品等输入文档张三在技术部工作负责项目X项目X使用 Spring Boot 和 MySQL。抽取结果实体张三人、技术部部门、项目X项目、Spring Boot技术、MySQL技术关系抽取识别实体之间的关系抽取结果(张三) —[任职于]→ (技术部)(张三) —[负责]→ (项目X)(项目X) —[使用技术]→ (Spring Boot)(项目X) —[使用技术]→ (MySQL)存入图数据库Neo4j/NebulaGraph/TigerGraph 等。在线查询用户提出问题│▼① 问题理解与分析│▼② 检索策略选择│┌───────────┼───────────┐▼ ▼ ▼向量检索 关键词检索 图检索│ │ │▼ ▼ ▼相关文本 关键词文档 实体、关系、路径│ │ │└───────────┼───────────┘▼③ 结果融合与排序│▼④ 证据整理与验证│▼⑤ 构建上下文│▼⑥ LLM 生成│▼⑦ 输出答案与依据代码用 LlamaIndex构建 Graph RAGfrom llama_index.core import SimpleDirectoryReaderfrom llama_index.core.indices.property_graph import PropertyGraphIndexfrom llama_index.llms.openai import OpenAIfrom llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore# 1. 加载文档documents SimpleDirectoryReader(./docs).load_data()# 2. 配置图存储graph_store Neo4jPropertyGraphStore(usernameneo4j,passwordpassword,urlbolt://localhost:7687,)# 3. 构建 Property Graph Indexindex PropertyGraphIndex.from_documents(documents,llmOpenAI(modelgpt-4o),graph_storegraph_store,show_progressTrue,)# 4. 查询query_engine index.as_query_engine()response query_engine.query(张三负责的项目用了什么技术)print(response)response query_engine.query(技术部和产品部之间有什么关系)print(response)混合模式向量图谱from llama_index.core import VectorStoreIndexfrom llama_index.core.query_engine import RetrieverQueryEnginefrom llama_index.core.retrievers import QueryFusionRetriever# 向量检索vector_index VectorStoreIndex.from_documents(documents)vector_retriever vector_index.as_retriever(similarity_top_k5)# 图谱检索graph_retriever index.as_retriever(top_k5)# 混合hybrid_retriever QueryFusionRetriever(retrievers[vector_retriever, graph_retriever],fusion_modereciprocal_rank_fusion,top_k10,)query_engine RetrieverQueryEngine.from_args(hybrid_retriever)response query_engine.query(Spring 事务和分布式事务的区别)print(response)适用场景场景需要 Graph RAG理由简单 FAQ否传统RAG够用单文档问答否不需要跨文档关系企业知识库人/部门/项目/技术是实体关系复杂科研文献分析是作者/论文/概念/引用关系金融风控是人物/公司/交易关系医疗诊断是症状/疾病/药物/相互作用法律分析是法条/案例/当事人关系全局摘要是社区摘要能力强总结传统RAG解决“知不知道资料里有这句话”。Agentic RAG解决“会不会主动把资料查明白”。GraphRAG解决“能不能看懂资料里的人和事是怎么连起来的”。