概要
- SWE-bench Verified は2024年8月以降、業界標準の自律ソフトウェアエンジニアリング評価指標として広く利用
- モデルの進歩が鈍化し、評価指標としての限界が明らかに
- テストケースの欠陥 や トレーニングデータ汚染 が評価の信頼性を損なう主因
- OpenAIはSWE-bench Verifiedの報告を停止し、新たな評価指標の開発を推奨
- 今後は SWE-bench Pro や GDPVal のような私的に作成されたベンチマークが重要
SWE-bench Verifiedの役割と進展
- SWE-bench Verified は、2024年8月の公開以降、最先端モデルの自律ソフトウェアエンジニアリング能力を測定する業界標準
- OpenAIの Preparedness Framework でも進捗追跡の主要指標として採用
- 公開後、モデル精度は 74.9%から80.9% へと向上したが、最近は進歩が停滞
- 残された失敗例がモデルの限界かデータセットの問題かが課題
SWE-bench Verifiedの問題点
- テストケースの欠陥 ・監査対象の27.6%の問題のうち、少なくとも59.4%で正しい解答がテストで不正に却下 ・タスク実装の細部に依存する「狭すぎるテスト」や、記述外の機能まで要求する「広すぎるテスト」が多数
- トレーニングデータ汚染 ・モデルがテスト対象の問題や解答を事前学習している事例を多数確認 ・「gold patch」や問題文の詳細をそのまま再現するケースも発生 ・これにより、モデルの本来の能力ではなく、事前露出度がスコアに影響
SWE-bench Verifiedの評価停止と今後の指針
- SWE-bench Verified のスコアはもはや実世界の能力向上を反映しないと判断
- OpenAIは SWE-bench Verifiedのスコア報告を停止、他社にも同様の対応を推奨
- 新たな「汚染されていない」評価指標の開発が急務
- 当面は SWE-bench Pro での評価報告を推奨
SWE-bench/SWE-bench Verifiedの詳細と監査結果
- SWE-bench (2023年公開)は、12のOSS PythonリポジトリからGitHub issueとPRを抽出し、バグ修正能力を評価 ・修正前後で失敗/成功するテストで正当性判定 ・モデルはテストを参照せず、issue文と修正前コードのみで解答
- SWE-benchの問題点 ・テストが過度に具体的・ミスマッチな場合が多い ・タスク記述が曖昧で複数解釈可能、テストカバレッジが限定的 ・環境依存でテストが不安定
- SWE-bench Verified は専門家3名による1,699問題の審査で500問題に厳選
- しかし再監査で138問題中59.4%に重大なテスト設計・記述問題を発見 ・「狭すぎるテスト」35.5%、記述外機能要求の「広すぎるテスト」18.8%、その他5.1%
具体的な失敗例
- pylint-dev__pylint-4551
・テストが特定関数名
get_annotationの実装を要求するが、問題文に明記なし ・正しい修正でも関数名が違うと失敗扱い - sympy__sympy-18199 ・PRは3つのissue解決、問題文は1つのみ記載 ・テストは全3つをカバーし、記述外の修正まで要求
汚染リスクと自動評価の課題
- SWE-bench Verifiedやリポジトリが公開・広範利用されており、モデルの事前学習時に情報流入が不可避
- GPT-5.2などがrelease note情報やgold patchをそのまま出力する事例を確認
- 自動red-teaming による汚染検出で、GPT-5.2, Opus, Gemini 3 Flash Previewなど主要モデルが多数のタスクでgold patchや詳細情報を再現
- 汚染リスクを避けるためには、 ・ベンチマークや解答の公開方法(パスワード保護等)の工夫 ・トレーニングデータフィルタリング(canary stringの厳密運用等)が不可欠
- 自動スコアリングは「正しい機能実装を、実装詳細に依存せず検証」できるテスト設計が難題
今後の評価指標と業界への提言
- OpenAIは最近 SWE-bench Pro のpublic splitで結果を報告 ・SWE-bench Verifiedより汚染が少なく、gold patchの完全再現も未確認
- 将来的には GDPVal のような「非公開・専門家作成タスク」「訓練済みレビュワーによる全体評価」が重要
- こうしたリソース集約型の評価が、真の能力向上測定には不可欠
- 業界・学術界全体で、 オリジナル・非公開ベンチマーク の開発と運用の協力が必要