——从一次检索就够了到想清楚再回答的完整进化之路引言当一次检索不够用的时候想象这样一个场景你问系统——对比一下在 vLLM 和 Ollama 上部署 Llama 3 的延迟和成本推荐哪个更适合我们的批量推理场景。标准 RAG 的处理流程很直接把整句话向量化 → 从文档库检索 top-k 片段 → 塞给 LLM 生成答案。这个流程对于什么是 API Key这种简单问答题绰绰有余但面对那个对比型问题你会发现向量检索只能抓到一个方向的文档另一半直接缺失系统不知道要拆分成子问题分别检索文档是检索到了但全是不相干的内容——系统连个这不对的自我判断都没有这就是Agentic RAG要解决的核心问题让检索系统学会思考——知道该搜什么、去哪搜、搜得对不对、要不要重搜。标准的 RAG 是一条流水线Agentic RAG 是一个会反思的智能体。一、RAG 进化简史从傻搜到会想回顾 RAG 的演进路径可以清晰地看到四个阶段阶段形态核心能力典型失败场景Naive RAG固定管线嵌入→检索→生成一次检索、一次生成检索不相关时束手无策Advanced RAG加前后处理重排序、混合检索提升单次检索质量复杂多步问题仍然吃力Agentic RAG状态机/Agent 循环反思、重写、自纠延迟增加需要重试上限Multi-Agent RAG多 Agent 协作分工、并行、校验协调复杂度高这个进化的本质很简单从相信一次检索能搞定到设计一个能自我纠错的系统。二、四种 Agentic 设计模式根据 2025 年 Singh 等人的综述论文Agentic RAG 有四种核心设计模式。它们是积木生产系统通常会组合使用模式 1反思Reflection——我刚才搜对了吗这是收益最高、实现最简单的模式。Agent 在检索后和生成后分别自检❌ 标准 RAG检索 → 直接生成。就算搜出来的是Python 蛇类养殖指南也硬着头皮回答Python 装饰器用法。✅ 反思 RAG检索 →问自己这些文档相关吗→ 不相关则重写查询 → 生成 →问自己回答有出处吗→ 没出处则重新生成。模式 2规划Planning——这个问题要先拆开面对复合问题Agent 先做任务分解再按计划逐步检索。这天然适合对比型、多条件型问题。模式 3工具使用Tool Use——该去哪个库查不同知识存在不同地方向量库存放非结构化文档、SQL 存放结构化数据、Web Search 获取实时信息。Agent 自主选择调用哪个工具。模式 4多 Agent 协作——分头去查回来汇总路由 Agent 把问题分发给专门的检索 Agent汇总 Agent 再统一整合。适合大型组织多知识源的场景。模式核心能力实现复杂度RAG 应用反思自评 重试⭐ 低文档质量打分、幻觉检测规划分解 排序⭐⭐ 中多步推理、子问题拆分工具使用选择合适工具⭐⭐ 中向量/SQL/Web 路由多 Agent分工 协调⭐⭐⭐ 高并行检索、交叉验证三、关键论文Self-RAG 与 CRAG两篇论文为 Agentic RAG 的实现提供了理论框架Self-RAGAsai et al., 2023核心思想训练 LLM 生成反思 Token控制检索全流程。四种关键 TokenToken决策输入输出Retrieve要不要检索问题yes / no / continueISREL文档相关吗问题 文档relevant / irrelevantISSUP答案有出处吗问题 文档 答案fully / partial / noISUSE答案有用吗问题 答案1-5 分关键洞察让检索自适应需要时才搜和自批判搜完检查质量Self-RAG 在开放域 QA、推理和事实验证上显著领先标准 RAG 和 ChatGPT。CRAG——Corrective RAGYan et al., 2024核心思想把检索失败当作常态事先设计好纠错路径。检索文档 → 轻量评估器打分Correct / Ambiguous / IncorrectCorrect → 直接生成Ambiguous → 补充 Web Search 结果Incorrect → 完全降级到 Web SearchKnowledge Refinement把文档拆成知识条逐条打分过滤无关内容关键洞察CRAG 不把检索失败当意外而是在架构层面设计好回退路径。四、LangGraph 实战构建可纠错的 RAG AgentLangGraph 把 RAG 的每一步建模成状态图中的节点把决策点建模成条件边。这是实现 Agentic RAG 最灵活的方式。4.1 架构总览┌──────────┐ ┌──────────────┐ ┌─────────────────┐ │ retrieve │────▶│ grade_docs │────▶│ 是否相关 │ └──────────┘ └──────────────┘ └───┬─────────┬───┘ │ Yes │ No ┌──────▼──┐ ┌──▼──────────┐ │ generate │ │ rewrite_query│ └────┬─────┘ └──┬──────────┘ │ │ ┌──────────▼──┐ │ │ 幻觉检测 │ │ └───┬────┬────┘ │ Yes │ │ No │ ┌──────────▼┐ │ │ │ 回答问题 │ │ 重新生成 ────┘ └───┬───┬───┘ │ Yes │ │ No │ ┌─────────▼┐ │ │ │ END │ │ 重写查询 ──▶ retrieve └──────────┘ │ │ (重试上限 3)4.2 状态定义from typing import TypedDict from langgraph.graph import StateGraph, END class AgentState(TypedDict): question: str # 当前问题可能被改写 documents: list[str] # 检索到的文档 generation: str # 生成的回答 web_search_needed: bool retry_count: int # 防无限循环的关键字段4.3 文档打分节点这是 Agentic RAG 最关键的一步让 LLM 判断检索结果是否相关。from pydantic import BaseModel, Field from langchain_core.prompts import ChatPromptTemplate class RelevanceGrade(BaseModel): is_relevant: bool Field( description文档与问题是否相关 ) grader_llm llm.with_structured_output(RelevanceGrade) GRADE_PROMPT ChatPromptTemplate.from_messages([ (system, 你是文档相关性评估器。判断文档是否与用户问题相关。), (human, 文档:\n{document}\n\n问题: {question}), ]) def grade_documents(state: AgentState) - AgentState: relevant_docs [] for doc in state[documents]: grade grader_llm.invoke( {document: doc, question: state[question]} ) if grade.is_relevant: relevant_docs.append(doc) return { **state, documents: relevant_docs, web_search_needed: len(relevant_docs) 0, }4.4 条件路由def should_search_web(state: AgentState) - str: 全部文档不相关 → 走 Web Search 降级路径 if state[web_search_needed]: return web_search return generate def check_generation(state: AgentState) - str: 生成后自检有幻觉重新生成。没回答到点重写查询。 if state.get(retry_count, 0) 3: return end # 兜底退出 # 幻觉检测 hallucination hallucination_grader.invoke(...) if not hallucination.is_grounded: return generate # 重新生成 # 答案质量检测 answer_check answer_grader.invoke(...) if not answer_check.answers_question: return rewrite_query # 换个问法重搜 return end4.5 图谱构建与运行workflow StateGraph(AgentState) workflow.add_node(retrieve, retrieve) workflow.add_node(grade_documents, grade_documents) workflow.add_node(rewrite_query, rewrite_query) workflow.add_node(web_search, web_search) workflow.add_node(generate, generate) workflow.set_entry_point(retrieve) workflow.add_edge(retrieve, grade_documents) workflow.add_conditional_edges( grade_documents, should_search_web, {web_search: web_search, generate: generate} ) workflow.add_edge(web_search, generate) workflow.add_conditional_edges( generate, check_generation, {end: END, rewrite_query: rewrite_query, generate: generate} ) workflow.add_edge(rewrite_query, retrieve) app workflow.compile() result app.invoke({ question: 对比 RLHF 和 DPO 的核心差异, retry_count: 0 })五、LlamaIndex 实战Agent 自主路由检索如果你的核心需求是跨多个数据源进行智能路由LlamaIndex 的 FunctionAgent 提供了更简洁的方案5.1 将查询引擎包装为工具from llama_index.core.tools import QueryEngineTool from llama_index.core.agent.workflow import FunctionAgent # 为不同文档集构建独立索引 index_api VectorStoreIndex.from_documents(docs_api) index_guides VectorStoreIndex.from_documents(docs_guides) tools [ QueryEngineTool.from_defaults( query_engineindex_api.as_query_engine(similarity_top_k5), nameapi_docs, description搜索 API 参考文档。用于函数签名、参数、返回值、端点等问题。, ), QueryEngineTool.from_defaults( query_engineindex_guides.as_query_engine(similarity_top_k5), nameuser_guides, description搜索用户指南和教程。用于操作步骤、架构概览、最佳实践。, ), ] agent FunctionAgent( toolstools, llmOpenAI(modelgpt-4o, temperature0), system_prompt( 你是文档助手。根据问题选择合适的工具搜索。 如果一个工具结果不够尝试其他工具。必须标注来源。 ), ) response await agent.run( user_msg如何为 API 请求添加认证给出代码示例。 )5.2 子问题自动拆分LlamaIndex 的 SubQuestionQueryEngine 可以自动将复杂问题拆解为子问题from llama_index.core.query_engine import SubQuestionQueryEngine sub_engine SubQuestionQueryEngine.from_defaults( query_engine_tools[ QueryEngineTool.from_defaults(deployment_engine, name部署文档), QueryEngineTool.from_defaults(pricing_engine, name定价文档), ], llmOpenAI(modelgpt-4o-mini), ) # 输入对比 vLLM 和 Ollama 部署 Llama 3 的成本和延迟 # 自动拆分为 # 子问题 1: vLLM 部署 Llama 3 的成本 # 子问题 2: vLLM 部署 Llama 3 的延迟 # 子问题 3: Ollama 部署 Llama 3 的成本 # 子问题 4: Ollama 部署 Llama 3 的延迟 response sub_engine.query(对比 vLLM 和 Ollama 部署 Llama 3 的成本和延迟)六、NgGraph vs LlamaIndex如何选择维度LangGraphLlamaIndex Agents编程范式显式状态图节点 边工具调用 Agent 循环控制流你定义每一个转换和条件Agent 自主决定工具调用顺序可观测性完整图可视化逐步 Trace工具调用日志、事件流灵活性最高——任何图拓扑高——可通过 Workflows 定制复杂度较高——需要更多代码较低——声明式工具定义最适合需要精确决策逻辑的自定义流程多数据源自主路由选择 LangGraph你需要精确控制每一步决策——文档打分后做什么、什么条件触发 Web Search、最多重试几次。选择 LlamaIndex Agents核心需求是多数据源智能路由让 LLM 自主决定检索策略。七、生产落地 Checklist7.1 防止无限循环Agentic RAG 的核心特点——循环Rewrite → Retrieve → Grade → Rewrite…——也是它的最大隐患。一定要在 State 中维护 retry_count硬上限通常设为 3-5 次。7.2 延迟与成本的平衡策略LLM 调用次数/查询延迟质量标准 RAG1低基准 文档打分1 kk文档数中更好 查询重写 重检索3-5较高显著提升完整自反思5-10高最佳优化建议打分用便宜模型GPT-4o-mini最终生成用强模型GPT-4o / Claude文档打分并行执行。7.3 什么时候不应该用 Agentic RAG问题是简单的事实查询——标准 RAG 配合好的 chunking 和 reranking 已经足够延迟是核心指标——每个 Agent 步骤增加 200-500ms语料库小而均匀——不需要在多个数据源之间路由预算有限——每次查询的 LLM 调用量是标准 RAG 的 5-10 倍核心理念先用标准 RAG 打好基础好的 chunking、混合检索、reranking然后根据评估结果在出问题的地方精准引入 Agentic 模式。八、评估维度Agentic RAG 的评估要比标准 RAG 多一个层次——不仅要评估检索和生成质量还要评估 Agent 的决策质量指标评估对象层级Recallk正确的文档是否被检索到检索层Answer Faithfulness回答是否忠于上下文生成层Answer Relevance回答是否切题生成层Grader Accuracy文档打分器判断是否正确Agent 层Routing Accuracy路由器选对工具了吗Agent 层Retry Efficiency重试是否提升了回答质量Agent 层Avg. Steps per Query平均每个问题走几步效率层总结Agentic RAG 不是要推翻标准 RAG而是在其之上的进化进化层级形态实现方式Level 0Naive RAG一次检索、一次生成固定 ChainLevel 1查询路由选最合适的检索器条件边Level 2Corrective RAG打分 → 不相关则纠错状态图 循环Level 3Self-Reflective RAG生成后自检 → 重写重搜状态图 双循环Level 4Adaptive RAG自主决定是否需要检索Agent 检索作为可选工具Level 5Multi-Tool Agent向量/SQL/Web 灵活切换多工具 AgentLevel 6Multi-Agent多 Agent 分工协作AgentWorkflow / 多图编排Agentic RAG 的本质就是三个字——想清楚。想清楚该搜什么、去哪搜、搜得对不对、要不要重搜。当你的 RAG 系统开始反思自己的行为它才真正从检索工具进化为了知识伙伴。参考论文Singh et al., Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, 2025. arXiv:2501.09136Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, 2023. arXiv:2310.11511Yan et al., Corrective Retrieval Augmented Generation, 2024. arXiv:2401.15884