💬 NLP

Synthesize and Reward -- Reinforcement Learning for Multi-Step Tool Use in Live Environments

本論文は、状態を持つサーバーのライブラリ、依存関係に基づいたデータ合成パイプライン、および新しいプログラムによる報酬システムを組み合わせることで、ライブ環境におけるマルチステップのツール利用に対する効果的な強化学習を可能にするフレームワークであるPROVEを紹介しており、その結果、複数のベンチマークおよびモデルファミリーにわたって大幅な性能向上を実現している。

原著者： Ibrahim Abdelaziz, Asim Munawar, Kinjal Basu, Maxwell Crouse, Chulaka Gunasekara, Suneet Katrekar, Pavan Kapanipathi

公開日 2026-06-03

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Ibrahim Abdelaziz, Asim Munawar, Kinjal Basu, Maxwell Crouse, Chulaka Gunasekara, Suneet Katrekar, Pavan Kapanipathi

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたは、非常に賢いが経験の浅い見習いに対して、実際の家を修理するために巨大で複雑な道具箱を使う方法を教えていると想像してください。目標は、見習いが単に正しい道具を選ぶだけでなく、正しい順序で使い、ミスに対処し、分からない時には立ち止まることができるようにすることです。

PROVEと題されたこの論文は、AIモデル（「見習い」）にまさにこれを行うための新しい訓練方法を説明しています。著者らは、従来の手法が主に3つの理由で失敗していることを発見し、これらを修正するために新しいシステムを構築しました。

以下は、単純な比喩を用いた彼らの解決策の解説です。

彼らが解決した3つの問題

「偽物の家」問題：
- 従来の方法： ほとんどの訓練は「シミュレーション」や静的なマップ内で行われていました。それは、家の図面の上で練習しているようなものです。もし見習いが図面に存在しないドアを開けようとしても、システムはかなり後になるまでそれが間違いであると認識できませんでした。
- 解決策： PROVEは**Live MCP Environments（ライブMCP環境）**を使用します。これは、見習いを、実際の配管や電気設備がある「本物の家」で訓練することを意味します。もし彼らが電球のないライトを点けようとしたら、システムは即座に「それはうまくいかなかった」と伝えます。これは、リアルタイムで、現実の結果を伴って行われます。
「架空の家具」問題：
- 従来の方法： 練習問題を生成する際、コンピュータはしばしば架空の詳細を作り上げてしまいました。例えば、「404号室にある赤い椅子を動かせ」という指示を出しますが、実際には404号室は存在せず、赤い椅子もありませんでした。見習いはその指示に従おうとして、即座に失敗することになります。
- 解決策： 彼らは**Grounded Data Pipeline（グラウンデッド・データ・パイプライン）**を構築しました。質問を出す前に、システムはまず「家」の中を確認し、実際にどのような家具が存在するかを調べます。もし101号室に赤い椅子があれば、システムは「101号室の赤い椅子を動かせ」と指示します。これにより、すべての練習課題が完了可能なものになります。
「おしゃべりすぎる（チャッターボックス）」問題：
- 従来の方法： 報酬システムは、生徒がチェックリストの全項目を完了した時だけ金メダルを与える教師のようなものでした。これは、生徒が注意深く考えるのではなく、たまたま正解に当たることを期待して、知っているあらゆるツールを呼び出し続けるという、怠慢な行動を助長してしまいました。
- 解決策： 彼らは**Programmatic Reward System（プログラマティックな報酬システム）**を作成しました。新しいシステムは、単に正しいツールが使われたかどうかをチェックするだけでなく、以下の点についても報酬を与えます。
  - 妥当性（Validity）： そのツールは実際に機能したか？
  - 網羅性（Coverage）： 必要なステップをすべて実行したか？
  - 効率性（Efficiency）： 無駄な時間や、不要な呼び出しを行わずに実行できたか？（これが「アンチ・チャッターボックス」のルールです）
  - 精密さ（Precision）： 正しいツール名と正しい設定を使用したか？

システムの仕組み（「コーチ」）

著者らは、トレーニングセッションを実行する「コーチ」（ステートマシン・オーケストレーター）を構築しました。

マップ： コーチはまず、ツール同士がどのように依存し合っているか（例：「送金」をする前に「残高を確認」しなければならない）というマップを描きます。
スカウティング： コーチはライブ環境を探索し、質問に使用するための実在するアイテムを見つけ出します。
練習： コーチはAIに多段階の質問を投げかけます。AIはツールを呼び出すことで問題を解決しようと試みます。
スコアカード： システムは、別のAIを使って採点（これは低速で高コストです）するのではなく、コードを使用して即座にチェックを行います。「ツールは実行されたか？正しいデータが返ってきたか？ステップを使いすぎていないか？」
ループ： AIはスコアを受け取り、改善しながら何度も挑戦します。

