LLMs通過純文本語言（例如英語）執(zhí)行命令的能力使得能夠完成用戶查詢的代理系統(tǒng)得以實(shí)現(xiàn)，通過協(xié)調(diào)正確的工具集合（例如ToolFormer、Gorilla）。這個(gè)能力以及最近的多模態(tài)努力，比如 GPT-4o 或 Gemini-1.5 模型，已經(jīng)擴(kuò)展了AI代理的可能性范圍。雖然這非常令人興奮，但這些模型的龐大尺寸和計(jì)算需求通常需要在云端進(jìn)行推理。這可能會(huì)為它們的廣泛應(yīng)用帶來幾個(gè)挑戰(zhàn)。首先，將視頻、音頻或文本文檔等數(shù)據(jù)上傳到云端的第三方供應(yīng)商可能會(huì)導(dǎo)致隱私問題。其次，這需要云端/Wi-Fi連接，這并不總是可能的。例如，部署在現(xiàn)實(shí)世界中的機(jī)器人可能并不總是有穩(wěn)定的連接。除此之外，延遲也可能成為一個(gè)問題，因?yàn)樯蟼鞔罅繑?shù)據(jù)到云端并等待響應(yīng)可能會(huì)減慢響應(yīng)時(shí)間，導(dǎo)致解決問題的時(shí)間不可接受。如果將LLM模型部署到邊緣，這些挑戰(zhàn)可以得到解決。

然而，目前的LLMs，如GPT-4o或Gemini-1.5，對(duì)于本地部署來說過于龐大。一個(gè)導(dǎo)致這種情況的因素是模型尺寸的很大一部分用于將世界的一般信息存儲(chǔ)到其參數(shù)內(nèi)存中，這對(duì)于特定的下游應(yīng)用可能并不是必要的。例如，如果你向這些模型提出一個(gè)關(guān)于歷史事件或著名人物的一般事實(shí)問題，它們可以使用其參數(shù)內(nèi)存產(chǎn)生結(jié)果，即使在提示中沒有額外的上下文。然而，這種將訓(xùn)練數(shù)據(jù)隱式存儲(chǔ)到參數(shù)內(nèi)存中的現(xiàn)象與LLMs中的“出現(xiàn)”現(xiàn)象相關(guān)，例如上下文學(xué)習(xí)和復(fù)雜推理，這已經(jīng)成為擴(kuò)展模型尺寸的推動(dòng)力。

然而，這引出了一個(gè)有趣的研究問題：

一個(gè)參數(shù)內(nèi)存顯著較少的小型語言模型能否模擬這些較大語言模型的這種出現(xiàn)能力？

實(shí)現(xiàn)這一點(diǎn)將顯著減少代理系統(tǒng)的計(jì)算占用，并因此實(shí)現(xiàn)高效和隱私保護(hù)的邊緣部署。研究表明，通過對(duì)不需要回憶通用世界知識(shí)的專門化、高質(zhì)量數(shù)據(jù)進(jìn)行訓(xùn)練，這對(duì)于小型語言模型是可行的。

這樣的系統(tǒng)在語義系統(tǒng)中尤其有用，其中AI代理的角色是理解用戶以自然語言提出的查詢，并且不是用ChatGPT類型的問答響應(yīng)來回答，而是協(xié)調(diào)正確的工具集合和API來完成用戶的命令。例如，在類似Siri的應(yīng)用程序中，用戶可能會(huì)要求語言模型創(chuàng)建一個(gè)具有特定與會(huì)者的日歷邀請(qǐng)。如果已經(jīng)存在用于創(chuàng)建日歷項(xiàng)的預(yù)定義腳本，那么LLM只需要學(xué)會(huì)如何使用正確的輸入?yún)?shù)（例如與會(huì)者的電子郵件地址、事件標(biāo)題和時(shí)間）來調(diào)用此腳本。這個(gè)過程不需要從維基百科等來源回憶/記憶世界知識(shí)，而是需要推理和學(xué)習(xí)如何調(diào)用正確的函數(shù)并正確協(xié)調(diào)它們。

教LLMs進(jìn)行功能調(diào)用

圖1：LLMCompiler功能調(diào)用規(guī)劃器概述。該規(guī)劃器理解用戶查詢并生成一系列具有相互依賴關(guān)系的任務(wù)。然后，LLMCompiler框架分派這些任務(wù)以完成用戶命令。在這個(gè)示例中，任務(wù)

