技術概要：AsyncTool

問題定義

大規模言語モデル（LLM）に基づくエージェントは、複雑な多段階タスクにおいて外部ツールを活用する能力を実証してきたが、既存の評価ベンチマークはツールの呼び出しにおける時間的側面を大きく見落としている。具体的には、現在の評価はツールの即時応答を前提とし、単一タスク設定に限定されている。しかし、実世界アプリケーションでは、エージェントはツールの応答遅延に直面し、複数の同時タスクを管理しなければならない。既存のベンチマークは、アイドル待機時間を活用して他の独立したタスクを進展させるエージェントの能力を評価できておらず、著者はこの能力を非同期ツール呼び出しと命名している。さらに、遅延および順序が入れ替わる可能性のあるツールフィードバックを伴う同時タスクを評価するための標準化された指標とプロトコルが存在しない。

手法

AsyncTool ベンチマーク

著者は、遅延を伴うツールフィードバックを有するインタラクティブなマルチタスク環境において、LLM ベースのエージェントを評価するために設計された最初のベンチマークであるAsyncToolを提案する。このベンチマークは、以下の現実的な条件をシミュレートする：

1. 同時実行：エージェントは複数の異種タスクを同時に受け取る。
2. 遅延フィードバック：ツール呼び出しには遅延が生じ、結果は即時に返されない。
3. 依存関係の追跡：タスクにはステップ内の依存関係が含まれており、エージェントはアイドル待機や結果の幻覚に陥ることなく、状態を追跡し、適切にタスク間を切り替える必要がある。

データ構築

データセットは、高品質と多様性を確保するための 4 段階パイプラインを通じて構築される：

1. データ収集：既存のベンチマークであるNESTFULおよびBFCLv3から生データを抽出し、12 のツールと 358 の単一タスクインスタンスを生成する。
2. 粗い再構築：Gemini 2.5 Proを用いて、タスク記述を再構築し、ツールと整合した厳密に順序付けられた関数呼び出しの軌跡を生成する。
3. 微細な注釈付け：人間の注釈者が、実行の有効性、依存関係の準拠、および引数の正しさを検証する。初期条件の誤解や無効な関数形式などのエラーを修正する。
4. マルチタスク構成：単一タスクインスタンスを重み付きランダムサンプリングを用いてマルチタスクシナリオ（2 タスクおよび 3 タスク）に組み合わせる。最終的なデータセットは、さまざまなタスクタイプ（例：データ管理、ファイルシステム、取引）および依存関係構造（SIMILAR および CROSS の組み合わせ）を網羅する712 のインスタンスから構成される。

評価プロトコル

パフォーマンスは 3 つの異なるレベルで評価される：

• ステップレベル：関数およびパラメータの一致に対する F1 スコアを用いて、基本的なツール呼び出し能力（形式、ツール選択、パラメータの正しさ）を評価する。
• サブタスクレベル：個々のサブタスクにおける軌跡の完了と環境の一貫性（隠れ状態の一致）を測定する。
• タスクレベル：タスク内のすべてのサブタスクが正しく完了されることを要求する、エンドツーエンドの成功を評価する。

さらに、著者は効率指向の指標、具体的にはタスク間での切り替え頻度を測定するSame-task Streakを導入する。低いストリークは優れたインターリーブ能力（アイドル時間の活用）を示し、高いストリークはエージェントが待機に陥っているか、コンテキストの切り替えに失敗している可能性を示唆する。

主要な結果

著者は、GPT-4.1、GPT-4o、Gemini 2.5 Pro などのクローズドソースモデルおよび各種オープンソースモデルを含む19 のモデルを AsyncTool で評価した。

• パフォーマンスの低下：同期設定と比較して、非同期実行は明確なパフォーマンスの低下をもたらす。遅延フィードバックは、特にタスク状態と依存関係の維持において、多大な課題を提起する。
• モデル比較：GPT-4.1が総合スコア 38.06 で最高を記録し、オープンソースモデルの中ではDeepSeek-V3.1-Terminus（28.93）がこれに続いた。クローズドソースモデルは、特にタスクレベルの指標において、一般的にオープンソースの対応モデルを上回った。
• 精度と効率のトレードオフ：分析は、タスク精度とスケジューリング効率の間にトレードオフが存在することを明らかにする。
  • 高性能モデル（例：GPT-4.1）は、高い精度とコンパクトなタスク切り替え（低い Same-task Streak）のバランスを取り、アイドル時間を効果的に活用する。
  • 一部のモデルは、依存関係の違反やツールの混同により、頻繁な切り替えを示すが精度は低い。
  • 他のモデルは高い精度を示すが、インターリーブが不十分（高い Same-task Streak）であり、待機期間を活用することに苦労していることを示している。
• 失敗モード：一般的なエラーには以下が含まれる：
  • 時間的推論の欠如：現在のツールの結果が返る前にタスクの次のステップを早急に実行し、しばしば幻覚化されたパラメータにつながる。
  • タスクの軽視：最も最近提示されたタスクに集中し、以前のタスクを無視する。
  • ツールの混同：あるタスク用 intend されたツールを別のタスクに適用する。
  • 依存関係の違反：前提となるステップをスキップするか、状態を誤って管理する。

意義と貢献

本論文は、以下の貢献を主張する：

1. AsyncTool ベンチマーク：遅延を伴うツールフィードバック、同時マルチタスク実行、多段階関数呼び出し、および依存関係-aware な調整を同時に考慮する新しいベンチマーク。
2. 多様なデータセット：ハイブリッドなデータ進化戦略を通じて構築された高品質な非同期マルチタスキングデータセットで、多様なシナリオと依存関係構造を網羅する。
3. 多レベル評価：ステップ、サブタスク、およびタスクレベルでのパフォーマンスを評価する包括的なプロトコルと、タスクのインターリーブを分析するための効率指標を組み合わせる。
4. 実証的洞察：時間的調整において現在のエージェントが苦労していることを特定する広範な実験。その発見は、効果的な非同期ツールの使用には、単に頻繁な切り替えだけでなく、依存関係の追跡と状態維持と切り替えを調整する能力が必要であることを浮き彫りにする。

著者は、時間的調整が将来のツール利用エージェントにとって不可欠な能力であり、AsyncTool が時間的推論と効率性の強化されたシステムを開発するための必要なテストベッドを提供すると結論づけている。

限界

本論文は、主に 2 つの限界を認めている：

1. データセットの範囲：データセットは NESTFUL および BFCLv3 から再構築されているため、ツールとシナリオの範囲はこれらのソースによって本質的に制約される。
2. 構築コスト：データ再構築における高性能モデル（Gemini 2.5 Pro）への依存と、広範な人間による検証の必要性により、データセット構築プロセスはコストが高く、手動修正を必要とする生成エラーを導入する可能性がある。