内容来源：https://blog.n8n.io/agentic-rag/

内容总结：

大型语言模型（LLM）虽功能强大，但在实际应用中存在明显缺陷，例如可能产生虚假信息、知识更新滞后、回答不一致以及缺乏深层语义理解等。为应对这些问题，开发者引入了检索增强生成（RAG）技术，通过连接外部数据源提升模型回答的准确性。然而，传统RAG仍属于静态、线性的“检索-生成”流程。

在此背景下，一种更为先进的“智能体驱动RAG”（Agentic RAG）逐渐兴起。该系统融入了基于LLM的智能体，能够自主决策检索策略、选择工具并评估答案质量，实现了从静态流程到动态智能工作流的转变。

与传统RAG相比，智能体驱动RAG具备多项突破性优势。其工作流不再是固定顺序，而是可动态调整的多步骤过程；能自主选择包括向量数据库、SQL数据库甚至网络API在内的多种数据源；还可根据查询类型自适应调整检索与生成策略，显著提升复杂问题的处理能力。

该系统涵盖三个核心环节：智能存储阶段由智能体动态解析文档、优化数据分块及元数据标注；动态检索阶段通过“检索路由”机制自主选择最合适的数据源；生成验证阶段则引入“答案评判”功能，通过迭代优化确保回答的准确性与完整性。

目前，智能体驱动RAG已应用于多个实际场景。例如可根据用户意图分类选择不同的检索策略，动态结合静态知识库与实时搜索引擎回应不同类型查询，以及通过混合使用SQL和GraphRAG技术分别处理结构化表格与非结构化文本数据。

尽管与另一种“自反思RAG”（Self-RAG）都致力于提升模型决策能力，智能体驱动RAG更侧重于在外部工作流中实现多智能体协同，而非依赖模型内部的自省机制。此外，它还可与“多模型RAG”结合，引入专门模型处理命名实体识别、虚假信息检测等子任务，进一步扩展系统能力。

总体而言，智能体驱动RAG代表了下一代AI应用开发的重要方向，通过引入自主决策与多工具调度机制，大幅提高了复杂知识处理任务的可靠性与适用性。目前已有多个开源工具和模板支持该技术的实践与推广。

中文翻译：

如果您曾使用过任何大型语言模型（LLM）应用，很可能已经体会到这些强大系统与生俱来的挑战。本质上，LLM 容易产生幻觉（即看似自信但实际错误的输出），且存在知识截止日期限制——这意味着除非明确提供实时或专有信息，否则它们无法获取这类信息。它们还可能生成不一致的回应，并且常常忽略细微的上下文差异，因为其语言处理依赖于学习到的模式而非真正的理解。

为了突破这些限制，开发者转向了检索增强生成（RAG）技术。该技术将 LLM 与外部数据源相连接，使模型能够在生成回答前获取相关的最新信息，从而显著提高准确性。RAG 是一次重大进步，但它本质上是一个静态、线性的过程：检索信息，然后生成答案。

但如果系统能变得更智能呢？如果它能自主决定寻找答案的最佳方式、选择使用哪些工具，甚至能自我评估回答的完整性呢？这正是智能体驱动 RAG（Agentic RAG）所承诺的愿景，也是该框架的下一代演进。通过引入基于 LLM 的智能体，我们将简单的 RAG 流程转变为动态、智能的工作流。

本文将探讨什么是智能体驱动 RAG、它如何突破前代技术的局限，以及为什么它有望重新定义我们构建复杂人工智能应用的方式。

---

什么是智能体驱动 RAG？

智能体驱动 RAG 的核心在于通过集成基于 LLM 的智能体，升级标准检索框架，引入自主决策能力。系统不再遵循固定指令，而是能够感知环境、做出决策并执行操作以实现目标。

尽管智能体现在整个工作流中发挥作用，但最根本的转变发生在索引阶段。在传统 RAG 中，索引是一个预定义且通常需要人工干预的过程；而在智能体驱动 RAG 中，这变成了由 AI 自主驱动的、具备上下文感知能力的动态操作。智能体不仅可以自主决定向向量数据库添加哪些信息，还能决定如何最高效地完成这一过程。

