SWE-bench: 言語モデルは現実世界のGitHubの問題を解決できるか？

CodeActの論文は、LLMエージェントにとってPythonが適切なアクションフォーマットであるという説得力のある根拠を示しました。しかし、適切なアクションフォーマットを選択することは問題の半分にすぎません。エージェントが、精選されたベンチマークだけでなく、現実世界のタスクの複雑さを処理できることを証明する必要があります。プリンストン大学のCarlos Jimenez、John Yang、Alexander Wettig、Shunyu Yao、Kexin Pei、Ofir Press、Karthik Narasimhanらによって発表され、ICLR 2024で紹介されたSWE-bench (arXiv:2310.06770) は、このギャップに正面から向き合うことをこの分野に強いた論文です。

論文について

「SWE-bench: Can Language Models Resolve Real-World GitHub Issues?」は、astropy、django、flask、matplotlib、pylint、pytest、requests、scikit-learn、seaborn、sphinx、sympy、xarrayの12の人気のあるPythonリポジトリから、実際にマージされたプルリクエストに基づいて2,294件のタスクインスタンスのベンチマークを構築しました。各インスタンスは、コードベースのスナップショットとGitHubイシューの説明をモデルに提示します。モデルは、既存のテストを壊すことなく、指定された以前は失敗していたテストセットを合格させるパッチを作成しなければなりません。このベンチマークは、約90,000件のPRをマイニングし、リンクされたイシューを解決し、かつ新しいテストを追加したものに絞り込み、その後、実行ベースのパス/フェイルの遷移を検証することによって構築されました。この規律ある構築方法により、曖昧であったり、簡単にごまかしたりできるグラウンドトゥルースという、典型的なベンチマークの問題を回避しています。

主なアイデア

• 発表時点で最高のパフォーマンスを示したモデルであるClaude 2は、BM25スパースリトリーバル（モデルが自ら関連ファイルを見つけなければならない現実的なデプロイ設定）を使用した場合、わずか1.96%のイシューしか解決できませんでした。
• オラクルリトリーバル（モデルに必要なファイルが正確に渡される設定）では、Claude 2は4.80%に向上しました。これは、ボトルネックが一部はリトリーバルにあるものの、主に編集にあることを裏付けています。完璧なコンテキストがあっても、成功率は5%を下回ったままです。
• GPT-4は、BM25リトリーバル（予算の都合により25%のサブセットで評価）では0.00%、オラクルでは1.74%のイシューを解決しました。Claude 2におけるオラクルからBM25への低下は深刻ですが、GPT-4においては致命的です。
• 生成されたパッチは体系的に短すぎます。Claude 2の成功したパッチは平均19.6行であるのに対し、人間による正解パッチは74.5行です。モデルは単純な局所的な修正を見つけますが、人間はファイル間にまたがる包括的な解決策を書きます。
• コンテキストを増やすことは、かえって悪影響を及ぼします。50kトークンのBM25は13kトークンよりも多くのオラクルファイルを回収しますが、解決率はしばしば低下します。「lost in the middle（中だるみ）」効果、つまり長いコンテキストの中に埋もれた関連する証拠をモデルが無視してしまう現象は、ここでも実証された失敗モードです。
• オラクルで取得されたコンテキストでファインチューニングされたSWE-Llama 13bは、オラクルでは4.00%を達成しましたが、BM25ではわずか0.70%でした。完璧なコンテキストでトレーニングを行うと、リトリーバルが現実的になったときに崩壊してしまう脆弱なエージェントが作成されます。

維持されているもの、そうでないもの

ベンチマークの構築は厳格です。実行ベースの評価（実際にテストを実行し、合否を判定する）は、コード編集タスクにおける正しいグラウンドトゥルースです。これは客観的で自動化が可能であり、ごまかしが困難です。単なるパッチの適用成功だけでなく、失敗から成功への遷移（fail-to-pass transitions）を要求するという決定は特に重要です。これにより、何もしない（no-ops）や削除といった、些細で正しく見えるパッチを防ぐことができます。

