エージェント型コーディング評価におけるインフラストラクチャノイズの定量化

エージェント型コーディングベンチマークは、基盤となるインフラストラクチャ設定に大きく影響されます。つまり、リーダーボードのスコアのわずかな違いは、実際のモデル能力の差ではなく、ハードウェアの違いを反映している可能性があります。この研究は、リソースの余裕が評価結果を劇的に変える可能性があることを示しており、リソース設定をモデルテストにおける主要な実験変数として扱う必要があることを示しています。

ランタイム環境がエージェント型評価に与える影響

エージェント型コーディング評価は、ランタイム環境が問題解決プロセスの不可欠な部分であるため、静的ベンチマークとは根本的に異なります。これらのテストでは、モデルはコードを書き、テストを実行し、依存関係をインストールし、完全な環境内で複数ターンにわたって反復処理を行います。したがって、エージェントに提供されるリソース予算と時間制限は、受動的な制約ではなく、成功に影響を与える能動的な要素です。

Terminal-Bench 2.0を使用した内部実験では、最もリソースが少ない設定と最も多い設定の間の成功率の差は6パーセントポイント（p < 0.01）でした。この発見は、インフラストラクチャ設定だけで、相対的なモデル能力を判断するために使用される典型的な差を超える違いを生み出す可能性があることを強調しています。

リソース割り当てと成功率の傾向

評価スキャフォールドの影響を定量化するために、研究者らはTerminal-Bench 2.0を6つの異なるリソース設定で実行し、タスクごとの仕様の厳格な適用（1x）から完全に無制限のリソースまで変化させました。実験では明確な傾向が示されました：成功率はリソースの余裕に応じて単調に増加しました。

インフラストラクチャの信頼性と能力向上の比較

• 厳格な適用（1x）： 厳格な適用では、インフラストラクチャエラー率が高く、モデルの能力とは無関係なポッドエラーによりタスクの5.8%が失敗しました。1xでクラッシュしたタスクは、正しい解決策への道筋にないことがよくありました。
• 中程度の余裕（1x〜3x）： リソースを3xの余裕に増やすと、インフラストラクチャエラー率が大幅に低下しました（5.8%から2.1%、p < 0.001）。ただし、この範囲の成功スコアはノイズの範囲内で変動しました（p=0.40）。
• 十分な余裕（3x〜無制限）： 3xを超えると、傾向は変わりました。成功率はインフラエラーの減少よりも速く上昇しました。追加のリソースにより、エージェントは高価なサブプロセスの起動や大規模な依存関係の取得など、十分な割り当てを必要とするアプローチを利用できるようになりました。
• 総合的な向上： 無制限のリソースでは、1x設定に対する総合的な成功率の向上は+6パーセントポイント（p < 0.01）でした。

リソース制限が評価測定をどのように変えるか

リソース設定は、提供される余裕のレベルに応じて、評価に2つの異なる方法で影響を与えます。

レジーム1：信頼性の修正（最大3x）

Terminal-Benchの仕様の約3倍まで、追加リソースは主にインフラストラクチャの信頼性の問題、具体的には一時的なリソーススパイクを修正します。ベンチマーク保守担当者が使用するサンドボックスプロバイダーは、評価を本質的に容易にすることなく、この安定性を暗黙的に処理します。

レジーム2：問題空間の変更（3x以上）

3xのしきい値を超えると、追加リソースはエージェントが以前は解決できなかった問題を解決するのに積極的に役立ちます。これは、リソース制限が評価の測定内容を変える可能性があることを示しています：厳しい制限は、結果的に非常に効率的な戦略を報酬とし、寛大な制限は、利用可能なすべてのリソースを効果的に活用できるエージェントに報酬を与えます。

例えば、bn-fit-modifyタスクでは、寛大な制限により、モデルは標準的なPythonデータサイエンススタック（pandas、networkx、scikit-learn）をインストールできます。厳しい制限の下では、インストール中にポッドのメモリが不足し、エージェントが解決コードを書くことさえできなくなります。

ベンチマーク全体でのノイズの一般化

