ローカルLLMのベンチマークが全モデル満点を出した。それがこのプロジェクトで最も有用な失敗だった
絞り込んだ実務的な問いから始めました。日本企業がオンプレで実際に動かすべきローカルLLMはどれか。 候補4つ、参赛しない独立ジャッジ、3つの軸 — 品質・レイテンシ・VRAM。
最初の実行は、全モデルがほぼ満点で返ってきました。Faithfulnessは全モデル1.0000。Hit rateは0.90〜1.00。ジャッジ一致率 κ = 1.0。
きれいな結果に見えました。実際には壊れたベンチマークでした — そしてその理由を突き止めたことが、どんなリーダーボードの数字よりも多くを教えてくれました。
良すぎて信じられない数字
これがv1、20問、4モデルです。
| モデル | パラメータ | Faithfulness | Hit rate |
|---|---|---|---|
| elyza-jp-8b | 8.0B | 1.0000 | 0.90 |
| gemma4-31b | 31.3B | 1.0000 | 0.95 |
| nemotron-nano-9b-jp | 8.9B | 0.9792 | 1.00 |
| swallow-8b | 8.0B | 1.0000 | 1.00 |
8Bモデルと31Bモデルが同じスコアを出したら、警報が鳴るべきです。これだけ容量の違うモデルが同じスコアに収束するのは、ほぼ常にテストが差を解像できていないことを意味します — 差が消えたのではなく。
区分度の内訳が決定的でした。90%の問題は全モデルが正解、10%は一部、0%はどのモデルも不正解できなかった。 10問中9問が候補を区別できないベンチマークは、候補を測っていません。問題が易しいかどうかを測っているだけです。実際、易しかった。
そして安心させてくれそうに見えた κ = 1.0 のジャッジ一致率は？ 2人のジャッジがほぼ全てに満点を付けるとき、完全一致は自明な解であって、強い信号ではありません。分散がゼロだと統計量自体が無意味になります。ここでの κ = 1.0 は「ジャッジが一致した」ではなく「一致するも何も、意見の分かれようがなかった」だったのです。
全員に満点を付けるベンチマークは、情報的にはベンチマークがないのと等価です。どのモデルを選ぶべきかの信号を含んでいないので、選定の判断ができません。
なぜこれが恥ずかしい部分ではなく面白い部分なのか
誘惑は、問題を静かに直してきれいなv2の表だけを公開することです。私は逆をやっています — v1をリポジトリに残し、失敗を記録したADRを付けて。失敗こそが方法論のコンテンツだからです。
4モデルを問題セットに通して表を出すのは誰でもできます。本当に難しく、本当に稀なのは、数字が素晴らしく見えるときに自分の測定が壊れていると気づくことです。公開されている「ローカルLLM比較」のほとんどは区分度を一度もチェックしていません。高スコアの表を見せて、それをベンチマークと呼んでいる。その表の全モデルが90%以上なら、見ているのはモデルの品質ではなく問題の易しさです。
なので本当の成果物は「モデルXが勝った」ではありません。プロトコルです。モデル選定ベンチマークは、比較するモデルを解像できる場合にのみ有効であり — そのことを、どのスコアを信じる前にも明示的にテストしなければならない。
区分度を作り直す
v2では問題セットを、候補を分離できるよう意図的に難しく設計した45問に置き換えました。
- 単一事実の検索ではなく多段推論
- 日本語のニュアンス — 敬語、専門用語、意図的に曖昧な表現
- 境界的な事実 — 幻覚を起こしやすい具体的な日付や数値
狙いは「難しさのための難しさ」ではありません。特定の分布です。最強のモデルでもいくつかは外すべき。v1は形が間違っていました（90/10/0）。v2は**全正解29%、一部正解51%、全不正解20%**に着地しました。誰も解けない20%が、上位帯で解像度を与える部分です。
これがv2です。
Hit rateのばらつきは0.10（v1）から0.22（v2）へ。モデルが実際に分離するようになりました。そして重要なジャッジ一致率は、κ が 1.0 から 0.920 に下がった。
この低下は改善です。v1の κ = 1.0 は分散ゼロのアーティファクトでした。v2の κ = 0.920 は実際の不一致の上で計算された本物の一致数値 — ジャッジ信頼性の統計量が初めて意味を持つバージョンです。完全なジャッジ一致を報告しているベンチマークを見たら、ジャッジが一致するための分散がそもそもあったのかを問うべきです。
注目に値する発見（注意書き付き）
二度見した点。nemotron-nano-9b-jp（8.9B）がhit rateで gemma4-31b（31.3B）と並んだ — それぞれ0.622 — しかもVRAMは約半分（約11GB対約20GB）、速度は約2.6倍（warm時 190対71 tokens/s）。
これが保たれるなら、生の能力ではなく制約で選定する意義そのものです。最大のモデルが自動的に正しいデプロイ選択ではありません。VRAM上限、レイテンシ目標、スループット要件の下では、31Bにタスクで並ぶ9Bの日本主権モデルの方が良い判断です — そして「どのモデルが最強か」という枠組みからは決して見えません。
正直な注意書き、先に出します。 これは45問です。nemotron対gemma4のタイはこのセット上の観察であり、確定した結果ではありません。より大きなサンプルでの確認が必要で、行動すべき結論ではなく追うべき手がかりとして報告しています。プロトコルの要点はまさに、サンプルが支持できない結果を主張させないことにあります。
ジャッジ構成（懐疑的な読者へ）
注意深い読者が最初に聞くのは「誰が採点し、何かが自分自身を採点したか」なので。
- 主ジャッジ: qwen3:32b — そして参赛者ではない。 中国モデルであり、私自身のデプロイ/コンテンツ分離ルールにより日本オンプレのデフォルト構成には入らないので、レースを降りて代わりに採点します。これで自己選好バイアスを回避します。どの参赛者も自分や同族の答案を採点しません。
- 交叉検証: gemma4:31b が20問のサブセットを再採点 し、主ジャッジの信頼性を確認（上記の κ = 0.920）。gemma4は参赛者なので、ジャッジプロトコルの検証にのみ使い、自分自身の採点には決して使いません。
32GBに2モデルは同時常駐できない（qwen3:32b 約29GB、gemma4:31b 約19GB）ので、全体は2パス構成です。全回答を生成し、退避し、ジャッジをロードし、全回答を採点。モデルごとにキャッシュされ、再開可能です。
モデル選定のためにベンチマークする人へ渡したいこと
- どのスコアを信じる前にも区分度をチェックする。 ほとんどの問題が全候補に正解されるなら、測っているのは問題の難易度であってモデルの品質ではない。
- 満点は緑信号ではなく赤信号。 特にサイズの大きく違うモデルが並んだとき。
- 低分散セットでの完全なジャッジ一致（κ=1.0）は無意味。 実際の不一致の上でのやや低い κ の方が価値がある。
- 生の能力ではなく制約で選ぶ。 「最強」と「このデプロイに正しい」は別の問い。
- 失敗版を残す。 壊れたベンチマークから機能するものへの道のりこそ、誰も偽装できない部分。
完全なプロトコル、v1の失敗、v2の修正、全ての生採点出力:
https://github.com/elvisyao007/eval-driven-llm/tree/main/reports/model-selection-v1
姉妹ツール — そもそもリトリーバル指標が信頼できるかを監査する依存ゼロのライブラリ — は eval-sanity にあります。
Discussion