熬了几个夜，终于让Agentic RAG工作流正常运行了，特来分享一下

一直以来都在想用 LLM + Agent + RAG + FastAPI 搭建一套完整的智能检索增强生成工作流（Agentic RAG Workflow）。我选择了一个客服支持项目来学习，经过一段时间的学习（主要是踩坑），大致上是跑通了这个工作流。赶紧总结分享起来。

Agentic RAG（代理型 RAG） 只是与 AI 智能体架构一起使用的 RAG（检索增强生成）。

使用传统 RAG 和 Agentic RAG，我们都可以使用 RAG Pipeline 填充搜索索引。该过程如下所示：

在实践中，我们的应用程序需要做两件事才能被称为 AI 智能体。

1. 首先，它需要具有一定的自主决策能力，也就是说，它需要具有代理性。如果你编写了一个执行一系列步骤的程序，其中一步是调用 LLM——恭喜你！你已经构建了一个调用 LLM 的程序工作流——这没有什么错。只是不要称它为 AI 智能体。AI 智能体不会协调要采取的一系列确切步骤。相反，智能体使用 AI 模型来决定如何解决问题，而不是在代码中命令式地定义它。这就是赋予它代理性的原因。

2. AI 智能体还需要有某种与环境交互的方式。对于软件来说，这意味着进行 API 调用、检索数据、向 LLM 发送提示等。 LLM 提供商为我们提供实现此目的的机制称为工具。事实证明，大多数 LLM 仅支持一种类型的工具：函数。

AI 智能体的基本应用程序架构如下所示：

AI 智能体使用与下图类似的方式处理循环。循环首先接收用户查询并执行初始数据检索以获取有用的上下文。然后，它将此信息连同用户目标的描述一起传递给 LLM。它还包括 LLM 可以使用的适当工具列表。每个函数/工具都使用 JSON 模式定义，以描述支持的参数和允许的值。指示 LLM 仅使用函数调用进行响应，而不进行其他任何响应。当 LLM 生成响应时，它应该采用标准结构来定义接下来应执行的函数调用。AI 代理负责执行 LLM 在其响应中指定的函数。然后，它将函数结果连同对话历史记录一起传递给 LLM，以便进行下一次循环。

对于我的客服支持项目，我希望 LLM 能够利用工具执行以下操作：

1. 从产品文档中查找产品信息；

2. 从客户支持论坛中查找与类似问题相关的数据；

3. 从内部知识库中识别可能有帮助的相关信息；

4. 终止解决过程，因为已找到解决方案；

5. 将问题升级给人工处理，因为 AI 智能体已尽其所能但无法解决问题。

直奔主题，传统 RAG 系统与 Agentic RAG 系统的关键设计区别在于检索函数的概念。

在这两种系统中，我们仍然需要使用 RAG Pipeline 来填充向量数据库。

但在构建搜索索引时，我们需要提前考虑用于与搜索索引交互的函数。

这些函数的设计需要预见 AI 智能体可能采取的操作，以便帮助智能体解决我们希望解决的问题。

在我尝试的第一个 Agentic RAG 实现中，我创建了一个函数，它是我使用的向量数据库的直通函数。

我将所有三个非结构化数据源加载到单个向量索引中，并填充元数据，以便我从每个系统中的多个文档中检索块。例如，设置元数据过滤器 source=docs 允许我将搜索限制在内部文档的上下文中。

然而，我最初的这种方法效果非常不理想。通过直通方法，从 LLM 接收到的函数调用请求经常毫无逻辑。它可能会错误地设置元数据过滤器，试图在外部数据源中搜索文档，甚至会不合理地组合各种元数据字段，这导致了糟糕的搜索效果。

可以想象，当检索到的数据质量不佳时，生成的结果也不会好到哪里去。

我进行的第一个显著的优化是将支持复杂查询的直通函数拆分为更小的具体函数。这种方法抽象了底层数据源，使 LLM 更容易识别和调用合适的工具来完成下一步的任务。

例如，创建一个名为 search_docs 的函数，该函数接受查询字符串并预先填充必要的元数据，这比使用一个名为 vector_search 的函数让 LLM 自行推理 source=docs（即搜索内部文档的方式）要高效得多。

即使我使用了描述性JSON架构定义来描述 source 参数的允许值，情况依然如此。

总结下来就是

1. 直通函数不可靠：让 LLM 直接与底层数据库交互并处理复杂的元数据过滤逻辑，容易导致混乱的搜索行为和无意义的函数调用。

2. 小而具体的函数更高效：将支持复杂查询的函数拆分为小型专用函数（如 search_docs）后，LLM 可以更轻松地识别并调用适当的工具，从而提高了检索的准确性和生成的质量。

这种方法本质上是通过减少LLM的推理负担，引导其以更结构化的方式使用特定的功能，这不仅提高了检索效率，还显著改善了生成结果的质量。

LLM 在默认状态下的推理能力较差，但一些模型的表现比其他模型要好。我尝试过的最小的模型是 Llama 3.1 8B，它的表现最差。

JSON 模式

它经常忽略函数调用的指令，并且在生成过程中返回无效的 JSON，这导致智能体应用程序频繁需要处理 JSON 解析异常。

70B 版本的 Llama 表现稍好一些，但仍未达到理想状态。

在我最初启动这个项目时，OpenAI 最新的公开模型还是 gpt-4-turbo。即使在启用 JSON 模式的情况下，生成的响应每 4 到 5 次中仍会返回一次无效的 JSON。

提示工程

提示工程是任何 RAG 系统中的关键组成部分。Agentic RAG 也不例外。

虽然高效的数据管理策略有助于实现高性能的信息检索，但仅凭这些措施还不足以确保理想的结果。

