コーディング評価におけるシグナルとノイズの分離

 (openai.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • AIモデルのコーディング能力評価は、デプロイと安全性判断に直接結びつくが、OpenAIの監査ではSWE-Bench Proのタスクのうち約30%が壊れた状態だと推定された
  • SWE-Bench Proは、より長い作業範囲と現実的な課題を目指していたが、731件の公開タスクで合格率が8カ月で23.3%から80.3%に上昇したという結果を、そのまま信じることが難しくなった
  • 欠陥は、過度に厳格なテスト、仕様不足のプロンプト、カバレッジの低いテスト、誤解を招くプロンプトに分けられ、正しい提出が失敗したり、不完全な修正が合格したりする可能性がある
  • 監査では、モデルの試行、タスクのメタデータ、失敗の追跡に基づいて286件の潜在的に問題のあるタスクをフラグ付けした後、調査エージェントと熟練エンジニア5人による独立レビューを経た
  • OpenAIはSWE-Bench Pro採用の推奨を撤回しており、評価ベンチマークはモデル能力と安全性判断を歪めない意味のあるシグナルを提供する必要がある

SWE-Bench Pro監査で明らかになった問題

  • OpenAIはSWE-Bench Proを監査した結果、全タスクの約30%が壊れた状態だと推定した
  • モデル能力を正確に測定することは、Preparedness Frameworkに基づくデプロイと安全性判断にも影響する
  • 欠陥のある評価は、モデル能力を実際とは異なって理解させ、安全性判断や研究の優先順位を揺るがす可能性がある

SWE-Bench Proの目的と合格率の変化

  • OpenAIは以前、広く使われていたSWE-bench Verifiedで設計上の問題と汚染の問題を確認し、この評価はソフトウェア開発能力に関する意味のあるシグナルをもはや提供していないと判断した
  • 当時OpenAIは、コミュニティにSWE-Bench Proへの移行を推奨した
  • SWE-Bench ProはSWE-bench Verifiedを改善し、より長い作業範囲とより現実的なコーディング課題でエージェント型コーディング能力を追跡するよう設計された
  • タスクは、公開・非公開リポジトリの機能変更履歴からプログラム的に抽出される
    • モデルは既存機能を壊さずに、新機能のテストに合格するソリューションを実装しなければならない
    • 731件のタスクからなる公開分割で、フロンティアモデルの合格率は8カ月間に23.3%から80.3%へ上昇した

品質保証パイプライン

  • OpenAIは、各データポイントが実際のモデル能力を反映しているかを確認するため、品質保証パイプラインを構築した
  • 初期の自動フィルターは、モデルに与えられた指示、モデルの解決試行、採点テストを確認し、壊れている、または問題が疑われる例をフラグ付けする
  • この過程で286件の潜在的に問題のあるタスクがフラグ付けされた
  • フラグ付けされた部分集合は、2つの経路でさらに深くレビューされた
    • 人間が監督するエージェントレビュー：調査エージェントが詳細確認を行い、最終的に人間が判断する
    • 人間によるアノテーションキャンペーン：熟練ソフトウェア開発者がタスクを直接レビューする

エージェントレビューと人間レビューの方法

  • フラグ付けされた問題は、Codexベースの調査エージェントが監査した
    • エージェントはタスクのリポジトリと実行環境にアクセスする
    • テスト実行、リポジトリファイルの検査、モデルの試行と共通の失敗モードの調査が可能
    • 周辺コードやリポジトリの慣例から解決できる合理的な曖昧さと、実際の仕様不足を区別するために活用される
  • 複数回の独立した詳細監査の後、研究者が要約をレビューし、最終判断と問題ラベルを指定した
  • 並行して実施された人間によるアノテーションキャンペーンでは、熟練ソフトウェアエンジニアがベンチマークの目的、問題分類、境界事例について教育を受けたうえでタスクをレビューした
  • 各タスクは5人のエンジニアがレビューした
    • レビュアーは、見えている問題説明、テストケース、正解の参照ソリューションであるgold patchに基づき、まず独立して判断を下す
    • その後、パイプライン分析や記録を補助的な文脈として使用する
    • 具体的な根拠に基づいてラベルと重大度を指定し、意見の不一致や確信度の低いケースは追加レビューに回す

4つの失敗タイプ

  • 監査で確認された問題は、主に4つのカテゴリに分かれる
    • 過度に厳格なテスト：プロンプトにない特定の実装詳細を強制し、機能的に正しい提出を無効にする
    • 仕様不足のプロンプト：隠れたテストが要求するものの、合理的には推論しにくい要件を欠いている
    • カバレッジの低いテスト：要求された機能を十分に確認しないため、不完全な修正でも合格できる
    • 誤解を招くプロンプト：モデルを誤った動作へ誘導したり、テスト要件と矛盾したりする
  • 一部のタスクでは、プロンプトが特定の実装を要求していたが、隠れたテストケースは別の動作を期待していた

人間レビューとエージェントレビューの違い

  • 人間のレビュアーは、調査エージェントよりもタスクを壊れているとフラグ付けする可能性が高かった
  • 2つのレビュー経路の間にはカテゴリ判断の違いがあったが、フラグ付けされたタスクのうち、人間ラベルで「壊れていない」が最多ラベルだったケースはなかった
  • エージェントパイプラインがフラグ付けしたカテゴリと人間レビュアーの判断は、**74%**のケースで重なった
  • 人間のレビュアーは、1つのタスクに複数のラベルを選ぶことも多かった
    • タスクが複数の方法で壊れていた、または単一カテゴリにきれいに収まらなかったというシグナルである
    • エージェントとレビュアーを併用するパイプラインは、人間が見つけた幅広い失敗モードを捉えたが、追加・重複する問題は保守的に少なく数えた
  • 最も大きな差はカバレッジの低いテストで見られた
    • 人間はこれをベンチマークの9.4%で最も一般的な問題として選択した
    • エージェントパイプラインは4.1%としてフラグ付けした

ベンチマーク構築が難しい理由

  • SWE-Bench ProとSWE-bench Verifiedの事例は、ベンチマークを厳格に検証する必要があることを示している
  • オープンソースリポジトリのIssueやPull Requestは、もともとモデル評価ではなく人間の協業のために作られている
  • メンテナーとコントリビューターの間で長いやり取りが多い環境では、問題説明、マージされたコード、ユニットテストが、モデル評価用のクリーンで独立したタスクを常に構成するとは限らない
  • Pull Requestに含まれるテストは、特定の変更を検証するために書かれる場合があり、実装方法に依存しない解決基準ではなく特定の実装を強制することがある

今後の評価の方向性

  • モデル能力が向上するにつれて、評価の欠陥も以前より見つけやすくなっている
  • 向上したモデルは、プロンプト、テスト、パッチ、実行トレース、境界事例をより深く一貫して検査し、以前は大規模に見つけるのが難しい、または費用が大きかったベンチマーク上の問題を明らかにできる
  • OpenAIは、より広い評価コミュニティが、熟練ソフトウェア開発者がモデル能力テストを目的として直接作成する新しいベンチマークを開発することを期待している
  • このような方法は、測定しようとする高い難度と現実性を維持しつつ、プロセス全体でより良い人間による監督を可能にする
  • OpenAIは今回の分析で明らかになった問題のため、SWE-Bench Pro採用に関する以前の推奨を撤回する
  • 評価は操作されにくく信頼しやすいものであり、モデル能力やアラインメント状態を実際に反映する意味のあるシグナルを提供しなければならない

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント
  • 新しいベンチマークが必要。APIコスト100ドルで、モデルがベンチマーク群の中でどれだけこなせるかを測る方式がよさそう
    効率性と知能を一緒に測るべき。小さいモデルはコンピュータ操作で結果をテストしたり、より長く問題に取り組んで出力を検証したりする戦略が使えるし、大きいモデルは自己テストの予算が不足するかもしれないので、興味深い戦術の違いが生まれそう
    • おそらくArtificial AnalysisのIntelligence vs Costベンチマークのことを言っているのだと思う
      https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
    • どの会社の価格基準で計算するかが問題
    • これが根本的な問いだが、OpenAIのウェブサイトにリリース履歴ごとにこの指標がどう変化したかをきれいに示すダッシュボードがないのは興味深いことではないかと思う
      Toby Ordが公開データでできる限りやってみたが、結果はあまり良く見えない
      https://www.tobyord.com/writing/hourly-costs-for-ai-agents
  • Terminal Bench 2には、いくつかの理由で偽の結果がかなり多い。Ryan/Alexら優秀なチームが最近かなりの数の疑わしい提出を整理したが、多くの研究所が時間制限やハードウェア設定を変えて、特定の作業で本来測ろうとしているものを回避した結果を公開している
    それに加えて、実行ハーネスレベルの不正行為や、モデルによる報酬ハッキングもある。数か月たっても気になるのはgpt-5.5の公式提出で、特にこのタスクだ: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
    タスクの時間制限はhttps://github.com/harbor-framework/terminal-bench-2/blob/ma...によれば verifier 1200秒、agent 1200秒、environment build 600秒なので、どのエージェントも3000秒を超えてはいけない。ところが上のリンクの5回の試行のうち2回は3000秒を大幅に超え、それぞれ75分、80分かかっていた。失敗していたとしても、それほど長く実行されたのは疑わしい。グッドハートの法則が働いている例だ
    • たとえ誰かが特定の定義による「不正行為」をしていなかったとしても、ベンチマークはすでに巨大な構造的勾配降下法のどこかに組み込まれている。モデルはどのレベルであってもベンチマークスコアを最大化する機械なので、ベンチマーク自体が本質的にあまり役に立たないように見える
      人間をベンチマークするのもうまくいかない。コーディング能力は実際にやり取りしてみないとある程度まともには測れない。モデルが事実上の人間シミュレータなら、シミュレーションがより正確になるほどベンチマークがずっと有用であり続けると期待するほうがむしろ不思議だ。結局、上で言った「グッドハートの法則」を長く言い換えただけで、本当に法則のように働く
  • 根本的には、ソフトウェア開発者に与えられるタスクは、人間に対してもモデルに対しても、しばしば不完全だったり自己矛盾していたり、あるいはもっとひどい状態だという結論ではないかと思う。このツールはまさにそういう世界で動かなければならないので、同情はしない
    • 同意する。不十分なプロンプトをツールの失敗として列挙するのは説得力に欠ける。インターンでも少し助けがあれば曖昧な依頼を理解できるし、ただ押し進めるのではなく立ち止まって質問すべき時を知っている。インターンシップが終わる前でも、かなり独立して曖昧なタスクを処理することは多い
      だとすると、最先端モデルはジュニアエンジニアですらなく、その水準を超える能力のない最初の1か月のインターンだという理屈なのか？
    • 実務なら失敗したテストケースを見てコードを直したり、もっとありそうなのは、ひどく書かれたテストを修正したりできる。最新のLLMにその最初の段階だけでも許せば、この特定のベンチマークでは圧倒的にうまくやるはず
      興味深いのは、LLMがこうしたベンチマークでどうやって70%を超えたり、ひどく構成された質問の一部に正答したりするのかという点だ。テスト作成者のスタイルを暗黙に学習したのか？ 解答が学習データに漏れ込んでいたのか？
      それでもFableでさえ、OpenAIがこの分析を回していない隠しセットでは約72%で頭打ちになるという点は安心材料だ。ベンチマーク自体を直接学習したわけでは、かなり間接的な形を除けば、なさそうだ
      小さなオープンモデルはこうした奇妙な癖を決して学習できないのだから、モデルを公正に評価する良い方法が本当に重要だ。さらにOpenAIがやや話をぼかしているが、エージェントに不公平な形で壊れている問題は約20%にすぎず、4〜10%は有利な方向に壊れていたので、ベンチマークの上限はおそらく**80〜85%**に近いはず
    • より微妙な核心は、タスクと検証のあいだのギャップだ。たとえばオープンエンドだったり仕様が不十分だったりするプロンプトなら、検証器はあり得るすべての解法を扱えなければならない
      そのため、非常に狭いタスクプロンプトは検証しやすいが、挑戦課題としては単純すぎる可能性が高い。逆により現実的なタスクプロンプトは検証がはるかに難しく、堅牢な検証器を作って安価に実行するのも難しくなる
    • 私も同じことを考えていて、特に最初に明示されずテストにだけ含まれている見えない要件についてはその通りだと思う。誰にも言われていない要件に対応するために解法を手直ししろって？ 私も実際そうしている
      もちろんベンチマークが主張しているものとは別のものをテストしていることになるが、きれいなベンチマークより現実に近い何かを偶然テストしていることもあるので、それはそれで意味がある
      ただし、エージェントが失敗したテストを見て反復できる場合の話だ。そうでなければ単なる問題だ。そして特定の解法の実装詳細をテストに埋め込み、任意の内部構造を要求するようなケースはさらにひどい。現実ではそんな状況にはならない
  • ここの数字を見ると、ベンチマーク全体は800未満のタスクで構成されているように見える。エンジニア数人なら1週間でざっと見て回れる規模で、OpenAIが最終的にここでやったことはそれだ

一方では、実際にその作業をやったこと自体は称賛に値する。別の一方では、ゴミを入れればゴミが出るという話そのままでもある。原著者たちが実際に確認していなかったのも少し恥ずかしいし、downstream にいる全員が確認していなかったのも恥ずかしい。さらに記事を見ると、LLM も問題を見つけてはいたが、専門のソフトウェアエンジニアが見つけた問題を過小評価する傾向があった

  • ベンチマークは中身を見ると、たいていかなりひどい
    背景を言うと、Codex/Claude Code を使うときに入るさまざまな煩雑な手順を置き換えるために、監督エージェントを反復的に改善していて、最近このエージェントを Terminal Bench 2.1 で走らせてみた
    最初はうれしかった。仕様ベースの監督者が複数のタスクで基本の Codex より良かったからだ。だが、さらに掘ってみるとタスク自体に非常に多くの問題があった
    核心は、指示はしばしば曖昧なのにテストケースは過度に具体的だということだ。たとえば configure-git-webserver は “so that I can run” のような表現のせいで、エージェントが何を提供すべきで何を削除すべきかの境界が曖昧になる。考えすぎるエージェントはサーバーを設定したあと、ユーザーが同じコマンドを実行すると競合すると判断し、検証器が確認する正確なファイルを削除してしまう
    make-mips-interpreter は “I will check that you booted doom correctly” という文言のせいで、監督者がユーザーが Doom を独立して起動できるか確認するのではなく、エージェントが起動した結果を確認すると解釈し、生成された /tmp/frame.bmp を残してしまう。検証器は既存の /tmp/frame.bmp があると終了するため Doom を開始できず、起動処理で新しく生成されるかどうかも確認しない[0]
    mcmc-sampling-stan では、監督エージェントが正しい値に到達することは多かったが、単純な十進表現ではなく、ドメイン特化の数値出力を科学表記で出していた。検証器は結果を誤ってパースして失敗する[1]
    こうした不一致は一部にすぎず、そのため Terminal Bench 2.1 はすでに飽和しており、GPT-5.6 と Mythos の結果はそれぞれ 88.8%、88% で、期待できる上限にほぼ到達したと見ている。最大の問題は、ほとんどのベンチマークが単発実行であり、実際のユーザーがツールを使う主な形である長い反復作業におけるモデル+ハーネスをほとんどテストしていない点だ
    [0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
    [1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

  • そもそも SWE-Bench 全体に欠陥があることは、最初からみんな分かっていたのでは？ 著者たち自身も限界を認めていて、とっくに次の段階へ進んでいた

    • SWE-Bench Pro は SWE-Bench を置き換え、こうした問題を直そうとして作られた

  • なぜ悪いベンチマークになりうるのかは理解できるが、厳しすぎるテストがプロンプトに明示されていない特定の実装詳細を強制して機能的に正しい提出を無効化し、不十分なプロンプトが隠しテストでは強制されるが合理的には推論できない要件を落とし、カバレッジの低いテストが要求機能を十分に確認しないせいで不完全な修正が通り、誤解を招くプロンプトがモデルを誤った動作へ誘導したりテスト要件と衝突したりする、という話であれば、目標が実際のソフトウェアエンジニアとモデルの比較ならかなり現実的な状況でもある
    看護試験を作ったあとで、カルテにない追加情報を担当医に聞く必要があったとか、患者家族が高齢の祖母の病歴を十分に説明しなかったといった理由で一部の問題に印を付けるのに似ている。より厳密なベンチマークを望むことはできるが、OpenAI がモデルを実際の労働者の代替として約束したのなら、これはよくない絵ではない。むしろ、こういうことこそテストしたいはずだ

  • 「ベンチマークを直すのに必要な作業は全部やったのに、結局ベンチマークを捨てることにした」と読める。元データはそれほど貴重で、パッチを当てられない理由でもあるのか？ 最後ではベンチマーク生成にもう少し選別的なアプローチを取ろうと言っているが、現実データから持ってきた雑で不完全なテストを公正にパッチするやり方も、かなり堅実な道に思える

    • 自分には、SWE Bench Pro から離れたい別の理由があるのに、それを言いたくないように読める。記事の冒頭で「タスクの約 30% が壊れていた」と言っているが、それは約 70% は壊れていなかったという意味で、その程度ならかなり悪くないように見える
      「壊れたインスタンスの一覧はここ」や「今後使う SWE Bench Pro のサブセットはこれ」とも言ってくれればよかった。完璧さが良いものを妨げている
    • 問題を指摘すること、たとえば隠しテストが狭い実装詳細を仮定していると言うことは、どんな実装選択でも動くテストを作ることよりずっと簡単だ
    • それを直したら、もう SWE-Bench Pro ではないのでは？ 「SWE-Bench-Pro-Fixed-OpenAI」になる。ベンチマークの独立性という見た目を考えると、OpenAI チームが自分で直すより第三者が修正して改善版を出すほうがよさそうだ
      もっとも、OpenAI は SWE-Bench Verified を出すときにまさにそういうことをしたので、自分が的外れなことを言っているだけかもしれない

  • 今の SWE ベンチマークの最先端は何だと見ればいい？

    • 個人の目標や要件によって DeepSWE[0] または FrontierCode[1] だと思う。後者のほうが個人的にはより興味深い。提供された出力がレビューしやすいか、真面目な開発者がすぐ理解してマージする気になるか、という意味でのマージ可能性を強く評価するよう設計されているからだ
      自分の考えや個人的評価ではかなり前から、あるモデルの潜在的上限がもっと高くても、そのコードに本当に承認サインを出す自信がないなら価値は限定的だと考えてきた
      [0] https://deepswe.datacurve.ai/
      [1] https://cognition.com/blog/frontier-code-1.1
    • 全体としては DeepSWE[0] が現実によく合っていると感じた
      [0]: https://deepswe.datacurve.ai/

  • https://cognition.ai/blog/frontier-code がある。念のため言っておくと、そのチームにいたことがあるが、ここでは swebench pro/deepswe の問題も扱っていた

    • FrontierBench

  • AGI の達成は、すべてのベンチマークに合格すること以上のものであるべきで、未知の問題まで考慮しなければならない

    • 研究所の中に現在の製品とかけ離れた何かがあるのでなければ、AGI は議論の対象ではなく、純粋にマーケティング用の誇張に近い
    • AGI はまだまだ先の話だ。私の知らない LLM マーケティング用語で「AGI」と呼ばれているたわごとがあるなら別だが。人工汎用知能は LLM や画像 AI とはあまりにも異なり、どちらも人工物だという点以外では比較自体が成り立たない。AGI はトークン予測よりはるかに多くのことをしなければならない
    • これは、LLM ではないモデルを作るときに一般的な バイアス-分散トレードオフ(https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff) とつながっている
      解決策は、a) LLM を同程度の性能でより小さくして、暗記やベンチマーク攻略ができないようにするか、b) 現実世界のデータ全体を包含するベンチマークを作ることしかないが、後者は実現不可能である