大型语言模型性能强大，但为了更好地用于解决实际问题，各式各样的 API 是必不可少的。

近日，加利福尼亚大学伯克利分校和微软研究院造出了一只「大猩猩」Gorilla，该模型能根据用户输入的自然语言为用户选择合适的 API 来执行对应任务。理论上讲，这个模型可以根据用户需求调用其它各种 AI 模型，因此 Gorilla 有望成为一个统御其它 AI 的 AI 模型。该项目的代码、模型、数据和演示都已发布。

(资料图片仅供参考)

网站：gorilla.cs.berkeley.edu论文：arxiv.org/abs/2305.15334GitHub：https://github.com/ShishirPatil/gorilla/Gorilla Spotlight Waitlist：https://t.co/rvmk13MhrxDiscord Community：https://discord.gg/pWeBheVY7n

大型语言模型（LLM）近来出尽风头，在自然对话、数学推理和程序合成等任务上都取得了显著进展。尽管进步非凡，但 LLM 依然从根本上受限于它们在一个固定的权重集内可存储的信息以及它们可使用一个静态的计算图（computation graph）和有限上下文所能计算的东西。此外，当世界变化时，还需要重新训练 LLM，以更新它们的知识和推理能力。

通过让 LLM 具备使用工具的能力，我们可以让其有能力访问更大范围的和不断变化的知识库，进而完成复杂的计算任务。具体来说，如果为 LLM 提供搜索技术和数据库，研究表明 LLM 的能力可得到强化，从而可以应对大得多的且更加动态多变的知识空间。而当为 LLM 提供计算工具时，LLM 就能完成复杂的计算任务。因此，引领市场的 LLM 提供商已经开始提供各种插件，让 LLM 可通过 API 来调用外部工具。

这样一来，LLM 的能力范围就从少量人工编码的工具转变成了大量不断变化的云 API，这让 LLM 可成为用户访问计算基础设施和网络的主要交互界面。举个例子，如果 LLM 可访问航班、租车、酒店、餐饮和娱乐行业的网络 API，那么从预定整个假期行程的各种票证到举办一场会议，只需简单地与 LLM 对话就能完成。但是，在为 LLM 集成各式工具方面，之前的研究考虑的都是可轻松注入到 prompt 中的少量 API，并且这些 API 基本都有很好的文档描述。

如果想要支持整个网络上数以百万计且不断变化的 API，我们就需要重新思考集成工具的方法。这种情况下，在单一的上下文中描述所有 API 的集合是不可能的。并且许多 API 功能重叠却又有细微不同的局限性和约束条件。新的情况还需要新的评估基准。

这篇论文中，研究者对这个方向进行了探索。

他们使用自指示微调（self-instruct fine-tuning）和检索（retrieval），让 LLM 可根据 API 和 API 文档准确地从大量重叠且多变的工具中做出选择。他们构建了 APIBench，这是一个大型 API 语料库，是从公开模型 Hub 中抓取的机器学习 API（模型），它们的功能很复杂且通常存在重叠。

为了构建这个数据集，研究者选取了三个主要的模型 Hub：TorchHub、TensorHub 和 HuggingFace。他们详尽地囊括了 TorchHub（94 个 API 调用）和 TensorHub（696 个 API 调用）中的所有 API 调用；而对于 HuggingFace，由于模型数量庞大且许多模型都没有规格数据，因此他们就从每个任务类别选取了下载次数最多的 20 个模型（共 925 个）。研究者使用自指示为每个 API 生成了 10 个合成的用户提问 prompt。这样，该数据集中的每一项都变成了一组配对的「指示」和「参照 API」。

研究者采用了常用的 AST 子树匹配技术来评估所生成的 API 的功能正确性。首先，所生成的代码被解码成一个 AST 树，然后找到一个子树且其根节点是我们关心的 API 调用（比如 torch.hub.load），然后使用它来索引数据集。研究者评估了 LLM 的功能正确性和幻觉问题并报告了相应的准确度。

然后他们通过微调得到了 Gorilla，这是一个基于 LLaMA-7B 的模型，并且其能通过新构建数据集索引文档。通过实验，研究者发现在 API 功能准确性以及降低幻觉错误方面，Gorilla 均显著优于 GPT-4。图 1 给出了一个输出示例。此外，研究者为 Gorilla 采用的检索感知型训练法（retrieval-aware training）还让模型可适应 API 文档的变化。最后，Gorilla 在理解和推理局限性方面的能力也得到了展示。

方法

图 1：API 调用示例

