agentic rag：5种自主AI代理通过增强信息检索革新行业的方法

Rifx.Online
Machine Learning , Natural Language Processing , AI Applications
05 Mar, 2025

简介

检索增强生成（RAG）是一种通过基于外部知识来源来增强大型语言模型（LLM）的方法。RAG 系统不是仅仅依赖于模型在训练期间记忆的内容（这可能已经过时或有限），而是从知识库中检索相关的文档或数据，并在生成过程中将该上下文提供给 LLM。这使得模型能够生成更准确、更及时、特定领域的响应，而无需进行广泛的微调。标准的 RAG 流程通常由两个主要组件组成：一个信息检索模块（通常使用嵌入和向量数据库）和一个生成模块（LLM）。例如，给定一个用户查询，系统会生成该查询的向量嵌入，在知识库中找到相似的向量（文档），然后将这些检索到的片段与查询一起输入到 LLM 中，以生成上下文相关的答案。

然而，传统的 RAG 有其局限性。它通常遵循一个静态、线性的工作流程：一个检索步骤，然后是一个生成步骤。如果初始检索未能找到有用的信息，最终的答案很可能是一个糟糕的响应或回退。此外，原始的 RAG 使用用户的查询原文进行相似性搜索，如果查询的措辞与相关文档不同，这可能不是最佳选择。传统的 RAG 系统也没有内置的机制来推理、规划或调整其超出该一次性检索的策略。因此，它们难以处理复杂或多步骤的查询，这些查询可能需要搜索多个来源、使用不同的工具或迭代改进。在实践中，这意味着一个标准的 RAG 系统可能会在涉及模糊问题、多方面问题或动态数据源的任务上绊倒。

进入Agentic RAG的世界——一种将AI 智能体嵌入到 RAG 流程中以克服这些挑战的下一代范式。一个agentic RAG系统赋予 LLM 以自主权：自主决定何时检索信息、检索什么、如何整合结果，甚至何时要求澄清。通过结合基于智能体的系统原则（如规划、工具使用和自我完善），Agentic RAG 能够实现更具适应性和智能的检索工作流程。在以下部分中，我们将探讨 Agentic RAG 与标准 RAG 的区别，深入研究其架构，并逐步介绍实现细节。我们还将研究实际用例，讨论性能考虑因素，并概述挑战和未来趋势。本博客假设您熟悉 RAG 的基础知识，并希望了解添加一个“智能体”如何能够为您的检索增强生成系统提供助力。

Agentic RAG 与标准 RAG 的区别

Agentic RAG 在标准 RAG 的基础上，将自主决策引入到检索和生成过程中。首先将标准 RAG 流程可视化，然后将其与基于 agent 的方法进行对比，这会很有帮助。

图：一个典型的标准 RAG 流程*。用户的查询通过嵌入模型进行嵌入，该模型用于从向量数据库中检索相关文档。检索到的上下文与查询（在上下文构建器以及提示下）结合，并传递给 LLM 以生成最终答案。此流程是一个单次传递的线性流程，不涉及任何迭代推理。*

在 vanilla RAG 系统（如上图）中，该过程是直接且被动的：对于每个查询，检索一次并生成。相比之下，Agentic RAG 流程插入了一个智能 agent，可以动态地控制和编排这些步骤。该 agent（通常是 LLM 本身，带有特殊的提示）可以决定是否、何时以及如何检索信息，可能执行多个检索-生成循环，或者使用向量存储之外的附加工具。

标准 RAG 和 Agentic RAG 之间的一些关键区别*包括：

工作流程：标准 RAG 遵循固定的单次检索和生成序列。Agentic RAG 使用由 agent 的推理引导的灵活的迭代工作流程。该 agent 可以执行多个检索/生成步骤，分解问题，或在中途更改策略。这意味着 Agentic RAG 可以处理静态 RAG 流程会难住的多步推理任务。
决策制定和适应性：在标准 RAG 中，系统始终进行检索然后停止，没有检查答案是否足够的概念。一个 agent 系统是自适应的：agent 可以评估中间结果，并决定检索更多信息或使用不同的工具，如果当前上下文似乎不足。从本质上讲，Agentic RAG 从基于规则的查询过渡到自适应问题解决，甚至允许多个 AI agent 协作和验证彼此的结果。
工具使用和数据源：传统的 RAG 通常将 LLM 连接到单个知识源（例如，一个文档的向量数据库）。Agentic RAG 更加灵活：该 agent 可以利用多个知识库和工具。例如，一个 agent 可以从私有文档索引中检索，调用 Web 搜索 API 获取外部信息，甚至使用计算器或其他 API —— 所有这些都在一个会话中完成。这种多工具功能意味着 Agentic RAG 可以根据需要从异构数据源（结构化数据库、非结构化文本、Web 等）中提取信息。
自我反思和准确性：一个标准的 RAG 模型不会自我验证其答案；正确与否取决于用户或开发人员。Agentic RAG agent 可以结合自我反思和反馈循环。例如，在检索上下文和草拟答案后，该 agent 可以仔细检查问题是否已完全回答或是否存在差距，然后决定获取更多信息或完善查询。这种迭代改进循环可以随着时间的推移提高答案的准确性，因为 agent 学会纠正错误或填补缺失的部分。简而言之，Agentic RAG 引入了一种 vanilla RAG 缺乏的自动验证和优化形式。
可扩展性和复杂性：由于 Agentic RAG 可能涉及多个 agent 和工具协同工作，因此它往往在范围上更具可扩展性——处理更广泛的查询类型和数据源。例如，您可以部署一个由专门 agent 组成的网络：一个用于查询内部文档，一个用于查询 API 或 Web，所有这些都由一个主 agent 协调。这种分布式方法可以比单个 RAG 模型覆盖更广的范围。当然，权衡的代价是增加了系统复杂性。在管理 agent 交互（如 CrewAI 等框架提供了有效执行此操作的功能）、工具集成以及跨回合维护状态方面存在开销。稍后我们将讨论性能影响，但值得注意的是，Agentic RAG 的强大功能是以更精细的流程为代价的。
多模态：传统的 RAG 通常处理基于文本的检索。Agentic RAG，通过先进的 LLM agent，可以结合多模态数据。由于最近的多模态 LLM，一个 agent 可以检索和推理图像、音频或其他数据类型以及文本。例如，一个 agent 可能会从数据库中提取图像，并使用图像字幕模型作为工具来解释它，将结果整合到答案中。这在 vanilla RAG 流程中并不常见，但 Agentic RAG 系统正开始探索此类功能。

