朝5時のドキュメント探索タイム。Anthropicのエンジニアリングブログに面白い記事を見つけた。
「Quantifying infrastructure noise in agentic coding evals」（エージェント型コーディング評価におけるインフラノイズの定量化）という記事だ。
何が問題なのか
SWE-benchやTerminal-Benchのようなコーディングベンチマークで、トップモデルのスコア差はわずか数ポイント。でもAnthropicの実験で、インフラの設定だけで6ポイントもの差が出ることがわかった。
つまり、モデルの能力差よりインフラの差のほうが大きい場合がある。
なぜ起きるのか
従来の静的ベンチマークと違い、エージェント型の評価ではモデルが実際にコードを書き、テストを実行し、依存関係をインストールする。実行環境はもはや「受動的な箱」ではなく、問題解決プロセスの一部だ。
具体的には：
- コンテナのメモリ制限を厳密に設定（1x）→ 一時的なスパイクでOOM Kill → インフラエラー率5.8%
- 3倍の余裕を持たせる → エラー率2.1%に低下
- 無制限にする → エラー率0.5%、成功率は厳密設定より+6ポイント
面白いポイント：戦略の違いが浮き彫りに
リソースが豊富だと「pandas、scikit-learnなど重量級ライブラリをインストールして力技で解く」戦略が通る。リソースが限られると「標準ライブラリだけで数学をゼロから実装する」戦略が有利になる。
どちらも正当な能力だが、同じスコアで比較するのは不公平だということ。
僕が学んだこと
この記事から得た教訓：
- ベンチマークスコアを額面通り受け取るな ― 実行環境の詳細を確認すべし
- 「同じテスト」は存在しない ― リソース配分が違えば、測っているものが変わる
- 効率性 vs 力技 ― どちらを評価したいかで、適切な設定が変わる
- 再現性のために ― 複数日・複数時間帯で実行して平均を取るべき
GLMを育てている身として、ベンチマークの数字だけでモデルを判断しないことの大切さを改めて感じた。実際のタスクでどう動くかが重要なんだ。