LLMを組み込んだシステムを評価する際に意識したい3つの視点

本記事では、LLMを組み込んだシステムを評価する際に意識したい三つの視点を紹介します。

開発や運用の現場では、出力の揺らぎや評価の曖昧さに悩むことも少なくありません。どんな基準で評価すべきか、どこまで信頼できるのかを見極めるために、観点を整理する必要があります。

本記事では、評価データの整え方、指標の選び方、そして実行上の注意点まで順を追って見ていきます。

背景

LLMを組み込んだシステムは、今や多くの場面で使われるようになってきました。ただし、そうしたシステムの動きを正しく評価するのは、簡単ではありません。なぜなら、ユーザーが入力できる内容も、そこから返ってくる応答も、無限に近いほど多様なためです。しかも、同じ入力でも毎回違う答えが返ってくることもあります。

さらに、会話が何ターンも続くような仕組みになると、途中で起きた小さなミスがどんどん蓄積し、全体の流れに影響することがあります。ちょっとした言い回しの違いで出力が変わったり、事実と異なる内容が混ざったり、時には正しい情報があるのに「わかりません」と返されることもあります。裏側で使っているAPIやデータソースとの連携も、出力の不安定さを生む要因になるため、設計の難易度が高い状況です。

こうしたなかで、現場で本当に使えるLLMシステムをつくるには、実際の利用シーンに即した形で応答の品質をチェックできる評価方法が必要です。うまく評価することで、改善の方向が見えやすくなり、使う人の信頼も得やすくなりますし、無駄な試行錯誤も減らせます。

とはいえ、今は「なんとなく広く使われている」評価手法が多く、本当にその場に合った評価ができているかというと、心もとないケースもあります。汎用的なベンチマークや定番のメトリクスでは、実際の業務やユーザー体験を十分に反映できないことがあります。

そこで今回の記事では、LLMシステムをより現実的に設計・運用するために、”実務に役立つ評価の考え方”を整理していきます。どんなデータを集めるか、何を基準に良しとするか、どうやって現場の要件に沿った形で評価を回していくか。その一連のプロセスを、わかりやすく枠組みとしてまとめた内容を紹介します。

まずはデータセット作成における5つの基本原則から整理していきます。

以下、Googleの研究報告をもとにお伝えします。同社は社内実務においてLLMを大規模に活用しているため、LLMシステムの評価ノウハウに関する話にも説得力があります。Googleがいかに社内実務にLLMを活用しているかについては、この記事も参考していただけると幸いです：Googleが実践するLLMを活用したコードマイグレーション

評価用データセットの作り方

LLMシステムの動きを正しく見極めるには、「どんなデータで評価するか」をきちんと設計することが大切です。

まず、評価用のデータセットを信頼できるものにするには、基本原則「5つのD」に沿って構成することが重要です。

データセット作成の基本原則「5つのD」

• 範囲を明確に定める（Defined Scope）
• 実際の利用シーンを反映する（Demonstrative）
• 内容に偏りがない（Diverse）
• モデルの学習に使ったデータと重ならない（Decontaminated）
• そして運用に合わせて継続的に見直す（Dynamic）

上記を押さえた上で、実際の準備プロセスを見ていきましょう。

データセットを準備する3つの方法

評価用データは、大きく分けて3つの方法で集めます。それぞれ良さと注意点があるため、目的に応じて使い分けると効果的です。

データの集め方①既存のベンチマークを使う

公開されている評価用データセットをそのまま使うのが一つ目の選択肢です。手軽に使い始められますが、自分たちのシステムにそのまま当てはまるとは限りません。学習時のデータと重なっている可能性もあり、要するにLLMが「すでに覚えていること」をテストすることになるケースもあります。そのため性能が過大評価されることもあります。信頼できるかどうかを見極めながら使う必要があります。

データの集め方②高品質なデータを人手で作る

専門知識が求められる領域では、専門家がデータを一つひとつ作成したいわゆる「ゴールデンデータセット」が効果的です。LLMの応答における正確さや有用性、内容の充実度まで含めて評価できるのが強みです。ただし、作成には時間やコストがかかります。社内の専門家や外部への依頼、UX調査やユーザーのフィードバックを活用するなどが主な方法です。

