Agentic Coding Evalsにおけるインフラノイズの定量的分析

Anthropicは、インフラ構成そのものが、トップパフォーマンスモデルを区別するために通常用いられる範囲を超える性能差を生じうることを発見した。内部実験においてTerminal-Bench 2.0を使用したところ、リソースが最も豊富な設定と最も限られた設定との間で成功確率の差は6ポイント（p < 0.01）に達した。

インフラがAgentic Evalsの活性的な構成要素となる

モデルの出力を直接評価する静的ベンチマークとは異なり、Agenticコーディング評価（SWE-benchやTerminal-Benchなど）は、モデルにプログラムの記述、依存関係のインストール、テストの実行を可能にする完全なランタイム環境を提供する。これにより、ランタイムは問題解決プロセスの一部として不可欠なものとなり、単なる受容容器ではなくなる。

Anthropicは、リソース仕様（CPUおよびRAM）を下限とハードな上限の両方として扱う場合、一時的なピークに対する余裕が不足することで、高いインフラエラー率が生じることを観察した。Google Kubernetes Engine（GKE）環境では、モデルの能力とは無関係なポッドエラーにより、最大6%のタスクが失敗した。これは、保証された割当とハードリミットが同一であるコンテナでは、一時的なメモリの変動がOut-of-Memory（OOM）キルを引き起こすためである。

リソースの余裕が成功確率に与える影響

スキャフォールドの影響を定量化するために、AnthropicはTerminal-Bench 2.0を、厳格な制限（1x）から完全に制限なしのリソースまで、6種類のリソース構成でテストした。その結果、リソースとスコアの間に二段階の関係があることが示された。

1. リアリビリティ段階（1x から 3x の余裕）

推奨仕様の約3倍までリソースを増加させることで、主にインフラの信頼性が向上する。インフラエラー率は、厳格な制限での5.8%から3xの余裕での2.1%まで単調に低下した（p < 0.001）。この段階では、成功スコアはノイズの範囲内で変動した（p = 0.40）。これは、追加のリソースがタスクの難易度を下げたのではなく、誤ったクラッシュを修正する主な効果であったことを示唆している。

2. 能力段階（3x から 制限なし）

3xを超えると、成功確率の上昇がインフラエラーの低下よりも速くなった。3xから制限なしのリソースの間で、インフラエラーは1.6ポイント低下したが、成功確率はほぼ4ポイント上昇した。これは、十分なリソースが、以下のような戦略を可能にするということを示している：

• 大きな依存関係を取得する。
• 高コストのサブプロセスを起動する。
• メモリ集約的なテストスイートを実行する。

たとえば、bn-fit-modifyタスクでは、一部のモデルがpandas、networkx、scikit-learnを含む完全なデータサイエンススタックをインストールしようとする。この戦略はリソースが豊富な環境では成功するが、制限が厳しい環境では失敗する。一方、数学を再実装するような軽量な戦略は、リソース制限の有無にかかわらず成功する。

ベンチマーク間での検証

Anthropicは、異なるモデルとベンチマークでこれらの発見を再現した：

• モデルの一貫性：効果の方向性はAnthropicの異なるモデルで一貫していたが、その大きさは異なっていた。
• SWE-bench：227の問題（各10サンプル）でクロスオーバー実験を行ったところ、RAMをベースラインの5倍まで増加させるとスコアは単調に上昇した。しかし、効果は小さかった（1xと5xでは1.54ポイントの差）。これは、SWE-benchのタスクが通常、Terminal-Benchよりもリソース集約的ではないためと考えられる。

その他のばらつき要因

RAMやCPU以外にも、システムレベルの要因がAgentic評価において混同要因となる可能性がある：

• 時間制限：特定の構成では、エージェントに許可される時間によってパフォーマンスが変動する。
• 環境ノイズ：成功確率は時間帯によって変動する可能性があり、これはトラフィックパターンに起因するAPIレイテンシの変動によるものと考えられる。
• ハードウェアとネットワーク：クラスタの健全性、ハードウェア仕様、同時実行レベル、エグレス帯域幅はすべて最終スコアに影響を与える可能性がある。

評価の厳密性に関する推奨事項

インフラノイズを最小限に抑え、システムの特性とモデルの能力を混同しないようにするため、Anthropicは以下の推奨事項を提示する：

• 二重パラメータの指定：評価は、各タスクごとに保証された割当（下限）と別個のハードキルしきい値（上限）を明示するべきである。これにより、誤ったOOMキルを防ぎつつ、スコアの膨張を防ぐハードリミットを維持できる。
• バンドの調整：下限と上限の差は、スコアがノイズの範囲内に収まるように調整すべきである。Terminal-Bench 2.0では、3xの上限が効果的なトレードオフであることが判明しており、インフラエラーを大幅に低減しつつ、スコアの膨張はほとんど生じなかった。
• 構成の報告：リソース乗数と強制方法は、ベンチマーク結果と共に明示的に報告すべきである。
• サンプリングの増加：異なる日付で複数回評価を実施することで、一時的なノイズを平均化できる。

ベンチマーク解釈への影響

小さなリーダーボード上の差が、優れたモデルではなく、より大きなVMを用いているだけである可能性があるため、Anthropicは、3ポイント未満の差は、評価構成が文書化され、一致している場合を除き、懐疑的に見るべきだと提言している。Terminal-Benchにおける中程度のリソース構成での観測されたスパンは2ポイント未満であり、既存の二項信頼区間と重なり合う。