2026-08-27·無料·論文·13分で読めます

LLM評価を1から — ベンチマークの読み方と汚染問題

モデル発表資料に並ぶベンチマークの棒グラフを、正しく疑いながら読むための記事。採点方式がMMLUのスコアを動かす仕組み、問題数から来る誤差の幅、公開ベンチマークが構造的に汚染される理由、Chatbot ArenaのBradley-Terryモデルとその弱点、LLM-as-a-judgeの三つの偏りまでを1から扱う。

要点

MMLUは57科目・4択・1万問超の多肢選択テストで、でたらめに答えても25点取れる。
同じモデル・問題でも、生成して答えを拾う方式と尤度で選ぶ方式ではスコアが違う。
スコアは標本平均で、SE=√(p(1-p)/n)。200問での「3ポイント勝った」はほとんど何も言っていない。
汚染は公開ベンチマークの構造的な帰結で、「していない」の証明はできない。
LLM-as-a-judgeには位置・冗長性・自己優遇の偏りがあり、Arenaの順位は好みを測っている。

#evaluation #benchmark #contamination #llm-as-a-judge #mmlu

対象textタスクevaluation

Measuring Massive Multitask Language Understanding

一次資料 — この記事の根拠

論文の発表 2020-09-07→この解説の公開 2026-08-276年後

Measuring Massive Multitask Language UnderstandingDan Hendrycks, Collin Burns, Steven Basart ほか · 2020-09-07 · v3arXiv:2009.03300論文ページ·PDF

Judging LLM-as-a-Judge with MT-Bench and Chatbot ArenaLianmin Zheng, Wei-Lin Chiang, Ying Sheng ほか · 2023-06-09 · v4arXiv:2306.05685論文ページ·PDF

Chatbot Arena: An Open Platform for Evaluating LLMs by Human PreferencearXiv:2403.04132論文ページ·PDF

A Careful Examination of Large Language Model Performance on Grade School ArithmeticarXiv:2405.00332論文ページ·PDF

原文の要旨（Abstract）を読む

We propose a new test to measure a text model's multitask accuracy. The test covers 57 tasks including elementary mathematics, US history, computer science, law, and more. To attain high accuracy on this test, models must possess extensive world knowledge and problem solving ability. We find that while most recent models have near random-chance accuracy, the very largest GPT-3 model improves over random chance by almost 20 percentage points on average. However, on every one of the 57 tasks, the best models still need substantial improvements before they can reach expert-level accuracy. Models also have lopsided performance and frequently do not know when they are wrong. Worse, they still have near-random accuracy on some socially important subjects such as morality and law. By comprehensively evaluating the breadth and depth of a model's academic and professional understanding, our test can be used to analyze models across many tasks and to identify important shortcomings.

原文の要旨（Abstract）を読む

Evaluating large language model (LLM) based chat assistants is challenging due to their broad capabilities and the inadequacy of existing benchmarks in measuring human preferences. To address this, we explore using strong LLMs as judges to evaluate these models on more open-ended questions. We examine the usage and limitations of LLM-as-a-judge, including position, verbosity, and self-enhancement biases, as well as limited reasoning ability, and propose solutions to mitigate some of them. We then verify the agreement between LLM judges and human preferences by introducing two benchmarks: MT-bench, a multi-turn question set; and Chatbot Arena, a crowdsourced battle platform. Our results reveal that strong LLM judges like GPT-4 can match both controlled and crowdsourced human preferences well, achieving over 80% agreement, the same level of agreement between humans. Hence, LLM-as-a-judge is a scalable and explainable way to approximate human preferences, which are otherwise very expensive to obtain. Additionally, we show our benchmark and traditional benchmarks complement each other by evaluating several variants of LLaMA and Vicuna. The MT-bench questions, 3K expert votes, and 30K conversations with human preferences are publicly available at https://github.com/lm-sys/FastChat/tree/main/fastchat/llm_judge.

「ベンチマークで最高点」は何を言っているのか

新しいモデルが出るたび、発表資料には棒グラフが並びます。MMLU、GSM8K、HumanEval — 名前は違っても、どれも「高いほど賢い」という顔をしています。けれどこの棒グラフを読むには、少なくとも三つのことを知っている必要があります。何を測ったのか、どう採点したのか、そして出題される前にその問題を見ていなかったかです。