下表总结了其中一些差异：

从本质上讲，Agentic RAG 将 RAG 的事实依据与 AI agent 的自主性和推理相结合。通过这样做，它解决了 vanilla RAG 的许多局限性，从而实现了更灵活、准确和能够处理复杂信息需求的系统。

架构深度解析

现在，让我们详细研究 Agentic RAG 系统的架构。从高层次来看，Agentic RAG 架构在通常的检索和生成组件之上引入了一个智能体层。这个智能体层可以实现为一个强大的单一智能体，或者是一组协同工作的专业智能体（一个多智能体系统）。我们将首先描述最简单的单一智能体情况，然后考虑更复杂的设置。

在单一智能体 RAG 架构中，智能体充当查询工作流程的智能“路由器”或控制器。涉及的组件包括：

用户查询：以自然语言提出的输入问题或任务。
智能体 (LLM)：一个 LLM（或 LLM 与一些程序逻辑的组合），该 LLM 已经被提示或设计来决定采取的行动。该智能体可以访问一个或多个工具——例如，向量数据库查找工具、网络搜索工具等。该智能体使用推理策略（通常通过链式思考提示）来确定在每个步骤中采取哪个行动。
知识来源/工具：这些可以包括向量数据库（用于基于嵌入的文档检索）、关键字搜索引擎、API（例如天气 API、计算器、SQL 数据库接口），甚至是其他从属智能体。在 Agentic RAG 的上下文中，至少有一个工具是检索器，可以获取与查询相关的上下文。
生成模型：最后，是 LLM 的生成步骤。在许多实现中，智能体本身就是生成答案的 LLM（一旦它收集了足够的信息）。在其他情况下，智能体可能会将最终答案的构建委托给一个单独的 LLM 实例，但在概念上，是同一个 LLM 负责推理和回答。

在单一智能体系统中，流程通常如下所示（对于给定的查询）：

智能体决策 — 需要检索：智能体检查查询（以及到目前为止的对话上下文，如果是多轮对话），并决定是否需要外部信息。对于一个简单的事实性问题，智能体可能会继续搜索知识库。如果查询非常简单或符合常识，智能体甚至可以决定直接回答而不进行检索（尽管在实践中，许多系统总是尝试检索）。这一条件步骤已经与标准 RAG 不同，标准 RAG 无论如何都会进行检索。
智能体决策 — 选择工具/来源：如果需要检索，智能体选择使用哪个工具或数据源。在路由器场景中，可能存在多个向量索引（例如，一个索引用于技术文档，另一个用于产品常见问题解答），智能体选择最有可能包含答案的索引。或者，它可能在向量数据库与网络搜索 API 之间进行选择，以回答有关时事的问题。这本质上是查询路由，是智能体系统的一项强大功能。
制定检索查询：然后，智能体制定查询，以输入到所选的检索工具中。这可以像逐字使用用户的提问一样简单，也可以是重新表述的版本。高级智能体实现可能会采用查询扩展或假设性问答等技术来改进检索。（例如，使用 HyDE 等方法，智能体可以生成一个想象的答案，并将其用作语义搜索查询。
检索和观察：检索工具（例如向量搜索）返回一些候选文档或数据。智能体“观察”这些结果。现在智能体可以决定：这些信息是否回答了问题，或者是否需要进一步的行动？如果结果不相关或不充分，智能体可能会循环回到步骤 2 或 3：可能尝试不同的数据源或重新表述查询并再次搜索。这个循环赋予 Agentic RAG 其自适应能力——如果第一次尝试不够好，能够自我纠正和迭代。
生成答案：一旦智能体收集了足够的支持信息（或确定检索无济于事），它就会使用 LLM 撰写最终答案。检索到的上下文通常包含在此答案生成步骤的提示中，类似于标准 RAG。智能体的链式思考也可能影响答案的框架方式（例如，如果被指示这样做，智能体可能会在答案中明确引用来源）。

在代码或伪代码中，简化的智能体循环可能如下所示：

while True:
    action = agent.plan(next_step, context_so_far)
    if action.type == "SEARCH":
        tool = action.tool_selection   # e.g. "VectorDB" or "WebSearch"
        query = action.formulated_query
        results = tool.run(query)
        agent.observe(results)
    elif action.type == "ANSWER":
        final_answer = agent.generate_answer(context_so_far)
        break

