Agentic RAG
把固定的「检索一次 → 生成」改成循环：模型自己决定要不要检索、检索什么、检索几轮，检索成了工具调用。强在能处理多跳与不确定的问题，贵在每轮都是一次模型调用 —— 失控时会反复检索同一个东西，或者明明该检索却直接答。
也叫：Agentic RAG · 检索循环 · 动态检索 · Router · ReAct 式检索
一、Agentic RAG：让检索变成一个循环出自 T2-9
判断要不要查 → 调用检索工具 → 观察够不够 → 不够就换个角度再来一轮
用户问题
Agent 循环 · 判断
要不要检索？查什么Router 先判断 query 类型
调用检索工具
向量库 / BM25本地知识库
SQL / 图谱结构化与关系数据
Web 搜索库外信息
观察结果
够回答了吗结果不相关就自我修正
两个出口
不够 · 换角度或换数据源再检索一轮必须设最大轮次
够了生成答案退出循环
同一个问题，两种管线的账
| 项目 | 固定管线 | Agentic 循环 |
|---|---|---|
| LLM 调用 | 检索一次后生成一次 | 每次决策都要调一次 |
| 整体成本 | 基准 | 可能是数倍 |
| 首字延迟 | 几百毫秒 | 数秒 |
| 失控形态 | — | 反复检索同一个东西 |
一个很加分的中间方案：不必每次都让 LLM 深度思考 —— 预定义几种检索策略，用轻量分类器选择，只在复杂 query 上启用完整 Agent 循环，既拿到大部分收益又避免成本失控。
稳定性仍是短板：模型会「明明该检索却直接答」，也会「反复检索同一个东西」，所以最大轮次和总 token 预算是必设项，评测也要看轨迹而不只看最终答案。
贵在每一次决策都要多调一次 LLM。首字延迟从几百毫秒涨到数秒，对话式产品要慎重；不设最大轮次和 token 预算，遇到答不了的问题它会疯狂循环烧钱。
核心变化
传统 RAG 是一条固定流水线：检索一次 → 生成。Agentic RAG 把检索变成 Agent 的一个工具，由模型自己决策：
用户问题
↓
【Agent 循环】
判断：这个问题需要检索吗？需要检索什么？
→ 调用检索工具（可以是向量库、SQL、图谱、Web 搜索）
→ 观察结果：够回答了吗？
├─ 不够 → 换个角度 / 换个数据源，再检索一轮
└─ 够了 → 生成答案关键组件通常包括：Router（判断 query 类型，路由到合适的数据源）、多个 Retriever、Memory（维护对话历史支持上下文感知检索）、ReAct 循环（思考-行动-观察，迭代到答案完整）。
它强在哪
- 动态多轮检索：根据中间结果决定要不要再查、查什么。
- 工具多样化：向量库、BM25、Web 搜索、数据库按需组合。
- 自我修正：检索结果不相关时能换个角度重来，而不是硬着头皮拿噪音作答。
到 2026 年，Agentic RAG 已被广泛视为企业复杂问答落地的事实标准。
它贵在哪（面试必答的另一半）
- 成本：每次决策都要调一次 LLM，整体成本可能是传统 RAG 的数倍。
- 延迟：多轮循环让首字延迟从几百毫秒涨到数秒，对话式产品要慎重。
- 稳定性：模型的决策能力仍不够可靠，会出现「明明该检索却直接答」「反复检索同一个东西」的情况，需要设最大轮次和兜底。
一个务实的中间方案（很加分）：不必每次都让 LLM 深度思考——预定义几种检索策略，用轻量分类器选择，只在复杂 query 上启用完整 Agent 循环。既拿到大部分收益，又避免成本失控。
以上节选自T2-9 GraphRAG、LightRAG 与 Agentic RAG，读全文能看到前后语境。