继羊驼之后，又来了个以动物命名的模型，这次是大猩猩（Gorilla）。
虽说目前LLM风头正旺，进展颇多，在各种任务中的性能表现也可圈可点，但这些模型通过API调用有效使用工具的潜力还亟待挖掘。
即使对于今天最先进的LLM，比如GPT-4，API调用也是一项具有挑战性的任务，主要是由于它们无法生成准确的输入参数，并且LLM容易对API调用的错误使用产生幻觉。
这不，研究人员搞了个Gorilla，一个经过微调的基于LLaMA的模型，它在编写API调用上的性能甚至超过了GPT-4。
而当与文档检索器相结合时，Gorilla同样展示出了强大的性能，使用户更新或版本变化变得更加灵活。
此外，Gorilla还大大缓解了LLM会经常遇到的幻觉问题。
为了评估该模型的能力，研究人员还引入了API基准，一个由HuggingFace、TorchHub和TensorHub API组成的综合数据集
Gorilla
LLMs的各项强大的能力不用再多介绍，包括自然对话能力、数学推理能力，以及程序合成在能力什么的。
然而，尽管性能强大，但LLM仍然会受到一些限制。并且，LLM也需要重新训练以及时更新他们的知识库，以及推理能力。
通过授权LLM可使用的工具，研究人员可以允许LLM访问巨大的、不断变化的知识库，完成复杂的计算任务。
通过提供对搜索技术和数据库的访问，研究人员可以增强LLM的能力，以处理更大和更动态的知识空间。
同样，通过提供计算工具的使用，LLM也可以完成复杂的计算任务。
因此，科技巨头已经开始尝试整合各类插件，使LLM能够通过API调用外部工具。
从一个规模较小的手工编码的工具，到能够调用一个巨大的、不断变化的云API空间，这种转变可以将LLM转变为计算基础设施，以及网络所需的主要界面。
从预订整个假期到举办一次会议的任务，可以变得像与能够访问航班、汽车租赁、酒店、餐饮和娱乐网络API的LLM交谈一样简单。
然而，许多先前的工作将工具整合到LLM中，考虑的是一小套有据可查的API，可以很容易地注入到提示中。
支持一个由潜在的数百万个变化的API组成的网络规模的集合，需要重新思考研究人员如何整合工具的方法。
现在已经不可能在一个单一的环境中描述所有的API了。许多API会有重叠的功能，有细微的限制和约束。在这种新的环境中简单地评估LLM需要新的基准。
在本文中，研究人员探索了使用自我结构微调和检索的方法，以使LLM能够准确地从使用其API和API文档表达的大量、重叠和变化的工具集中进行选择。
研究人员通过从公共模型中心刮取ML API（模型）来构建API Bench，这是一个具有复杂且经常重叠功能的大型API语料库。
研究人员选择了三个主要的模型中心来构建数据集：TorchHub、TensorHub和HuggingFace。
研究人员详尽地包括了TorchHub（94个API调用）和TensorHub（696个API调用）中的每一个API调用。
对于HuggingFace，由于模型的数量很大，所以研究人员选择了每个任务类别中下载最多的20个模型（总共925个）。
研究人员还使用Self-Instruct为每个API生成了10个用户问题的prompt。
因此，数据集中的每个条目都成为了一个指令参考API对。研究人员采用常见的AST子树匹配技术来评估生成的API的功能正确性。
研究人员首先将生成的代码解析成AST树，然后找到一个子树，其根节点是研究人员关心的API调用，然后使用它来索引研究人员的数据集。
研究人员检查LLMs的功能正确性和幻觉问题，反馈相应的准确性。然后，研究人员再对Gorilla进行微调，这是一个基于LLaMA-7B的模型，使用研究人员的数据集进行文档检索的操作。
研究人员发现，Gorilla在API功能准确性以及减少幻觉错误方面明显优于GPT-4。
研究人员在图1中展示了一个实例。
此外，研究人员对Gorilla进行的检索感知训练使得该模型能够适应API文档的变化。
最后，研究人员还展示了Gorilla理解和推理约束的能力。
另外，在幻觉方面，Gorilla也表现出色。
下图是精度和幻觉在四种情况下的对比，零样本（即，没有任何检索器）以及使用BM25、GPT和Oracle的检索器。
其中BM25和GPT是常用的检索器，而Oracle检索器则会以100%的相关性返回相关文档，表示一种上限。
图中准确性更高、幻觉更少的即为效果更好。
在整个数据集中，Gorilla在提高准确性的同时减少了幻觉。
为了收集数据集，研究人员细致地记录了HuggingFace的The Model Hub、PyTorch Hub和TensorFlow Hub模型的所有在线模型。
HuggingFace平台托管和服务有总共203681个模型。
然而，其中很多模型的文档都不咋样。
为了过滤掉这些质量不高的模型，研究人员最终从每个领域挑选出前20个模型。
研究人员考虑了多模态数据的7个领域，CV的8个领域，NLP的12个领域，音频的5个领域，表格数据的2个领域，以及强化学习的2个领域。
过滤后，研究人员从HuggingFace得到了总共925个模型。TensorFlow Hub的版本分为v1和v2。
最新的版本（v2）总共有801个模型，研究人员处理了所有的模型。在过滤掉几乎没有信息的模型后，剩下了626个模型。
与TensorFlow Hub类似，研究人员从Torch Hub得到95个模型。
在self-instruct范式的指导下，研究人员采用GPT-4来生成合成指令数据。
研究人员提供了三个语境中的例子，以及一个参考的API文档，并责成模型生成调用API的真实用例。
研究人员特别指示该模型在创建指令时不要使用任何API名称或提示。研究人员为三个模型中心的每一个构建了六个例子（指令-API对）。
这18个点，是唯一手工生成或者修改过的数据。
而Gorilla，则是检索感知的LLaMA-7B模型，专门用于API调用。
如图3所示，研究人员采用自我构造来生成{指令，API}对。
为了对LLaMA进行微调，研究人员将其转换为用户——代理的聊天式对话，其中每个数据点都是一个对话，用户和代理轮流交谈。
然后研究人员在基础的LLaMA-7B模型上进行标准的指令微调。在实验中，研究人员在有和没有检索器的情况下分别训练了Gorilla。
在研究中，研究人员关注的是旨在为提高LLM针对特定任务准确识别适当的API的能力的技术——这是该技术发展中至关重要，但经常被忽略的方面。
由于API的功能是一种通用语言，使不同的系统之间能够进行有效地沟通，正确使用API可以提高LLM与更广泛的工具进行互动的能力。
在研究人员收集的三个大规模数据集中，Gorilla的性能超过了最先进的LLM（GPT-4）。Gorilla产生了可靠的API调用ML模型，且没有产生幻觉，并能在挑选API时满足约束条件。
由于希望找到一个具有挑战性的数据集，研究人员选择了ML APIs，因为它们的功能相似。专注于ML领域的API的潜在缺点是，如果在有倾向的数据上进行训练，它们就有可能产生有偏见的预测，可能对某些子群体不利。
为了消除这种顾虑并促进对这些API的深入了解，研究人员正在发布更加广泛的数据集，其中包括超过11000个指令——API对。
在下图这个示例中，研究人员使用抽象语法树（AST）子树匹配来评估API调用的正确性。
抽象语法树是源代码结构的树形表示，有助于更好地分析和理解代码。
首先，研究人员从Gorilla返回的API调用（左侧）构建相关的API树。然后将其与数据集进行比较，以查看API数据集是否具有子树匹配。
在上面的示例中，匹配的子树以棕色突出显示，表示API调用确实是正确的。其中Pretrained=True是一个可选参数。
这一资源将为更广泛的社区提供服务，作为研究和衡量现有API的宝贵工具，为更公平和优化使用机器学习做出贡献。
