API-Bank: 一个工具-增强LLMs的综合基准

23年10月阿里、香港科技大学、北大和深圳智能思创的论文“API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs”。

大语言模型 (LLM) 可以通过利用外部工具来增强其功能。 然而，三个关键问题仍未得到解答：(1) 目前的LLMs在使用工具方面的效率如何？ （2）如何提高LLMs运用工具的能力？ (3) 使用工具需要克服哪些障碍？ 为了解决这些问题，引入 API-Bank，一个基准，专为工具增强的LLMs而设计。 对于第一个问题，开发一个由 73 个 API 工具组成的可运行评估系统。 用 753 个 API 调用对 314 个工具用对话进行标注，评估现有LLMs在规划、检索和调用 API 方面的能力。 对于第二个问题，构建一个全面的训练集，其中包含来自 1,000 个不同域2,138 个 API 的1,888 个工具使用对话。 用这个数据集，训练 Lynx，一个从 Alpaca 初始化的工具增强的 LLM。

实验结果表明，与 GPT-3 相比，GPT-3.5 表现出更高的工具利用率，而 GPT-4 在规划方面表现出色。 然而，仍然存在进一步改进的巨大潜力。 此外，Lynx 比 Alpaca 的工具利用性能超越26 分多，接近 GPT-3.5 的有效性。

由于工具增强型LLM缺乏权威的能力定义和基准，在初始阶段先做广泛的问卷调查。 通过对 500 多名表示有兴趣将其他工具纳入 LLM 的用户进行采访，收集他们的需求。 在此基础上，提出衡量工具增强LLMs能力的定义以及训练和评估的数据标准。

理想的工具增强 LLM 应该使用户能够在私有 API 池中定义他们所需的 API，并请求 LLM 在适当的时间调用这些 API 以满足他们的需求。 根据对用户的采访，确定包含工具增强LLMs要求的两个维度：池中少还是多的APIs、每轮单次还是多次的APIs调用。

如图所示，这两个维度产生了四种预期条件：API少、一次调用； API少，多次调用； 许多APIs，一次调用，以及许多APIs，多次调用。 在实现过程中，前两个条件的难度级别相似。 由于当所有API都输入时，规划多个API的调用很简单，因此合并了前两个条件。 那么有三个条件评估以下能力：

1. 调用：在已知 API 的情况下，能够根据给定的查询调用 API；
2. 检索+调用：在未知API的情况下，能够检索并调用单个API；
3. 规划+检索+调用：在API未知的情况下，能够持续规划、检索和调用多个API。

如下是各种能力的例子：

在对基准评估的能力进行分级之后，另一个关键方面是确保数据的质量。 调用 API 发生在开放环境中，无法预先确定域和功能。 此外，API调用就像数学一样严格，调用过程中的任何错误（例如不正确的API名称、输入参数错误或不正确的API调用顺序）都可能导致无法满足用户需求。 因此，对于基准建设，需要考虑以下标准：

1.域多样性：训练和测试数据应尽可能全面地覆盖广泛的领域；
2. API真实性：API的名称、定义、输入输出参数应与现实世界非常相似；
3. API 多样性：基准测试应包括各种 API 类型和用途。
4. 评估真实性：评估应包含一个能够与LLMs实时互动的功能系统。 LLM 提供 API 调用，系统执行该调用并将结果返回给 LLM。 评估基于执行对系统的影响，评估LLMs是否充分响应用户的要求。

系统中实现了 73 个 API，包括天气预报等常用的日常 API，以及访问文本-到-图像生成等其他 AI 模型。 所有API均由高级研发工程师在同一框架内实施，总时间投入为98人-天。 对于与数据库操作相关的API，建立必要的数据库并使用初始条目对其进行初始化，这是构建对话的关键步骤。 对于访问外部信息（例如搜索引擎）的 API，必须确保检索的信息保持不变，以确保可重复性。 在测试对话中跟踪每个 API 的所有查询，并记录特定时间点的检索结果，将它们硬编码在 API 中以保持结果一致性。

其中，开发了一个特殊的API，称为“API Search”，以满足Retrieval+Call和Plan+Retrieval+Call能力的评估要求。 具体来说，在这两种场景中，LLM 事先并不知道 API Pool 中可用的 API，因此需要利用 API Search 根据用户查询来识别可能需要的 API。 在提供给 LLM 的输入中，在开头提供 API 搜索的说明，并且在每次其他 API 调用之前都需要进行 API 搜索。 在执行 API 搜索时，模型应将用户的需求压缩为几个关键字。 API 搜索从查询关键字和 API 池中所有 API 的元信息中获取句子嵌入。 它计算关键字与所有API嵌入之间的余弦相似度，返回相似度最高的API的元信息。

