OLMO-EVAL：モデル開発ループのための評価ワークベンチ（7 分読）

[記事一覧に戻る](https://huggingface.co/blog) 💻 コード：[https://github.com/allenai/olmo-eval](https://github.com/allenai/olmo-eval) LLM を構築している間、あなたは多くの介入を通じて何度も評価を行います。データ、アーキテクチャ、ハイパーパラメータへのあらゆる調整、およびスケールアップのすべてのステップは、同じループに戻ります：ベンチマークの追加または再構成、各新しいモデルチェックポイントでの再実行、結果の記録、そして小規模な実験で有効だったものが大規模なトレーニングランでも維持されるかどうかの確認です。 ほとんどの評価ツールはこの目的のために設計されていません。それらは完成したモデルに対して確立されたベンチマークを実行するために構築されているか、サンドボックス内で多段階のツール使用問題をモデルに実行させるために作られています。常に変化し続けるモデルに対応できず、また特定の現実世界の条件下でモデルがどのように振る舞うかを反映するものでもありません。 この評価課題に対処するための私たちの最後のプロジェクトは、[OLMES](https://github.com/allenai/olmes)、すなわちオープン言語モデル評価標準（Open Language Model Evaluation Standard）でした。2024 年に導入されたこの基準は、異なるリリース間での LLM ベンチマークスコアの比較を容易にするために作られました。同じモデルが、異なる方法で同じベンチマークにスコア付けされていました——プロンプトのフォーマットやタスクの定式化といった側面は論文ごとにしばしば異なっていたため、「どのモデルが最も優れた性能を発揮したか」という主張の多くは再現不可能でした。OLMES はベンチマーキングにおける選択事項を、オープンで文書化された標準に固定し、Olmo から Tulu までの私たちのオープンモデルの評価基準として基盤となりました。 しかし、モデルの最終スコアは評価プロセスの一部に過ぎません——だからこそ私たちは、OLMES に基づき LLM 開発の残りの部分へと拡張する新しいワークベンチ **[olmo-eval](https://github.com/allenai/olmo-eval)** を公開するのです。OLMES と比較して、olmo-eval は新規評価の実装にかかる作業を削減し、評価を実行する場所や方法を定義する際の柔軟性を高め、個々のコンポーネントをより大きなワークフローに組み合わせることを容易にします。エージェント型および多ターン評価（multi-turn evaluation）はファーストクラスのユースケースとしてサポートされており、強力な分析ツールによって、介入がベースラインに対して実際に改善をもたらしたのか、それとも単なるノイズの差に過ぎないのかを判断しやすくなっています。 ## olmo-eval が既存のツールと異なる点 *パフォーマンスが 2.4 ポイント（pp）変化したとしても、それは判断を下すのに十分な変化でしょうか？* olmo-eval は、コンテナ化されたサンドボックス環境内で AI エージェントを評価するためのオープンフレームワークである Harbor と、いくつかの点で重複しています。しかし、両者のツールの範囲は異なります。Harbor は主にエージェントベンチマークの実行と公開を対象としていますが、olmo-eval はモデル開発における日常的な作業のために構築されました。具体的には、ベンチマークの追加や設定、チェックポイント間での実行、そして単一の総合スコアではなくプロンプトごとに結果を分析する作業です。 Harbor はすべてを同じ方法で実行します—密封された再現可能なコンテナ内です。コンテナはリソースを多く消費するため、olmo-eval では各ベンチマークの実行方法をユーザーが選択できるようになっています。単にモデルに質問に答えてもらえばよいベンチマークは直接実行でき、これはより高速かつ低コストです。一方、ロックダウンされた環境が必要なベンチマーク（例えば、モデルが作成したコードを実行するものなど）には、隔離されたコンテナセットアップが用意されます。軽量なパスがデフォルトであり、olmo-eval はベンチマークが実際にそれを必要とする場合にのみ、重いセットアップを選択します。 Harbor のベンチマーク追加プロセスは、公開して共有する予定の評価用であり、それに伴う追加の検証ステップを想定しています。一方、olmo-eval は開発中の迅速な移動のために構築されており、ベンチマークの追加方法はベンチマークが何を必要とするかによります：基本的な評価のための短い定義で、モデルがベンチマークを進める際にツールを使用できるオプション付き、あるいはすでに独自のコードと手順を持つベンチマークの場合は、olmo-eval がそのまま実行し、他のベンチマークスコアと同じ形式で結果を報告できるようにする薄いラッパーです。 Harbor と olmo-eval の両方は、ランタイムポリシー（モデルが回答を生成するためにどのように実行されるか）からベンチマークを分離して保持しており、一方を変更しても他方を再記述する必要はありません。ただし、olmo-eval はより高いモジュール性を備えて設計されています。olmo-eval では、評価対象のモデル、使用可能なツール、コンテナ化された環境、および LLM-as-a-judge（LLM をジャッジとして利用する仕組み）のようなヘルパーモデルはすべて、交換可能なコンポーネントです。ツールを多数のハーンネスで再利用したり、他のベンチマークに影響を与えずに評価用モデルを一つのベンチマークに組み込んだり、プロンプトの正確な wording（文言）などの小さな設定を変更したりすることが、広範な労力なしに可能です。 Harbor は各モデルに対して総合スコアを報告します。olmo-eval も同様にスコアを報告しますが、それぞれに標準誤差と検出可能な最小効果（ノイズから確実に区別できる最小限の差異）が付随しています。しかし、より有用な視点として、同じ質問を 2 つのモデルチェックポイント間で並べて比較し、一つずつ対照させることができます。これは、他の条件はすべて固定されたままです。これにより、総合平均におけるわずかな変化が、実際の改善を示しているのか、単なるノイズに過ぎないのかを見極める手助けとなります。 If you're looking for... olmo-eval offers Authoring a multi-example benchmark Task subclass with a DataSource, metrics, and scoring surface Wrapping an existing agent-style benchmark with its own runner ExternalEval or SandboxedExternalEval; the benchmark keeps its loop and scoring, and results land in olmo-eval's schema Swapping the runtime under a fixed benchmark --harness and harness presets; the harness carries provider, tools, scaffold, sandboxes, and auxiliary providers Parallel container execution Sandbox instances for parallel executors with capability-based routing, Docker or Modal modes Tool definitions reusable across tasks and harnesses @tool decorator with optional global registry Multi-turn execution loops Scaffolds, e.g., openai_agents, selected per harness, not baked into the task definition ## An integrated evaluation stack olmo-eval は、それぞれ単独でも有用ですが、実験的な大規模言語モデル（LLM）開発ループを強化するために連携して設計された 4 つのコンポーネントで構成されています： - ベンチマークロジックとランタイムポリシーを分離するタスク/スイート/ハーン抽象化。olmo-eval におけるベンチマークの定義方法、すなわち何を評価するかを示すのが「タスク」です。「スイート」は実行するセットとして複数のタスクをグループ化し、「ハーン」は各タスクの実行方法を制御します。この分離により、測定対象を変更することなく、同じタスクを標準的なベースラインとして実行することも、ツールやスケフォールディング（支援構造）付きで実行することも可能になります。 - 非同期サンドボックスプランナーを含むサンドボックスおよび機能ルーティングレイヤー。これは、モデルの応答がツールを使用したアクション（コードの記述と実行やウェブブラウジングなど）に依存する評価をサポートします。目的は、モデルの実際のツール使用能力を評価することです。ベンチマークでツールの利用が必要となる場合、olmo-eval は該当ツールを実行し、その結果をモデルにフィードバックします。 - 各実行、その設定、および結果を同じ構造化形式で記録する正規化された実験スキーマ。これにより、関連する実験をグループ化したり、時間経過に伴うチェックポイントを比較したり、長期にわたるモデル開発ワークフローで蓄積しがちな不整合性を回避することが可能になります。 - 2 つのモデルを対比して比較するための結果ビューア：質問ごとに 2 つのモデルまたはチェックポイントを並べて表示することで、全体の平均値では隠れてしまう小さくても実在する性能変化を浮き彫りにします。 ほとんどのモデル評価設定では、ベンチマークの追加は大規模な統合プロジェクトとなります。しかし olmo-eval では、必要なものはタスクだけです。タスクはベンチマークデータセットを定義し、評価リクエストがどのように構築され、モデルの回答がどのように採点されるかを決定します（すべてのコードは Python で記述されています）: from olmo_eval.common.formatters import ChatFormatter from olmo_eval.common.metrics import AccuracyMetric from olmo_eval.common.scorers import ExactMatchScorer from olmo_eval.common.types import Instance, SamplingParams from olmo_eval.data import DataLoader, DataSource from olmo_eval.evals.tasks.common import Task, register, register_variant @register("internal_freshqa") class InternalFreshQA(Task): data_source = DataSource(path="s3://evals/internal/freshqa.jsonl", split="test") formatter = ChatFormatter() sampling_params = SamplingParams(temperature=0.0) metrics = (AccuracyMetric(scorer=ExactMatchScorer),) @property def instances(self): loader = DataLoader() for idx, doc in enumerate(loader.load(self.config.get_data_source())): yield Instance( question=doc["question"], gold_answer=doc["answer"], metadata={"id": doc.get("id", f"freshqa_{idx}"),} ) バリアントは、ベンチマークを複製することなく評価ポリシーの変更を表します: register_variant("internal_freshqa", "3shot", num_fewshot=3, fewshot_seed=1234) register_variant("internal_freshqa", "zero", num_fewshot=0) スイートは、まとめて実行するベンチマークを標準セットにグループ化します: from olmo_eval.evals.suites import Suite, register register(Suite( name="base_qa_few_shot", tasks=( "sciq:mc:3shot", "arc_challenge:mc:3shot", "internal_freshqa:mc:3shot", ), )) また、ランタイムポリシーがタスク定義ではなくハネス（harness）に存在するため、生成されたポイントトラックが単に妥当に見えるかどうかに依存するのではなく、異なる実行条件下で同じベンチマークを簡単に再実行できます。 # ベースライン olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero # 同じタスク、同じスコアリング、検索/ツールランタイム有効化 olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero --harness search_agent ## 再現可能な評価のオープン化 [olmo-eval](https://github.com/allenai/olmo-eval) は、評価が単発の実行ではなく継続的なモデル開発の一部である場合、つまり、再現性のある条件下でチェックポイント間で同じベンチマークを繰り返し実行し、集計レベルと質問ごとの両方で介入を比較する必要がある場合に使用してください。 「このチェックポイントは前回のものとどう異なり、どこで具体的に改善または後退したのか？」という繰り返しの問いがある場合、それが olmo-eval が構築されたワークフローです。 再現可能な評価は、モデルが完成して一度スコアリングされる方法だけでなく、モデルがどのように構築されるかにも合わせて進化するべきです。olmo-eval は OLMES 標準をアクティブなモデル開発に持ち込み、コミュニティがこれを基盤として構築できるようにオープンにリリースしています。

OLMO-EVAL：モデル開発ループのための評価ワークベンチ（7 分読）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト