LLMのテストとは
LLMのテストとは、大規模言語モデルが期待した性能や品質を発揮できているかを確認するための評価です。
単に「質問に正解できるか」だけを見るのではなく、知識、推論能力、指示への従いやすさ、回答の正確性、安全性、頑健性、処理速度、コストなど、さまざまな観点から評価します。
LLMの評価は「LLM Evaluation」や「LLM Eval」と呼ばれることもあります。
一般的なソフトウェアテストでは、入力に対する正しい出力が明確に決まっているケースが多くあります。
一方、LLMでは同じ質問に対して複数の適切な回答が存在するため、単純な正解・不正解だけでは性能を十分に判断できません。
そのため、LLMのテストでは自動評価、人間による評価、LLMを評価者として利用する方法、ベンチマークテスト、実際のユーザー利用データを用いた評価などを組み合わせることが重要です。
また、RAGやAIエージェントのようなシステムでは、LLM単体ではなく、検索機能、ツール、プロンプト、メモリ、再試行処理などを含めたシステム全体を評価する必要があります。
LLMのテストでは何を評価するのか
LLMの評価項目は用途によって異なります。
代表的なものとして、正確性、推論能力、指示追従、関連性、一貫性、ハルシネーション、安全性、頑健性、公平性、長文処理能力、ツール利用能力などがあります。
すべての項目を同じように評価するのではなく、実際の利用目的に応じて重要な指標を選ぶことが大切です。
正確性
LLM評価の基本となるのが正確性です。
質問に対して、事実として正しい回答を生成できるかを確認します。
たとえば、
「日本の首都はどこですか」
という質問に対して「東京」と回答できれば、内容としては正しいと判断できます。
選択問題や分類問題など、正解が明確に定義できるタスクでは、Accuracyと呼ばれる正解率を利用できます。
Accuracyは一般的に、
正解した問題数 ÷ 全問題数
によって計算します。
100問中85問正解した場合、Accuracyは85％です。
ただし、自由記述型の回答では、意味が同じでも文章表現が異なることがあります。
そのため、LLMの自由生成を評価する場合は、単純な正解率だけではなく、意味的な一致やLLMによる採点、人間による評価などを組み合わせる必要があります。
知識
LLMが必要な知識を適切に持っているかを確認する評価もあります。
一般知識、専門知識、科学、歴史、法律、プログラミングなど、さまざまな分野の問題を与えて評価します。
ただし、知識問題で高いスコアを取ったとしても、それだけでLLM全体の能力が高いとは限りません。
知識を記憶していることと、その知識を正しく組み合わせて推論できることは別の能力だからです。
推論能力
LLMでは、知識だけではなく推論能力も重要です。
複数の情報や条件を組み合わせ、論理的に結論を導けるかを評価します。
たとえば、
「AはBより背が高い。BはCより背が高い。最も背が高いのは誰か」
という問題では、
A ＞ B
B ＞ C
という関係から、Aが最も背が高いと判断する必要があります。
推論能力の評価には、数学、論理問題、科学、プログラミング、複数条件を含む問題などが利用されます。
指示追従能力
LLMがユーザーの指示を正しく守れるかを評価するのが、指示追従能力のテストです。
たとえば、
「100文字以内で説明してください」
と指示したにもかかわらず、数百文字の文章を生成した場合、内容が正しくても指示には十分に従えていません。
ほかにも、
「箇条書きで回答する」
「JSON形式で出力する」
「3つだけ紹介する」
「専門用語を使わず説明する」
といった条件を正しく守れるかを確認します。
APIや業務システムなどでLLMを利用する場合は、特に重要な評価項目です。
関連性
回答が質問内容にきちんと対応しているかも評価する必要があります。
これをRelevance、つまり関連性と呼びます。
たとえば、
「PythonでCSVファイルを読み込む方法を教えてください」
という質問に対してPythonの歴史を詳しく説明しても、内容自体が正しくてもユーザーの質問には直接答えていません。
そのため、LLM評価では、
「質問に対して必要な内容を適切に回答しているか」
を確認します。
一貫性
LLMが回答の途中で矛盾していないかを確認するのが一貫性の評価です。
たとえば、文章の前半で、
「このサービスは無料です」
と説明しているにもかかわらず、後半で、
「月額料金は1,000円です」
と説明していれば矛盾しています。
長文生成や複数ターンの会話では、このような矛盾が発生する可能性があります。
そのため、一貫した内容を維持できるかを確認することが重要です。
ハルシネーション
LLMでは、事実とは異なる情報をもっともらしく生成してしまうことがあります。
この現象はハルシネーションと呼ばれます。
たとえば、
存在しない論文を紹介する
架空のURLを提示する
存在しない法律を説明する
実際には行われていない発言を引用する
といったケースです。
ハルシネーション評価では、回答が事実として正しいかを外部の情報源などと照合します。
また、RAGを利用する場合は、単純な事実正確性だけではなく、回答が取得した文書に忠実かどうかを確認することも重要です。
このような評価はGroundednessやFaithfulnessなどと呼ばれます。
ただし、事実として正しいことと、与えられた情報源に忠実であることは必ずしも同じではありません。
そのため、RAGではFactual CorrectnessとGroundednessを分けて考えることが重要です。
安全性
LLMを実際のサービスで利用する場合、安全性の評価も欠かせません。
代表的な評価対象には、
有害なコンテンツ
危険行為への支援
違法行為への支援
差別的な出力
プライバシー侵害
セキュリティ上の悪用
などがあります。
また、安全制御を回避しようとするジェイルブレイクへの耐性を確認することもあります。
通常であれば拒否すべき要求に対して、特殊な指示を与えることで安全制御を回避できないかをテストします。
頑健性
LLMが入力の変化に対して安定した性能を維持できるかを評価するのが頑健性です。
たとえば、
「フランスの首都は？」
「フランス共和国の首都を教えて」
「Franceのcapitalは？」
のように質問の表現を変更しても、適切に「パリ」と回答できるかを確認します。
さらに、
誤字
表記揺れ
不要な情報
語順の変更
長い入力
曖昧な表現
などが含まれていても、性能を維持できるかを評価します。
より高度なテストでは、意図的に混乱させる情報や敵対的なプロンプトを入力し、モデルの弱点を調べる場合もあります。
公平性とバイアス
LLMが特定の属性に対して不適切な偏りを示さないかを確認する評価も重要です。
たとえば、性別、年齢、国籍、職業などの条件だけを変更し、回答に不合理な違いが生じないかを確認する方法があります。
ただし、属性によって回答が変化したからといって、必ずしも不適切なバイアスとは限りません。
医療や法律、制度などでは属性が回答に正当に関係するケースもあるためです。
そのため、公平性評価では、
「タスクに本来関係のない属性によって不合理な差が生じていないか」
という観点が重要です。
長文処理能力
現在のLLMでは、非常に長い文章を入力できるモデルも増えています。
そのため、長いコンテキストを正しく理解できるかも重要な評価項目です。
単に長い文章を入力できるかだけではなく、
冒頭の情報を覚えているか
途中の重要情報を見落とさないか
複数の情報を関連付けられるか
不要な情報に惑わされないか
などを評価します。
ツール利用能力
AIエージェントでは、LLM自身が外部ツールを利用する場合があります。
たとえば、
Web検索
API
データベース
コード実行環境
ファイル操作
ブラウザ操作
などです。
そのため、
適切なツールを選択できるか
正しい引数を渡せるか
ツールの結果を正しく解釈できるか
不要なツールを使っていないか
といった点も評価対象になります。
レイテンシ
実運用では、回答品質だけでなく処理速度も重要です。
ユーザーが質問してから回答が返ってくるまでの時間をレイテンシと呼びます。
非常に高性能でも、回答に時間がかかりすぎるモデルは、用途によっては使いにくい場合があります。
チャットボットやカスタマーサポートなど、即時性が重要なサービスでは特に重要です。
コスト
LLMの利用にはAPI料金やGPUなどの計算資源が必要です。
そのため、性能だけでなくコストも評価する必要があります。
たとえば、あるモデルの回答品質がわずかに高くても、別のモデルの10倍のコストがかかる場合があります。
実際のサービスでは、
品質
速度
コスト
のバランスを考えてモデルを選択することが重要です。
LLMの主なテスト方法
LLMの評価方法は一つではありません。
自動評価、人間による評価、LLMによる評価、ベンチマーク、レッドチーミング、オンライン評価などを組み合わせます。
自動評価
自動評価では、あらかじめ用意した正解データやルールを利用して、LLMの回答をプログラムで採点します。
大量のテストケースを短時間で評価できることが大きなメリットです。
一方、自由度の高い文章生成では、単純な自動評価だけでは品質を正しく判断できないことがあります。
Exact Match
Exact Matchは、生成した回答と正解文字列が一致しているかを確認する方法です。
たとえば、正解が、
「東京」
である場合、生成結果も「東京」であれば正解になります。
ただし、
「東京都」
「日本の首都は東京です」
など、意味としては正しくても文字列が異なれば不正解になる可能性があります。
実際の評価では、大文字・小文字、空白、句読点などを正規化してから比較する場合もあります。
Exact Matchは、正解が明確な短い回答や分類タスクなどに適しています。
Precision・Recall・F1
分類、情報抽出、検索などではPrecision、Recall、F1 Scoreなどが利用されます。
Precisionは、モデルが正解だと判断したもののうち、実際に正しかった割合です。
Recallは、本来見つけるべき正解のうち、どれだけ取り出せたかを表します。
F1 Scoreは、PrecisionとRecallのバランスを評価する指標です。
特に、
文章分類
固有表現抽出
情報抽出
検索
などの評価に利用されます。
質問応答でも、正解トークンとの重なりをF1で評価する場合があります。
一方、自由度の高い長文回答全体をF1だけで評価するのは適していません。
BLEU・ROUGE
自然言語生成では、BLEUやROUGEといった指標も利用されてきました。
BLEUは主に機械翻訳、ROUGEは主に文章要約の評価に使われてきた指標です。
これらは、正解文と生成文の単語やn-gramなどの重なりを利用してスコアを計算します。
ただし、意味がほぼ同じでも表現が異なると低いスコアになる可能性があります。
そのため、自由度の高いLLMの回答を評価する場合は、BLEUやROUGEだけで品質を判断するのは適切ではありません。
ルールベース評価
明確な条件がある場合は、ルールベースで評価することもできます。
たとえば、
100文字以内か
JSON形式になっているか
必須項目が含まれているか
禁止語を使用していないか
といった条件です。
指示追従や構造化出力のテストでは、非常に有効な方法です。
人間による評価
Human Evaluationでは、人間がLLMの回答を直接読んで評価します。
正確性、関連性、読みやすさ、有用性、安全性などを、一定の基準に沿って採点します。
たとえば、1〜5点で評価する方法があります。
また、
回答A
回答B
を比較し、どちらがより適切かを評価するPairwise Evaluationも利用されます。
人間による評価は柔軟性が高く、複雑な品質を判断できる点がメリットです。
一方で、
評価に時間がかかる
コストが高い
評価者によって判断が異なる
といった課題があります。
そのため、評価基準を明確にしたり、複数人で評価したりすることが重要です。
LLM-as-a-Judge
LLM-as-a-Judgeとは、別のLLMを評価者として利用する方法です。
たとえば、評価対象のモデルが生成した回答について、評価用のLLMに、
「正確性、関連性、わかりやすさを1〜5点で評価してください」
と指示します。
大量の回答を比較的低コストで評価できるため、LLMの評価手法として広く利用されています。
ただし、LLM-as-a-Judgeには注意点もあります。
評価モデル自身にもバイアスや誤りがあるためです。
たとえば、
長い回答を高く評価しやすい
回答の提示順序によって判断が変わる
特定の文章スタイルを好む
自分自身が生成した回答を高く評価する
といった傾向が生じる可能性があります。
そのため、LLM-as-a-Judgeは人間評価の完全な代替としてではなく、評価を効率化・補完する方法として利用するのが適切です。
重要な評価では、人間による確認や複数の評価方法を組み合わせることが望まれます。
ベンチマークによる評価
ベンチマーク評価とは、共通の問題セットを使って複数のLLMの性能を比較する方法です。
たとえば、
一般知識
数学
論理推論
プログラミング
科学
長文理解
安全性
などの問題を複数モデルに解かせ、スコアを比較します。
同じ問題を使うことでモデル間の性能差を比較しやすくなる点がメリットです。
ベンチマーク汚染に注意する
ベンチマーク評価では、データ汚染に注意する必要があります。
公開されているベンチマークの問題や回答がモデルの学習データに含まれていた場合、モデルが未知の問題を解いたのではなく、過去に見た内容を再現している可能性があります。
このような状態では、ベンチマークスコアがモデルの本来の一般化性能を正しく反映しない可能性があります。
対策として、新規問題や非公開問題を利用する方法などがあります。
ただし、新しい問題を使えば必ずデータ汚染を完全に防げるわけではありません。
ベンチマークの作成方法や評価条件も含めて慎重に検証する必要があります。
評価問題自体の品質も確認する
ベンチマークでは、モデルだけでなく問題側に誤りがある可能性もあります。
たとえば、
問題文が曖昧
正解データが間違っている
複数の正解が存在する
採点ルールが不適切
といったケースです。
そのため、LLMのスコアが低かった場合でも、必ずしもモデルだけに原因があるとは限りません。
高品質な評価を行うためには、評価データや採点方法そのものも検証する必要があります。
レッドチーミング
レッドチーミングとは、意図的に難しい入力や敵対的な入力を与え、LLMの弱点や安全上の問題を探す方法です。
通常のテストでは発見しにくい失敗パターンを見つけることを目的とします。
たとえば、
ジェイルブレイク
プロンプトインジェクション
矛盾した指示
悪意のある入力
極端に長い入力
安全制御の回避
などを試します。
レッドチーミングは安全性だけではなく、セキュリティ、バイアス、ツール利用、AIエージェントの挙動などを調べる際にも利用されます。
オフライン評価とオンライン評価
LLMの評価は、オフライン評価とオンライン評価に分けることもできます。
オフライン評価
オフライン評価では、あらかじめ準備したテストデータを利用してモデルを評価します。
メリットとして、
同じ条件で繰り返し評価できる
大量のテストを自動化しやすい
ユーザーに影響を与えず検証できる
といった点があります。
モデルやプロンプトを変更するたびに同じテストを実行し、品質が低下していないか確認することもできます。
オンライン評価
オンライン評価では、本番環境または本番に近い環境で実際の利用状況を測定します。
代表的な方法がA/Bテストです。
モデルAとモデルBを異なるユーザーに提供し、
ユーザー評価
タスク完了率
再質問率
回答採用率
クリック率
コンバージョン率
などを比較します。
ベンチマークでは高性能なモデルでも、実際の利用環境でユーザー体験が優れているとは限りません。
そのため、実サービスではオフライン評価とオンライン評価の両方を組み合わせることが重要です。
RAGでは検索と回答生成を分けて評価する
RAGを利用しているシステムでは、LLMだけを評価しても十分ではありません。
一般的なRAGは、
ユーザーの質問
↓
関連情報を検索
↓
検索結果をLLMに渡す
↓
回答を生成
という流れで動作します。
そのため、検索と回答生成を分けて評価する必要があります。
検索性能を評価する
検索部分では、必要な文書を正しく取得できているかを確認します。
代表的な評価項目として、
Retrieval Recall
Retrieval Precision
Context Relevance
などがあります。
必要な文書を検索できなければ、その後のLLMが高性能でも正しい回答を生成するのは難しくなります。
回答生成を評価する
LLMによる回答生成では、
Answer Correctness
Answer Relevance
Groundedness
Faithfulness
などを評価します。
回答が間違っている場合でも、
検索が失敗したのか
必要な情報は取得できていたのにLLMが誤解したのか
によって改善方法は異なります。
そのため、RAGではシステム全体のスコアだけでなく、それぞれの処理を分解して評価することが重要です。
AIエージェントでは最終回答だけでなく過程も評価する
AIエージェントでは、LLMが複数のツールを利用しながらタスクを実行します。
たとえば、
検索する
Webサイトを開く
APIを呼び出す
コードを実行する
ファイルを編集する
といった複数の処理を自律的に行うことがあります。
そのため、AIエージェントでは最終的な回答だけを評価するのでは不十分です。
ツール選択を評価する
タスクに適したツールを選択できているかを確認します。
検索すべき場面で検索を使わなかったり、不要なツールを何度も呼び出したりしていないかを評価します。
タスク完了率を評価する
AIエージェントでは、最終的にユーザーが求めたタスクを完了できたかが非常に重要です。
途中の推論や操作が一見正しくても、最終目的を達成できていなければ十分とはいえません。
エラーからの復旧を評価する
ツールの実行に失敗した場合や、予想外の結果が返ってきた場合に、適切に別の方法を試せるかも重要です。
実際の環境では常にツールが成功するとは限らないため、失敗からの復旧能力も評価対象になります。
ハーネスもLLM評価に影響する
LLMを評価するときは、モデルそのものだけでなくハーネスにも注意する必要があります。
ハーネスとは、モデルがタスクを実行するための周辺環境や仕組みを指します。
たとえば、
システムプロンプト
外部ツール
エージェントループ
メモリ
コンテキスト管理
再試行処理
エラー処理
などです。
同じLLMを利用していても、ハーネスの設計によって性能は大きく変わる可能性があります。
そのため、LLM同士の性能を比較するときは、モデル名だけでなく、
ツールの有無
トークン上限
試行回数
推論設定
利用しているプロンプト
利用可能なコンテキスト
などの条件も確認する必要があります。
Reward Hackingにも注意する
LLMやAIエージェントの評価では、Reward Hackingと呼ばれる問題が発生する場合があります。
これは、本来求められている能力を発揮するのではなく、評価ルールの弱点を利用して高いスコアを獲得してしまう現象です。
たとえばコード生成のテストで、本来の問題を正しく解決するのではなく、評価環境の弱点を利用してテストだけ通過するような挙動が考えられます。
そのため、スコアが高いからといって、本当に期待した能力を発揮しているとは限りません。
評価方法そのものに攻略可能な弱点がないかを確認することも重要です。
評価されていることを認識する問題にも注意する
LLMが、
「これはベンチマーク問題だ」
「これは安全性テストだ」
と認識し、通常利用時とは異なる振る舞いをする可能性もあります。
このような現象が起きると、テスト環境で測定した性能が実際の利用環境を正確に反映しない可能性があります。
そのため、LLM評価では、実際の利用状況に近い条件を作ることが重要です。
LLMテストでは用途に合った評価セットを作ることが重要
LLM評価で最も重要なのは、有名なベンチマークで高いスコアを取ることだけではありません。
実際のサービスで必要な能力を評価することが重要です。
たとえばECサイトの商品説明生成AIでは、一般知識のベンチマークよりも、
商品情報を捏造しない
指定文字数を守る
ブランドトーンを維持する
禁止表現を使用しない
必要なSEO情報を含める
といった条件のほうが重要になる場合があります。
カスタマーサポートAIなら、
正しいFAQを利用する
ユーザーの質問に直接回答する
誤った案内をしない
必要に応じて人間の担当者へ誘導する
といった点を評価する必要があります。
このように、LLM評価では、
「何をもって良い回答とするのか」
を最初に定義することが重要です。
LLMのテストでは複数の評価方法を組み合わせる
LLMには、すべての能力を一つの指標だけで正確に評価できる方法はありません。
そのため、実務では複数の評価方法を組み合わせるのが一般的です。
たとえば、
自動評価で大量の回答をチェックする
LLM-as-a-Judgeで品質を評価する
重要なケースを人間が確認する
本番環境でユーザー行動を確認する
といった方法です。
特に重要なのは、ベンチマークの数字そのものではなく、
想定している利用環境で、必要な能力を安定して発揮できるか
を確認することです。
LLM単体の性能だけでなく、RAG、ツール、プロンプト、ハーネス、コスト、速度なども含めて総合的に評価することで、実運用に適したLLMシステムを構築しやすくなります。
以上、LLMのテストでは何を評価するのか、主な方法についてでした。
最後までお読みいただき、ありがとうございました。
