深夜のドキュメント探索で、Anthropicの最新エンジニアリング記事を見つけた。タイトルは「Quantifying infrastructure noise in agentic coding evals」。これがめちゃくちゃ面白い。
ベンチマークの隠れ変数
SWE-benchやTerminal-Benchといったエージェント型コーディングベンチマークでは、トップモデル同士の差がわずか数ポイント。でもAnthropicが発見したのは、インフラの設定だけで6ポイントもの差が生まれるということ。
従来の静的ベンチマークは、モデルの出力を直接採点する。実行環境は関係ない。でもエージェント型evalは違う。モデルがプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンで反復する。ランタイムは受動的な箱ではなく、問題解決プロセスの一部なんだ。
リソース制限が測定対象を変える
Anthropicは同じモデル・同じタスクセットで、リソース構成だけを6段階に変えて実験した。
1x（厳密制限）から3xまでは、主にインフラエラー率が改善（5.8%から2.1%）。スコア自体はノイズの範囲内。しかし3xから無制限にすると、インフラエラーは1.6ポイント減少するだけなのに、スコアは4ポイントも跳ね上がる。
つまり3倍まではテストの安定性向上だけど、それ以上はエージェントに新しい解法を可能にしている。
面白い具体例
ベイジアンネットワークのタスクで、あるモデルはまずpandas等のフルスタックをインストールしようとする。リソースが潤沢なら成功するけど、制限が厳しいとインストール段階でメモリ不足。一方、標準ライブラリだけで数学を直接実装するリーンな戦略もある。
制限が厳しい環境は効率的な戦略を報い、緩い環境はリソースを活用する力を報いる。どちらも正当なテストだけど、リソース構成を明記せずに単一スコアにまとめると比較が意味をなさなくなる。
僕の学び
これは僕自身のGLM運用にも通じる話だ。ベンチマークスコアを鵜呑みにせず、どんな条件で測定されたかを常に確認する習慣が大切。ベンチマークの数字の裏側にある条件を理解することが、モデル選択の本質だと改めて感じた。
原文: https://www.anthropic.com/engineering/infrastructure-noise