LLMアプリの評価(eval)の作り方｜「動いた気がする」で止めないための実務手順

LLMを使った機能を作ると、いくつか試して「良さそう」と感じた時点で完成にしたくなります。ですが、その「動いた気がする」は評価ではありません。プロンプトを少し直す、モデルを新しくする、RAGの検索を変える。そのたびに品質が上がったのか下がったのか、感覚では追えなくなります。この記事では、LLMアプリの評価(eval)をどう作るかを、小さく始めて回し続ける手順として整理します。

なぜ「動いた気がする」は危ないか#

手元で3件試してうまくいったとき、頭の中では合格にしています。ですが、その3件はたまたま素直な入力だったかもしれません。実運用では、言葉足らずの質問、想定外の言い回し、社内でしか通じない略語が混ざります。少数の成功体験は、失敗の分布を教えてくれません。

さらに厄介なのは、変更の影響が見えないことです。プロンプトを直してある質問が改善しても、別の質問がこっそり悪化する、ということは普通に起きます。評価データが無ければ、この「あちらを立てればこちらが立たず」を検知できません。評価とは、機能追加のたびに毎回同じ物差しを当てて、全体として良くなったかを確かめる仕組みです。

評価データは実運用に似せる#

評価の質は、評価データが現実に似ているかでほぼ決まります。開発者が思いつく「きれいな質問」だけを並べると、本番で起きる失敗を素通りしてしまいます。

各ケースには、期待する結果(正解、または「満たすべき条件」)を添えておきます。ここが後の採点の基準になります。

指標はタスク型で変える#

万能な単一指標はありません。何を「正解」とするかは、タスクの性質で変わります。

一致判定で済むタスクは、機械的に採点できるので迷いません。難しいのは出力に幅があるタスクです。ここは「事実に反していないか」「依頼された観点を満たしているか」「言ってはいけないことを言っていないか」といった観点を分け、それぞれを段階(例: 満たす/一部/満たさない)で採点するルーブリックを先に決めます。採点基準を言葉にしておくと、人が採点しても、後述のLLM採点に任せても、ぶれが小さくなります。

自動評価と人手レビューを併用する#

自動評価は速くて安定していますが、測れるのは「形」に近い部分です。一致するか、形式が正しいか、禁止語が入っていないか。一方で、文章としての自然さや、微妙なニュアンスの誤りは、機械的な一致では拾いきれません。

現実的なのは併用です。まず自動で回せる部分を自動化し、機械では判断が難しい観点だけ人が見ます。人手レビューは全件でなくてよく、自動評価で差が出たケースや、点数が割れたケースを抜き出して確認すれば十分なことが多いです。人が見た結果は、後で述べるようにテストデータへ戻していきます。

LLM-as-a-judgeの使いどころと落とし穴#

出力の採点そのものを、別のLLMに任せる方法があります。いわゆるLLM-as-a-judgeです。ルーブリックと採点対象を渡し、「この基準で1〜5点で採点して」と頼むやり方で、人手採点をスケールさせる手段として使われます。有効ですが、いくつか落とし穴があります。

判定の仕組みとしては、採点用LLMに専用のツールや上位モデルを与える設計もあります。関数呼び出しの考え方はここでも共通です。

失敗をテストに戻す継続的な評価#

評価は一度作って終わりではありません。運用していると、評価データに無かった新しい失敗が必ず出てきます。この失敗を捨てずに、次のテストケースへ育てるループが肝心です。

このループが回り始めると、評価データセットは「自社で実際に起きた失敗の集まり」に育ちます。汎用ベンチマークの数字より、こちらのほうが自社の品質を正しく映します。

スコアはバージョンに紐づける#

評価結果は、それ単体では意味を持ちません。「85点だった」ではなく、「どのプロンプトで、どのモデルで、どの評価データで85点だったか」までそろって初めて比較できます。

これらを紐づけておくと、「先週より点が下がったのはモデルを変えたからか、評価データを増やしたからか」を切り分けられます。紐づけが無いと、数字が動いても原因が分からず、評価が判断材料になりません。

RAGやエージェントでの難しさ#

単発の入力と出力なら採点は比較的単純ですが、RAGやエージェントでは難しさが増します。

RAGでは、最終回答が間違っていたとき、原因が検索(必要な文書を引けなかった)なのか、生成(引けたのに読み違えた)なのか、切り分けが要ります。回答の当否だけでなく、根拠として使った文書が適切だったかを別に採点すると、どこを直すべきかが見えます。

エージェントでは、複数ステップを経て結果に至るため、最終結果だけでなく途中の道筋(どのツールをどの順で呼んだか)も評価対象になります。最終的に正解でも、無駄な手順や危うい操作を経ていれば、実務では問題です。まずは最終結果の評価から始め、必要に応じて途中経過の評価を足していくのが現実的です。

よくある質問#

まとめ#

評価は、LLMアプリを「たまたま動くもの」から「変えても壊れていないと確認できるもの」へ引き上げる土台です。単一の万能指標は無く、完璧な採点表も要りません。まずは代表タスクを少数そろえ、変更の前後で同じ物差しを当てるところから始めてください。失敗を評価に戻し続ければ、その物差しは自社の品質を最もよく映す資産に育っていきます。