AI eval ツール: lm-evaluation-harness — ベンチマーク標準

lm-evaluation-harness (通称 lm-eval、または lm-eval-harness) は、EleutherAI が開発する学術ベンチマーク用の OSS フレームワークです。MMLU、HellaSwag、GSM8K、HumanEval、ARC、TruthfulQA といった標準ベンチマークを、統一された CLI から走らせられます。LLM の素の能力 (capability benchmark) を測るための de facto 標準で、Hugging Face の Open LLM Leaderboard もこれを裏側で使っています。

本記事では、2020 年代初期から今日まで残り続けている理由、主な機能、最小動作例、Inspect AI との棲み分け、そしてハマりやすい点を整理します。

EleutherAI と歴史

EleutherAI は 2020 年に Discord で発足した非営利の研究コミュニティで、GPT-Neo、GPT-J、Pythia といった初期のオープンモデル群で知られます。lm-evaluation-harness は 2021 年ごろ、GPT-Neo の論文実験を再現可能にする目的で書かれました。ライセンスは MIT で、現在も活発にメンテナンスされています。

GPT-3 以降、各社・各研究室が独自のベンチマーク実装を回していましたが、プロンプト整形や few-shot の組み方が微妙に違うため、論文間で数字を直接比べられないという問題がありました。lm-evaluation-harness は「同じコードで同じ条件で測る」ことを最初から目標に置いています。2022 年ごろから学術コミュニティでの採用が加速し、2023 年の Hugging Face Open LLM Leaderboard 採用で事実上の標準になりました。

なぜ乱立しなかったか

評価ツールは普通、各社・各ラボで独自実装が乱立しがちです。にもかかわらず lm-evaluation-harness が標準になったのは、以下のような理由があります。

第一に、EleutherAI 自体が特定の商用ベンダーに紐づかない非営利コミュニティで、中立的に受け止められました。学術論文で引用しやすい立ち位置です。

第二に、タスク定義が YAML/Jinja2 ベースで、プロンプトテンプレートがコードから分離されています。「論文 X と全く同じプロンプトで測りたい」という要求を、設定ファイル差分として提示できます。

第三に、Hugging Face transformers、vLLM、OpenAI 互換 API、ONNX、SGLang、NVIDIA NeMo など主要バックエンドを一通り押さえています。モデルの入手経路に合わせてバックエンドを切り替えられ、ロックインがありません。

第四に、Open LLM Leaderboard が lm-evaluation-harness を採用した影響があります。「leaderboard で勝つには lm-eval で走らせる必要がある」という事実上の制約が働き、網羅性の勝負は網羅した者が勝つという循環を生みました。

主な機能

v0.4 系で以下の機能が揃っています。

• 統一 CLI — lm_eval コマンドひとつで全タスクを走らせられる
• 数百のタスク — 60 以上のベンチマーク、サブタスク込みで数百種類
• 多様なバックエンド — HF transformers、vLLM、OpenAI、Anthropic、TextSynth、SGLang、Megatron-LM、NeMo、OpenAI 互換ローカルサーバ
• 量子化評価対応 — AutoGPTQ、GPTQModel、bitsandbytes などで量子化したモデルの能力劣化を測れる
• YAML/Jinja2 タスク定義 — プロンプト、few-shot 例、採点ロジックを設定ファイルで記述
• ログ・再現性 — 乱数シード、プロンプト、サンプル単位の出力まで保存
• 並列化 — tensor / data parallel、batch_size 自動調整
• サブコマンド — lm_eval run、lm_eval ls、lm_eval validate などの管理コマンド

最小動作例

インストールはバックエンドごとに extras を指定します。

pip install "lm_eval[hf]"      # Hugging Face
pip install "lm_eval[vllm]"    # vLLM
pip install "lm_eval[openai]"  # OpenAI API

Llama 3 8B を MMLU と GSM8K で測る、典型的な実行例はこうです。

lm_eval --model hf \
    --model_args pretrained=meta-llama/Meta-Llama-3-8B \
    --tasks mmlu,gsm8k \
    --device cuda:0 \
    --batch_size 8

vLLM バックエンドなら数倍速くなります。

lm_eval --model vllm \
    --model_args pretrained=meta-llama/Meta-Llama-3-8B,tensor_parallel_size=2,dtype=auto \
    --tasks hellaswag,arc_easy,arc_challenge \
    --batch_size auto

OpenAI 互換 API を叩く場合はこうです。

lm_eval --model openai-chat-completions \
    --model_args model=gpt-4o-mini \
    --tasks truthfulqa_mc2 \
    --limit 100

結果は stdout にスコアテーブルで表示され、--output_path を指定すれば JSON と per-sample ログが書き出されます。

支える主要タスク

典型的に走らせるベンチマークは以下です。

• MMLU (Massive Multitask Language Understanding) — 57 分野の多肢選択で、汎用知識の指標
• HellaSwag — 文完成の常識推論
• GSM8K — 小学校レベルの算数文章題
• HumanEval / MBPP — Python コード生成
• ARC (AI2 Reasoning Challenge) — 科学問題の多肢選択
• TruthfulQA — 誤情報を避ける能力
• Winogrande — 代名詞照応による常識推論
• BIG-Bench Hard (BBH) — Google BIG-Bench のうち、LLM が苦手な 23 タスク
• GPQA、MATH、IFEval — 近年の leaderboard v2 系で追加された難問系

タスク一覧は lm_eval --tasks list で確認できます。

Hugging Face Open LLM Leaderboard との関係

Hugging Face Open LLM Leaderboard は、公開モデルを横並びで比較するリーダーボードで、2023 年から運営されています。評価実行は lm-evaluation-harness が担当しており、投稿されたモデルは Hugging Face 側のクラスタで自動的に lm-eval を使ってスコア計算されます。

Leaderboard v1 (2023) は ARC、HellaSwag、MMLU、TruthfulQA、Winogrande、GSM8K の 6 タスク構成でした。v2 (2024 年リニューアル) は IFEval、BBH、MATH、GPQA、MuSR、MMLU-Pro の 6 タスクに刷新され、より難しい問題が中心になっています。いずれも lm-eval 側に leaderboard タスクグループとして用意されており、同じ条件を手元で再現できます。

向くケース・向かないケース

向くケース

• 公開モデル同士の capability 比較 (A の MMLU は B より何ポイント高いか)
• 学術論文での再現性ある測定
• 量子化や fine-tuning の効果測定 (ベースモデルとの差分を同じベンチマークで評価)
• 新しいモデルを公開する前の社内 QA (リーダーボードに出す前の下見)

向かないケース

• プロダクト固有の品質評価 (ユーザーのプロンプトや tone に合わせた判定)
• マルチターン agent の tool 呼び出し評価
• 安全性 / red teaming 評価 (危険能力、CBRN など)
• LLM-as-a-judge を主軸にした主観採点

lm-evaluation-harness は「静的なデータセットに対する静的な正解判定」が中心なので、動的に振る舞う agent や、人間基準で採点したい用途には別のツールを選びます。

Inspect AI との棲み分け

同じ「学術色の強い評価 OSS」として Inspect AI (UK AISI 製) と比較されますが、志向はかなり違います。

• lm-evaluation-harness: capability benchmark 専門。既存ベンチマークをそのまま再現する
• Inspect AI: agent 評価、safety 評価、tool 使用付きの動的タスク向け

モデル公開前の「MMLU で何点か」は lm-eval、frontier model の「サイバー攻撃能力の閾値を超えたか」は Inspect AI、という使い分けになります。Hugging Face Open LLM Leaderboard のスコアを再現したいなら lm-eval 一択ですし、UK AISI の pre-deployment eval を回したいなら Inspect AI です。両者は競合というより補完関係です。

ハマりポイント

実務で詰まる点をいくつか挙げます。

一つめは計算リソースです。MMLU 一つで約 14,000 サンプル、BBH で約 6,500 サンプルあります。7B モデルでも full suite を走らせると GPU 時間が数時間かかります。--limit でサンプル数を絞って動作確認してから本番に進むのが安全です。

二つめは cherry-picking バイアスです。モデルベンダーが「MMLU で 85 点」と主張しても、few-shot の数、プロンプト整形、サンプリング条件を変えれば数字は動きます。lm-eval でデフォルト設定を走らせた数字と比較するのが、再現可能な出発点になります。

三つめはベンチマーク汚染 (data contamination) です。公開ベンチマークの問題文が学習データに混入している可能性は年々高まっており、「素のスコア」が能力ではなく記憶を測ってしまうリスクが指摘されています。GPQA や MATH のような難問系、あるいは非公開テストセットを併用するのが現実的な回避策です。

四つめはバックエンド間の微妙な差です。HF transformers と vLLM では、同じモデル・同じプロンプトでも tokenizer や sampling の実装差でスコアがわずかにずれることがあります。論文で数字を主張するなら、バックエンドを明記するのが礼儀です。

五つめはタスク定義のバージョン互換性です。lm-eval 自身のバージョンが上がるとタスク定義も更新されることがあり、過去の数字と直接比較できない場合があります。--include_path でタスク YAML を固定し、lm-eval のタグも併せて記録しておくと再現しやすくなります。

chaff grade との関係

chaffjs の grade は、プロダクト eval 文脈で決定論的な採点を担当するツールです。LLM-judge の意見的な採点と、事実ベースの採点を分離する用途で使います。

lm-evaluation-harness は capability benchmark 用途です。正解ラベルがデータセットに固定されており、採点は perplexity ベースや正規表現マッチなどすでに決定論的になっています。LLM-judge をあえて組み込まないのが設計方針なので、chaff grade と直接統合する例もありません。この住み分けは chaffjs の README 最終段落 にも明記されています: “lm-evaluation-harness and Arize Phoenix need nothing chaff-specific”。

まとめ

lm-evaluation-harness は、公開モデルの capability を再現可能に測るための標準フレームワーク です。2026 年現在、Hugging Face Open LLM Leaderboard の基盤として、また各モデル公開時の自社ベンチマーク発表の裏側として、依然として一線で使われ続けています。プロダクトの eval には向きませんが、「このモデルは MMLU で何点か」「量子化で何ポイント落ちたか」といった素の能力評価では、まず lm-eval を手に取ることになります。学術色が強く重めのツールですが、評価数字の読み方を身につける意味でも、一度は手元で動かしておく価値があります。

関連記事

• AI eval ツール 10 選 — 比較と使い分け
• AI eval ツール: Inspect AI
• AI eval ツール: OpenAI Evals
• AI eval ツール: Phoenix
• AI エージェント評価サーベイ論文を読み解く

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。