作为基准测试，我希望通过向 LLM 提供广泛的指令来解决用户的查询，并将函数定义交给 LLM，观察这种方法能在多大程度上推动任务的完成。我开始的提示如下：

你是一家提供软件平台的公司的自动化 AI 技术支持助理。你的职责是帮助用户解决他们的技术问题和疑问。

用户的输入如下。你的目标是尽你所能协助用户实现他们的目标。

当然，调用聊天 API 时还包含了一组函数定义。

正如前面提到的，我在这个阶段将检索函数拆分为更受限的、细粒度的函数。

在初始提示（starting prompt）的基础上，Claude 和 gpt-4-turbo 在面对输入查询时，经常会生成不正确的响应。

为了解决这个问题，我更新了提示，明确告诉 LLM：除非它确信答案是正确的，否则不要生成响应。

你是一家提供软件平台的公司的自动化 AI 技术支持助理。你负责帮助用户解决技术问题。

你可以访问产品文档，其中包含有关公司产品和服务的详细信息。你可以访问包含操作方法文章的内部知识库。你还可以访问用户经常寻求帮助的社区论坛。你可以使用来自这些来源的信息来帮助用户解决他们的问题。

除非你确定自己对用户的问题有准确的答案，否则请使用 escalate_to_human 函数将问题上报给人工支持人员。如果你不确定，请不要编造答案。

用户的输入如下。你的目标是尽最大努力帮助用户实现他们的目标。

使用 Agentic RAG 系统的链式思维（Chain of Thought, CoT）

在这个问题中，要求 LLM 具备以下推理能力：

• 决定接下来要采取的步骤，以便更接近解决用户的问题。

• 判断何时已找到问题的解决方案。

• 判断何时应放弃并将问题交给人工处理。

我的第一个想法是参考 CoT 研究，看看是否可以将这些高级推理机制应用到这里。但是对于我的用例，使用 CoT 方法的效果并不明显。

CoT技术在论文中通常用于数学文字题的解答，这些问题的解决方式涉及可重复的逐步方法，并且存在明确的正确答案。然而，我的 AI 智能体的场景并不符合这一特征，因为智能体需要在不确定的环境中做出决策，而不仅仅是寻找单一的“正确答案”。

明确历史交互记录

尽管我在每次处理循环中都会传入聊天记录，但我发现 LLM 有时会忽视它已经得出的发现。例如，LLM会：

1. 使用 Agentic RAG 在文档中搜索，得到一个响应。

2. 然后在知识库中搜索相关信息。

3. 但接着又在文档中搜索相同或非常相似的查询。

为了解决这个问题，我增加了一条指令：

查阅历史交互记录以了解你所发现的其他内容。

这条指令的目的是让 LLM 在重复搜索之前，记住和利用之前的发现，从而减少不必要的冗余操作。

突破时刻：结构化响应

当我为这个用例实施 Agentic RAG 时，OpenAI 推出了他们的 gpt-4o 模型并引入了结构化响应。

此时，智能体在确保响应中的数据完整性和使用信息检索获取所需信息方面做得越来越好。我仍然经常遇到 LLM 产生无效 JSON 响应的情况，这会中断处理循环。

使用 strict=true 的结构化响应可以改善这个问题。OpenAI 在这一领域所做的任何科学研究似乎都得到了回报。

借助结构化输出，我构建 AI 智能体的 Agentic RAG 方法开始产生可靠且值得信赖的输出。

传统 RAG 的很多经验仍然适用于 Agentic RAG

与传统 RAG 一样，Agentic RAG 依靠上下文相关内容来帮助 LLM 生成更全面的响应。数据质量非常重要。

从非结构化数据源构建下游 rag 管道以支持全面的信息检索对于解决 agentic RAG 解决的问题是必不可少的。与传统 RAG 一样，agentic RAG 需要最新信息。

不要仅仅依赖 LLM 的推理能力

我们的 Agentic RAG 系统会犯错误。Agentic RAG 开发通常是一门艺术，而不是一门科学。我们需要考虑持续的质量保证机制和其他外部工具，以帮助我们监控智能体随时间的表现。

Agentic RAG 的难点仍然是 RAG Pipeline

我对我尝试过的每个 RAG 框架都有同样的感觉。他们倾向于关注问题中最容易解决的部分（数据检索和与 LLM 交互并不是一件难事）。

处理围绕非结构化数据源的数据工程的诸多细微差别和挑战，以提供针对信息检索进行优化的最新信息，是检索增强生成的繁琐部分。

让多个智能体协作

为单个智能体构建 Agentic RAG 系统涉及许多设计挑战和障碍。随着任务的复杂性增加，将职责重构为多智能体系统是很自然的。当多个智能体相互协作以创建智能系统时，我们必须要考虑一组新的架构问题。

仍然需要解决安全通信协议和处理敏感或机密数据等熟悉的要求。当我们在需要多个智能体的架构中实现 Agentic RAG 时，管理系统资源、访问控制和实施强大的数据保护措施也成为首要任务。

具有自主代理的 Agentic RAG

对于许多 Agentic RAG 用例，没有最终用户与智能体交互。相反，自主代理会自行识别和解决问题。

内容审核、版权侵权和质量保证系统等用例需要自主的 Agentic RAG 智能体。

这为处理循环增加了一个新的维度。这些 Agentic RAG 代理通常依赖于事件驱动的触发，不仅必须确定解决特定目标的最佳方法，还必须确定目标。

在这里，Agentic RAG 系统需要访问文本和视觉数据、庞大的知识图谱和自然语言理解。Agentic RAG 方法仍然依赖于信息检索、与大型语言模型的集成以及外部工具。但它也可以涉及更复杂的查询和处理逻辑，以帮助 Agentic RAG 智能体自主运行。