AI評価を始めるのが、かつてないほど簡単になった。それを確実に再現できるかどうかはまた別の話だ。開発者は、これまで以上に多くのベンチマーク、評価ライブラリ、モデルAPI、エージェントフレームワークを利用できるようになりました。しかし、プロンプト、モデル、採点方法を固定したとしても、必ずしも実行結果が再現可能になるわけではない。実行環境も重要です。
Pythonの依存関係が変わります。ローカルツールが変化する。セットアップ手順は文書化されていない。あるマシンで正常に動作するワークフローでも、別のマシンでは異なる動作をする場合があります。評価に関する議論のほとんどは、何を測定すべきか、つまりベンチマーク、採点方法、あるいは評価モデルといった点に焦点を当てている。そうした評価がどのように実施されるかについては、あまり注意が払われていない。しかし、その実行段階こそが、数週間後あるいは数か月後に他の人が同じワークフローを再現できるかどうかを左右することが多いのです。
私がDocker Sandboxの調査を始めたとき、別の評価フレームワークを構築しようとしていたわけではありませんでした。もっと些細な質問がありました。
DockerサンドボックスとSBXキットを使えば、評価ワークフローの再実行、検証、比較が容易になるだろうか？
その疑問は最終的にSBX AI評価キットへと発展しました。これは、再現可能な実行、構造化された評価記録、およびランタイムの証拠に焦点を当てた、オープンソースのDockerサンドボックスMixinキットです。現在の実装では、AIモデルを実行したり、評価判断を自動的に導き出したりすることはありません。その代わりに、設定されたコマンドを一貫して実行し、実際に実行された内容の証拠を保存します。
実践編
実際には、ワークフローはまず、評価コマンドをexecutionブロック内のどこで実行するかを選択することから始まります。
execution:
executor: sbx
command:
- python3
- -c
- print("hello from sbx")
executor: sbx指定すると、ランナーはコマンドの実行を Docker サンドボックスに委任し、実行時の証拠を結果として得られるアーティファクトに書き込みます。
このリポジトリはSBX Mixin Kitとしてもパッケージ化されているため、Claudeサンドボックスの起動時に適用できます。
sbx run claude --kit .
ランナーは設定されたエグゼキュータを読み取り、コマンドをSBXに委任します。SBXはサンドボックス内でそのコマンドを実行します。
python run_evaluation.py
ドキュメントから実行可能なワークフローへ
各評価は、評価内容と実行するコマンドを記述したYAMLファイルで定義されます。リポジトリはその定義を検証し、実行し、結果を構造化されたJSONレコードとして生成します。違いは、何が記録されるかという点にある。書面による評価は、その人が何をしようとしていたかを記録するものである。実行状況に基づいた評価は、実際に何が起こったのかを捉える。
評価と実行の分離
評価定義は、実行場所に関係なく独立していなければならないと考えました。ローカル開発中に作成されたワークフローは、後でDockerサンドボックス内で実行されるという理由だけで変更する必要はありません。
これらの懸念事項を分離するために、私は実行者抽象化を導入しました。評価では何を実行するべきかが記述され、実行者はそれをどこで実行するかを決定する。
ローカル実行環境を使用すると、設定されたコマンドはホスト上で実行されます。SBXエグゼキュータを使用すると、コマンドの実行はDockerサンドボックスに委任されます。両者を切り替えるには、実行環境の設定を変更するだけでよく、周囲の評価ワークフローを書き換える必要はありません。
図1。評価定義は実行環境に依存しない。同じワークフローで、ローカルエグゼキュータまたはSBXエグゼキュータのどちらを使用しても、実行時エビデンスを同じ構造で生成できます。
憶測ではなく証拠を収集する
実行ごとに、ランナーは実際に何が起こったかを調査するのに十分な情報を記録します。
- 選任された遺言執行者、
- 実行されたコマンド、
- 標準出力（
stdout）と標準エラー（stderr）、 - 終了コード、
- そして実行時間。
これらの詳細は評価成果物に保存されます。リポジトリは評価構成の要約も生成します。これにより、完全な実験追跡システムを置き換えることなく、評価構成とそれが生成する成果物との間に決定論的なリンクが作成されます。
{
"executor": "sbx",
"command": ["python3", "-c", "print(\"hello from sbx\")"],
"stdout": "hello from sbx\n",
"stderr": "",
"exit_code": 0,
"duration_ms": 120.0
}
1つの評価から多数の評価への拡張
実際の評価は、単一の実行だけで行われることはほとんどない。チームはプロンプトを比較し、動作を検証し、リリース間の回帰を測定し、複数のシナリオをテストします。それが評価スイートの開発につながった。
個々の評価方法を変更するのではなく、評価スイートは複数の評価定義を単一の反復可能なワークフローにグループ化します。各評価はそれぞれ独自の構造化された成果物を生成する一方、スイート全体では全体の実行結果をまとめた要約も生成する。
評価を超えた再利用可能なSBXキット
同様のパターンは評価に限ったことではない。SBXキットは、開発環境だけでなく、エンジニアリングワークフローが依存するセットアップもパッケージ化できます。同じモデルは、回帰テスト、ポリシーチェック、セキュリティ分析、コード生成実験、および一貫した実行と検証可能な結果に依存するその他のワークフローをサポートできる。
結論
SBX AI評価キットは、評価フレームワーク、ベンチマーク、またはスコアリングシステムに取って代わるものではありません。その役割はより限定的で、設定された評価ワークフローを、再実行や検証が容易な方法で実行することである。
私が抱いた疑問は単純だ。ベンチマークスコアを比較したり、評価モデルを選択したりする前に、他の人が同等の条件下で同じワークフローを確実に実行できるだろうか？
GitHub の sbx-ai-eval-kit リポジトリでは、コードを調べたり、カスタム評価 YAML を試したり、ワークフローを自分で実行したりできます。
リソース
- SBX AI評価キット– ソースコード、評価定義の例、およびこの記事で説明する実装。
- Docker Sandboxes ドキュメント– Docker Sandboxes のセットアップと実行に関する公式ドキュメント。
- キットを使用した Docker サンドボックスのカスタマイズ– 再利用可能なキットを使用して Docker サンドボックスを拡張するための公式ドキュメント。