結果

チームは4つの異なるAIモデル（小規模から中規模まで）でテストを行いました。彼らは何百万もの例を必要とせず、約13,000回の高品質な練習セッションを使用しました。

結果は目覚ましいものでした。

モデルは多段階の問題を解決する能力が大幅に向上しました。
3つの主要なテスト（BFCL、τ 2-bench、T-Eval）において、最大10ポイントのスコア向上を記録しました。
極めて重要な点として、モデルは効率的になることを学びました。彼らは不必要なツール呼び出しをやめ、根拠のない推測をして暴走するのではなく、情報が不足している場合には停止することを学びました。

結論

この論文は、ロボットにツールを使わせる方法を教えるために、膨大な数の人間のアノテーターや超高性能な「判定用AI」は必要ないということを証明しています。代わりに、彼らに練習するための実際の環境、作業するための実際の実データ、そして効率性を評価するスマートなスコアリングシステムを与えれば、複雑なタスクのオーケストレーションを非常に迅速に学習できるのです。

重要な教訓は、AIに現実世界でのツールの使い方を教える場合、データの「量」よりも、**訓練の「質（現実の状態と現実の報酬）」**が勝るということです。

技術サマリー: PROVE — 検証済み環境におけるプログラム的報酬

問題提起

大規模言語モデル（LLM）にマルチステップのツール呼び出しをオーケストレーションさせる訓練を行う際、以下の3つの結合された障害が、自律型エージェントのデプロイを阻害しています。

コストのかかる現実的な環境: 現実的で状態を持つ実行環境を構築することはリソース集約的であり、多くのパイプラインはキャッシュされたAPIやシミュレーションされたAPIに依存せざるを得ず、状態依存の失敗モードを見逃してしまいます。
乖離した合成データ: 合成トレーニングクエリは、サーバーの実際の状態に基づかずに生成されることがよくあります。その結果、生成されたツール呼び出しが実在しないエンティティを参照し、訓練中の実行失敗を引き起こします。
冗長性のインセンティブ: 標準的な再現率ベースの強化学習（RL）報酬は、冗長なツール呼び出しパターンを助長します。モデルは、グラウンドトゥルース（GT）の網羅率を最大化するために、過剰なツール呼び出しを出力することを学習しますが、これは明示的にペナルティを与えられることが稀な退行現象です。

メソドロジー: PROVE フレームワーク

著者らは、共有されたライブ実行バックエンドを介して、データ合成とRLループを密結合させるフレームに PROVE (Programmatic Rewards On Verified Environments) を提案しています。このメソドロジーは、以下の3つのコアコンポーネントで構成されています。

1. ライブ MCP 環境フレームワーク

静的なキャッシュの代わりに、PROVE は、金融、生産性、コマース、旅行、IoT などのドメインにわたる 343 個のツール を公開する 20 個の状態を持つ Model Context Protocol (MCP) サーバー のライブラリを活用します。

状態依存の実行: キャッシュされた API とは異なり、これらのサーバーは現実的な状態依存のダイナミクス（例：送金後の口座残高の変化、永続的なカレンダーイベント）を捉えます。
セッション限定の隔離: 各 RL ロールアウトエピソードには一意のセッションIDが付与され、状態の隔離と再現可能な初期条件を保証します。
統合: 本フレームワークは VERL RL フレームワークと統合されており、モデルが生成したツール呼び出しを適切な MCP サーバーにルーティングし、実行レスポンスを返します。

2. グラウンデッドな状態マシンによるデータ合成

乖離した合成データの問題に対処するため、PROVE は検証済みのマルチターン・トラジェトリを生成する自動パイプラインを採用しています。

依存関係グラフの発見: LLM がツールペア間の関係（明示的、暗黙的、またはなし）を分類して依存関係グラフを構築し、現実的なマルチステップの連鎖をシードします。
ライブ状態のサンプリング: クエリ生成の前に、システムはライブ MCP サーバーをプロンプトして、実際のエンティティ（例：有効なアカウントID、存在する都市）を列挙します。この「サンプリング・コンテキスト」がプロンプトに注入されることで、LLM はサーバー状態に実際に存在するエンティティのみを使用するように制約されます。
状態マシン・オーケストレーター: 有限状態マシンが会話を駆動し、クエリ生成、LLLL プロセッシング、ツール実行、およびリカバリ（修正されたパラメータや代替ツールでのリトライ）の間の遷移を管理します。
堅牢性と検証: パイプラインは確率的な摂動（ディストラクター、削除された列挙型、無関係なクエリ）を導入し、新しくリセットされた環境に対してリプレイ検証を行います。エラー率が 30% 未満であり、かつ機密パラメータのプロベナンス（由来）が有効な会話のみが保持されます。
データセット: このプロセスにより、マルチターン会話、明確化のトラジェトリ、および棄却の例を含む 約 13,517 件のトレーニング例 が得られます。