「ゴールデンデータセット」を作成する際は、品質を保つには、明確な指示と一貫した作業フローが欠かせません。なお、専用のデータラベリングツールを使えば、作業のバラつきを抑えやすくなります。

データの集め方③LLMでデータを自動生成する

LLMを活用して（プロンプトと応答から）データセット用のデータを自動生成する方法もあります。コストを抑えつつ多くのデータを用意しやすいため、実務でよく使われています。ただし、生成したデータの品質や偏りには注意が必要になります。とくに、モデルの訓練に使われたデータと重複していないか、人の目でしっかり確認する必要があります。

高度な工夫としては、LLM自身に応答の良し悪しを自己評価させる手法の応用や、徐々に指示の複雑さを上げていくといったテクニックも有用です。また、プロンプトの多様性を広げるために、異なるキャラクターを演じさせたり、温度パラメータなどを調整したりする手法も有効です。

組み合わせて使うと効果的

以上3つのデータ収集手法は、目的に応じて使い分けるだけでなく、組み合わせて使うのが効果的です。

たとえば、以下のようなステップが想定できます。

1. 最初は既存ベンチマークや少量の人手データで土台をつくる
2. そこから自動生成でデータを広げていく
3. そうしてできた初期データを少しずつ改善していく

このような手順を踏むと全体像をつかみながら簡易的なデータセット（シルバー）を高品質なもの（ゴールデン）へと育てることができます。

データの品質を測るときの視点

評価データがどれだけ良いかを見極めるには、先ほどの「5つのD」をどれだけ満たしているかを定量的にチェックする視点も必要です。

データセット作成の基本原則「5つのD」（再掲）

• 範囲を明確に定める（Defined Scope）
• 実際の利用シーンを反映する（Demonstrative）
• 内容に偏りがない（Diverse）
• モデルの学習に使ったデータと重ならない（Decontaminated）
• そして運用に合わせて継続的に見直す（Dynamic）

チェックの結果、評価が低ければ、それは実際の利用には合っていないというサインかもしれません。

似たようなプロンプトが多すぎないか、カバーする領域に偏りがないか、モデルが事前に学習していない内容に対しても正しく評価できるかなど、いくつかの軸でバランスをとりながら、データセットそのものをアップデートしていくことが求められます。

忘れてはいけない汚染除去

評価用データセットの中身をLLMが既に知っている場合、性能が実際よりも高く見えてしまいます。その結果、モデルの選び方やシステムの設計判断を誤ってしまうおそれがあります。こうした“汚染”を防ぐには、学習が終わったあとに別で集めたデータだけを使うことが基本です。外部に公開しない形で、独立した評価用データセットを保っておくのが理想です。

なお、汚染のチェックにはいくつか方法があります。たとえば、プロンプトの一部だけを与えても正解をそのまま出してくるかどうかを見る方法（「継続テスト」）。モデルの応答にどれだけ自信を持っているかを調べる方法があります（対数確率やパープレキシティを確認する）。また、もし学習データにアクセスできる場合は、文の一致や類似度を機械的に比較することで、重なりを見つけることも可能です。扱うデータが大量になるときは、効率化のためにアルゴリズムを使う必要があります。

動的更新

評価に使うデータは一度作って終わりではなく、定期的に見直し、追加や削除を繰り返していく必要があります。実際の業務やユーザー環境が変われば、テスト対象のシステムも変わっていきます。そうした変化に合わせて、古くなったデータは整理し、新しいデータを取り込んでいくことで、評価としての意味を保ち続けましょう。

サンプル数の目安をどう考えるか

評価データは、多すぎても扱いにくく、少なすぎても統計的に意味のある結果が得られません。

どれくらいのデータが必要かを見積もるには、サンプルサイズの計算式を使う方法があります。

たとえば、ある指標について「80％くらいの精度が出るだろう」と予想し、誤差5％で95％の信頼性を確保したいと考えた場合、必要なサンプル数?は次の式で求められます。

ここで、

?（信頼係数）＝1.96（95％信頼区間の場合）

