GAIA: 一個嚴苛的智慧體基準

HuggingFace發表於2024-07-09
AI智慧體

簡要概括

經過一些實驗，我們對 Transformers 智慧體構建智慧體系統的效能印象深刻，因此我們想看看它有多好！我們使用一個 用庫構建的程式碼智慧體 在 GAIA 基準上進行測試，這可以說是最困難、最全面的智慧體基準測試……最終我們取得了第一名的成績！

GAIA: 一個嚴苛的智慧體基準

什麼是智慧體？

一句話: 智慧體是基於大語言模型 (LLM) 的系統，可以根據當前用例的需要呼叫外部工具，也可以不呼叫，並根據 LLM 的輸出進行後續步驟的迭代。工具可以包括從 Web 搜尋 API 到 Python 直譯器的任何東西。

形象類比: 所有程式都可以描述為圖表。先做 A，再做 B。If/else 分支是圖中的岔路口，但它們不會改變圖的結構。我們將 智慧體 定義為: LLM 輸出將改變圖結構的系統。智慧體決定呼叫工具 A 或工具 B 或不呼叫任何工具，它決定是否再執行一步: 這些都會改變圖的結構。您可以將 LLM 整合到一個固定的工作流中，比如在 LLM judge 中，但這並不是一個智慧體系統，因為 LLM 的輸出不會改變圖的結構。

下面是兩個執行 檢索增強生成 的不同系統的插圖: 一個是經典的，其圖結構是固定的。但另一個是智慧體的，圖中的一個迴圈可以根據需要重複。

Classical vs Agentic RAG

智慧體系統賦予大語言模型 (LLM) 超能力。詳情請閱讀 我們早期關於 Transformers Agents 2.0 釋出的部落格。

GAIA 是智慧體最全面的基準測試。GAIA 中的問題非常難，突出了基於 LLM 的系統的某些困難。

以下是一個棘手問題的例子:

在 2008 年的畫作《烏茲別克的刺繡》中展示的水果中，哪些是 1949 年 10 月海洋班輪早餐選單的一部分，該班輪後來作為電影《最後的航程》的漂浮道具使用？請將這些水果按逗號分隔的列表給出，並根據它們在畫作中的排列順時針順序，從 12 點位置開始。使用每種水果的複數形式。

你可以看到這個問題涉及幾個難點:

  • 以約束格式回答。
  • 多模態能力，需要從影像中讀取水果。
  • 需要收集多個資訊，有些資訊依賴於其他資訊:
    • 圖片中的水果
    • 用作《最後的航程》漂浮道具的海洋班輪的身份
    • 上述海洋班輪 1949 年 10 月的早餐選單
  • 上述內容迫使正確的解決路徑使用幾個鏈式步驟。

解決這個問題需要高水平的計劃能力和嚴格的執行力，這恰恰是 LLM 難以應對的兩個領域。

因此，它是測試智慧體系統的絕佳測試集！

在 GAIA 的 公開排行榜 上，GPT-4-Turbo 的平均成績不到 7%。最高的提交是一種基於 Autogen 的解決方案，使用了複雜的多智慧體系統並利用 OpenAI 的工具呼叫功能，達到了 40%。

下面讓我們繼續 🥊

Let's fight

構建合適的工具 🛠️

我們使用了三種主要工具來解決 GAIA 問題:

a. 網頁瀏覽器

對於網頁瀏覽，我們主要複用了 Autogen 團隊的提交 中的 Markdown 網頁瀏覽器。它包含一個儲存當前瀏覽器狀態的 Browser 類，以及幾個用於網頁導航的工具，如 visit_page 、page_down 或 find_in_page 。這個工具返回當前視口的 Markdown 表示。與其他解決方案 (如截圖並使用視覺模型) 相比，使用 Markdown 極大地壓縮了網頁資訊，這可能會導致一些遺漏。然而，我們發現該工具整體表現良好，且使用和編輯都不復雜。

注意: 我們認為，將來改進這個工具的一個好方法是使用 selenium 包載入頁面，而不是使用 requests。這將允許我們載入 JavaScript (許多頁面在沒有 JavaScript 的情況下無法正常載入) 並接受 cookies 以訪問某些頁面。

b. 檔案檢查器

許多 GAIA 問題依賴於各種型別的附件檔案，如 .xls 、.mp3 、.pdf 等。這些檔案需要被正確解析。我們再次使用了 Autogen 的工具，因為它們非常有效。

非常感謝 Autogen 團隊開源他們的工作。使用這些工具使我們的開發過程加快了幾周！🤗

c. 程式碼直譯器

我們不需要這個工具，因為我們的智慧體自然會生成並執行 Python 程式碼: 詳見下文。

程式碼智慧體 🧑‍💻

為什麼選擇程式碼智慧體？

