評価ワークフロー
AutomationBench レシピは、ローカルマシン上で Harbor を実行します。各試行には CPU サンドボックスが割り当てられ、AutomationBench はそこにエージェントループ、シミュレートされたアプリケーション、アサーションベースの評価器をインストールします。モデルはお使いの推論エンドポイントで実行されます。サンドボックス内に GPU や実際のアプリケーションの認証情報を用意する必要はありません。 このレシピは Harbor のBaseAgent および BaseEnvironment インターフェースを実装し、公開されている CoreWeave Sandboxes ソフトウェア開発キット (SDK) の呼び出しを使用します。ネイティブの auto-bench 評価器を変更せずにそのまま実行し、上流の AutomationBench Harbor アダプターは必要ありません。Harbor、AutomationBench、cwsandbox SDK のバージョンはレシピ内で固定されています。
前提条件
開始する前に、以下を準備してください。- ローカルマシンにインストールされた
uvと Git。このレシピには Python 3.13 以降が必要です。Python がインストールされていない場合は、uvが対応するバージョンの Python をダウンロードします。 - サンドボックスへのアクセス権を持つ CoreWeave API アクセストークン。
- 選択した同時実行数をまかなえるサンドボックスの同時実行クォータと、サンドボックスあたり 2 vCPU および 4 GiB のメモリを許可するリソースポリシー。
- ツール呼び出しに対応した推論エンドポイント、APIキー、および十分な推論クォータ。この例では、Serverless Inference の APIキーを作成します。
- ネットワークアクセス (お使いのマシンからサンドボックス API およびパッケージリポジトリへのアクセスと、サンドボックスから GitHub、Debian と Python のパッケージリポジトリ、および推論エンドポイントへのアクセス) 。
レシピのインストール
レシピのリポジトリをクローンし、バージョン固定済みの依存関係をインストールします。モデルと認証情報を設定する
シークレットマネージャーから認証情報を読み込み、プロセスの環境変数に設定します。CWSANDBOX_API_KEY には CoreWeave サンドボックスの認証情報を、MODEL_API_KEY には推論の認証情報を設定してください。キーは .env ファイルに保存しないでください。
.env ファイルには、モデルのエンドポイント、モデル名、および必要に応じて project のみを設定します。Serverless Inference の例では、次の設定を使用します。[WANDB-TEAM] と [WANDB-PROJECT] は、アクセス権のある名前に置き換えてください。
MODEL_PROJECT は、Serverless Inference の使用量のトラッキングに使用する OpenAI-Project ヘッダーを設定します。
このモデル ID は一例であり、必須ではありません。利用可能なモデルから、ツール呼び出しに対応したモデルを選択してください。互換性のある別のプロバイダーや、自身でホストしているモデルを使用する場合は、.env ファイル内のモデル設定を置き換えてください。[INFERENCE-HOST] と [MODEL-ID] は、ご利用のプロバイダーの値に置き換えます。
MODEL_API_KEY に読み込み、CWSANDBOX_API_KEY は設定したままにしてください。プロバイダーが project ヘッダーを使用しない場合は、コマンドを実行する前に .env ファイルから MODEL_PROJECT を削除し、継承された MODEL_PROJECT 環境変数があればその設定を解除してください。エンドポイントには、サンドボックスからアクセスできる必要があります。localhost はお使いのマシンではなく、サンドボックス自体を指します。その他の API プロトコルを使用する場合は、ネイティブ評価器のオプションを調整する必要があります。
このレシピでは、サンドボックスの操作に CoreWeave の認証を明示的に使用します。サンドボックスのトークンはホスト上にのみ保持されます。サンドボックスの作成時に注入されるのは、モデルの設定と推論キーのみです。ジョブの設定には認証情報の値は含まれません。
認証情報の取り扱いに関する詳しいガイダンスについては、環境変数とシークレットを参照してください。ダウンロードしたログやトレースには、タスクデータやプロバイダーのエラーメッセージが含まれる場合があるため、適切に保護してください。
セットアップチェックを実行する
シンプルなタスクを 1 つ、1 つのサンドボックスで評価します。results-smoke/job-result.json ファイルを調べて、完了した試行とエラーになった試行の数を確認します。終了ステータスがゼロであれば、エラーのままの試行や欠落している試行が残っていないことを意味します。ただし、モデルがタスクのアサーションに合格したことを意味するわけではありません。ネイティブの agent/automationbench.json エクスポートには、passed、score、実行時間、トークン使用量が記録されます。検証器は、passed と score を、それぞれ pass と partial_credit という名前の Harbor 報酬にマッピングします。job-result.json では、stats.evals エントリの metrics の下に、各報酬の試行全体での平均値が記録されます。報酬のない試行はゼロとしてカウントされます。reward_stats には、報酬の値ごとに該当する試行がリストされます。
エージェントは、api ツールセットを使用し、応答ステップは最大 50、サンドボックスごとに一度に実行するタスクは 1 つで、推論設定にはプロバイダーのデフォルトを使用します。ネイティブのタスク全体の自動修復は無効化されているため、試行の再試行は Harbor が管理します。なお、モデルクライアントが個々のリクエストを内部で再試行することはあります。
並列度を上げる
セットアップの確認が成功したら、まずは小規模なサブセットで試します。
採点対象のセットを評価するには、そのタスクリストと、クォータの範囲内で実行できる同時実行数を選択します。
キャパシティおよび推論制限による失敗の再試行
このレシピでは Harbor のRetryConfig を設定し、元の試行の後に最大 5 回の再試行を許可します。待機時間はそれぞれ 30、60、120、240、300 秒です。再試行の許可リストには、次の例外が含まれます。
SandboxResourceExhaustedErrorSandboxUnavailableErrorSandboxRequestTimeoutErrorEnvironmentStartTimeoutErrorApiRateLimitErrorApiUsageLimitError
ApiUsageLimitError を再試行の対象外としています。このレシピでは、この例外を除外セットから削除し、許可リストに追加しています。アダプターは、ネイティブの評価器が出力する推論クォータおよび rate-limit の終了メッセージのうち、認識できるものを対応する Harbor の例外にマッピングします。このマッピングはプロバイダーのエラーテキストに依存するため、プロバイダーが異なる形式でエラーを報告する場合は、ログを確認してください。
キャパシティやクレジットが恒常的に不足している場合は、キャパシティやクレジットが利用可能になるまで待つ必要があります。再試行後もエラーが解消しない場合、スクリプトはゼロ以外の終了コードで終了し、最後のエラーを保持します。通常のアサーション失敗、応答拒否、不正な形式のツール呼び出し JSON、エージェントの実行タイムアウトは、再試行ポリシーのトリガーにはなりません。
Harbor は再試行の前に、失敗した試行のディレクトリを削除します。このレシピの試行終了時フックは、削除される前に各試行を結果および利用可能なログとともにアーカイブします。スコアを報告する際は、これらの試行を保持し、インフラストラクチャーの復旧を行ったことを明記してください。モデルの失敗を、再試行で得られたより良い成果に断りなく置き換えないでください。
結果と時間のかかる試行を確認する
各出力ディレクトリには、次のアーティファクトが含まれます。
タスクの所要時間とトークン使用量は、ネイティブエクスポートで確認してください。このアダプターは、Harbor の集計用エージェントトークンフィールドやコストフィールドには値を設定しません。結果とあわせて、モデル、エンドポイント、ベンチマークのリビジョン、タスクリスト、推論の設定、同時実行数、再試行ポリシーを記録してください。run を停止した場合は、エクスポート済みのタスクのみを完了した評価として報告し、結果が部分的なものであることを明記してください。
ステップ数や出力トークン数が少なくても、モデルの応答時間がタスクの所要時間の大半を占めることがあります。遅延の原因をサンドボックスのリソースと判断する前に、
model_time_s と tool_time_s を比較し、agent/eval.log ファイルを確認してください。不正な形式のツール呼び出し JSON をプロバイダーが拒否するのは、モデルまたはプロトコルの障害であり、サンドボックスのクォータ枯渇を示すものではありません。AutomationBench は、ターンの途中で停止したロールアウトをエクスポートの summary.aborted_tasks フィールドに列挙します。これらのタスクごとの errors 配列は空になる場合があるため、タスクのエラーだけでなく、このフィールドとログも確認してください。
セットアップのタイムアウトは 11 分です。エージェントの実行には別途 45 分のタイムアウトがあり、その中で実行されるネイティブ評価コマンドのタイムアウトは 40 分です。各サンドボックスの有効期間の上限は 1 時間で、タイムアウトに達していなくても上限に達した時点でサンドボックスは終了します。エージェント実行のタイムアウトは、このポリシーでは再試行の対象になりません。
停止とクリーンアップ
フォアグラウンドの run を停止するには、Ctrl+C を押して Harbor が終了するまで待ちます。このジョブでは、ティアダウンのためにdelete=True が設定されています。プロセスが強制終了された場合やクリーンアップに失敗した場合は、残っているサンドボックスを削除する前にローカルのランナーを停止してください。ランナーが動作したままだと、削除したサンドボックスの代わりが作成されてしまいます。
ランナーが停止したら、その出力ディレクトリを使用してクリーンアップが完了したことを検証します。
results-smoke は、停止したジョブのディレクトリに置き換えてください。このスクリプトは記録済みのサンドボックス ID のみを削除し、それぞれの終端状態を出力します。すでに存在しないサンドボックスは not_found と報告されます。終了コードが 0 以外の場合は、削除または終端状態の検証に失敗しているため、原因を調査してください。ホストプロセスが消失した場合でも、設定済みの有効期間の上限によってサンドボックスのライフタイムは制限されます。
検証のスコープ
レシピの開発中、ネイティブの評価器は、Serverless Inference 上のopenai/gpt-oss-120b を使用して 8 つの CPU サンドボックスで並列実行し、公開タスク 800 件のうち 730 件の結果をエクスポートしました。この run は完了前に停止したため、その結果はベンチマークスコアとして扱えません。Harbor の再試行スケジューリングは別途検証済みです。具体的には、SandboxResourceExhaustedError を意図的に注入し、30 秒のバックオフを経て、実際のタスク 1 件が完了し、結果のエクスポートとクリーンアップまで行われることを確認しました。このレシピでは、初期の実験で使用していた環境フックを、公開 SDK の呼び出しを使用する BaseEnvironment 実装に置き換えています。このリファクタリングはオフラインテストでカバーされていますが、実際のサービスに対してはまだ実行していません。また、Harbor の同時実行数を高く設定した状態での完全なデータセットの検証も行っていません。
オフラインテストと、省略可能な制御された再試行チェックについては、レシピの README を参照してください。