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 は新規評価の実装にかかる作業を削減し、評価を実行する場所や方法を定義する際の柔軟性を高め、個々のコンポーネントをより大きなワークフローに組み立てやすくします。エージェント型および多ターン評価はファーストクラスユースケースとしてサポートされており、強力な分析ツールによって、介入がベースラインに対して実際に改善をもたらしたのか、それとも単なるノイズの差に過ぎないのかを判断しやすくなっています。 ## olmo-eval と既存ツールの違い olmo-eval は、コンテナ化されたサンドボックス環境内で AI エージェントを評価するためのオープンフレームワークである Harbor と、いくつかの点で重複しています。しかし、両者のツールは範囲において異なります。Harbor は主にエージェントベンチマークの実行と公開を対象としていますが、olmo-eval はモデル開発における日常的な作業のために構築されました。具体的には、ベンチマークの追加と設定、チェックポイント間での実行、そして単一の総合スコアではなくプロンプトごとに結果を分析する作業です。 Harbor は、すべてを密封された再現可能なコンテナ内で同じ方法で実行します。コンテナはリソースを多く消費する可能性があるため、olmo-eval では各ベンチマークの実行方法をユーザーが選択できます。質問に答えるだけで済むモデルが必要なベンチマークは直接実行でき、これはより高速かつ低コストです。一方、コードを実行するなど厳格な環境が必要なベンチマーク（例：モデルが作成したコードを実行するもの）には、隔離されたコンテナセットアップが用意されます。軽量なパスがデフォルトであり、olmo-eval はベンチマークが実際にそれを必要とする場合にのみ、重いセットアップを選択します。 Harbor のベンチマーク追加プロセスは、公開して共有することを計画した評価（evals）向けに設計されており、それに伴う追加の検証ステップが含まれています。一方、olmo-eval は開発中の迅速な移動を目的としており、ベンチマークの追加方法はベンチマークが何を必要とするかによって異なります。基本的な評価には短い定義を提供し、モデルがツールを使用できるオプションを追加したり、すでに独自のコードと手順を持つベンチマークには薄いラッパー（wrapper）を追加して、olmo-eval がそのまま実行できるようにし、他のベンチマークスコアと同じ形式で結果を報告できるようにします。 Harbor と olmo-eval の両方とも、ベンチマークをランタイムポリシー（モデルの回答生成方法）から分離して設計しているため、一方を変更しても他方を再記述する必要はありませんが、olmo-eval はより高いモジュール性を備えています。olmo-eval では、評価対象となるモデル、使用可能なツール、コンテナ化された環境、そして LLM-as-a-judge（LLM を用いた採点者）のようなヘルパーモデルなど、すべてが交換可能なコンポーネントとして構成されています。一つのツールを多数のハーンネスで再利用したり、あるベンチマークに評価モデルを組み込んだりしても他のベンチマークに影響を与えずに済みますし、プロンプトの正確な文言といった細かい設定も多大な労力なく調整可能です。 Harbor は各モデルに対して総合スコアを報告します。olmo-eval も同様にスコアを報告しますが、それには標準誤差と検出可能な最小効果（ノイズから確実に区別できる最小限の差異）が併記されます。しかし、より有用な視点として、同じ質問を2 つのモデルチェックポイントにわたって並べ、他はすべて固定した状態で一つずつ比較するアプローチがあります。これにより、総合平均における微小な変化が実際の改善を示しているのか、単なるノイズに過ぎないのかを判断しやすくなります。 **もしあなたが探しているものが…なら、olmo-eval は以下を提供します** 複数例を含むベンチマークの作成：**Task** サブクラスと **DataSource**、メトリクス、スコアリングサーフェスの定義 既存のエージェント型ベンチマークを独自のランナーでラップする：**ExternalEval** または **SandboxedExternalEval**；ベンチマーク自体のループとスコアリングは維持され、結果はスキーマに格納されます 固定されたベンチマーク**harness**とharnessのプリセットの下でランタイムを切り替えること; harness はプロバイダー、ツール、スケフォールド、サンドボックス、および補助プロバイダーを担う 並列コンテナ実行: 能力ベースルーティングを持つ並列実行用のサンドボックス**インスタンス**。Docker または Modal モードに対応 タスクやharness間で再利用可能なツールの定義:**@tool**デコレーターとオプションのグローバルレジストリ 多ターン実行ループ: **openai_agents**などのスケフォールド。harness ごとに選択され、タスク定義に埋め込まれるものではない ## 統合された評価スタック olmo-eval は、それぞれ単独でも有用でありながら、実験的な大規模言語モデル (LLM) の開発ループを強化するために連携して動作するように設計された4つのコンポーネントで構成されています: - ベンチマークロジックとランタイムポリシーを分離するタスク/スイート/ハーン抽象化。タスクとは、olmo-eval におけるベンチマークの定義方法（何を評価するか）です。スイートは実行するセットとしてタスクをグループ化し、ハーンは各タスクの実行方法を制御します。この分離により、測定対象を変更することなく、同じタスクを標準ベースラインとして、あるいはツールやスケフォールディング付きで実行することが可能になります。 - 非同期サンドボックスプランナーを含むサンドボックスおよび機能ルーティングレイヤー。これは、モデルの応答がツールを使用したアクション（コードの記述と実行やウェブブラウジングなど）に依存する評価をサポートします。目的は、モデルの実際のツール使用を評価することです。ベンチマークでツールの利用が必要となる場合、olmo-eval はそのツールを実行し、結果をモデルにフィードバックします。 - 各ラン、その構成、および結果を同じ構造化形式で記録する正規化された実験スキーマ。これにより、関連する実験のグループ化や、時間経過に伴うチェックポイントの比較が可能になり、長期にわたるモデル開発ワークフローで蓄積しがちな不整合性を回避できます。 - 2 つのモデルを対比して比較するための結果ビューア：質問ごとに 2 つのモデルまたはチェックポイントを並べることで、全体の平均値では隠れてしまう小さくても実在するパフォーマンスの変化を浮き彫りにします。 ほとんどのモデル評価設定において、ベンチマークを追加するには大規模な統合プロジェクトが必要です。しかし olmo-eval では、*タスク* 1 つで十分です。タスクは、ベンチマークデータセットの定義、評価リクエストの構築方法、およびモデル回答の採点方法を規定します： 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 標準をアクティブなモデル開発に持ち込み、コミュニティがこれに基づいて構築できるようにオープンにリリースしています。 ## Ai2 の最新ニュースに関する月次更新を受け取るには購読してください。

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

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

調べる

選ぶ

サイト