LLM評価ハーネス（エルエルエムヒョウカハーネス）
LLM（大規模言語モデル）の性能を体系的に測定・比較するためのフレームワーク。EleutherAI が開発した lm-evaluation-harness が代表的な実装であり、数百種類のベンチマークを統一インターフェースで実行できる。
LLM評価ハーネスとは
LLM評価ハーネス（LLM Evaluation Harness）は、大規模言語モデルの能力を定量的・再現可能な形で測定するための統合テストフレームワークである。最も広く利用されているのは EleutherAI が開発・公開している lm-evaluation-harness（通称 lm-eval）で、HuggingFace Open LLM Leaderboard の公式評価ツールとしても採用されている。
モデル開発者が独自のベンチマーク結果を自己申告する従来の手法では、評価条件の不統一（プロンプト形式、few-shot 数、トークナイザの違い等）により公平な比較が困難だった。評価ハーネスはこの問題を解決し、同一条件下での横断的な性能比較を可能にする。
主要な評価ハーネスの比較
| ハーネス名 | 開発元 | 対応タスク数 | 特徴 |
|---|---|---|---|
| lm-evaluation-harness | EleutherAI | 400+ | OSS標準、HuggingFace連携 |
| HELM | Stanford CRFM | 80+ | 多軸評価（精度・公平性・毒性） |
| OpenCompass | 上海AI研究所 | 100+ | 中国語ベンチマーク充実 |
| Eval Harness (OpenAI) | OpenAI | 非公開 | 内部利用、Evals リポジトリで一部公開 |
| BigBench | 200+ | 204タスク、学際的 | |
| LightEval | HuggingFace | 60+ | 軽量・高速、lm-eval互換 |
アーキテクチャと動作原理
lm-evaluation-harness のアーキテクチャは以下の4層で構成される。
モデルインターフェース層
対象モデルへの統一アクセスを提供する。HuggingFace Transformers、GGUF（llama.cpp）、vLLM、OpenAI API、Anthropic API など複数のバックエンドに対応しており、--model フラグで切り替え可能である。
# HuggingFace モデルの評価
lm_eval --model hf --model_args pretrained=meta-llama/Llama-3.1-8B-Instruct --tasks mmlu --num_fewshot 5
# vLLM バックエンドの評価
lm_eval --model vllm --model_args pretrained=meta-llama/Llama-3.1-8B-Instruct,tensor_parallel_size=2 --tasks mmlu
# OpenAI API の評価
lm_eval --model openai-completions --model_args model=gpt-4o --tasks mmlu
タスク定義層
各ベンチマークをYAML形式のタスク設定ファイルで定義する。プロンプトテンプレート、評価メトリクス、データセットの取得方法、few-shot 例の構成方法を宣言的に記述できる。
評価実行層
バッチ処理によるトークン生成と対数尤度計算を効率的に実行する。loglikelihood（選択肢の尤度比較）、generate_until（自由生成＋正規表現マッチ）、loglikelihood_rolling（パープレキシティ算出）の3つの評価モードを提供する。
集計・レポート層
タスクごとのスコアを集計し、JSON/CSV 形式で出力する。WandB（Weights & Biases）や MLflow への自動ログ記録にも対応している。
評価手法の分類
LLM の評価手法は大きく以下の4カテゴリに分類される。
| 評価手法 | 説明 | 代表的ベンチマーク | 長所 | 短所 |
|---|---|---|---|---|
| 多肢選択式 | 正解選択肢の対数尤度で判定 | MMLU, ARC, HellaSwag | 自動化容易、再現性高 | 実用能力と乖離 |
| 自由生成式 | 生成テキストを正規表現や完全一致で判定 | HumanEval, GSM8K | 実用に近い評価 | 採点基準の曖昧さ |
| ヒューマン評価 | 人間の評価者が品質を判定 | Chatbot Arena, AlpacaEval | 最も実用的 | コスト高、再現性低 |
| LLM-as-Judge | 別の LLM が生成品質を評価 | MT-Bench, Arena-Hard | スケーラブル | 評価バイアスの存在 |
実運用での活用パターン
CI/CD パイプラインへの統合
モデルのファインチューニングや量子化後に自動テストとして評価ハーネスを実行し、性能劣化（リグレッション）を検知する。
# GitHub Actions での評価自動化例
evaluate:
runs-on: gpu-runner
steps:
- uses: actions/checkout@v4
- name: Run evaluation
run: |
lm_eval --model hf \
--model_args pretrained=./finetuned-model \
--tasks mmlu,hellaswag,arc_challenge \
--num_fewshot 5 \
--batch_size auto \
--output_path results/
- name: Check regression
run: python scripts/check_regression.py results/
モデル選定ワークフロー
複数の候補モデルを同一ベンチマークスイートで評価し、用途に最適なモデルを選定する。コスト（推論速度・メモリ使用量）と精度のトレードオフを定量化できる。
カスタムドメイン評価
業務固有のタスク（法律文書要約、医療用語抽出、コードレビュー等）に対するカスタムベンチマークを定義し、汎用ベンチマークでは測定できないドメイン特化性能を評価する。
評価ハーネスの限界と注意点
- データ汚染（Contamination）: 評価データがモデルの学習データに混入している可能性がある。lm-eval は
--decontamination_ngrams_pathで汚染検出を試みるが完全ではない - ベンチマーク飽和: 既存ベンチマークのスコアが上限に近づき、モデル間の差異が測定困難になる現象。MMLU では複数のモデルが90%超を達成している
- タスク形式依存性: 同じ知識を問う場合でも、プロンプト形式（0-shot vs 5-shot、Chain-of-Thought の有無）によりスコアが大幅に変動する
- 実用性との乖離: ベンチマークスコアが高くても、実際のユースケースでの品質と相関しない場合がある
よくある質問（FAQ）
Q1: lm-evaluation-harness と HELM はどう使い分けるべきか？
lm-evaluation-harness はタスク数と対応モデルの幅広さが強みで、モデル開発者・研究者のデファクトスタンダードである。HELM は精度だけでなく公平性・毒性・ロバスト性など多軸での評価が必要な場合（企業のモデル選定・コンプライアンス評価）に適している。まずは lm-eval で基本性能を測定し、必要に応じて HELM で多軸評価を追加するのが実践的なアプローチである。
Q2: 評価ハーネスの実行にはどの程度の計算資源が必要か？
タスク数とモデルサイズに依存する。7B パラメータモデルで MMLU（57科目・約14,000問）を評価する場合、A100 80GB GPU 1枚で約30分〜1時間が目安である。vLLM バックエンドを使用すると Continuous Batching により2〜3倍高速化できる。API ベースのモデル（GPT-4o 等）では GPU は不要だが、API コストと Rate Limit に注意が必要である。
Q3: 自社モデルの評価結果を公開する際の注意点は？
評価条件（few-shot数、プロンプト形式、バージョン、デコーディング設定）を完全に開示することが重要である。lm-eval の --log_samples フラグでサンプルレベルの予測結果を保存し、再現可能性を担保するのがベストプラクティスである。Open LLM Leaderboard への提出では、lm-eval の特定バージョンと設定が指定されている。