本文为学习目的的个人翻译，译文及后文「译者总结」仅供参考。
原文链接：How Agentic RAG Works?。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。
标准 RAG 系统的主要问题，并不在检索，也不在生成。
问题在于，在生成发生之前，中间没有任何机制去判断这次检索是否真的已经足够好了。
标准 RAG 是一条信息单向流动的流水线：从查询到检索再到响应，没有检查点，也没有第二次机会。对于那些答案明确的简单问题，这种方式运行良好。
然而，一旦查询变得模糊，或者答案分散在多个文档中，或者第一次检索返回了看起来不错但其实并不正确的内容，RAG 就开始失去价值。
Agentic RAG 试图修复这个问题。它基于一个简单的问题：如果系统能够在回答之前先停下来思考，会怎样？
在这篇文章中，我们将看看 Agentic RAG 是如何工作的，它如何改进标准 RAG，以及在使用它时应该考虑哪些权衡。
一次查询，一次检索
要理解 Agentic RAG 修复了什么，我们需要先明确标准 RAG 是如何工作的，以及它在哪些地方做得不够好。
一个标准的 RAG 流水线有一个很直接的流程：
- 用户提出一个问题。
- 系统把这个问题转换成一种数值表示，称为 embedding，它捕捉的是查询的语义含义。
- 然后系统搜索向量数据库——一种专门用于查找语义相似内容的数据库——并检索出最匹配的文本片段。
- 这些片段会和原始问题一起传给大语言模型，然后由 LLM 基于检索到的上下文生成答案。
见下图：
下图展示了 embedding 通常是什么样子：
这种方式对于那些直接、明确、并且面对一个组织良好的知识库的问题来说，效果极好。比如“我们的退货政策是什么？”这类问题。一个干净的文档语料库，几乎每次都能给出可靠答案。
下面是一个典型的查询流：
问题会在查询变得更复杂时出现。下面是几个场景：
- 模糊查询：当用户问“我该如何处理税务？”时，他们可能指的是个人所得税、企业税务，或者非营利组织的免税身份。标准 RAG 无法澄清，也无法改写。它会原样接收查询，检索相似度得分最高的内容，然后寄希望于结果正确。
- 证据分散：有时答案分布在多个文档中。一个员工问“外包人员的远程办公政策是什么？”时，就需要同时从远程办公政策和外包协议中获取信息。标准 RAG 通常只会从一个统一的 chunk 池中检索，而且并没有“如果第一个来源不够，就去检查第二个来源”的概念。
- 虚假的自信：检索返回了一些基于相似度得分看上去相关的内容，但实际上并没有回答问题。也许它确实属于正确主题，但来自一份过期版本的文档。系统没有机制去区分“相关”和“实际上正确”这两者。无论如何，它都会生成一个自信的回答。
这三种失败模式有着相同的根本原因：系统不会反思它检索回来的内容。它无法问自己，这些结果是否已经足够好。
从流水线到控制循环
Agentic RAG 通过引入 AI agent 的能力，把这条线性流水线替换成了一个循环。
从本质上看，AI agent 是一种软件系统，它能够感知环境、做出决策，并采取行动，以某种程度上的独立性去实现特定目标。“agent”这个词在这里很关键。正如旅行代理会代表我们去寻找航班并协商交易一样，AI agent 会代表用户或系统完成任务，而不需要在每一个步骤上都持续获得指导。
下图展示了 AI agent 的概念：
在 Agentic RAG 中，流程不再是“先检索，再生成”，而变成了：检索、评估返回结果、决定是回答还是重试，如果有需要，就换一种方式重新检索。
见下图：
“Agentic”这个词听上去可能像是一种营销包装，但在这里，agent 指的是：一个 LLM 被赋予了做决策和调用工具的能力。你可以把它理解为：这个 LLM 不只是生成文本，它还能够选择采取行动，比如执行一次搜索、查询数据库、调用 API，或者判断自己在回应之前还需要更多信息。
这让系统具备了标准 RAG 所没有的三种能力。
- 工具使用与路由：agent 可以根据问题决定应该查询哪个知识源。财务问题可能去 SQL 数据库；政策问题可能去文档存储；产品问题可能两边都要查。简单说，agentic 系统会选择正确的位置，或者搜索多个位置。
- 查询优化：在搜索之前，agent 可以把一个模糊查询改写得更具体。在搜索之后，如果结果看起来不够强，它还可以重新组织问题并再次尝试。agent 会在检索前后都对查询本身采取行动。
- 自我评估：当结果返回之后，agent 会检查这些结果，例如问自己“这些内容相关吗？”“完整吗？”“是否与其他信息冲突？”如果其中任何一个答案是否定的，agent 就可以换一个查询、换一个来源，或者两者都换。这直接解决了“一次性命中”的问题。
下图展示了 Agentic RAG 的高层方式：
不过，把 Agentic RAG 理解成一个二元开关是有误导性的。
在最简单的形式里，它就像一个路由器，决定应该查询两到三个知识库中的哪一个。对于多数据源环境来说，这就已经是相对于标准 RAG 的一次有意义升级。
再往前一步，你会得到像 ReAct（Reasoning + Acting，推理 + 行动）这样的系统框架：agent 在“推理自己当前知道什么”和“采取行动去获得更多信息”之间交替推进，并在每一步检索之后做评估。
见下图：
再往更复杂的方向发展，就是多 agent 系统：多个专门化 agent 在一个编排器的协调下协同工作。
控制循环是一个有用的心智模型。不过，如果把它映射回前面提到的失败模式，就会更容易理解。
- 通过查询优化解决模糊性：像“我该如何处理税务？”这样的问题，会先经过 agent。agent 可以根据上下文把它拆成子问题，或者先改写成更有针对性的表达，再进行检索。如果第一次检索返回的是个人所得税相关内容，但上下文显示用户实际上问的是企业税务，agent 就可以继续优化并重新搜索。
- 通过路由解决证据分散：关于外包人员远程办公政策的问题，现在会先经过 agent，而 agent 会识别出它需要两个来源。它会先把查询路由到人力资源政策文档库，拿到结果后，再去查外包协议，然后把两部分结果综合起来，再生成答案。
- 通过自我评估解决虚假自信：agent 检索到一个看起来相关的文本片段，但它来自一份两年前更新的文档。评估步骤会把这个问题标出来。接着，agent 可能会搜索更新版本，或者转向其他来源，或者在回答里加上保留说明。系统不再盲目信任相似度得分。
这三种能力，与前面提到的三种失败模式是一一对应的。
Agentic RAG 被设计出来，就是为了填补标准 RAG 一次性流程无法覆盖的那些缺口。除此之外，agentic 系统还可能具备其他能力，比如 memory 和 semantic caching，让系统能够在多轮对话中保留上下文。
成本、延迟与适用边界
上面的内容可能会让 Agentic RAG 看起来像是标准 RAG 的直接升级版。然而，循环中的每一次迭代都有成本，而且这些成本可能大到使许多系统根本不应该采用它。下面是几个需要考虑的方面：
- 延迟：每一次循环，意味着又一次 LLM 调用、又一次检索、又一次评估。标准 RAG 查询可能只要 1 到 2 秒，而一个经历三到四轮循环的 agentic 查询可能需要 10 秒甚至更久。对于实时聊天应用来说，这通常是不可接受的。
- 成本：每一次 agent 决策都会消耗 token。一个每天要处理数千次查询的系统，其成本可能会比标准 RAG 高出 3 到 10 倍。哪怕这些查询中的 80% 只是简单 FAQ，这也意味着大量资金被花在了不必要的推理上。
- 调试与可预测性：标准 RAG 相对更具确定性。而 Agentic RAG 引入了变化性，因为 agent 会根据每一步发现的内容做出不同决策。这使得问题更难复现、更难编写测试，也更难向利益相关者解释为什么同一个问题在不同场景下会得到不同答案。
- 评估器悖论：自我评估步骤本身也是靠 LLM 来判断检索是否足够好。系统能否自我纠正，取决于这个 LLM 是否有能力判断相关性。一个弱评估器可能会拒绝本来很好的结果，让系统陷入徒劳搜索；也可能会接受糟糕结果，仍然产出错误答案。归根到底，我们是在用一次 LLM 调用去监督另一次 LLM 调用。
- 过度纠正：有时候，agentic 循环会比实际需要更“聪明”。它可能会在评估阶段丢弃其实有用的检索结果，继续搜索更好的内容，最后反而得到比第一次结果更差的答案。
这并不意味着 Agentic RAG 不应该被使用。它的意思是，是否使用它，应该是一个工程决策，而不是默认选择。
对于那些直接的事实查询、面向干净且单一来源知识库的问题，并不需要推理循环。对于那些高吞吐、低复杂度、且延迟和成本比边界情况更重要的查询模式，也同样如此。如果一个现有 RAG 系统的大多数失败，来自糟糕的 chunking 或过期数据这样的检索质量问题，那么先修复这些问题，往往比给它加一层 agent 更有效。
结论
理解 Agentic RAG 的核心心智模型其实很直接。
Agentic RAG 把检索从一条一次性流水线，变成了一个带决策点的循环。而这些决策点，就是它全部的价值所在。
在评估或构建 RAG 系统时，有三个问题可以帮助你穿透表面的噪音：
- 系统是否从正确的来源进行检索？
- 它能否判断自己检索到的内容是否已经足够好？
- 如果答案是否定的，它有没有能力再试一次？
如果这三个问题的答案全是“没有”，而且查询本身又很复杂，那么这就是应该考虑 agentic 方法的信号。如果查询很简单，而且知识库很干净，那么标准 RAG 很可能仍然是更合适的选择。
从“流水线”到“控制循环”的转变，也并不只发生在 RAG 上。它反映了 AI 系统演进中的一个更广泛趋势：从刚性的流水线，转向具备反馈循环和决策能力的系统。
参考资料
- Seven Failure Points When Engineering a Retrieval Augmented Generation System
- Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
译者总结
这篇文章的核心，不是给 Agentic RAG 下一个统一定义，而是说明它相对于标准 RAG 的本质变化：系统不再只做一次检索并立刻生成，而是在检索之后增加了评估、重试和路由等决策点。
原文前半部分先用标准 RAG 的三类常见失败场景——模糊查询、证据分散、虚假自信——来说明问题，再在后半部分把 Agentic RAG 的三项能力——工具使用与路由、查询优化、自我评估——与这些失败模式一一对应起来。理解这组对应关系，是读懂全文的关键。
文章后半部分虽然介绍了 Agentic RAG 的能力，但作者并没有把它描述成“默认更好”的方案。相反，延迟、成本、调试复杂度、评估器本身的不可靠，以及过度纠正，都是原文明确强调的代价和边界。
原文含推广段落，已略。参考资料部分也提示了这篇文章的定位更偏综述和工程判断，而不是某种唯一正确的架构结论。