到目前为止，我们已经讨论了 Agent 系统架构，如何将系统组织成子Agent以及如何构建统一机制来标准化通信。

今天，我们将把注意力转向工具层以及代理系统设计中你需要考虑的最重要的方面之一：数据检索。

数据检索与Agent RAG

有可能创建不需要数据检索的Agent系统。这是因为有些任务仅使用你的语言模型所训练的知识就可以完成。

例如，你很可能能够创建一个有效的Agent来撰写关于历史事件（如罗马帝国或美国南北战争）的书籍。

对于大多数Agent系统来说，提供数据访问是系统设计的一个关键方面。因此，我们需要考虑围绕这一功能领域的几个设计原则。

检索增强生成（RAG）已成为将大型语言模型（LLM）连接到其生成响应所需数据的 facto 标准技术。顾名思义，实施RAG的一般模式包括三个步骤：

检索 ——从外部知识库中检索额外的上下文。在这个上下文中，我使用“知识库”是一个广义的术语，它可以包括API调用、SQL查询、向量搜索查询，或任何用于查找相关上下文以提供给LLM的机制。

增强 ——用户的输入会用检索步骤中获得的相关上下文进行增强。

生成 ——LLM利用其预训练的知识以及这种增强的上下文来生成更准确的响应，即使是关于它从未训练过的话题和内容。

因此，在一个问答系统中使用RAG大致如下所示：

Agent 系统几乎总是需要某种RAG（检索增强生成）的实现来履行其职责。然而，在设计Agent系统时，重要的是要考虑不同类型的数据如何影响整个系统的要求。

结构化数据和API

那些已经开发出成熟的API项目的公司，会比那些没有的公司更容易找到通往价值的路径。这是因为驱动代理系统所需的大部分数据，与今天驱动非Agent系统所用的数据是相同的。

一家已经构建了用于生成保险报价的API的保险公司，比那些仍处于客户端/服务器时代的公司更容易将该API接入Agent系统。

事实上，Agent系统有望颠覆保险业务的几乎所有方面。从报价到承保，从精算科学（保险业务中的赔率制定者）到理赔管理，Agent人工智能很可能在未来2-3年内完全接管这些角色。但这只有在Agent系统能够访问正确的数据和能力时才会发生。

以人工智能为先的API管理 

许多公司将API管理等同于拥有一个API网关。然而，在Agent系统的领域中，OpenAPI（Swagger）成为Agent系统消费现有API的关键推动因素。这是因为OpenAPI中使用的JSON模式可以轻松转换为许多大型语言模型（LLM）提供商所使用的函数定义结构。

此外，允许Agent系统查找和发现API的服务发现机制，为Agent系统自行创造新兴能力提供了有趣的机会。根据你的观点，这要么是一个令人兴奋的前景，要么是一个令人恐惧的前景。

在适当的安全措施到位的情况下，甚至可以将API目录搜索作为一个可用功能暴露给大型语言模型（LLM），以便它查找可用于解决当前任务的额外能力。

非结构化数据和RAG

虽然大多数公司都有成熟的实践来管理运营、分析和其他类型的结构化数据，但非结构化数据管理通常远远落后。

文档、电子邮件、PDF、图像、客户服务记录以及其他自由格式的文本来源对于Agent系统来说可能极具价值——但前提是，你能够在正确的时间，以正确的格式检索到正确的信息。这就是检索增强生成（RAG）特别强大的地方。

为什么非结构化数据具有挑战性

非结构化数据的范围往往更大，格式也更加多样化（PDF、图像、纯文本、HTML等）。这种多样性可能会使简单的数据检索方法不堪重负。

与存储在关系表中的结构化数据不同，非结构化数据没有强制的模式。你不能简单地在PDF上运行SQL查询，或者在电子表格中进行直接的“查找”。

这促使了新技术的迅速采用，以解决这些挑战。

向量数据库和语义搜索

现代的向量数据库和语义搜索技术为大规模检索非结构化数据铺平了道路。这些系统将文本转换为高维向量嵌入，从而允许基于相似性的查找。用户或代理的查询也会被转换为向量，然后检索数据库中最接近的向量（即，上下文最相似的文本片段）。

大型文档会被分割成更小的“片段”，每个片段分别进行索引。这使得检索器能够只检索相关的片段，而不是将整个文档塞入提示中。

许多向量数据库允许你为每个片段附加元数据（例如，作者、日期、文档类型）。这些元数据可以指导下游逻辑——例如，只检索最新的产品手册或与用户问题相关的知识库文章。

在高流量场景或数据质量至关重要的情况下（例如，法律或医疗用例），你可以在语义搜索之后应用额外的过滤器和排名标准，以确保只返回最高质量或经领域批准的内容。

用于非结构化数据处理的RAG管道

RAG管道充当非结构化数据源与向量数据库之间的连接组织。它们通常包括提取、分块和嵌入等几个步骤，将杂乱无章或自由格式的文档转换为优化的搜索索引，以便为你的大型语言模型（LLM）提供相关上下文。

在下面的图像中，你可以看到数据如何从各种非结构化数据源流动。这些可能包括知识库、文件系统中的文档、网页、SaaS平台中的内容等许多其他来源。

在RAG管道内部，非结构化数据会经历一系列转换。这些包括提取、分块、元数据处理和嵌入（向量）生成，然后写入向量索引。这些管道提供了关键功能，即在你的LLM需要回答问题或完成任务时，提供最相关的信息片段。

因为非结构化数据通常分散在不同的数据孤岛中，保持其同步和更新可能是一个挑战。在大型企业中，一些非结构化数据源在不断变化，这意味着RAG管道必须以最小的延迟捕获和处理这些变化。

过时的嵌入或陈旧的文本片段可能导致你的AI系统给出不准确或误导性的答案，尤其是当用户寻求有关产品更新、政策变化或市场趋势的最新数据时。确保你的管道能够处理近乎实时的更新——无论是通过事件驱动的触发器、定期爬虫还是流数据馈送——可以显著提升系统输出的质量和可信度。

优化RAG性能

熟悉构建数据管道的数据工程实践的开发人员，通常对向量数据的非确定性本质毫无准备。

在传统的数据管道中，我们对源系统和目标系统中数据应有的形式有很好的了解。例如，PostgreSQL中的一组关系表可能需要转换为BigQuery中的单一扁平结构。我们可以编写测试来告诉我们，源系统中的数据是否正确转换为我们想要的目标系统中的表示形式。

当处理非结构化数据和向量索引时，无论是源还是目标都不太明确。网页和文档包含

接下来是什么？

在本系列的第五部分也是最后一部分中，我们将探讨横向关注点。我们将深入研究安全、可观测性、工具隔离等一些Agent系统设计者需要考虑的重要领域。