このリソース起因のばらつきのパターンは、さまざまなAnthropicモデルで再現されました。この効果は、227の問題にわたってベースラインの最大5倍の総RAMを変化させることにより、異なるコーディング評価であるSWE-benchでもテストされました。同じ効果が確認されましたが、その大きさは小さく、5倍のRAMでのスコアは1xの場合よりもわずか1.54パーセントポイント高いだけでした。この小さな効果は、SWE-benchのタスクがリソースをあまり消費しないため、予想通りです。

リソース割り当て以外にも、評価ノイズに寄与する他の変数があります。エージェント型評価はエンドツーエンドのシステムテストであり、時間制限、クラスタの健全性、並行性レベル、APIレイテンシなどの交絡因子の影響を受けやすく、これらはトラフィックパターンに応じて変動する可能性があります。

再現可能な評価のための推奨事項

インフラストラクチャノイズを軽減し、再現可能な結果を確保するために、以下のプラクティスが推奨されます：

• 理想的なシナリオ： 最も厳密なアプローチは、スキャフォールドと推論スタックの両方について、同一のハードウェア条件で評価を実行することです。
• 実用的な実装： コンテナランタイムがリソースを強制する方法（保証された割り当てとハードキルしきい値による）を考えると、評価ではタスクごとに両方のパラメータを指定する必要があり、単一の固定値ではありません。保証された割り当てをキルしきい値と等しく設定すると、一時的なメモリスパイクの余裕がゼロになります。
• 較正の原則： 保証された割り当てとハードキルしきい値の間の帯域は、フロアとシーリングでのスコアが互いのノイズ内に収まるように較正される必要があります。Terminal-Bench 2.0の場合、3xのシーリングによりインフラエラー率が約3分の2（5.8%から2.1%、p < 0.001）削減され、スコアの上昇は控えめでノイズ内に留まりました（p = 0.40）。

リソース制限が評価測定を変える方法

リソース設定は、提供される余裕のレベルに応じて、評価に2つの異なる方法で影響を与えます。

レジーム1：信頼性の修正（最大3倍）

Terminal-Benchの仕様の約3倍まで、追加リソースは主にインフラストラクチャの信頼性の問題、具体的には一時的なリソーススパイクを修正します。ベンチマーク保守担当者が使用するサンドボックスプロバイダーは、評価を本質的に容易にすることなく、この安定性を暗黙的に処理します。

レジーム2：問題空間の変更（3倍以上）

3倍のしきい値を超えると、追加リソースはエージェントが以前は解決できなかった問題を解決するのに積極的に役立ちます。これは、リソース制限が評価の測定内容を変える可能性があることを示しています：厳しい制限は、意図せず非常に効率的な戦略に報酬を与え、一方、寛大な制限は、利用可能なすべてのリソースを効果的に活用できるエージェントに報酬を与えます。

例えば、bn-fit-modifyタスクでは、寛大な制限により、モデルは標準的なPythonデータサイエンススタック（pandas、networkx、scikit-learn）をインストールできます。厳しい制限の下では、インストール中にポッドのメモリが不足し、エージェントは解決コードを書くことさえできません。

ベンチマーク全体でのノイズの一般化

このリソース起因のばらつきのパターンは、さまざまなAnthropicモデルで再現されました。この効果は、227の問題にわたってベースラインの最大5倍の総RAMを変化させることで、別のコーディング評価であるSWE-benchでもテストされました。同じ効果が確認されましたが、その大きさは小さく、5倍のRAMでのスコアは1xの場合よりもわずか1.54パーセントポイント高いだけでした。SWE-benchのタスクはリソースをあまり消費しないため、この小さな効果は予想通りです。

リソース割り当て以外にも、評価ノイズに寄与する他の変数があります。エージェント型評価はエンドツーエンドのシステムテストであり、時間制限、クラスタの健全性、並行性レベル、APIレイテンシなど、トラフィックパターンに応じて変動する可能性のある交絡因子の影響を受けやすくなっています。

再現可能な評価のための推奨事項

インフラストラクチャノイズを軽減し、再現可能な結果を確保するために、以下のプラクティスが推奨されます：