例如，智能体可以智能解析复杂文档，提取更丰富、更有用的元数据，并为不同类型的内容选择最优的分块策略。这将索引从一项静态的设置任务转变为持续的知识构建过程，为后续生成更准确、更相关的结果奠定基础。

---

简单 RAG 与智能体驱动 RAG 有何区别？

简单（或原始）RAG 与智能体驱动 RAG 的主要区别在于其工作流程和智能水平。虽然两者都旨在通过外部数据增强大型语言模型（LLM），但它们的方法和能力存在显著差异。简单 RAG 是线性且静态的，而智能体驱动 RAG 是动态、自适应且自主的。

以下直接对比帮助理解关键区别：

功能特点	简单 RAG	智能体驱动 RAG
工作流程	固定的“检索-读取”序列	动态多步骤流程（查询重写、多源检索或跳过检索）
决策能力	无；路径预先确定	智能体自主决策（路由选择、工具使用、自我批判）
数据源与工具	单一非结构化知识库	多源接入（向量数据库、SQL、网络 API 等）
适应性	僵化；所有查询流程相同	自适应；根据复杂多跳查询调整检索步骤

本质上，简单 RAG 为 LLM 提供被动的外部知识访问，而智能体驱动 RAG 则为其提供智能操作的主动框架。该框架使系统能够通过动态选择工具和数据源来解决复杂问题。这种智能还延伸至知识库本身：智能体可以自主更新和维护其信息，决定存储内容及索引方式，以实现最佳的相关性和准确性。

---

智能体驱动 RAG 的结构是怎样的？

如前所述，智能体驱动 RAG 从根本上改变了系统存储、检索和使用信息的方式。它不再采用僵化的流水线，而是引入一个三阶段生命周期，智能体在每一步都做出决策，以提高最终答案的质量和相关性。构建这样的系统需要三个关键组成部分：

智能存储：决定索引内容及方式

在任何信息被检索之前，必须先进行存储。在传统 RAG 系统中，索引过程是静态的；而智能体驱动 RAG 系统将其转变为主动的智能过程。

智能体可以分析输入数据，并决定是否应进行索引。更重要的是，它会决定最有效的存储方式，包括高精度解析复杂文档、创建丰富的元数据以优化筛选、选择最佳分块策略，甚至根据数据上下文选择最合适的嵌入模型。这确保知识库不仅是一个被动的存储库，而且是一个经过优化和战略组织的信息源。

动态检索：为数据选择合适工具

当用户提出问题时，智能体系统擅长从最佳来源找到正确的信息。它不限于搜索单个向量数据库。

通过通常称为“检索路由器”（Retriever Router）的组件，LLM 智能体分析传入查询并决定最佳操作路径。这可能意味着查询 SQL 数据库、使用网络搜索 API 或搜索内部产品文档。通过配备多种工具，系统可以与多个不同的数据源交互，确保无论信息位于何处，都能检索到最相关的上下文。

“你是一个路由器。你的工作是选择最佳工具来回答用户的查询。你有两个工具：

1. SQL_database_tool：用于有关销售、收入或特定指标的问题。
2. document_vector_store_tool：用于有关公司政策或一般信息的问题。”

验证生成：撰写与批判答案

信息检索完成后，过程并未结束。系统使用“答案批判”（Answer Critic）功能检查所检索的信息是否正确、完整地回答了用户的原始问题。如果答案不完整或不正确，批判者可以生成一个新的、更具体的问题以检索缺失信息，并触发新一轮检索。这种生成与批判的迭代过程确保最终回应在对用户呈现之前是准确和全面的。

“你是一名答案批判者。评估 GENERATED_ANSWER 是否完全满足了 USER_QUERY。如果不完整，请说明缺失内容，并生成一个新的 INTERNAL_QUERY 以查找缺失信息。”

---

智能体驱动 RAG 的三大应用场景

