代理 RAG：自主 AI 代理如何改变信息检索_rag 数据库代理-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_20182781/article/details/146395601

介绍

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

然而，传统的 RAG 有其局限性。它通常遵循静态的线性工作流程：一个检索步骤之后是单个生成步骤。如果最初的检索没有找到有用的信息，那么最终的答案很可能是不理想的。此外，vanilla RAG 逐字使用用户的查询进行相似性搜索，如果查询的措辞与相关文档不同，则这可能是次优的。传统的 RAG 系统也没有内置的机制来推理、计划或调整它们的策略。因此，它们在复杂或多步骤的查询中挣扎，这些查询可能需要搜索多个来源，使用不同的的工具，或者迭代改进。在实践中，这意味着标准的 RAG 系统可能会在涉及模棱两可的问题、多方面的问题或在动态数据源的任务上出错。

进入代理 RAG 的世界-下一代范式，将 href="https://medium.com/ai-in-plain-english/agents-react-vs-coact-d44ada0dd103">AI 代理嵌入RAG 管道以克服这些挑战。一个代理 RAG 系统为LLM提供了代理能力：自主决定行动的能力，比如何时检索信息，检索什么，如何整合结果，甚至何时要求澄清。通过结合基于代理的系统的原则（例如计划、工具使用和自我改进），代理 RAG 支持更具适应性和智能的检索工作流。下面，这里将探讨代理 RAG 与标准 RAG 的不同之处，深入研究其体系结构，并详细介绍实现细节。这里还将研究现实世界的用例，讨论性能考虑因素，并概述挑战和未来趋势。这里假设你熟悉 RAG 基础知识，并且希望了解如何添加“代理”来增强检索增强生成系统。

代理RAG与标准RAG有何不同

代理 RAG 建立在标准 RAG 的基础上，在检索和生成过程中引入自主决策。首先将标准 RAG 管道可视化，然后将其与代理驱动的方法进行对比，这是很有帮助的。

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

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

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

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

从本质上讲，代理 RAG 将 RAG 的事实基础与 AI 代理的自主性和推理能力结合在一起。通过这样做，它解决了普通 RAG 的许多限制，使系统更加灵活、准确，并且能够处理复杂的信息需求。
架构深度挖掘
现在详细研究一下代理 RAG 系统的体系结构。在高层次上，代理 RAG体系结构在通常的检索和生成组件之上引入了代理层。这个代理层可以实现为单个功能强大的代理，也可以实现为一系列协同工作的专门代理的集合（一个多代理系统）。这里将首先描述单个代理的最简单情况，然后考虑更复杂的设置。
在单代理 RAG 体系结构中，代理充当查询工作流的某种智能“路由器”或控制器。所涉及的组件有：

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

单智能体系统中的流程通常是这样的（对于给定的查询）：

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

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

while True:
    action = agent.plan（next_step, context_so_far）
 if action.type == "SEARCH":
        tool = action.tool_selection# e.g.；“VectorDB”或“WebSearch”查询= action。Formulated_query
 results = tool.run(query) 
        agent.observe(results)
 elif action.type == "ANSWER":
        final_answer = agent.generate_answer(context_so_far)
 break

这个循环会一直持续，直到代理决定它已经准备好输出一个答案（或者为了安全达到最大步长限制）。

现在，让这里将架构可视化。下图是一个代理 RAG 代理在一个循环中与多个工具交互的示意图：

图：具有自治代理的代理 RAG 体系结构。代理（一个具有推理策略的 LLM）接收用户的输入并给出指令，该指令在非线性工作流中采取多个动作。在这个示例中，代理可以使用诸如 RAG（向量数据库查找）、web 搜索或其他 api 之类的工具。在生成答案之前，它可能会执行几个工具调用（甚至组合结果）。如果需要，代理还可以决定向用户提出后续问题（使交互成为会话）。这个灵活的循环会一直持续下去，直到代理确信它可以回答这个问题。将此与前面的单通道图进行对比—这里代理有效地将反馈循环和决策分支插入到 RAG 管道中。

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

在上图中，代理甚至可以按顺序执行多个操作（例如，执行 web 搜索，然后将这些结果提供给向量 DB 查询），并在必要时重复。这证明了代理 RAG 的非线性、自主工作流程的特点。

对于更复杂的部署，这里可以使用多代理 RAG 系统。与单个代理处理所有事情不同，多个代理被分配了专门的角色。例如，你可能有：