3. マルチコンポーネント・プログラム的報酬

PROVE は、外部の「LLM-as-judge」モデルを必要としない、5 つの部分からなる完全なプログラム的報酬関数 ( $R_{total}$ ) を導入しています。

妥当性 ( $R_{validity}$ ): 関数名の存在、パラメータの互換性、およびライブ実行の成功に基づいた段階的なスコア (0–1)。
網羅率 ( $R_{coverage}$ ): すべての GT ワークフローのステップが正しい依存順序で完了しているかを測定します。これは、モデルの呼び出しが GT 引数キーと一致するために、すべてのキーを含まなければならないことを強制します。
適応的効率性 ( $R_{efficiency}$ ): 冗長性に抗うために設計された主要な貢献です。これは、複雑さにスケーリングされた予算 ( $B = n_{gt} + \lceil n_{gt} \cdot \beta \rceil$ ) を超える呼び出しに対してペナルティを適用します。これにより、複雑なタスクには余裕を持たせつつ、不要な呼び出しにはペナルティを与えます。
ツール名シグナル ( $R_{name}$ ): グラウンドトゥルースに現れるツールの名前を選択した場合に明示的なボーナスを与えます。これは、妥当性スコアが正しいツール選択を学習する前に飽和してしまうボトルネックに対処します。
引数値のマッチング ( $R_{arg}$ ): 特定の引数値（単なるキーではなく）をグラウンドトゥルースと一致させた場合のボーナスであり、マルチターン対話のパフォーマンスを不均衡に向上させます。

実験設定

モデル: 2 つのファミリーからなる 4 つのインストラクションチューニング済みモデル：Qwen3-4B, Qwen3-8B, Qwen2.5-7B, および Granite-4.1-8B。
訓練: すべてのモデルは、8×H100 GPU 上で 350 ステップ、Group Relative Policy Optimization (GRPO) を使用して訓練されました。
ハイパーパラメータ: 同一の報酬重みがすべてのモデルで使用され、学習率のみがファミリーごとに調整されました。
ベンチマーク: BFCL Multi-Turn、 $\tau$ 2-bench、および T-Eval での評価。

結果

PROVE は、わずか約 13K のトレーニング例（AgenticQwen のような並行する RL パイプラインよりも約 8 倍少ない）を使用して、4 つのモデルと 3 つのベンチマークすべてで一貫した改善を示しました。

BFCL Multi-Turn: 最大 +10.2 ポイント の向上 (Qwen3-4B)。
$\tau$ 2-bench: 最大 +6.8 ポイント の向上 (Qwen2.5-7B)。
T-Eval: 最大 +6.5 ポイント の向上 (Qwen2.5-7B)。

アブレーション研究:

報酬コンポーネント: 適応的効率性 ペナルティ ( $\beta=0$ ) または ツール名 シグナルを除去すると、最大の総低下（ベンチマーク全体で約 9 ポイント）が発生し、冗長性の防止とツール選択の誘導におけるそれらの決定的な役割が確認されました。
RL vs. SFT: 同じデータを用いて教師あり微調整 (SFT) を行った場合、モデルはしばしばマルチターン・ベンチマーク（例： $\tau$ 2-bench）で退行しましたが、PROVE は一貫して性能を向上させました。これは、報酬シグナルが合成トラジェトリを信頼できるエージェント行動に変換するために不可欠であることを示唆しています。
教師の堅牢性: データ合成の「教師」LLM を入れ替えた場合（Gemma-4-31B-it vs. Qwen3-32B）でも結果は安定しており、得られた利得は特定の教師のスタイルではなく、報酬の定式化とライブ実行ループに由来することを示しています。

意義と主張

本論文は、コンパクトで完全なプログラム的報酬をグラウンデッドなデータ合成と組み合わせることで、以下を実現することなく、一貫したマルチステップのツール・オーケストレーションの向上を駆動できると主張しています。

大規模なデータパイプライン（数百万件ではなく、約 13K の例を使用）。
報酬計算のための高価な「LLM-as-judge」モデル。
手動のアノテーション。

著者らは、適応的効率性ペナルティとツール名シグナルが最も負荷の高いコンポーネントであり、ツール使用における RL を制限してきた歴史的なボトルネックである冗長性とツール選択を、うまく解決していると強調しています。ライブ実行と合成を密接に結合することで、PROVE は訓練データが実行可能であることを保証し、報酬シグナルが現実世界の状態依存のダイナミクスを反映するようにしています。