SWE-Compass は、大規模言語モデルのエージェント型コーディング能力を評価するためのベンチマークである。 実際の GitHub プルリクエストから組み立てられ、タスクタイプ、プログラミングシナリオ、プログラミング言語という 3 つの直交する軸に沿って構成されているため、モデルの性能を単一の解決率として報告するのではなく、軸ごとに 診断できる。これは SWE-Compass: 大規模言語モデルのエージェント型コーディング能力の統一的評価に向けて によって提案されたもので、同論文は、既存のソフトウェアエンジニアリングのベンチマークが抱える、タスクの カバー範囲の狭さ、言語の偏り、実際の開発者のワークフローとの整合性の不足と同論文が説明する問題に対処する ためにこれを構築した。
内容
1 つのインスタンスは、実際のプルリクエストから抽出されたタスクを、実行可能な環境と再現可能なテストと 組み合わせたものであり、これによりプロンプティングベースの手法とエージェントベースの手法を、制御された 予算のもとで比較できる。ベンチマークは 40 のリポジトリにわたる 2,000 のインスタンスを収録しており、 1 インスタンスあたりの変更ファイル数は平均 4.7 である。
3 つの軸はいずれも固定の集合である。8 つのタスクタイプは、機能実装、機能拡張、バグ修正、 リファクタリング、パフォーマンス最適化、コード理解、テストケース生成、構成とデプロイである。8 つの プログラミングシナリオは、アプリケーション開発、データベースシステム、データサイエンスとデータ エンジニアリング、機械学習と AI、インフラストラクチャ開発、専門的なプログラミング領域、セキュリティ エンジニアリング、UI/UX エンジニアリングである。10 の言語は Python、JavaScript、TypeScript、Java、C、 C++、Go、Rust、Kotlin、C# である。
これらの軸は事前に選ばれたものではない。提案論文は、Stack Overflow と GitHub から収集したリポジトリ レベルのコーディングに関する議論から、反復的な能動学習の手順を用いてこれらを導き出している。まず 4 つの 人気のあるソフトウェア関連トピックをラベルプールの種とし、インコンテキスト学習によるラベル付けの ステップで言語モデルに収集した会話を 3 つの次元に沿ってアノテーションさせ、モデルに導かれたシードの 最適化を伴うタグのクラスタリングによって、プールが収束するまで洗練させた。反復は 5 回行われた。
来歴
リポジトリは複数の品質指標でフィルタリングされた。すなわち、有効なオープンソースライセンスがあること、 スターが 500 以上あること、過去 6 か月以内に活発にメンテナンスされていること、異なるコントリビューターが 3 人以上いること、イシューとプルリクエストが合計 1,000 件を超えること、フォークが 200 を超えること、 そして実行可能なユニットテストが存在することである。それらのリポジトリ内のプルリクエストは、メイン ブランチにマージされていること、説明的なイシューに紐づいていること、ファイル単位または行単位で識別可能な 変更を含んでいること、そしてリポジトリ、イシューの説明、コミット、テストパッチ、コードパッチを含む 完全なメタデータを持つことを満たす場合にのみ残された。このフィルタリングを通過したプルリクエストは 約 50,000 件だった。
次に、構成ファイルから依存関係の情報を抽出して Dockerfile に落とし込むことで、プルリクエストごとに実行環境が 構築された。論文によれば、自動ビルドの初期成功率は約 2% であり、30 人のアノテーターによる専門家の支援を 受けた修復によって保持率は約 8% まで引き上げられ、約 4,000 の実行可能なイメージが得られた。
タスクインスタンスは、これらの環境から 3 つの相補的な戦略によって構築された。コード理解については チェックリスト合成を用いる。これは、モデルが生成した自然言語のクエリを難易度を考慮したスコアリング関数で フィルタリングし、推論の要点をまとめたチェックリストと組み合わせるものである。構成とデプロイ、および テストケース生成についてはリバースマスキングを用いる。これは、検証済みの成果物に摂動を加え（Dockerfile の 依存パッケージを削除または置換する、あるいは不完全なテストスイートを引き出すなど）、失敗を再現するケースだけを 残すものである。パッチベースのタスクタイプについてはヒューリスティックなフィルタリングを用いる。これは、 プルリクエストを意図と振る舞いの文脈によって分類するもので、パフォーマンス最適化のシードとしては、変更前後の いずれでもユニットテストに合格しつつ実行時間を 30% 超改善するパッチが特定される。最終的な検証段階では、 難易度によるフィルタリング、現実的な言語分布を反映するよう重み付けされたタスクバランス型のサンプリング、 そして実行可能性、正しさ、意味的一貫性についての専門家による手動検証が適用された。
データセットは https://huggingface.co/datasets/Kwaipilot/SWE-Compass で公開されている。
利用
提案論文は、SWE-Agent と Claude Code という 2 つのエージェント型フレームワークのもとで、ネットワークを 無効化し再試行なしの固定されたオフラインコンテナ内で 10 のモデルを評価している。同論文によれば、 Claude-Sonnet-4 がどちらのフレームワークでも首位であり、マクロ平均で Claude Code では 32.9%、SWE-Agent では 31.8% だった。大半のスコアは 20% 台前半から半ばに集中し、全体の範囲はおよそ 10〜33% である。オープン ウェイトのシステムの中では、Qwen3-Coder-480B-A35B-Instruct が SWE-Agent で 27.2%、Claude Code で 21.9% に 達したと報告されている。
同じ論文は、このベンチマークの軌跡を失敗分析にも用いており、3 つのシステムについてモデルごとに 600 件の 失敗した軌跡をサンプリングし、6 カテゴリの分類法のもとで分類している。同論文によれば、要件の誤解と、 副作用を伴う不完全な解決策が合わせて失敗の 60% 超を占め、技術的な知識の不足は 5〜8% にとどまる。
同論文は、このベンチマークを先行するリポジトリレベルのデータセットと対比して位置づけている。その比較表には SWE-Bench Verified、SWE-Bench Pro、Multi-SWE-bench などが挙げられて おり、それらはカバーする言語が少なく、ほとんどの場合バグ修正のみを対象としていることを根拠としている。