和2被一起獲取以獨(dú)立檢索Sid和Lutfi的電子郵件地址。在執(zhí)行每個(gè)任務(wù)后，結(jié)果被轉(zhuǎn)發(fā)到創(chuàng)建日歷事件的任務(wù)。在執(zhí)行任務(wù)3之前，LLMCompiler會(huì)用實(shí)際值替換占位符變量（例如，在任務(wù)

中的變量1和$2）。

如上所述，主要關(guān)注的是將用戶查詢轉(zhuǎn)換為一系列函數(shù)調(diào)用以完成任務(wù)的應(yīng)用程序。在這種應(yīng)用程序中，模型不需要自己編寫函數(shù)定義，因?yàn)檫@些函數(shù)（或API）大多是預(yù)定義的并且已經(jīng)可用。因此，模型需要做的是確定（i）調(diào)用哪些函數(shù)，（ii）相應(yīng)的輸入?yún)?shù)，以及（iii）根據(jù)函數(shù)調(diào)用之間所需的相互依賴關(guān)系確定調(diào)用這些函數(shù)的正確順序（即函數(shù)編排）。

第一個(gè)問題是找到一種有效的方法來使SLMs執(zhí)行函數(shù)調(diào)用。像GPT-4這樣的大型模型能夠執(zhí)行函數(shù)調(diào)用，但是如何才能用開源模型實(shí)現(xiàn)這一點(diǎn)呢？LLMCompiler是研究人員最近提出的一個(gè)框架，它通過指示LLM輸出一個(gè)包含它需要調(diào)用的函數(shù)集合以及輸入?yún)?shù)和它們的依賴關(guān)系的函數(shù)調(diào)用計(jì)劃來實(shí)現(xiàn)這一點(diǎn)（參見圖1中的示例）。生成了這個(gè)函數(shù)調(diào)用計(jì)劃后，可以解析它并根據(jù)依賴關(guān)系調(diào)用每個(gè)函數(shù)。

關(guān)鍵部分在于教會(huì)模型使用正確的語法和依賴關(guān)系創(chuàng)建這個(gè)函數(shù)調(diào)用計(jì)劃。原始的LLMCompiler論文只考慮了大型模型，如LLaMA-2 70B，當(dāng)在提示中提供足夠的指令時(shí)，這些模型具有復(fù)雜的推理能力來創(chuàng)建計(jì)劃。然而，小型模型是否可以通過相同的方式提示以輸出正確的函數(shù)調(diào)用計(jì)劃呢？不幸的是，實(shí)驗(yàn)表明，諸如TinyLLaMA-1.1B（甚至更大的Wizard-2-7B模型）之類的現(xiàn)成的小型模型無法輸出正確的計(jì)劃。錯(cuò)誤的范圍包括使用錯(cuò)誤的函數(shù)集、虛構(gòu)的名稱、錯(cuò)誤的依賴關(guān)系、不一致的語法等。

這是可以預(yù)料的，因?yàn)檫@些小型模型是在通用數(shù)據(jù)集上進(jìn)行訓(xùn)練的，主要是為了在一般基準(zhǔn)測(cè)試中實(shí)現(xiàn)良好的準(zhǔn)確性，這些測(cè)試主要測(cè)試模型的世界知識(shí)和一般推理或基本指令遵循能力。為了解決這個(gè)問題，研究人員探索了是否可以在專門為函數(shù)調(diào)用和規(guī)劃而策劃的高質(zhì)量數(shù)據(jù)上對(duì)這些模型進(jìn)行微調(diào)，從而提高這些小型語言模型對(duì)目標(biāo)任務(wù)的準(zhǔn)確性，有可能勝過更大的模型。

數(shù)據(jù)生成

圖2：TinyAgent是一個(gè)助手，可以與各種MacOS應(yīng)用程序進(jìn)行交互，以幫助用戶。命令可以通過聚光燈輸入或語音傳達(dá)給它。

作為驅(qū)動(dòng)應(yīng)用程序，考慮了解決用戶日常任務(wù)的蘋果Macbook的本地代理系統(tǒng)，如圖2所示。特別是，該代理程序配備了16種不同的功能，可以與Mac上的不同應(yīng)用程序進(jìn)行交互，包括：

• 電子郵件：撰寫新郵件或回復(fù)/轉(zhuǎn)發(fā)郵件
• 聯(lián)系人：從聯(lián)系人數(shù)據(jù)庫(kù)檢索電話號(hào)碼或電子郵件地址
• 短信：向聯(lián)系人發(fā)送短信
• 日歷：創(chuàng)建具有標(biāo)題、時(shí)間、參與者等詳細(xì)信息的日歷事件
• 備忘錄：設(shè)置各種活動(dòng)和任務(wù)的提醒
• 文件管理：在不同的文件路徑中打開、閱讀或總結(jié)文檔
• Zoom 會(huì)議：安排和組織 Zoom 會(huì)議