此循环持续进行，直到智能体决定准备好输出答案（或达到安全的最大步骤限制）。

现在，让我们可视化架构。下面是一个图表，说明了 Agentic RAG 智能体与多个工具在循环中的交互：

图：带有自主智能体的Agentic RAG 架构。智能体（具有推理策略的 LLM）接收用户的输入，并给出指令，这些指令在非线性工作流程中采取多个行动。在本图中，智能体可以使用 RAG（向量数据库查找）、网络搜索或其他 API 等工具。在生成答案之前，它可能会执行多个工具调用（甚至组合结果）。如果需要，智能体还可以决定向用户提出后续问题（使交互具有对话性）。这个灵活的循环持续进行，直到智能体确信它可以回答查询。将其与之前的单次传递图进行对比——在这里，智能体有效地将一个反馈循环和决策分支插入到 RAG 管道中。有关更多信息，请参阅此博客，其中详细讨论了 ReAct 和 CoAct 之间的区别。

一个与 CoAct 架构类似的例子将类似于下图所示的图：

在上图中，智能体甚至可以按顺序执行多个操作（例如，进行网络搜索，然后将这些结果输入到向量数据库查询中），并根据需要重复。这展示了 Agentic RAG 的非线性、自主工作流程特征。

对于更复杂的部署，我们可以拥有多智能体 RAG 系统。不是单个智能体处理所有事情，而是为多个智能体分配专门的角色。例如，你可能会有：

