从查一次就生成到想清楚再回答——让检索增强生成学会自主思考如果你在项目里用过 RAG检索增强生成一定经历过这个时刻用户问了一个复杂问题你的 pipeline 老老实实地检索了 top-5 文档块塞进 prompt生成答案——结果牛头不对马嘴。问题不在模型质量而在于传统的 RAG 假设一次检索就够了。但现实世界的复杂问题——跨文档推理、多跳问答、需要先收集信息再判断的问题——一锤子检索永远搞不定。Agentic RAG正是为了解决这个痛点而诞生把检索从一次性查询升级为自主推理闭环。Agent 不再被动地接收检索结果然后生成而是像一个研究员一样——拆解问题、多次检索、评估信息质量、重写查询、决定何时停止、何时换个角度再来一次。本文会从以下四个维度逐一拆解 Agentic RAG 的核心机制并给出可直接运行的代码实现路由 Agent根据问题类型选择最优检索策略查询重写让模糊问题变精确让检索命中率翻倍迭代检索 自检多次检索直到信息充分而不是一次就停多源融合与评分从多个知识源收集证据并交叉验证本文适合已有基础 RAG 实践经验的开发者想从能跑到跑得好。读完你将能实现一个具备自主检索决策能力的 Agentic RAG 系统。一、RAG 进化简史从 Naive 到 Agentic先厘清概念。RAG 的演进大致分四个阶段阶段模式检索次数决策主体典型失败场景Naive RAG一次检索 → 一次生成1无固定 pipeline取消订阅怎么操作 → 检索到账户注销政策完全不相关Advanced RAG混合检索 重排序 → 生成1无流水线优化检索质量更高了但复杂多跳问题仍无法处理Agentic RAGAgent 自主规划 → 多次检索 → 自检 → 最终生成2 ~ 10LLM AgentReAct 循环成本与延迟显著增加需精心设计停止条件Multi-Agent RAG多个专业 Agent 分工协作每个 Agent 2 ~ 5协调器 专业 Agent编排复杂度高Agent 间通信可能出错本文重点拆解Agentic RAG这一层。它不是 Multi-Agent RAG 的平替而是后者的基础单元——先把一个 Agent 的自主检索能力做扎实再说多 Agent 协作。⚡ 关键思维转变在 Naive RAG 中你问怎么检索最相关的文档在 Agentic RAG 中你问Agent 需要什么信息才能回答这个问题它要怎么找找了之后够了吗——检索从机械动作变成了推理过程的一部分。二、Agentic RAG 的核心架构Agentic RAG 的心智模型可以用一个循环来描述用户问题 → [路由] → [查询重写] → [检索] → [评估] → ──不够──┐↑ │└──────────── [重写查询、换策略] ──┘↓ 够了[融合 生成最终答案]路由 Agent判断问题类型事实型/推理型/对比型选择最强检索策略避免用同一套路回答所有问题。✏️查询重写将用户自然语言查询转换为更适合检索的精确表达包括关键词提取、同义词扩展、子问题拆分。迭代检索 自检检索后先自检信息够了吗相关吗不够就换个角度再搜。这是 Agentic 区别于 Naive 的核心差异。多源融合向量库、关键词索引、SQL 数据库、Web API——不同工具擅长不同查询Agent 自主选择调用哪个。三、路由 Agent不同问题不同策略传统 RAG 对所有问题一视同仁向量化 → 搜 top-k → 生成。但特斯拉 Model Y 的续航是多少和比较特斯拉和小鹏的自动驾驶技术路线是本质不同的两类问题。前者一句话就能回答后者需要多轮检索和深度合成。路由 Agent在检索开始前先做一次分类将问题路由到最合适的检索策略from typing import Literal from langgraph.graph import StateGraph, END from pydantic import BaseModel, Field # --- 定义路由类别 --- class RouteDecision(BaseModel): category: Literal[factual, comparison, multi_hop, analytical] Field( description问题类型factual简单事实, comparison对比, multi_hop多跳推理, analytical深度分析 ) reasoning: str Field(description分类理由) class AgentState(BaseModel): query: str route: RouteDecision | None None retrieved_docs: list[str] [] evaluation: dict {} final_answer: str # --- 路由节点让 LLM 决定走哪条策略 --- async def router_node(state: AgentState) - AgentState: prompt f分析以下用户问题决定最佳检索策略 问题{state.query} - factual简单事实查询一次精确检索即可 - comparison对比两个或多个对象需要分别检索并比较 - multi_hop需要多步推理上一步结论影响下一步检索 - analytical需要深度分析可能涉及多轮检索和综合判断 请以 JSON 格式返回{{category: ..., reasoning: ...}} response await llm.invoke(prompt) state.route RouteDecision.model_validate_json(response) return state # --- 四种检索策略 --- async def factual_search(state: AgentState) - AgentState: 高精度单次检索top-k 取小threshold 取高 docs await vector_store.similarity_search( state.query, k3, score_threshold0.85 ) state.retrieved_docs [d.page_content for d in docs] return state async def comparison_search(state: AgentState) - AgentState: 拆分比较对象各自检索再合成 # Step 1: 让 LLM 提取比较对象 entities_prompt f请从以下问题中提取需要对比的对象列表JSON数组\n{state.query} entities json.loads(await llm.invoke(entities_prompt)) all_docs [] for entity in entities: docs await vector_store.similarity_search( f{entity} 核心特性 技术路线, k5 ) all_docs.extend([f[{entity}] {d.page_content} for d in docs]) state.retrieved_docs all_docs return state async def multi_hop_search(state: AgentState) - AgentState: [检索→推理→生成新查询→再检索] 循环 for round_num in range(3): docs await vector_store.similarity_search(state.query, k5) state.retrieved_docs.extend([d.page_content for d in docs]) # 基于已有信息生成下一个查询 next_query_prompt f基于已有信息{state.retrieved_docs[-3:]} 原始问题{state.query} 如果想完整回答原始问题还需要了解什么生成一个新的检索查询。 如果信息已经足够回复 ENOUGH。 next_query await llm.invoke(next_query_prompt) if ENOUGH in next_query: break state.query next_query.strip() return state async def analytical_search(state: AgentState) - AgentState: 多角度多源检索向量 关键词 可能涉及工具调用 # 向量检索 vector_docs await vector_store.similarity_search(state.query, k8) # 关键词检索BM25补充精确匹配 keyword_docs bm25_index.search(state.query, k8) # 去重 融合Reciprocal Rank Fusion fused reciprocal_rank_fusion(vector_docs, keyword_docs, k10) # 重排序提纯 state.retrieved_docs await reranker.rerank( state.query, [d.content for d in fused], top_n5 ) return state路由的价值在于精准匹配策略与问题类型。对于简单事实查询走 factual 策略一次高质量检索就够延迟低、成本小。而对于推理型问题走 multi_hop多花点时间但答案质量显著提升。这是一个该省省该花花的调度智慧。四、查询重写把大白话翻译成检索语用户问最近有什么大新闻你不可能直接把这个句子向量化然后去搜——太模糊了。大新闻对向量而言就是 noise。查询重写就是把自然语言转成更适合检索的精确表达。4.1 三种重写策略策略原始查询重写后适用场景关键词提炼上次那个关于AI的法案通过了吗EU AI Act 2024 legislative status对话中有指代消解需求子问题拆分AI对医疗和教育的综合影响[AI在医疗领域的应用与影响, AI在教育领域的应用与影响]复合问题单一检索覆盖不了多视角重写GPT-5 值得升级吗[GPT-5新特性, GPT-5与GPT-4对比, GPT-5基准测试结果]评价类问题需要多角度信息4.2 子问题拆分最实用的重写策略from pydantic import BaseModel, Field class SubQueries(BaseModel): queries: list[str] Field(description子问题列表每个应能独立检索) class QueryRewriter: def __init__(self, llm, max_sub_queries: int 4): self.llm llm self.max_sub_queries max_sub_queries async def rewrite(self, query: str, context: list[str] | None None) - list[str]: context_str \n.join(context) if context else 无 prompt f将以下问题拆分为 {self.max_sub_queries} 个以内可独立检索的子问题。 每个子问题应 1. 独立完整不是对上一问的追问 2. 使用适合检索的关键词表达 3. 覆盖原问题的所有关键信息点 对话上下文{context_str} 用户问题{query} 以 JSON 格式返回{{queries: [子问题1, 子问题2, ...]}} response await self.llm.invoke(prompt) result SubQueries.model_validate_json(response) return result.queries # --- 使用示例 --- rewriter QueryRewriter(llm) queries await rewriter.rewrite( Spring AI 2.0 相比 1.x 有哪些改进对现有项目升级有什么注意事项 ) # 输出 # [Spring AI 2.0 新特性变更列表, # Spring AI 1.x 到 2.0 迁移指南 破坏性变更, # Spring AI 2.0 升级注意事项 兼容性]为什么子问题拆分效果显著经验数据表明将复合问题拆分为 3-4 个子问题分别检索答案完整度提升 35-50%。原因是向量检索本质上是找最相似的单一信息点——一个涵盖多主题的 query embedding不如多个单一主题的 query embedding 各自精准。五、迭代检索 自检Agentic 的灵魂这是 Agentic RAG 区别于传统 RAG 的最核心差异。Agent 在检索后不是直接生成而是先自检这些文档真的回答了用户的问题吗缺少哪些关键信息换个查询角度是不是能搜到更好的结果如果答案不满意Agent 会重写查询、换个检索策略、甚至调用不同的工具直到信息充分或达到最大迭代次数。import asyncio from dataclasses import dataclass, field dataclass class IterativeAgentState: query: str retrieved_docs: list[str] field(default_factorylist) iteration: int 0 sufficiency_score: float 0.0 missing_info: str class IterativeRAGAgent: def __init__(self, llm, retriever, max_iterations: int 5, sufficiency_threshold: float 0.8): self.llm llm self.retriever retriever self.max_iterations max_iterations self.sufficiency_threshold sufficiency_threshold async def run(self, query: str) - str: state IterativeAgentState(queryquery) while state.iteration self.max_iterations: # Step 1: 检索 docs await self.retriever.search(state.query, k5) state.retrieved_docs.extend([d.content for d in docs]) # Step 2: 自检 —— 信息够了吗 sufficiency await self.self_check(state) state.sufficiency_score sufficiency[score] state.missing_info sufficiency.get(missing, ) if state.sufficiency_score self.sufficiency_threshold: break # Step 3: 不够 → 重写查询换个角度搜 state.query await self.rewrite_query(state) state.iteration 1 # Step 4: 最终生成 return await self.generate_final(state) async def self_check(self, state: IterativeAgentState) - dict: 让 LLM 自评已有信息是否足以回答问题 prompt f评估当前检索到的信息是否足以回答原始问题。 原始问题{state.query} 已检索到的文档片段共 {len(state.retrieved_docs)} 条 {chr(10).join(f- {doc[:300]}... for doc in state.retrieved_docs[-5:])} 请给出 1. 充分性评分0.0-1.01.0 完全足够0.0 完全不够 2. 如果不够缺少什么关键信息 3. 建议下一轮搜索的关键词 以 JSON 格式返回{{score: 0.0-1.0, missing: 描述缺少的信息, suggested_query: 建议的搜索词}} response await self.llm.invoke(prompt) return json.loads(response) async def rewrite_query(self, state: IterativeAgentState) - str: prompt f已有文档未完全覆盖原始问题需要换个角度搜索。 原始问题{state.query} 已有信息但还缺少{state.missing_info} 请生成一个新的检索查询重点搜索缺失的信息。 直接返回查询字符串不要加其他内容。 return (await self.llm.invoke(prompt)).strip()⚠ 关键配置充分性阈值与最大迭代次数是 Agentic RAG 最需要调优的两个参数。阈值太低0.6容易过早停止、答案不完整阈值太高0.95会导致无限循环。建议从 0.8 开始并结合 RAGAS 指标Faithfulness ≥ 0.9, Answer Relevancy ≥ 0.85进行系统性评估后再微调。最大迭代次数建议 5实测中超过 5 轮的边际收益极低。六、多源融合向量库不够时要学会借工具纯向量检索只擅长语义相似匹配面对精确查询2026年Q1营收、实时数据今天的股价、结构化数据时就力不从心了。Agentic RAG 的 Agent 应该能自主决定调用哪种工具。from langgraph.prebuilt import ToolNode # --- 定义多种检索工具 --- async def vector_search_tool(query: str) - str: 语义搜索适合概念性、描述性问题 docs await vector_store.similarity_search(query, k5) return format_docs(docs) async def keyword_search_tool(query: str) - str: 关键词搜索适合精确术语、型号、API 名称 docs bm25_index.search(query, k5) return format_docs(docs) async def sql_query_tool(query: str) - str: SQL查询适合统计数据、聚合信息 # Agent 写 SQL → 执行 → 返回结果 sql await llm.invoke( f生成SQL查询以下问题表结构见schema:\n{query} ) return await db.execute(sql) async def web_search_tool(query: str) - str: 网络搜索适合实时信息、最新动态 results await search_api.search(query, num5) return format_results(results) # --- 将这些工具注册给 Agent --- tools [ vector_search_tool, keyword_search_tool, sql_query_tool, web_search_tool, ] # LangGraph 中Agent 自主选择调用哪个工具 agent create_react_agent(llm, tools) result await agent.invoke({ messages: [ HumanMessage(content对比2025年和2026年Q1的三个主要云服务商市场份额变化) ] })这个例子中Agent 会自动推理我需要市场数据走 SQL 工具也需要行业分析走向量工具还需要最近动态走 Web 搜索——然后自主编排调用序列并合成答案。工具选择的门当户对原则• 概念/原理类查询 → 向量语义搜索• 精确术语/型号/版本号 → BM25 关键词搜索• 统计/聚合/对比数据 → SQL 结构化查询• 实时动态/最新信息 → Web Search API不要把所有查询都扔进向量库。Agent 的智能体现在选对合适的工具。七、最终生成从堆文档到结构化输出经过多轮检索Agent 手里有了一堆来自不同来源的文档片段。最后一关是合成——不是简单的拼接而是去重、排序、甄别矛盾信息、补全逻辑缺口。class FinalGenerator: def __init__(self, llm): self.llm llm async def generate(self, query: str, docs: list[str], max_context_tokens: int 6000) - str: # Step 1: 去重 重排序把最相关的放在最前面 unique_docs deduplicate_by_similarity(docs, threshold0.92) ranked_docs await reranker.rerank(query, unique_docs, top_n10) # Step 2: 动态窗口优先保留高分文档超出 token 限制则截断低分文档 context_window build_context_window(ranked_docs, max_tokensmax_context_tokens) # Step 3: 带引用的最终生成 prompt f基于以下检索到的资料回答用户问题。 要求 1. 如果资料中有矛盾信息指出并说明你的判断依据 2. 对于关键事实在文末列出引用来源[1] [2]... 3. 如果信息不足明确指出哪些部分无法确认 参考资料 {context_window} 用户问题{query} return await self.llm.invoke(prompt)✨ 带引用的生成 vs 不带引用Agentic RAG 的优势不仅在于回答更准还在于可追溯。每个关键断言都能对应回检索到的文档——这对企业知识库、法律、金融等场景至关重要。单纯模型说对了不够模型能告诉我它为什么说对了才是目标。八、走向生产Agentic RAG 落地 Checklist⏱️延迟控制Agentic RAG 的延迟是 Naive RAG 的 3-8 倍。给简单查询设置快速路径路由 Agent 判为 factual 直接单轮生成不上循环控制最大迭代次数。成本管理每次自检都消耗一次 LLM 调用。用轻量模型如 GPT-4o-mini做自检和查询重写只在与用户交互和最终生成时用强模型。质量评估RAGAS 四指标Faithfulness、Answer Relevancy、Context Precision、Context Recall。上 Agentic 后 Context Recall 通常提升 20-35%。️安全边界Agent 能调用 SQL 和 API必须做好权限控制和请求频率限制。LLM 生成 SQL 时做语法校验禁止 DDL 操作。一句话总结 Agentic RAG 的价值它不是让检索更准而是让系统知道什么时候不准了然后想办法变准。这种元认知能力——对自己的知识边界有意识——正是 Agentic RAG 超越传统 RAG 的根本原因。写在最后RAG 的演进路线非常清晰Naive RAG → Advanced RAG混合检索 重排序→ Agentic RAG自主推理循环→ Multi-Agent RAG多智能体协作。当前行业的主流正从 Advanced 向 Agentic 过渡。对开发者来说关键不在于追逐最新的框架或论文而在于理解这背后的设计哲学让检索从一次性操作变成推理过程的一部分。路由 Agent 帮你选策略查询重写帮你把问题问清楚迭代自检帮你确保信息充分——这三个机制组合起来就能让一个跑 demo 的 RAG pipeline 变成能处理真实复杂问题的工作系统。技术的进步不在于让模型变得更大而在于让它变得更聪明地利用已有信息。Agentic RAG 就是这条路上的一块重要拼图。从一个路由 Agent 开始给简单问题快速通道、给复杂问题多加两轮思考——不需要一步到位一步步迭代即可。#Agentic RAG #检索增强生成 #LangGraph #Query Rewriting #Routing Agent #Self-Check #多源检索 #RAGAS #ReAct #AI Agent