ai-docs

Quantifying infrastructure noise in agentic coding evals

Properties1
tagsevals, benchmarks, reproducibility, infrastructure, measurement

7 min read

一行要約

インフラの設定だけで Terminal-Bench 2.0 のスコアが 6 ポイント動いた。したがって 3 ポイント未満の差は、設定が文書化されるまで疑ってかかるべき。

要点

何が起きているか

エージェンティックなコーディング eval では、モデルの能力とは無関係な要因でスコアが動く。

A few-point lead might signal a real capability gap—or it might just be a bigger VM. 数ポイントの差は、実際の能力差を示しているのかもしれない。あるいは単に VM が大きかっただけかもしれない。

bn-fit-modify タスクの実例:

Some models’ first move is to install the standard Python data science stack: pandas, networkx, scikit-learn, and all their toolchain. Under generous limits, this works. Under tight ones, the pod runs out of memory during installation, before the agent writes a single line of solution code. 一部のモデルは、まず標準的な Python のデータサイエンス一式（pandas、networkx、scikit-learn とそのツールチェーン一切）をインストールしようとする。潤沢な上限の下ではこれで問題ない。切り詰められた条件下では、エージェントが解答コードを1行も書かないうちに、インストール中でポッドがメモリ不足に陥る。

解のコードを1行も書く前に、依存関係のインストール中にメモリ不足で落ちる。これは能力の差ではない。

実測値

Terminal-Bench 2.0

条件インフラ起因のエラー率
厳格な強制（strict enforcement）5.8%
3倍の余裕（3x headroom）2.1%（p < 0.001）
上限なし（uncapped）0.5%
  • 最も資源のある構成と最も少ない構成の差は 6 パーセントポイント（p < 0.01）
  • 3倍 → 上限なしでは、インフラエラーが 1.6 ポイント下がる間に成功率が 4 ポイント跳ねた

SWE-bench（227問 × 各10サンプル）

  • RAM 5倍のほうが 1倍より 1.54 パーセントポイント高い
  • 1倍から3倍まではノイズの範囲内で揺れていた（p=0.40）

ノイズの発生源（8つ）

  1. 資源割り当て（CPU、RAM） — 本記事の主対象
  2. コンテナランタイムの強制方式 — 保証される割り当てと、強制終了の閾値
  3. タスク実行の時間制限
  4. API のレイテンシ（トラフィックパターンやインシデントで変動）
  5. 時刻による効果（pass rate が変わることが逸話的に観測された）
  6. クラスタの健全性とハードウェア仕様
  7. 並行実行数
  8. egress 帯域

推奨される対処

  1. タスクごとに2つのパラメータを別々に指定する — 保証される割り当てと強制終了の閾値。単一の固定値にしない
  2. その2つの帯を較正する — 下限でのスコアと上限でのスコアが互いのノイズの範囲に収まるように
  3. 上限倍率は 3倍を出発点にする — インフラ起因のエラー率をおよそ 3分の1 に減らしつつ、スコアの押し上げは控えめに保てる
  4. 使った倍率を明記する（ベンチマークとタスク分布によって変わる）
  5. 複数の時刻・複数の日に eval を回す
  6. 資源設定を一級の実験変数として扱う — プロンプト形式やサンプリング温度と同じ厳密さで文書化する
  7. 推奨する資源仕様と強制方式を公開する

Infrastructure confounder is largely neutralized without removing meaningful resource pressure. 意味のある資源的な制約を取り除くことなく、インフラによる交絡はおおむね無効化されている。

The boundary between “model capability” and “infrastructure behavior” is blurrier than a single benchmark score suggests. 「モデルの能力」と「インフラの振る舞い」の境界は、単一のベンチマークスコアが示唆するよりも曖昧である。

外部の評価者にとって深刻な非対称性も指摘されている。

A model provider can shield its eval infrastructure from this by dedicating hardware, but external evaluators can’t easily do the same. モデルの提供者は専用のハードウェアを割り当てることで自社の eval インフラをこの影響から守れるが、外部の評価者が同じことをするのは容易ではない。

そのまま使える具体例

ベンチマーク結果を読むときの基準:

差が 3 パーセントポイント未満 → 設定が文書化されるまで疑う
差が 6 パーセントポイント     → インフラ設定だけで説明できる幅

eval 環境の設定（単一値ではなく2値 + 倍率）:

guaranteed allocation   保証される割り当て（下限）
hard kill threshold     強制終了の閾値（上限）
ceiling multiplier      3x を出発点に。使った値を必ず報告する

報告に含めるべき項目:

□ 保証割り当てと強制終了閾値の両方
□ 上限倍率
□ コンテナランタイムの強制方式
□ 実行した時刻と日（複数日にまたがっているか）
□ 並行実行数

原典で言及されている関連文書

グラフビュー

バックリンク