SWE-bench Verifiedがもはやフロンティアのコーディング能力を測定できない理由

 (openai.com)
4 ポイント 投稿者 GN⁺ 2 일 전 | 1件のコメント | WhatsAppで共有
  • 自律的なソフトウェアエンジニアリング作業の代表的指標だった SWE-bench Verified は、フロンティアモデルの能力を測るには適性が大きく低下している
  • 最近の最高性能の向上幅は 74.9%から80.9% にとどまっており、残る失敗がモデルの限界なのかデータセットの欠陥なのかを区別しにくくなっている
  • 監査対象の138件の問題のうち 59.4% で、テスト設計や問題説明に重大な欠陥が確認され、限定的なテストや過度に広いテストが機能的に正しい解法まで失格にしていた
  • 公開データとコードベースに基づく評価であるため、学習データ汚染を避けるのが難しく、一部モデルはタスク説明やIDだけで ゴールドパッチ をほぼそのまま再現した
  • そのため SWE-bench Verifiedのスコア報告 を中止し、汚染の影響が比較的小さい SWE-bench Pro と非公開ベンチマークへ評価の軸を移している

ベンチマークがもはや測定できない理由

  • SWE-bench Verified は自律的なソフトウェアエンジニアリング作業におけるモデル性能を測る標準指標として広く使われてきたが、現在水準のフロンティアモデルの能力を測定するには適性が大きく低下している
  • 最高性能の向上幅がこの6か月で 74.9%から80.9% にとどまり、残る失敗がモデルの限界なのかデータセットの欠陥なのかを区別しにくくなっている
  • 新たな分析では、欠陥のあるテスト と 学習データ汚染 が中核的問題として明らかになり、スコアが実際のコーディング能力よりもベンチマークへの露出度を強く反映するようになっている
  • そのためOpenAIは SWE-bench Verifiedのスコア報告を中止 し、他のモデル開発企業にも同様の対応を勧めている
  • 代替として、汚染が比較的少ない SWE-bench Pro の利用を推奨しており、新たな非汚染評価指標も構築中である

背景

  • 元の SWE-bench は2023年に公開され、12のオープンソースPythonリポジトリにおける解決済みGitHub Issueと対応するPRを組み合わせて構成された
  • 各問題では、修正前のコードベースとIssue本文だけが与えられた状態でコード変更を生成する必要があり、適用後に すべてのテストを通過 することが合格基準となる
    • 修正前は失敗し、正しい修正後には通過しなければならないテストが含まれる
    • 既存機能が壊れていないか確認する 回帰テスト も含まれる
  • 元の評価には、正しい修正も拒否する過度に具体的なテスト、複数の解釈が可能な不十分な仕様、環境差によって失敗するテストといった問題があった
  • これを減らすため、2024年に SWE-bench Verified が作られ、1,699件の問題を専門家レビューで絞り込み 500件の問題セット を構成した
    • 各問題は3人の専門家が独立にレビューした

テスト設計の欠陥

  • OpenAI o3が64回の独立実行でも一貫して解けなかった 138件の問題 を監査対象とし、各事例は少なくとも6人の熟練ソフトウェアエンジニアが独立にレビューした
  • その結果、138件中 59.4% にはテスト設計または問題説明に重大な欠陥があり、優れたモデルや人間でも解くのが非常に難しい、あるいは不可能な状態だった
  • 監査対象タスクの 35.5% は、特定の実装詳細を強制する限定的なテストを含んでいた
    • 機能的に正しい複数の解法も無効とされうる
  • 監査対象タスクの 18.8% は、問題説明にない追加機能まで要求する広範なテストを含んでいた
  • 残る 5.1% には、上の2分類に明確には入らない別種の問題があった

  • 限定的なテストケース

    • pylint-dev__pylint-4551 では、PRテストが get_annotation 関数を直接インポートするが、この関数名は問題仕様には出てこない
    • そのため、問題を機能的に正しく解決しても、その 特定の関数名 を実装しなければインポートエラーでテストに失敗する可能性がある

  • 広範なテストケース

    • sympy__sympy-18199 は、実際には #17373、#17377、#18212 の3件のIssueをまとめて修正したPRから取られている
    • しかしSWE-bench Verifiedのタスク説明は #18212 しか扱っていないため、説明どおりに実装しても残り2件を検査するテストで失敗する可能性がある

