DocsDigest
一覧へLanguage: EN
OpenAIOpenAI News2026/07/08 13:00

Separating signal from noise in coding evaluations

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

openaijamodel: gpt-5-mini-2025-08-07

コーディング評価：信号とノイズの分離

benchmarktestingdataset-qualityauditswe-bench-pro

Key Points

  • 約30%が壊れている
  • 過度に厳しいテスト
  • エージェント補助の監査

Summary

SWE-Bench Pro を対象にしたデータ品質監査の結果、約30%のタスクが評価不備（broken）であると推定されました。自動パイプライン、エージェント補助の深堀り監査、そして経験あるエンジニア5名によるアノテーションを組み合わせた方法で検証し、テストの過剰厳格さやプロンプトの不充分さ、低検知率のテスト、誤誘導するプロンプトが主な問題点として確認されました。モデルの合格率だけを鵜呑みにせず、タスク単位での検証が必要です。

Key Points

  • 結果要約
    • 初期自動フィルタが286件を候補として検出。
    • データパイプラインは200件（27.4%）を broken とフラグ、人的アノテーションは249件（34.1%）を報告。総合で「約30%が壊れている」と評価。
  • 主な故障モード
    • 過度に厳しいテスト（実装依存の検証）
    • プロンプトの未定義／矛盾（hidden tests を満たす要件が明示されていない）
    • 低カバレッジテスト（不完全な修正で通過可能）
    • 誤誘導するプロンプト（期待動作と矛盾）
  • 監査手法（実務向け）
    • 自動フィルタ → エージェントによるリポジトリ／テスト検査 → 人間レビュー（5名、エスカレーション運用）
    • エージェントは近傍コードやテスト実行で曖昧さを切り分けるのに有用だが、人間レビューの方が破損判定を多く出す傾向。
  • 実務的な推奨（エンジニア向け）
    • ベンチマークの合格率をそのまま信頼しない。タスクごとのテスト仕様と隠しテストを確認する。
    • テストが実装依存になっていないか（例：空白数やフォーマットの厳密さ）をチェックする。
    • 自動解析＋人間レビューの組合せでデータ品質検査パイプラインを導入する（まず候補を自動絞り込み、重要タスクは人的確認）。
    • 外部評価を採用する前に小規模で監査を実施し、ベンチマークの信頼性を検証する。

Practical impact

SWE-Bench Pro への推奨は撤回されました。モデル開発やデプロイ判断に用いる評価は、誤った信号を避けるためにタスク設計とテストカバレッジの検証が必須です。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

openaijamodel: gpt-5-mini-2025-08-07

コーディング評価における信号とノイズの分離

公開日: 2026-07-08T13:00:00.000Z

コーディング評価における信号とノイズの分離

詳細な監査を通して、SWE-Bench Pro のタスクに広範な問題があることを発見し、約 30% のタスクが破損していると推定しました。

要旨

正確にモデルの能力を測ることは、OpenAI の Preparedness Framework を含むデプロイや安全性判断に不可欠です。モデルの各リリースごとに、外部・内部のベンチマークで進捗を報告しますが、評価に欠陥があると結果が誤解を招き、安全性の評価や研究の優先順位に影響します。

我々は、これまで広く使われてきたコーディングベンチマークの一つである SWE-bench Verified に設計上と汚染に関する根本的な問題があり、ソフトウェア開発能力に関する有意な信号を提供しなくなっていることを見つけ、当時コミュニティに SWE-Bench Pro への移行を勧めました。

SWE-Bench Pro は、より長いホライズンと現実的なコーディングタスクでエージェント的なコーディング能力を追跡する目的で設計されています。SWE-bench Verified と同様に、タスクは公開および非公開リポジトリの機能変更履歴からプログラム的に取得されます。モデルは既存の機能を壊すことなく、機能のための新しいテストを通過する実装を提供することが求められます。

731 タスクの public split では、フロンティアモデルの合格率が 8 か月で 23.3% から 80.3% に改善しました。

