VAKRA 基準測試分析：代理推理、工具使用與失效模式

TL;DR

Hugging Face 發布了 VAKRA 基準測試，這是一個包含 62 個領域中超過 8,000 個本地託管 API 的可執行套件，用於測試 AI 代理在組合推理、工具選擇、多跳工作流和策略合規性方面的表現；目前的尖端模型表現不佳，暴露了實際部署中的關鍵差距。

什麼是 VAKRA？

VAKRA 是一個以工具為基礎的可執行基準測試，旨在評估 AI 代理在企業級環境中進行推理和行動的能力。與傳統的孤立技能測試不同，VAKRA 通過要求代理執行完整的多步驟工作流並提供執行軌跡以供驗證，來衡量跨 API 和文件的組合推理能力。

關鍵統計數據：

  • 8,000+ 由真實資料庫支援的本地託管 API。
  • 62 個領域，涵蓋商業智能、儀表板和文件檢索。
  • 任務涉及 3–7 步推理鏈，將結構化 API 調用與非結構化文件檢索相結合。
  • 四個能力組測試不同的技能集（API 鏈接、工具選擇、多跳推理，以及帶有策略約束的多源推理）。

該基準測試、數據集、排行榜和代碼已在 Hugging Face 和 GitHub 上公開。

能力 1 – 使用商業智能 API 的 API 鏈接

  • 實例： 橫跨 54 個領域的 2,077 個實例。
  • 工具集： SLOT‑BIRD（7 個通用工具）和 SEL‑BIRD（擴展的領域特定獲取器）。
  • 工作流： 從 get_data(tool_universe_id) 開始以加載輕量級預覽並配置伺服器，隨後進行 1–12 次鏈接工具調用以進行數據過濾和選擇。
  • JSON 請求範例（簡化版）：
    {
  "query": "Which football team has a build‑up play speed of 31 …?",
  "tool_calls": [
    {"name": "get_data", "arguments": {"tool_universe_id": "..."}, "label": "retrieved_data_1"},
    {"name": "select_data_equal_to", "arguments": {"data_label": "retrieved_data_1", "key_name": "play_speed", "value": 31}, "label": "FILTERED_DF_0"},
    ..
  ],
  "answer": "FC Barcelona"
}
  • 挑戰： 從龐大且動態的集合中選擇正確的工具，並提供許多選填參數。

能力 2 – 使用儀表板 API 的工具選擇

  • 實例： 橫跨 17 個領域的 1,597 個實例。
  • 工具集： REST‑BIRD，通過 FastAPI 提供並由 MCP 伺服器封裝。
  • 領域規模： 每個領域包含 6–328 個工具（平均 116 個）。
  • 約束： OpenAI 對工具列表有 128 個項目的限制，這迫使代理必須實現篩選機制；基準測試使用簡單的啟發式篩選器。
  • 目標： 為查詢識別單一正確的端點式 API。

能力 3 – 使用儀表板 API 的多跳推理

  • 實例： 橫跨 38 個領域的 869 個實例。
  • 要求： 1–5 次邏輯跳轉；每次跳轉必須調用正確的 API 並傳遞適當的參數。
  • 觀察： 隨著跳轉深度增加，準確率急劇下降，證實了鏈接多次 API 調用是當前模型的主要難點。

能力 4 – 多跳、多源推理與策略遵循

  • 實例： 橫跨 41 個領域的 644 個實例。
  • 特點：
    • 多源： 查詢可能需要如 API → 文件檢索 (RAG) → API 的序列，並通過來源去污染確保每次跳轉的答案僅能從單一來源獲取。
    • 多輪： 提供對話上下文；代理只能回答當前輪次。
    • 工具使用策略： 文本形式的約束規定了可以使用哪些知識來源（例如，「技術查詢僅使用文件檢索器」）。
  • 策略執行： 基準代理在提示詞前添加一個約束句子；開發者可以實現更複雜的檢查。

評估框架

VAKRA 使用一種以執行為中心的瀑布式流水線，從工具執行正確性和最終答案質量兩方面驗證代理。

  1. 策略遵循（僅限能力 4） – 通過程序驗證。
  2. 工具調用序列驗證 – 預測的調用被執行；結果與地面真值（ground-truth）進行比較。
    • 如果精確匹配失敗，則使用基於 LLM 的評估器（改編自 CRAG）檢查預測的軌跡是否檢索了所有所需信息，允許其他有效但不同的工具序列。
  3. 最終響應評估 – LLM 裁判確認答案是基於已執行的工具輸出，並在事實上與參考答案匹配。

評分

四個能力權重相等：

$$\text{Leaderboard Score}=\frac{1}{4}\sum_{i=1}^{4}\text{Capability}_i$$

  • 能力 1-3： 簡單準確率（正確查詢數 / 總查詢數）。
  • 能力 4： 多源查詢的權重為兩倍，以反映更高的難度。

錯誤分析 – 代理在哪裡失效

分析按首次失效點對錯誤進行分類：

  1. 工具選擇錯誤。
  2. 缺失或幻覺參數。
  3. 參數值錯誤。
  4. 最終響應錯誤或無根據。

API 鏈接 (能力 1)

  • 最佳模型： GPT‑OSS‑120B，主要是由於對工具 Schema 的卓越理解以及對選填參數的穩健處理。
  • 錯誤模式： 使用 SLOT‑BIRD 集合的模型在參數命名方面遇到困難；使用 SEL‑BIRD 的模型因為工具集較大而犯了更多的工具選擇錯誤。

儀表板工具選擇 (能力 2)

  • 最佳模型： Gemini‑3‑flash‑preview，在所有錯誤類別中表現優於其他模型。
  • 主要錯誤： 工具選擇失敗和參數值錯誤；即使工具調用成功，合成最終答案仍然是一個挑戰。

多跳推理 (能力 3)

  • 趨勢： 準確率隨跳轉深度下降（1 跳 > 2 跳 > 3+ 跳）。所有模型都顯示出相同的模式，證實了鏈接多次 API 調用會放大誤差傳播。

多跳多源與策略 (能力 4)

  • 混合跳轉： 需要同時進行 API 調用和文件檢索的實例最難；與純 API 或純 RAG 跳轉相比，性能大幅下降。
  • 策略影響： 模型通常對策略的遵循能力較差；當策略限制了最相關的來源時，大多數模型會出現明顯的準確率下降。Granite‑4.0‑h‑Small‑32B 是一個例外，表現出較少的退化。
  • 具體觀察： GPT‑OSS‑120B 經常跳過單跳 RAG 調用，而是從內部知識回答；Gemini‑3‑flash‑preview 在 2 跳 API-RAG 組合上表現出色，可能利用了其在儀表板 API 上的優勢。

對代理開發的啟示

  • 工具能力 ≠ 可靠性： 選擇正確的 API 只是問題的一部分；代理還必須管理參數、執行多步驟工作流並尊重外部約束。
  • 以執行為中心的指標至關重要： 傳統的僅限答案的評分掩蓋了中間步驟的失敗；VAKRA 基於軌跡的評估揭示了這些差距。
  • 策略處理是一個弱點： 實際部署通常會施加合規或安全策略；當前模型很難將此類約束納入其推理中。
  • 基準測試作為開發目標： 通過揭示代理在哪裡失效，VAKRA 為改進工具使用模組、篩選機制和具備策略意識的提示詞提供了具體的路線圖。

如何嘗試 VAKRA

在基準測試中運行您的代理，以發現它是在工具選擇、多跳推理還是策略合規性方面失敗，並根據 VAKRA 提供的詳細錯誤細分進行迭代。

Sources