近いのは模試です。偏差値70は「この模試の、この受験者層の中で、この出題傾向に対して」の70であって、本番で上位に入れる保証ではありません。さらに受験者の一人が事前に同じ問題冊子を手に入れて暗記していたなら、その70は学力ではなく記憶の証明になります。LLMの評価で起きているのは、まさにこの二つ — 的がずれる問題と、問題が漏れる問題です。

MMLUの中身を開ける

MMLUは "Massive Multitask Language Understanding" の略で、2020年に公開された多肢選択テストです（Hendrycks et al.）。中身は素朴で、57科目・4択・1万問超。高校物理から法学、医学まで、人間向けの試験問題を寄せ集めた構成です。

4択なので、でたらめに答えても25点取れます。0点が下限ではないので、スコアは「25点を起点とした伸び」として見ないと改善幅を過大評価します。

そして点数を大きく動かすのに表に出ないのが採点方法です。4択を解かせる方法には主に二つあります。

生成させて拾う: 「答えは B です」と書かせて、出力テキストからBを取り出す
尤度で選ぶ: A/B/C/D それぞれを続きとして書いたときの確率を計算し、いちばん高いものを選ぶ

同じモデル・同じ問題でも、この二つはスコアが違います。1は答えを抽出する処理の出来に左右され、2はそもそも「モデルが自由に喋ったときの正しさ」を測っていません。論文やモデルカードのMMLUを比べるときは、採点方式とfew-shot数（例示を何問見せたか）が揃っているかを最初に確認します。揃っていない数字を並べるのは、単位の違う量を同じ軸に載せるのと同じです。

測れないものもはっきりさせておきます。4択が見るのは選択肢の中から選ぶ能力だけです。根拠を説明できるか、知らないことを「知らない」と言えるか、長い文脈を保てるか、指示の細部に従えるか — 製品で効いてくる性質の多くは、この形式の外側にあります。ベンチマークが高いのに使ってみるとがっかりする、という経験の多くはここから来ます。

スコアは1つの数字ではなく、幅を持った推定値

スコアは、ありうる全問題の中から $n$ 問を抜き出して測った標本平均です。標本である以上、誤差があります。

\mathrm{SE} = \sqrt{\frac{p(1-p)}{n}}

(1)

$p$ は正答率（0〜1）、 $n$ は問題数、 $\mathrm{SE}$ は「同じ実力のモデルで測り直したとき、スコアがどれくらいばらつくか」です。ばらつきは問題数の平方根に反比例して縮みます。

数を入れます。 $p=0.85$ 、 $n=14{,}000$ なら $\mathrm{SE}$ は約0.3ポイント、95%の幅で±0.6ポイントほど。一方 $n=200$ （難問系のベンチマークにはこの桁のものがあります）だと約2.5ポイント、幅は±5ポイントに広がります。つまり200問のベンチマークで「3ポイント勝った」は、ほとんど何も言っていません。しかもこれは問題の選ばれ方だけの誤差で、生成のゆらぎ、few-shot例の選び方、プロンプトの言い回しによる差はこの上に乗ります。

FIG 1次数を上げるほど訓練データには合うのに、テストでは外れていく。公開ベンチマークを見ながらデータやプロンプトを何十回も調整する行為は、これと同じ構造でリーダーボードに過学習していく

この図の「訓練データ」を公開ベンチマーク、「テストデータ」を実際のユーザーの入力に置き換えると、業界全体の縮図になります。誰もがMMLUを見て学習データを選び、プロンプトを調整する。一つひとつは正当な改善ですが、同じテストセットを何百回も参照した時点で、それは実質的に訓練データの一部です。過学習と評価設計で扱ったvalidationへの過学習と同じ構造が、業界サイズで起きています。

汚染 — 問題が学習データに混ざる

事前学習データはウェブの大規模クロールで、公開ベンチマークはGitHubにも解説ブログにもデータセット共有サイトにも載っています。有名になるほどコピーが増え、次世代モデルの学習データに入る確率が上がる。汚染は誰かの不注意ではなく、公開ベンチマークという仕組みの構造的な帰結です。症状は暗記の症状で、問題文をわずかに書き換えると解けなくなる、選択肢の順番を入れ替えると点が落ちる、答えは合っているのに途中式が破綻している。

これを正面から測ったのがGSM1kです（Zhang et al., 2024）。算数ベンチマークGSM8Kと同じ難易度分布・同じ形式で新規に1,250問を作り、両方で採点しました。結果は一様ではなく、ほとんど落ちない系統がある一方、二桁ポイント落ちる系統もありました。同じ「GSM8K 何点」が、モデルによって中身の違うものを指していたわけです。

