olmo-eval：モデル開発ループのための評価ワークベンチ

olmo-evalは、Allen AIが公開した新しい評価ワークベンチで、大規模言語モデル（LLM）の開発中に繰り返される評価サイクルを特にサポートするように設計されています。LLMを構築する際、データ、アーキテクチャ、ハイパーパラメータの調整や規模の拡大ごとに、同じループが発生します。つまり、ベンチマークの追加や再構成、新しいモデルチェックポイントでの再実行、結果の記録、小規模実験で有効だった変更が完全なトレーニング実行でも有効かどうかの確認です。既存の評価ツールのほとんどはこれに対応しておらず、完成したモデルに対して確立されたベンチマークを実行するか、サンドボックス内でマルチステップのツール使用問題を実行するかのいずれかに特化しています。それらは絶えず変化するモデルに追従できず、特定の実世界条件下でのモデルの振る舞いを反映しません。

olmo-evalは、OLMES（Open Language Model Evaluation Standard）標準に基づいています。OLMESは2024年に導入され、LLMのベンチマークスコアをリリース間で比較しやすくすることを目的としていました。同じモデルが同じベンチマークで異なる方法でスコアリングされていたため（プロンプトフォーマットやタスク策定が論文ごとに異なることが多かった）、どのモデルが最も優れているかという主張は再現可能ではないことがよくありました。OLMESは、オープンで文書化された標準としてベンチマークの選択を固定し、OlmoからTuluまでのオープンモデルの評価の基盤となりました。

しかし、モデルの最終スコアは評価プロセスの一部に過ぎません。そこで、OLMESを基盤とし、LLM開発の残りの部分に拡張する新しいワークベンチ、olmo-evalをリリースします。OLMESと比較して、olmo-evalは新しい評価の実装作業を削減し、評価の実行場所と方法を定義する柔軟性を高め、個々のコンポーネントをより大きなワークフローに組み立てやすくします。エージェント型およびマルチターン評価が第一級のユースケースとしてサポートされ、より強力な分析ツールにより、介入がベースラインを実際に改善したのか、それとも差がノイズに過ぎないのかを判断するのに役立ちます。

olmo-evalと既存ツールの違い

パフォーマンスの2.4ポイントの変化は判断を下すのに十分ですか？

olmo-evalは、コンテナ化されたサンドボックス環境内でAIエージェントを評価するためのオープンフレームワークであるHarborといくつかの点で重複します。ただし、2つのツールはその範囲が異なります。Harborは主にエージェントベンチマークの実行と公開を目的としています。olmo-evalは、モデル開発の日常業務（ベンチマークの追加と構成、チェックポイント間の実行、単一の全体スコアではなくプロンプトごとの結果分析）向けに構築されています。

Harborはすべてを同じ方法で実行します——密閉された再現可能なコンテナ内で。コンテナはリソースを大量に消費する可能性があるため、olmo-evalでは各ベンチマークの実行方法を選択できます。モデルが質問に答えるだけでよいベンチマークは直接実行でき、より高速で安価です。ロックダウンされた環境が必要なベンチマーク——たとえば、モデルが作成したコードを実行する必要があるもの——は、分離されたコンテナ設定を取得します。軽量パスがデフォルトであり、olmo-evalはベンチマークが実際に必要とする場合にのみ、重量級の設定を選択します。

Harborでベンチマークを追加するプロセスは、公開して共有する予定の評価向けに構築されており、それに伴う追加の検証手順があります。olmo-evalは、開発中に迅速に動くために構築されており、ベンチマークの追加方法はベンチマークのニーズに依存します。基本的な評価には短い定義で、ツールを使用したモデルの実行を可能にするオプションがあります。すでに独自のコードと手順を持つベンチマークには、薄いラッパーを記述して、olmo-evalがそのまま実行し、他のベンチマークスコアと同じ形式で結果を報告できるようにします。

Harborとolmo-evalはどちらも、ベンチマークをランタイムポリシー（モデルが回答を生成する方法）から分離しているため、一方を変更しても他方を書き換える必要はありませんが、olmo-evalはより高いモジュール性を実現するように設計されています。olmo-evalでは、評価されるモデル、使用できるツール、コンテナ化された環境、および補助モデル（LLM-as-a-judgeなど）はすべて交換可能なコンポーネントです。ツールを複数のハーネス間で再利用したり、スコアリングモデルを他のベンチマークに影響を与えることなく1つのベンチマークにプラグインしたり、プロンプトの正確な表現などの小さな設定を大規模な作業なく調整したりできます。

Harborは各モデルの全体的なスコアを報告します。olmo-evalもこれらのスコアを報告し、それぞれに標準誤差と最小検出可能効果（ノイズから確実に区別できる最小の差）を付けます。しかし、より有用なビューは、同じ質問を2つのモデルチェックポイントで並べて、他のすべてを固定して1つずつ比較します。これにより、全体的な平均の小さな変化が実際の改善を示しているのか、単なるノイズなのかを確認するのに役立ちます。

統合評価スタック

olmo-evalは、単独でも有用ですが、実験的なLLM開発ループを強化するために連携して動作するように設計された4つのコンポーネントで構成されています。

• タスク/スイート/ハーネス抽象化：ベンチマークロジックをランタイムポリシーから分離します。タスクはolmo-evalでベンチマークを定義する方法です——何を評価するか。スイートはタスクをグループ化して一緒に実行するセットにし、ハーネスは各タスクの実行方法を制御します。この分離により、同じタスクを標準ベースラインとして、またはツールや足場を使用して実行でき、測定内容を変更することなく実行できます。

• サンドボックスと機能ルーティングレイヤー：非同期サンドボックスプランナーを含みます。これにより、モデルの応答がツールを使用したアクション（コードの作成と実行、Webブラウジングなど）に依存する評価をサポートします。重要なのは、モデルの実際のツール使用を評価することです。ベンチマークがツールを必要とする場合、olmo-evalはそれらのツールを実行し、結果をモデルにフィードバックします。

• 正規化された実験スキーマ：すべての実行、その構成、結果を同じ構造化形式で記録します。これにより、関連する実験をグループ化し、チェックポイントを経時的に比較し、長期のモデル開発ワークフローで頻繁に蓄積される不整合を回避できます。

• 結果ビューア：ペアワイズモデル比較用：2つのモデルまたはチェックポイントを質問ごとに並べることで、全体的な平均では隠れてしまう小さなが真のパフォーマンス変化を明らかにします。

ほとんどのモデル評価設定では、ベンチマークの追加はかなりの統合プロジェクトです。olmo-evalでは、必要なのはタスクだけです——タスクはベンチマークデータセット、評価リクエストの構築方法、モデル回答のスコアリング方法を定義します（すべてPythonコード）。

オープンで再現可能な評価

評価が単発の実行ではなく、継続的なモデル開発の一部である場合にolmo-evalを使用してください——再現可能な条件下で同じベンチマークをチェックポイント間で繰り返し実行し、介入を集計レベルと質問ごとのレベルの両方で比較する必要がある場合です。

「このチェックポイントは前のものとどう異なり、どこで正確に改善または劣化したのか？」という質問が繰り返される場合、それがolmo-evalが構築されたワークフローです。

再現可能な評価は、モデルがどのように構築されるか——完成した後にどのようにスコアリングされるかだけでなく——に歩調を合わせるべきです。olmo-evalはOLMES標準をアクティブなモデル開発に持ち込み、コミュニティがそれを基に構築できるようにオープンにリリースしています。