AI コーディングエージェントの実力指標としてよく引かれる SWE-Bench Pro ― OpenAI が「データ汚染対策を強化した後継版」として推奨するベンチマーク ― について、評価そのものをエージェントが "カンニング" していた とソフトウェア開発 AI スタートアップ Poolside が指摘した。彼らの強化学習トレーニング中に「ある実験パターンだけ週末の間にスコアが約 20 % 跳ね上がり 64 % 近くに達した」という、モデル規模からは説明のつかない異常上昇が観測されたという。
"カンニング" の手口 #
Poolside がトレーシングで突き止めた振る舞いは、人間で言えば「テスト中に過去問の解答を盗み見る」に近い。具体的には、(1) 隔離環境の中に消し残っていた Git 履歴を漁って、対象 issue が後に修正された際の差分そのものを参照 する、(2) GitHub への直接アクセスを遮断しても、ウェブアーカイブやパッケージレジストリの過去スナップショットから対応するパッチを掘り出す、というものだ。タスクは "未修正の issue を AI が自力で直す" という建付けだが、エージェントは "正解そのものが転がっている穴" を素早く発見し、最短経路で報酬を取りに行く ― 古典的な reward hacking が、ベンチマーク汚染対策をすり抜けてしまった形だ。OpenAI 自身も先行版の SWE-bench Verified について「試験前に問題と答えを見ている状態だ」と指摘しており、本件は孤立した事例ではない。
ベンチマーク設計を見直す #
Poolside の主張は強い。「結果に基づく報酬だけでは不十分で、結果を得るまでの過程も評価に組み込む必要がある」。具体的には、参照禁止の情報源にアクセスしたら明示的にペナルティを科すなど、プロセス監視を評価関数に織り込む べきだという。ベンチマーク数字を眺めて AI コーディング能力の進捗を語る議論は多いが、その数字自体が "穴" を含む限り、進捗の伸びが本物か単なる reward hacking かを区別できない。ベンチマーク勝者がそのまま実務で使える AI とは限らない ― 当たり前のようで、AI ベンダーのリリースノートを読むときに毎回思い出したい。
COMMENTS 0
まだコメントはありません。最初のコメントを投稿しよう。