虽然检索增强生成 (RAG) 在 2023 年占据主导地位，但 智能体工作流正在 2024 年推动巨大的进步。使用 AI 智能体为构建更强大、更健壮和更通用的基于大型语言模型 (LLM) 的应用程序开辟了新的可能性。其中一种可能性是在智能体 RAG 管道中通过 AI 智能体增强 RAG 管道。
本文将介绍 Agentic RAG 的概念、实现方式以及其优势和局限性。
Agentic RAG 的基本原理
Agentic RAG 描述了基于 AI 智能体的 RAG 实现。在进一步讨论之前，让我们快速回顾一下 RAG 和 AI 智能体的基本概念。
什么是检索增强生成 (RAG)
检索增强生成 (RAG) 是一种构建基于 LLM 的应用程序的技术。它利用外部知识源为 LLM 提供相关的上下文，并减少幻觉。
一个朴素的 RAG 管道由一个检索组件（通常由一个嵌入模型和一个向量数据库组成）和一个生成组件（一个 LLM）组成。在推理时，用户查询用于在索引文档上运行相似性搜索，以检索与查询最相似的文档，并为 LLM 提供额外的上下文。
典型的 RAG 应用程序有两个显著的局限性
- 朴素的 RAG 管道仅考虑一个外部知识源。然而，某些解决方案可能需要两个外部知识源，而某些解决方案可能需要外部工具和 API，例如网络搜索。
- 它们是一次性解决方案，这意味着上下文只检索一次。没有对检索上下文的质量进行推理或验证。
AI 系统中的智能体是什么
随着 LLM 的普及，新的 AI 智能体和多智能体系统范式应运而生。AI 智能体是具有角色和任务的 LLM，它们可以访问内存和外部工具。LLM 的推理能力帮助智能体规划所需的步骤并采取行动来完成当前的任务。
因此，AI 智能体的核心组件是
- LLM（具有角色和任务）
- 内存（短期和长期）
- 规划（例如，反思、自我批评、查询路由等）
- 工具（例如，计算器、网络搜索等）
一个流行的框架是 ReAct 框架。ReAct 智能体可以通过结合路由、查询规划和工具使用到一个实体中，在保持状态（在内存中）的同时处理顺序的多部分查询。
ReAct = 推理 + 行动（使用 LLM）
该过程包括以下步骤
思考：收到用户查询后，智能体推理下一步要采取的行动
行动：智能体决定一个行动并执行它（例如，使用工具）
观察：智能体观察行动的反馈
此过程迭代，直到智能体完成任务并响应用户。
Agentic RAG 是什么？
Agentic RAG 描述了基于 AI 智能体的 RAG 实现。具体来说，它将 AI 智能体整合到 RAG 管道中，以协调其组件并执行超出简单信息检索和生成的其他操作，以克服非智能体管道的局限性。
Agentic RAG 描述了基于 AI 智能体的 RAG 实现。
Agentic RAG 如何工作？
虽然智能体可以整合到 RAG 管道的不同阶段，但 Agentic RAG 最常指的是智能体在检索组件中的使用。
具体来说，检索组件通过使用具有不同检索工具的检索智能体来实现智能体化，例如
- 向量搜索引擎（也称为查询引擎），它在向量索引上执行向量搜索（如典型的 RAG 管道中）
- 网络搜索
- 计算器
- 以编程方式访问软件的任何 API，例如电子邮件或聊天程序
- 等等。
RAG 智能体然后可以推理并执行以下检索场景
- 决定是否检索信息
- 决定使用哪个工具检索相关信息
- 制定查询本身
- 评估检索到的上下文并决定是否需要重新检索。
Agentic RAG 架构
与顺序朴素 RAG 架构相比，Agentic RAG 架构的核心是智能体。Agentic RAG 架构可以具有各种复杂程度。在最简单的情况下，单智能体 RAG 架构是一个简单的路由器。但是，您也可以将多个智能体添加到多智能体 RAG 架构中。本节讨论这两种基本的 RAG 架构。
单智能体 RAG（路由器）
在最简单的情况下，Agentic RAG 是一个路由器。这意味着您至少有两个外部知识源，并且智能体决定从哪个知识源检索其他上下文。但是，外部知识源不必仅限于（向量）数据库。您可以从工具中检索更多信息。例如，您可以进行网络搜索，或者您可以使用 API 从 Slack 频道或您的电子邮件帐户中检索其他信息。
-ae2ec18616941504070d6b2a7210a358.png)
多智能体 RAG 系统
正如您所料，单智能体系统也有其局限性，因为它仅限于一个智能体，具有推理、检索和答案生成功能。因此，将多个智能体链接到多智能体 RAG 应用程序是有益的。
例如，您可以拥有一个主智能体，协调多个专用检索智能体之间的信息检索。例如，一个智能体可以从专有的内部数据源检索信息。另一个智能体可以专门从您的个人帐户（例如电子邮件或聊天）检索信息。另一个智能体也可以专门从网络搜索中检索公共信息。
超越检索智能体
上面的示例显示了不同检索智能体的用法。但是，您也可以将智能体用于检索以外的目的。智能体在 RAG 系统中的可能性是多方面的。
Agentic RAG 与（Vanilla）RAG
虽然 RAG 的基本概念（发送查询、检索信息和生成响应）保持不变，但 工具使用使其通用化，使其更加灵活和强大。
这样想：普通的（Vanilla）RAG 就像在图书馆（在智能手机出现之前）回答一个特定问题。另一方面，Agentic RAG 就像手里拿着一部智能手机，上面有网络浏览器、计算器、您的电子邮件等。
| Vanilla RAG | Agentic RAG | |
|---|---|---|
| 访问外部工具 | 否 | 是 |
| 查询预处理 | 否 | 是 |
| 多步检索 | 否 | 是 |
| 检索信息的验证 | 否 | 是 |
实现 Agentic RAG
如前所述，智能体由多个组件组成。要构建 Agentic RAG 管道，有两种选择：具有函数调用的语言模型或智能体框架。两种实现方式都能达到相同的结果，这取决于您想要的控制和灵活性。
具有函数调用的语言模型
语言模型是 Agentic RAG 系统的主要组件。另一个组件是工具，它使语言模型可以访问外部服务。具有函数调用的语言模型提供了一种通过允许模型与预定义的工具交互来构建智能体系统的途径。语言模型提供商已将此功能添加到他们的客户端中。
2023 年 6 月，OpenAI 发布了 gpt-3.5-turbo 和 gpt-4 的函数调用。它使这些模型能够可靠地将 GPT 的功能与外部工具和 API 连接起来。开发人员很快开始构建将 gpt-4 插入代码执行器、数据库、计算器等应用程序。
Cohere 进一步推出了他们的连接器 API，为 Command-R 模型套件添加工具。此外，Anthropic 和 Google 为 Claude 和 Gemini 启动了函数调用功能。通过使用外部服务为这些模型提供支持，它们可以访问和引用网络资源、执行代码等等。
函数调用不仅适用于专有模型。Ollama 引入了对流行的开源模型（如 Llama3.2、nemotron-mini 和 其他）的工具支持。
要构建一个工具，首先需要定义该函数。在这个片段中，我们正在编写一个使用 Weaviate 的 混合搜索 从数据库中检索对象的函数。
def get_search_results(query: str) -> str:
"""Sends a query to Weaviate's Hybrid Search. Parses the response into a {k}:{v} string."""
response = blogs.query.hybrid(query, limit=5)
stringified_response = ""
for idx, o in enumerate(response.objects):
stringified_response += f"Search Result: {idx+1}:\n"
for prop in o.properties:
stringified_response += f"{prop}:{o.properties[prop]}"
stringified_response += "\n"
return stringified_response
然后，我们将通过 tools_schema 将该函数传递给语言模型。该模式随后将在提示中用于语言模型。
tools_schema=[{
'type': 'function',
'function': {
'name': 'get_search_results',
'description': 'Get search results for a provided query.',
'parameters': {
'type': 'object',
'properties': {
'query': {
'type': 'string',
'description': 'The search query.',
},
},
'required': ['query'],
},
},
}]
由于您正在直接连接到语言模型 API，因此需要编写一个在语言模型和工具之间路由的循环。
def ollama_generation_with_tools(user_message: str,
tools_schema: List, tool_mapping: Dict,
model_name: str = "llama3.1") -> str:
messages=[{
"role": "user",
"content": user_message
}]
response = ollama.chat(
model=model_name,
messages=messages,
tools=tools_schema
)
if not response["message"].get("tool_calls"):
return response["message"]["content"]
else:
for tool in response["message"]["tool_calls"]:
function_to_call = tool_mapping[tool["function"]["name"]]
print(f"Calling function {function_to_call}...")
function_response = function_to_call(tool["function"]["arguments"]["query"])
messages.append({
"role": "tool",
"content": function_response,
})
final_response = ollama.chat(model=model_name, messages=messages)
return final_response["message"]["content"]
您的查询将如下所示
ollama_generation_with_tools("How is HNSW different from DiskANN?",
tools_schema=tools_schema, tool_mapping=tool_mapping)
您可以按照 此示例 重现上述内容。
代理框架
DSPy、LangChain、CrewAI、LlamaIndex 和 Letta 等代理框架应运而生，以促进使用语言模型构建应用程序。这些框架通过连接预构建的模板来简化构建代理式 RAG 系统的过程。
- DSPy 支持 ReAct 代理和 Avatar 优化。Avatar 优化描述了用于描述每个工具的自动化提示工程的使用。
- LangChain 提供了许多用于处理工具的服务。LangChain 的 LCEL 和 LangGraph 框架进一步提供了内置工具。
- LlamaIndex 进一步引入了 QueryEngineTool，这是一个用于检索工具的模板集合。
- CrewAI 是开发多代理系统领先的框架之一。用于工具使用的关键概念之一是在代理之间共享工具。
- Swarm 是 OpenAI 构建的一个用于多代理编排的框架。Swarm 同样侧重于工具在代理之间共享的方式。
- Letta 接口将反映和完善内部世界模型作为函数。这可能包括使用搜索结果来更新代理对聊天机器人用户的记忆，而不仅仅是响应问题。
企业为什么采用代理式 RAG
企业正在从原版 RAG 转向构建代理式 RAG 应用程序。Replit 发布了一个代理，可以帮助开发人员构建和调试软件。此外，Microsoft 宣布了 copilots，它们与用户一起工作，提供完成任务的建议。这些只是生产中代理的几个例子，可能性是无限的。
代理式 RAG 的优势
从原版 RAG 到代理式 RAG 的转变使这些系统能够产生更准确的响应、自主执行任务以及更好地与人类协作。
代理式 RAG 的优势主要在于检索到的附加信息的质量得到提高。通过添加具有工具访问权限的代理，检索代理可以将查询路由到专门的知识来源。此外，代理的推理能力能够对检索到的上下文进行验证，然后再用于进一步处理。因此，代理式 RAG 管道可以带来更强大和更准确的响应。
代理式 RAG 的局限性
然而，任何事情都有两面性。将 AI 代理用于子任务意味着将 LLM 纳入完成任务。这伴随着在任何应用程序中使用 LLM 的局限性，例如增加的延迟和不可靠性。根据 LLM 的推理能力，代理可能无法充分完成任务（甚至根本无法完成）。重要的是要纳入适当的故障模式，以帮助 AI 代理在无法完成任务时摆脱困境。
总结
本博客讨论了代理式 RAG 的概念，涉及将代理纳入 RAG 管道。虽然代理可以用于 RAG 管道中的许多不同目的，但代理式 RAG 最常涉及使用具有工具访问权限的检索代理来泛化检索。
本文讨论了使用单代理和多代理系统以及它们与原版 RAG 管道不同的代理式 RAG 架构。
随着 AI 代理系统的兴起和普及，许多不同的框架正在演变用于实现代理式 RAG，例如 LlamaIndex、LangGraph 或 CrewAI。
最后，本文讨论了代理式 RAG 管道的优势和局限性。
更多资源
准备开始构建了吗？
请查看 快速入门教程，或使用 Weaviate Cloud (WCD) 的免费试用版构建令人惊叹的应用程序。