技術要約: SWE-Future

問題提起

現在のソフトウェアエンジニアリング（SWE）エージェント向けのベンチマークは、多くの場合、過去のGitHubのIssueやプルリクエスト（PR）の再生に依存しています。これはリアリズムを提供する一方で、重大な妥当性の問題を引き起こします。ベンチマークが公開されるにつれ、そのリポジトリ、Issueのテキスト、およびPRのメタデータが、モデルの事前学習、ファインチューニング、合成データの生成、またはモデル選択のループに紛れ込むリスクが生じます。これにより、モデルが真のコーディング能力を実証しているのではなく、単にベンチマークの解を記憶しているだけであるという「データ汚染」が発生します。逆に、純粋な合成タスク生成は、過去の再生を回避できるものの、プロジェクトの慣習、メンテナーの優先順位、あるいは現実的な依存関係の制約を無視してしまうため、実際のリポジトリのニーズから乖離してしまうことがよくあります。

メソドロジー

SWE-Futureは、このギャップを埋めるために「予測条件付きデータ合成（forecast-conditioned data synthesis）」手法を提案します。実現済みのPRを再生する代わりに、この手法は、事前のスナップショットに基づく証拠を用いてリポジトリの将来的な進化を予測し、その予測を使用してタスク合成をガイドします。プロセスは、厳格な時間的境界を持つ4つの明確なステージに分かれています。

1. 証拠収集 (Pre-$T_0$): 時刻 $T_0$ におけるリポジトリのスナップショットに対し、システムは $T_0$ 以前のIssue、PR、ラベル、およびテキストを集約します。メンテナンスのみの変更（例：依存関係の更新、ドキュメント、CI）を除外し、コアとなるコーディングタスク（機能実装/拡張、バグ修正、リファクタリング）に焦点を絞ります。
2. 予測 (Forecasting): システムは、$T_0$ 以前のシグナルを「タスクファミリー」にクラスタリングします（例：「モジュールXにおける再発性のハングアップ」や「機能YのためのAPI拡張」）。これらは特定のPRタイトルではなく、リポジトリの需要の粗い方向性です。決定論的なスコアリング・ヒューリスティックを用い、シグナルの量、Issue数、およびラベルの多様性に基づいて、これらのクラスターをランク付けします。
3. 遡及的検証 (Retrospective Validation): 予測が固定された後、システムは $(T_0, T_1]$ の期間（ここで $T_1 = T_0 + 6$ ヶ月）にマージされたPRを確認します。セマンティック・マッチングを用いて、凍結された予測ファミリーが実際の将来の作業と一致するかどうかを判断します。極めて重要な点は、これらの後のPRは予測の方向性を検証するためだけに使用され、最終的なタスクの構築には使用されないことです。
4. タスク合成 ($T_{gen}$): 検証された予測ファミリーが条件付けシグナルとして機能します。タスク生成用のスナップショット ($T_{gen}$) が選択されます。$T_{gen}$ で可視なリポジトリの状態と、検証されたファミリーの方向性のみを使用して、マルチエージェント・ワークフローが具体的なコーディングタスクを構築します。このワークフローには以下が含まれます。
   • コンテキスト選択: $T_{gen}$ 内の具体的なコード対象の特定。
   • タスク記述: エージェントに対して可視となるIssue形式のリクエストの生成。
   • オラクル設計およびパッチ構築: 非表示のテストパッチとゴールドパッチ（解）をゼロから作成し、タスクが実行可能（FAIL TO PASS）であることを保証します。
   • 検証: テストパッチがベースのスナップショットで失敗し、ゴールドパッチによってパスすることを確認すると同時に、公開されるタスク記述に隠蔽されたアーティファクトが漏洩しないことを確認します。

主な貢献

1. 予測条件付き合成: 過去のPR再生に頼るのではなく、リポジトリ進化の予測を条件付けシグナルとして用いることで、現実的かつ将来志向のコーディングタスクを構築する手法を導入しました。
2. 遡及的検証プロトコル: 予測されたファミリーが将来のリポジトリ作業を捉えているかどうかをテストするプロトコルを確立しました。80リポジトリを用いた研究において、フォキャスターはセマンティック・マッチング指標の下で、58.1%の将来作業適合率（強力または関連する一致）を達成しました。
3. 実行可能なデータセット構築: 検証された予測を、61リポジトリにわたる200タスクのコーディングエージェント用データセットへと変換できることを示しました。これらのタスクは $T_{gen}$ スナップショットに基づいたものであり、実行可能な検証アセット（テストおよびゴールドパッチ）を含んでいますが、これらは $T_0$ 以降のPRアーティファクトを使用せずに構築されています。

結果

• 予測性能: 76リポジトリから生成された260の予測ファミリーのうち、151個（58.1%）が将来の作業に対して「強力」または「関連」していると検証されました。バグ修正ファミリーが最も高い適合率（89/139）を示し、次いで機能実装/拡張（45/93）となりました。
• データセット構成: 最終的なデータセットには、120のバグ修正、60の機能実装/拡張、および20のリファクタリングタスクを含む計200のタスクが含まれています。
• 汚染の軽減: この手法は、タスク生成を過去のPR再生から効果的に切り離すことに成功しました。公開されるタスク記述には、テストパッチのロジック、ゴールドパッチの詳細、または遡及的検証のラベルは含まれておらず、これらは隠蔽された評価用アセットとして保持されます。

意義と主張

本論文は、SWE-Futureが「歴史的再生（高リアリズム、高汚染リスク）」と「純粋な合成生成（低汚染、低リポジトリ圧力）」の間の「中間領域」に対処することを主張しています。リポジトリの履歴を $T_0$ で凍結し、起こりうる方向性を予測し、その上で $T_{gen}$ に基づいてタスクを接地することで、この手法は過去のプルリクエスト再生への直接的な依存を軽減します。

著者らは、目標はモデルがそのリポジトリを見たことがないことを証明することではなく、観察された過去のPRをタスク素材として直接再生することを避けることであると強調しています。このアプローチにより、情報の境界を明確に保ちながら、自然なプロジェクトの進化を反映したリポジトリ固有のタスクを作成することが可能になります。また、フォキャスターがノイズとなるアンカーを拾ってしまう可能性や、生成されたテストパッチが（特にリファクタリングタスクにおいて）メンテナーが書いたテストほどの精度を持たない可能性があるといった限界についても認めています。今後の課題として、予測のノイズ除去およびテスト合成品質の向上が挙げられています。