検出の手当ては三つ。n-gram重なりは、学習コーパスと評価データで一定長（13語、50文字などの閾値）の連続部分列が一致する問題を除外する方法で、露骨なコピーには効き、言い換えには効きません。カナリア文字列は、ベンチマークのファイルにウェブ上へ他に存在しない一意の文字列（GUID）を埋め込む方法で、モデルがその続きを再現できたら学習していた証拠になります（BIG-benchが採用）。時間で切るのは、カットオフより後に作られた問題だけで採点する方法で、定期的に新問へ入れ替える運用（LiveBench、LiveCodeBenchなど）がこれです。筋はいちばん良い一方、モデルごとにカットオフが違うので土俵を揃えにくい。

「汚染していない」の証明はできません。学習データが非公開なら検出は原理的に不可能で、言い換えられたコピーも文字列一致では捕まらないからです。できるのは、汚染していたら落ちるはずの新問で測り直して「落ちなかった」証拠を積むことだけです。

自動採点の罠 — 正解しているのに不正解になる

採点は最終的にプログラムが行い、この採点コードが思っているよりずっと大きくスコアを動かします。典型例が答えの抽出処理です。

import re

def extract_choice(text):
    m = re.search(r"\b([A-D])\b", text)   # 最初に現れた A〜D を答えとみなす
    return m.group(1) if m else None

extract_choice("A は電圧と電流を混同しているので、正解は C です。")  # -> 'A'

モデルは正しくCと答えているのに、採点器はAを拾って不正解にします。逆に「答えだけを出力せよ」と強く指示すれば抽出は安定しますが、今度は指示に従う能力が科目知識のスコアに混ざる。どちらに転んでも、測っているものがずれます。

コード生成では pass@k が使われます。 $k$ 個生成して1つでも通れば正解という考え方ですが、 $k$ 個だけ作って数えると値がばらつくため、 $n$ 個（ $n>k$ ）生成して不偏推定します。

\mathrm{pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}

(2)

$n$ は1問あたりの生成数、 $c$ はそのうちテストに通った数、 $\binom{a}{b}$ は「 $a$ 個から $b$ 個を選ぶ組み合わせの数」です。分数は「 $k$ 個引いて全部ハズレを引く確率」なので、1から引けば「少なくとも1つ当たる確率」になります。

pass@1 と pass@10 は別の能力です。pass@10 が高いのは「当たりを含む候補群を出せる」モデルであって、テストを実行して選び直す仕組みが製品側にないなら、その高さは体感に結びつきません。

LLMに採点させるときの三つの偏り

自由記述は文字列照合できないので、強いモデルに採点させる「LLM-as-a-judge」が使われます。MT-Bench / Chatbot Arenaの論文（Zheng et al., 2023）は、この方式が人間の評価とよく一致する一方で、はっきりした偏りを持つことを示しました。

位置バイアス: 二つの回答をA・Bとして見せると、提示順そのものが勝敗を動かす
冗長性バイアス: 長い回答が好まれる。情報が増えていなくても、書き足すだけで勝率が上がる
自己優遇バイアス: 採点役が、自分（または同系統）の出力を高く評価する

位置バイアスへの対策は素朴ですが効きます。

def judge_pair(a, b):
    v1 = ask_judge(a, b)          # A→B の順で採点
    v2 = ask_judge(b, a)          # 順番を入れ替えてもう一度
    if v1 == v2:
        return v1                 # 一致したときだけ勝敗として採用
    return "tie"                  # 割れたら引き分け＝位置バイアスの疑い

呼び出し回数は倍になりますが、順序の影響はこれでほぼ落ちます。冗長性には、採点基準に「長さでは評価しない」と明記したうえで回答長を別に記録し、後から相関を見る。自己優遇には採点役と被採点モデルの系統を分けるのが確実です。自社モデルの改善を自社の最上位モデルに採点させる構成は、社内では通っても外には出せません。

Chatbot Arena — 人間の投票を1つの数字にする

Chatbot Arena（現LMArena）では、質問を投げると匿名の2モデルが並んで回答し、ユーザーがどちらが良いかを投票します。名前が伏せられるのでブランドの影響が乗りにくく、質問は実際のユーザーが持ち込むので出題が固定されず、問題文が事前に存在しないぶん汚染も起きにくい。

