One AI to rule them all.

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

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

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

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

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

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

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

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

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

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

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

方法

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

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

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

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

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

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

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

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

Gorilla

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

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

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

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

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

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

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

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

驗(yàn)證 API

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

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

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

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

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

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

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

評估

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

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

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

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

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

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

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

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

審核編輯 ：李倩