APPLICATION

Agentic RAG快速指南

Agentic RAG系统为LLM配备了自主权：决定何时检索信息、检索什么内容、如何整合结果，甚至何时请求澄清的能力。

admin

Mar 4, 2025 • 35 min read

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

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

进入自主式RAG的世界——这是一种下一代范式，它将一个AI代理嵌入到RAG管道中，以克服这些挑战。自主式RAG系统为LLM配备了自主权：决定何时检索信息、检索什么内容、如何整合结果，甚至何时请求澄清的能力。通过引入基于代理系统的原理（如计划、工具使用和自我完善），自主式RAG使检索工作流程更加适应性和智能。在接下来的部分中，我们将探讨自主式RAG与标准RAG的不同之处，深入其架构，并逐步介绍实现细节。我们还将研究实际应用案例，讨论性能考虑因素，并概述挑战和未来趋势。本文假设您已经熟悉RAG的基本概念，并希望了解添加“代理”如何能加速您的检索增强生成系统。

1、自主式RAG与标准RAG的区别

自主式RAG在标准RAG的基础上引入了自主决策过程，增强了检索和生成过程。首先可视化标准RAG管道，然后将其与代理驱动方法进行对比。

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

在一个标准的RAG系统中（如上所示），过程是直接且反应式的：对于每个查询，检索一次并生成。相比之下，自主式RAG管道插入了一个智能代理，可以动态控制和协调这些步骤。代理（通常是具有特殊提示的LLM本身）可以决定是否、何时以及如何检索信息，可能执行多次检索-生成循环，或者使用除了向量存储之外的其他工具。

标准RAG与自主式RAG之间的一些关键区别包括：

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

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

总之，自主式RAG将RAG的事实基础与AI代理的自主性和推理能力结合起来。通过这样做，它解决了标准RAG的许多限制，使得系统更加灵活、准确，并能够应对复杂的信息需求。

2、架构深度剖析

现在让我们详细审视自主式RAG系统的架构。从高层次来看，自主式RAG架构在常规检索和生成组件之上引入了代理层。这个代理层可以实现为一个强大的单一代理，也可以实现为一组专门代理的协作（多代理系统）。我们将首先描述最简单的单一代理情况，然后考虑更复杂的设置。

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

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

单一代理系统中的流程通常如下（针对给定查询）：

代理决策——需要检索吗：代理检查查询（以及迄今为止的对话背景，如果是多轮对话），并决定是否需要外部信息。对于一个简单事实性问题，代理可能会继续搜索知识库。如果查询非常简单或常识性，代理甚至可以直接作答而不进行检索（尽管在实践中，许多系统总是尝试检索）。这个条件步骤已经不同于标准RAG，后者无论怎样都会每次都检索。
代理决策——选择工具/数据源：如果需要检索，代理会选择哪个工具或数据源。在路由场景中，可能有多个向量索引（例如，一个索引用于技术文档，另一个索引用于产品FAQ），代理会选择最有可能有答案的那个。或者它可能会在向量数据库和网络搜索API之间选择，以回答关于当前事件的查询。这本质上是查询路由，是自主系统的一个强大功能。
制定检索查询：代理随后制定要输入选定检索工具的查询。这可以简单地使用用户的原始问题，也可以是重新表述的版本。高级代理实现可能会采用诸如查询扩展或假设问答的技术来改善检索。（例如，使用HyDE方法，代理可以生成一个想象的答案，并将其用作语义搜索查询。
检索并观察：检索工具（例如向量搜索）返回一些候选文档或数据。代理“观察”这些结果。现在代理可以决定：这些信息是否回答了问题，还是需要进一步操作？如果结果无关或不足，代理可能会回到步骤2或3：也许尝试不同的数据源或重新表述查询并再次搜索。这个循环是自主式RAG具有适应性力量的原因之一——能够自我纠正和迭代，如果第一次尝试不够好。
生成答案：一旦代理收集到了足够的支持信息（或确定检索没有帮助），它就会使用LLM编写最终答案。检索到的上下文通常会包含在生成答案的提示中，类似于标准RAG。代理的链式思维也可能影响答案的组织方式（例如，代理可能会在答案中明确引用来源，如果被指示这样做的话）。

在代码或伪代码中，一个简化的代理循环可能看起来像这样：

PS：市场上大约有90个框架，这完全取决于您的用例和偏好。

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

这个循环将继续，直到代理决定准备好输出答案（或达到最大步骤限制以确保安全）。