汚染問題

  • SWE-bench Verifiedと対象リポジトリのコードベース、リリースノートはすべて公開され広く利用・議論されているため、データ汚染の回避が難しい
  • OpenAIは自社モデルでも汚染の兆候を確認しており、ほぼ解決不可能とみなした31件のタスクをGPT‑5.2が解いた事例も含まれる
  • django__django-14725 では、テストが問題仕様にない edit_only パラメータを要求しているが、GPT‑5.2は推論過程でこのパラメータが Django 4.1 に導入されたことまで正確に指摘した
  • OpenAIは汚染の深刻度を評価するため、自動化されたレッドチーム用テスト環境 を構築した
    • 各SWE-bench Verifiedの問題について、GPT‑5がGPT‑5.2‑Chat、Claude Opus 4.5、Gemini 3 Flash Previewの汚染有無を調査した
    • GPT‑5にはタスクID、説明、ゴールドパッチ、PRテストが提供され、合計15ターンのあいだプロンプトと誘導戦略を変えられるようにした
    • 各ターン後、評価モデルが新たに明らかになったタスク固有情報の量に基づいて、汚染の深刻度を なし〜強い に分類した
    • 強い汚染事例は追加の評価モデルで情報漏えい過多かどうかを検証し、最終的に人手でレビューした

モデル別の深刻な汚染事例

  • GPT‑5.2

    • django__django-11451 では、短いタスク説明のスニペットだけでも 正確なゴールドパッチ を出力した
    • ModelBackend.authenticate() で username is None or password is None のときに早期リターンする条件、ファイルパス、メソッド名まで再現した

  • Claude Opus 4.5

    • astropy__astropy-13236 では、修正対象ファイルパス astropy/table/table.py、_convert_data_to_col メソッド、さらにdiff内の インラインコメント まで文字どおり引用した
    • 構造化ndarrayを NdarrayMixin に自動変換していた4行のコードも正確に復元した

  • Gemini 3 Flash

    • django__django-11099 では、タスクID以外の追加情報がほとんどない状態でも、タスク説明と ゴールドパッチ全体 を文字どおり出力した
    • ユーザー名検証用の正規表現が r'^[\\w.@+-]+$' から r'^[\\w.@+-]+\\Z' に変わる内容と、行単位のdiffまで再現した

重要な教訓

  • 公開利用可能な資料から抽出したベンチマークは 汚染リスク を抱えており、学習データへの露出がスコアを目立たない形で水増しする可能性がある
  • 公開クローリングデータでベンチマークを作る場合、モデル開発者は汚染有無を確認する 追加テスト を実施すべきである
  • 公開されたベンチマークと解答も最終的には学習データに含まれうるため、データセットの配布方法と学習データのフィルタリングの両方に特別な注意が必要である
    • パスワード保護のような配布制御方式が言及されている
    • カナリア文字列の厳格運用のような フィルタリング手法 も合わせて言及されている
  • 自動採点は、重要でない実装差異には左右されず、かつ抜け道を防げるだけの堅牢性を備える必要があるが、その両立は非常に難しい
  • こうした欠陥を見つけるには、複数回にわたる 大規模な手動ラベリング が必要だった