如 Wang et al. (2024) 所示，讓智慧體以程式碼形式表達其操作比使用類似 JSON 的字典輸出有幾個優勢。對我們來說，主要優勢是 程式碼是表達複雜操作序列的非常最佳化的方式。可以說，如果有比我們現有程式語言更好地嚴格表達詳細操作的方法，它將成為一種新的程式語言！

考慮他們論文中給出的這個例子:

Code agents are just more intuitive than JSON

它突出了使用程式碼的幾個優點:

  • 程式碼操作比 JSON 簡潔得多。
    • 需要執行 4 個並行的 5 個連續操作流？在 JSON 中，你需要生成 20 個 JSON blob，每個在其獨立的步驟中; 而在程式碼中，這隻需 1 步。
    • 平均而言，論文顯示程式碼操作需要比 JSON 少 30% 的步驟，這相當於生成的 tokens 減少了 30%。由於 LLM 呼叫通常是智慧體系統的主要成本，這意味著你的智慧體系統執行成本減少了約 30%。
  • 程式碼允許重用常見庫中的工具
  • 使用程式碼在基準測試中表現更好，原因有二:
    • 它是一種更直觀的表達操作的方式
    • LLM 的訓練資料中有大量程式碼，這可能使它們在編寫程式碼方面比編寫 JSON 更流暢。

我們在 agent_reasoning_benchmark 上的實驗中證實了這些點。

在我們最近的構建 Transformers 智慧體的實驗中，我們還觀察到了一些額外的優勢:

  • 在程式碼中儲存一個命名變數要容易得多。例如，需要儲存一個由工具生成的岩石影像以供以後使用？
    • 在程式碼中沒有問題: 使用 “rock_image = image_generation_tool(“A picture of a rock”)” 將變數儲存在你的變數字典中的 “rock_image” 鍵下。之後 LLM 可以透過再次引用 “rock_image” 來在任何程式碼塊中使用其值。
    • 在 JSON 中，你需要做一些複雜的操作來建立一個名稱來儲存這個影像，以便 LLM 以後知道如何再次訪問它。例如，將影像生成工具的任何輸出儲存為 “image_{i}.png”，並相信 LLM 稍後會理解 image_4.png 是記憶體中之前呼叫工具的輸出？或者讓 LLM 也輸出一個 “output_name” 鍵來選擇儲存變數的名稱，從而使你的操作 JSON 的結構複雜化？
  • 智慧體日誌可讀性大大提高。

Transformers 智慧體的 CodeAgent 實現

LLM 生成的程式碼直接執行可能非常不安全。如果你讓 LLM 編寫和執行沒有防護措施的程式碼，它可能會產生任何幻覺: 例如，它可能認為所有你的個人檔案需要被《沙丘》的傳說副本覆蓋，或者認為你唱《冰雪奇緣》主題曲的音訊需要分享到你的部落格上！

所以對於我們的智慧體，我們必須使程式碼執行安全。通常的方法是自上而下: “使用一個功能齊全的 Python 直譯器，但禁止某些操作”。

為了更安全，我們選擇了相反的方法， 從頭開始構建一個 LLM 安全的 Python 直譯器。給定 LLM 提供的 Python 程式碼塊，我們的直譯器從 Python 模組 ast 提供的 抽象語法樹表示 開始。它按樹結構逐個執行節點，並在遇到任何未明確授權的操作時停止。

例如，一個 import 語句首先會檢查匯入是否在使用者定義的 authorized_imports 列表中明確提及: 如果沒有，則不執行。我們包括了一份預設的 Python 內建標準函式列表，如 print 和 range 。任何在此列表之外的內容都不會執行，除非使用者明確授權。例如， open (如 with open("path.txt", "w") as file: ) 不被授權。

遇到函式呼叫 ( ast.Call ) 時，如果函式名是使用者定義的工具之一，則工具會被呼叫並傳遞呼叫引數。如果是先前定義並允許的其他函式，則正常執行。

我們還做了幾個調整以幫助 LLM 使用直譯器:

  • 我們限制執行操作的數量以防止 LLM 生成的程式碼中出現無限迴圈: 每次操作時計數器增加，如果達到一定閾值則中斷執行。
  • 我們限制列印輸出的行數，以避免用垃圾填滿 LLM 的上下文長度。例如，如果 LLM 讀取一個 100 萬行的文字檔案並決定列印每一行，那麼在某個點上這個輸出會被截斷，以防止智慧體記憶體爆炸。

基礎多智慧體協調

網頁瀏覽是一項非常上下文豐富的活動，但大多數檢索到的上下文實際上是無用的。例如，在上面的 GAIA 問題中，唯一重要的資訊是獲取畫作《烏茲別克的刺繡》的影像。周圍的內容，比如我們找到它的部落格內容，通常對解決更廣泛的任務無用。

為了解決這個問題，使用多智慧體步驟是有意義的！例如，我們可以建立一個管理智慧體和一個網頁搜尋智慧體。管理智慧體應解決高階任務，並分配具體的網頁搜尋任務給網頁搜尋智慧體。網頁搜尋智慧體應僅返回有用的搜尋結果，以避免管理智慧體被無用資訊干擾。