让我们通过几个具体示例看看这些原理如何在实际中应用。以下工作流展示了 n8n 基于节点的可视化界面如何完美适用于设计和协调智能体驱动 RAG 系统所需的复杂多步逻辑。

1. 自适应 RAG（选择正确的检索策略）

并非所有问题都相同。有些问题需要简单事实，而其他问题则需要深入分析。简单 RAG 系统对它们一视同仁，这可能导致结果不佳。该工作流展示了一种更先进的自适应 RAG：首先分析用户意图，然后为该特定类型的问题选择最佳检索策略。

该工作流围绕一个多阶段过程构建，智能体在其中做出决策以定制检索和生成流程：

• 查询分类：用户提交查询时，第一个 AI 智能体并不直接回答，其唯一任务是将用户意图分类为四种类型之一：事实型、分析型、观点型或上下文型。
• 策略路由：根据分类结果，Switch 节点将流程引导至四个不同路径之一。每条路径都是处理该类查询的专门策略。
• 查询适配：在每个路径上，另一个 AI 智能体调整原始查询以优化检索效果：
  • 对事实型查询，智能体重写问题以更精确。
  • 对分析型查询，智能体将问题分解为若干子问题以确保全面覆盖。
  • 对观点型查询，智能体识别需搜索的不同观点。
• 定制检索与生成：适配后的查询用于从向量数据库检索相关文档。最后，一个总结性智能体使用专为原始查询类型设计的系统提示生成答案（例如，事实型需“精确”，观点型需“呈现多样观点”）。

该工作流是智能体驱动 RAG 的典型范例，因为它超越了简单地路由到不同数据源，而是路由到不同的信息检索策略。初始分类智能体充当复杂的检索路由器，自主判断用户意图，从而决定整个后续工作流——这是简单 RAG 系统所缺乏的。四个路径中的智能体积极转换用户查询，它们不只是传递查询，而是基于初始分类努力改进它。

2. 具备动态知识源的 AI 智能体

该工作流展示了智能体驱动 RAG 的一个核心原则：动态源选择。我们不依赖单一知识库，而是构建一个能在两个不同信息源之间智能选择的 AI 智能体：一个用于基础知识的静态 RAG 数据库，和一个用于实时事件的实时搜索引擎。

该工作流的主要组成部分是 AI Agent 节点。该智能体连接了两个不同的“工具”来回答问题：

• RAG MCP 服务器：连接至包含特定预加载信息（此处是关于模型上下文协议 Model Context Protocol 的信息）的传统 RAG 数据库。
• 搜索引擎 MCP 服务器：使智能体能够执行实时网络搜索，获取最新信息。

为何这被视为“智能体驱动 RAG”？此设置超越了简单 RAG，因为 AI 不仅检索信息，还做出决策。当用户提问时，智能体必须首先分析查询并决定使用哪个工具来回答。这正是“检索路由器”概念的实践。模型上下文协议（MCP）充当通信层，使智能体能够了解其可用工具（两个服务器）并做出选择。

例如，如果您问“什么是模型上下文协议？”，智能体会识别这是一个基础问题，并将其路由至 RAG MCP 服务器。但如果您问“上周末谁赢了 F1 比赛？”，智能体理解这需要当前信息，并将使用搜索引擎 MCP 服务器来寻找答案。这种自主决策使得该工作流具备“智能体”特性。

3. 处理表格与非结构化数据的 AI 智能体（SQL + GraphRAG）

此高级工作流解决了传统 RAG 系统最重大的挑战之一：处理来自 Excel 文件或 Google Sheets 等来源的结构化表格数据。虽然标准 RAG 擅长搜索文本，但在需要对关系数据进行精确计算或比较时常常失败，因为分块过程破坏了表格结构。

该系统通过创建一个混合智能体来解决该问题，该智能体可以在针对表格数据的 SQL 查询和针对非结构化文档的 GraphRAG 之间进行选择。

在此查看原版 YouTube 视频：[视频链接]

该工作流围绕智能数据摄取流程构建，根据数据类型进行差异化处理。当新文件添加到指定的 Google Drive 文件夹时，流程开始。n8n 工作流中的一个初始步骤检查文件类型以确定正确的处理路径。

