LLMの評価方法とは？FDEが現場で使う指標・手順・ツールを解説
- 大量のテストケースを短時間・低コストで回せる
- プロンプトやモデルを変えた後の回帰テストに向く
- 評価用LLM自体の偏りを定期的に人手で確認する必要がある
- 業務上の妥当性や言い回しの細かな違いを判断できる
- 評価基準づくりや自動評価の正しさの確認に欠かせない
- コストと時間がかかるため、少数のサンプルに絞って実施する
- 1. 要件定義顧客業務の成功条件と許容できない失敗を言語化する
- 2. 評価セット作成実際の業務データに近い入力と期待する出力を用意する
- 3. 評価の実行自動評価と人手評価を組み合わせてスコアを出す
- 4. 失敗の分析誤答をパターンごとに分類し、原因を特定する
- 5. 改善と再評価プロンプト・RAG・モデルを修正し、同じ評価セットで回帰を確認する
LLMの評価方法にはどんな種類がある？
LLMの評価方法は「自動評価」「LLM-as-a-Judge」「人手評価」の3種類に大きく分かれます。どれか1つではなく、目的に合わせて組み合わせて使います。
LLMの評価は、モデル単体の性能を測る「モデル評価」と、プロンプト・検索・後処理まで含めたアプリケーション全体の品質を測る「システム評価」に分けて考えると整理しやすくなります。FDE（Forward Deployed Engineer）が顧客の現場で主に扱うのは後者のシステム評価です。MMLUのような公開ベンチマークの順位がよくても、顧客の業務データで期待どおりに動くとは限りません。
自動評価とLLM-as-a-Judgeはどう違う？
自動評価は正解との一致をルールや統計で測る方法で、LLM-as-a-Judgeは別のLLMに採点させる方法です。
自動評価は、完全一致（Exact Match）、正規表現での形式チェック、BLEUやROUGEのような文字列の重なり、BERTScoreのような埋め込みの類似度などで機械的にスコアを出します。安く、何度でも同じ結果が出ますが、「意味は同じでも言い回しが違う」回答を低く採点しがちです。
LLM-as-a-Judgeは、採点基準（ルーブリック）をプロンプトに書いて、評価用のLLMに「正確さ」「根拠への忠実さ」などを判定させる方法です。自由記述の回答も評価できます。一方で、Zhengら（2023, “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”, arXiv:2306.05685）は、提示順で判定が変わる位置バイアス、長い回答を好む冗長性バイアス、自分の出力を高く評価する自己選好バイアスなどを報告しています。
| 評価方法 | 向いている対象 | 強み | 弱み |
|---|---|---|---|
| 自動評価（ルール・統計） | 分類、抽出、定型出力 | 低コスト・再現性が高い | 言い換えや自由記述に弱い |
| LLM-as-a-Judge | 要約、QA、対話 | 自由記述も大量に採点できる | 採点がぶれる・バイアスがある |
| 人手評価 | 最終品質、業務適合性 | 現場の感覚を反映できる | 高コスト・時間がかかる |
人手評価はいつ必要になる？
人手評価は、採点基準を作るときと、自動評価の信頼性を確かめるときに欠かせません。
LLM-as-a-Judgeの採点が人の判断とどれくらい一致するかは、実際に人が採点したサンプルと比べないと分かりません。現場では、最初の数十件から百件程度を業務担当者と一緒に採点し、「何をもって良い回答とするか」を言葉にする工程が、その後の評価全体の質を決めると感じる場面が多くあります。すべてを人手で採点し続けるのではなく、基準づくりと定期的な抜き取り確認に人手を集中させるのが現実的です。
LLM評価の指標はどう選ぶ？
指標は「ユースケースで何が失敗か」から逆算して選びます。品質指標に加えて、コストとレイテンシも必ず一緒に測ります。
指標を先に決めてしまうと、測りやすいものだけを測る状態になりがちです。FDEはまず顧客と「この回答が出たら業務上困る」という失敗例を洗い出し、その失敗を検出できる指標を選びます。
ユースケース別の代表的な指標は？
RAGなら忠実性と検索精度、分類・抽出なら正解率やF1、要約や対話なら網羅性や有用性が中心になります。
| ユースケース | 主な品質指標 | 補足 |
|---|---|---|
| 分類・タグ付け | 正解率、適合率・再現率、F1 | ラベルの偏りがある場合はF1を重視 |
| 情報抽出（JSON出力など） | 項目単位の完全一致、スキーマ準拠率 | 形式エラーはルールで検出可能 |
| RAG（社内文書QA） | Faithfulness（忠実性）、Answer Relevancy、Context Precision / Recall | Ragasなどで定義されている指標 |
| 要約 | 網羅性、事実誤りの有無、ROUGE | ROUGE単独では品質を判断しにくい |
| 対話・アシスタント | 有用性、トーン、拒否の適切さ | ルーブリック＋LLM-as-a-Judgeが中心 |
RAGの指標はRagasのドキュメントでの定義が広く参照されています。「回答が取得した文書に支えられているか（忠実性）」と「必要な文書を取得できたか（Context Recall）」を分けて測ると、問題が検索側と生成側のどちらにあるかを切り分けられます。
品質以外に測るべき指標は？
本番運用では、品質と並んでレイテンシ、1リクエストあたりのコスト、安全性を測る必要があります。
精度が高くても、応答に何十秒もかかったり、1件あたりのAPI費用が業務の採算に合わなかったりすれば導入は進みません。Stanford CRFMのHELM（Liangら, 2022）も、正確さだけでなく、頑健性、公平性、バイアス、有害性、効率などを含めた多面的な評価を提案しています。現場でも、少なくとも次の4軸をセットで見ておくと議論がしやすくなります。
- 品質：正確性、忠実性、形式準拠
- 速度：p50 / p95レイテンシ
- コスト：入出力トークン量と1件あたりの費用
- 安全性：個人情報の漏えい、不適切な出力、プロンプトインジェクションへの耐性
LLM評価はどんな手順で進める？
LLM評価は「失敗の定義→評価データ作成→ベースライン測定→改善と再評価→本番監視」の順で進めます。
この順番には理由があります。評価データより先にプロンプト改善を始めると、改善できたのかどうかを誰も判断できなくなるためです。
評価データセットはどう作る？
評価データセットは、顧客の実データに近い入力と期待する出力の組を、典型例と難しい例を混ぜて作ります。
評価データ（ゴールデンデータセット）の作り方は次のとおりです。
- 実際の問い合わせやログから入力を集める：個人情報はマスキングしてから使う
- 典型例と境界例を分ける：よくある質問、文書に答えがない質問、あいまいな質問、意図的な攻撃入力を混ぜる
- 期待する出力か、採点基準を付ける：正解が1つに決まらないタスクは「含むべき要素」「含んではいけない要素」で書く
- 業務担当者のレビューを通す：FDEだけで正解を決めない
- バージョン管理する：データの変更履歴を残し、スコアの比較を可能にする
件数は多ければよいわけではありません。少数でも失敗パターンを網羅しているほうが、改善のヒントが多く得られる印象があります。LLMで評価データを合成する方法もありますが、合成データだけだと実際の入力の癖を取りこぼしやすいので、実データと組み合わせるのが無難です。
改善サイクルはどう回す？
変更は1回に1つだけ入れ、同じ評価データで再評価して、前後のスコアと失敗例を比べます。
プロンプト、モデル、チャンク分割、検索件数を同時に変えると、どの変更が効いたのか分かりません。スコアの平均だけでなく、「改善前は正解で、改善後に失敗した事例（デグレ）」を必ず目で確認します。リリース前の評価をCIに組み込み、スコアが基準を下回ったらマージを止める運用にしておくと、後から入るメンバーにも品質基準を引き継げます。
LLM評価に使えるツールは？
LLM評価ツールは、評価指標ライブラリ、テスト実行ツール、トレース・監視基盤の3系統に分けて選びます。
1つのツールですべてをまかなうより、開発時のテストと本番の監視で役割を分けるほうが運用しやすいことが多いです。
代表的なLLM評価ツールにはどんなものがある？
Ragas、DeepEval、promptfoo、LangSmith、Langfuse、Arize Phoenixなどがよく使われます。
| ツール | 系統 | 主な用途 | 提供形態 |
|---|---|---|---|
| Ragas | 評価指標ライブラリ | RAG向け指標（忠実性、Context Recallなど） | OSS（Python） |
| DeepEval | 評価指標・テスト | pytest風のLLMテスト、LLM-as-a-Judge指標 | OSS（Python） |
| promptfoo | テスト実行 | プロンプト・モデルの比較、レッドチーミング | OSS（CLI / Node.js） |
| OpenAI Evals | 評価フレームワーク | 評価タスクの定義と実行 | OSS＋OpenAIプラットフォーム機能 |
| LangSmith | トレース・評価基盤 | トレース、データセット管理、評価実行 | SaaS（LangChain社） |
| Langfuse | トレース・評価基盤 | トレース、スコア記録、プロンプト管理 | OSS（セルフホスト可）＋クラウド |
| Arize Phoenix | トレース・評価基盤 | トレースの可視化、評価 | OSS |
| MLflow | 実験管理 | LLM評価結果の記録と比較 | OSS |
各ツールの機能や料金体系は更新が速いので、導入前に公式ドキュメントで最新の仕様を確認してください。
ツールはどう選べばよい？
顧客のデータをどこに置けるかと、既存の開発・運用体制に組み込めるかを最優先で判断します。
機能比較より先に確認すべきなのはデータの扱いです。金融・医療・公共分野の顧客では、プロンプトやログを外部SaaSに送れない場合があり、セルフホストできるOSS（Langfuse、Arize Phoenixなど）が候補になります。次に、顧客のエンジニアが引き継げるかどうかです。FDEが去った後に誰も運用できない評価基盤は、結局使われなくなります。Python中心の組織ならRagasやDeepEval、CI中心で回したいならpromptfooのように、顧客チームの技術スタックに寄せて選ぶのが安全です。
FDEが顧客の現場でLLM評価を行うときの注意点は？
FDEは評価基準を顧客と一緒に作り、データの取り扱いと評価結果の説明責任に特に注意する必要があります。
Palantirが広めたFDEという職種は、顧客の現場に入り込んで、プロダクトを実際の業務で使える状態にするのが役割です。LLM評価も同じで、技術的に正しいだけでなく、顧客の意思決定に使えるものでなければ意味がありません。
顧客と評価基準をどう合意する？
「何%なら本番に出せるか」という合格ラインと、絶対に許されない失敗を、評価の前に文書で合意します。
LLMの出力は確率的なので、精度100%は約束できません。現場では次の項目を事前に決めておくと、後の議論がかなり楽になります。
- 合格ライン：主要指標の目標値と、その根拠（人手で処理した場合の誤り率と比べるなど）
- 致命的な失敗：誤った金額の提示、個人情報の出力など、1件でも出たら止める失敗
- 人の確認を挟む範囲：自動化する範囲と、人が最終判断する範囲の線引き
- 評価のやり直し条件：モデル更新、文書追加、業務ルール変更のタイミング
数値目標は顧客の業務リスクによって大きく変わるため、一般的な「正解の数字」はないと考えたほうがよいでしょう。
データとセキュリティで気をつける点は？
評価データには実業務の情報が含まれるため、マスキング、保存場所、外部API送信の可否を最初に確認します。
LLM-as-a-Judgeでは、評価対象の入力と出力を評価用LLMに送ることになります。本番システムが閉域環境で動いていても、評価パイプラインだけ外部APIに送っていた、というのは起こりがちな見落としです。評価用のデータセット、ログ、ジャッジの呼び出し先まで含めて、顧客の情報セキュリティ部門と確認しておきます。
もう1つの注意点は、評価結果の伝え方です。平均スコアだけを報告すると、意思決定者には「だいたい動く」としか伝わりません。代表的な成功例と失敗例を並べ、「どの種類の質問で、どのように間違えるか」を業務の言葉で説明すると、追加投資や運用設計の判断材料になります。評価は品質を測るだけでなく、顧客とFDEが同じ現実を見るための共通言語でもある、というのが現場で働く実務者としての実感です。
参考文献
- Zheng, L. et al. (2023). “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” arXiv:2306.05685
- Liang, P. et al. (2022). “Holistic Evaluation of Language Models (HELM).” Stanford CRFM, arXiv:2211.09110
- Ragas、DeepEval、promptfoo、LangSmith、Langfuse、Arize Phoenix、MLflow 各公式ドキュメント