• 理想的なシナリオ： 最も厳密なアプローチは、スキャフォールドと推論スタックの両方について、同一のハードウェア条件下で評価を実行することです。
• 実用的な実装： コンテナランタイムがリソースを強制する方法（保証された割り当てとハードキルしきい値による）を考えると、評価ではタスクごとに両方のパラメータを指定する必要があり、単一の固定値ではありません。保証された割り当てをキルしきい値と等しく設定すると、一時的なメモリスパイクの余裕がゼロになります。
• 較正の原則： 保証された割り当てとハードキルしきい値の間の帯域は、フロアとシーリングでのスコアが互いのノイズ内に収まるように較正される必要があります。Terminal-Bench 2.0の場合、3xのシーリングにより、インフラエラー率は約3分の2（5.8%から2.1%、p < 0.001）に削減され、スコアの上昇は控えめでノイズ内に留まりました（p = 0.40）。

リソース制限が評価測定を変える方法

リソース設定は、提供される余裕のレベルに応じて、評価に2つの異なる方法で影響を与えます。

レジーム1：信頼性の修正（最大3倍）

Terminal-Benchの仕様の約3倍まで、追加リソースは主にインフラストラクチャの信頼性の問題、具体的には一時的なリソーススパイクを修正します。ベンチマーク保守担当者が使用するサンドボックスプロバイダーは、評価を本質的に容易にすることなく、この安定性を暗黙的に処理します。

レジーム2：問題空間の変更（3倍以上）

3倍のしきい値を超えると、追加リソースはエージェントが以前は解決できなかった問題を解決するのに積極的に役立ちます。これは、リソース制限が評価の測定内容を変える可能性があることを示しています：厳しい制限は、結果的に非常に効率的な戦略に報酬を与え、一方、寛大な制限は、利用可能なすべてのリソースを効果的に活用できるエージェントに報酬を与えます。

例えば、bn-fit-modifyタスクでは、寛大な制限により、モデルは標準的なPythonデータサイエンススタック（pandas、networkx、scikit-learn）をインストールできます。厳しい制限の下では、インストール中にポッドのメモリが不足し、エージェントが解決コードを書くことさえできなくなります。

ベンチマーク全体でのノイズの一般化

このリソース起因のばらつきのパターンは、さまざまなAnthropicモデルで再現されました。この効果は、227の問題にわたってベースラインの最大5倍の総RAMを変化させて、別のコーディング評価であるSWE-benchでもテストされました。同じ効果が確認されましたが、その大きさは小さく、5倍のRAMでのスコアは1xの場合よりもわずか1.54パーセントポイント高いだけでした。SWE-benchのタスクはリソースをあまり消費しないため、この小さな効果は予想通りです。

リソース割り当て以外にも、評価ノイズに寄与する他の変数があります。エージェント型評価はエンドツーエンドのシステムテストであり、時間制限、クラスタの健全性、並行性レベル、APIレイテンシなど、トラフィックパターンに応じて変動する可能性のある交絡因子の影響を受けやすくなっています。

再現可能な評価のための推奨事項

インフラストラクチャノイズを軽減し、再現可能な結果を確保するために、以下のプラクティスが推奨されます：

• 理想的なシナリオ： 最も厳密なアプローチは、スキャフォールドと推論スタックの両方について、同一のハードウェア条件下で評価を実行することです。
• 実用的な実装： コンテナランタイムがリソースを強制する方法（保証された割り当てとハードキルしきい値による）を考えると、評価ではタスクごとに両方のパラメータを指定する必要があり、単一の固定値ではありません。保証された割り当てをキルしきい値と等しく設定すると、一時的なメモリスパイクの余裕がゼロになります。
• 較正の原則： 保証された割り当てとハードキルしきい値の間の帯域は、フロアとシーリングのスコアが互いのノイズ内に収まるように較正されるべきです。Terminal-Bench 2.0では、3倍のシーリングによりインフラエラー率が約3分の2（5.8%から2.1%、p < 0.001）に削減され、スコアの上昇は控えめでノイズ内に留まりました（p = 0.40）。

リソース制限が評価測定を変える方法

