LLM出力の評価——ゴールデンセットとオフラインeval

「プロンプトを変えたら、なんとなく良くなった気がする」——LLMを使った開発でよく聞くフレーズだ。しかしこの「気がする」で本番運用を続けると、ある日、以前は正しかった質問に壊れた回答が返ってくるようになる。

この記事では、LLMアプリケーションの評価を、感触から機械採点へ移すための実務的な考え方を整理する。

まず、ゴールデンセットを作る

評価の骨格は、代表的な入力と期待される出力のペアだ。編集部が観測してきた成功例は、ほぼ例外なく、50〜200件のゴールデンセットを最初に整備している。

完璧を目指す必要はない。過去のログから代表的な質問を抽出し、正解を人手で書く。ユーザー種別・入力パターン・エッジケースが偏らないよう分布に気を配る。「これがカバーできていれば安心」というカバレッジ確認より、「代表性のあるサンプルを早く揃える」ことのほうが優先度が高い。

評価軸を絞る

「品質」を測るとき、抽象的な採点をしても運用に使えない。編集部が観測した現実的な評価軸は、業務ごとに次のように分かれていた。

• 質問応答：正解の主要事実が含まれているか（キーワードマッチまたはLLM-as-a-Judgeで採点）。
• 要約：元文書のキーポイントを含み、元にない情報を含まないか（人手評価が中心）。
• 抽出：スキーマに準拠しているか、必須フィールドが揃っているか（決定論的に採点可能）。
• RAG：正しい原文を引用しているか、引用箇所と回答が整合しているか。

すべての軸を一度に測る必要はない。まず1〜2軸に絞って自動採点を回し、そこから広げる。

機械採点できる部分は、必ず自動化する

ゴールデンセットが整ったら、そこに対する評価を自動で走らせる仕組みを組む。CIパイプラインで、プロンプト変更・モデル切替・スキーマ変更のたびに自動評価を回す。結果は履歴として保存し、平均スコアの推移をダッシュボードで追える状態にする。

機械採点可能な軸は驚くほど多い。JSONスキーマ準拠、必須フィールド、キーワード有無、応答長、応答時間、引用の一致——これらだけでも、大きな回帰を捕まえられる。

LLM-as-a-Judgeの、有効な使い方と限界

「LLM出力の品質を、別のLLMに採点させる」パターン（LLM-as-a-Judge）は、抽象的な軸（自然さ、丁寧さ、有害性）を大規模に測るために有用だ。人手評価が現実的でない件数の採点を、数十分で終えられる。

ただし限界がある。編集部が観測してきた失敗パターンは主に3つ。採点者モデルのバイアス：長い応答を高く評価する、自モデルの応答を高く評価する。採点基準の不安定さ：同じ入力を同じ日に2回採点しても、点数がばらつく。ゴールデンセット外の弱さ：想定外の入力パターンでは、採点自体が信頼できない。

実運用では、LLM-as-a-Judgeの結果と人手評価のサブサンプル（10〜20件）を、月に一度相関検定する。相関が0.6を下回るようなら、採点プロンプトかモデルを見直す。

本番の一部から、オンライン評価で拾う

オフライン評価は、既知の問題を再発させないためには強力だが、未知の問題は捕まえられない。「モデルアップデートで、いままで問題なかった質問群が壊れた」を検知するには、本番運用中のフィードバックが必要になる。

編集部が観測してきた運用は、シンプルな仕組みを組み合わせていた。UI上に「役に立った / 立たなかった」のフィードバックボタン。低品質と報告された応答を、翌週の評価会でレビュー。ログの詳細な記録と組み合わせれば、劣化の兆しを早期に捕まえられる。

ただし、評価も更新が必要

ゴールデンセットは静的なアセットではない。運用が進むと、想定していなかった質問パターンが出てくる。業務内容が変わり、以前の正解が古くなる。編集部は、四半期に一度、ゴールデンセットの見直しを推奨している。「評価の評価」を定期的に行う運用が、長期的な品質を担保する。

参考にした一次資料

• Zheng, L. et al. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” arXiv:2306.05685.
• Chang, Y. et al. “A Survey on Evaluation of Large Language Models.” arXiv:2307.03109.

関連する話題として、RAG運用とスタック選定もあわせてお読みください。