根据设计原则定义的能力分级，标注Call、Retrieval+Call、Plan+Retrieval+Call API能力的评估数据。

对于Call的能力，首先从API池中随机抽取API。 然后，指示标注者首先根据 API 文档想象一个可以由这些 API 解析的查询。 然后，他们对 API 调用进行标注并让系统执行它。 最后，他们根据执行输出对响应打标签。 请注意，通话数据不一定代表单轮对话。 还要求标注者针对同一组 API 提出多个查询，同时提供对话历史记录和 API 调用历史记录。

对于Retrieval+Call能力，目标是获取复杂的用户需求并将其分解为多个简单的查询，每个查询都可以通过执行单个 API 来完成。 为了实现这一目标，首先从池中获取一组 API，范围从 1 到 5 个，并要求标注者确定他们是否可以共同解决复杂的需求。 如果是这样，他们会将其分为几个简单的查询。 对于每个查询，标注者都会给LLM 调用的 API 打标签并提供输入参数。 他们还给LLMs根据系统将一致性定义为是否执行相同的数据库查询或修改以及返回的结果是否相同。 关于 API 调用后响应的评估，用 ROUGE-L 指标。

API-Bank不仅评估现有LLMs使用工具的有效性，而且还提高他们使用这些工具的表现。

实现这一目标的最直接方法是创建适合工具-增强LLMs的高质量训练数据集。 然而，以低成本构建大规模训练数据集，同时满足域多样性和 API 真实性的设计原则，是具有挑战性的。 评估集中每个对话的手动注释成本达到 8 美元，这使得创建大型数据集的成本很高。 此外，设计一个多样化且真实的 API 池，对于标注者来说是一个挑战。 招募的标注者只能提供 100 个 API，这无法满足对多样化训练集的需求。 因此，提出一种多智体数据生成方法，可以快速且经济有效地构建符合设计原则的工具-增强 LLM 训练数据。

LLMs的出现带来了数据注释的范式转变，为自动生成标注数据提供了人类标注者的替代方案。 一种代表性的方法是自学（Wang et al., 2022）。 然而，虽然自学在为写作等简单任务生成数据方面是有效的，但在生成符合设计原则的工具增强 LLM 数据时遇到了困难。 具体来说，制定一个复杂的指令，包括域多样性、API多样性和真实性的要求，以及规划、检索和调用API的三个具体能力。 然而，广泛使用的 ChatGPT 很难生成完全符合指令的数据，只有 5% 的数据可用。 即使升级到更强大的 GPT-4，可用率也提高到 25%，但仍然存在大量错误。 这些错误源于同时向LLM提供了大量的要求，导致很难有效地理解它们。 因此，出现了一种直观的方法：能否将需求分解为多个更简单的任务来缓解这个问题，从而允许LLMs一次执行一项任务？

首先根据设计原则应纳入数据的元素包括：域、API、查询、能力以及 API 调用和响应。 域决定了 API 的功能，而 API 和能力则决定了它们可以处理的查询类型。 域、API、查询和能力的组合决定了 LLM 如何进行 API 调用并生成适当的响应。

为了模拟这些元素之间的依赖关系，用五个智体，如图 所示：（1）第一个智体生成多个域，例如医疗保健和健身。 (2) 第二个智体考虑域，生成潜在的 API。 值得注意的是，在此阶段，为了确保模拟 API 的真实性，将公共 API中的示例添加到智体输入中。 (3)第三个智体从模拟的API中随机选择一个或多个API。 此外，它还选择了设计原则中概述的功能。 然后，该信息用于创建与所选功能匹配的查询，并且可以通过调用所选 API 来实现。 (4) 第四个智体将域、API、能力和查询作为输入。 它预计将进行必要的 API 调用、模拟 API 的执行并生成解决查询的响应。 (5)最后，第五个智体，充当测试人员。 该智体会自动验证生成的数据是否符合设计原则（它实际上丢弃了 35% 的实例）。 所有五个智体都是向 ChatGPT 提供特定提示来实现的。 他们共同协作，逐步完成复杂的数据生成。 多智体消除了对人工标注的需求，每个对话仅花费 0.1 美元，与手工标注相比，节省开销 98%。