?（予想精度）＝0.8

?（許容誤差）＝0.05

これを計算すると、245.86という結果が出ます。

よって、この場合、必要なサンプル数は約246件になります。

より正確な結果を求めると必要なデータ数は一気に増えてしまうため、評価の精度とコストのバランスをとる意識が大切です。

データセットは評価の土台

どんなデータで評価するかは、LLMシステムの評価全体の出発点になります。公開ベンチマークを使うのか、人手で整えるのか、LLMで生成するのか、その選び方と組み合わせ方には工夫が求められます。ただどんな手法を使う場合でも、評価に使うデータには共通して求められることがあります。

それは、実際の使われ方を想定し、多様で、学習データとは独立していて、時間とともに見直しを行い、そして評価対象の範囲が明確になっていることです。こうした前提をしっかり整えておくことで、あとに続く評価指標の設計や、全体の分析の精度が安定します。

データセットの準備は、LLMシステムの評価を進めていくうえでの“土台”になります。この土台がしっかりしていれば、評価の結果も実際の改善につなげやすくなります。

評価指標の選び方

評価用のデータセットが整ったら、次に考えるべきは「どんな基準でLLMの出力を評価するか」です。事実確認、文章の流暢さ、要約や翻訳の精度など、なにを重視して評価するかによって、選ぶべき指標は変わってきます。

また、評価したいポイントが複数ある場合は、それに応じて複数の指標を組み合わせることになります。「これひとつですべて判断できる」という万能な指標は存在しません。バランスよく見ることが大切です。

表現の一致度を見る指標

よく使われるのが、生成された文章と理想の応答との間で、単語やフレーズの重なり具合を見るタイプの指標です。計算が簡単で処理効率も良く、言語に依存しにくい点がよいところです。

ただし、言い換え表現には弱く、意味が通っていても単語が違えば低スコアになる傾向があります。また、事実確認や構文の自然さを評価するには不向きです。応答が長すぎたり、単語を繰り返したりしても、過大評価につながることがあります。

そのため、この手の指標を使う場合は、できるだけ表現の幅をカバーする複数の模範解答を用意しておくとよいです。

以下では、表現の一致度を見る指標の種類をいくつか挙げます。

ROUGE

要約タスクなどでよく使われる、人間が作った要約と自動生成の要約との重なりを（n-gramや単語列の共通性をもとに）比較する方法をROUGEと言います。

「どれだけ必要な情報を拾えているか（再現率）」あるいは「無駄が少なく、的を射ているか（適合率）」、またはそのバランスを見ます。バランスを測る際のスコアはF1スコアと呼ばれ、再現率と適合率から算出します。

ROUGEはあくまで単語レベルの重なりに注目するため、表現が異なる場合の正しさを見落とすことがあります。たとえば、アポロ11号の例で「月面着陸」の代わりに「火星着陸」と書いた場合でも、周辺の語句が合っていれば高スコアになってしまいます。

他、いくつかの例をまとめます。

BLEU

BLEUは翻訳の評価で広く使われており、翻訳の長さなどをもとにスコアを出します。短すぎる訳にはペナルティがつくようになっています。

コード生成やクエリの出力にも応用されていますが、意味や機能の正確さまでは見られません。構文的な一致に強く、一方で内容の多様性や柔軟な表現にはあまり対応できません。

BLEUにはいくつかの改良型もあります。たとえば、同義語や語形の違いを考慮する仕組みなどが組み込まれたMETEORなどがあります。

キーワードによる評価

回答の内容をキーワードベースで評価する方法もあります。全文を比べるより、含むべき語が含まれているかを重視する考え方です。

ただし、この方法にも注意点があります。たとえば、質問文をそのまま繰り返しているだけでも高スコアになることがあり、「答えていないけど単語は合っている」といったケースを見逃す可能性があります。

意味の近さを見る指標

単語レベルではなく、文の意味的な類似度を数値化する方法もあります。埋め込みモデルを使用して回答文をベクトル表現に変換し、どれだけ近い意味を持っているかを測ります。モデルが言語の意味をきちんと捉えていれば、単語が違っていても「正しい内容」を捉えられることがあります。