现在，让我们可视化架构。下面是一张插图，展示了自主式RAG代理与多个工具在循环中的互动：

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

类似的CoAct架构示例可能如下图所示：

在上面的图表中，代理甚至可以按顺序执行多个动作（例如，先进行网络搜索，然后将那些结果输入到向量数据库查询）并重复必要次数。这展示了自主式RAG的非线性、自主工作流特性。

对于更复杂的部署，我们可以有多代理RAG系统。不是单一代理处理一切，而是分配多个代理担任专门角色。例如，你可能会有：

一个网络代理，只负责查询外部网络资源，
一个数据库代理，只查询内部数据库，
和一个协调代理，将问题委派给适当的专家，并汇总发现。

这样的多代理设置甚至可以让一个代理调用另一个代理作为“工具”来完成特定子任务。实际上，一个多代理RAG可能看起来像是这些代理协作的层次结构或网络。例如，IBM描述了一个Agentic RAG系统，其中一个代理查询外部数据库，而另一个代理则浏览电子邮件和内部数据，每个代理都使用自己的检索方法。协调者然后将他们的输出结合起来形成最终答案。这种设计可以提高鲁棒性（代理互相检查），并实现专业化，但也带来了更多的复杂性。

总结来说，自主式RAG架构通过代理（或代理）将经典检索生成管道升级，引入了推理、决策点和可能的多步骤循环。这种架构比标准RAG更复杂，但在处理需要灵活性的真实世界任务时显著更强大。接下来，我们将看到如何在实践中实现这样的架构，包括哪些工具和框架可以帮助实现。

3、实现细节

如何构建一个自主式RAG系统？在本节中，我们将概述一个分步实现，附带代码片段。我们假设您具备Python和常见AI框架的基础知识。我们将使用LangChain，虽然它不是唯一的选择，但它是一个开源框架，用于构建LLM应用程序，但您也可以使用其他库或从零开始实现类似的想法。

3.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

# 假设我们有一份文档列表（字符串）在docs_list  
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)  
docs = text_splitter.create_documents(docs_list)# 创建嵌入并索引到FAISS  
embedding_model = OpenAIEmbeddings()  # 使用OpenAI嵌入（需要API密钥）  
vector_store = FAISS.from_documents(docs, embedding_model)

在上述代码片段中，我们将文档分割成约500个字符的块，并为每个块创建嵌入，存储在FAISS索引中。vector_store现在可以通过查询新查询的嵌入来检索相关的段落。

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

3.2 定义代理使用的工具

接下来，我们需要定义代理可以使用的工具。最少我们需要一个检索工具，它封装了对向量存储的调用。我们还可以添加其他工具——为了举例说明，让我们包含一个网络搜索工具（这可以是一个简单的包装任何搜索API的函数，或者在这里模拟它，因为我们不能真正调用互联网）。

使用LangChain的工具界面：

from langchain.agents import Tool

# 定义一个查询向量存储的函数  
def vector_search(query: str) -> str:  
    """从向量数据库中检索相关文档并返回结果的拼接字符串。"""  
    docs = vector_store.similarity_search(query, k=3)  
    # 结合检索到的文档的内容（可能包括元数据或片段格式）  
    return "\n".join([doc.page_content for doc in docs])# 创建检索工具  
retrieval_tool = Tool(  
    name="VectorDB",  
    func=vector_search,  
    description="从知识库中检索相关文档。"  
)# （可选）定义第二个工具，例如网络搜索（这里我们模拟它）  
def web_search(query: str) -> str:  
    # 这是一个占位符，用于实际的网络搜索API调用。  
    # 实际上，可以使用SerpAPI或Bing API等API。  
    return fake_web_search_api(query)search_tool = Tool(  
    name="WebSearch",  
    func=web_search,  
    description="在网络上搜索最新的信息。"  
)

在这里，我们创建了两个工具：VectorDB和WebSearch。每个工具只是接受一个字符串输入并返回一个字符串输出（例如，检索到的文本）。代理将使用这些工具的名称来计划行动。

3.3 初始化代理

现在我们设置代理本身。我们选择一个LLM来驱动代理的推理——例如，OpenAI GPT-4模型或本地LLM。然后初始化一个具有上述工具访问权限的代理。LangChain提供了方便的代理初始化函数；这些用例中的一种常见配置是“ReAct”风格代理（它使用一种思考/行动/观察的提示格式）。

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