結果は非常によく維持されています。SWE-benchは2023年10月に公開され、瞬く間にコーディングエージェントの事実上の評価基準となりました。当初の1.96%というベースラインは、意図的に選ばれたものではなく、真に示唆に富むものです。関連グループによって2024年に発表されたSWE-agentは、エージェントとコンピュータのインターフェースを再設計することで、成功率を12.47%まで引き上げました。この6倍の向上自体が、元のベースラインがいかに多くの可能性を残していたかを裏付けています。

この論文が十分に扱いきれていない点が2つあります。第一に、ベンチマークがPythonのみであることです。これは実用上の必要性からですが、Pythonの慣習に過剰適合（オーバーフィッティング）するリスクを生みます。第二に、この論文ではリトリーバル拡張生成（RAG）のベースラインのみを提案しており、エージェントベースのアプローチについては明示的に将来の課題としています。この保留は2023年時点では適切でしたが、論文自体からはどのようなエージェントアーキテクチャが有効であるかというシグナルは得られないことを意味します。

「オラクル」設定も、見かけほど強力な上限ではありません。完璧なファイルコンテキストを提供しても、それらのファイル内でのコードの特定（ローカライゼーション）は解決されませんし、モジュール間の相互作用に関する複数ファイルにわたる推論にも役立ちません。オラクル設定でのClaude 2の4.8%という数値は、コンテキストに正しいファイルがあっても、モデルは95%の確率で失敗することを意味します。問題は主にリトリーバルにあるのではありません。

なぜこれが金融AIにとって重要なのか

BeancountはGitHubでホストされているPythonプロジェクトです。Beancountのライトバック（書き戻し）エージェントは、本質的にSWE-bench形式のタスクを解決する必要があります。つまり、元帳ファイルと指示（「この取引を追加して」「この残高の不一致を修正して」）が与えられたときに、既存の表明（assertion）を壊すことなく bean-check をパスする編集を行うエージェントです。

リトリーバルの失敗は、元帳のローカライゼーション問題に直接類似しています。ユーザーが「第3四半期の事務用品費の過大計上を修正して」と言ったとき、エージェントはまず、数千行に及ぶ可能性のあるファイルの中から関連するエントリを見つけなければなりません。これは、BM25がSWE-benchのインスタンスの40〜50%で失敗したファイル特定タスクと同じです。「lost in the middle」による劣化は、長い .beancount ファイルにも同様に当てはまります。古い日付のエントリも、新しいものと同様に無視される可能性があります。

パッチ長の非対称性は、実用的な警告です。モデルはパッチを狭く当てすぎる傾向があります。会計においては、これはオフセットエントリ（相手勘定）を忘れて一方のエントリだけを修正したり、経費行を更新しても繰越残高を古いままにしたりすることに相当します。本番環境のBeancountエージェントには、検証レイヤー（bean-check、残高表明、または明示的な照合パス）が必要です。これにより、エージェントに局所的な妥当性だけでなく、編集による全体的な影響を確認させることができます。

オラクルとBM25のギャップは、リトリーバルの品質がエージェントの品質と切り離せないものであることも思い出させてくれます。ユーザーの質問に対してどの勘定科目やファイルが関連しているかを確実に見極めることができないエージェントは、編集を試みる前の元帳ナビゲーションの段階で失敗することになります。

次に読むべきもの

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — 直接の続編です。エージェントとコンピュータのインターフェースを再設計することで、1.96%から12.47%へと向上させました。ファイルナビゲーションとコード検索の設計原則は、Beancountエージェントのツール作成に直接応用できます。
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — エージェントの複雑さを取り除き、足場（スキャフォールディング）のない単純なローカライゼーションと修復のパイプラインが競争力を持ち得ることを示しています。インターフェースを重視するアプローチに対する有用な対照案です。
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — 階層型メモリ管理により、長いコンテキストの問題に正面から取り組んでいます。数年分に及ぶBeancountの元帳を推論しなければならないエージェントに直接関連します。