FC-SWE、失敗したパッチから学ぶソフトウェアエージェント

概要

リポジトリ単位のソフトウェア開発は、一度のコード生成で終わる課題ではありません。エージェントはコードを読み、ツールを呼び出し、複数のファイルを修正し、テスト結果を見ながら方針を変える必要があります。パッチが検証に失敗した場合でも、テスト出力には原因を絞り込むための情報が含まれています。FC-SWEは、この失敗後の回復プロセスを強化学習の対象に組み込みました。

手法のポイント

一般的なGRPOでは、同じissueに対して複数の軌跡を独立に生成し、完成したパッチの報酬を比較します。しかし、失敗したパッチや検証器の指摘は、通常、次の生成の入力には引き継がれません。FC-SWEでは、初回試行と回復試行を連鎖させます。

• 失敗条件付きコンテキスト：検証に失敗すると、リポジトリを元の状態へ戻し、issue、失敗したパッチ、検証フィードバックを次の試行へ渡します。
• 軌跡ごとの報酬：各試行は自身の検証結果だけで評価されます。回復に成功しても、以前の失敗パッチに誤って報酬が付くことはありません。
• アクティブセットによる比較：同じissueで実際に実行された初回・回復軌跡だけを比較対象にします。失敗試行は残しますが、まだ実行されていない試行は比較に加えません。

この構成は、回復学習に特有の難しさに対応します。次の試行を生成するかどうかは前回の結果で決まり、その試行の入力内容は前回の実行結果に依存するからです。リポジトリをリセットすることで、汚染された状態を引き継ぐ修正と、フィードバックを利用した修正も区別しやすくなります。

結果と注意点

実験では、Qwen3.5-4BとSWE-agentを用い、SWE-bench Verifiedの500課題すべてを検証器支援型の複数回試行プロトコルで評価しました。FC-SWEのResolved@1は41.7%、Resolved@2は52.8%で、GRPOベースラインの38.9%、48.5%を上回りました。学習時の連鎖は最大2回でしたが、テスト時に11回の予算を与えるとResolved@11は70.7%に達しました。

ただし、Resolved@Kは最大K回のフィードバック付き試行で累積的に解決できた割合です。独立サンプリングのPass@Kや、通常の単一試行ランキングのスコアとは異なります。したがって、この結果から直接言えるのは、検証器を使った回復能力が改善したという範囲です。

意義

FC-SWEの重要性は、失敗を単なるマイナス報酬ではなく、次の判断に使える学習情報へ変えた点にあります。高コストのテスト、状態を持つリポジトリ、長いツール利用が必要なエージェントに特に適した考え方です。今後は、学習時の回復回数を増やした場合の安定性、検証コスト、ノイズの多いフィードバックへの頑健性が課題になります。コードはNVIDIA NeMo RLの専用ブランチで公開予定ですが、現時点では未公開です。

出典：Hugging Face Daily Papers