評価とベンチマーク

なぜLLMの評価は難しいのか

• 正解が1つとは限らない: 要約や文章作成は、良い答えが何通りもあります。
• 答えが揺れる: サンプリング（第2章）があるので、同じ問題でも正解したりしなかったりします。何回か解かせた平均を見る必要があります。
• 聞き方で変わる: プロンプトの書き方、例題の有無、推論モデルなら思考の量（第27章）で点数が動きます。MMLU-Pro の論文は、24種類のプロンプトで成績の揺れを調べています。
• 「良い」の中身が人による: 正確さ、読みやすさ、安全性、速さ、安さ。どれを重視するかは用途次第です。

いちばん素朴な指標：パープレキシティ

パープレキシティ（perplexity）は、モデルが文章の次のトークンをどれだけ迷わずに予測できたかを表す数値で、低いほど良いとされます。「次の単語の候補を平均で何個くらいに絞り込めているか」というイメージです。

便利なのは、同じモデルの量子化前後（第10章）を比べるような場面です。llama.cpp にも計測ツールがあり、量子化による品質低下の確認に使われています。一方で、llama.cpp のドキュメント自身が、トークナイザが違うモデル同士では直接比べられないこと、指示に従うよう微調整すると人間の評価は上がってもパープレキシティは悪化しがちなことを注意しています。「役に立つかどうか」は測れないのです。

ベンチマークの地図

そこで、問題と正解を用意して解かせるベンチマークが使われます。代表的なものを、何を測っているかで分けてみます。

いくつか補足します。GPQA の論文では、その分野の博士（課程を含む）の正答率が65%、ほかの分野の優秀な人がウェブ検索を使って30分以上かけても34%でした。HumanEval は手書きの164問のPythonの問題です。SWE-bench Verified は、元のSWE-benchから人手で品質を確認した500問のサブセットです。

ARC-AGI は、2019年にフランソワ・ショレが知能の測り方を論じた論文から生まれました。知識の量ではなく、初めて見る課題にどれだけ効率よく適応できるかを測ろうとしています。ARC Prize 2026 の課題になっている ARC-AGI-3 は、説明なしのゲーム環境を探索し、自分で目標を見つけて攻略する対話型のベンチマークです2026年10月時点。

Arena は、2023年に Chatbot Arena として始まり、LMArena を経て2026年1月に「Arena」へ名称を変えました。人間の投票からモデル同士の強さを推定するので、「人が好む回答」を幅広く測れます。そのかわり、好まれやすい書き方（長さや見た目）の影響も受けます。

日本語のベンチマーク

英語のベンチマークで高得点でも、日本語で同じように使えるとは限りません。日本語向けの代表的な評価は次のとおりです2026年10月時点。

JGLUE は分類・文の類似度・読解など、文の理解を測るタスクが中心です。チャットで使うLLMの実力を見るなら、対話や生成を含む Japanese MT-Bench や、複数の評価をまとめた Nejumi のほうが参考になるでしょう。ただし Nejumi も「既存ベンチマークの飽和」に対応するために版を重ねてきました。版が変われば点数の意味も変わります。

汚染と飽和：ベンチマークの寿命

flowchart TD
  A["新しいベンチマーク
公開"] --> B["各社が点数を競う"]
  B --> C["問題と答えが
ネットに広まる"]
  C --> D["学習データに混入
＝汚染"]
  B --> E["上位が満点近くに
＝飽和"]
  D --> F["点数が実力を
反映しなくなる"]
  E --> F
  F --> A

汚染（contamination）の例として、2024年の GSM1k の研究があります。小学校レベルの算数ベンチマーク GSM8k とそっくりな新しい問題を1000問作って解かせたところ、一部のモデル群で正答率が最大8%下がり、元の問題に過剰に適応している兆候が見られました。

実務向けのベンチマークでも同じことが起きます。OpenAI は2026年2月、自ら公開した SWE-bench Verified の結果報告をやめると発表しました。学習時に問題を見ていた形跡があること、正しい修正を不合格にしてしまう不備のあるテストが多いことが理由で、代わりに一部の問題を非公開にした SWE-bench Pro を勧めています。

飽和（saturation）については、Humanity's Last Exam の論文が、MMLUのような有名ベンチマークでLLMの正答率が90%を超え、最先端の差を測れなくなったことを作成の動機に挙げています。対策としては、LiveCodeBench のように新しい問題を足し続け、モデルの学習データの締め切り日より後の問題だけで測る方法や、問題の一部を非公開にする方法がとられています。

LLMに採点させる：LLM-as-a-judge

文章の良し悪しを人間が全部採点するのは大変です。そこで強いLLMを審査員にするLLM-as-a-judgeが広く使われています。2023年の Zheng らの研究では、GPT-4 を審査員にすると人間の判断と80%以上一致し、人間どうしの一致率と同程度でした。ただし同じ論文が、審査員LLMのくせも指摘しています。

人間の投票によるランキングにも落とし穴があります。2025年の論文「The Leaderboard Illusion」は、一部の企業が公開前に多数の非公開バリアントを Chatbot Arena で試し、良かった結果だけを公表できたことで順位がゆがんだと指摘しました。Llama 4 の公開前には Meta が27もの非公開バリアントを試していたと報告しています。

リーダーボードの読み方

点数を見るときは、次のチェックリストを思い出してください。

• いつの、どの版か: 日付とベンチマークの版（例: SWE-bench の Verified か Pro か）を確認する。
• 条件はそろっているか: 試行回数（1回目で正解か、k回中1回でも正解か）、思考の量、ツールや検索の使用可否、エージェントの枠組みが同じか。
• 誰が測ったか: 開発元の自己申告か、第三者の再現か。
• 差は誤差を超えているか: 数百問程度のベンチマークでは、1〜2ポイントの差は揺れの範囲かもしれない。
• 費用と速さは: 同じ点数でも、1問あたりのトークン数や時間が10倍違えば実用上は別物。

自分のアプリを評価する

実際の問い合わせ、社内文書、過去の不具合など、自分の用途を代表する入力と、それに対する理想の答え（または合否の基準）を集めたものをゴールデンセットと呼びます。最初は30〜100件程度でも、何も測らないよりずっと役に立ちます。

flowchart TD
  A["実際の入力を集める"] --> B["正解や採点基準を
つけてゴールデンセットに"]
  B --> C["モデル・プロンプト・
設定ごとに実行"]
  C --> D["採点
完全一致・テスト・
LLM審査員・人手"]
  D --> E["精度・費用・
待ち時間を比較"]
  E --> F["本番で見つかった
失敗例を追加"]
  F --> C

採点方法は、できるだけ機械的なものから選びます。分類や抽出なら完全一致、コードならテストの実行、RAG（第19章）なら「根拠の文書を正しく引けたか」が使えます。自由な文章だけはLLM審査員に頼り、その審査員の判定も一部を人間が抜き取りで確かめます。

指標は精度だけではありません。最初の1文字が出るまでの時間（TTFT: Time To First Token）、1秒あたりの生成トークン数、1件あたりの費用も一緒に記録しましょう。モデルの更新、プロンプトの修正、量子化（第10章）の変更のたびに同じセットを流せば、知らないうちに品質が落ちるデグレ（回帰）にも気づけます。エージェント（第28章）なら、最終結果だけでなく、途中の手数や失敗からの立ち直りも見どころです。