Hugging Face 在代理工具上的開放模型基準測試

Hugging Face 在代理工具上的開放模型基準測試

Hugging Face 開發了一套基準測試框架，不僅衡量程式碼代理是否能得到正確答案，還會測量達成答案所需的努力——以 token、時間與回合數來計算。以 transformers 套件作為案例研究，研究顯示，為代理優化軟體（例如加入 CLI 或精選文件）可以大幅降低大型模型的延遲，但同時可能為較小模型帶來模糊性與失敗風險。

衡量代理效率超越最終答案

傳統基準測試往往只關注最終輸出，掩蓋了運行成本與可靠性。Hugging Face 主張，即使兩個代理得到相同結果，它們在成本、延遲與 token 使用上也可能有天壤之別。例如，一個代理可能會寫出長達 40 行的 Python 程式碼來執行情感分類，另一個則可能只需一條 CLI 指令。

為了捕捉這些細微差異，基準測試框架會在三種不同的環境存取層級上評估代理：

  • Bare：代理僅透過 pip install transformers 安裝套件。
  • Clone：代理在工作目錄中檢出套件的完整原始碼。
  • Skill：代理獲得一個封裝好的「Skill」，內含精選的 CLI 文件與任務範例，已載入其上下文中。

模型大小對工具採用的影響

研究揭示，開放模型的大小與能力會導致截然不同的影響：

大型開放模型

對於高效能模型而言，任務完成率往往接近 100%，因此「match %」的指標價值較低。重點轉向所需的努力。研究發現，為大型模型引入專屬 CLI 與 Skill 後，任務的中位執行時間下降，因為它們從除錯 Python 程式碼轉為使用精簡的 CLI 指令。

然而，這種效率伴隨著 token 的增加。在 clone 變體中，代理常會閱讀新的 CLI 實作與範例腳本以學習介面，導致中位輸入從約 4k token 增至 6.4k token。這筆探索成本通常是一次性的，於實際使用時會在多個任務間攤銷。

小型開放模型

對於較小的模型，「match %」仍是關鍵指標。研究指出，雖然良好的工具介面必不可少，但過度新增功能可能適得其反。例如，Qwen3-4B 模型在加入 CLI 後的 clone 層級，token 消耗從約 2.4k 暴增至約 23k，因為它一次性讀取大量原始碼卻未提升準確度。

更嚴重的是，部分小型模型的正確率會崩潰。Qwen3-14B 模型在情感分類任務中，clone 變體的 match rate 為 100%，但在使用 Skill 變體時跌至 0%。追蹤顯示，模型誤將 Skill 文件當作可直接呼叫的工具（例如 transformers(command="classify", ...)），而非需透過 bash 執行的指令，導致它宣稱任務不可完成。

技術實作與「標記」

為了在原始指標之外分析代理行為，框架使用「標記」——具名的模式，用以匹配執行過程中的特定行為。針對 transformers 研究，使用了兩個主要標記：

  • cli：當代理呼叫 transformers 命令列工具時觸發。
  • pipeline：當代理使用高階的 pipeline(...) Python API 時觸發。

資料顯示，大型模型較傾向於透過 Skill 層級利用新上下文（CLI），採用率為 55.3%，而較小模型則更依賴於訓練資料中記憶的 API 模式。

給函式庫維護者的關鍵建議

對軟體開發者而言，最主要的結論是：面向代理的 API 必須在不同模型規模下進行評估。對強大模型有助於簡化工作流程的功能，可能在較小模型上引入模糊或觸發失敗模式。為降低風險，Hugging Face 建議使用 Upskill 等工具，僅在能顯著提升小模型效能時，才由強模型生成與驗證 Skills。

工具與可取得性

此基準測試框架以 CLI agent-eval 實作，設計為以設定檔為基礎，可適配任何可從命令列操作的函式庫。系統利用 Hugging Face Jobs 在相同硬體上平行執行，並將結果與追蹤資料存於 Hugging Face Buckets，供 Hub 的 agent-traces 觀察器進行分析。

摘要： Hugging Face 推出全新基準測試框架，用以評估不同模型規模與函式庫版本對程式碼代理使用軟體工具時的效率與成功率的影響。

標題： Hugging Face 在代理工具上的開放模型基準測試

Sources