# LLM評価 ## 定義 大規模言語モデル(LLM)の性能・能力・人間との整合を定量化する手法の総称。評価軸は「質問ソース(静的/ライブ)」と「評価指標(グラウンドトゥルース/人間嗜好)」の 2 軸に大別される。静的グラウンドトゥルース型(MMLU・HumanEval 等)が最も普及しているが、人間の嗜好との整合を評価するにはペアワイズ比較・クラウドソーシング等の手法が必要となる。(Source: [[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]]) ### 評価手法の分類(Figure 1 準拠) | 質問ソース | 評価指標 | 例 | |---|---|---| | 静的 | グラウンドトゥルース | MMLU、HellaSwag、GSM-8K、HumanEval | | 静的 | 人間嗜好 | MT-Bench、AlpacaEval | | ライブ | グラウンドトゥルース | Codeforces 週次コンテスト | | ライブ | 人間嗜好 | **Chatbot Arena** | ### 静的ベンチマークの限界 1. **オープンエンド評価の困難**: 多肢選択・定型 QA は実世界の柔軟・対話的使用を捉えられない。 2. **テストセット汚染**: 静的なテストセットは時間とともに汚染されやすく信頼性が低下する。 3. **グラウンドトゥルースの不在**: 複雑なタスクでは正解が存在しないか、存在しても特定が困難。 4. **飽和（Saturation）**: 最先端モデルが 90% 超の正解率を達成すると、モデル間の能力差を識別できなくなる（例: MMLU に対する現在の最先端モデル）。(Source: [[@2025__arXiv__Humanity's Last Exam]]) ### 最前線ベンチマーク（Frontier Benchmark）の設計アプローチ 飽和問題に対応するためのベンチマーク設計方向（HLE が統合して採用）: - **マルチモーダル対応**: テキスト＋画像の問題を含める - **専門家による作問**: 教授・研究者・博士号取得者が担当 - **多段階レビュー**: LLM 難易度チェック → 専門家レビュー → 承認者最終確認 - **広い科目カバレッジ**: MMLU 同様に多科目をカバー（HLE は 100+ 科目） - **クローズドエンド設計**: 自動採点のための多肢選択・完全一致型回答 - **プライベートテストセット**: 公開セットへのオーバーフィッティング検出用に非公開セットを保持 (Source: [[@2025__arXiv__Humanity's Last Exam]]) ### 人間嗜好に基づく評価の手法 - **ペアワイズ比較**: 2 モデルの出力を並べてユーザーが好みを選ぶ(採用: Chatbot Arena)。絶対スコアより認知負荷が低く一致率が高い。 - **LLM-as-judge**: GPT-4 等の強い LLM を審判として使う自動評価(例: MT-Bench, AlpacaEval)。コスト低・再現性高だが、審判モデルのバイアスを引き継ぐ。 - **専門家評価**: 精度は高いがコストが大きく、スケールしにくい。 ### ランキング手法 - **Elo レーティング**: チェスで普及した逐次更新型ランキング。Chatbot Arena の初期版で採用されたが、統計的推定精度が BT モデルより劣るとして置き換えられた。 - **Bradley-Terry (BT) モデル**: ペアワイズ比較をロジスティックモデルで定式化し MLE で係数推定。サンドイッチ共分散行列で頑健な信頼区間を構成できる。Chatbot Arena で採用。 ## 横断的知見 - **静的クローズドエンド評価（グラウンドトゥルース型）とライブ人間嗜好評価は相補的**: Chatbot Arena（[[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]]）は「ライブ×人間嗜好」の象限を埋め、HLE（[[@2025__arXiv__Humanity's Last Exam]]）は「静的×グラウンドトゥルース」の最難関極端を埋める。いずれも単独では不十分であり、LLM 能力の多面的測定には両アプローチが必要。(Source: [[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]], [[@2025__arXiv__Humanity's Last Exam]]) - **ベンチマーク飽和は不可避であり、評価設計は常に時代と競争する**: MMLU は最先端モデルで 90% 超となり能力差を識別できなくなった。HLE も将来的には同様の飽和が予想される（論文自身が「これが最後の学術試験になるかもしれない」と述べつつ AGI の証明にはならないと釘を刺す）。ベンチマーク設計はモデル進化より速く難易度を更新し続ける必要がある。(Source: [[@2025__arXiv__Humanity's Last Exam]]) - **モデルの確信度とキャリブレーション**: HLE では全モデルが誤答時も高確信度を示し、RMS キャリブレーション誤差は 73〜89% に達した。これは Chatbot Arena が「人間がどちらを好むか」を測るのとは異なる次元の問題であり、モデルが「わからない」と言えるかどうかという能力のギャップを示している。(Source: [[@2025__arXiv__Humanity's Last Exam]]) - **クラウドソーシングの母集団バイアスは静的評価にも存在する**: Chatbot Arena はユーザーが研究者・愛好家中心であるバイアスを持つ。HLE の質問提供者も 50 か国・500+ 機関の専門家集団であり、一般ユーザーの使用パターンとは異なる「専門家フロンティア」を測っている。いずれも代表性の問題は残る。(Source: [[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]], [[@2025__arXiv__Humanity's Last Exam]]) - **ゼロエラー境界(ZEH)は評価範囲の恣意性を排除する第三のアプローチである**: HLE(静的・専門家問題)や Chatbot Arena(ライブ・人間嗜好)とは異なり、ZEH はモデル自身が境界を定める。7B と 72B の Qwen2.5 の掛け算評価で、評価範囲次第では「差がない」と言えてしまう問題を ZEH=22 対 ZEH=42 という客観値が解消する。また ZEH はオープンエンドに難度が延伸するためベンチマーク飽和も起きにくい。(Source: [[joisino-LLMの能力の穴-2026]]) - **産業実装は Promptfoo によるオフライン評価とバージョン管理されたベンチマークデータセットで評価駆動開発を回す**: Amazon の SRE エージェント(Papapanagiotou, SREcon25 EMEA)は、チケット記述と期待仮説を対にした社内ベンチマークデータセットを Promptfoo でバージョン管理しつつ、LLM-as-judge によるオフライン評価を継続的に実行するフライホイールを構築した。これは本ページが扱う学術的評価手法(Chatbot Arena・HLE 等)の「静的グラウンドトゥルース型×専門家データセット」象限を、産業運用のドメイン特化・継続更新という形で具体化した実例である。(Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]) - **ドメイン特化のツール利用エージェント評価は、精度単軸ではなく精度×レイテンシ×トークン消費量(verbosity)の 3 軸が最低限必要である**: Chatbot Arena・HLE が汎用能力を「1 つの物差し」(人間嗜好スコア/正答率)で測るのに対し、[[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] は AIOps ツール利用エージェントの評価で、精度が高くても低レイテンシ・低トークンが「早期終了」や「不完全なツール連鎖」の兆候であるケースを複数実証した(例: Mixtral 8x22B・GPT-3.5 Turbo は AR タスクで最速だが精度 0%)。これは Chatbot Arena/HLE の枠組みが前提とする「1 回の応答の質」評価と異なり、マルチステップ実行の**完遂度**(トークンが生成された=タスクを最後まで実行した、という代理指標)を測る必要があることを示す。(Source: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §4.2–4.3) - **モデルファミリー間の verbosity(冗長性)特性が体系的に異なることが、コスト評価の必要性を裏付ける**: 産業実装の測定では、Anthropic Claude 系が Advanced Reasoning タスクで 4〜4.7 万トークンを消費する一方、OpenAI 系は 2〜2.6 万トークンにとどまった。これは静的ベンチマーク(MMLU 等)や人間嗜好評価(Chatbot Arena)が捉えない「同じ正答に到達するコスト」という次元であり、pay-per-token モデルの実運用評価には LLM 評価の物差しとして verbosity を独立変数に含める必要がある。(Source: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §4.3) ## 未解決の問い - Chatbot Arena のユーザー分布の偏り(研究者・愛好家中心)が実世界の LLM 性能推定にどの程度バイアスを与えるか？ - LLM-as-judge と人間評価の一致率の差はモデル進化とともにどう変化するか？ - AIOps・SRE ドメイン特化の LLM 評価(障害対応能力・RCA 精度等)には、汎用の Chatbot Arena 型評価で十分か、ドメイン特化ベンチマークが必要か？ - 能動サンプリングはモデル数が増大する(100+ モデル)シナリオでどこまでスケールするか？ - HLE における専門家問題の質保証は十分か？FutureHouse の指摘（化学・生物問の約 30% 誤り）を踏まえ、ベンチマークの「正解性」をどう担保するか？ - 最前線ベンチマーク（HLE 等）での高スコアは実際のどのような能力と相関するか、またどの能力と相関しないか？ - ZEH(ゼロエラー境界)が示す「能力の穴」と、Chatbot Arena・HLE の高スコアはどう両立するか？高い汎用性能と単純タスク失敗の共存をベンチマーク設計でどう評価するか？ - 精度×レイテンシ×トークン消費量の 3 軸評価は、AIOps 以外のツール利用エージェントドメイン(コーディングエージェント、データベース O&M 等)にも一般化できるか。ドメインごとに軸の重み付けはどう変わるべきか。([[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]]) ## 横断的知見(追記) - **GPT-4 が示した「学術・専門試験」という評価軸の台頭**: GPT-4 技術報告(2023)は NLP ベンチマーク(MMLU・HumanEval 等)に加え、バー試験・LSAT・医療知識試験・AP 試験・GRE など**人間向け資格試験**をそのままモデル評価に用いた。この手法は「モデルが人間の水準に達したかどうか」を資格試験のパーセンタイルで表現できる直感的な強みを持つ一方、訓練データ汚染の管理が困難で、問題の難易度・出題形式・採点ルビックが試験設計者の意図と LLM 評価の目的の乖離を生む。HLE(Humanity's Last Exam)は「専門家でも難しい問題」で差別化を図る次世代方向であり、GPT-4 の試験評価からの連続進化と見なせる。(Source: [[@2023__arXiv__GPT-4 Technical Report]], [[@2025__arXiv__Humanity's Last Exam]]) - **GPT-4 以降 MMLU は「飽和ベンチマーク」になった**: GPT-4 が MMLU 86.4% を達成したことで、MMLU は 2023 年以降の最先端モデル比較に有効でなくなった。Chatbot Arena はライブ・人間嗜好評価でこの飽和を回避し、HLE はさらに困難な静的問題でカバーする。GPT-4 の MMLU スコアが「飽和の起点」として歴史的参照点となっている。(Source: [[@2023__arXiv__GPT-4 Technical Report]], [[@2025__arXiv__Humanity's Last Exam]]) ## 関連 - [[Chatbot Arena]] — 人間嗜好型ライブ評価の代表実装 - [[LMSYS]] — Chatbot Arena 開発元 - [[Center for AI Safety]] — HLE 開発元 - [[Dan Hendrycks]] — HLE 上級著者・MMLU 設計者 - [[RCA評価設計]] — 根本原因分析タスクにおける LLM 評価の wiki 内関連概念 - [[ゼロエラー境界]] — 評価範囲の恣意性を排除するオープンエンド評価指標 - [[LLM能力スパース性]] — 高度能力と単純誤りが共存する現象 - [[agentic SRE]] — Promptfoo によるオフライン評価フライホイールの産業実装先 - [[AIOps]] / [[ReAct]] — ツール利用エージェントの精度×レイテンシ×トークン消費量評価の産業実装先 - `structures/` 内の関連 MOC: なし(今後追加予定) ## 出典 - [[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]] - [[@2025__arXiv__Humanity's Last Exam]] - [[joisino-LLMの能力の穴-2026]] - [[@2023__arXiv__GPT-4 Technical Report]]（§4 Capabilities: Table 1 試験・Table 2 ベンチマーク; Appendix C/D 汚染対策） - [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]] — Promptfoo によるオフライン評価フライホイールの産業実装 - [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]](§4 RQ1〜RQ3: 精度・レイテンシ・トークン消費量の 10 モデル横断比較)