投票結果は対戦記録の山です。これを1つのレーティングに変えるのがBradley-Terryモデルで、各モデルに強さ $\xi_i$ を割り当てて勝率を書きます。

P(i \text{ が } j \text{ に勝つ}) = \frac{e^{\xi_i}}{e^{\xi_i} + e^{\xi_j}} = \sigma(\xi_i - \xi_j)

(3)

$\xi_i$ はモデル $i$ の強さ、 $\sigma$ はシグモイド関数です。式が言っているのは「勝率を決めるのは強さの絶対値ではなく差だけ」ということ。観測された勝敗がいちばん起こりやすくなるよう、全モデルの $\xi$ を同時に推定します（最尤推定）。チェスのEloと同じ形で、Eloの「400点差なら強い側の勝率は約91%」はこの式の目盛りを決め直したものです。

FIG 2上の勝率の式は「2要素のsoftmax」そのもの。温度に当たる目盛り（Eloの400点）を変えると、同じ強さの差でも勝率の出方が変わる。分布が尖る／平らになる感覚が、そのままレート差の効き方に対応する

弱点も見えます。まず好みは正しさではありません。投票者が選ぶのは「良いと感じた回答」で、整った箇条書きや適度な長さといったスタイルが票を集めやすいことが分かっており、運営側もスタイルの影響を切り分ける補正（style control）付きのランキングを併記しています。補正なしの順位表を能力の順位として読むのは危険です。次に出題の分布は投票者の分布で、Arenaを訪れる人が持ち込む質問は、あなたの業務ドメイン（医療記録、契約書、社内コード）とは違います。そして上位陣のレート差は数十点しかないことが多く、対戦数が足りなければ信頼区間は重なります。1位と3位が統計的に区別できないことは珍しくありません。

現場ではこう使う

評価を回すのは、MLエンジニア、モデル評価担当、そして「どのモデルを製品に載せるか」を決める技術選定者です。触るのはまず既製のハーネスで、EleutherAIの lm-evaluation-harness なら --tasks mmlu --num_fewshot 5 のように条件を明示して流せます。出力の acc と acc_norm（選択肢の長さで正規化した精度）は別物なので混ぜて比較しない。Stanford の HELM は精度以外（頑健性・バイアス・効率）も並べる設計で、「1指標で並べない」思想の実装例です。プロンプト単位の回帰テストだけなら promptfoo のような軽いツールで足ります。

社内の評価セットを作る手順は決まっています。本番のログから問題を作る（公開ベンチマークは一次スクリーニングまで）。調整のたびに見るdevと、最終判断だけに使うtestを分ける（testを何度も見た瞬間、それはdevになります）。温度0・seed固定で最低2回流す。差は $\sqrt{p(1-p)/n}$ を計算して「82% ± 3pt」と幅つきで報告する。

事故になる落とし穴は三つです。

公開ベンチマークを学習データに混ぜる。配布されている指示データセットには評価予定のベンチマークが紛れていることがあり、n-gram重なりのフィルタをかけてから使う
「%」と「ポイント」の混同。80%→84%は「4ポイント改善」であって「4%改善」ではありません（後者なら83.2%）
評価のときだけ特別なプロンプトを使う。few-shot例やシステムプロンプトを評価用にだけ作り込むと本番と乖離します。言い回しがどれだけ結果を動かすかはプロンプトエンジニアリングの科学で扱っています

設計レビューで問われるのは三つ。「汚染をどう確認したか」「その差は有意か」「指標はユースケースと一致しているか」。どれも「高いスコア」ではなく「その数字の作り方」を聞いています。なお、Arenaと同じ「対戦記録から強さを推定する」構造はInstruction TuningとRLHFの報酬モデルとほぼ同型で、評価と学習は同じ数式の表と裏にあります。

まとめ

スコアは、測り方（採点方式・few-shot数）と問題数から来る誤差の幅を添えて初めて意味を持つ
汚染は公開ベンチマークの構造的な帰結。「していない」の証明はできず、新問で落ちなかった証拠を積むしかない
LLM-as-a-judgeには位置・冗長性・自己優遇の偏りがある。順序反転の二重採点で位置バイアスはほぼ落ちる
Chatbot Arenaは汚染に強い代わりに「好み」を測っている。スタイル補正なしの順位を能力順と読まない
最終判断は公開ベンチマークではなく、自分のドメインの評価セットで行う