Agentic RAG:让检索从固定流程变成自主决策

传统 RAG 是一条单向管道:查询 → 检索 → 生成,一次走完。

这个结构在简单事实型问题上表现很好——「X30 的吸力是多少」,检索一次,拿到参数表,生成答案。但当问题变成「对比 A 产品和 B 产品在欧美的合规要求」时,这条管道会立刻暴露它的脆弱:它只给模型一次机会。首次检索的结果如果不合适,系统没有任何补救手段,只能拿着不对的上下文硬答。

Agentic RAG 要解决的就是这件事。

一、传统 RAG 的三大瓶颈

瓶颈一:多跳推理无力

有些问题的答案不在任何一个片段里,而是需要从多个来源逐步收集证据再组合。

问题:「对比 A 产品和 B 产品在欧美的合规要求」

需要的信息:
  ① A 产品在欧盟的合规要求   ┐
  ② A 产品在美国的合规要求   ├─ 四个独立的信息点
  ③ B 产品在欧盟的合规要求   │   分布在可能四份不同的文档里
  ④ B 产品在美国的合规要求   ┘

单次检索:用整句去检索 → 大概率召回一份「合规要求总览」,
          里面四条信息只覆盖了一两条 → 答案必然残缺

关键在于第二个检索该查什么,取决于第一个检索查到了什么。这个依赖关系是单向管道无法表达的。

瓶颈二:查询歧义与分解困难

复杂问题本身包含多个子问题,但固定管道里没有「先拆再查」这一步。

用户问「退货政策对跨境订单适用吗,和国内比有什么区别」,这里面其实是三个子问题:退货政策是什么、跨境订单是否适用、两者差异在哪。用整句去做向量检索,得到的是一堆「哪里都沾一点」的片段。

瓶颈三:检索失败无法自救

首次检索结果不相关时,系统没有「反思」和「重试」的机制。

这是三个瓶颈里最致命的一个。前面两个还可以靠「用户把问题问清楚一点」来绕过,但这一条是系统性的:只要检索有可能失败(而它一定会失败),单向管道就没有任何恢复能力。系统不知道该退回去重查,也不知道该换个说法再查一次。

二、核心转变:把检索当成工具

Agentic RAG 的思路是把检索从「流程里的一步」变成「Agent 可以调用的工具」。

这个视角一换,整条链路就活了:既然检索是个工具,那就可以被调用多次、可以用不同的参数调用、可以在调用之后判断要不要再调一次。

具体体现在三个转变:

转变	传统 RAG	Agentic RAG
动态规划	固定检索一次	Agent 先推理查询意图,决定是否检索、检索哪个索引、用何种查询方式
迭代精炼	检索结果直接用	评估首次检索结果,信息不足则自动改写查询、扩大或缩小检索范围,反复迭代直至收集到足够证据
多工具协同	只有向量库	可协调向量库、SQL 数据库、API 等异构数据源,按需调用

用流程图对比会更清楚:

【传统 RAG:单向管道,一次机会】

  问题 ──→ 检索 ──→ 生成 ──→ 答案
            (topK=5)
   ↑ 没有回退路径,检索错了就错了


【Agentic RAG:带反馈的循环】

  问题
   ↓
  ┌─────────────────────────────────────────┐
  │  Agent 推理:下一步该做什么?             │
  │    ① 直接回答?   (不需要检索)            │
  │    ② 检索一次?                          │
  │    ③ 拆成子问题,分别检索?               │
  │    ④ 调用 SQL / API 拿结构化数据?         │
  └─────────────────────────────────────────┘
   ↓ 执行
  检索 / 工具调用
   ↓
  ┌─────────────────────────────────────────┐
  │  评估:证据够了吗?                       │
  │    不够 → 改写查询 / 换数据源 → 回到上面 │
  │    够了 → 退出循环                       │
  └─────────────────────────────────────────┘
   ↓
  生成答案(带引用)

循环是这张图的核心。Agent 在每一轮都能看到「上一轮拿到了什么」,并据此决定「下一步该查什么」——这正好补上了多跳推理需要的那种依赖关系。

三、量化收益

Agentic RAG 不是概念上的优化,它在公开数据集上有可测量的提升:

数据集	特点	指标	传统 RAG	Agentic RAG	提升
HotpotQA	多跳推理	上下文精度	0.168	0.246	+0.078(约 +46%)
ASQA	长形式问答	精度	0.504	0.652	+0.148(约 +29%)
		召回率	0.278	0.478	+0.200(约 +72%)

从这两组数据能读出一些规律:

多跳数据集(HotpotQA)的绝对分数很低(0.168 → 0.246),说明这类任务本身很难,而且基数低意味着相对提升空间大——传统 RAG 在这类问题上的基础能力有多弱,一目了然。
长形式问答(ASQA)的召回率提升最猛(0.278 → 0.478,约 +72%)。这符合直觉:长形式答案需要覆盖更多信息点,单次检索天然覆盖不全,而迭代检索能一轮轮把缺口补上。
注意精度提升(0.504 → 0.652)小于召回提升。这是迭代检索的典型特征:多查几轮能捞到更多相关内容,但也会带进更多噪声。所以 Agentic RAG 往往要配套更强的精排和上下文压缩。

四、循环是怎么停下来

Agentic RAG 最大的工程风险不是「检索得不够」,而是**「停不下来」**——Agent 一直觉得证据不足,反复检索,延迟和 Token 消耗无上限地涨。

所以设计上必须有几道闸:

机制	作用
最大轮次上限	硬性限制循环次数(常见 3~5 轮),超了就用现有证据生成
证据充分性判断	明确的判据,而不是让模型凭感觉说「够了」
预算控制	累计 Token / 耗时超阈值就收敛
降级路径	轮次用尽仍不足 → 明确告知信息不全,或交由人工处理

