UCSBとLinkedInの研究者が、AIエージェントに自らのツール呼び出しを予測させるよう訓練

Why it matters

Tool latency keeps multi-step agents from feeling interactive. Self-speculation could hide part of that wait without serving a second model, but production gains will depend on exact-match rates, API costs and safeguards for state-changing actions.

Jiabao Ji, Yujian Liu and Li An、3名のUC Santa Barbaraの研究者でLinkedInのインターンとして働いている彼らは、検索エンジン、データベース、外部APIに依存するシステムで増大する遅延要因を取り除く試みとして、自分自身の次のツール呼び出しを予測し事前実行するようにAIエージェントを訓練しました。

研究者らはその手法を7月28日のarXivの論文で記述しており、共同執筆者にはLinkedInの研究者Rohit Jain、Gungor Polatkan、Siyu ZhuとUCSBのコンピュータサイエンス教授Shiyu Changが含まれます。DAIR.AIは7月30日にXでこの研究を紹介しました。

JiはChangの指導を受けるUCSBの博士課程4年生です。彼の以前の研究インターンシップにはAdobe Research、MetaのGenAI Llamaグループ、Apple AI/MLがあり、その後2026年にLinkedInのCoreAIグループでの業務に従事しました。Liuも同じくChangの指導を受ける博士課程4年生で、以前はAdobe Research、MIT-IBM Watson AI Lab、AMD GenAIで働いていました。彼らの新しい論文は、エージェントに正しくツールを選ばせる訓練を超え、いつその呼び出しを開始できるかに焦点を移しています。

One model, two jobs

ツールを使うエージェントはテキスト生成と外部システムの待機を交互に行います。検索リクエスト、データベース検索、サブエージェントの呼び出しはモデル自身のトークン生成よりも時間がかかることがあり、高価な推論ハードウェアが遊休状態になり、能力のあるエージェントでも動作が遅く感じられます。

推測的ツール実行はそのギャップを埋めようとします。エージェントが推論を続けている間に、スペキュレータが次の構造化された呼び出し（ツール名と引数を含む）を予測して早めにリクエストを開始します。予測がエージェントが最終的に出す呼び出しと完全に一致すれば、システムはその結果を再利用します。不一致であれば、推測された作業は破棄されなければなりません。

従来のアプローチは一般にその予測を小さなドラフトモデルに割り当てるか、キャッシュしたトレースから可能性の高いアクションを取得していました。UCSBとLinkedInの研究者らは、これらのシステムが「スペキュレータ - エージェントギャップ」を生むと論じています：ドラフトモデルはエージェントが行う可能性のあることを近似するが、配備されたエージェントのポリシーと正確に一致しない、という点です。追加のモデルはまた、サービング時に独自の重みとKVキャッシュを必要とします。

彼らのセルフ・スペキュレーティング設計は両方の役割を一つの言語モデルに与えます。エージェントモードでは、モデルはタスクを推論し通常どおりツールを呼び出します。スペキュレータモードでは、部分的な軌跡と次の構造化された呼び出しを予測する短いサフィックスを受け取ります。両モードはモデルのパラメータを共有し、同じプレフィックスKVキャッシュを再利用できます。

研究者らは交互の強化学習更新を通じて両モードを訓練しました。各バッチのエージェントロールアウトは、現在のモデルが実際に選択した呼び出しの新しい例を生成します。その呼び出しが次にそのモデルの推測訓練のターゲットとなります。最終的な訓練スケジュールでは、エージェント更新を4回行った後にスペキュレータ更新を8回行い、訓練がモードを切り替えるたびにオプティマイザの状態をリセットしました。

その分離は重要でした。1対1の更新スケジュールでは、アブレーションで使用した3つの検索ベンチマークの平均でHit@1スコア31.8、タスク成功率10.3を記録しました。4対8のスケジュールは同じ反復予算下でHit@1 55.2、タスク成功率26.1に達しました。

The benchmark gains

研究者らは4 billion-parameterのQwen3とQwen3.5モデルで手法をテストしました。評価は検索用にHotpotQA、MuSiQue、BrowseComp-Plusをカバーし、会話型API利用のためにtau-benchの航空券と小売のドメインも含めました。

Qwen3-4Bでは、スーパーバイズドファインチューニング後の平均次呼び出しHit@1が44.1から、共同強化学習段階後に61.2に上昇しました。Qwen3.5-4Bは48.9から66.3に改善しました。Hit@1成功はツール名と完全な引数辞書の両方が完全一致することを要求しました。

報告された下流タスク成功率の平均も横ばいかわずかに増加しました。Qwen3-4Bはスーパーバイズドファインチューニング後26.6から強化学習後27.7に、Qwen3.5-4Bは49.2から50.6に移動しました。これらの平均はベースラインの難易度が大きく異なるタスクを組み合わせたものなので、追加されたスペキュレーション目的がテストされた設定でエージェントの既存能力を消していないことを示しています。

以前の市販品との比較は、研究者らが別個のドラフトモデルを拒否した理由を示しました。MuSiQue上で、自分の次の呼び出しを予測するQwen3-4BはHit@1 25.3を達成し、GPUメモリを8.70 GB使用し、推測の実壁時計時間が8.3秒でした。外部スペキュレータとしてのQwen3-1.7BはHit@1 14.7に達しましたが、組み合わせたセットアップでは12.76 GBと33.1秒を消費しました。テストは単一のNvidia H100で実行され、モデル間の明示的な切り替えを使用していたため、これらの測定値は論文のサービング設定を記述しており普遍的なプロダクションコストを示すものではありません。

Where the claim stops

結果はセルフ・スペキュレーティング構成がより高い予測精度と低いサービングオーバーヘッドを示すことを確立しました。論文は、実際のツールが並行して動作する際に訓練済みモデルがユーザーが体感するレイテンシをどれだけ低減するかを示すエンドツーエンドのプロダクション導入を報告していません。

訓練後の予測の約6〜7割は正確な一致が起きていました。残りの推測呼び出しは再利用できず、運用者は無駄になったAPIリクエストと計算資源を正解した予測によって節約されたレイテンシと天秤にかける必要があります。

安全性は即時のユースケースをさらに狭めます。誤った推測的ウェブ検索は破棄できますが、誤った注文、データベース更新、外向きメッセージはエージェントがそのアクションを確定する前に外部の状態を変える可能性があります。著者らは現在のケースを読み取り専用操作に限定し、状態を変更するツールにはドライランモード、ロールバック機構、または人間の確認を提案しています。

実験は4B規模のモデルと2つのタスクファミリを使用しました。コード実行、ブラウザ制御、長時間実行されるワークフロー、マルチエージェントシステム、大規模なフロンティアモデルは評価の外にあります。その境界内でさえ、この研究はエージェント設計者にとって実用的な設計選択を指摘しています：配備されたポリシーは、それを模倣するように訓練されたより安価なモデルよりも次の行動を予測するのに優れている可能性がある、という点です。