meguli
業務効率化読了 約11分

LLM RAGの回答精度をどう測る?検索・生成を分けた評価方法

LLM RAGの回答精度は、検索結果の妥当性と生成回答の正確さを分けて評価します。質問・正解データの準備から、検索漏れや根拠の読み違いの切り分け、改善後の再評価まで解説します。

こんにちは、平岡です。弊社では、LLM RAGの回答精度を評価するとき、まず検索と生成を分けて確認します。検索結果に必要な資料がなければ、LLMが正しい回答を作るのは難しくなります。一方、資料が検索できていても、回答に反映されなかったり、資料にない内容が加わったりすることがあります。検索結果の妥当性と、根拠に沿った生成回答の正確さを別々に測ることが、原因を見つける出発点です。

LLM RAGの回答精度は検索と生成に分けて見る

評価を二段階で考える

RAGは、外部の情報を検索し、その情報を使ってLLMが回答を生成する仕組みです。評価では、検索した資料が質問に合っているかと、その資料を使った回答が正確かを分けて見ます。回答だけを採点すると、検索漏れなのか、根拠の読み違いなのかを判別しにくくなります。

Microsoft Foundryでは、検索工程の評価として「Retrieval」「Document Retrieval」、最終回答の評価として「Groundedness」「Relevance」「Response Completeness」を別の対象にしています。評価結果も工程ごとに見れば、検索設定を見直すべきか、回答の作り方を見直すべきか判断しやすくなります。

評価の基本

検索結果には、質問に必要な情報があるかを確認します。回答には、その情報に沿っているか、質問への答えが含まれているかを確認します。回答の点数だけで、RAG全体の原因を決めないことがポイントです。

RAGとLLMで評価する対象

RAGの評価対象

評価の流れは「質問」「検索結果」「生成回答」の3つに分けると整理しやすくなります。質問に対してどの資料が取得され、その情報が回答にどう使われたかを順にたどります。

  • 質問:実際に利用者が入力する内容
  • 検索結果:質問に対して取得された資料やチャンク
  • 生成回答:検索結果をもとにLLMが作成した文章

Microsoft Foundryの評価データ例では、query、context、responseを持たせます。複数のチャンクを使う場合、contextには区切り文字を挟んで連結できます。この形なら、どの質問に対して何を検索し、その結果から何を回答したかを一緒に見直せます。

回答だけで判定しない

回答に誤りがあったら、まず検索結果を見ます。必要な資料がない場合と、資料はあるのに回答が誤っている場合では、直す場所が異なります。

評価用の質問と正解データを準備する

評価データの準備

評価データは、実際の利用場面に近い質問から作ります。営業担当が社内の商品資料を調べるなら、商品名や条件を含む質問を選び、参照すべき資料と期待する回答を紐づけます。回答が一通りに決まらない質問では、必須の情報と許容できる言い換えを先に決めておくと採点がぶれにくくなります。

Microsoft FoundryのDocument Retrieval評価では、正解データにretrieval_ground_truthを指定します。ここには文書IDと質問関連度ラベルを持たせ、retrieved_documentsには検索文書IDと関連度スコアを持たせます。検索結果の評価に使う情報と、回答の評価に使う情報を混ぜずに準備するのが実務上の要点です。

query:評価対象の質問
context:検索された資料・チャンク(複数は区切り文字で連結可能)
response:生成された回答
retrieval_ground_truth:正解となる文書IDと質問関連度ラベル
retrieved_documents:検索文書IDと関連度スコア

質問の種類を整理する

質問データが特定の形に偏らないよう、答えに必要な情報の数や質問の抽象度を分けます。Ragasは質問の種類として、単一文書などから答える「Single-Hop」と、複数の情報源を結び付ける「Multi-Hop」を区別し、それぞれに「Specific」と「Abstract」の例を示しています。

  • 単純な事実確認:1つの資料から答えられるか
  • 複数資料を参照する質問:情報源をまたいで答える必要があるか
  • 資料に答えがない質問:根拠がないときに無理に回答しないか
  • Specific/Abstractの質問:具体的な情報を尋ねる質問と、抽象度のある質問の両方が含まれているか

資料に答えがない質問では、期待する回答を事実の説明ではなく「資料から判断できない」といった扱いに定める方法があります。質問の種類ごとに件数を並べてみれば、たとえば事実確認ばかりで複数資料を使う質問が不足している、といった評価データの偏りにも気づけます。

検索結果の妥当性を評価する

検索の評価観点

検索結果では、質問に答えるための資料が含まれているか、重要な根拠が上位にあるか、関係のない資料が混ざっていないかを見ます。回答の出来ばえではなく、LLMに渡された情報が質問に合っているかを評価する段階です。

Microsoft Foundryの「Document Retrieval」は、正解ラベルと検索文書を比較し、Fidelity、NDCG、XDCG、Max Relevance、Holesを算出します。正解ラベルが用意できない場合、同じく「Retrieval」評価で、質問に対する取得コンテキストの関連性をLLMが判定し、1〜5段階のスコアで評価できます。正解データの有無に応じて評価方法を選ぶ形です。