今後の評価の方向性

  • ここ数か月、OpenAIは SWE-bench Pro公開評価データ の結果を報告する方針を取っており、他のモデル開発者にも同じ対応を勧めている
  • SWE-bench Proも完全ではないが、経験的にはSWE-bench Verifiedより 汚染の影響が小さい
    • 内部の汚染検証パイプラインでは一部の汚染事例が見つかっている
    • ただしSWE-bench Verifiedよりはるかにまれで、深刻度も低かった
    • どのモデルも文字どおり完全一致するゴールドパッチは生成できなかった
  • 今後は、独自性があり 非公開で作成されたベンチマーク への投資を継続する計画である
  • GDPVal では、ドメイン専門家が非公開でタスクを作成し、訓練された評価者がソリューションを総合的に採点する
  • こうした方式はリソースを多く要するが、実質的な能力向上を測るにはますます不可欠な要素になっている

関連記事

1件のコメント

 
GN⁺ 2 일 전
Hacker Newsの反応

  • SWE-bench の共同制作者として整理すると、SWE-bench Verified は今や 93.9% まで来てほぼ飽和しており、Anthropic は祝福に値する
    それでもまだその数値に届いていないチームには、さらに伸ばせる余地がある
    SWE-bench Multilingual と SWE-bench Multimodal はまだ飽和しておらず、Multimodal は来月中にオープンソース公開する予定
    ベンチマークはいずれどれも飽和するものなので、次の段階のベンチマークも作り続けており、すでに https://codeclash.ai/ や https://algotune.io/ のようなものが出てきている

    • 飽和したからといって SWE-bench Verified を使うなという意味ではない
      核心は、テストのかなりの部分が不正確で、実際には正しい解法でも不正解と採点される点にある
      また、最先端モデルは問題の元になった PR をすでに読んで記憶している可能性が高い
      しかも中には、解法を暗記していなければ事実上解けない問題もあり、たとえば問題文に出てこない特定の helper 関数名を正確に出力しないとテストを通過できないケースがある
      それなのに最先端モデルがこうした問題を通過するのは、その名前が必要だという事実を覚えているからだと思われる
      次世代ベンチマークがこの点を解決しない限り、飽和しているかどうかに関係なく同じ問題は残り続ける
    • 記事の内容どおりなら 27.6% のサブセットを監査し、そのうち 59.4% に機能的に正しい提出を拒否する欠陥テストがあったということになる
      計算すると 0.191 * 0.594 > 1 - 0.936 なので、監査したサブセットに代表性がなかったのか、それとも Anthropic が少し怪しい方法で高得点を取ったのかが気になる
    • SPECint と SPECfp もまったく同じサイクルをたどった
      ベンチマークを作り、飽和し、廃れ、置き換えられ、また繰り返した
      結局この treadmill 自体が商品として回っているパターンに見え、解決策は分からないが歴史の繰り返しのように感じる
    • その間の代替として https://SWE-rebench.com もあるようだ
      私の理解では SWE-bench をひねった興味深いバリエーションに見える
    • SWE-bench 自体は素晴らしいと思う
      今のように厳しく検証されているのは、それだけ広く採用され成功したことへの反作用に見える

  • 新しく出るどんなベンチマークでも、すぐに 学習データ に取り込まれてすぐ古びてしまうのはあまりにも明らかに思える
    マーケティング目的だけでも特定のベンチマークに合わせて最適化する動機は常にあり、学習 cutoff があるとしても普通は公開時点との差は 3〜6 か月しかない
    だからコーディングベンチマークの本当の難しさは、既存ベンチマークを流用せず、学習データに絶対含まれていないと保証できる完全に新しい問題を作ることにある
    この観点では、モデルのリリース前に作られたベンチマークはそのモデルの性能を代表しているとは言いがたく、些細な改善を宣伝するためにデータを混ぜ込む金銭的インセンティブが大きすぎる
    正直、マーケティング資料からベンチマーク自体を外して、モデルに直接語らせてコミュニティに判断させる方がいいのだろうが、金が絡む企業は絶対そうしない気がする

    • だから Zork bench を作った
      テキストアドベンチャーゲーム Zork は LLM の学習データに入っていて決定論的なので、本来なら簡単にプレイしてクリアできるはずだ
      ところが実際にはそうではなく、その理由を探るのが Zork bench の目的だ
      https://github.com/mnky9800n/zork-bench
    • コミュニティに判断させると言っても、そもそもどのコミュニティを指すのかが曖昧だ
      LLM を 10 年以上使ってきた専門家から、一度もコードを書いたことのない vibe coder まで混ざっており、オンラインでは GPT 5.5 を救世主のように見る人もいれば 5.4 より愚かだと見る人もいる
      私も新モデルごとに非公開ベンチマークを自作する時間はないので、結局 private または semi-private ベンチマークに頼って改善の程度を見積もったうえで、購読して自分で使ってみる
      少なくとも Reddit のランダムユーザーやボットが作り出す空気よりは少し信頼できる
    • コーディングベンチマークを再び意味あるものにする簡単な方法の一つは、モデルのコンテキストに 20万トークン のノイズや無関係な内容を先に詰め込むことだ
      あるいは同じコンテキストでテストを順番に回し続け、モデルがどれだけ持ちこたえた後に文脈を取り違え始めるかを見る方法もある
      今のベンチマークは常に greenfield 問題だが、実際に欲しいのは腐ったコンテキストを扱えるモデルだ
    • 依然として本質の一段下を見ている気がする
      今のボトルネックは 能力そのもの ではなく、モデルが本番環境で何を 見られるか にある
      コンテキスト構造、retrieval の品質、tool use、複数ターンにまたがる状態の組み合わせ能力が重要で、SWE-bench にはこうした要素がほとんどない
      SWE-bench は one-shot の問題集のような形だが、最先端のコーディング作業はもはやそんな形ではない
      たとえデータ汚染がまったくない完璧なベンチマークを作れたとしても、その多くは依然として間違った軸を測ってしまう可能性が高い
      孤立した問題ではすでに人間の大学院生レベルに達しており、レバレッジはより大きなシステムの中でどう機能するかにある
      だがそれはほとんど好みや嗜好に近く、客観的に測るのが極めて難しい
    • オンラインの コミュニティ 自体があまりにも astroturfed されている
      Anthropic はインフルエンサーに金を払って Claude Code を押し、ボットも大量に回しているようで、オンラインの総意は信頼しにくい
      皆が善意で行動していたとしても、ドメインの違いのせいで体感が大きく分かれることがある
      たとえば AI は frontend や広く使われるライブラリ周りではずっと強いかもしれない
      結局モデル評価は自分で使ってみるしかないが、新モデルごとにこれを繰り返すのはあまりに疲れるし、それだけでは十分に包括的でもない

  • ベンチマーク/eval はもともと難しく、業界規模でゲーム化するインセンティブが極めて大きくなるとさらに難しくなる
    ELT-Bench も最近の例で、データエンジニアリングのワークロード向けに 1 年ほど前に出た最初の本格的ベンチマークだった
    ところが数日前、原著者の一人を含む続報論文でベンチマーク自体が監査され、構造的問題のため結果が偏っていたと報告された
    論文はこちら: https://arxiv.org/abs/2603.29399
    実のところ、こうしたことは新しくもなく、昔の業界でももっと小さい規模ですでに一通り起きていた
    今日の状況がデータベース benchmarketing wars にどれほど似ているかを書いた記事もある
    https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

    • 結局いちばん難しいのは、ベンチマークを 学習データから分離 することだ
      BrowseComp plus や他の deep research データセットでも似た問題が見られ、これは frontier lab が意図的にごまかしているというより、ウェブ全体を学習している以上自然に起きる
      新しいデータセットは永続的に作り続ける必要がある
    • データベースベンチマーク も似た系統だ
      自分で classifier を作る中で体験したが、ある種の作業ではモデルが人間より一貫してうまくやるため、precision 自体を測れなくなる
      そうなるとその classifier 自体が state-of-the-art benchmark になり、自分自身以外に比較対象がなくなる
      コーディングより論理性が低く継続的推論も少ない複雑作業でさえこうなるのだから、いつかは測定対象から独立した補正済みベンチマークそのものが消えてしまうかもしれない
    • では 毎月新しいベンチマーク を作る方式でこの問題を解決できるのかが気になる

  • 結局、私たちは大体において 自業自得のベンチマーク を受け取っているのだと思う
    SWE-bench を通過した PR のかなりの部分は、実際には merge されない気がする: https://news.ycombinator.com/item?id=47341645
    また上位モデルの SWE-bench スコアは git history の漏洩 によって歪められていた可能性もある: https://news.ycombinator.com/item?id=45214670

  • いっそ最高級モデルにベンチマークを直接作らせたらどうかと思う
    冗談はさておき、私が期待しているのは ARC-AGI-3 で、人間シミュレーションをしてみると本当に推論比重が高く感じられた
    リーダーボードはこちら: https://arcprize.org/leaderboard
    現在、ほとんどの最高級モデルでも 5% を超えられていない

    • ここでは 手数の最小化 を重視し、どんな harness も許可していないので、基準が非常に高い
      現在の検証済み最高モデルである Claude Opus 4.6 でも、わずか 0.45% 程度だ
      ただし新しすぎるので、次世代モデルではかなり改善すると期待している
    • 最高級モデルにベンチマークを作らせるという発想も、完全に突飛というわけではない
      以前のモデルに新モデルをインタビューさせ、両者または第三の審判モデルにどちらがより賢いか判定させたうえで seed を変えて 100 回繰り返せばいい
      双方が新モデルの勝利を認めた割合をスコアにすればよさそうだ
    • 推論比重の高いベンチマーク の方がより良い方向に見える
      そうしたものは最もゲーム化しにくい
    • AI が AI でも解けない問題 を書けるのか、とも思う
      考えると少しおかしい

  • より良いベンチマークは 客観的採点、学際的な広さ、拡張性 を備え、単一正解だけの形式は避けるべきだ
    https://gertlabs.com で私たちが設計したものもそういう方向で、コーディングによる問題解決と大筋で関係するようにしている

    • このベンチマークは、これまで見てきた他のランキングより正確に感じられる
      私の体感では gpt 5.4/5.5 は技術的にほぼ欠点がなく、問題が起きるとすれば大抵は入力が曖昧だからだ
      バグ修正や実装中の問題にも自力で対応する傾向があり、作業を抜け漏れなく終わらせることが多い
      一方で Opus は、技術力の面ではやや過大評価されていると思う
      美しい UX を作るデザイナー/開発者的な感覚は優れているが、作業の検証はいつも gpt 5.5 に任せることになる
      最も驚いたのは Xiao-Mi の結果で、まだ使っていないが、これを見て試してみる気になった
      この混沌とした AI 速度競争の中で意味ある基準を作ってくれたチームに祝意を送りたい
    • Claude Code 系は C++ と Java では依然として他モデルを大きく上回っており、GPT 5.5 は Python や JS などでより高く出ているのが興味深い
      学習データセットの偏りや go-to-market の重点の違いが表れているようで、Anthropic が OpenAI よりエンタープライズ顧客に注力してきた結果かもしれないと思う
      Opus を C++ に使った私の体感とも一致する
      ただ C# の結果は空欄なので、@gertlabs、ETA があるのか気になる
    • このベンチマークを見ると Deepseek V4 pro が Deepseek V4 flash より劣っているように見え、かなり興味深い結果だ
      なぜそうなったのかコメントが聞きたい

  • こうしたことは、有機的であれ無機的であれ、結局起こるべくして起きた
    ベンチマークの成績 さえ良く見せられれば、外で一般化しなくても構わないという流れになりやすい
    類似例として Graduate student descent も思い出す
    https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

  • 振り返ると、SWE-bench はもともとそこまで大したものではなかったのかもしれない
    2025 年を通じて、モデルが 良いコード を作る割合は実質ほとんど改善しておらず、自動テストを通過する能力だけが向上したという解釈の方が正しそうだ
    https://entropicthoughts.com/no-swe-bench-improvement

    • コード品質の改善がまったくなかったという見方には同意しにくい
      2025 年 1 月には Claude 3.5 Sonnet、Gemini 1.5 Pro、OpenAI では GPT-4o が主力で、それらのモデルと今の最先端モデルをすべて使ってきた立場からすると、現在のモデルは確かに一段大きく進歩している
    • この解釈はかなり当たっている可能性がある
      モデル品質は停滞しており、新しい改善ベクトルを見つけるのは決して簡単ではないようだ
      これまで改善速度を押し上げてきた モデル幅の拡大 も限界に達しつつあるように見え、今後どんな含意が出てくるのか気になる
      長期的には、ツーリングだけで解決できる範囲にも限界がある
    • それでも 自動テスト通過率 の向上は、莫大なコーディング生産性の源泉だ
      Anthropic が数十億ドル規模の価値で評価される理由の一つもそこにある
      SWE-bench がコーディング分野で有用だったのは、ソフトウェア工学において自動テストを作り活用する伝統とインフラが非常に強いからだ
    • あるいは、そのせいで最近の各社の 価格設定 がより制限的で高額になっているのかもしれない

  • 記事が言っているのは、モデルがしばしば解けなかった 27.6% のサブセット を監査したところ、そのうち少なくとも 59.4% に、機能的に正しい提出すら拒否する欠陥テストがあったという意味に読める
    もし本当なら、これまで問題と正答のかなり大きな塊が誤っていたことにならないかと思うし、だとすればこれがどう有効な測定だったのか疑問が大きい
    ベンチマーク作成プロセスの説明を見る限り基準はかなり高そうなのに、そんな手順でどうしてこれほどひどいデータ品質になったのかもよく分からない
    問題を自ら明らかにしたのは評価できるが、それでも多くの疑問が残る

    • それは 全体の 4 分の 1 が間違っていたという意味ではなく、27.6% のサブセットのうち 59.4% に欠陥テストがあったという意味だろう
      そして現実的な理由から、ベンチマークは本質的にあなたのユースケースを代表しないし、すべてのユースケースを代表するわけでもない
      入っている項目を測ることにしか有効ではなく、それ以上でも以下でもない
      公開ベンチマークにエコシステムが執着する理由が理解できないのもそのためだ
      たとえば Qwen 3.5 が Benchmark X で Qwen 2.5 より 50% 良かったとしても、私の使う作業で 50% 良い保証はほとんどない
      私は実運用でモデルが失敗した事例をもとにプロンプトを調整しながら 非公開ベンチマーク を作り続けてきた
      新モデル更新が出ても私のベンチマークでは 2〜3% しか動かないことが大半なのに、公開ベンチマークでは 30〜40% 向上したと宣伝されるので、学習データ汚染がないとは信じがたい
    • ImageNet も世界で最も有名なデータセットの一つだが、かなり多くの画像に誤ラベルがある
      極端な話、より高得点を取るには誤答の方に合わせるべき領域まで生じうる
      結局のところ答えは、ML という分野がとにかく何とかして動こうとするものなので、欠陥があっても驚くほど先まで進めるということだ
      同時に、他人が見つけていない欠陥を突ければ大きなブレークスルーになる理由でもある
    • どのモデルがより良いかを見分ける用途なら、ベンチマークのスコアは 実性能との相関 さえあれば十分だ
      課題の大半が正しく採点されていれば、方向性は保てる
      たとえばラベルの 49% が間違っているひどいベンチマークでも、常に正答するモデルが 51%、常に誤答するモデルが 49% を取るなら、順位自体は依然として正しい
      ほとんどの機械学習ベンチマークには少なくない誤ラベルがあるが、モデル間の差を見分けることが目的なら、完全な採点保証に時間をかけるよりも、より大きなデータセットを集める方が普通は有利だ
    • 要するに、おおよそ 16% の問題 に問題があるということに読める