本文为学习目的的个人翻译，译文及后文「译者解读」仅供参考。

原文链接：How Agentic RAG Works?。

版权归原作者或原刊登方所有；若认为不妥，请联系删除。本文为非官方译本。

标准 RAG 系统的主要问题，其实不在检索，也不在生成。

问题在于，在生成发生之前，中间没有任何机制去判断这次检索是否真的已经足够好了。

标准 RAG 是一条单向流动的流水线：从查询，到检索，到响应，没有检查点，也没有第二次机会。

这对于那些答案简单明确的问题来说，通常运行得很好。

然而，一旦查询变得模糊，或者答案分散在多个文档中，或者第一次检索回来的内容看起来不错但其实并不对，RAG 就开始失去价值。

Agentic RAG 试图修复这个问题。

它基于一个简单的问题：如果系统能够在回答之前先停下来思考，会怎么样？

在这篇文章中，我们将看看 Agentic RAG 是如何工作的，它如何改进标准 RAG，以及在使用它时应该考虑哪些权衡。

Agentic RAG 总览示意图

一次查询，一次检索

要理解 Agentic RAG 修复了什么，我们需要先明确标准 RAG 是如何工作的，以及它在哪些地方做得不够好。

一个标准的 RAG 流水线有一个很直接的流程：

  • 用户提出一个问题。
  • 系统把这个问题转换成一种数值表示，称为 embedding，它捕捉的是查询的语义含义。
  • 然后系统搜索向量数据库——一种专门用于查找语义相似内容的数据库——并检索出最匹配的文本片段。
  • 这些片段会连同原始问题一起传给大语言模型，然后由 LLM 基于检索到的上下文生成答案。

见下图：

标准 RAG 流程示意图

下图展示了 embedding 通常看起来是什么样子：

Embedding 可视化示意图

对于那些直接、明确，并且面对的是一个组织良好的知识库的问题，这种方式效果非常好。

比如像“我们的退货政策是什么？”这样的问题。只要文档语料足够干净，几乎每次都能得到一个可靠的答案。

下面是一个典型的查询流示意：

典型查询流示意图

问题会在查询变得更复杂时出现。下面是几个场景：

  • 模糊查询：当用户问“我该如何处理税务？”时，他们可能指的是个人所得税、企业税务，或者非营利组织的免税身份。标准 RAG 无法澄清，也无法改写。它会原样接收查询，检索相似度得分最高的内容，然后寄希望于结果正确。
  • 证据分散：有时答案分布在多个文档中。一个员工问“外包人员的远程办公政策是什么？”时，就需要同时从远程办公政策和外包协议中获取信息。标准 RAG 通常只会从一个统一的 chunk 池中检索，而且并没有“如果第一个来源不够，就去检查第二个来源”的概念。
  • 虚假的自信：检索返回了一些看上去相关的内容，但实际上并没有回答问题。也许它确实属于正确的主题，但来自一份过期版本的文档。系统没有机制去区分“相关”和“实际上正确”这两者。无论如何，它都会生成一个自信的回答。

这三种失败模式有着相同的根本原因。

系统不会反思它检索回来的内容。

它不会问自己：这些结果真的已经足够好了吗？

标准 RAG 局限性示意图

从流水线到控制循环

Agentic RAG 通过引入 AI agent 的能力，把这条线性流水线替换成了一个循环。

从本质上看，AI agent 是一种软件系统，它能够感知环境、做出决策，并采取行动，以某种程度的自主性去实现特定目标。

这里“agent（代理）”这个词很关键。

正如旅行代理会代表我们去寻找航班、协商交易一样，AI agent 会代表用户或系统完成任务，而不需要在每一个细小步骤上都持续获得指导。

在 Agentic RAG 中，流程不再是“先检索、再生成”，而变成了：检索、评估返回结果、决定是回答还是再试一次，如果有需要，就换一种方式重新检索。

见下图：

Agentic RAG 控制循环示意图

“Agentic”这个词听起来可能像是在做营销包装，但在这里，agent 的含义是：一个 LLM 被赋予了做决策和调用工具的能力。