我們在工作流程中建立了這種多智慧體協調:

  • 頂級智慧體是一個 ReactCodeAgent。它天生處理程式碼，因為它的操作是用 Python 編寫和執行的。它可以訪問以下工具:
    • file_inspector 讀取文字檔案，帶有一個可選的 question 引數，以便根據內容只返回對特定問題的答案，而不是整個檔案內容。
    • visualizer 專門回答有關影像的問題。
    • search_agent 瀏覽網頁。更具體地說，這個工具只是一個網頁搜尋智慧體的包裝器，這是一個 JSON 智慧體 (JSON 在嚴格的順序任務中仍然表現良好，比如網頁瀏覽，其中你向下滾動，然後導航到新頁面，等等)。這個智慧體可以訪問網頁瀏覽工具:
      • informational_web_search
      • page_down
      • find_in_page
      • …… (完整列表 在這行)
    • file_inspector 讀取文字檔案，帶有一個可選的 question 引數，以便根據內容只返回對特定問題的答案，而不是整個檔案內容。
    • visualizer 專門回答有關影像的問題。
    • search_agent 瀏覽網頁。更具體地說，這個工具只是一個網頁搜尋智慧體的包裝器，這是一個 JSON 智慧體 (JSON 在嚴格的順序任務中仍然表現良好，比如網頁瀏覽，其中你向下滾動，然後導航到新頁面，等等)。這個智慧體可以訪問網頁瀏覽工具:

將智慧體作為工具嵌入是一種簡單的多智慧體協調方法，但我們想看看它能走多遠——結果它能走得相當遠！

規劃元件 🗺️

目前有 亂糟糟的一堆 規劃策略，所以我們選擇了一個相對簡單的預先計劃工作流程。每隔 N 步，我們生成兩件事情:

  • 我們已知或可以從上下文中推匯出的事實摘要和需要發現的事實
  • 基於新觀察和上述事實摘要，逐步制定解決任務的計劃

可以調整引數 N 以在目標用例中獲得更好的效能: 我們為管理智慧體選擇了 N=2，為網頁搜尋智慧體選擇了 N=5。

一個有趣的發現是，如果我們不提供計劃的先前版本作為輸入，得分會提高。直觀的解釋是，LLM 通常對上下文中任何相關資訊有強烈的偏向。如果提示中存在先前版本的計劃，LLM 可能會大量重複使用它，而不是在需要時重新評估方法並重新生成計劃。

然後，將事實摘要和計劃用作額外的上下文來生成下一步操作。規劃透過在 LLM 面前展示實現目標的所有步驟和當前狀態，鼓勵 LLM 選擇更好的路徑。

結果 🏅

這是我們提交的最終程式碼。

我們在驗證集上得到了 44.2% 的成績: 這意味著 Transformers 智慧體的 ReactCodeAgent 現在總體排名第一，比第二名高出 4 分！ 在測試集中，我們得到了 33.3% 的成績，排名第二，超過了微軟 Autogen 的提交，並且在硬核的第 3 級問題中獲得了最高平均分。

我們做到了！

這是一個支援 程式碼操作效果更好 的資料點。鑑於其效率，我們認為程式碼操作很快將取代 JSON/OAI 格式，成為智慧體記錄其操作的標準。

據我們所知，LangChain 和 LlamaIndex 不支援程式碼操作，微軟的 Autogen 對程式碼操作有一些支援 (在 docker 容器中執行程式碼)，但它看起來是 JSON 操作的附屬品。因此，Transformers Agents 是唯一將這種格式作為核心的庫！

下一步

希望你喜歡閱讀這篇部落格！工作才剛剛開始，我們將繼續改進 Transformers Agents，從多個方面入手:

  • LLM 引擎: 我們的提交使用了 GPT-4o (不幸的是)， 沒有任何微調。我們的假設是，使用經過微調的 OS 模型可以消除解析錯誤，並獲得更高的分數！
  • 多智慧體協調: 我們的協調方式較為簡單，透過更無縫的協調，我們可能會取得更大的進展！
  • 網頁瀏覽器工具: 使用 selenium 包，我們可以擁有一個透過 cookie 橫幅並載入 JavaScript 的網頁瀏覽器，從而讀取許多當前無法訪問的頁面。
  • 進一步改進規劃: 我們正在進行一些消融測試，採用文獻中的其他選項，看看哪種方法效果最好。我們計劃嘗試現有元件的替代實現以及一些新元件。當我們有更多見解時，會發布我們的更新！

請在未來幾個月關注 Transformers Agents！🚀

現在我們已經建立了智慧體的內部專業知識，歡迎隨時聯絡我們的用例，我們將很樂意提供幫助！🤝

英文原文: https://hf.co/blog/beating-gaia

原文作者: Aymeric Roucher, Sergei Petrov

譯者: innovation64

相關文章