大型語(yǔ)言模型性能強(qiáng)大，但為了更好地用于解決實(shí)際問(wèn)題，各式各樣的 API 是必不可少的。

近日，加利福尼亞大學(xué)伯克利分校和微軟研究院造出了一只「大猩猩」Gorilla，該模型能根據(jù)用戶(hù)輸入的自然語(yǔ)言為用戶(hù)選擇合適的 API 來(lái)執(zhí)行對(duì)應(yīng)任務(wù)。理論上講，這個(gè)模型可以根據(jù)用戶(hù)需求調(diào)用其它各種 AI 模型，因此 Gorilla 有望成為一個(gè)統(tǒng)御其它 AI 的 AI 模型。該項(xiàng)目的代碼、模型、數(shù)據(jù)和演示都已發(fā)布。

(資料圖片僅供參考)

網(wǎng)站：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

大型語(yǔ)言模型（LLM）近來(lái)出盡風(fēng)頭，在自然對(duì)話、數(shù)學(xué)推理和程序合成等任務(wù)上都取得了顯著進(jìn)展。盡管進(jìn)步非凡，但 LLM 依然從根本上受限于它們?cè)谝粋€(gè)固定的權(quán)重集內(nèi)可存儲(chǔ)的信息以及它們可使用一個(gè)靜態(tài)的計(jì)算圖（computation graph）和有限上下文所能計(jì)算的東西。此外，當(dāng)世界變化時(shí)，還需要重新訓(xùn)練 LLM，以更新它們的知識(shí)和推理能力。

通過(guò)讓 LLM 具備使用工具的能力，我們可以讓其有能力訪問(wèn)更大范圍的和不斷變化的知識(shí)庫(kù)，進(jìn)而完成復(fù)雜的計(jì)算任務(wù)。具體來(lái)說(shuō)，如果為 LLM 提供搜索技術(shù)和數(shù)據(jù)庫(kù)，研究表明 LLM 的能力可得到強(qiáng)化，從而可以應(yīng)對(duì)大得多的且更加動(dòng)態(tài)多變的知識(shí)空間。而當(dāng)為 LLM 提供計(jì)算工具時(shí)，LLM 就能完成復(fù)雜的計(jì)算任務(wù)。因此，引領(lǐng)市場(chǎng)的 LLM 提供商已經(jīng)開(kāi)始提供各種插件，讓 LLM 可通過(guò) API 來(lái)調(diào)用外部工具。

這樣一來(lái)，LLM 的能力范圍就從少量人工編碼的工具轉(zhuǎn)變成了大量不斷變化的云 API，這讓 LLM 可成為用戶(hù)訪問(wèn)計(jì)算基礎(chǔ)設(shè)施和網(wǎng)絡(luò)的主要交互界面。舉個(gè)例子，如果 LLM 可訪問(wèn)航班、租車(chē)、酒店、餐飲和娛樂(lè)行業(yè)的網(wǎng)絡(luò) API，那么從預(yù)定整個(gè)假期行程的各種票證到舉辦一場(chǎng)會(huì)議，只需簡(jiǎn)單地與 LLM 對(duì)話就能完成。但是，在為 LLM 集成各式工具方面，之前的研究考慮的都是可輕松注入到 prompt 中的少量 API，并且這些 API 基本都有很好的文檔描述。

如果想要支持整個(gè)網(wǎng)絡(luò)上數(shù)以百萬(wàn)計(jì)且不斷變化的 API，我們就需要重新思考集成工具的方法。這種情況下，在單一的上下文中描述所有 API 的集合是不可能的。并且許多 API 功能重疊卻又有細(xì)微不同的局限性和約束條件。新的情況還需要新的評(píng)估基準(zhǔn)。

這篇論文中，研究者對(duì)這個(gè)方向進(jìn)行了探索。

他們使用自指示微調(diào)（self-instruct fine-tuning）和檢索（retrieval），讓 LLM 可根據(jù) API 和 API 文檔準(zhǔn)確地從大量重疊且多變的工具中做出選擇。他們構(gòu)建了 APIBench，這是一個(gè)大型 API 語(yǔ)料庫(kù)，是從公開(kāi)模型 Hub 中抓取的機(jī)器學(xué)習(xí) API（模型），它們的功能很復(fù)雜且通常存在重疊。

