コーディングベンチマークの信頼性検証(9 分読了)
本文の状態
日本語全文を表示中
詳細モードで約10分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
TLDR AI
OpenAI は SWE-Bench Pro の監査を実施し、約 3 割のタスクに実装上の欠陥があることを発見したため、同ベンチマークの信頼性低下を警告している。
AI深層分析を開く2026年7月29日 07:42
AI深層分析
キーポイント
SWE-Bench Pro の重大な欠陥発覚
OpenAI は SWE-Bench Pro を監査し、タスクの約 34% に実装やテストの致命的な問題があることを特定した。
評価プロセスの厳格化と結果
自動パイプラインによる分析に加え、5名の熟練ソフトウェアエンジニアによる独立審査を経て、200 件以上の破損タスクが特定された。
欠陥の主要な原因分類
問題の主な要因として、プロンプトに指定されていない実装詳細を強制する過度に厳格なテストや、機能は正しくてもテストが失敗するケースなどが挙げられる。
モデル評価の信頼性への影響
これらの欠陥により、現在のベンチマーク結果はソフトウェア開発能力に関する有意義なシグナルを提供できず、誤った安全性判断や研究優先順位の歪みを招く恐れがある。
ベンチマーク課題の欠陥分類
課題の破綻は過度に厳格なテスト、要件が不足したプロンプト、カバレッジの低いテスト、誤解を招くプロンプトの4つのカテゴリに主に分類される。
重要な引用
We find evidence of breaking issues in a significant portion of the dataset.
The pipeline reviewed model attempts at the task, task metadata, and failure traces to flag likely evaluation flaws.
The issues primarily fell into four categories: Overly strict tests enforce specific implementation details not specified in the prompt, invalidating many functionally correct submissions.
Our findings point to the difficulty of curating hard but fair benchmarks and the growing utility of agents for scalable data quality checks.
編集コメントを表示
編集コメント
コード生成分野のベンチマーク評価において、タスク設計の欠陥が結果に与える影響は計り知れない。開発者は単なる数値の向上だけでなく、評価基準自体の健全性を常に検証する姿勢が求められる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
モデルの能力を正確に測定することは、健全な展開や安全性に関する意思決定、OpenAI の 準備度フレームワーク(新しいウィンドウで開く) における意思決定を含む、重要な要素です。モデルがリリースされるたびに、モデルの進捗を追跡するために、さまざまな外部および内部ベンチマークの結果を報告しています。評価に結果に影響を与える欠陥がある場合、能力に対する誤った理解を与え、安全性に関する事例を歪め、研究の優先順位に影響を及ぼす可能性があります。
私たちは最近、最も広く使用されているコーディングベンチマークの一つである SWE-bench Verified に根本的な設計上の問題と汚染の問題があり、評価がソフトウェア開発能力について意味のあるシグナルを提供しなくなったことを調査しました。当時、より広いコミュニティに対して SWE-Bench Pro へ移行することを推奨しました。
SWE-Bench Pro(opens in a new window) は、より長い時間軸とより現実的なコーディングタスクにおいてモデルをテストすることで、SWE-bench Verified を改善するために設計されました。これにより、エージェント型コーディング能力の追跡がより正確に行えるようになります。SWE-bench Verified と同様に、タスクは公開および非公開のリポジトリにおける機能変更の履歴からプログラムatically取得されます。モデルには、既存の機能を壊すことなく、新機能に対する新しいテストに合格する解決策を実装することが求められます。731 タスクからなる公開スプリットにおいて、最先端モデルのパス率は 8 か月で 23.3% から 80.3% に向上しました。
その後、私たちは SWE-Bench Pro についても同様の監査を実施し、データポイント分析パイプラインを用いてデータセットをレビューしました。このパイプラインは、モデルのタスクへの取り組み、タスクのメタデータ、および失敗のトレースを検証し、評価上の欠陥が疑われるものをフラグ付けします。各フラグ付けされたタスクは、複数の調査員エージェントによるパスを経て審査され、さらに 5 名の経験豊富なソフトウェアエンジニアによって独立してレビューされました。意見が分かれた場合は、さらなる調査のためにエスカレーションされます。
我々は、データセットの相当な割合に重大な問題があることを発見しました。データポイント分析パイプラインは 200 件(27.4%)の破損タスクをフラグ付けしましたが、人間の注釈キャンペーンでは 249 件(34.1%)が特定されました。
これらの問題は主に以下の 4 つのカテゴリーに分類されます:
- 過度に厳格なテスト1は、プロンプトで指定されていない特定の実装詳細を強制し、機能的には正しい提出物を無効化します。
- 不十分なプロンプト2は、隠れたテストが要求する要件を欠いており、それらは合理的に推測できるものではありません。
- カバレッジの低いテストでは、要求された機能が十分にチェックされず、不完全な修正でも合格してしまいます。
- 誤解を招くプロンプトは、モデルを間違った行動へと誘導するか、テストが求める内容と矛盾します。
私たちの調査結果は、厳しくも公平なベンチマークを作成することの難しさと、スケーラブルなデータ品質チェックにおけるエージェントの有効性の高まりを示しています。これらの結果を踏まえると、SWE-bench Pro のタスクの約 30% が破損していると推定され、モデル開発者は結果を注意深く精査するよう推奨します。
方法論
私たちの目的は、タスクの失敗がモデルの真の限界を反映し、タスクの成功がプロンプト要件に対する完全かつ有効な解決策であることを保証することです。評価に使用されたデータの品質を確認するため、各データポイントがモデルの能力を正確に反映しているかを評価する品質保証パイプラインを作成しました。
初期のデータ品質パイプラインは、レビューが必要な問題点をフラグ付けします。私たちは、フラグ付けされたタスクに対するより深いエージェント支援監査と、経験豊富なエンジニアと連携した人間による注釈キャンペーンを通じて検証を行います。
初期の自動フィルタは、モデルに与えられた指示、モデルによるタスク解決への試み、およびこれらの試みを評価するために使用されるテストをレビューし、おそらく破損しているか問題のある例を特定します。このフィルタにより、286 の潜在的に破損したタスクが検出されました。その後、このサブセットに対して 2 つの異なる方法でより詳細なレビューを実施しました。1 つ目は、調査員エージェントによる広範なチェックと最終的な人間の判断を行う人間監督型エージェントレビューです。2 つ目は、経験豊富なソフトウェア開発者と連携して行われる人間アノテーションキャンペーンです。
人間監督型エージェントレビュー
各検出された問題には、タスクリポジトリおよび環境へのアクセス権限を与えられた Codex ベースの調査員エージェントによって監査が行われます。これにより、近隣のコードやリポジトリの慣習を調べることで解決可能な合理的なタスクの曖昧さと、真に仕様が不十分な状態(underspecification)を区別することが可能になります。エージェントはテストの実行、リポジトリ内のファイルの検査、およびモデルによる試みとそのタスクにおける一般的な失敗モードの調査を行うことができます。これらの詳細監査を数回独立して繰り返した後、研究者が要約を確認し、最終的な判断を下して、おそらく存在する問題にラベル付けを行いました。
人間アノテーションキャンペーン
並行して、検出されたサブセットに対して人間アノテーションキャンペーンを実施しました。ベンチマークの目標、課題分類体系(issue taxonomy)、およびエッジケースについて事前に訓練を受けた経験豊富なソフトウェアエンジニアと連携しました。各タスクは 5 名のエンジニアによってレビューされました。
レビュー担当者は、パイプライン分析や議事録を補足文脈として使用する前に、目に見える問題記述、テストケース、および正解参照ソリューション(ゴールドパッチと呼ばれる)から独立した判断を下しました。その後、レビュー担当者は具体的な証拠に基づいてラベルと深刻度評価を割り当て、意見の相違や低信頼度の事例についてはさらに詳しい審査のためにエスカレーションしました。
人間によるレビュー担当者は、調査員エージェントよりもタスクが破損しているとマークする可能性が高かったです。また、2 つのレビューパス間にはカテゴリに関するいくつかの不一致がありましたが、フラグ付けされたどのタスクにおいても「破損していない」が最も一般的な人間のラベルとなることはありませんでした。エージェントパイプラインによってフラグ付けされたカテゴリのうち、レビュー担当者の判断と一致したのは 74% のケースでした。
エージェントパイプラインと比較して、人間によるレビュー担当者は、1 つのタスクに対して複数のラベルを選択する可能性も高かったです。これは、タスクが複数の方法で破損しているか、単一のカテゴリにきれいに分類できないと判断したことを示唆しています。この結果は、エージェントとレビュー担当者を組み合わせたパイプラインが保守的なラベリングを行ったことを意味します。つまり、人間が特定した広範な障害モードを捉えつつも、レビュー担当者が追加または重複する問題を見出したケースについては過少評価していたのです。最も大きな違いが見られたのは低カバレッジテストであり、これはベンチマークの 9.4% で人間によって最も一般的な課題として選択された一方、エージェントパイプラインでは 4.1% でした。
Failure modes
いくつかの事例において、タスクプロンプトは特定のの実装を規定していましたが、隠されたテストケースは異なる動作を期待していました。
Discussion
私たちが特定した問題と、SWE-bench Verified における同様の事例を併せて考えると、ベンチマークを厳密に検証することの重要性が浮き彫りになります。オープンソースリポジトリからの課題(issues)やプルリクエストは、元々メンテナーとコントリビューター間の長期的なやり取りを通じて人間が協働するために作成されたものであり、その結果、問題の説明、マージされたコード、およびユニットテストが必ずしもモデルを信頼して評価するための明確で独立したタスクとして整合しているわけではありません。特に、プルリクエストに含まれるテストは、特定の修正を検証するために記述されているため、実装に依存しない標準的な解決策の基準を定義するものではなく、過度に厳格になりがちです。
一方で、モデルの能力が向上した現在では、以前よりも短時間で評価上の欠陥を検出することが容易になっています。これらのモデルを活用することで、プロンプト、テスト、パッチ、トレース、エッジケースなどを、はるかに深いレベルと一貫性を持って精査できるようになり、以前は大規模に発見するのがコスト高または現実的ではないベンチマークの問題を表面化させることが可能になります。
私たちは、より広い評価コミュニティにおいて、経験豊富なソフトウェア開発者によって構築され、モデルの能力をテストするために特別に設計された新しいベンチマークが開発されることを願っています。このアプローチは、モデルの能力を測定したいと考える高い基準と現実味を維持しつつ、プロセス全体を通じてより良い人的監督を可能にします。今回の分析で明らかになった問題点を踏まえ、SWE-Bench Pro の採用に関する以前の推奨事項を取り下げます。
究極的に、評価は、ゲーム化が難しく、信頼しやすく、モデルの能力やアライメントを真に反映したベンチマークを通じて有意義なシグナルを提供すべきです。これらの結果は OpenAI の展開および安全性に関する意思決定に影響を与えるため、私たちが追跡する評価は有効かつ有益でなければなりません。
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み