可以把它理解为：这个 LLM 不只是生成文本，它还能够选择采取行动，比如运行一次搜索、查询数据库、调用 API，或者决定在作答之前它还需要更多信息。

查询优化、路由与自我纠正

这让系统具备了标准 RAG 所没有的三种能力。

  • 工具使用与路由（Tool use and routing）：agent 可以根据问题决定应该查询哪个知识源。财务问题可能去 SQL 数据库；政策问题可能去文档存储；产品问题可能两边都要查。换句话说，agentic 系统会选择正确的地方，或者搜索多个地方。
  • 查询优化（Query refinement）：在搜索之前，agent 可以把一个模糊的查询改写得更具体。在搜索之后，如果结果看起来不够强，它还可以重新组织问题并再次尝试。agent 会在检索前后都对查询本身采取行动。
  • 自我评估（Self-evaluation）：当结果返回之后，agent 会检查这些结果，例如问自己“这些内容相关吗？”“完整吗？”“是否和其他信息冲突？”如果其中任何一个答案是否定的，agent 就可以换一个查询、换一个来源，或者两者都换。这直接解决了“一次性命中”的问题。

下图展示了 Agentic RAG 的高层方式：

Agentic RAG 高层架构示意图

不过，把 Agentic RAG 理解为一个二元开关是有误导性的。

在最简单的形式里，它可以只是一个路由器，决定在两到三个知识库中查询哪一个。对于多数据源环境来说，这就已经比标准 RAG 有了实质性的提升。

再往前一步，你会得到像 ReAct（Reasoning + Acting，推理 + 行动）这样的系统框架：agent 在每一步之间交替进行推理和行动，在多个检索步骤之间不断评估。

见下图：

ReAct / 多步推理与行动示意图

再往更复杂的方向发展，就是多 agent 系统：多个专门化的 agent 在一个编排器的协调下协同工作。

“控制循环”是一个很有用的心智模型。不过，如果把它重新映射回前面提到的失败模式，会更容易理解。

  • 用查询优化解决模糊性：对于“我该如何处理税务？”这个问题，它会先经过 agent。agent 可以根据上下文把它拆解成子问题，或者先把它改写成更有针对性的表达，再进行检索。如果第一次检索回来的结果是关于个人所得税，而上下文表明用户其实在问企业税务，agent 就可以改写并再次搜索。
  • 用路由解决证据分散：关于外包人员远程办公政策的问题，现在会先经过一个 agent。这个 agent 会识别出它需要两个来源。它会先路由到 HR 政策文档库，检索结果；再路由到外包协议文档库，从那里检索；然后在生成答案之前，把两组检索结果综合起来。
  • 用自我评估解决虚假的自信：agent 检索到了一个看似相关的片段，但它来自一份两年前更新的文档。评估步骤会把这个问题标记出来。接下来，agent 可能会去搜索更新的版本，或者改查另一个来源，或者在回答中加入保留说明。系统不再盲目信任相似度得分。

这三种能力，正好分别对应前面那三种失败模式。

Agentic RAG 正是为了解决标准 RAG 在“一次性检索”模式下的短板而设计的。

除了上面这三种能力之外，agentic 系统还可能具备更多能力，比如 memory 和 semantic caching，这样系统就可以在多轮对话中保留上下文。

权衡与代价

前面这些内容可能会让 Agentic RAG 看起来像是标准 RAG 的直接升级版。

