Agentic RAG

让模型自己决定搜什么，读完结果再搜一次。不用建图也能做多跳检索。

标准的 RAG 只检索一次，然后作答。一次检索，一次机会。

Agentic RAG 把检索变成模型可以反复调用的工具。它去搜，读返回的结果，判断够不够用，不够就换一个更好的查询再搜一次。

对那些无法事先知道该怎么搜才对的提问，这个差别很关键。

循环带来了什么

多跳。 处理支付的那个服务归哪个团队负责？ 第一次搜：找到支付服务，拿到它的名字。第二次搜：查这个名字归谁管。第二个查询依赖第一个结果，所以任何一次单独的检索都找不到答案。

**自我纠正。**检索回来的文本块并不相关。单发式系统照样拿它们作答。agent 则会察觉并改写查询。

**分解。**复合问题被拆成几次独立的检索，每次都能检得准，而不是用一个大查询什么也精确匹配不上。

**来源选择。**当手上有多个工具——文档检索、代码检索、工单检索、SQL——模型会按问题类型来挑，而不是把所有地方都搜一遍。

**充分性判断。**模型可以得出结论说语料里没有答案，并如实讲出来，而不是拿最接近的一段来答。这能实实在在减少幻觉，也正是这个模式值得付出成本的原因。

结构长什么样

一个带着检索工具的 agent 循环：

loop:
  model decides: search, or answer
  if search: run it, append results
  if answer: return

结构上没有任何新东西。设计功夫都花在工具定义和停止条件上。

要做对的几件事

工具分开，描述要有对比。 search_docs、search_code、search_tickets——每个都写清自己覆盖什么、什么时候该优先用另一个同类工具。工具描述的质量决定了模型会不会搜对地方，描述含糊是这里最常见的失效。

**结果要精简。**检索回来的文本块会在上下文里不断累积，而且每轮迭代都要重发一遍。只返回最低限度的有用文本加一个来源标识；需要全文时另给一个工具去取。

**硬性的迭代上限。**三到五次检索。没有这个上限，找不到东西的 agent 会一直搜下去。

**重复检测。**反复发出几乎一样的查询，是这个模式的典型失效。记录搜过什么，并把它呈现给模型。

**明确允许放弃。**给出一种方式，让模型能判定答案不在语料里，并奖励它这么做。否则，遵循指令的压力会让它拿检索到的任何东西硬凑一个答案。

代价

每轮迭代都是一次带完整累积记录的模型调用，所以成本随检索次数按平方增长。一次五搜的问答，成本可能远超单发式的五倍。

延迟同样叠加：五次串行的往返，每次还都包含检索。

这就让路由变得重要。大多数问题都是单跳的，应该走便宜那条路。把循环留给真正需要它的问题——要么先做分类，要么先走单发，等第一次检索得分很低时再升级。

与 GraphRAG 对比

两者都在解决多跳问题，但付出的环节正好相反。

GraphRAG 在建索引时就把结构预先算好。索引贵，查询便宜，而且它能处理「主要主题有哪些」这类整语料级别的问题，这是它独有的本事。

Agentic RAG 在查询时才把路径算出来。没有索引成本，查询贵，而且能适应没人预料到的问题。

语料经常变，或者查询模式难以预测时，agentic 检索通常是更划算的选择——它不需要重建。而在稳定的语料上反复问全局性问题时，预计算更胜一筹。

实操要点

**先从单发做起。**等你指得出某几个具体问题是因为缺了第二次检索才答错的，再加循环。很多看似多跳失败的情况，其实是分块或混合检索没做好。

**记录每一次检索。**查询序列是你诊断答案为什么错的唯一途径——而且它通常一眼就能看出问题。

**与查询改写结合。**模型自己写出来的查询，和用户直接给的查询一样，都能从对话式改写中受益。

**评结果，不评路径。**做评测时，很多不同的检索序列都能到达同一个正确答案；给路径打分，等于惩罚合理的差异。