為了構(gòu)建這個(gè)數(shù)據(jù)集，研究者選取了三個(gè)主要的模型 Hub：TorchHub、TensorHub 和 HuggingFace。他們?cè)敱M地囊括了 TorchHub（94 個(gè) API 調(diào)用）和 TensorHub（696 個(gè) API 調(diào)用）中的所有 API 調(diào)用；而對(duì)于 HuggingFace，由于模型數(shù)量龐大且許多模型都沒(méi)有規(guī)格數(shù)據(jù)，因此他們就從每個(gè)任務(wù)類(lèi)別選取了下載次數(shù)最多的 20 個(gè)模型（共 925 個(gè)）。研究者使用自指示為每個(gè) API 生成了 10 個(gè)合成的用戶(hù)提問(wèn) prompt。這樣，該數(shù)據(jù)集中的每一項(xiàng)都變成了一組配對(duì)的「指示」和「參照 API」。

研究者采用了常用的 AST 子樹(shù)匹配技術(shù)來(lái)評(píng)估所生成的 API 的功能正確性。首先，所生成的代碼被解碼成一個(gè) AST 樹(shù)，然后找到一個(gè)子樹(shù)且其根節(jié)點(diǎn)是我們關(guān)心的 API 調(diào)用（比如 torch.hub.load），然后使用它來(lái)索引數(shù)據(jù)集。研究者評(píng)估了 LLM 的功能正確性和幻覺(jué)問(wèn)題并報(bào)告了相應(yīng)的準(zhǔn)確度。

然后他們通過(guò)微調(diào)得到了 Gorilla，這是一個(gè)基于 LLaMA-7B 的模型，并且其能通過(guò)新構(gòu)建數(shù)據(jù)集索引文檔。通過(guò)實(shí)驗(yàn)，研究者發(fā)現(xiàn)在 API 功能準(zhǔn)確性以及降低幻覺(jué)錯(cuò)誤方面，Gorilla 均顯著優(yōu)于 GPT-4。圖 1 給出了一個(gè)輸出示例。此外，研究者為 Gorilla 采用的檢索感知型訓(xùn)練法（retrieval-aware training）還讓模型可適應(yīng) API 文檔的變化。最后，Gorilla 在理解和推理局限性方面的能力也得到了展示。

方法

圖 1：API 調(diào)用示例

給定一個(gè) prompt，從左至右分別為 GPT-4、Claude、Gorilla 生成的示例 API 調(diào)用。在這個(gè)例子中，GPT-4 給出了一個(gè)根本不存在的模型，Claude 則選取了一個(gè)錯(cuò)誤的軟件庫(kù)。對(duì)比之下，Gorilla 模型能夠正確辨別任務(wù)并建議了一個(gè)完全合格的 API 調(diào)用。

數(shù)據(jù)集收集

為了收集數(shù)據(jù)集，研究者精心記錄了 HuggingFace 的 The Model Hub、PyTorch Hub 以及 TensorFlow Hub Models 的所有在線模型卡片。后面為了方便描述，以上三個(gè) Hub 將被分別簡(jiǎn)稱(chēng)為 HuggingFace、Torch Hub 和 TensorFlow Hub。

API 文檔：HuggingFace 平臺(tái)托管了大約 203681 個(gè)模型。但是，其中大部分都存在文檔問(wèn)題，比如描述很差、缺乏依賴(lài)描述或模型卡片中沒(méi)有信息等。為了濾除這些模型，研究者從每個(gè)域都僅選取了前 20 個(gè)模型。其中多模態(tài)數(shù)據(jù)方面 7 個(gè)域、計(jì)算機(jī)視覺(jué)方面 8 個(gè)、NLP 方面 12 個(gè)、音頻方面 5 個(gè)、表格式數(shù)據(jù)方面 2 個(gè)、強(qiáng)化學(xué)習(xí)方面 2 個(gè)。