给定一个 prompt，从左至右分别为 GPT-4、Claude、Gorilla 生成的示例 API 调用。在这个例子中，GPT-4 给出了一个根本不存在的模型，Claude 则选取了一个错误的软件库。对比之下，Gorilla 模型能够正确辨别任务并建议了一个完全合格的 API 调用。

数据集收集

为了收集数据集，研究者精心记录了 HuggingFace 的 The Model Hub、PyTorch Hub 以及 TensorFlow Hub Models 的所有在线模型卡片。后面为了方便描述，以上三个 Hub 将被分别简称为 HuggingFace、Torch Hub 和 TensorFlow Hub。

API 文档：HuggingFace 平台托管了大约 203681 个模型。但是，其中大部分都存在文档问题，比如描述很差、缺乏依赖描述或模型卡片中没有信息等。为了滤除这些模型，研究者从每个域都仅选取了前 20 个模型。其中多模态数据方面 7 个域、计算机视觉方面 8 个、NLP 方面 12 个、音频方面 5 个、表格式数据方面 2 个、强化学习方面 2 个。

过滤后，从 HuggingFace 共获得 925 个模型。TensorFlow Hub 的版本分为 v1 和 v2。最新的 v2 版本共有 801 个模型，它们全部被纳入考虑。滤除信息很少和无信息的模型卡片后，剩余 626 个模型。类似地，研究者从 Torch Hub 得到了 95 个模型。最终得到 1645 个 API 调用。然后，他们将其中每一个的模型卡片都转换成一个 json 对象，其有以下字段：{域，框架，功能，api_名称，api_调用，api_参数，环境要求，示例代码，性能，描述}. 下方给出了一个例子。选取这些字段的目的是将这些机器学习域的 API 调用泛化到其它域，包括 RESTful API 调用。

指示生成：研究者使用自指示范式来引导 GPT-4 生成合成的指令数据。他们提供了三个基于上下文的示例以及一个参照 API 文档，给模型的任务是生成调用该 API 的真实世界用例。研究者特别指示模型在创建指令时避免使用任何 API 名称或提示。对于三个模型 Hub 中的每一个，研究者都构建了六个示例（指令 - API 对）。这 18 个数据点是仅有的人工生成或人工修改的数据。对于那 1645 个 API 数据点中的每一个，研究者采用的方法是从 6 个对应的指令示例中采样出 3 个，用以生成总计 10 对「指令 - API」，如图 3 所示。

研究者重点指出，这些指令只需使用 GPT-4 就能生成，当然也可使用其它开源的替代工具，比如 LLaMA 和 Alpaca 等。

Gorilla

研究者构建的 Gorilla 模型是一种检索感知型的 LLaMA-7B 模型，并特别针对 API 调用任务进行了微调。如图 3 所示，研究者使用了自指示来生成 {指令，API} 对。为了微调 LLaMA，需要将其转换成用户与智能体聊天形式的对话数据，其中每个数据点都是一轮对话，即用户和智能体各说话一次。然后再在基础 LLaMA-7B 模型上执行标准的指令微调。在实验中，研究者训练 Gorilla 时使用了两种方案：使用检索器及不使用检索器。

图 3：Gorilla：一个让 LLM 与 API 交互的系统

图中，上半部分是训练过程。研究者表示这是目前最详尽的机器学习 API 数据集。下半部分是推理过程；Gorilla 支持两种模式：使用检索和零样本（无检索）。在这个具体示例中，用户查询的是基于自然语言生成图像，模型能够建议出合适的 API。

带有局限条件的 API 调用：API 调用往往自带局限性。这些局限性要求 LLM 不仅要能理解 API 调用的功能，还要能根据不同的限制参数对 API 调用进行分类。这个要求会为整个过程引入额外的复杂性，这要求对 LLM 有更加精细的理解。

具体来说，对机器学习 API 而言，常见的限制因素有两个：参数数量和准确度下限。来看个例子，如果有以下 prompt：「调用一个参数数量少于一千万的图像分类模型，但保持 ImageNet 准确度至少为 70%。」这样的 prompt 极具挑战性，让 LLM 难以准确解读和响应。LLM 不仅必须理解用户描述的功能，还需要推理用户请求中嵌入的各种约束条件。这一挑战突出表明：现实世界 API 调用对 LLM 的要求是非常错综复杂的。模型只理解 API 调用的基本功能是不够的；模型还必须理解伴随这些调用而来的复杂约束条件并做出适当响应。这些观察结果表明：针对 API 调用任务对 LLM 进行微调是必需的。