![](https://wsrv.nl/?url=https://cdn-i

Agentic RAG：检索增强生成的下一次演进

检索增强生成（RAG）已迅速成为提高大型语言模型（LLM）准确性和可靠性的流行技术。然而，经典的 RAG 流程存在局限性。它通常涉及单个检索步骤和单个生成步骤，这对于复杂的查询可能是不够的。另一方面，Agentic RAG 引入了 agent 的概念，这些 agent 可以推理、做出决策并相互交互，以提高 RAG 系统的整体性能。

核心思想：Agent 和协调

Agentic RAG 的核心思想是将一个复杂的任务分解为更小、更易于管理且可以由专门的 agent 处理的子任务。然后，这些 agent 可以协作以解决整个任务。这种方法具有以下几个优点：

提高准确性： Agent 可以被设计为专注于任务的特定方面，从而产生更准确的结果。
增强鲁棒性： 多个 agent 可以相互核对彼此的工作，使系统对错误更具鲁棒性。
增加灵活性： 基于 agent 的架构允许在适应不同类型的查询和数据源方面具有更大的灵活性。

Agent 设计和协作

在 Agentic RAG 系统中，每个 agent 负责一个特定任务。例如，您可能拥有：

一个 Web Agent，仅处理查询外部 Web 资源，
一个 DB Agent，仅查询内部数据库，
和一个 Coordinator Agent，它将问题委托给相应的专家，然后汇总调查结果。

这种多 agent 设置甚至可以让 agent 相互查询：一个 agent 可能会调用另一个 agent 作为“工具”来完成一个特定的子任务。在实践中，一个多 agent RAG 可能看起来像一个 agent 协作的层次结构或网络。例如，IBM 描述了一个 Agentic RAG 系统，其中 一个 agent 查询外部数据库，而另一个 agent 梳理电子邮件和内部数据，每个 agent 都使用自己的检索方法。然后，协调器将它们的输出组合起来形成最终答案。这种设计可以提高鲁棒性（agent 相互核对）和专业化，但代价是增加了复杂性。

总而言之，我们可以说 Agentic RAG 架构使用一个 agent（或多个 agent）增强了经典的检索和生成流程，这些 agent 引入了推理、决策点，以及可能的多步循环。这种架构本质上比 vanilla RAG 更复杂，但在处理需要灵活性的现实世界任务方面更强大。接下来，我们将看到如何在实践中实现这样的架构，包括哪些工具和框架可以提供帮助。

实现细节

如何构建一个 Agentic RAG 系统？在本节中，我们将概述一个分步实施方案，并附带代码片段。我们假设您对 Python 和常见的人工智能框架有一定的工作知识。我们将使用 LangChain，尽管它不是唯一的，市场上也有很多最好的，我们将在后续的博客中亲身体验它们，但让我们从这个例子开始（一个用于构建 LLM 应用程序的开源框架），以说明如何使用检索工具构建一个 agent，同样，您可以使用其他库或从头开始实现类似的想法。

1. 设置用于检索的知识库

首先，您需要一个知识来源进行检索——通常是用于文档的向量存储。这部分本质上与标准 RAG 设置相同。您将准备文本数据（文档、维基百科文章、PDF 等）的语料库，将它们分成段落，将它们嵌入到向量表示中，并将它们在向量数据库（FAISS、Chroma、Weaviate、Qdrant 等）中建立索引。

例如，使用 LangChain 和 FAISS：

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import FAISS

## Suppose we have a list of documents (strings) in docs_list
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = text_splitter.create_documents(docs_list)

## Create embeddings and index in FAISS
embedding_model = OpenAIEmbeddings()  # using OpenAI embeddings (requires API key)
vector_store = FAISS.from_documents(docs, embedding_model)

在上面的代码片段中，我们将文档分成大约 500 个字符的块，并为每个块创建嵌入，将它们存储在 FAISS 索引中。现在，可以查询 vector_store 以获取给定新查询嵌入的相似文档。

（在一个真实系统中，您可以使用本地 Transformer 模型进行嵌入（例如，SentenceTransformers）以提高效率。目标是拥有一个 vector_store，它有一个方法可以为任何查询检索 top-k 相关的段落。）

2. 为 Agent 定义工具

接下来，我们定义 agent 可以使用的工具。至少，我们将有一个检索工具，它封装了对向量存储的调用。我们还可以添加其他工具——为了说明，让我们包括一个网络搜索工具（它可以是任何 searchAPI 的简单包装器或一个虚拟函数，因为我们实际上无法在此处调用互联网）。

使用 LangChain 的工具接口：

from langchain.agents import Tool

## Define a function to query the vector store
def vector_search(query: str) -> str:
    """Search the vector DB for relevant docs and return a concatenated string of results."""
    docs = vector_store.similarity_search(query, k=3)
    # Combine the content of retrieved docs (with maybe metadata or snippet formatting)
    return "\n".join([doc.page_content for doc in docs])

## Create the retrieval tool
retrieval_tool = Tool(
    name="VectorDB",
    func=vector_search,
    description="Retrieve relevant documents from the knowledge base."
)

## (Optional) Define a second tool, e.g., a web search (here we simulate it)
def web_search(query: str) -> str:
    # This is a placeholder for an actual web search API call.
    # In practice, use an API like SerpAPI or Bing API.
    return fake_web_search_api(query)

search_tool = Tool(
    name="WebSearch",
    func=web_search,
    description="Search the web for up-to-date information."
)

这里我们创建了两个工具：VectorDB 和 WebSearch。每个工具都只接受一个字符串输入并返回一个字符串输出（例如，检索到的文本）。agent 在规划操作时将按名称使用这些工具。

3. 初始化 Agent

现在我们设置 agent 本身。我们选择一个 LLM 来驱动 agent 的推理——例如，OpenAI GPT-4 模型或本地 LLM。然后，我们初始化一个可以访问上面定义的工具的 agent。LangChain 提供了方便的 agent 初始化函数；对于这些用例，一种常见的配置是“ReAct”风格的 agent（它使用推理提示格式 Thought/Action/Observation）。

from langchain.chat_models import ChatOpenAI
from langchain.agents import initialize_agent

## Initialize the language model for the agent (using a chat model in this case)
llm = ChatOpenAI(model_name="gpt-4", temperature=0)  # or another LLM of choice

## Create the agent with tools. We use a verbose setting to observe its thought process.
agent = initialize_agent(
    tools=[retrieval_tool, search_tool],
    llm=llm,
    agent="zero-shot-react-description",  # This tells LangChain to use a ReAct-based agent
    verbose=True
)

在幕后，这设置了一个提示策略，其中 agent LLM 被指示如何使用工具。zero-shot-react-description agent 将使用工具 description 字符串来决定何时以及如何调用它们。当我们运行 agent 时，它将输出它的思维链（因为我们设置了 verbose=True），显示诸如：“Thought: I should search the knowledge base. Action: VectorDB…” 等步骤，遵循 ReAct 模式 (Agentic RAG)。

4. 提问（Agent 运行）

准备好我们的 agent 后，现在我们可以向它提供一个用户查询并获得答案：

query = "What are the main differences between standard RAG and Agentic RAG?"
response = agent.run(query)
print("Agent's answer:", response)

当这段代码执行时，agent 将在内部决定如何回答这个问题。它可能会首先使用 VectorDB 工具，并使用一个类似 “standard RAG and Agentic RAG differences” 的查询。如果我们的知识库中有一个已索引的文章（比如这篇博文或相关文档），向量搜索可能会返回一个列出这些差异的段落。agent 将读取结果（ReAct 中的 Observation），然后继续。由于这个查询直接询问差异，单个检索可能就足够了，然后 agent 将生成一个列出差异的答案（可能引用它所看到的上下文）。如果问题更复杂，agent 也可以决定调用 WebSearch 来获取外部信息，或者使用一个更精细的问题进行另一次 VectorDB 查询。

幕后发生的事情是 agent 使用 LLM 来模拟一个推理链。例如，LLM 可能会输出一个类似于以下的思考过程：

Thought: The query asks for differences between standard RAG and Agentic RAG. I should recall what Agentic RAG means.
Action: VectorDB["standard RAG Agentic RAG differences"]
Observation: (receives some text about RAG vs Agentic RAG)
Thought: I got some points about flexibility and adaptability. The question likely expects a list of differences.
Action: Answer["Agentic RAG differs from standard RAG in several ways..."]

然后返回最终答案。通过检查 agent 的思考（如果 verbose=True），开发人员可以调试 agent 是否做出了好的选择，或者它是否陷入困境或幻觉出一个动作。

5. 替代实现方法

虽然我们演示了使用 LangChain，但您可以使用其他框架（如 Autogen、CrewAI、BAML、PydanticAI、Agno、Huggingface 等）来实现 Agentic RAG 逻辑。

无论您选择哪种实现路径，核心思想都是：定义您的知识来源，将它们包装为工具或函数，并在一个循环中提示 LLM 使用这些工具并最终回答问题。复杂性可以从一个简单的路由器（提示中的 if-else 逻辑）到一个完全自由的 agent，它自己决定一切。一个简单的方法通常是一个好的起点——例如，如果需要，只允许一个额外的检索（一个两步 RAG）就可以在许多情况下提高准确性。

比较性能和可扩展性

随着 Agentic RAG 带来的复杂性增加，一个自然而然的问题是：性能影响是什么，我们是否能获得可衡量的收益？答案取决于我们所考虑的性能方面——答案质量、延迟/吞吐量和可扩展性，它们各自受到的影响不同。让我们分解一下这些考虑因素以及任何已知的发现：

答案质量和成功率： Agentic RAG 的主要动机是提高复杂查询的成功率。通过允许多次检索尝试和更智能的查询制定，Agentic RAG 可以检索到单次 RAG 可能会遗漏的相关信息。从经验上讲，这通常转化为更高的答案准确性和“我不知道”或幻觉答案的减少。例如，Hugging Face 的团队指出，一种 agentic 方法恢复了高级 RAG 技术（如查询重构和迭代检索），因此可以找到普通 RAG 可能会遗漏的信息。虽然确切的基准数字取决于具体情况，但可以考虑这样的场景：在 100 个难题中，普通 RAG 可能获得 60 个正确答案，而 Agentic RAG（通过两步检索）可能会将其提高到 75 个正确答案，因为它可以在运行时修复错误。在关键任务领域（法律、医疗），这种正确性的提高是关键的性能指标。
计算开销和延迟： Agentic RAG 本质上更耗费资源。调用 LLM 代理进行多步推理意味着更多的 LLM 调用（每次工具使用通常都需要 LLM 在前后进行思考）和更多的检索操作。这增加了单个查询的延迟，也增加了计算成本（如果使用 API 调用 LLM）。正如 Qdrant 的文章所指出的，标准 RAG 通过一次 LLM 调用提供快速答案，而代理可能需要进行多次调用，并且延迟会累积起来。例如，如果普通 RAG 在 2 秒内响应，则 Agentic RAG 可能需要 5-10 秒，具体取决于它运行的步骤数。对于许多交互式应用程序，这种延迟仍然是可以接受的，但需要注意这种权衡。还有一个吞吐量方面的问题——每个查询执行更多工作的系统将在相同的硬件上支持更少的每秒查询。限制代理步骤的数量或使用更快（但可能不太准确）的模型作为代理等技术可以缓解这种情况。
数据源的可扩展性： 积极的一面是，Agentic RAG 可以扩展到更丰富的数据生态系统。因为它可以协调多个来源，所以您可以继续向代理的工具/索引库中添加内容以扩大其知识范围。 IBM 指出，RAG 代理网络接入多个数据孤岛，可以在处理各种查询时实现更大的可扩展性。如果您只是向标准 RAG 投入更多数据（例如，一个巨大的向量索引如果太大可能会变得缓慢或不精确），它可能会崩溃，而智能地将查询路由到正确子索引的代理可以更好地随着数据的增长而扩展。这更像是一种系统设计可扩展性——系统可以覆盖更大的范围，尽管如前所述，每个查询都比较慢。基本上，Agentic RAG 牺牲了一些运行时性能，以换取范围和灵活性的可扩展性。
基准测试注意事项： 为了评估 Agentic RAG 与标准 RAG 的对比，人们可能会使用答案准确度、F1 或一组查询的检索召回率等指标，以及测量平均延迟。截至目前，还没有专门针对“agentic 与非 agentic RAG”性能的标准基准，但研究人员正在调整 QA 基准来测试多步检索。早期迹象（来自社区实验）显示，使用 agentic 方法时，失败的查询更少，并且对边缘情况的处理更稳健。如果您的用例涉及关键准确性（例如，减少幻觉），Agentic RAG 可能值得付出性能成本。如果您需要对简单查询进行闪电般的快速响应，那么更简单的 RAG 可能就足够了。
系统复杂性和维护： “性能”的另一个方面是系统的维护和扩展有多容易。 Agentic RAG 具有更多活动部件，这意味着更多出现错误或意外交互的机会。例如，如果代理没有得到适当的约束，它可能会陷入工具调用循环。监控和调试这些系统并非易事——开发人员通常需要跟踪代理的推理步骤。像 Arize 的 Phoenix 或 LangSmith 这样的工具可以跟踪代理决策以帮助调试。就工程工作量而言，请考虑您可能会花费更多时间来调整提示、平衡代理何时停止以及更新知识来源。因此，虽然这本身不是一个“性能指标”，但这种复杂性是一项需要考虑的成本。 DigitalOcean 的比较分析强调了集成开销——将检索模块与代理逻辑相结合可能比单通道管道更复杂。

因此，Agentic RAG 倾向于以更高的延迟和系统复杂性为代价来提高答案质量和多功能性。对于许多应用程序来说，这种权衡是值得的，特别是如果查询足够复杂以至于需要它。一种明智的方法是选择性地使用 Agentic RAG：例如，为简单的常见问题解答部署一个标准 RAG，但对于更难的查询或当简单方法失败时切换到 Agentic 管道。这样，您就可以平衡吞吐量和准确性。随着该领域的成熟，我们预计会对代理步骤进行更好的优化（也许缓存结果，使用更小的模型进行推理等），以缩小性能差距。

Agentic RAG 的挑战与未来

虽然 Agentic RAG 强大，但并非没有挑战。在设计和部署此类系统时，务必了解这些局限性。与此同时，Agentic RAG 的未来非常令人兴奋，积极的研究和快速发展正在解决许多此类问题。

主要挑战：

复杂性和可调试性：如前所述，Agentic RAG 系统比标准管道更复杂。管理多个代理或工具及其交互可能很困难。可能会出现错误或故障模式，例如代理进入检索的无限循环或选择次优工具。追踪推理（“代理为什么要做 X？”）需要对思维链进行良好的日志记录。开发人员需要强大的监控。例如，Arize 建议跟踪代理的决策和结果，以确保系统行为正常并查明问题所在。如果提示没有精心设计，也可能发生工具误用或误解指令的情况。
延迟和成本：如前所述，迭代的性质增加了推理成本。这可能会成为实时应用程序或预算有限的应用程序的障碍。必须仔细决定超时或步数限制，以使代理不会尝试太久。缓存中间结果并重复使用它们可能会有所帮助（实际上，一些代理框架实现了某种形式的语义记忆或缓存先前的查询，以避免重复工作）。
数据质量和知识边界：RAG 和 Agentic RAG 都严重依赖于底层数据的质量。如果知识库不完整或包含错误/偏差，代理可能会检索误导性信息，然后自信地使用它，从而可能使错误复杂化。代理还带来了“脱离脚本”的风险——例如，以非预期的方式使用工具，或引入可能不相关甚至不安全的信息。确保代理不违反数据访问策略非常重要（例如，某些工具只能用于某些查询）。
安全性和伦理问题：如果未正确沙盒化，具有更大自主权的代理可能会执行不良操作。例如，如果给定一个可以执行代码或发送请求的工具，它应该有约束以防止滥用。目前正在积极研究如何使代理更值得信赖——例如，结合 LLM 输出的可信度估计，以决定是否信任检索到的信息片段或对其进行复查。一个代理批评另一个代理的多代理设置也有助于发现错误，但这并非万无一失。还有伦理方面的考虑：一个自动搜索网络的代理可能会偶然发现受版权保护的文本并将其包含在答案中，或者可能需要过滤以避免从开放来源检索不当内容。
评估：如何评估 Agentic RAG 系统？传统的指标（如答案准确性）适用，但评估代理的决策过程更加棘手。代理是否使用了最佳的步数？它是否每次都选择了正确的工具？目前正在进行研究，以定义代理的评估指标（一些研究人员关注“工具使用效率”等问题，或者让人类评估代理的推理是否合理）。确保可重复性也面临挑战——由于 LLM 的随机性，代理在对同一查询的不同运行中可能会采取不同的操作。在受控设置中，设置随机种子或使用确定性模式可能会有所帮助，但生产系统仍可能出现可变性。

未来趋势和发展：

尽管面临挑战，Agentic RAG 还是一个快速发展的领域，具有广阔的前景：

更好的代理框架：我们预计会看到更多成熟的框架，这些框架使构建和约束代理变得更容易。例如，微软的 Autogen 库允许定义多代理对话和工具使用，结构更清晰（并且正在积极改进）。未来的框架可能包括内置的安全检查、循环检测和针对常见模式（如检索然后提出后续问题）的优化。随着这些工具的改进，实施代理解决方案的障碍将会降低。
规划算法的集成：目前正在研究将经典规划或强化学习与基于 LLM 的代理相结合。Agentic RAG 可以从非 LLM 规划算法中受益，以更系统地决定检索的顺序（而不是完全依赖于 LLM 的学习推理，这可能不稳定）。这可以使代理行为更可预测和更优化。
从反馈中学习：目前，大多数代理都是通过提示手动创建的。未来，我们可能会看到 基于学习的代理，其中代理策略会根据反馈或演示进行微调。想象一下，在多步搜索的示例上微调 LLM，以便它学习何时执行一次检索，何时执行两次检索等。这与诸如*从人类反馈中进行强化学习 (RLHF)*等技术应用于工具使用的情况重叠。一个相关的想法是让代理学习自我改进——例如，记住哪些策略适用于哪些查询，从而实现随时间的元学习。
多模态和多步推理：随着 LLM 获得多模态能力（参见 GPT-4 等），Agentic RAG 可能会扩展到这些模态。我们可能会看到一个代理，它可以检索图像或图表作为上下文，并将其合并到答案中，或者即时生成可视化。此外，检索和操作之间的界限可能会变得模糊——例如，代理可能不仅“检索”静态信息，还会触发计算（例如检索运行模拟的结果）。未来的代理可能是一个通用的问题解决助手，而 RAG 只是众多工具之一。
与知识图谱和符号 AI 的融合：将 LLM 代理与知识图谱或数据库相结合，以进行更基于知识的推理的趋势也在不断发展。Agentic RAG 可以使用知识图谱来验证答案的一致性（从结构化的方式检查其工作）。神经符号 AI 的努力表明，代理可以在推理循环中将非结构化信息转换为结构化形式，以提高准确性。
标准化和最佳实践：随着越来越多的案例研究出现（在医疗保健、金融等领域），我们可能会看到 Agentic RAG 的最佳实践被记录下来。例如，关于如何选择代理数量、如何有效地进行查询路由、如何在代理的上下文中处理用户后续问题等的指南。社区已经在分享模式；例如，Qdrant 文章中描述的“路由器”代理与完整“自主”代理的概念有助于设计人员为其需求选择正确的复杂性级别。

因此，Agentic RAG 是检索增强生成理念的强大演变，使我们更接近于能够思考、检索的 AI 系统

Agentic RAG：智能检索增强生成的新范式

什么是检索增强生成（RAG）？

检索增强生成（RAG）是一种人工智能框架，它通过结合大型语言模型（LLM）的生成能力和外部知识库的检索能力来提高LLM的性能。传统的LLM在生成文本时主要依赖于预训练期间学习到的知识，而RAG系统则允许LLM访问并利用最新的、私有的或特定领域的知识。

RAG系统的工作流程通常包括以下几个步骤：

索引和嵌入： 将知识库中的文档进行切分、处理，并生成向量嵌入。这些嵌入将用于后续的检索过程。
查询理解： 将用户提出的问题或查询转化为向量嵌入。
检索： 使用查询嵌入在知识库的嵌入中进行相似性搜索，找到与查询相关的文档。
增强： 将检索到的文档作为上下文，与原始查询一起输入到LLM中。
生成： LLM基于查询和检索到的上下文生成答案。

RAG架构的优势在于：

知识更新： RAG系统可以轻松地更新知识库，从而使LLM能够获取最新的信息。
可解释性： RAG系统可以提供生成答案的依据，用户可以追溯到支持答案的文档。
领域适应性： RAG系统可以针对特定领域构建知识库，从而提高LLM在特定领域的表现。
减少幻觉： 通过检索外部知识，RAG系统可以减少LLM生成虚假信息的可能性。

Agentic RAG 架构

Agentic RAG是RAG架构的一种演进，它引入了自主代理（Agent）的概念，使得RAG系统能够更智能地处理复杂的查询和任务。Agentic RAG系统通常包含多个Agent，每个Agent负责不同的任务，例如：

查询分解Agent： 将复杂的查询分解成更小的子查询。
检索Agent： 从多个知识库中检索相关信息。
信息提炼Agent： 过滤和提炼检索到的信息，提取关键内容。
推理Agent： 对提炼后的信息进行推理，生成最终的答案。
生成Agent： 基于推理结果生成最终的文本答案。

Agentic RAG系统的优势在于：

处理复杂查询： Agentic RAG系统可以通过分解查询和协同多个Agent来处理复杂的、多步骤的查询。
增强检索能力： Agentic RAG系统可以使用多个检索Agent，从不同的知识库中检索信息，从而提高检索的全面性和准确性。
提高生成质量： Agentic RAG系统可以通过信息提炼和推理来提高生成答案的质量和准确性。
自动化流程： Agentic RAG系统可以自动化RAG流程中的多个环节，从而提高效率。

Agentic RAG 的关键组件

Agentic RAG系统通常包含以下关键组件：

Agent框架： 提供Agent的定义、管理和协作机制。常用的Agent框架包括LangChain、Haystack等。
LLM： 用于生成文本、进行推理和执行Agent之间的协作。
知识库： 存储用于检索的文档和数据。
向量数据库： 用于存储文档的向量嵌入，并进行相似性搜索。
工具： Agent可以使用的工具，例如搜索引擎、计算器、API调用等。
流程编排： 定义Agent之间的交互流程，以及任务的分解和组合方式。

Agentic RAG 的应用场景

Agentic RAG系统可以应用于各种需要智能信息检索和生成任务的场景，例如：

智能客服： 提供更智能、更准确的客户服务，能够处理复杂的问题和查询。
知识管理： 帮助用户快速检索和获取企业内部的知识，提高工作效率。
内容创作： 辅助内容创作者进行研究、写作和编辑，提高创作效率和质量。
数据分析： 从海量数据中提取有价值的信息，并生成分析报告。
个性化推荐： 根据用户偏好和行为，推荐个性化的内容和服务。

Agentic RAG 的实现步骤

实现Agentic RAG系统通常需要以下步骤：

需求分析： 确定Agentic RAG系统的应用场景、目标用户和功能需求。
架构设计： 设计Agentic RAG系统的整体架构，包括Agent的数量、类型、交互流程等。
数据准备： 准备知识库数据，包括文档的收集、清洗、切分和嵌入。
Agent开发： 开发各个Agent，包括查询分解Agent、检索Agent、信息提炼Agent、推理Agent和生成Agent。
流程编排： 使用Agent框架或流程编排工具，定义Agent之间的交互流程。
系统集成： 将各个组件集成在一起，构建完整的Agentic RAG系统。
测试和优化： 对系统进行测试，并根据测试结果进行优化，提高系统的性能和准确性。

Agentic RAG 的挑战与未来发展

Agentic RAG系统虽然具有很多优势，但也面临一些挑战：

Agent协作： 如何有效地协调多个Agent之间的协作，确保任务的正确完成。
知识库管理： 如何有效地管理和更新知识库，确保知识库的准确性和完整性。
性能优化： 如何提高Agentic RAG系统的性能，使其能够快速响应用户的查询。
可解释性： 如何提高Agentic RAG系统的可解释性，使用户能够理解系统生成答案的原因。

未来，Agentic RAG系统将朝着以下几个方向发展：

更智能的Agent： Agent将具备更强的推理能力、学习能力和适应能力。
更灵活的架构： Agentic RAG系统将支持更灵活的架构，可以根据不同的任务和需求进行定制。
更高效的检索： 检索技术将不断发展，提高检索的效率和准确性。
更强大的工具： Agent将可以使用更强大的工具，例如更先进的搜索引擎、API调用等。
更广泛的应用： Agentic RAG系统将在更多的领域得到应用，例如医疗、教育、金融等。

结论

Agentic RAG是RAG架构的一种重要发展方向，它通过引入Agent的概念，使得RAG系统能够更智能地处理复杂的查询和任务。虽然Agentic RAG系统还面临一些挑战，但随着技术的不断发展，Agentic RAG系统将在未来发挥越来越重要的作用，为人工智能应用带来新的可能性。Agentic RAG systems will learn, adapt, evolve, and refine like a human researcher might. While there are challenges in making these systems robust and efficient, ongoing research and engineering advances are rapidly addressing them. The future likely holds Agentic RAG systems that are more efficient, secure, and easier to build, enabling a new class of intelligent applications.

Agentic RAGs：检索增强生成的下一代技术

Agentic RAGs 代表了从标准检索增强生成模型到更具适应性和智能性的重大飞跃。通过赋予 LLMs 代理能力——即规划、调用工具和迭代的能力——我们得到了能够处理更复杂查询、无缝集成多个数据源并持续改进其结果的系统。

Agentic RAGs 不仅仅从检索到的信息中生成答案，而是通过智能地管理整个检索生成过程来推动 AI 系统的发展。对于 AI/ML 工程师来说，掌握这种模式开启了构建以前无法实现的助手和应用程序的可能性——那些能够真正研究、推理和响应并具有高度自主性的应用程序。我衷心鼓励您尝试本文中提出的想法和代码示例，查阅参考文献以进行更深入的探讨，并考虑如何将 agentic 检索增强生成应用于您自己的领域或项目。

参考文献

【1】 A. Singh 等人，“Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG,” arXiv 预印本 arXiv:2501.09136, 2025. 综述文章概述了 RAG 的演进以及自主代理的整合，其中包含 Agentic RAG 架构的分类和行业应用 ([2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG) ([2501.09136] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG).
【2】 IBM Cloud 博客 — Ivan Belcic, Cole Stryker, “What is agentic RAG?”, 2025 年 3 月. 介绍了 Agentic RAG 及其相对于传统 RAG 的优势，重点介绍了灵活性、适应性、准确性、可扩展性和多模态 (What is Agentic RAG? | IBM) (What is Agentic RAG? | IBM).
【3】 Weaviate 博客 — “What is Agentic RAG?”, 2024 年 11 月. 解释了基于代理的 RAG 实现，包括代理如何编排 RAG 组件、单代理（路由器）与多代理架构，以及检索代理及其操作的示例 (What is Agentic RAG | Weaviate) (What is Agentic RAG | Weaviate).
【4】 Qdrant 技术博客 — K. Łukawski, “What is Agentic RAG? Building Agents with Qdrant,” 2024 年 11 月. 深入探讨了将 RAG 与代理相结合的技术，描述了标准 RAG 与 Agentic 工作流程、路由代理、具有循环的自主代理，以及查询扩展和质量判断等工具的示例 (What is Agentic RAG? Building Agents with Qdrant — Qdrant) (What is Agentic RAG? Building Agents with Qdrant — Qdrant).
【5】 Arize AI 博客 — Trevor LaViale, “Understanding Agentic RAG,” 2024. 讨论了传统 RAG 的局限性以及 Agentic RAG 如何为检索添加智能。包括使用 LlamaIndex ReAct 代理与向量和 SQL 工具的教程，以及监控此类系统的重要性 (Understanding Agentic RAG — Arize AI) (Understanding Agentic RAG — Arize AI).
【6】 DigitalOcean 社区 — Adrien Payong 等人，“RAG, AI Agents, and Agentic RAG: An In-Depth Review and Comparative Analysis,” 2025 年 1 月. 综合文章比较了标准 RAG、AI 代理和 Agentic RAG，包括理论背景、用例（医疗保健、法律、客户支持）以及特性比较表 (RAG, AI Agents, and Agentic RAG: An In-Depth Review and Comparative Analysis | DigitalOcean) (RAG, AI Agents, and Agentic RAG: An In-Depth Review and Comparative Analysis | DigitalOcean).
【7】 Hugging Face Cookbook — Aymeric Roucher, “Agentic RAG: turbocharge your RAG with query reformulation and self-query!”, 2023. 教程演示了代理增强的 RAG，该 RAG 执行迭代检索。重点介绍了 vanilla RAG 的局限性（单次检索步骤、语义不匹配）以及代理如何制定更好的查询并根据需要重新搜索 (Agentic RAG: turbocharge your RAG with query reformulation and self-query! — Hugging Face Open-Source AI Cookbook) (Agentic RAG: turbocharge your RAG with query reformulation and self-query! — Hugging Face Open-Source AI Cookbook).
【8】 LangChain 文档 — “Retrieval Agents / Agentic RAG,” LangChain AI, 2023. 关于在 LangChain 中实现检索代理的文档，展示了如何为 LLM 提供检索器工具，以及如何使用 ReAct 决定何时查询向量索引 (Agentic RAG).
【9】 ArXiv — Yunfan Gao 等人，“Retrieval-Augmented Generation for Large Language Models: A Survey,” arXiv:2312.10997, 2023. (RAG 的背景参考) RAG 范式概述（朴素、高级、模块化）、组件（检索、生成、增强技术）以及 RAG 系统的演进 ([2312.10997] Retrieval-Augmented Generation for Large Language Models: A Survey) ([2312.10997] Retrieval-Augmented Generation for Large Language Models: A Survey). 这提供了 Agentic RAG 作为 RAG 演进的下一步的背景。