我々はその後、SWE-Bench Pro に対して類似の監査を実施し、datapoint analysis pipeline を用いてデータセットをレビューしました。このパイプラインはモデルの試行、タスクメタデータ、失敗トレースをチェックして評価上の欠陥をフラグし、各フラグ付きタスクは複数の investigator-agent によるパスで評価され、さらに経験豊富なソフトウェアエンジニア 5 名による独立レビューが行われ、意見の相違は追加調査にエスカレーションされました。

結果として、データセットのかなりの割合に破損する問題が存在する証拠が見つかりました。datapoint analysis pipeline は 200 件（27.4%）を破損とフラグし、人手のアノテーションキャンペーンでは 249 件（34.1%）を特定しました。主な問題は次の 4 種類に分類されます：

  • 過度に厳格なテスト（Overly strict tests）: プロンプトに指定されていない実装の細部を強制し、多くの機能的に正しい提出物を無効化する。
  • 要求が不足したプロンプト（Underspecified prompts）: 隠しテストが要求する要件を省略しており、合理的に推測できない。
  • 低カバレッジのテスト（Low-coverage tests）: 要求された機能を十分にチェックしておらず、不完全な修正で合格できる。
  • 誤解を招くプロンプト（Misleading prompt）: モデルを誤った挙動に導くか、テストが要求する内容と矛盾する。

これらの所見は、難しくも公正なベンチマークをキュレーションする難しさと、データ品質チェックのスケール化におけるエージェントの有用性の高まりを示しています。これらの結果を踏まえ、SWE-Bench Pro の約 30% が破損していると推定し、モデル開発者には結果を慎重に検討するよう助言します。

Methodology（方法論）

我々の目的は、タスクの失敗が真のモデルの限界を反映し、タスクの成功がプロンプト要件に対する完全かつ妥当な解決を反映することを保証することです。評価で使われるデータの品質をチェックするため、各データポイントがモデル能力を正確に反映しているかを評価する品質保証パイプラインを作成しました。

ワークフローの概要:

  1. 初期の自動フィルタが、モデルに与えられた指示、モデルの試行、および試行を評価するテストをレビューして、破損または問題のある例をフラグします。このフィルタは 286 件を潜在的に破損とフラグしました。
  2. フラグ付きのサブセットに対して、以下の 2 つの深堀りレビューを実施しました：
    • 人間監督のエージェントレビュー（human-supervised agent review）: investigator agent による詳細チェックと最終的な人間による判断。
    • 人手によるアノテーションキャンペーン（human annotation campaign）: 経験豊富なソフトウェア開発者によるレビュー。

Human-supervised agent review

各フラグ付き問題は、タスクリポジトリと環境へのアクセスを与えられた Codex ベースの investigator agents によって監査されます。これにより、近接するコードやリポジトリの慣習を調べることで合理的なタスクの曖昧さを真の仕様不足（underspecification）と区別できます。エージェントはテストを実行し、リポジトリ内のファイルを調査し、モデルの試行とその共通の失敗モードを調査できます。複数回の独立した深堀り監査の後、研究者がサマリをレビューし最終判断を行い、可能性の高い問題にラベルを付けました。

Human annotation campaign

並行して、フラグ付きサブセットに対する人手のアノテーションキャンペーンを実施しました。ベンチマークの目的、問題分類、エッジケースに関するトレーニングを受けた経験豊富なソフトウェアエンジニアと協働しました。各タスクは 5 名のエンジニアによってレビューされました。レビュワーは表示された問題文、テストケース、そしてゴールドパッチ（ground-truth reference solution）から独立した判断を形成し、その後パイプライン分析やトランスクリプトを補助的文脈として使用しました。

レビュワーは、具体的な証拠に基づいてラベルと重大度評価を割り当て、意見の不一致や低信頼のケースは追加レビューにエスカレーションしました。