# 初始化代理使用的语言模型（在这种情况下使用聊天模型）  
llm = ChatOpenAI(model_name="gpt-4", temperature=0)  # 或选择其他LLM# 使用工具创建代理。我们使用了详细的设置来观察其思考过程。  
agent = initialize_agent(  
    tools=[retrieval_tool, search_tool],  
    llm=llm,  
    agent="zero-shot-react-description",  # 这告诉LangChain使用基于ReAct的代理  
    verbose=True  
)

在底层，这设置了提示策略，其中代理LLM被指示如何使用工具。zero-shot-react-description代理将使用工具的description字符串来决定何时以及如何调用它们。当我们运行代理时，它会输出其链式思维（因为我们设置了verbose=True），显示步骤，如：“思考：我应该搜索知识库。行动：VectorDB...”等等，遵循ReAct模式（Agentic RAG）。

3.4 提问

有了我们的代理，我们现在可以给它一个用户查询并得到答案：

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

当执行此代码时，代理将内部决定如何回答这个问题。很可能，它会首先使用VectorDB工具，用一个精心设计的查询，如“standard RAG和Agentic RAG之间的差异”。如果我们的知识库中有一篇类似这篇文章或相关文档的文章被索引，向量搜索可能会返回一段列举这些差异的文本。代理将读取结果（ReAct中的观察），然后继续。由于这个问题直接询问差异，一次检索可能就足够了，代理将生成一个列出差异的答案（可能引用它看到的上下文）。如果问题是更复杂的，代理可能会决定调用WebSearch以获取外部信息，或者再做一次VectorDB查询并用精炼后的查询再次搜索。

后台发生的事情是代理使用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..."]

最终答案将被返回。通过检查代理的思考（如果verbose=True），开发人员可以调试代理是否做出了正确的选择，或者它是否陷入了困境或产生了错误的行动。

3.5 替代实现方法

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

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

4、性能和可扩展性比较

考虑到自主式RAG的额外复杂性，一个自然的问题是：性能影响是什么，我们能得到可衡量的好处吗？答案取决于我们考虑的性能方面——答案质量、延迟/吞吐量和可扩展性各有不同影响。让我们逐项分析这些考虑因素以及已知的发现：

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

因此，自主式RAG倾向于提高答案质量和多功能性，但以更高的延迟和系统复杂性为代价。对于许多应用场景，这种权衡是值得的，特别是如果查询复杂到需要这种程度。一种明智的方法是在简单FAQ问题上部署标准RAG，但在更难的查询或当简单方法失败时切换到自主式管道。这样，你可以平衡吞吐量和准确性。随着领域的成熟，我们预计会更好地优化代理步骤（可能缓存结果，使用较小的模型进行推理等）来缩小性能差距。

5、自主式RAG的挑战与未来

尽管自主式RAG很强大，但它们并非没有挑战。在设计和部署此类系统时，重要的是要意识到这些限制。同时，自主式RAG的未来非常令人兴奋，积极的研究和快速发展正在解决许多这些问题。

主要挑战：

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

未来趋势和发展：

尽管存在挑战，自主式RAG是一个快速发展的领域，有许多有前景的方向：

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

因此，自主式RAG是检索增强生成理念的重大飞跃，使我们更接近于像人类研究员一样思考、检索和改进的AI系统。虽然使这些系统稳健和高效的挑战依然存在，但持续的研究和工程进展正在迅速解决这些问题。未来可能会出现更高效、安全且易于构建的自主式RAG系统，开启新一代智能应用的大门。

6、结束语

自主式RAG代表了从标准检索增强生成模型的重大进步，向管道注入了急需的适应性和智能。通过赋予LLM自主权——决定何时检索信息、调用工具和迭代——我们得到了能够处理更复杂查询、无缝集成多个数据源并不断自我改进结果的系统。

自主式RAG通过不仅从检索的信息中生成答案，而是智能地管理整个检索生成过程，推动了AI系统的极限。对于AI/ML工程师来说，掌握这一模式开启了构建以前遥不可及的助手和应用的可能性——那些能够真正研究、推理和回应的系统，具有相当大的自主性。我衷心鼓励您试验文中提出的想法和代码示例，查阅参考资料进行深入了解，并考虑自主式检索增强生成如何应用于您自己的领域或项目。

原文链接：Agentic RAG: How Autonomous AI Agents Are Transforming Information Retrieval

汇智网翻译整理，转载请标明出处