——从"一次检索就够了"到"想清楚再回答"的完整进化之路
引言：当"一次检索"不够用的时候
想象这样一个场景：你问系统——"对比一下在 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-RAG（Asai et al., 2023）
核心思想：训练 LLM 生成反思 Token，控制检索全流程。四种关键 Token：
Token决策输入输出
Retrieve要不要检索？问题yes / no / continue
ISREL文档相关吗？问题 + 文档relevant / irrelevant
ISSUP答案有出处吗？问题 + 文档 + 答案fully / partial / no
ISUSE答案有用吗？问题 + 答案1-5 分
关键洞察：让检索自适应（需要时才搜）和自批判（搜完检查质量），Self-RAG 在开放域 QA、推理和事实验证上显著领先标准 RAG 和 ChatGPT。
CRAG——Corrective RAG（Yan et al., 2024）
核心思想：把检索失败当作常态，事先设计好纠错路径。
检索文档 → 轻量评估器打分
Correct → 直接生成
Ambiguous → 补充 Web Search 结果
Incorrect → 完全降级到 Web Search
Knowledge Refinement：把文档拆成"知识条"，逐条打分，过滤无关内容
关键洞察：CRAG 不把检索失败当意外，而是在架构层面设计好回退路径。
四、LangGraph 实战：构建可纠错的 RAG Agent
LangGraph 把 RAG 的每一步建模成状态图中的节点，把决策点建模成条件边。这是实现 Agentic RAG 最灵活的方式。
4.1 架构总览
┌──────────┐ ┌──────────────┐ ┌─────────────────┐ │ retrieve │────▶│
grade_docs │────▶│ 是否相关？ │ └──────────┘ └──────────────┘
└───┬─────────┬───┘ │ Yes │ No ┌──────▼──┐ ┌──▼──────────┐ │ generate │ │
rewrite_query│ └────┬─────┘ └──┬──────────┘ │ │ ┌──────────▼──┐ │ │
幻觉检测？ │ │ └───┬────┬────┘ │ Yes │ │ No │ ┌──────────▼┐ │ │ │ 回答问题？ │ │
重新生成 ────┘ └───┬───┬───┘ │ Yes │ │ No │ ┌─────────▼┐ │ │ │ END │ │ 重写查询
──▶ retrieve └──────────┘ │ │ (重试上限 = 3)
4.2 状态定义
4.3 文档打分节点
这是 Agentic RAG 最关键的一步：让 LLM 判断检索结果是否相关。
4.4 条件路由
4.5 图谱构建与运行
五、LlamaIndex 实战：Agent 自主路由检索
如果你的核心需求是跨多个数据源进行智能路由，LlamaIndex 的 FunctionAgent 提供了更简洁的方案：
5.1 将查询引擎包装为工具
5.2 子问题自动拆分
LlamaIndex 的 SubQuestionQueryEngine 可以自动将复杂问题拆解为子问题：
fromllama_index.core.query_engineimportSubQuestionQueryEnginesub_engine = SubQuestionQueryEngine.from_defaults( query_engine_tools=[ QueryEngineTool.from_defaults(deployment_engine, name="部署文档"), QueryEngineTool.from_defaults(pricing_engine, name="定价文档"), ], llm=OpenAI(model="gpt-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 自主决定检索策略。
七、生产落地 Checklist
7.1 防止无限循环
Agentic RAG 的核心特点——循环（Rewrite → Retrieve → Grade → Rewrite…）——也是它的最大隐患。一定要在 State 中维护 retry_count，硬上限通常设为 3-5 次。
7.2 延迟与成本的平衡
策略LLM 调用次数/查询延迟质量
标准 RAG1低基准
+ 文档打分1 + k（k=文档数）中更好
+ 查询重写 + 重检索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 的决策质量：
指标评估对象层级
Recall@k正确的文档是否被检索到？检索层
Answer Faithfulness回答是否忠于上下文？生成层
Answer Relevance回答是否切题？生成层
Grader Accuracy文档打分器判断是否正确？Agent 层
Routing Accuracy路由器选对工具了吗？Agent 层
Retry Efficiency重试是否提升了回答质量？Agent 层
Avg. Steps per Query平均每个问题走几步？效率层
总结
Agentic RAG 不是要推翻标准 RAG，而是在其之上的进化：
进化层级形态实现方式
Level 0Naive RAG：一次检索、一次生成固定 Chain
Level 1查询路由：选最合适的检索器条件边
Level 2Corrective RAG：打分 → 不相关则纠错状态图 + 循环
Level 3Self-Reflective RAG：生成后自检 → 重写重搜状态图 + 双循环
Level 4Adaptive RAG：自主决定是否需要检索Agent + 检索作为可选工具
Level 5Multi-Tool Agent：向量/SQL/Web 灵活切换多工具 Agent
Level 6Multi-Agent：多 Agent 分工协作AgentWorkflow / 多图编排
Agentic RAG 的本质就是三个字——"想清楚"。想清楚该搜什么、去哪搜、搜得对不对、要不要重搜。当你的 RAG 系统开始反思自己的行为，它才真正从"检索工具"进化为了"知识伙伴"。
参考论文：
Singh et al., Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, 2025. arXiv:2501.09136
Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, 2023. arXiv:2310.11511
Yan et al., Corrective Retrieval Augmented Generation, 2024. arXiv:2401.15884