每個(gè)這些功能/工具都有預(yù)定義的Apple腳本，模型只需利用這些預(yù)定義的API，并確定正確的函數(shù)調(diào)用計(jì)劃來完成特定任務(wù)，就像圖1中所示的那樣。但是正如之前所討論的，需要一些用于評(píng)估和訓(xùn)練小型語言模型的數(shù)據(jù)，因?yàn)樗鼈兊默F(xiàn)成函數(shù)調(diào)用能力不盡如人意。

創(chuàng)建具有不同功能調(diào)用計(jì)劃的手工數(shù)據(jù)既具有挑戰(zhàn)性，又不具備可擴(kuò)展性。然而，可以使用像GPT-4-Turbo這樣的LLM來策劃合成數(shù)據(jù)。這種方法正在變得越來越普遍，其中一個(gè)能力強(qiáng)大的LLM被指示生成類似于給定樣本示例或模板的數(shù)據(jù)（請(qǐng)參見LLM2LLM和Self-Instruct）。研究人員采用了類似的方法，但是沒有向LLM提供通用的用戶查詢作為模板，而是提供了各種功能集，并指示它生成需要這些功能才能完成任務(wù)的逼真用戶查詢，以及相關(guān)的函數(shù)調(diào)用計(jì)劃和輸入?yún)?shù)，就像圖1中所示的示例一樣。為了驗(yàn)證生成數(shù)據(jù)的有效性，研究人員對(duì)函數(shù)調(diào)用計(jì)劃進(jìn)行了合理性檢查，以確保它們形成可行的圖表，以及函數(shù)名稱和輸入?yún)?shù)類型是正確的。通過這種方法，研究人員創(chuàng)建了80K個(gè)訓(xùn)練數(shù)據(jù)、1K個(gè)驗(yàn)證數(shù)據(jù)和1K個(gè)測(cè)試數(shù)據(jù)，總成本僅為約500美元。

為改進(jìn)函數(shù)調(diào)用推理進(jìn)行微調(diào)

圖3：圖同構(gòu)成功率。僅當(dāng)生成的計(jì)劃的有向無環(huán)圖（DAG）與地面實(shí)況計(jì)劃的DAG同構(gòu)時(shí)，模型的成功率才為1；否則為0。在上面的例子中，對(duì)于頂部情況，雖然獲取電子郵件地址的順序與地面實(shí)況計(jì)劃不同（地面實(shí)況計(jì)劃在獲取Sid的電子郵件地址之前獲取Lutfi的電子郵件地址，而生成的計(jì)劃在獲取Sid的電子郵件地址之前獲取Lutfi的電子郵件地址），但由于兩個(gè)DAG彼此同構(gòu)，因此該計(jì)劃的成功率為1。對(duì)于底部情況，由于預(yù)測(cè)的DAG包含一個(gè)錯(cuò)誤的節(jié)點(diǎn)，對(duì)應(yīng)錯(cuò)誤的函數(shù)調(diào)用，因此該計(jì)劃的成功率為0。

有了數(shù)據(jù)集，現(xiàn)在可以繼續(xù)微調(diào)現(xiàn)成的SLMs以增強(qiáng)它們的函數(shù)調(diào)用能力。研究人員從兩個(gè)基本的小型模型開始：TinyLlama-1.1B（instruct-32k版本）和Wizard-2-7B。對(duì)于這些模型的微調(diào)，首先需要定義一個(gè)指標(biāo)來評(píng)估它們的性能。目標(biāo)是使這些模型能夠準(zhǔn)確地生成正確的計(jì)劃，這不僅涉及選擇正確的函數(shù)集，還涉及以正確的順序?qū)λ鼈冞M(jìn)行正確的編排。因此，研究人員定義了一個(gè)成功率指標(biāo)，如果兩個(gè)標(biāo)準(zhǔn)都滿足則分配為1，否則為0。檢查模型是否選擇了正確的函數(shù)集是很簡(jiǎn)單的。為了確保這些函數(shù)的編排是正確的，另外構(gòu)建了一個(gè)基于依賴關(guān)系的函數(shù)調(diào)用的有向無環(huán)圖（DAG），如圖3所示，其中每個(gè)節(jié)點(diǎn)代表一個(gè)函數(shù)調(diào)用，從節(jié)點(diǎn)A到B的有向邊表示它們的相互依賴關(guān)系（即函數(shù)B只能在函數(shù)A執(zhí)行之后執(zhí)行）。然后，比較這個(gè)DAG是否與地面實(shí)況計(jì)劃的DAG相同，以驗(yàn)證依賴關(guān)系的準(zhǔn)確性。

