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.

採点係を機械にするということ

作文コンクールを想像してください。応募が100本なら、審査員が全部読んで順位を付けられます。では10万本ならどうでしょう。しかも毎週、プロンプトを少し変えるたびに全部読み直したい——これが、いま言語モデルを開発している人が置かれている状況です。

出力が「正解と一致するかどうか」で測れるなら話は簡単です。数学の答えが 42 かどうかは文字列比較で済みます。ところが実際に測りたいのは「この要約は原文に忠実か」「この返答は失礼でないか」「この説明は分かりやすいか」といった、正解が一つに定まらない性質です。これを人手で測ると、1回の評価に数十万円と数日がかかります。

そこで出てきたのが LLM-as-a-Judge、つまり「別の言語モデルに採点させる」という発想です。採点基準を書いた指示文と、採点対象の出力を渡し、点数か勝敗を返させる。ただそれだけの仕組みですが、評価のコストが桁で下がるので、いまや新モデルの開発サイクルの内側に組み込まれています。

同時に、これは測定器としてはかなり癖のある道具でもあります。この記事では、仕組みと、癖の正体と、癖を承知で使うための手順を順に見ていきます。ベンチマーク全体の読み方はLLM評価を1から — ベンチマークの読み方と汚染問題で扱っているので、ここでは採点器そのものに絞ります。

判定のさせ方は3種類しかない

実装の細部は無数にありますが、聞き方の型は3つに整理できます。

1. 単一採点（pointwise） — 出力を1つ見せて「1〜5点で採点せよ」と言う。安く、たくさん回せます。弱点は基準がぶれることです。同じ答案でも、その日の指示文の言い回しやサンプルの並びで点が動きます。絶対値は信用せず、同じ設定内での相対比較にだけ使うのが安全です。

2. ペア比較（pairwise） — 出力AとBを並べて「どちらが良いか」と聞く。人間も絶対評価より相対評価のほうが安定するのと同じで、一致率は上がります。代わりに後述する位置バイアスが乗り、比較回数も膨らみます。

3. 参照付き採点（reference-based） — 模範解答を一緒に渡して照合させる。採点が一番安定しますが、模範解答を用意できる課題にしか使えません。

どれを選ぶかは「何を意思決定したいか」で決まります。モデルAとBのどちらをデプロイするかならペア比較、回帰テストとして毎日の点数を追いたいなら参照付き採点が向きます。

仕組み: 判定は「分類」であり、答えは分布である

判定モデルが 4 と出力するとき、内部で起きているのは「1」「2」「3」「4」「5」というトークンのどれを出すかの確率計算です。私たちが受け取る 4 は、その分布から最も確率の高い1点を抜き出したものにすぎません。

s = \sum_{i=1}^{K} i \cdot p(i)

(1)

$K$ は点数の段階数（5段階なら5）、 $p(i)$ はモデルが「 $i$ 点」と答える確率、 $s$ が最終的なスコアです。この式(1)が言っているのは要するに、各点数を「その点数が出る確率」の重みで平均する、ということです。判定器が4点に0.6、3点に0.3、5点に0.1の確率を置いているなら、 $3 \times 0.3 + 4 \times 0.6 + 5 \times 0.1 = 3.6$ 点。つまり「4点だが、やや3点寄り」という迷いまで数字に残すわけです。

なぜわざわざこうするのか。整数だけを受け取ると、判定器は「3」か「4」ばかり返して分布が潰れ、100件の出力に同じ点が並んでしまいます。確率で重み付ければ 3.7 と 3.2 の差が残り、細かい優劣が見えるようになります。この手法は G-Eval で提案され、人手評価との相関を上げる工夫として広く使われています。

分布として見る、という感覚をつかむには実際に動かすのが早いです。下の図で温度を上げ下げしてみてください。判定器の確信が強いとき（尖った分布）と迷っているとき（平らな分布）で、同じ「最頻値4点」でも意味がまったく違うことが分かります。

FIG 1判定器が出す点数の分布。尖っていれば「4点で間違いない」、平らなら「3〜5のどこか」でしかない。整数を1つ受け取るだけでは、この違いが消えてしまう

平らな分布に対して整数を1つだけ受け取るのは、迷っている審査員に「で、結局何点？」と詰め寄っているのと同じです。返ってきた数字は答えというより、その場しのぎの丸め込みに近い。

三大バイアス

判定器が人間とずれる原因は、大きく3つが繰り返し観測されています。MT-Bench の論文はこれらに名前を付け、実測した最初期の仕事です。

