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

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

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

一個參數內存顯著較少的小型語言模型能否模擬這些較大語言模型的這種出現能力？

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

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

教LLMs進行功能調用

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

和2被一起獲取以獨立檢索Sid和Lutfi的電子郵件地址。在執行每個任務后，結果被轉發到創建日歷事件的任務。在執行任務3之前，LLMCompiler會用實際值替換占位符變量（例如，在任務

中的變量1和$2）。

如上所述，主要關注的是將用戶查詢轉換為一系列函數調用以完成任務的應用程序。在這種應用程序中，模型不需要自己編寫函數定義，因為這些函數（或API）大多是預定義的并且已經可用。因此，模型需要做的是確定（i）調用哪些函數，（ii）相應的輸入參數，以及（iii）根據函數調用之間所需的相互依賴關系確定調用這些函數的正確順序（即函數編排）。

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

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

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

數據生成

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

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

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

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

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

為改進函數調用推理進行微調

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

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

在定義了評估指標之后，研究人員應用了LoRA對模型進行了3個時期的微調，使用了學習率為7e-5的80K個訓練示例，并根據驗證性能選擇了最佳檢查點。對于微調，提示不僅包括地面實況函數的描述（即地面實況計劃中使用的函數），還包括其他無關的函數作為負樣本。研究人員發現負樣本對教授模型如何為給定查詢選擇適當的工具特別有效，從而改善了訓練后的性能。此外，研究人員還包括了幾個上下文示例，展示了如何將查詢轉換為函數調用計劃。這些上下文示例是通過基于訓練數據中的用戶查詢的檢索增強生成（RAG）過程選取的。

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

使用 RAG 工具進行高效推理

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

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

前面討論過的微調的TinyAgent模型在其提示中包含了所有可用工具的描述。然而，這是相當低效的。可以通過僅根據用戶查詢包含相關工具的描述來顯著減小提示大小。例如，考慮上圖中顯示的示例，在該示例中，用戶要求創建一個與兩個人的日歷邀請相關的任務。在這種情況下，LLM只需要在其提示中包含獲取電子郵件地址和創建日歷事件的函數。

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

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

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

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

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

快速邊緣部署與量化

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

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

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

將所有內容整合起來

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

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

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

本文轉載自公眾號AIGC最前線   

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