ToolLLM：使得大语言模型掌握调用真实的APIs

23年6月 来自除美国耶鲁大学以外的国内多家大学和公司，即 清华、人大、腾讯、知乎等 的论文“ToolLLM: Facilitating Large Language Models To Master 16000+ Real-world APIs“。

尽管开源大型语言模型（LLM）及其变型（例如LLaMA和Vicuna）取得了进步，但在执行更高级别的任务方面仍然受到很大限制，例如遵循人类指令使用外部工具（API）。这是因为当前的指令调优主要集中在基本的语言任务上，而不是工具使用领域。这与最先进的（SOTA）LLM形成鲜明对比，例如ChatGPT，后者已经展示了出色的工具使用能力，但不幸的是仍然闭源。为了促进开源LLM中的工具使用功能，该文引入了 ToolLLM ，这是一个数据构建、模型训练和评估的通用工具使用框架。首先介绍 ToolBench ，这是一个用于工具的指令微调数据集，用 ChatGPT 自动创建。具体来说，从 RapidAPI Hub 收集有49 个类别 16464 个真实世界的 RESTful API，然后通过提示 让ChatGPT 生成涉及这些 API 的各种人类指令，涵盖单个工具和多个工具场景。最后，用 ChatGPT 为每个指令去搜索有效的解决方案路径（API 调用链）。为了使搜索过程更有效率，作者开发了一种基于深度优先搜索的决策树（DFS-DT），使LLM能够评估多个推理轨迹并扩展搜索空间，结果表明DFSDT显着增强了LLM的规划和推理能力。为了有效地评估工具使用情况，还开发了一个自动评估器： ToolEval 。在ToolBench上微调LLaMA并获得ToolLLaMA。ToolEval显示，ToolLLaMA表现出执行复杂指令和推广到未见API的非凡能力，并表现出与ChatGPT相当的性能。为了使流水线更实用，还设计了一个神经 API 检索器，为每个指令推荐合适的 API，无需手动选择 API。

如图所示，一个高质量的指令调优数据集 ToolBench。用最新的ChatGPT（gpt-3.5-turbo-16k）自动构建，该ChatGPT已通过增强的函数call功能进行了升级。给定一条指令，API 检索器推荐一组相关 API，这些 API 被发送到 ToolLLaMA 进行多轮决策，得出最终答案。尽管筛选了大量 API，但检索器表现出非凡的检索精度，返回的 API 与基本事实密切相关。

如图左边所示，每个工具可能由多个 API 组成。对于每个工具，会抓取以下信息：工具的名称和描述、主机的 URL 以及属于该工具的所有可用 API；对于每个 API，记录其名称、描述、HTTP 方法、必需参数、可选参数、请求主体、API 调用的可执行代码片段（snippets）以及示例 API 调用响应。这些丰富而详细的元数据是LLM理解和有效使用API的宝贵资源，即使是以零样本的方式。

滤波过程如下：（1）初始测试：首先测试每个API的基本功能，以确定是否可操作。丢弃任何不符合此基本标准的 API;（2）示例响应评估：进行API调用，获得示例响应。然后，通过响应时间和质量来评估其有效性。始终表现出较长响应时间的 API 将被省略。此外，会过滤掉具有低质量响应的 API，例如 HTML格式源代码或其他错误消息。最后，只保留了 3451 个高质量工具（16464 个 API）

在检查每个 API 返回的响应时，发现某些响应可能包含冗余信息，并且太长而无法输入 LLM。由于LLM的上下文长度有限，这可能会导致问题。因此，执行响应压缩以减少 API 响应的长度，同时保留其关键信息。

由于每个 API 都有固定的响应格式，因此使用 ChatGPT 来分析一个响应示例，并删除响应中不重要的key以缩短其长度。ChatGPT 的提示包含以下每个 API 的信息：（1） 工具文档，包括工具名称、工具描述、API 名称、API 描述、参数和示例 API 响应。这给了 ChatGPT 一个关于 API 功能的提示;（2） 3 个上下文学习示例，每个示例包含一个原始 API 响应和一个由专家编写的压缩响应模式。这种方式获得了所有 API 的响应压缩策略。在推理过程中，当 API 响应长度超过 2048 个token时，删除不重要的信息压缩响应。如果压缩响应仍长于 2048，仅保留前 2048 个token。

生成高质量的指令需要两个关键方面：1）多样性，以确保LLM处理广泛的API使用场景，提高其通用性和健壮性；2）多工具使用，以反映通常需要多种工具相互作用的现实世界情况，提高LLM的实际适用性和灵活性。为此，采用自下而上的方法来生成指令。不是从头开始头脑风暴（brainstorming）出指令，然后搜索相关的API，而是从收集的API开始，并制定涉及它们的各种指令。

如上图的右边所示，对于 单工具指令 （I1） ，迭代每个工具并为其 API 生成指令。但是，对于多工具设置，由于 RapidAPI 中不同工具之间的互连是稀疏的，因此来自整个工具集的随机采样组合通常会导致一系列不相关的工具，这些工具无法以自然的方式被单个指令覆盖。为了解决稀疏性问题，利用RapidAPI 层次结构信息。由于属于同一类别或集合的工具在功能和目标上通常相互关联，因此从同一类别/集合中随机选择 2-5 个工具，并从每个工具中最多采样 3 个 API 来生成指令。将生成的指令分别表示为 类别内（intra-category）多工具指令 （I2） 和 聚集内（intra-collection）多工具指令 （I3） 。通过严格的人工评估，发现这种方式生成的指令已经具有高度的多样性，涵盖了各种实际场景。Atlas5 的指令可视化说明了这一点。

在生成初始指令集后，评估它们是否存在于 采样的API集合中，进一步滤除那些带有幻觉相关 API 的指令。最后，收集了超过 200k 个合格的指令 N 个相关 API 对，包括 I1/I2/I3 的 87413/84815/25251 个实例。

如图 所示，给定指令 Inst∗，提示 ChatGPT 搜索有效的动作序列：{a1 ， · · · ， aN }。这种多步骤的决策过程被塑造成 ChatGPT 的多轮对话。在每个时间步 t 处，模型根据先前的交互生成一个动作at，即 ChatGPT（at|{A1， R1， · · ·， at−1， rt−1}， Inst∗），其中 r∗ 表示真正的 API 响应。对于每个动作，都会提示 ChatGPT 指定要使用的 API、API 调用的特定参数及其“思维”。换句话说，at 具有以下格式：“思维：· · · ，API 名称：· · · ，参数：· ”。因此，决策空间是思维、可用 API 和可能参数的笛卡尔乘积，其本质上是无限的。