Agentic RAG (自主检索增强生成)
一句话
让 LLM 自己决定检索策略。 不是固定的「用户问 → 检索 → 回答」，而是 LLM 根据问题动态判断：要不要检索、用什么检索、检索几次。
从 RAG 到 Agentic RAG 的跃迁
传统 RAG： 用户问 ─→ 检索 ─→ 回答 （固定管线）
Agentic RAG：用户问 ─→ LLM 决策 ─→ 路由/拆解/多跳检索 ─→ 回答 （自主决策）三个核心能力
| 能力 | 说明 | 例子 |
|---|---|---|
| 路由 | 判断问题类型，走不同检索策略 | 闲聊直接答、专业问题走 RAG、简单问题走知识库 |
| 拆解 | 把复杂问题拆成子问题，逐轮检索 | 「四大恶人老二的儿子，其生父公开身份是什么？」→ 先查「老二是谁」→ 再查「此人」→ 再查「其子生父」 |
| 回退 | 本地查不到时转网络搜索 | Milvus 没命中 → 自动调用搜索 API |
实现方式
Agentic RAG 通常基于 LangGraph 构建，核心是 StateGraph + 条件路由：
text
┌─→ 闲聊节点 → END
START ─→ 路由节点 ─→ 简单RAG节点 → END
└─→ 复杂问题 → 拆解 → 多轮检索 → 生成 → END
↑_____________↓ (循环直到满足条件)应用场景
| 场景 | 为什么需要 Agentic |
|---|---|
| 客服系统 | 用户问题千变万化——有时问退货政策（文档检索），有时问订单状态（API 查询），有时纯闲聊。固定管道无法自适应 |
| 研究助手 | 「比较 A 论文和 B 论文的方法论差异，再查 C 论文是否引用了其中任何一篇」——需要拆解 + 多轮检索 |
| 故障诊断 | 「服务 X 报 500 错误」→ Agent 先查日志 → 发现依赖 Y 超时 → 查 Y 的最近变更 → 定位到具体 commit |
| 旅行规划 | 「推荐杭州周末行程」→ Agent 查天气 → 查景点 → 查餐饮 → 整合成完整计划 |
横向对比：传统 RAG vs GraphRAG vs Agentic RAG
| 传统 RAG | GraphRAG | Agentic RAG | |
|---|---|---|---|
| 决策者 | 固定管道 | 固定管道+图结构 | LLM 自主 |
| 灵活性 | ⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 实现复杂度 | ⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 适合问题 | 简单事实查询 | 多跳关系推理 | 复杂、多步骤、策略型 |
| 成本 | 低（一次检索） | 中（图遍历+LLM 翻译） | 高（多轮 LLM 调用） |
| 可控性 | 高（可预测） | 中 | 低（LLM 可能做意外决定） |
| 可演进性 | 静态 | 需图谱维护 | 自然演进（加工具/加路由） |
优缺点
优点：
- 自适应——同一个系统可以处理闲聊、文档问答、API 查询、多轮推理，不需要为每种问题写一个接口
- 可扩展——新增一个知识源只需加一个工具（如
web_search），不需要改整体架构 - 更像人——人会先判断「这个问题需要翻资料吗？」，Agentic RAG 让这个判断自动化了
缺点：
- 延迟高——每多一次决策 = 多一次 LLM 调用，用户体验可能感知到等待
- 成本高——多轮 LLM 调用 = token 消耗大
- 可调试性差——固定管道出问题容易定位（哪步挂了），Agent 自主决策出问题需要排查「它为什么做了这个决定」
- 可能过度检索——LLM 有时过于「勤快」，一个简单问题拆了 5 轮
如何选择
text
你的系统需要——
简单问答，检索一次就够？
→ 传统 RAG （省钱、快、可控）
用户会问「A 和 B 什么关系」这种多跳问题？
→ GraphRAG （建图投入大，但关系推理精准）
用户问题类型多变、需要自适应、可能涉及多轮检索？
→ Agentic RAG （灵活但有成本代价）
以上都有，预算和技术栈都到位？
→ Agentic RAG + GraphRAG 混合 （LLM 自主路由到向量检索 or 图检索）如果你刚开始学：先掌握传统 RAG → 再学 LangGraph → 然后上 Agentic RAG。GraphRAG 放在最后——没有图也能做出很好的 RAG 系统，但 Agentic 思维是每个 AI 开发者都应该学的。
小结
Agentic RAG 是 RAG 的「自动驾驶模式」——从固定管道升级为 LLM 自主决策。它解决了「用户问题不可预测」的根本矛盾，但代价是更高的延迟和成本。在你的 AI 学习旅程中，Agentic RAG 是理解 Agent 如何「思考」的关键一站。