• 对于表格数据（Excel/Sheets），系统执行一系列步骤以正确构建其查询结构：
  • 下载文件并提取其内容。
  • 代码节点随后在 Supabase 等数据库中创建新的 PostgreSQL 表，并根据文件标题动态生成数据库模式。
  • 最后，用数据填充新表，处理文本、数字、日期等各种数据类型。
• 非结构化数据（PDF、Word 文档） 被路由至 GraphRAG 系统，使用名为 LightRAG 的库进行更复杂的摄取过程：
  • LLM 首先分析文档内容以识别关键实体（如人物、公司、概念）及连接它们的关系，而不是简单地对文本进行分块。
  • 然后使用这些提取的实体和关系构建结构化的知识图谱。该图谱代表文档的核心信息，通常存储在专用的图数据库中。

为何这被视为“智能体驱动 RAG”？系统不会以相同方式索引所有输入数据。智能体基于文件类型做出决策，为表格数据（SQL 数据库）与非结构化文档（GraphRAG）选择不同的、更有效的存储策略。它还会根据用户的问题决定使用哪个知识源。如果查询最适合用表格数据回答，它会生成 SQL 查询并使用“执行 SQL 查询”工具直接从数据库获取答案。如果问题是关于文档内容的，则它将查询路由到 GraphRAG 工具。

---

常见问题解答（FAQ）

Self-RAG 与智能体驱动 RAG 有何区别？

虽然两者都代表了相对于简单 RAG 的进步，但它们以不同方式改进流程。关键区别在于：Self-RAG 将决策能力内建于语言模型本身，而智能体驱动 RAG 将决策能力构建在模型周围的工作流中。

Self-RAG 是一个特定框架，通过微调模型使其在生成过程中自行做出检索决策。它使用特殊的“反思令牌”（reflection tokens）来内部决定是否需要搜索信息、检索到的文档是否相关以及其答案是否有事实充分支持。它旨在赋予模型自我纠正和自我评估其过程的能力。

正如我们所讨论的，智能体驱动 RAG 是一种更广泛的架构模式。它使用基于 LLM 的智能体来管理外部工作流，包括分析用户意图以选择正确的工具、使查询适应特定策略以及批判最终答案。

Graph RAG 与智能体驱动 RAG 有何区别？

智能体驱动 RAG 关乎系统决策和工作流执行的智能与自主性。Graph RAG 则关乎底层知识库的结构和丰富性，它使用知识图谱来实现更精确、关联和多跳的信息检索。一个智能体驱动 RAG 系统可能会将 Graph RAG 作为其专门的“检索智能体”或用于查询结构化数据的工具之一，这体现了这些变体如何相互补充。

传统 RAG 与 Graph RAG 的关键区别在于底层数据库。Graph RAG 通常涉及查询图数据库（例如 Neo4j、ArangoDB 等），而传统 RAG 则涉及查询向量数据库（例如 Pinecone、Qdrant、Milvus 等）。

RAG 与多模型 RAG 有何区别？

多模型 RAG 是一种在 RAG 流程的不同阶段使用不同的、专门的 AI 模型以提高性能和处理复杂任务的方法。这可能涉及多种策略：

• 多样化 LLM 运用：在复杂应用中，可以使用“多 LLM 策略”将不同的大型语言模型（LLM）分配给它们最擅长的工作。这可能涉及诸如以下的专门任务特定模型：
  1. 命名实体识别（NER）模型，用于提取特定实体以进行元数据过滤。
  2. 幻觉检测和审核模型，以确保最终答案的质量和安全性。

智能体驱动 RAG 是多模型方法的一个很好的例子。此设置使用多个协同工作的 LLM 智能体。这些智能体可以具有特定的“配置文件”（如“编码员”智能体和“测试员”智能体），协调行动并相互提供反馈以处理复杂的多步骤任务。

---

总结

正如我们所介绍的，智能体驱动 RAG 是传统 RAG 系统的一次重大升级。它摆脱了简单的“检索-读取”过程，利用 AI 智能体创建了更智能、更灵活的工作流。