在定義了評(píng)估指標(biāo)之后，研究人員應(yīng)用了LoRA對(duì)模型進(jìn)行了3個(gè)時(shí)期的微調(diào)，使用了學(xué)習(xí)率為7e-5的80K個(gè)訓(xùn)練示例，并根據(jù)驗(yàn)證性能選擇了最佳檢查點(diǎn)。對(duì)于微調(diào)，提示不僅包括地面實(shí)況函數(shù)的描述（即地面實(shí)況計(jì)劃中使用的函數(shù)），還包括其他無關(guān)的函數(shù)作為負(fù)樣本。研究人員發(fā)現(xiàn)負(fù)樣本對(duì)教授模型如何為給定查詢選擇適當(dāng)?shù)墓ぞ咛貏e有效，從而改善了訓(xùn)練后的性能。此外，研究人員還包括了幾個(gè)上下文示例，展示了如何將查詢轉(zhuǎn)換為函數(shù)調(diào)用計(jì)劃。這些上下文示例是通過基于訓(xùn)練數(shù)據(jù)中的用戶查詢的檢索增強(qiáng)生成（RAG）過程選取的。

使用上述設(shè)置，微調(diào)了TinyLlama-1.1B/Wizard-2-7B模型。微調(diào)后，1.1B模型的成功率從12.71%提高到78.89%，而7B模型的性能從41.25%提高到83.09%，比GPT-4-Turbo高出約4%。

使用 RAG 工具進(jìn)行高效推理

圖4：基于用戶輸入的高效工具選擇。并非所有用戶輸入都需要所有可用工具；因此，選擇正確的工具集以最小化提示大小并提高性能至關(guān)重要。在這種情況下，LLM只需要在其提示中包含獲取電子郵件地址和創(chuàng)建日歷事件的函數(shù)，就可以完成其任務(wù)。

主要目標(biāo)是能夠在Macbook上本地部署TinyAgent模型，與像GPT這樣的閉源模型部署在的GPU相比，Macbook的計(jì)算和內(nèi)存資源有限。為了實(shí)現(xiàn)低延遲的高效性能，需要確保不僅模型大小小，而且輸入提示盡可能簡(jiǎn)潔。后者是延遲和計(jì)算資源消耗的重要因素，因?yàn)樽⒁饬?duì)序列長(zhǎng)度的二次復(fù)雜度。

前面討論過的微調(diào)的TinyAgent模型在其提示中包含了所有可用工具的描述。然而，這是相當(dāng)?shù)托У??？梢酝ㄟ^僅根據(jù)用戶查詢包含相關(guān)工具的描述來顯著減小提示大小。例如，考慮上圖中顯示的示例，在該示例中，用戶要求創(chuàng)建一個(gè)與兩個(gè)人的日歷邀請(qǐng)相關(guān)的任務(wù)。在這種情況下，LLM只需要在其提示中包含獲取電子郵件地址和創(chuàng)建日歷事件的函數(shù)。

為了利用這一觀察結(jié)果，需要確定完成用戶命令所需的函數(shù)，將其稱為工具RAG，因?yàn)樗c檢索增強(qiáng)生成（RAG）的工作方式相似。然而，有一個(gè)重要的細(xì)微之處。如果使用基本的RAG方法，其中計(jì)算用戶查詢的嵌入并使用該嵌入來檢索相關(guān)工具，會(huì)得到非常低的性能。這是因?yàn)橥瓿捎脩舻牟樵兺ǔＰ枰褂脦讉€(gè)輔助工具，如果輔助工具的嵌入與用戶查詢不相似，則簡(jiǎn)單的RAG方法可能會(huì)忽略這些工具。例如，上圖中顯示的示例需要調(diào)用獲取電子郵件地址函數(shù)，即使用戶查詢只是詢問如何創(chuàng)建日歷邀請(qǐng)。

這可以通過將問題視為哪些工具是必需的分類來解決。為此，在訓(xùn)練數(shù)據(jù)上微調(diào)了一個(gè)DeBERTa-v3-small模型，以進(jìn)行16路分類，如圖5所示。用戶查詢作為輸入提供給此模型，然后通過一個(gè)大小為768x16的簡(jiǎn)單全連接層傳遞最后的CLS標(biāo)記，將其轉(zhuǎn)換為一個(gè)16維向量（這是工具的總大?。?。這一層的輸出經(jīng)過一個(gè)sigmoid層，產(chǎn)生選擇每個(gè)工具的概率。在推斷過程中，選擇概率大于50%的工具，并在提示中包含它們的描述。平均而言，注意到僅檢索到3.97個(gè)工具，召回率為0.998，而基本的RAG需要使用前6個(gè)工具才能實(shí)現(xiàn)0.968的工具召回率。

