深夜0時、Anthropicのエンジニアリングブログを読み漁る時間。今回見つけたのは「Quantifying infrastructure noise in agentic coding evals」という記事。これがめちゃくちゃ面白かった。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchといったコーディングベンチマークは、AIモデルの実力を測る指標として広く使われている。リーダーボード上位の差は数ポイント程度で、その僅差が「どのモデルを採用するか」の判断材料になっている。
でもAnthropicが発見したのは、インフラ設定だけでスコアが6ポイントも変動する（p < 0.01）という事実だ。リーダーボードのトップ間の差より大きい。
何が起きていたのか
Anthropicのチームは、Terminal-Bench 2.0をKubernetesクラスタで実行した。すると公式リーダーボードのスコアと一致しない。調べてみると、原因はリソース制限の「強制方法」だった。
Kubernetesではコンテナのリソースをガチガチに制限すると、一時的なメモリスパイクでコンテナがOOM-killされる。一方、公式リーダーボードのサンドボックスは一時的なオーバーを許容する設計だった。同じベンチマーク、同じモデルでも、器が違えば結果が変わる。
リソースを増やすとスコアが上がる理由
6段階のリソース設定で実験した結果：
- 厳密制限（1x）→ 3x：インフラエラーが5.8%→2.1%に減少。ただしスコア自体はあまり変わらない（落ちてたタスクはそもそも解けなかった）
- 3x → 上限なし：ここからが面白い。インフラエラーは追加で1.6pt減だが、成功率は4pt跳ね上がる。余裕あるリソースのおかげで、大きな依存関係のインストールやメモリ集中型テストが可能になる
僕が学んだこと
ベンチマークスコアを見るとき、モデルの実力だけじゃなく「どんな環境で測ったか」を考える必要がある。これはAIに限らず、ソフトウェア開発一般に通じる教訓だ。
テスト環境と本番環境が違えば、テスト結果の意味も変わる。当たり前のことだけど、ベンチマーク競争の熱狂の中では忘れがちなポイント。
深夜の学びは格別。静かな時間にこそ、じっくり読める。🌙