这种转变意味着智能体在信息生命周期的每一步都自主决策。在存储阶段，它们可以智能地确定如何索引信息，选择最佳分块策略或元数据以提高知识库效率。在检索期间，它们充当智能路由器，为特定查询选择最佳工具，无论是向量数据库、SQL 数据库还是实时网络搜索。最后，在生成阶段，它们不仅提供答案，还可以审查自身工作的准确性，如果第一次答案不够好，则会触发更多搜索轮次。

正如 n8n RAG 工作流示例所展示的，这些功能不仅仅是理论，而是您今天就可以使用的实用工具，用于构建下一代强大且可信的 AI 应用程序。

---

下一步？

下一步是从理论转向实践。思考您自己的数据以及面临的挑战。一个能在数据库和网络搜索之间做出选择的智能体是否能改善您的结果？根据用户查询调整检索策略是否能提供更相关的答案？

查看这些分步视频指南，了解如何使用 n8n 构建智能体驱动 RAG 系统：

• 我构建了终极 n8n RAG AI 智能体模板
• 使用 n8n 的智能体驱动 RAG 存储所有数据类型
• 终极 n8n 智能体驱动 RAG 系统（SQL + GraphRAG）
• 使用推理 LLM 构建 | n8n 智能体驱动 RAG 演示 + 模板

欲深入了解基础知识，请探索本关于使用 n8n 构建自定义知识 RAG 聊天机器人的教程。您不必从零开始，可以浏览 n8n 社区预构建的 AI 工作流，作为您自己项目的起点。

英文来源：

If you’ve worked with any Large Language Model (LLM) applications, you've likely struggled with the inherent challenges of these powerful systems. At their core, LLMs are prone to hallucinations (i.e., confident yet incorrect outputs) and suffer from knowledge cut-off dates, meaning they lack access to real-time or proprietary information unless explicitly provided. They can also produce inconsistent responses and often miss nuanced context, processing language based on learned patterns rather than true understanding. To overcome these limitations, developers turned to Retrieval-Augmented Generation (RAG), a technique that connects LLMs to external data sources. This allows the model to fetch relevant, up-to-date information before formulating a response, dramatically improving accuracy. RAG was a significant step forward, but it's fundamentally a static, linear process: retrieve information, then generate an answer. But what if the system could be more intelligent? What if it could autonomously decide the best way to find an answer, which tools to use, and even critique its own response for completeness? This is the promise of Agentic RAG, the next evolution of this framework. By integrating LLM-powered agents, we transform the simple RAG pipeline into a dynamic, intelligent workflow. In this article, we'll explore what Agentic RAG is, how it moves beyond the limitations of its predecessor, and why it is set to redefine how we build sophisticated AI applications. What is an agentic RAG? At its core, Agentic RAG upgrades the standard retrieval framework by integrating LLM-powered agents to introduce autonomous decision-making. Instead of following a rigid set of instructions, the system can perceive its environment, make decisions, and execute actions to achieve a goal. While this intelligence is applied across the entire workflow, the most fundamental shift occurs during indexing. In traditional RAG, indexing is a predefined and often manual process. With Agentic RAG, this becomes a dynamic and context-aware operation driven by the AI itself. An agent can autonomously decide not just what information to add to the vector store, but also how to do it most effectively. For example, an agent can intelligently parse complex documents to extract richer, more useful metadata and also decide on the optimal chunking strategy for different types of content. This transforms indexing from a static setup task into an ongoing process of knowledge-building, laying the foundation for more accurate and relevant results down the line. What is the difference between simple RAG and agentic RAG? The primary difference between simple (or naive) RAG and Agentic RAG lies in their operational workflow and intelligence. While both aim to enhance Large Language Models (LLMs) with external data, their approaches and capabilities differ significantly. Simple RAG is a linear and static process, whereas Agentic RAG is dynamic, adaptive, and autonomous. To better understand the key distinctions, here is a direct comparison:	Feature	Simple RAG	Agentic RAG
Workflow	Fixed “retrieve then read” sequence	Dynamic, multi-step process (query rewriting, multi-source retrieval, or skipping retrieval)
Decision-making	None; path is predetermined	Agent makes decisions (routing, tool use, self-critique)
Data Sources & Tools	Single, unstructured knowledge base	Multiple sources (vector stores, SQL, web APIs, etc.)
Adaptability	Rigid; same process for every query	Adaptive; adjusts retrieval steps for complex, multi-hop queries