過(guò)濾后，從 HuggingFace 共獲得 925 個(gè)模型。TensorFlow Hub 的版本分為 v1 和 v2。最新的 v2 版本共有 801 個(gè)模型，它們?nèi)勘患{入考慮。濾除信息很少和無(wú)信息的模型卡片后，剩余 626 個(gè)模型。類(lèi)似地，研究者從 Torch Hub 得到了 95 個(gè)模型。最終得到 1645 個(gè) API 調(diào)用。然后，他們將其中每一個(gè)的模型卡片都轉(zhuǎn)換成一個(gè) json 對(duì)象，其有以下字段：{域，框架，功能，api_名稱(chēng)，api_調(diào)用，api_參數(shù)，環(huán)境要求，示例代碼，性能，描述}. 下方給出了一個(gè)例子。選取這些字段的目的是將這些機(jī)器學(xué)習(xí)域的 API 調(diào)用泛化到其它域，包括 RESTful API 調(diào)用。

指示生成：研究者使用自指示范式來(lái)引導(dǎo) GPT-4 生成合成的指令數(shù)據(jù)。他們提供了三個(gè)基于上下文的示例以及一個(gè)參照 API 文檔，給模型的任務(wù)是生成調(diào)用該 API 的真實(shí)世界用例。研究者特別指示模型在創(chuàng)建指令時(shí)避免使用任何 API 名稱(chēng)或提示。對(duì)于三個(gè)模型 Hub 中的每一個(gè)，研究者都構(gòu)建了六個(gè)示例（指令 - API 對(duì)）。這 18 個(gè)數(shù)據(jù)點(diǎn)是僅有的人工生成或人工修改的數(shù)據(jù)。對(duì)于那 1645 個(gè) API 數(shù)據(jù)點(diǎn)中的每一個(gè)，研究者采用的方法是從 6 個(gè)對(duì)應(yīng)的指令示例中采樣出 3 個(gè)，用以生成總計(jì) 10 對(duì)「指令 - API」，如圖 3 所示。

研究者重點(diǎn)指出，這些指令只需使用 GPT-4 就能生成，當(dāng)然也可使用其它開(kāi)源的替代工具，比如 LLaMA 和 Alpaca 等。

Gorilla

研究者構(gòu)建的 Gorilla 模型是一種檢索感知型的 LLaMA-7B 模型，并特別針對(duì) API 調(diào)用任務(wù)進(jìn)行了微調(diào)。如圖 3 所示，研究者使用了自指示來(lái)生成 {指令，API} 對(duì)。為了微調(diào) LLaMA，需要將其轉(zhuǎn)換成用戶(hù)與智能體聊天形式的對(duì)話數(shù)據(jù)，其中每個(gè)數(shù)據(jù)點(diǎn)都是一輪對(duì)話，即用戶(hù)和智能體各說(shuō)話一次。然后再在基礎(chǔ) LLaMA-7B 模型上執(zhí)行標(biāo)準(zhǔn)的指令微調(diào)。在實(shí)驗(yàn)中，研究者訓(xùn)練 Gorilla 時(shí)使用了兩種方案：使用檢索器及不使用檢索器。

圖 3：Gorilla：一個(gè)讓 LLM 與 API 交互的系統(tǒng)

圖中，上半部分是訓(xùn)練過(guò)程。研究者表示這是目前最詳盡的機(jī)器學(xué)習(xí) API 數(shù)據(jù)集。下半部分是推理過(guò)程；Gorilla 支持兩種模式：使用檢索和零樣本（無(wú)檢索）。在這個(gè)具體示例中，用戶(hù)查詢(xún)的是基于自然語(yǔ)言生成圖像，模型能夠建議出合適的 API。

帶有局限條件的 API 調(diào)用：API 調(diào)用往往自帶局限性。這些局限性要求 LLM 不僅要能理解 API 調(diào)用的功能，還要能根據(jù)不同的限制參數(shù)對(duì) API 調(diào)用進(jìn)行分類(lèi)。這個(gè)要求會(huì)為整個(gè)過(guò)程引入額外的復(fù)雜性，這要求對(duì) LLM 有更加精細(xì)的理解。

具體來(lái)說(shuō)，對(duì)機(jī)器學(xué)習(xí) API 而言，常見(jiàn)的限制因素有兩個(gè)：參數(shù)數(shù)量和準(zhǔn)確度下限。來(lái)看個(gè)例子，如果有以下 prompt：「調(diào)用一個(gè)參數(shù)數(shù)量少于一千萬(wàn)的圖像分類(lèi)模型，但保持 ImageNet 準(zhǔn)確度至少為 70%?！惯@樣的 prompt 極具挑戰(zhàn)性，讓 LLM 難以準(zhǔn)確解讀和響應(yīng)。LLM 不僅必須理解用戶(hù)描述的功能，還需要推理用戶(hù)請(qǐng)求中嵌入的各種約束條件。這一挑戰(zhàn)突出表明：現(xiàn)實(shí)世界 API 調(diào)用對(duì) LLM 的要求是非常錯(cuò)綜復(fù)雜的。模型只理解 API 調(diào)用的基本功能是不夠的；模型還必須理解伴隨這些調(diào)用而來(lái)的復(fù)雜約束條件并做出適當(dāng)響應(yīng)。這些觀察結(jié)果表明：針對(duì) API 調(diào)用任務(wù)對(duì) LLM 進(jìn)行微調(diào)是必需的。

檢索感知型訓(xùn)練：當(dāng)使用檢索器（根據(jù)指令微調(diào)過(guò)的數(shù)據(jù)集）訓(xùn)練時(shí)，還要在用戶(hù) prompt 后面附帶一句「Use this API documentation for reference: 」。研究者表示，這么做的目的是讓 LLM 學(xué)會(huì)通過(guò)解析問(wèn)題的后半部分來(lái)回答前半部分。研究結(jié)果表明，這樣做能夠 a) 讓 LLM 適應(yīng)測(cè)試時(shí) API 文檔中的變化，b) 基于上下文學(xué)習(xí)提升性能表現(xiàn)，c) 減少幻覺(jué)錯(cuò)誤。

