深入了解 VAKRA：代理的推理、工具使用與失效模式

深入了解 VAKRA：代理的推理、工具使用與失效模式

概述

VAKRA 是一個以工具為基礎的執行基準測試，透過要求跨 API 與文件的組合推理，來衡量 AI 代理在企業級環境中的推理與行動能力。它的重要性在於揭示了表面層級的工具能力與可靠的端到端代理行為之間的差距，顯示出即使是強大的模型在處理多步驟工作流時也經常失敗。

任務描述

VAKRA 包含四種能力，每種能力都在一個可執行環境中測試一組獨特的技能，該環境擁有橫跨 62 個領域、超過 8,000 個本地託管的 API 以及與領域對齊的文件集。

能力 1：使用商業智能 API 進行 API 鏈接

此能力包含橫跨 54 個領域的 2,077 個測試實例，要求代理從 SLOT‑BIRD 和 SEL‑BIRD 集合中鏈接 1–12 個工具調用，從 JSON 數據源中推導答案。每個實例都以一個 get_data(tool_universe_id=id) 調用開始，該調用會初始化數據源並配置 MCP 伺服器以公開相應的工具集。

能力 2：使用儀表板 API 進行工具選擇

此能力包含橫跨 17 個領域的 1,597 個實例，使用擴展的 REST‑BIRD 集合，該集合包含透過 FastAPI 包裝並由 MCP 伺服器提供的端點式 API。代理必須從每個領域包含 6 到 328 個工具（平均 116 個）的特定領域集合中選擇正確的 API。OpenAI API 規範將工具列表限制在 128 個，因此需要一個篩選機制。

能力 3：使用儀表板 API 進行多跳推理

能力 3 部分包含取自 38 個學科領域的 869 個測試實例，同樣依賴 REST‑BIRD API 集合，但增加了多跳推理。問題要求一到五次邏輯跳躍，每次跳躍涉及從 API 調用中提取並結合支持性證據。

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

能力 4 包含橫跨 41 個領域的 644 個實例，建立在 REST‑BIRD API 集合的基礎上，並增加了每個領域的文件索引、多輪對話以及可選的工具使用策略。查詢可能需要來自 API、文件檢索器或兩者結合（API‑RAG‑API 模式）的信息。策略是純文本指令，限制代理在特定回合中可以使用哪些知識源。

評估框架

VAKRA 透過評估最終答案的正確性以及完整的工具執行軌跡的有效性來評估代理，獎勵透過有效推理過程獲得正確答案的代理。

評估指標

VAKRA 評估器針對預測的最終響應和相應的工具調用軌跡進行操作，在與地面真值（ground truth）相同的環境中執行預測的調用，以驗證中間輸出。評估遵循瀑布式流水線：對於能力 4 任務，首先檢查策略遵循情況；然後將預測的工具調用序列與地面真值進行比較；只有具有有效軌跡的樣本才會進入最終響應評估。

工具序列的正確性是透過執行每個預測的工具並將工具響應集與地面真值的響應集進行比較來確定的，允許替代但有效的調用。如果檢查結果不確定，則使用改編自 CRAG 框架的基於 LLM 的評估來判斷預測的軌跡是否在結構差異下檢索到了所有要求的資訊。最終響應由 LLM 判斷，以確保其基於預測的工具輸出並與地面真值答案在事實上保持一致。

分數按能力計算並取平均值以得出排行榜：排行榜分數 = (能力₁ + 能力₂ + 能力₃ + 能力₄) / 4。能力 1-3 是正確查詢的簡單平均值；能力 4 中，多源正確查詢的權重是僅 API 或僅 RAG 正確查詢的兩倍。

錯誤分析

錯誤分析使用階段式分類，將每次失敗歸因於第一個失效點：工具選擇、參數提供、參數值或最終響應落地。

失效階段隔離

透過將每個實例歸類為最早的失敗階段，錯誤被視為數據集的離散部分，避免了重複計算並提供了具解釋性的細分。

能力 1：使用商業智能 API 進行 API 鏈接

對於此能力中的 2,077 個樣本，GPT‑OSS‑120B 以大幅領先於其他模型，主要是因為對工具 Schema 的理解更好以及在填充可選參數方面的魯棒性。SLOT‑BIRD（1,477 個樣本）的錯誤主要集中在除 GPT‑OSS‑120B 以外的所有模型的錯誤工具參數名稱，而 SEL‑BIRD（600 個樣本）顯示的參數錯誤較少，但由於工具集更大且具動態性，工具選擇錯誤較多。

能力 2：使用儀表板 API 進行工具選擇

在 1,597 個樣本中，Gemini‑3‑flash‑preview 在所有錯誤類別中都優於其他模型。大量的工具選項導致工具選擇和參數值選擇頻繁出錯，而幻覺或跳過必要參數的情況較少。即使所有工具調用都是正確的，模型（特別是 Gemini‑3‑flash‑preview 和 Claude‑Sonnet‑4‑5）在從工具響應中綜合出正確答案方面仍面臨挑戰，這可以從錯誤圖表最右側的下降中得到證明。

多跳推理：跳躍深度對模型性能的影響

準確率隨著跳躍深度的增加而下降：模型在單跳問題上表現最好，在兩跳問題上性能下降，而在所有測試模型的三跳或更多跳問題上性能進一步下降。

多跳多源推理：混合跳躍對模型性能的影響

性能因交互類型而異：單次 API 調用（1-hop API）比多次 API 調用（2-hop API）更容易；加入文件檢索器（RAG 跳躍或混合 API-RAG 模式）會增加難度。在 1-hop RAG 問題上，GPT‑OSS‑120B 傾向於從參數化知識中返回答案而不是調用檢索器，這可能是因為問題集中於 Wikipedia 實體。Gemini‑3‑flash‑preview 在 2-hop API-RAG 模式上表現相對強勁，可能受益於其在儀表板 API 工具選擇方面的優勢。

策略對模型性能的影響

當策略限制訪問最相關的信息源時（「策略更新答案」），除 Granite‑4.0‑h‑Small‑32B 以外的所有模型都經歷了明顯的性能下降。模型要麼違反約束，要麼無法檢索到足夠的信息，有時雖然理解了策略但仍回答錯誤。這表明，雖然模型可以對工具和來源進行推理，但它們很難將外部約束納入該推理中——這是可靠的現實世界部署的一個關鍵要求。

結論

VAKRA 揭示了表面層級的工具能力與穩健的端到端代理可靠性之間的關鍵差距。雖然現代模型越來越能夠選擇 API 並執行孤立的工具調用，但基準測試顯示，單憑這些能力不足以進行現實世界的部署；當被要求在跨越 API、文件、對話上下文和策略要求的執行約束下進行組合推理時，模型經常會崩潰。

嘗試 VAKRA —— 你的代理在哪裡失效？

在 VAKRA 基準測試上測試你的代理，看看它在哪裡失敗——是工具選擇、多跳推理，還是策略約束。

👉 嘗試它並告訴我們你的代理學到了什麼

Sources