圖5：工具RAG方案概述。將工具檢索構(gòu)建為一個(gè)多標(biāo)簽分類問題。用戶查詢作為輸入提供給微調(diào)后的DeBERTa-v3-small模型，該模型輸出一個(gè)16維向量，指示工具的概率。選擇概率高于50%的工具，平均每個(gè)查詢有3.97個(gè)工具，而基本RAG中有6個(gè)工具。

在整合了工具RAG后評(píng)估了模型的性能。下表顯示了結(jié)果，報(bào)告了簡(jiǎn)單RAG系統(tǒng)以及微調(diào)后的DeBERTa方法的性能。正如大家所見，基于DeBERTa的工具RAG方法實(shí)現(xiàn)了幾乎完美的召回性能，提高了基線準(zhǔn)確性，同時(shí)將提示大小減少了約2倍的令牌。

表1：使用DeBERTa與基本RAG和無RAG設(shè)置進(jìn)行TinyAgent性能比較。

快速邊緣部署與量化

即使對(duì)于參數(shù)為O(1B)的小型模型，在邊緣部署模型，例如在消費(fèi)者的MacBook上，仍然可能具有挑戰(zhàn)性，因?yàn)榧虞d模型參數(shù)可能會(huì)消耗可用內(nèi)存的大部分。這些問題的解決方案是量化，它允許以降低的位精度存儲(chǔ)模型。量化不僅減少了存儲(chǔ)要求和模型占用空間，還減少了加載模型權(quán)重到內(nèi)存所需的時(shí)間和資源，從而降低了整體推理延遲（有關(guān)量化的更多信息，請(qǐng)參見此處）。

為了更有效地部署模型，研究人員將模型量化為4位，組大小為32，這是由llama.cpp框架支持的，具有量化感知訓(xùn)練。如表2所示，4位模型的延遲改善了30%，同時(shí)模型大小減少了4倍。還注意到輕微的準(zhǔn)確性提高，這是由于通過模擬量化進(jìn)行了額外的微調(diào)。

表2：在量化之前和之后的TinyAgent模型的延遲、大小和成功率。延遲是函數(shù)調(diào)用規(guī)劃器的端到端延遲，包括提示處理時(shí)間和生成時(shí)間。

將所有內(nèi)容整合起來

以下是在Macbook Pro M3上部署的最終TinyAgent-1.1B模型的演示，您實(shí)際上可以下載并安裝在您的Mac上進(jìn)行測(cè)試。它不僅在您的計(jì)算機(jī)上本地運(yùn)行所有的模型推理，而且還允許您通過音頻提供命令。還在本地使用了來自O(shè)penAI的Whisper-v3模型，使用whisper.cpp框架進(jìn)行本地處理音頻。1.1B模型的準(zhǔn)確性超過了GPT-4-Turbo，并且在本地設(shè)備上部署時(shí)速度明顯快。

總結(jié)一下，本文介紹了TinyAgent，并展示了確實(shí)可以訓(xùn)練一個(gè)小型語言模型并用它來驅(qū)動(dòng)處理用戶查詢的語義系統(tǒng)。特別是，考慮了一個(gè)類似Siri的Mac助手作為驅(qū)動(dòng)應(yīng)用程序。啟用它的關(guān)鍵組件是（i）通過LLMCompiler框架教授現(xiàn)成的SLM執(zhí)行函數(shù)調(diào)用，（ii）為手頭的任務(wù)策劃高質(zhì)量的函數(shù)調(diào)用數(shù)據(jù)，（iii）在生成的數(shù)據(jù)上微調(diào)現(xiàn)成的模型，以及（iv）通過一種稱為ToolRAG的方法根據(jù)用戶查詢僅檢索必要的工具來優(yōu)化提示大小，以及量化模型部署以減少推理資源消耗。經(jīng)過這些步驟，最終模型在此任務(wù)上實(shí)現(xiàn)了80.06%和84.95%的成功率，超過了GPT-4-Turbo的79.08%。

譯自（有刪改）：https://bair.berkeley.edu/blog/2024/05/29/tiny-agent

本文轉(zhuǎn)載自公眾號(hào)AIGC最前線   

原文鏈接：??https://mp.weixin.qq.com/s/di5b7lW0RXowWik3UcgAEA??