设计时要遵循一个原则:

Agent 的循环必须有确定的终止条件,而且这个条件不能是「模型觉得够了」。

模型对「信息是否充分」的判断同样是概率性的,而且它倾向于「再查一次更保险」。把它作为唯一的终止条件,等于把系统的延迟上限交给了模型的偏好。

五、适用场景与成本权衡

Agentic RAG 并非万能——它增加了延迟、Token 消耗和系统复杂度。每次循环都意味着多一轮 LLM 调用 + 多一轮检索 + 更多上下文,延迟不是线性增长而是成倍增长。

所以它应该在以下场景启用:

适合	不适合
查询需要多步骤推理	简单事实型问答
需要跨数据源整合(文档 + 数据库 + API)	单一知识库就能回答
模糊或复杂的长形式问题	意图明确的短查询
需要交叉验证和自我纠错的高可靠性场景	对延迟极度敏感的场景

对于简单的事实问答,传统 RAG 依然是更经济高效的选择。

一个务实的做法是分层路由:先用一个便宜的判断(规则或小模型)识别问题类型,简单问题走传统 RAG 的单次管道,复杂问题才进 Agent 循环。这样既拿到了复杂场景的收益,又不用为所有请求付循环的成本。

六、回到 RAG 本身的三个挑战

Agentic RAG 解决的是「检索策略」这一层的问题,但 RAG 还有两个更底层的挑战,它同样绕不开。

挑战一:复杂问题的精准召回

这一点上面已经展开——语义匹配是有短板的。

简单问句很好召回,但用户问题是跨章节、多文档综合推理、口语化、缩写、歧义问题时,向量相似度容易匹配到看似相近但无关的 chunk。单轮检索很难一次性集齐全部需要的信息。

这正是引入 Agentic RAG 的动机:用它做多轮检索和子问题拆解。但要注意,Agentic RAG 缓解的是「没查全」的问题,它并不能让单次语义匹配变准——如果一次检索的候选集本身就是偏的,多查几轮也只是在偏的方向上多走几步。

挑战二:幻觉无法彻底根除

就算召回的原文全部正确,LLM 依然可能错误解读原文、强行合并冲突信息、脑补不存在的内容。

这一点需要说清楚:幻觉不完全是「资料没给够」的问题。给足了正确的上下文,模型依然可能出错——它可能把两份文档里不同条件下的结论硬凑成一个,也可能在原文只有定性描述时补一个具体的数字。

而且幻觉很难自动识别——它读起来往往比正确答案更流畅、更自信。人工标注成本很高。虽然可以做引用溯源、事实校验,但校验本身会增加 Token 开销和延迟。

所以幻觉治理是分层的:Prompt 约束(限定范围、强制引用)、上下文组织(控制片段数量、控制关键信息位置)、后置校验(抽取关键实体和数字做 grounding check)、拒答策略(把「不知道」设计成一个合法输出)。Agentic RAG 能改善的是第一环——把正确的资料找回来,剩下的几环还得各自解决。

挑战三:长上下文的取舍矛盾

为了提升召回,最直接的做法是增加 TopK,但这会带来更长的上下文。而上下文越长:

LLM 容易「丢信息」——长文本里中段的内容容易被忽略
Token 成本上涨
接口延迟变高

这里存在一个持续博弈:

召回更多片段 → 信息更全
             → 但更容易出现 LLM 忽略细节、成本变高、延迟变高

召回更少片段 → 成本低、延迟低
             → 但容易信息不足,漏答案

没有万能参数,需要在召回数量、chunk 大小、Rerank 策略、上下文压缩之间持续调优。

Agentic RAG 在这个矛盾上是把双刃剑:它通过多轮检索提高了召回,但每一轮的上下文都会累积,总上下文长度比单轮检索增长得更快。所以走 Agentic 路线时,上下文管理(压缩、摘要、只保留关键证据)不是可选项,而是必需品。

还有一个容易被忽略的坑:文档质量

业务文档本身质量不稳定——版本迭代、内容冲突、表格多、扫描 PDF 的 OCR 错误。上游的脏数据会直接击穿 RAG 效果,无论下游用的是什么架构。

这一条和架构无关,但它的影响可能比架构更大:Agentic RAG 会在脏数据上循环更多次,而不是把它过滤掉。

小结

传统 RAG 是一次性固定流程(查询→检索→生成),三大瓶颈是:多跳推理无力、查询歧义难以分解、检索失败无法自救
Agentic RAG 的核心转变是把检索视为可调用的「工具」,让 LLM 自主决策,体现在三点:动态规划、迭代精炼、多工具协同
量化收益:HotpotQA 上下文精度 0.168 → 0.246;ASQA 精度 0.504 → 0.652,召回率 0.278 → 0.478
精度提升小于召回提升,说明迭代检索会带进噪声,需要配套更强的精排与上下文压缩
循环必须有确定的终止条件——最大轮次、预算上限、降级路径,不能只靠「模型觉得够了」
它增加延迟、Token 消耗和系统复杂度;适合多步推理、跨源整合、长形式问答和高可靠场景,简单事实问答仍应走传统 RAG
RAG 的三个底层挑战依旧存在:复杂问题召回、幻觉、长上下文权衡;Agentic RAG 只解决其中「检索策略」这一环
上游文档质量的影响与架构无关——脏数据会击穿任何架构

从「固定流程」到「自主决策」,变的不是模型能力,而是系统对不确定性的处理方式:传统 RAG 假设第一次检索是对的,Agentic RAG 承认它可能错,并为此准备了退路。