In essence, while simple RAG provides an LLM with passive access to external knowledge, agentic RAG gives it an active framework for intelligent operation. This framework enables the system to solve complex problems by dynamically choosing tools and data sources. This intelligence also extends to the knowledge base itself; an agent can autonomously update and maintain its own information, deciding what to store and how to index it for optimal relevance and accuracy.
What is the structure of agentic RAG?
As we previously saw, agentic RAG fundamentally changes how a system stores, retrieves, and uses information. Instead of a rigid pipeline, it introduces a three-staged lifecycle where agents make decisions at every step to improve the quality and relevance of the final answer. Building such a system requires three key components:
Intelligent storage: deciding what and how to index
Before any information can be retrieved, it must be stored. In a traditional RAG system, this indexing process is static. An Agentic RAG system, however, turns this into an active, intelligent process.
An agent can analyze incoming data and decide if it should be indexed at all. More importantly, it decides the most effective way to store it. This includes performing high-precision parsing of complex documents, creating rich metadata for better filtering, choosing the optimal chunking strategy, and even selecting the most appropriate embedding model for the context of the data. This ensures the knowledge base is not just a passive repository but an optimized and strategically organized source of information.
Dynamic retrieval: using the right tool for the right data
When a user asks a question, an agentic system excels at finding the right information from the best possible source. It is not limited to searching a single vector store.
Using a component often called a Retriever Router, an LLM agent analyzes the incoming query and decides the best course of action. This might mean querying a SQL database, using a web search API, or searching internal product documentation. By being equipped with a variety of tools, the system can interact with multiple, diverse data sources, ensuring it can retrieve the most relevant context, no matter where it lives.
"You are a router. Your job is to select the best tool to answer the user's query. You have two tools:

1. SQL_database_tool: Use for questions about sales, revenue, or specific metrics.
2. document_vector_store_tool: Use for questions about company policies or general information."
   Verified generation: composing and critiquing the answer
   Once the information is retrieved, the process isn't over, using an Answer Critic function, the system checks if the retrieved information has correctly and completely answered the user's original question. If the answer is incomplete or incorrect, the critic can generate a new, more specific question to retrieve the missing information and trigger another round of retrieval. This iterative process of generating and critiquing ensures the final response is accurate and comprehensive before it is ever presented to the user.
   "You are an Answer Critic. Evaluate if the GENERATED_ANSWER fully addresses the USER_QUERY. If it is incomplete, state what is missing and generate a new INTERNAL_QUERY to find the missing information."
   3 agentic RAG use cases
   Let's see how these principles work in practice through a few concrete examples. The following workflows illustrate how n8n's visual, node-based interface is perfectly suited for designing and orchestrating the complex, multi-step logic that Agentic RAG systems require.
   Adaptive RAG (choosing the right retrieval strategy)
   Not all questions are the same. Some ask for a simple fact, while others require a deep analysis. A simple RAG system treats them all identically, which can lead to poor results. This workflow demonstrates a more advanced, adaptive RAG by first analyzing the user's intent and then choosing the best retrieval strategy for that specific type of question.
   This workflow is built around a multi-stage process where agents make decisions to tailor the retrieval and generation process.
   • Query classification: When a user submits a query, the first AI agent doesn't try to answer it. Its only job is to classify the user's intent into one of four categories: Factual, Analytical, Opinion, or Contextual.
   • Strategic routing: A Switch node directs the flow to one of four distinct paths based on the classification. Each path is a specialized strategy for handling that type of query.
   • Query adaptation: On each path, another AI agent adapts the original query to optimize it for retrieval.
   • For factual queries, the agent rewrites the question to be more precise.
   • For analytical queries, the agent breaks the question down into several sub-questions to ensure broad coverage.
   • For opinion queries, the agent identifies different viewpoints to search for.
   • Tailored retrieval and generation: The adapted query is used to retrieve relevant documents from a vector store. Finally, a concluding agent generates the answer using a system prompt specifically designed for the original query type (e.g., "be precise" for factual, "present diverse views" for opinion).
     This workflow is a prime example of Agentic RAG because it moves beyond simply routing to different data sources and instead routes to different information retrieval strategies.
     The initial classification agent acts as a sophisticated Retriever Router. It's making an autonomous decision about the user's intent, which dictates the entire subsequent workflow. A simple RAG system lacks this understanding and uses a one-size-fits-all approach.
     The agents in each of the four paths actively transform the user's query. They aren't just passing it along, they are working to improve it based on the initial classification.
     AI Agent with a dynamic knowledge source
     This workflow demonstrates a core principle of Agentic RAG: dynamic source selection. Instead of relying on a single knowledge base, we'll build an AI agent that can intelligently choose between two different information sources: a static RAG database for foundational knowledge and a live search engine for current events.
     The main component of this workflow is the AI Agent node. This agent is connected to two distinct "tools" that it can use to answer questions:
   • A RAG MCP server: This server is connected to a traditional RAG database containing specific, pre-loaded information (in this case, about the Model Context Protocol).
   • A search engine MCP server: This server gives the agent the ability to perform real-time web searches, providing access to up-to-the-minute information.
     Why is this considered "Agentic RAG"? This setup goes beyond simple RAG because the AI isn't just retrieving information; it's making a decision. When a user asks a question, the agent must first analyze the query and decide which tool is best suited to answer it.
     This is the "Retriever Router" concept in action. The Model Context Protocol (MCP) acts as the communication layer that allows the agent to understand its available tools (the two servers) and choose one.
     For example, if you ask, "What is Model Context Protocol?", the agent will recognize this as a foundational question and route it to the RAG MCP Server. However, if you ask, "Who won the Formula 1 race last weekend?", the agent understands this requires current information and will use the Search Engine MCP Server to find the answer.
     This autonomous decision-making is what makes the workflow "agentic".
     AI agent for tabular and unstructured data (SQL + GraphRAG)
     This advanced workflow addresses one of the most significant challenges for traditional RAG systems: handling structured, tabular data from sources like Excel files or Google Sheets. While standard RAG excels at searching text, it often fails when asked to perform precise calculations or comparisons on relational data because the chunking process breaks the table's structure.
     This system solves that problem by creating a hybrid agent that can choose between SQL queries for tabular data and GraphRAG for unstructured documents.
     Check out the original YouTube video here:
     The workflow is built around an intelligent data ingestion process that treats data differently based on its type. The process begins when a new file is added to a designated Google Drive folder. An initial step in the n8n workflow checks the file type to determine the correct processing path.
     For tabular data (Excel/Sheets), the system executes a series of steps to properly structure it for querying:
   • The file is downloaded and its contents are extracted.
   • A code node then creates a new PostgreSQL table in a database like Supabase. It dynamically generates a database schema from the file's headers.
   • Finally, it populates the new table with the data, handling various data types like text, numbers, and dates.
     Unstructured data (PDFs, Word documents) are routed to the GraphRAG system for a more sophisticated ingestion process using a library called LightRAG. In short:
   • Instead of simply chunking the text, an LLM first analyzes the document's content to identify key entities (like people, companies, or concepts) and the relationships that connect them.
   • These extracted entities and relationships are then used to build a structured knowledge graph. This graph represents the core information from the document and is usually stored in a dedicated graph database.
     Why is this considered "Agentic RAG"? The system doesn't just index all incoming data the same way. An agent makes a decision based on the file type, choosing a different, more effective storage strategy for tabular data (SQL database) versus unstructured documents (GraphRAG).
     It also decides which knowledge source is appropriate, based on the user's question. If the query is best answered with tabular data, it generates an SQL query and uses the execute SQL query tool to get the answer directly from the database. If the question is about document content, it routes the query to the GraphRAG tool instead.
     FAQs
     What is the difference between self RAG and agentic RAG?
     While both represent advancements over simple RAG, they focus on improving the process in different ways. The key difference is that Self-RAG builds decision-making into the Language Model itself, while Agentic RAG builds decision-making into the workflow around the model.
     Self-RAG is a specific framework that fine-tunes a model to make its own retrieval decisions during generation. It uses special "reflection tokens" to internally decide if it needs to search for information, if the retrieved documents are relevant, and if its own answer is well-supported by the facts. It’s about giving the model the ability to self-correct and self-assess its own process.
     Agentic RAG, as we've discussed, is a broader architectural pattern. It uses LLM-powered agents to manage an external workflow. This includes analyzing a user's intent to choose the right tool, adapting the query to a specific strategy, and critiquing the final answer.
     What is the difference between graph RAG and agentic?
     Agentic RAG is about the intelligence and autonomy of the system's decision-making and workflow execution. Graph RAG is about the structure and richness of the underlying knowledge base, using knowledge graphs to enable more precise, relational, and multi-hop information retrieval. An Agentic RAG system might incorporate a Graph RAG as one of its specialized "retriever agents" or tools for querying structured data, demonstrating how these variants can complement each other.
     The key differentiator between traditional RAG and Graph RAG is the underlying database. Graph RAG tipically involves querying a graph database, for example Neo4j, ArangoDB etc. In contrast traditional RAG involves querying a vector database (vector stores), for example Pinecone, Qdrant, Milvus etc.
     What is the difference between RAG and multi-model RAG?
     Multi-model RAG is an approach where different, specialized AI models are used at various stages of the RAG pipeline to improve performance and handle complex tasks. This can involve several strategies:
     Diverse LLM utilization: In complex applications, a "multi-LLM strategy" can be used to assign different Large Language Models (LLMs) to the jobs they perform best. This might involve specialized task-specific models like:
3. Named Entity Recognition (NER) models to extract specific entities for metadata filtering.
4. Hallucination-detection and moderation models to ensure the quality and safety of the final answer.
   Agentic RAG is a great example of a multi-model approach. This setup uses multiple LLM agents that work together to solve a problem. These agents can have specific "profiles" (like a "coder" agent and a "tester" agent), coordinate their actions, and provide feedback to each other to tackle complex, multi-step tasks.
   Wrap up
   As we've covered, Agentic RAG is a big step up from traditional RAG systems. It moves away from the simple "retrieve-then-read" process and uses AI agents to create a smarter, more flexible workflow.
   This shift means that agents make their own decisions at every step of the information lifecycle. In the storage phase, they can intelligently figure out how to index information, choosing the best chunking strategy or metadata to make the knowledge base more effective. During retrieval, they act as a smart router, choosing the best tool for a specific query, whether that's a vector database, a SQL database, or a live web search. Finally, in the generation phase, they don't just give an answer, they can also review their own work for accuracy, triggering more search rounds if the first answer isn't good enough.
   As the n8n RAG workflow examples have shown, these capabilities are not just theories but are practical tools you can use today to build the next generation of powerful and trustworthy AI applications.
   What’s next?
   The next step is to move from theory to practice. Think about your own data and the challenges you face. Could an agent that chooses between a database and a web search improve your results? Could adapting the retrieval strategy based on a user's query provide more relevant answers?
   Check out these step-by-step video guides on how to build Agentic RAG systems with n8n:
   • I Built the ULTIMATE n8n RAG AI Agent Template
   • Store All Data Types with Agentic RAG in n8n
   • The ULTIMATE n8n Agentic RAG System (SQL + GraphRAG)
   • Building with Reasoning LLMs | n8n Agentic RAG Demo + Template
     For a deeper look into the fundamentals, explore this tutorial on building a custom knowledge RAG chatbot using n8n. You don't have to start from scratch, browse the pre-built AI workflows from the n8n community to use as a starting point for your own projects.