但循环中的每一次迭代都是有成本的，而这些成本大到足以让很多系统不适合使用它。下面是几个需要考虑的方面：

  • 延迟（Latency）：循环每多一次，就意味着又多一次 LLM 调用、又多一次检索、又多一次评估。一次标准 RAG 查询可能只需要 1～2 秒；而一个经历三到四轮循环的 agentic 查询可能需要 10 秒甚至更久。对于实时聊天应用来说，这通常是不可接受的。
  • 成本（Cost）：agent 的每一次决策都会消耗 token。对于每天处理数千次查询的系统来说，成本可能比标准 RAG 高出 3～10 倍。即使其中 80% 的查询都只是简单 FAQ，这也意味着大量不必要的推理成本。
  • 调试与可预测性（Debugging and predictability）：标准 RAG 相对来说是比较确定的。而 Agentic RAG 会引入更多变化，因为 agent 会根据每一步找到的内容做出不同决策。这会让问题更难复现、更难写测试，也更难向利益相关方解释为什么同一个问题在不同场景下会得到不同答案。
  • 评估器悖论（The evaluator paradox）：自我评估步骤依赖另一次 LLM 调用来判断这次检索是否已经足够好。系统能否自我纠正，取决于这个 LLM 是否善于判断相关性。一个弱的评估器可能会把本来已经很好的结果判为不合格，让系统继续无意义地搜索；也可能接受很差的结果，最后仍然生成错误答案。说到底，我们是在让一个 LLM 去监督另一个 LLM。
  • 过度纠正（Overcorrection）：有时 agentic 循环会比实际所需更“聪明”。它可能会在评估阶段丢弃本来就有用的信息，继续搜索“更好的结果”，最后反而得到一个比第一次结果还差的答案。

这并不意味着不应该使用 Agentic RAG。

它意味着：是否要使用它，应该是一个工程上的决策，而不是默认选择。

对于一个干净、单一来源的知识库中的直接事实查询，并不需要一个推理循环。

对于高并发、低复杂度、延迟和成本比边缘问题处理能力更重要的场景，也同样不需要。

如果一个现有 RAG 系统的大多数问题来自于检索质量本身，例如 chunk 切分不好或者数据过期，那么先修这些问题，带来的收益往往会比叠加一个 agentic 层更大。

理解 Agentic RAG 的核心心智模型其实很简单。

Agentic RAG 把检索从一条一次性的流水线，变成了一个带有决策点的循环。

而这些决策点，就是它全部的价值所在。

在评估或构建 RAG 系统时，下面三个问题有助于抓住本质：

  • 系统是否在从正确的来源检索？
  • 它能否判断自己检索到的内容是否足够好？
  • 如果结果不够好，它是否有能力再试一次？

如果这三个问题的答案都是否定的，而查询本身又很复杂，那么这就是考虑 agentic 方法的信号。

如果查询很简单，知识库也很干净，那么标准 RAG 可能就是正确选择。

总结

从“流水线”到“循环”的转变，也并不只发生在 RAG 上。

它反映的是 AI 系统演化中的一个更广泛趋势：从刚性的流水线，走向具备反馈回路和决策能力的系统。

参考资料

译者解读

  1. 这篇文章最关键的判断，不是“标准 RAG 检索不够强”，而是“标准 RAG 缺少对检索结果的复核机制”。如果只抓这个主线来读，全文结构会清楚很多：作者先指出一次性检索的局限，再说明 Agentic RAG 如何通过反馈回路补上这个缺口。

  2. 文中反复提到的 Routing、Query Refinement、Self-Evaluation，并不是三个平行的炫技功能，而是分别对应三种常见失败模式：查错地方、问题没问清、检索结果看似相关却不够回答。把这三组映射关系看明白，会比单记术语更有用。

  3. “Agentic” 在这里更接近“带决策能力的流程”，而不是单纯“用了 agent 框架”。原文强调 control loop，其实是在提醒读者：真正的变化发生在系统结构上，而不只是换了一个更会说话的模型。

  4. 这篇文章比较可贵的一点，是它没有把 Agentic RAG 写成默认答案。延迟、成本、可预测性下降，以及评估器本身可能出错，都是实际系统里绕不过去的代价。读这篇文章时，最好把它当成一种工程取舍分析，而不是趋势宣言。

  5. 如果把原文放回落地场景，它更像一个排查框架：当系统经常遇到模糊查询、多源信息、过期内容或“相关但不够用”的召回结果时，Agentic RAG 才真正有价值。若问题主要出在 chunk 切分、数据质量或索引策略上，先修基础检索通常更直接。这一点虽然原文没有展开成操作手册，但它的判断边界已经说得很明确。