不過(guò)研究者也發(fā)現(xiàn)了一個(gè)讓人驚訝的現(xiàn)象：當(dāng)使用檢索器來(lái)提升 LLM 的能力時(shí)，其性能并不一定總是會(huì)提升，有時(shí)候還會(huì)降低。

Gorilla 推理：推理階段，用戶(hù)提供自然語(yǔ)言表達(dá)的 prompt。類(lèi)似于訓(xùn)練階段，Gorilla 在推理時(shí)也有兩種模式：零樣本和使用檢索。使用零樣本模式時(shí)，prompt（沒(méi)有進(jìn)一步的 prompt 微調(diào)）會(huì)被饋送給 Gorilla LLM 模型，然后模型返回有助于完成任務(wù)和 / 或目標(biāo)的 API 調(diào)用。使用檢索模式時(shí)，檢索器（BM25 或 GPT-Index）首先會(huì)檢索 API 數(shù)據(jù)庫(kù)中存儲(chǔ)的最新的 API 文檔。然后再在用戶(hù) prompt 后面添加一個(gè)消息：Use this API documentation for reference:，之后再饋送給 Gorilla。Gorilla 的輸出是要調(diào)用的 API。除了這個(gè)附加消息之外，該系統(tǒng)不會(huì)再添加更多 prompt 微調(diào)。

驗(yàn)證 API

歸納式程序合成是指合成滿足測(cè)試用例的程序，這類(lèi)技術(shù)已經(jīng)取得了不少成功。但是，在評(píng)估 API 調(diào)用性能時(shí)，測(cè)試用例卻不夠用，因?yàn)轵?yàn)證代碼的語(yǔ)義正確性往往非常困難。以圖像分類(lèi)任務(wù)為例，有 40 多種模型都可用于該任務(wù)。即使將選擇范圍收縮至單一的 Densenet 系列，也有 4 種不同的配置可能性。

因此，一個(gè)任務(wù)可能存在多個(gè)正確答案，而且很難通過(guò)單元測(cè)試判斷使用的 API 在功能上是否等價(jià)于參照 API。因此，為了評(píng)估新模型的性能，研究者使用他們收集的數(shù)據(jù)集對(duì)功能等價(jià)性進(jìn)行了比較。為了追蹤數(shù)據(jù)集中的哪個(gè) API 是 LLM 調(diào)用，研究者采用了 AST 樹(shù)匹配策略。在這項(xiàng)研究中，由于只考慮一個(gè) API 調(diào)用，因此為了揭示正在使用數(shù)據(jù)集中的哪個(gè) API，可以檢查候選 API 調(diào)用的 AST 是否是參照 API 調(diào)用的子樹(shù)。

