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

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

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

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

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

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

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

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

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

中的變量1和$2）。

如上所述，主要關(guān)注的是將用戶查詢轉(zhuǎn)換為一系列函數(shù)調(diào)用以完成任務(wù)的應(yīng)用程序。在這種應(yīng)用程序中，模型不需要自己編寫函數(shù)定義，因為這些函數(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ù)編排）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了利用這一觀察結(jié)果，需要確定完成用戶命令所需的函數(shù)，將其稱為工具RAG，因為它與檢索增強生成（RAG）的工作方式相似。然而，有一個重要的細微之處。如果使用基本的RAG方法，其中計算用戶查詢的嵌入并使用該嵌入來檢索相關(guān)工具，會得到非常低的性能。這是因為完成用戶的查詢通常需要使用幾個輔助工具，如果輔助工具的嵌入與用戶查詢不相似，則簡單的RAG方法可能會忽略這些工具。例如，上圖中顯示的示例需要調(diào)用獲取電子郵件地址函數(shù)，即使用戶查詢只是詢問如何創(chuàng)建日歷邀請。

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

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

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

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

快速邊緣部署與量化

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

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

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

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

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

總結(jié)一下，本文介紹了TinyAgent，并展示了確實可以訓(xùn)練一個小型語言模型并用它來驅(qū)動處理用戶查詢的語義系統(tǒng)。特別是，考慮了一個類似Siri的Mac助手作為驅(qū)動應(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ù)上實現(xiàn)了80.06%和84.95%的成功率，超過了GPT-4-Turbo的79.08%。

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

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

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