检索感知型训练：当使用检索器（根据指令微调过的数据集）训练时，还要在用户 prompt 后面附带一句「Use this API documentation for reference: 」。研究者表示，这么做的目的是让 LLM 学会通过解析问题的后半部分来回答前半部分。研究结果表明，这样做能够 a) 让 LLM 适应测试时 API 文档中的变化，b) 基于上下文学习提升性能表现，c) 减少幻觉错误。

不过研究者也发现了一个让人惊讶的现象：当使用检索器来提升 LLM 的能力时，其性能并不一定总是会提升，有时候还会降低。

Gorilla 推理：推理阶段，用户提供自然语言表达的 prompt。类似于训练阶段，Gorilla 在推理时也有两种模式：零样本和使用检索。使用零样本模式时，prompt（没有进一步的 prompt 微调）会被馈送给 Gorilla LLM 模型，然后模型返回有助于完成任务和 / 或目标的 API 调用。使用检索模式时，检索器（BM25 或 GPT-Index）首先会检索 API 数据库中存储的最新的 API 文档。然后再在用户 prompt 后面添加一个消息：Use this API documentation for reference:，之后再馈送给 Gorilla。Gorilla 的输出是要调用的 API。除了这个附加消息之外，该系统不会再添加更多 prompt 微调。

验证 API

归纳式程序合成是指合成满足测试用例的程序，这类技术已经取得了不少成功。但是，在评估 API 调用性能时，测试用例却不够用，因为验证代码的语义正确性往往非常困难。以图像分类任务为例，有 40 多种模型都可用于该任务。即使将选择范围收缩至单一的 Densenet 系列，也有 4 种不同的配置可能性。

因此，一个任务可能存在多个正确答案，而且很难通过单元测试判断使用的 API 在功能上是否等价于参照 API。因此，为了评估新模型的性能，研究者使用他们收集的数据集对功能等价性进行了比较。为了追踪数据集中的哪个 API 是 LLM 调用，研究者采用了 AST 树匹配策略。在这项研究中，由于只考虑一个 API 调用，因此为了揭示正在使用数据集中的哪个 API，可以检查候选 API 调用的 AST 是否是参照 API 调用的子树。

识别乃至定义幻觉可能非常困难。对此，研究者采用的方法是 AST 匹配。他们将幻觉定义为不属于数据库中任意 API 的子树的 API 调用，即调用了一个完全想象出来的工具。这种形式的调用不同于调用了错误的 API（这种情况被定义为错误）。

AST 子树匹配：AST 子树匹配可识别数据库中的哪个 API 是 LLM 调用的 API。由于每次 API 调用可能有许多参数，因此就需要对每个参数进行匹配。更进一步，由于 Python 允许默认参数，因此对于每个 API 都需定义要用哪些参数去匹配数据库。举个例子，在函数调用中可以检查 repo_or_dir 和模型参数。通过这种方式，可以轻松地检查参数是否与参照 API 匹配。

图 4 给出了更多细节。在这个例子中，Gorilla 返回了一个 torch API 调用。首先构建这个树，然后验证它与数据库中的子树匹配，即沿节点 torch.hub.load、pytorch/vision 和 densenet121 的子树。但是，这里没有检查沿叶节点 pretrained = True 的匹配情况，因为这个参数是可选的。

图 4：用于评估 API 调用的 AST 子树匹配

图中左侧是 Gorilla 返回的一个 API 调用。首先构建相关的 API 树。然后将其与构建的数据集比较，看该 API 数据集是否有匹配的子树。图中用棕色框标记了匹配的子树，这说明这个 API 调用是正确的。Pretrained=True 是一个可选参数。

评估

图 5：使用 GPT 检索器时的准确度

很显然，Gorilla 的表现优于 Torch Hub 和 HuggingFace，与 Tensorflow Hub 的表现相当。

表 1：在 Torch Hub、HuggingFace 和 Tensorflow Hub API 上评估 LLM。

表 1 表明经过轻度微调的 Gorilla 取得了优于其它所有模型的当前最佳表现。此外，还可以发现在没有检索器时进行微调以及在评估时使用 ground truth 检索器对性能几乎没有帮助。

表 2：检索技术的比较

可以看出，检索器更好时，使用检索器进行微调仍然是更好的方法，而在另一种情况下，如果没有好的检索器，零样本微调可能是更优选择。

表 3：在感知约束条件的 API 调用任务上评估 LLM

可以看出，当使用检索器（BM25 或 GPTIndex）时，Gorilla 的表现接近最优秀的 GPT-3.5，而在不使用检索器时，Gorilla 的准确度最高。

关键词：