LLM評価の本質は、ダッシュボードではなく失敗を読むことだ

LLM評価という言葉を聞くと、多くのチームはすぐに基盤を作ろうとする。評価基盤。メトリクス。ダッシュボード。自動採点。LLM-as-a-judge。

でもHamel HusainのFAQが繰り返し言っているのは、もっと地味なことです。

まず出力を見ろ。

20件でもいい。50件でもいい。実際のユーザー会話、実際の失敗、実際の変な返答を見る。そこから失敗の型を作る。評価はそこから始まる。

evalは別プロジェクトではなく、デバッグである

Hamelは、評価を開発プロセスの一部として扱う。ソフトウェア開発にデバッグが含まれるのと同じです。別予算の立派な儀式ではない。

彼は、プロジェクトでは60〜80%の時間をエラー分析と評価に使うことがある、と書いている。これは大げさに見えるかもしれない。でもLLM製品では、失敗を見ないまま改善する方がもっと危ない。

なぜなら、LLMの失敗はアプリごとに違うからです。

不動産アシスタントの失敗、医療要約の失敗、社内検索の失敗、コードレビューの失敗は違う。一般的なROUGEやBERTScore、きれいな平均点では見えない失敗がある。ユーザーが本当に困る失敗は、だいたいプロダクト固有です。

だから最初にやることは、評価器を書くことではない。失敗を見ることです。

最小評価は、30分で20〜50件を見ること

Hamelの最小可行評価は、かなり小さい。

大きな基盤を作らない。まず30分、20〜50件のLLM出力を人間が見る。ユーザーを理解しているドメイン専門家を一人置き、その人が品質判断者になる。彼はそれを「benevolent dictator」と呼ぶ。

この言い方は強いけれど、意味は分かる。初期のLLM評価では、多数決よりも深い判断が要る。何が本当に悪いのか。どの失敗がユーザーに効くのか。何を直すべきか。これは、仕様だけ読んだ外注ラベラーには分かりにくい。

まず人が見る。メモする。分類する。失敗の名前を付ける。

この時点で直せるものは多い。正規表現で捕まるもの、プロンプトの明らかなバグ、ツール呼び出しの漏れ、フォーマット違反。そういうものは、立派なLLM judgeを作る前に直せばいい。

評価器は、想像した失敗ではなく、見つけた失敗に書く

多くのチームは、評価マトリクスを先に作りたがる。質問タイプA、B、C。難易度。ドメイン。形式。全部を埋める。

でもHamelは、実際の失敗から評価戦略を作れと言う。エラー分析で見つけたパターンに対して評価を書く。想像上の失敗ではなく、現物の失敗に払う。

これはかなり実務的です。

たとえば、すべての「時系列をまたぐ質問」で失敗しているなら、その軸で評価を作る。複数ソースを統合する質問で失敗しているなら、そこを重点的に見る。ユーザーの入力理解で失敗しているのか、中間処理で失敗しているのか、最後の出力形式で失敗しているのか、workflow stageで分ける。

評価は網羅表ではなく、失敗地図です。

高い合格率に安心しない

もう一つ刺さるのは、高い合格率への警戒です。

100%通るevalは、システムが強い証拠ではないかもしれない。単に簡単すぎるだけかもしれない。Hamelは、70%くらいの通過率の方が、実際にシステムを圧迫している意味ある評価かもしれない、と書いている。

これは日本の品質文化とも相性がいい。検査は「通すため」にあるのではない。弱いところを見つけるためにある。

LLM評価でも同じです。ダッシュボードを緑にするための評価は、気持ちはいい。でも製品を良くしない。むしろ危険です。失敗が見えなくなる。

LLM-as-a-judgeは最後の魔法ではない

LLM-as-a-judgeも、使いどころがあります。ただし、最初の一手ではない。

Hamelの整理では、まずドメイン専門家がデータセットを見て、合否と批評を書く。エラーを直す。そのうえで、必要な失敗モードに対してLLM judgeを反復的に作る。重いjudgeは非同期やバッチで回すのが普通で、低遅延が必要な本番ガードレールには向かないことが多い。

つまり、judgeは人間の判断を置き換えるものではない。人間の批評を写し取り、繰り返し使える形にするものです。

ここを間違えると、「AIでAIを評価する」だけの危ない循環になる。人間が何を良いとするかを見せないまま、モデルに採点させても、採点らしいものが出るだけです。

個人的な見方

LLM評価の本質は、メトリクス作りではなく、失敗を読む訓練です。

これはyuewei-digestにもそのまま刺さる。記事の分類、重要度、要約、洞察、日文稿。全部LLMの出力です。だから本当に品質を上げるなら、まず代表的な出力を50件見て、どこでズレるかを分類するべきです。

スコアが甘い。カテゴリが漂う。要約は合っているが判断が薄い。日本視角が後付けになる。一次源に戻っていない。こういう失敗を名前にする。名前にできた失敗だけが、評価になり、改善になります。

日本のSIerや企業AI導入にも同じことが言える。「AIの品質をどう担保するか」で止まるチームは多い。でも最初の答えは、かなり泥臭い。まず50件見ろ。失敗を書け。型にしろ。直せるものは直せ。必要なものだけ自動評価にしろ。

ダッシュボードはその後でいい。緑のグラフより、赤い失敗メモの方が先です。

―― AI未来編集室「AIウォッチ」