要点回顾

Agentic RAG 把检索变成循环里的一个工具——搜、读、改、再搜。
它带来多跳、自我纠正、分解、来源选择，以及诚实地回答「语料里没有」。
它需要带对比的工具描述、精简的结果、迭代上限、重复检测，以及允许放弃。
成本和延迟随迭代增长——做好路由，让简单问题留在单发路径上。
与 GraphRAG 相比：代价付在查询时而不是索引时；更适合多变的语料和预料之外的问题。

下一篇： 面向图像与表格的 RAG

标准的 RAG 只检索一次，然后作答。一次检索，一次机会。

Agentic RAG 把检索变成模型可以反复调用的工具。它去搜，读返回的结果，判断够不够用，不够就换一个更好的查询再搜一次。

对那些无法事先知道该怎么搜才对的提问，这个差别很关键。

循环带来了什么

**自我纠正。**检索回来的文本块并不相关。单发式系统照样拿它们作答。agent 则会察觉并改写查询。

**分解。**复合问题被拆成几次独立的检索，每次都能检得准，而不是用一个大查询什么也精确匹配不上。

**来源选择。**当手上有多个工具——文档检索、代码检索、工单检索、SQL——模型会按问题类型来挑，而不是把所有地方都搜一遍。

结构长什么样

一个带着检索工具的 agent 循环：

loop:
  model decides: search, or answer
  if search: run it, append results
  if answer: return

结构上没有任何新东西。设计功夫都花在工具定义和停止条件上。

要做对的几件事

**硬性的迭代上限。**三到五次检索。没有这个上限，找不到东西的 agent 会一直搜下去。

**重复检测。**反复发出几乎一样的查询，是这个模式的典型失效。记录搜过什么，并把它呈现给模型。

**明确允许放弃。**给出一种方式，让模型能判定答案不在语料里，并奖励它这么做。否则，遵循指令的压力会让它拿检索到的任何东西硬凑一个答案。

代价

每轮迭代都是一次带完整累积记录的模型调用，所以成本随检索次数按平方增长。一次五搜的问答，成本可能远超单发式的五倍。

延迟同样叠加：五次串行的往返，每次还都包含检索。

与 GraphRAG 对比

两者都在解决多跳问题，但付出的环节正好相反。

GraphRAG 在建索引时就把结构预先算好。索引贵，查询便宜，而且它能处理「主要主题有哪些」这类整语料级别的问题，这是它独有的本事。

Agentic RAG 在查询时才把路径算出来。没有索引成本，查询贵，而且能适应没人预料到的问题。

语料经常变，或者查询模式难以预测时，agentic 检索通常是更划算的选择——它不需要重建。而在稳定的语料上反复问全局性问题时，预计算更胜一筹。

实操要点

**先从单发做起。**等你指得出某几个具体问题是因为缺了第二次检索才答错的，再加循环。很多看似多跳失败的情况，其实是分块或混合检索没做好。

**记录每一次检索。**查询序列是你诊断答案为什么错的唯一途径——而且它通常一眼就能看出问题。

**与查询改写结合。**模型自己写出来的查询，和用户直接给的查询一样，都能从对话式改写中受益。

**评结果，不评路径。**做评测时，很多不同的检索序列都能到达同一个正确答案；给路径打分，等于惩罚合理的差异。

要点回顾

Agentic RAG 把检索变成循环里的一个工具——搜、读、改、再搜。
它带来多跳、自我纠正、分解、来源选择，以及诚实地回答「语料里没有」。
它需要带对比的工具描述、精简的结果、迭代上限、重复检测，以及允许放弃。
成本和延迟随迭代增长——做好路由，让简单问题留在单发路径上。
与 GraphRAG 相比：代价付在查询时而不是索引时；更适合多变的语料和预料之外的问题。

下一篇： 面向图像与表格的 RAG