たとえば、「月面」と「月」など、同じ対象を指す表現はベクトル的には近くなるため、意味ベースの評価では正しく高スコアになります。

独自の業務用語や文体を扱う場合には、カスタムの埋め込みモデルを用意することも検討されます。

含意関係を見る指標

「この応答は、元の質問に対して矛盾していないか」「正しく言い換えられているか」といった視点での評価ができるNLI（自然言語推論）と呼ばれる指標もあります。

たとえば、アポロ11号のミッションに関する質問に対して、「火星に着陸した」と答えていた場合は「矛盾」、似た意味で言い換えていれば「含意」、全く別の話をしていれば「中立」と判定されます。

事実確認を重視するタスクでは、こうした視点で評価できる仕組みがあると便利です。

LLMを使った自動評価

LLM自体を使って、出力の品質を自動で評価させる方法もあります。これを「オートレーター」と呼ぶことがあります。

たとえば、ある質問に対して複数の回答があったとき、「どちらが良いか」をLLMに聞いてスコアを出させる形です。

内容の正しさや流暢さ、回答の網羅性など、複数の観点で評価できるようにプロンプトを工夫します。

人手を使わずに多くのデータをさばける点で実用的ですが、LLM自身のバイアスや判断のゆらぎが入りやすくなる点には注意が必要です。

その他の指標

出力された文章の「もっともらしさ」を数値化する手法もあります。たとえば、パープレキシティ（PPL）は、LLMがその応答をどれだけ「自然」と感じたかを示す指標です。

*同じ名称のAIサービスがあるため混同に注意。

ただし、内容が正しいかどうかとは別の話になるため、参考程度にとどめるのがよいでしょう。文法的に正しくても、事実としては間違っている応答に高スコアがつくこともあります。

指標選びは“目的次第”

どの指標を使うかは、最終的に「何を重視したいか」によって決まります。表現の正確さを見たいのか、意味の一貫性を見たいのか、それとも流暢さや誤情報のリスクに注目したいのか。

万能な指標はないからこそ、それぞれの特性を理解し、組み合わせて活用していくことが求められます。組み合わせに長けるとより実感に近い評価ができるようになります。

評価をどう実践するか

データセットと評価指標が整ったら、次は「実際にどう評価を進めていくか」を考えます。

LLMを組み込んだシステムでは、従来のソフトウェアとは違った注意点がいくつかあります。たとえば、同じ入力でも出力が変わる性質、ちょっとした文言の違いで出力が大きく変わる敏感性、さらには事実と異なる内容が出てしまうハルシネーションなどです。

そうした特有の現象にどう向き合えばよいかを整理しながら、評価結果をどのように開発や改善に活かしていけるかを見ていきます。

出力のばらつきにどう向き合うか

LLMでは、まったく同じプロンプトでも出力が変わることがあります。モデルの性質だけでなく、APIの状態や実行タイミングによっても結果が揺れます。性能を正しく捉えるには、こうしたばらつきがどのくらいあるかをきちんと把握しておく必要があります。

見落としがちなのは、タイミングによる影響です。夜間や負荷の低い時間にだけ評価してしまうと、本番環境での応答ばらつきをうまく再現できないことがあります。

出力のばらつきへの向き合い方①応答の多数決をとる方法

対処方法として、同じ入力に対して複数回モデルを実行し、よく出てくる応答を選ぶアプローチがあります。温度パラメータを高めに設定し、応答のバリエーションを確保したうえで、最頻出のものを代表とみなします。

これをするとばらつきを抑えられるだけでなく、全体としての応答品質が上がるケースもあります。

ただし、モデルを何度も呼び出す必要があるため、コストや遅延とのバランスを見ながら取り入れることになります。

出力のばらつきへの向き合い方②揺らぎを見積もっておく

LLMの出力には一定のばらつきがあります。同じプロンプトでも、毎回少しずつ違う結果が返ってくるため、1回だけの評価で良し悪しを判断すると誤解が生まれるおそれがあります。