一个只处理查询外部 Web 源的 WebAgent，
只查询内部数据库的 DB 代理；
以及一个协调代理，它将问题委托给适当的专家，然后汇总结果。

这样的多代理设置甚至可以让代理相互查询：一个代理可能会调用另一个代理作为“工具”来完成特定的子任务。在实践中，多代理 RAG 可能看起来像这些代理协作的层次结构或网络。总而言之，这里可以说代理 RAG 体系结构用一个（或多个）代理增强了经典的检索和生成管道，该代理引入了推理、决策点和可能的多步骤循环。这种体系结构本质上比普通的RAG 更复杂，但在处理需要灵活性的实际任务时却更加强大。接下来，这里将看到如何在实践中实现这样的体系结构，包括哪些工具和框架可以提供帮助。

实现细节

如何建立一个代理 RAG 系统？在这时，这里将概述一个逐步实现的过程，并附上代码片段。这里将假设你具有 Python 和常见 AI 框架的工作知识。这里将使用 LangChain，尽管它不是唯一的，也是最好的，市场上有很多，这里将在以后的博客中使用它们，但让这里从这个例子（一个用于构建 LLM 应用程序的开源框架）开始，以说明如何使用检索工具构建代理，同样，你可以使用其他库实现类似的想法，或者从头开始。

建立检索知识库
首先，你需要一个知识库来检索——通常是文档的向量存储。这部分本质上与标准 RAG 设置相同。你将准备一个文本数据的语料库（文档、wiki 文章、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 相关段落。)

为 Agent 定义工具
接下来，这里定义代理可以使用的工具。至少，这里将有一个检索工具来包装对向量存储库的调用。这里还可以添加其他工具——为了说明，让这里包括一个网络搜索工具（它可以是任何 searchAPI 或虚拟函数的简单包装，因为这里不能在这里实际调用互联网）。
使用 LangChain 的工具：
from langchain.agent 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
现在这里设置代理本身。这里选择一个LLM 来为代理的推理提供动力——例如， OpenAI GPT-4 模型或本地 LLM。然后，这里初始化一个可以访问上面定义的工具的代理。LangChain 提供方便的代理初始化函数；这些用例的一个常见配置是 “ReAct”风格的代理（它使用思考/行动/观察的推理提示格式）。
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
)
在底层，这设置了一个提示策略，在这个策略中，代理 LLM 被指示如何使用工具。zero-shot- reaction -description 代理将使用工具描述字符串来决定何时以及如何调用它们。当这里运行代理时，它将输出它的思维链（因为这里设置了
verbose=True），显示如下步骤：“思考：我应该搜索知识库。行动：VectorDB…
等等，遵循 ReAct 模式（代理 RAG）。
提问（Agent in Action）
这里的代理准备好了，这里现在可以向它提供一个用户查询并得到一个答案：
query = "What are the main differences between standard RAG and Agentic RAG?"
response = agent.run(query)
print("Agent's answer:", response)
VectorDB
执行此操作时，代理将在内部决定如何回答问题。很可能，它将首先使用
工具，并使用类似“标准 RAG 和代理RAG 之间的差异”这样的公式查询。如果这里的知识库有一篇文章（比如这个博客或相关文档）被索引，向量搜索可能会返回一个列举这些差异的段落。代理将读取结果（ReAct 中的 Observation），然后继续。由于这个查询是直接请求差异，单个检索可能就足够了，然后代理将生成一个列出差异的答案（可能引用它看到的上下文）。如果问题更复杂，代理也
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），开发人员可以调试代理是否做出了正确的选择，或者它是否陷入了困境或产生了幻觉。

可选的实现方法
当这里演示使用 LangChain 时，你可以使用其他框架（如 Autogen，CrewAI， BAML, PydanticAI, Agno， Huggingface 等）实现代理RAG 逻辑。
无论你选择哪种实现路径，核心思想都是：定义你的知识来源，将其包装为工具或功能，并提示 LLM 在循环中使用这些工具并最终回答问题。复杂度可以是简单的路由器（提示符中的 if-else 逻辑），也可以是自行决定一切的自由形式代理。一个简单的方法通常是一个很好的起点——例如，只要允许在需要时进行一次额外的检索（两步 RAG），就可以在许多情况下提高准确性。
比较性能和可伸缩性
随着代理 RAG 的复杂性增加，一个自然的问题是：性能影响是什么？这里是否获得了可衡量的收益？答案取决于这里考虑性能的哪个方面——应答质量、延迟
/吞吐量和可扩展性每个方面受到不同的影响。让这里将这些考虑因素与任何已知的发现一起分解：