位置バイアス（position bias） — AとBを並べて見せたとき、先に置かれたほうを選びやすい。中身を入れ替えただけで勝者が変わることがあります。これは判定器の性能が低いという話ではなく、順序という無関係な情報が判定に混ざっているという話です。対策は単純で、AB順とBA順の両方を走らせる。両方で同じ側が勝てば採用、割れたら「引き分け」として扱います。これで比較コストは2倍になりますが、位置の影響はほぼ抜けます。

冗長性バイアス（verbosity bias） — 長い回答を高く評価しやすい。箇条書きを足し、前置きを足し、まとめを足すだけでスコアが上がってしまう。これが厄介なのは、判定器を報酬信号として学習を回すと、モデルが「無駄に長く書く」方向に最適化されていくからです。AlpacaEval では、長さの影響を回帰で差し引いた長さ補正済みの勝率を出す方法が提案されました。手元で回すだけなら、まず出力文字数と判定スコアの相関を取るのが最初の検査になります。相関が強ければ、測っているのは品質ではなく長さです。

自己選好（self-enhancement bias） — 判定器が、自分自身（や同系統のモデル）の出力を高く評価しやすい。GPT系の判定器でGPT系のモデルを評価すると、身内びいきが入る可能性があります。だから「自社モデルの改善を、自社モデルで採点して報告する」構図は、それ自体が利益相反です。回避策は、判定器を評価対象と別系統にする、あるいは複数の判定器で多数決を取ることです。

3つに共通するのは、判定器が「品質」ではなく「品質と相関する何か」を見てしまっているという構造です。順序、長さ、文体の親近性——どれも人間の評価者にもある癖ですが、機械は同じ癖を何万件にも一貫して適用するので、集計値に確実に残ります。

比較の数は2乗で増える

ペア比較には、バイアスとは別に量の問題があります。 $n$ 個のモデルを総当たりで比べると、必要な比較は $n(n-1)/2$ 組。さらに各組で複数の質問を投げ、位置入れ替えで2倍にするので、実際の呼び出し回数は次のようになります。

C = \frac{n(n-1)}{2} \times m \times 2

(2)

$n$ はモデル数、 $m$ は1組あたりの質問数、最後の2は位置入れ替えの分です。この式(2)が言っているのは要するに、「組の数 × 1組あたりの質問数 × 順序2通り」を掛け合わせただけで、 $C$ が実際に判定器を呼ぶ回数です。10モデルを質問80問で総当たりすれば、 $45 \times 80 \times 2 = 7200$ 回。モデルが5個なら10組ですが、20個になると190組。モデルを4倍にすると比較は約19倍になります。

FIG 2n が増えたときの伸び方の違い。総当たり比較は n² の曲線に乗るので、モデルが増えるほど「全部比べる」は現実的でなくなる

だから実運用では総当たりを諦めます。基準となるモデルを1つ固定して全員をそれと比べる（比較は $n$ 回で済む）か、対戦をランダムに間引いてレーティングで順位を推定するかです。「全部と比べていない」ことを忘れなければ、どちらも十分使えます。

審査員を審査する

ここが最も飛ばされやすく、最も重要な工程です。判定器を導入したら、その判定器が人間とどれくらい一致するかを、必ず自分のタスクで測る。他人のベンチマークでの一致率は、あなたのデータに対する保証ではありません。

手順はこうです。自分のタスクから100〜300件を抜き、人手でラベルを付ける。同じ件を判定器に判定させ、突き合わせる。見るべき指標は3つです。

一致率 — 単純に何%合ったか。ただしこれは水増しされます。2択で当てずっぽうでも50%は合うからです。そこで偶然の一致を引いた指標を使います。

\kappa = \frac{p_o - p_e}{1 - p_e}

(3)

$p_o$ は実際に一致した割合、 $p_e$ は偶然だけで一致すると期待される割合、 $\kappa$ （カッパ）がその補正後の値です。この式(3)が言っているのは要するに、素の一致率からまぐれで当たる分を差し引き、まぐれを超えて伸ばせる余地で割った、ということです。2択で $p_e = 0.5$ のとき、一致率75%なら $\kappa = (0.75 - 0.5) / 0.5 = 0.5$ 。「4分の3も合っている」ように見えた数字が、偶然を除けば半分の実力しかないと分かります。0なら偶然と同じ、1なら完全一致。

人間同士の一致率との比較 — これが判定器の合格ラインです。人間の評価者2人でも意見は割れます。MT-Bench の論文では、強い判定器と人間の一致率が、人間同士の一致率と同程度の水準に達したことが示されました。裏を返せば、人間同士が6割しか一致しない主観的な課題で、判定器に9割を求めるのは筋が悪いということです。上限は人間の側にあります。