検索設定を比較するときは、検索アルゴリズムのvectorとsemantic、top_k、チャンクサイズを変えて検索結果を作り、Document Retrievalで比較する方法がMicrosoftのRAG評価ガイドに記載されています。一度に複数条件を変えると違いの理由を追いにくいため、比較する条件を絞って評価データにかけると判断しやすくなります。

検索側の判定

必要な資料が検索結果にないなら、検索側の問題として記録します。資料は含まれているが順位が低い場合も、回答の正確さとは分けて扱います。

生成回答の正確さと根拠を確認する

回答の評価観点

回答では、参照資料と内容が一致しているか、質問に必要な情報が含まれているか、資料にない説明を加えていないかを確認します。Microsoft Foundryの「Groundedness」は、回答がコンテキストに沿い、捏造を含まないかを測る評価です。推奨入力はquery、response、contextの3項目です。

Ragasの「Faithfulness」は、回答中の主張のうち、取得コンテキストで裏付けられる主張の割合を0〜1で評価します。「Context Recall」は、正解回答の主張のうち取得コンテキストで裏付けられる割合を測る指標で、比較用の参照情報が必要です。RagasのRAG向け指標一覧には、ほかに「Context Precision」「Response Relevancy」も掲載されています。

Microsoft Foundryの標準評価例では、Groundednessなどのスコアは1〜5で、既定の合格しきい値は3です。3以上は合格として扱われますが、自社の質問で何を合格とするかは、評価データと実際に必要な回答品質を見て決めます。

  • 資料との一致:回答の各主張がコンテキストに沿っているか
  • 必要事項の充足:質問への回答に必要な情報が抜けていないか
  • 根拠外の説明:資料にない内容を事実のように加えていないか
  • 回答できない質問:資料に根拠がない場合、期待どおりの扱いになっているか

検索と生成を切り分けて原因を探る

原因の切り分け

回答に誤りがあった場合は、検索結果に必要な資料が含まれていたかを先に見ます。資料が見つかっていなければ検索漏れ、資料はあるのに回答が違えば、根拠の読み違いや回答への反映不足が候補になります。

たとえば、社内資料を参照して答える質問で、回答の条件が資料と異なっていたとします。検索結果に該当資料がなければ検索側の課題です。該当資料が含まれているのに別の条件を回答したなら、資料の解釈か回答への反映を調べます。検索結果と回答を順に並べることで、修正対象を一段ずつ絞れます。

  • 検索結果に必要な資料がない:検索漏れとして記録
  • 資料はあるが根拠と回答が食い違う:読み違い・反映の問題として記録
  • 根拠の内容は正しいが必要事項が抜ける:回答の不足として記録
調査の順序

質問、検索結果、回答をこの順に見比べます。最初に誤りが現れた段階を問題箇所として記録すれば、検索側と生成側の改善が混ざりにくくなります。

評価結果を改善と継続確認につなげる

評価の活用

評価で見つけた問題は、検索側・生成側に分けて記録します。検索条件や回答方法を変更したら、同じ質問と参照資料で再評価し、点数だけでなく誤りの内容も比較します。質問や参照資料を更新したときも、以前の評価データに影響がないか確認する流れを用意します。

LangSmithは、代表的な入力と正解出力を含むデータセットで複数バージョンを比べるベンチマーク、変更による性能低下を調べる回帰テスト、本番ログを使うバックテストを説明しています。評価を一度きりにせず、変更前後を同じデータで比べる運用に活用できます。

評価条件をそろえる

MicrosoftのRAG評価ガイドは、実験で選んだハイパーパラメーターと評価指標を記録し、埋め込み・検索などの粒度とシステム全体の粒度で結果を残すよう説明しています。検索アルゴリズム、top_k、チャンクサイズを変えて比べた場合は、どの条件の結果なのかを評価記録に残します。

評価データの版:
検索アルゴリズム:vector / semantic
ハイパーパラメーター:top_k、チャンクサイズなど
評価指標:
記録する粒度:埋め込み・検索など / システム全体
変更内容:

LLMの応答は非決定的で、同じプロンプトでも異なる結果になり得ます。Microsoftのガイドでは、評価目標を単一の値ではなく範囲にする方法も挙げています。1回の評価結果だけで結論を固定せず、条件と結果をセットで見比べるのが現実的です。

まとめ

LLM RAGの回答精度は、検索結果の妥当性と生成回答の正確さを分けて評価します。質問・検索結果・回答を順にたどれば、検索漏れ、根拠の読み違い、回答の不足を切り分けやすくなります。次の一歩は、実際の質問から評価用データを作り、検索結果と回答を別々に確認することです。

参考・出典

この記事をシェア
𝕏 でポストB! はてブ
m
株式会社meguli

AI×DXで、社会の巡りをよくする。中小企業の現場で使えるAI活用・業務改善の実践情報を発信しています。

ご相談・お問い合わせはこちら →

あわせて読みたい