回答质量和成功率：代理 RAG 的主要动机是提高复杂查询的成功率。通过允许多次检索尝试和更智能的查询公式，代理 RAG 可以检索一次性 RAG 可能错过的相关信息。根据经验，这通常转化为更高的答案准确性，减少“我不知道”或幻觉答案。例如，拥抱脸的团队注意到，代理方法恢复了高级 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 或检索召回等指标，以及测量平均延迟。到目前为止，还没有专门针对“代理与非代理 RAG”性能的标准化基准，但研究人员正在调整 QA 基准来测试多步骤检索。早期迹象（来自社区实验）表明，使用代理方法，查询失败的次数更少，对边缘情况的处理也更稳健。如果你的用例涉及到关键的准确性（例如，减少幻觉），那么代理 RAG 的性能成本可能是值得的。如果你需要对简单查询的快速响应，那么一个更简单的 RAG 可能就足够了。
系统复杂性和维护：“性能”的另一个方面是系统维护和扩展的难易程度。代理 RAG 有更多的活动部件，这意味着出现 bug 或不可预见的交互的机会更多。例如，如果没有适当的约束，代理可能会陷入工具调用的循环中。监控和调试这些系统是非常重要的——开发人员经常需要跟踪代理的推理步骤。像 Arize 的 Phoenix 或 LangSmith 这样的工具可以追踪代理的决定来帮助调试。在工程工作方面，考虑到你可能会花更多的时间来调整提示，平衡代理何时应该停止，以及更新知识来源。因此，虽然不是一个“性能指标”本身，但这种复杂性是一个需要考虑的成本。DigitalOcean 的对比分析强调了集成开销——将检索模块与代理逻辑相结合可能比单通道管道更复杂。
因此，代理 RAG 倾向于以更高的延迟和系统复杂性为代价来提高回答质量和多功能性。对于许多应用程序来说，这种权衡是值得的，特别是当查询足够复杂而需要它的时候。一个明智的方法是有选择地使用代理 RAG：例如，为简单的 FAQ问题部署一个标准的 RAG，但对于更难的查询切换到代理管道，或者当简单的方法失败时作为回退。这样，你就可以平衡吞吐量和准确性。随着该领域的成熟，这里期望更好地优化代理步骤（可能缓存结果，使用更小的模型进行推理等）来缩小性能差距。
代理RAG的挑战和未来
虽然代理RAG很强大，但它们并非没有挑战。在设计和部署这类系统时，必须意识到这些限制。与此同时，代理 RAG 的未来是非常令人兴奋的，积极的研究和快速发展解决了许多这些问题。
主要挑战:
复杂性和可调试性：如前所述，代理 RAG 系统比标准管道更复杂。管理多个代理或工具及其交互可能很困难。可能会出现错误或失败模式，例如代理进入无限循环的检索或选择次优工具。跟踪推理（“为什么代理要做 X?”）需要很好地记录思维链。开发人员需要健壮的监控。例如，Arize 建议跟踪代理的决策和结果，以确保系统正常运行，并查明哪里出了问题。如果提示没有精心设计，也可能发生工具误用或误解指令。
延迟和成本：如前所述，迭代性质增加了推理成本。这可能是实时应用程序或预算有限的应用程序的障碍。人们必须仔细决定超时或步长限制，这样代理就不会继续尝试事情太长时间。缓存中间结果并重用它们会有所帮助（事实上，一些代理框架实现了语义记忆或缓存先前查询的形式，以避免重复工作）。
数据质量和知识边界：RAG 和代理 RAG 在很大程度上依赖于底层数据的质量。如果知识库不完整或包含错误/偏差，代理可能会检索误导性信息，然后自信地使用它，这可能会使错误复杂化。代理还会带来“脱稿”的风险——例如，以意想不到的方式使用工具，或者引入可能不相关甚至不安全的外部信息。确保代理不违反数据访问策略是很重要的（例如，如果某些工具应该只用于某些查询）。
安全和道德问题：有了更大的自主权，如果没有正确地沙盒化，代理可能会执行不受欢迎的操作。例如，如果给定一个可以执行代码或发送请求的工具，它应该有约束以防止滥用。关于使代理更值得信赖的研究正在进行中——例如，结合 LLM 输出的可信度估计来决定是否信任一段检索到的信息或对其进行双重检查。一个代理批评另一个代理的多代理设置也可以帮助发现错误，但这并不是万无一失的。还有道德方面的考虑：自动搜索网络的代理可能会偶然发现有版权的文本并将其包含在答案中，或者可能需要过滤以避免从开放资源中检索到不适当的内容。
评价：你如何评价代理RAG 系统？传统的指标（如回答准确性）适用，但评估代理的决策过程更加棘手。智能体是否使用了最优的步数？它是否每次都选择了正确的工具？正在进行的研究是为智能体定义评估指标（有些研究像 “工具使用效率”这样的东西，或者让人类评估智能体的推理是否合理）。确保再现性也是一个挑战——由于LLM的随机特性，代理可能在同一查询的不同运行中采取不同的操作。设置随机种子或使用确定性模式可以在受控设置中有所帮助，但生产系统可能仍然会看到可变性。
未来趋势和发展：
尽管面临挑战，代理 RAG 是一个快速发展的领域，具有良好的发展方向：
更好的 Agent 框架：这里期望看到更成熟的框架，使构建和约束 Agent 变得更容易。例如，微软的 Autogen 库允许以更结构化的方式定义多代理对话和工具使用（并且正在积极改进中）。未来的框架可能包括内置的安全检查、循环检测和对常见模式的优化（比如检索然后询问后续）。随着这些工具的改进，实现代理解决方案的障碍将会降低。
规划算法的集成：有研究将经典规划或强化学习与基于 llm 的代理相结合。代理 RAG 可以从非 LLM 规划算法中受益，以更系统地决定检索顺序（而不是完全依赖 LLM 的学习推理，这可能是不稳定的）。这可以使代理行为更具可预测性和最优性。
从反馈中学习：目前，大多数代理都是用提示手工制作的。未来，这里可能会看到基于学习的智能体，其中智能体策略是根据反馈或演示进行微调的。想象一下，在多步搜索的例子上对 LLM 进行微调，这样它就可以学习何时进行一次检索，何时进行两次检索等等。这与应用于工具使用的人类反馈强化学习（RLHF）等技术重叠。一个相关的想法是让代理学习自我改进-例如，记忆哪些策略适用于哪些查询，随着时间的推移实现元学习。
多模式和多步骤推理：随着LLM获得多模式能力（参见GPT-4 等），代理 RAG 可能会扩展到这些模式。这里可能会看到一个代理，它可以检索图像或图表作为上下文，并将其合并到答案中，或者动态生成可视化。此外，检索和操作之间的界限可能会变得模糊——例如，代理可能不仅“检索”静态信息，还会触发计算（比如检索运行模拟的结果）。未来的代理可能是一个通用的解决问题的助手，RAG 只是众多工具中的一个。
与知识图和符号 AI 的融合：还有一种趋势是将 LLM 代理与知识图或数据库相结合，以获得更多基于知识的推理。代理 RAG 可以使用知识图来验证答案的一致性（本质上是以结构化的方式检查其工作）。神经符号 AI 的努力指向可以在推理循环中将非结构化信息转换为结构化形式的代理，以提高准确性。
标准化和最佳实践：随着更多案例研究的出现（在医疗保健、金融等领域），这里可能会看到代理 RAG 的最佳实践文档。例如，关于如何选择代理数量的指导方针，如何有效地进行查询路由，如何在代理的上下文中处理用户后续问题等。社区已经在分享模式了；例如，Qdrant 文章中描述的“路由器”代理与完全“自主”代理的概念可以帮助设计师根据他们的需求选择合适的复杂程度。

因此，代理 RAG 是检索增强生成思想的强大进化，使这里更接近能够像人类研究人员一样思考、检索和改进的 AI 系统。虽然在使这些系统强大和高效方面存在挑战，但正在进行的研究和工程进展正在迅速解决这些问题。未来的代理 RAG系统可能会更高效、更安全、更容易构建，从而实现一类新的智能应用程序。

结论

代理 rag 代表了标准检索增强生成模型的重大飞跃，为管道注入了急需的适应性和智能。通过赋予LLM计划、调用工具和迭代的能力，这里得到的系统可以处理更复杂的查询，无缝集成多个数据源，并不断自我改进其结果。

agent RAGs 突破了 AI 系统的极限，不仅可以从检索到的信息中生成答案，还可以智能地管理整个检索生成过程。对于 AI/机器学习工程师来说，掌握这种模式为构建以前无法企及的助手和应用程序提供了可能性——这些助手和应用程序可以真正自主地进行研究、推理和响应。我衷心地鼓励你对所呈现的想法和代码示例进行实验，查阅参考资料以进行更深入的研究，并考虑如何将代理检索增强生成应用到你自己的领域或项目中。