Ch12: Agentic RAG——让 LLM 自主编排检索
Part 6: 进阶专题 前置章节：Ch03: RAG 技术演进、Ch11: Graph RAG 后续章节：Ch13: 多模态 RAG 返回目录：README
结论先行：Agentic RAG 把「检索策略」的编排权从工程师交给 LLM——由模型决定查什么、查几次、结果够不够。收益是复杂开放域问题的质量上限更高；代价是延迟不可预测、成本随检索轮次线性甚至指数增长、调试难度陡增。生产环境常见做法是 半 Agentic：关键路径仍用固定管线，只在「低置信度」分支触发 Agent 二次检索。
一、从 Ch03 的演进到 Agentic
Ch03 讲了六种模式从 Naive 到 Multi-hop 的演进光谱。Agentic 与 Multi-hop 的区别：
| 维度 | Agentic RAG | Multi-hop RAG |
|---|---|---|
| 决策主体 | LLM 决定策略 | LLM 决定推理链每一步 |
| 检索次数 | 1–N（不确定） | N（与跳数绑定） |
| 典型模式 | ReAct、Tool Use | 链式 QA、迭代检索 |
| 代表落地 | Dify Agent、WeKnora MCP | LangChain MultiQuery + Self-RAG |
日常类比：固定管线 RAG 像自动售货机——按按钮出饮料，流程固定。Agentic RAG 像派给研究助理——「你去查一下去年各产品线 ROI，不够再补财务部的数据」，助理自己决定查几次、查哪些库。
二、Agentic RAG 的典型控制环
用户 Query
↓
LLM 规划（是否需要检索？查哪个知识库？query 怎么改写？）
↓
执行检索 Tool（向量 / BM25 / 图谱 / 外部 API）
↓
LLM 评估上下文（够不够回答？要不要再查？）
├─ 够 → 生成答案 + 引用
└─ 不够 → 改写 query / 换数据源 → 回到检索（循环，有 max_steps）
半 Agentic 模式（推荐生产默认）
def semi_agentic_rag(query: str, retriever, llm, confidence_threshold=0.7):
# 第一轮：固定管线（快、便宜、可预测）
docs = retriever.hybrid_search(query, top_k=5)
draft = llm.generate(query, docs)
confidence = llm.score_faithfulness(query, draft, docs)
if confidence >= confidence_threshold:
return draft
# 第二轮：仅低置信度时触发 Agent 扩展
sub_queries = llm.decompose(query) # 「这个问题需要拆成哪几个子问题？」
extra_docs = []
for sq in sub_queries:
extra_docs.extend(retriever.hybrid_search(sq, top_k=3))
return llm.generate(query, dedupe(docs + extra_docs))
WeKnora 可通过 MCP 暴露检索 Tool，由外部 Agent（如 Claude Code）调用；Dify 在工作流里用 Agent 节点 + 知识检索节点 组合实现类似逻辑。详见 Agent 与 RAG 集成。
三、六大模式在本章的落点
| 模式 | 编排者 | WeKnora | Dify | 竞赛贡献切入点 |
|---|---|---|---|---|
| Naive | 代码 | 默认 API 单次检索 | 基础 Chatbot | 补测试 / 文档 |
| Advanced | 代码 + Rerank | 复合 Rerank | 混合检索 + Rerank 节点 | Rerank 策略 PR |
| Modular | 可配置管线 | Plugin 管线 | Workflow DAG | 新 Plugin |
| Graph | 代码 + 图谱 | PMI 第三路 | 无原生 | 图谱增量维护 |
| Agentic | LLM | MCP Tool | Agent 节点 | 多跳 query 规划 |
| Multi-hop | LLM 链 | 实验 / 社区 | 迭代节点 | Self-RAG 评估脚本 |
完整展开见专题 Agentic RAG 模式（5 万字级）。
四、成本与延迟：Token 经济学
Agentic RAG 的隐性账单：
| 环节 | 典型 Token 消耗 | 备注 |
|---|---|---|
| 规划轮 | 500–2000 | 每轮一次 LLM 调用 |
| 检索结果注入 | 2000–8000/轮 | 与 top_k × chunk 长度相关 |
| 自我评估 | 300–1000/轮 | 「够不够」判断 |
| 多轮叠加 | × N 轮 | N 无上限则成本失控 |
工程护栏（竞赛与生产通用）：
max_retrieval_rounds硬上限（通常 2–3）- 每轮 top_k 递减（第一轮 10，第二轮 5）
- 低置信度才进入 Agent 分支（半 Agentic）
- 缓存相同 query 的检索结果（Redis / 本地 LRU）
- 用 RAGAS faithfulness 做离线评估，证明多轮确实提升质量而非浪费 token
五、Agentic vs Graph RAG：互补而非替代
- Graph RAG：在固定管线内增加第三路召回，适合「关系推理」类 query
- Agentic RAG：在运行时动态决定检索策略，适合「开放域、多步骤」类 query
最佳组合：固定三路检索作第一轮 → 低分时 Agent 拆解子问题并对子问题再检索 → 可选 对子问题启用图谱路。WeKnora 的三路 + MCP 正是这种架构的素材库。
六、竞赛向：WeKnora 上的 Agentic 贡献方向
| 级别 | 方向 | 说明 |
|---|---|---|
| L2 | RAGAS 评估 + 多轮对比 | 证明 Agentic 分支何时值得开启 |
| L3 | Query 分解 / 改写模块 | Go 后端或 Python docreader |
| L4 | Self-RAG 式置信度门控 | 需设计 faithfulness 打分接口 |
环境矩阵与第一周清单见 Ch10 竞赛速查；真实 PR 模式见 WeKnora 实战。
章末自检
- 用一句话区分 Agentic RAG 与 Multi-hop RAG
- 解释为什么生产环境推荐「半 Agentic」而非全 Agentic
- 列出至少 3 条控制 Agentic 成本的工程护栏
- 说明 WeKnora MCP 与 Dify Agent 节点在架构上的相似点
- 若用户抱怨「回答慢且贵」，你会先查检索轮次还是 chunk 大小？
延伸阅读
- Ch03: RAG 技术演进
- Ch11: Graph RAG
- Agentic RAG 模式
- Agent 与 RAG 集成
- RAG 评估方法论
- 技术挑战 — Agentic 多跳成本控制（难点 #8）