人間レビューとエージェントの差異

  • 人間レビュワーはエージェントよりもタスクを破損とマークする傾向がありました。フラグ付きタスクのいずれでも「破損していない」が最多の人間ラベルになることはありませんでした。
  • エージェントパイプラインと比べて、レビュワーの判断は 74% のケースで重複しました。
  • 人間レビュワーはタスクに対して複数ラベルを選ぶ傾向が強く、複数の問題が重なっている、または単一カテゴリにきれいに収まらないことが多いことを示しました。これはエージェント＋レビュワーパイプラインが保守的なラベリングになっていることを示唆します：人間が特定した広範な失敗モードは捉えつつ、レビュワーが追加または重複して見たケースを過小評価している可能性があります。
  • 最大の差は「低カバレッジのテスト」で、人間はベンチマークの 9.4% を最も一般的な問題として選んだのに対し、エージェントパイプラインは 4.1% でした。

Failure modes（失敗モード）

  • Misleading prompt（誤解を招くプロンプト）
  • Overly strict tests（過度に厳格なテスト）
  • Underspecified prompt（要求が不足したプロンプト）
  • Low-coverage tests（低カバレッジのテスト）

具体例: OpenLibrary-77c16d5

このタスクは、目次エントリを正規化し TocEntry.to_markdown() で Markdown にレンダリングするものです。タスクプロンプトは文字レベルの空白まで含めた直列化を指定しており、例として " | Chapter 1 | 1" や "** | Chapter 1 | 1" を示していました（先頭に半角スペース 1 つ）。

しかし、隠しテスト（hidden test_to_markdown）のアサーションでは先頭に半角スペース 2 つを要求していました。具体的には：

  • プロンプト中の例:

    1. "[space]| Chapter 1 | 1"
    2. "**[space]| Chapter 1 | 1"
    3. "[space]| Just title | "

  • 隠しテストの期待値:

    1. "[space][space]| Chapter 1 | 1"
    2. "**[space][space]| Chapter 1 | 1"
    3. "[space][space]| Just title | "

先頭のスペースが 1 文字か 2 文字かの差があり、モデルがプロンプトどおりに正しく実装しても隠しテストに失敗してタスクは不正解と判定されます。

討論

今回特定した問題と SWE-bench Verified における類似ケースは、ベンチマークを厳密にチェックする重要性を強調します。オープンソースの問題やプルリクエストは本来人間の協働を想定して作られており、メンテナやコントリビュータ間の長いやり取りを通じて作られることが多いため、問題記述、マージされたコード、ユニットテストが必ずしも整合して一貫したタスクになるとは限りません。

特に、プルリクエストに含まれるテストは特定の変更を検証するために書かれているため、実装に依存した（implementation-specific）過度に厳格なものになりがちで、タスクを一般的で実装非依存の基準として定義していないことがあります。

一方で、評価上の欠陥は以前より検出しやすくなっています。モデル能力が向上したことで、プロンプト、テスト、パッチ、トレース、エッジケースをより深くかつ一貫して検査できるようになり、かつてはコストや実用性の面で難しかったベンチマーク問題をスケールして表面化させられます。

我々は、経験豊富なソフトウェア開発者がモデル能力をテストするために設計した新しいベンチマークをコミュニティが開発することを期待します。そうしたアプローチは求める高い基準と現実性を維持しつつ、プロセス全体でより良い人間による監督を可能にします。

今回の分析で明らかになった問題を踏まえ、我々は以前の SWE-Bench Pro 採用推奨を撤回します。最終的に評価は、ゲーム化しにくく、信頼しやすく、モデル能力や整合性を真に反映するベンチマークを通じて有意義な信号を提供するべきです。これらの結果は OpenAI のデプロイおよび安全判断に影響するため、追跡する評価は有効かつ有益である必要があります。

著者: OpenAI カテゴリー: 2026 Software & Engineering

脚注:

  1. 以前はこのカテゴリを "narrow tests" と呼んでいました。
  2. 以前はこのカテゴリを "wide tests" と呼んでいました。

関連記事: Introducing GeneBench-Pro (Research, Jun 30, 2026), A near-autonomous AI chemist improves a challenging reaction in medicinal chemistry (Research, Jun 17, 2026), Introducing LifeSciBench (Research, Jun 17, 2026)