そこで、あるプロンプトに対して何回か繰り返し出力を取って、その平均スコアとばらつきの幅を記録しておきます。たとえば、同じ質問で10回テストしてスコアが 78、80、82… という結果になれば、「このプロンプトの平均スコアは80点前後で、だいたい±2点くらいは揺れる」という目安が得られます。

こうしてあらかじめ「どれくらいスコアが揺れるか」を見積もっておくと、あとでシステムやプロンプトを変更したときに、スコアの変化が本当に改善によるものか、それとも自然なばらつきの範囲内なのかを見分けやすくなります。

入力のちょっとした違いに強くなるには

ユーザーの入力は常にきれいとは限りません。大文字小文字の違いやスペースの有無、語順の入れ替えといった小さな変化でも、LLMの出力は大きく変わることがあります。

こうした敏感さも考慮に入れてあらかじめ評価しましょう。入力にあえてノイズを加えて評価を行う方法が有効です。たとえば、文字の順序を入れ替えたり、余分な空白を入れたり、あるいはLLM自身を使ってプロンプトを書き換えたりします。

それによって何が分かるかというと、以下のようなことです。

• どの評価指標がノイズに弱いか
• どの種類のタスクが影響を受けやすいか
• どのデータがとくに壊れやすいか

プロンプト設計の見直しや、評価指標の選定にもつながります。

LLMが複数つながっているシステムを評価するには

LLMの呼び出しが連続しているようなワークフローでは、出力の一部が次の入力になります。たとえば、RAGのように外部知識を取得してから応答する仕組みでは、中間のコンポーネントの品質が最終出力に強く影響します。

コツ①モデルの知識と外部情報を区別する

LLMはもともと膨大な知識を持っています。そのため、外部知識を使わなくてもそれなりの応答が返ってくる場合があります。ただ、それがモデルの思い込みによるものなのか、外部知識をもとにしたものなのかを見極める必要があります。

この見極めには、たとえば以下のような方法があります。

• 人手で、情報源がどこかを確認する
• 別のLLMを使って、どこまで外部知識が活用されているかを評価する
• 提供されたドキュメントと応答の意味的な近さを測る

こうした情報がそろえば、モデルが不確かな分野で「それっぽく答えてしまっている」ことに気づける可能性が高まります。

コツ②外部検索の有無で比べてみる

シンプルに、外部検索を使ったときと使わなかったときで性能を比べるという方法もあります。もしほとんど差がないなら、外部検索が実質的に機能していないか、モデルが知っている話題なのかもしれません。

ただし、これはあくまで全体のスコアを比べる手法なので、構成要素ごとの分析には不向きです。

ハルシネーションや空返事の扱い

LLMが事実と異なる内容を生成していないか（ハルシネーション）や、逆に答えるべき場面で「わかりません」と逃げていないかといった観点も重要です。

ハルシネーションへの対策としては、たとえば、存在しないCVE番号を使って質問をしてみると、モデルの反応が確認できます。知らないものを知らないと答えられるかどうかが問われます。

一方で、答えられるはずの質問に対しても「わからない」と返してしまうケースも。これは、ハルシネーションを抑えようとする設計が過剰に働いてしまっている可能性があります。たとえば、「知らないときは『わかりません』と答えてください」といった指示を強く出しすぎると、本来は答えられるはずの場面でも空返事が増えてしまうことがあります。指示の設計を見直しましょう。

評価の現場に落とし込むために

単に指標を決めて終わりではなく、「実際に評価を回す」最後の工夫がとても重要です。LLMならではの揺らぎや複雑性をしっかり踏まえることで、評価結果をより確かなものに近づけていけます。

評価を通じて何が起きているかを見える化し、それを設計や改善につなげていく。そのための考え方と手法を整理しました。

まとめ

本記事では、LLMを活用したシステムを評価していく際に意識したい3つの視点を紹介しました。

データセットをどう準備するか、どんな指標で見るか、そして評価をどのように実行するかです。

それぞれの項目について、現場でも活かしやすいヒントや工夫があることが分かります。工夫を積み重ねていくことで、LLMを含むシステムの状態をより正確に把握できるようになります。

もしご自身のプロジェクトで評価に迷うことがあれば、今回の枠組みをひとつの参考として取り入れてみてはいかがでしょうか。