位置入れ替え一貫性 — 同じペアをAB順とBA順で判定させ、結論が変わらない割合。これは人手ラベルなしで測れるので、いちばん安く回せる健全性チェックです。この値が低い判定器は、何を測っているにせよ安定していません。

判定器そのものを測るための公開データセット（RewardBench、JudgeBench など、正解が既知の比較ペアを集めたもの）もあり、判定器候補の一次選抜には使えます。ただし最終判断は自分のデータで、が原則です。

コードで書く最小の判定器

位置入れ替えまで含めた、実用最小形はこれくらいの分量です。

def judge_pair(model, question, a, b):
    """AB順とBA順の両方で聞き、割れたら引き分けにする"""
    v1 = ask(model, question, first=a, second=b)   # -> "first" | "second"
    v2 = ask(model, question, first=b, second=a)

    if v1 == "first" and v2 == "second":
        return "A"          # 順序を変えてもAが勝った
    if v1 == "second" and v2 == "first":
        return "B"
    return "tie"            # 位置で結論が変わった = 判定不能

引き分けを捨てずに数えるのが要点です。tie の比率がそのまま位置バイアスの強さの実測値になり、判定器や指示文を変えたときの改善が追えます。

現場ではこう使う

誰がいつ触るか。 LLMアプリの開発者・MLエンジニアが、プロンプトやモデルを差し替える前後で回帰を検出する場面が中心です。次にデータ／評価担当が、人手ラベルとの一致を定期的に測り直す運用。さらにRLHFやオンポリシー蒸留のように、判定器を報酬信号として学習に組み込む使い方があります（最後の用途は要求水準が一段上がります。測定器のズレが、そのままモデルの癖として焼き付くからです）。

触るパラメータ。 判定器側は temperature（判定では0付近に固定し、実行ごとに結論が動くのを防ぐ）、確率重み付けを使うなら logprobs／top_logprobs、そして評価軸ごとに分けた採点基準（rubric）です。「総合的に良いか」ではなく「事実正確性」「指示追従」「安全性」を別々に採点させると、判定の再現性が上がり、落ちた原因も追えます。ライブラリでは OpenAI Evals、LangSmith、Ragas、DeepEval あたりが定番で、位置入れ替えや rubric 分割は多くが機能として持っています。

事故になる落とし穴。

判定器のバージョンを固定しない。 APIのモデルが静かに更新されると、モデル側が何も変わっていないのに「品質が改善した」グラフが出ます。判定器のモデル名・版・指示文はコードと一緒にバージョン管理し、変えたら過去分を測り直す。
判定器と評価対象が同系統。 自己選好が入ります。少なくとも自社モデルの優位を対外的に主張する場面では避けます。
長さを見ていないこと。 出力文字数とスコアの相関は必ず出す。判定器を報酬に使う場合、これを怠ると出力が数百字ずつ肥大していきます。
点数の絶対値を信じる。 「平均4.2点」に意味はありません。同じ判定器・同じ指示文・同じ質問セットでの差分だけが読めます。
有意差を見ない。 200件で勝率52%と48%は、ほぼ確実に区別がついていません。判定回数からくる誤差の見積もりはA/Bテストの統計と同じ考え方です。
人手との一致を一度しか測らない。 タスクの分布は変わります。四半期ごとに数百件で測り直すのを運用に組み込む。

問われる問い。 「その判定器が正しいと、どうやって確認しましたか」——一致率とκ、人間同士の一致率、位置入れ替え一貫性の3点で答えられれば十分です。エージェントのように途中の手順まで採点したい場合は、最終成果だけを見るのか経過も見るのかで設計が変わります。そちらはエージェント評価 — ベンチとハーネスの作法で扱っています。

まとめ

LLM-as-a-Judge は、正解が一つに定まらない品質を安く大量に測るための道具。単一採点・ペア比較・参照付き採点の3型がある
判定の中身は点数トークンの確率分布。整数1つに丸めると、判定器が迷っているという情報が失われる
位置・冗長性・自己選好の3バイアスは、判定器が品質そのものではなく「品質と相関する何か」を見てしまう構造から出る。位置は入れ替えで、長さは相関の監視と補正で、自己選好は判定器の系統を分けることで減らせる
導入したら必ず自分のタスクで人手と突き合わせる。合格ラインは100%ではなく、人間同士の一致率

LLM-as-a-Judge を1から — AIがAIを採点する仕組みと限界

要点