首个大规模使用工具的大模型来了:伯克利发布 Gorilla24核M2 Ultra处理器性能跑分出炉 Intel/AMD笑了:苹果还嫩AI浪潮席卷 行业生态再造显卡销量崩了 出货量暴降背后:越来越贵降价不现实 英伟达一家独大22.5 万元!小鹏 G6 预售价惊艳全场,但仍逃不过「翻车」命运卷疯!国产带头杀价 4TB SSD被杀至969元:闪存、性能没得说苹果M2 MacBook Air 13英寸降价了:8999元起售百度沈抖:未来所有企业都会强依赖大模型都知道是淘汰赛,但谁都不想被淘汰拒绝直男风!盘点618少女心爆棚的电竞好物小桌面也能有顶级好声音!惠威桌面音箱带你畅享音乐今年最火的耳机,为什么是耳夹式耳机?通用、福特、特斯拉,北美三大统一充电标准AI浪潮席卷,行业生态再造欧盟批准81亿欧元公共资金支持芯片研发,首批产品2025年面市大模型乘风破浪,AI打通应用落地渠道

2023-06-10 0 1,118

机器之心报道

编辑:Panda

One AI to rule them all.

小型词汇数学模型操控性强大,但为了更好地用于解决实际问题,各种各样的 API 是必不可少的。

近日,加州大学康奈尔大学分校和谷歌研究院制出了一只「长颈鹿」Gorilla,该数学模型能依照采用者输入的自然词汇为采用者选择合适的 API 来执行对应各项任务。理论上讲,这个数学模型能依照采用者需求初始化其他各种各样 AI 数学模型,因此 Gorilla 有望成为一个统摄其他 AI 的 AI 数学模型。该项目的代码、数学模型、数据和模拟都已正式发布。

网站:gorilla.cs.berkeley.edu

论文:arxiv.org/abs/2305.15334

GitHub:https://github.com/ShishirPatil/gorilla/

Gorilla Spotlight Waitlist:https://t.co/rvmk13Mhrx

Discord 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 的准确度最高。

THE END

转载请联系本公众号获得授权

投稿或寻求报道:content@jiqizhixin.com

相关文章

发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务