識(shí)別乃至定義幻覺(jué)可能非常困難。對(duì)此，研究者采用的方法是 AST 匹配。他們將幻覺(jué)定義為不屬于數(shù)據(jù)庫(kù)中任意 API 的子樹(shù)的 API 調(diào)用，即調(diào)用了一個(gè)完全想象出來(lái)的工具。這種形式的調(diào)用不同于調(diào)用了錯(cuò)誤的 API（這種情況被定義為錯(cuò)誤）。

AST 子樹(shù)匹配：AST 子樹(shù)匹配可識(shí)別數(shù)據(jù)庫(kù)中的哪個(gè) API 是 LLM 調(diào)用的 API。由于每次 API 調(diào)用可能有許多參數(shù)，因此就需要對(duì)每個(gè)參數(shù)進(jìn)行匹配。更進(jìn)一步，由于 Python 允許默認(rèn)參數(shù)，因此對(duì)于每個(gè) API 都需定義要用哪些參數(shù)去匹配數(shù)據(jù)庫(kù)。舉個(gè)例子，在函數(shù)調(diào)用中可以檢查 repo_or_dir 和模型參數(shù)。通過(guò)這種方式，可以輕松地檢查參數(shù)是否與參照 API 匹配。

圖 4 給出了更多細(xì)節(jié)。在這個(gè)例子中，Gorilla 返回了一個(gè) torch API 調(diào)用。首先構(gòu)建這個(gè)樹(shù)，然后驗(yàn)證它與數(shù)據(jù)庫(kù)中的子樹(shù)匹配，即沿節(jié)點(diǎn) torch.hub.load、pytorch/vision 和 densenet121 的子樹(shù)。但是，這里沒(méi)有檢查沿葉節(jié)點(diǎn) pretrained = True 的匹配情況，因?yàn)檫@個(gè)參數(shù)是可選的。

圖 4：用于評(píng)估 API 調(diào)用的 AST 子樹(shù)匹配

圖中左側(cè)是 Gorilla 返回的一個(gè) API 調(diào)用。首先構(gòu)建相關(guān)的 API 樹(shù)。然后將其與構(gòu)建的數(shù)據(jù)集比較，看該 API 數(shù)據(jù)集是否有匹配的子樹(shù)。圖中用棕色框標(biāo)記了匹配的子樹(shù)，這說(shuō)明這個(gè) API 調(diào)用是正確的。Pretrained=True 是一個(gè)可選參數(shù)。

評(píng)估

圖 5：使用 GPT 檢索器時(shí)的準(zhǔn)確度

很顯然，Gorilla 的表現(xiàn)優(yōu)于 Torch Hub 和 HuggingFace，與 Tensorflow Hub 的表現(xiàn)相當(dāng)。

表 1：在 Torch Hub、HuggingFace 和 Tensorflow Hub API 上評(píng)估 LLM。

表 1 表明經(jīng)過(guò)輕度微調(diào)的 Gorilla 取得了優(yōu)于其它所有模型的當(dāng)前最佳表現(xiàn)。此外，還可以發(fā)現(xiàn)在沒(méi)有檢索器時(shí)進(jìn)行微調(diào)以及在評(píng)估時(shí)使用 ground truth 檢索器對(duì)性能幾乎沒(méi)有幫助。

表 2：檢索技術(shù)的比較

可以看出，檢索器更好時(shí)，使用檢索器進(jìn)行微調(diào)仍然是更好的方法，而在另一種情況下，如果沒(méi)有好的檢索器，零樣本微調(diào)可能是更優(yōu)選擇。

表 3：在感知約束條件的 API 調(diào)用任務(wù)上評(píng)估 LLM

可以看出，當(dāng)使用檢索器（BM25 或 GPTIndex）時(shí)，Gorilla 的表現(xiàn)接近最優(yōu)秀的 GPT-3.5，而在不使用檢索器時(shí)，Gorilla 的準(zhǔn)確度最高。

關(guān)鍵詞：