LLM評価 — 点数を出すことではなく、ものさしを設計し監査すること¶
一言で: LLM 評価の本題は「何点取れたか」ではなく、ものさしの側にある — どの難易度帯・どのドメインで差が出るように作るか（レンジ設計）、そしてそのものさし自体が壊れていないか（監査）。合格点は試験が教えてくれる最もつまらない情報。
論点マップ¶
| 問い | 対立軸 | 現在地（私の理解） |
|---|---|---|
| 何を測るか | 単一スコア vs 能力の地形図 | 単一スコアは「どこで崖落ちするか」を全部隠す。難易度を振って性能曲線を描くのが本筋 |
| 難易度をどう扱うか | 主観ラベル vs 測定量 | サプライザル（bit）や IRT で測る。ただし難易度を推定するモデル自体も監査対象 |
| ドメイン特化ベンチの設計 | 1本のものさし vs レンジの違う束 | タスクごとに「識別できるモデル帯」が違う。ランダム床＋飽和曲線でレンジを確認して束にする |
| ベンチを信頼してよいか | 暗黙に信頼 vs 監査 | MMLU で 6.49% の誤り、KramaBench の ground truth 欠陥。評価データも成果物であり欠陥を持つ |
知見の整理¶
1. 合格点ではなく「能力の地形図」を描く¶
Google の Discovery Bench は、クエリの曖昧さをサプライザル（情報理論の測定量）で定量化し、同じ設問を難易度別にスイープして性能曲線を描く。同一エージェント・同一クエリでも言い回しだけで F1 が 1.00 → 0.00 まで崖落ちする — 静的ベンチの平均点には一切現れない。しかも「易しくすれば上がる」わけではなく、Medium が Low を上回る非単調性（スイートスポット）がある。 → 詳細: agent評価 — サプライザルと evaluate your evals
2. ドメイン特化ベンチは「レンジの違うものさしの束」として設計する¶
日本語×金融の SIG-FIN-032 ベンチ（現 japanese-lm-fin-harness）は良い実例。感情分析＋資格試験系4タスク（証券アナリスト・会計士監査・FP2級・証券外務員）で約90モデルを計測し、平均と各タスクの関係を 1−exp(x) 系の飽和曲線でフィットした。分かったのは:
- chabsa（感情分析）は中堅モデルの識別に効くが、GPT-4 級では飽和（現実的上限 ~95 にほぼ到達）
- cpa_audit（会計士監査）は GPT-4 単体でも 37 点で、上位モデルの識別にしか使えない（合格レベルには RAG が必要）
- 各タスクにランダム正解率の床を明記しておくと「何もできない」との距離が常に見える
つまり1つのベンチ内でも、タスクごとに「差が出るモデル帯」= 測定レンジが異なる。設計時はレンジを意識して束にする、利用時は自分の対象帯で識別力のあるタスクを見る。
3. ものさし自体を監査する（evaluate your evals）¶
- ground truth を直接読む: KramaBench では「正解テーブルがクエリに答えていない」等の実欠陥が発見された。MMLU-Redux では専門家再アノテートで 6.49% が誤り（Virology は 57%）
- 難易度推定に使う LLM も監査対象: 曖昧化を LLM 自由生成にすると F1 ≈ 0.34、TF-IDF に足場を置くと ≈ 0.85 — ものさしを最適化してしまうリスクがある
- 一次資料自体の不整合にも注意: SIG-FIN-032 論文は本文「平均60超は GPT-4 のみ」と表1（Qwen-72B 62.18）が食い違う。表だけ・本文だけを引用すると誤る
4. 実務への持ち帰り¶
- モデル選定の根拠として: 日本語金融の知識タスクでは 35〜45 点帯のモデルが団子（パラメータ数の影響が軽微 = コーパス不足が疑われる）。ドメイン知識を任せるなら最上位モデル帯が必要、という定量的裏付けに使える
- 自分で評価ハーネスを作るときの型: ①ランダム床を置く ②難易度/識別レンジを測定量として扱う ③評価器・評価データを成果物として監査する ④最良プロンプトで測る割り切り（in-sample に見えても公平性のため）
主要ソース¶
- agent評価 — サプライザルで難易度を測り、評価器そのものを評価する（Google Cloud Blog, 2026）
- 平野正徳「言語モデル性能評価のための日本語金融ベンチマーク構築と各モデルのパフォーマンス動向」SIG-FIN-032-06, 2023 — https://www.jstage.jst.go.jp/article/jsaisigtwo/2023/FIN-032/2023_28/_pdf/-char/ja （コード: https://github.com/pfnet-research/japanese-lm-fin-harness ）
- MMLU-Redux — https://arxiv.org/abs/2406.04127 / tinyBenchmarks — https://arxiv.org/abs/2402.14992 / metabench — https://arxiv.org/abs/2407.12844
作成: 2026-07-11 ／ 最終更新: 2026-07-11