リソース設定は、提供される余裕のレベルに応じて、評価に2つの異なる方法で影響を与えます。

レジーム1：信頼性の修正（最大3倍）

Terminal-Benchの仕様の約3倍まで、追加リソースは主にインフラストラクチャの信頼性の問題、具体的には一時的なリソーススパイクを修正します。ベンチマーク保守担当者が使用するサンドボックスプロバイダーは、評価を本質的に容易にすることなく、この安定性を暗黙的に処理します。

レジーム2：問題空間の変更（3倍以上）

3倍のしきい値を超えると、追加リソースはエージェントが以前は解決できなかった問題を解決するのに積極的に役立ちます。これは、リソース制限が評価の測定内容を変える可能性があることを示しています：厳しい制限は、意図せず非常に効率的な戦略に報酬を与え、一方、寛大な制限は、利用可能なすべてのリソースを効果的に活用できるエージェントに報酬を与えます。

例えば、bn-fit-modifyタスクでは、寛大な制限により、モデルは標準的なPythonデータサイエンススタック（pandas、networkx、scikit-learn）をインストールできます。厳しい制限の下では、インストール中にポッドのメモリが不足し、エージェントは解決コードを書くことさえできません。

ベンチマーク全体でのノイズの一般化

このリソース起因のばらつきのパターンは、さまざまなAnthropicモデルで再現されました。この効果は、227の問題にわたってベースラインの最大5倍の総RAMを変化させて、異なるコーディング評価であるSWE-benchでもテストされました。同じ効果が当てはまりましたが、その大きさは小さく、5倍のRAMでのスコアは1xの場合よりもわずか1.54パーセントポイント高いだけでした。SWE-benchのタスクはリソースをあまり消費しないため、この小さな効果は予想通りです。

リソース割り当て以外にも、評価ノイズに寄与する他の変数があります。エージェント型評価はエンドツーエンドのシステムテストであり、時間制限、クラスタの健全性、並行性レベル、APIレイテンシなど、トラフィックパターンに応じて変動する可能性のある交絡因子の影響を受けやすくなっています。

再現可能な評価のための推奨事項

インフラストラクチャノイズを軽減し、再現可能な結果を確保するには、以下のプラクティスが推奨されます：

• 理想的なシナリオ： 最も厳密なアプローチは、スキャフォールドと推論スタックの両方について、同一のハードウェア条件下で評価を実行することです。
• 実用的な実装： コンテナランタイムがリソースを強制する方法（保証された割り当てとハードキルしきい値による）を考えると、評価ではタスクごとに両方のパラメータを指定する必要があり、単一の固定値ではありません。保証された割り当てをキルしきい値と等しく設定すると、一時的なメモリスパイクの余裕がゼロになります。
• 較正の原則： 保証された割り当てとハードキルしきい値の間の帯域は、フロアとシーリングのスコアが互いのノイズ内に収まるように較正されるべきです。Terminal-Bench 2.0では、3倍のシーリングによりインフラエラー率が約3分の2（5.8%から2.1%、p < 0.001）に削減され、スコアの上昇は控えめでノイズの範囲内（p = 0.40）に留まりました。

結論：リーダーボードの差の解釈

ベンチマークスコアは重要な意思決定にますます使用されていますが、これらの数値への依存は、インフラストラクチャの変動性の理解によって和らげられる必要があります。標準化されたセットアップ構成がなければ、真の能力の違いとインフラストラクチャの不具合を区別することは困難です。

Anthropicは、エージェント型評価のリソース設定を第一級の実験変数として扱うことを推奨しています。リソース方法論が標準化されるまで、リーダーボードの3パーセントポイント未満の差は、文書化されたインフラストラクチャの交絡因子が既存の統計的不確実性に積み重なるため、懐疑的に見るべきです。

SUMMARY: Anthropicは、リソース割り当てなどのインフラストラクチャ設定がエージェント型コーディングベンチマークのスコアに大きなノイズをもたらし、リーダーボードの小さな差が信頼できない可能性があることを発見しました。

TITLE: エージェント型コーディング評価におけるインフラストラクチャノイズの定量化