RAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説

RAG（Retrieval-Augmented Generation）の評価でつまずきやすい原因は、モデルや検索方式だけではありません。「何を正解とし、どの失敗を検出したいか」が評価データセットに定義されていないことが、比較不能な評価につながります。

RAGは検索と生成からなるため、最終回答だけを見ても、検索が悪かったのか、取得した根拠を回答に使えていないのかを判別しにくい構造です。RAG評価では、検索モジュールと生成モジュールを分けた診断が重要であることが報告されています。RAGCheckerの原論文

本記事では、既存のRAGの基本的な仕組みやAI評価の全体設計を前提に、RAG評価データセットそのものを実務で作る手順へ絞って解説します。テンプレートと運用手順はMojiによる提案です。

結論：RAG評価データセットは「質問と正解文」だけで作らない

最小限の質問・期待回答ペアだけでも回答の正しさは見られます。しかし、RAGの改善に使うには不足しがちです。RAGASの現在の評価スキーマでも、ユーザー入力、取得コンテキスト、参照コンテキスト、生成回答、参照回答、評価基準（rubric）といった項目が扱われています。Ragas公式ドキュメント

実務では、次の二層に分けて管理すると、原因分析と再評価をしやすくなります。

ここで重要なのは、「正解の根拠」と「実際に取得された根拠」を混ぜないことです。前者だけでは検索性能を測れず、後者だけでは正しい根拠を取得できたか分かりません。

最初に決めること：評価の利用目的と失敗の定義

データ作成前に、評価結果で何を意思決定するかを一文で決めます。たとえば「検索方式AとBのどちらを採用するか」「規程改定後に回答品質が落ちていないか」「高リスク質問を人へエスカレーションできているか」です。

次に、失敗を検索・生成・プロダクト挙動へ分解します。LangSmithのRAG評価ガイドでも、回答の正確性、質問への関連性、取得文書との整合性（groundedness）、取得品質は別の観点として整理されています。LangSmith公式ドキュメント

なお、根拠に基づかないもっともらしい出力は、RAGでも重要なリスクです。背景はハルシネーションの解説も参照してください。

評価データセットの推奨スキーマ

以下は、CSV・スプレッドシート・JSONLのどれでも扱えるMojiの推奨テンプレートです。Ragasなどのツールへ渡す項目と、運用上必要な管理項目を分けています。

ポイントは、参照回答を唯一の採点基準にしないことです。表現が異なっても、必要な主張と条件を満たす回答はあり得ます。特に長文回答では、文面の一致よりも主張単位の正確性を評価対象にします。RAGCheckerは、固定チャンクを前提にした従来の検索指標には意味的な範囲を捉えにくい制約があると指摘しています。RAGCheckerの原論文

作成手順1：質問を「利用者の仕事」から収集する

質問は、文書の見出しを言い換えただけでは不十分です。ユーザーが目的達成のために投げる問いを起点にします。収集元は、匿名化・権限確認を前提として、問い合わせ履歴、検索ログ、FAQ、研修で出る質問、担当者へのヒアリング、障害・誤回答の記録です。

質問は少なくとも以下のカテゴリに層別します。

• 直接検索型：一つの規程・手順に答えがある
• 言い換え型：略称、口語、誤字、業務固有語を含む
• 条件分岐型：所属、契約、金額、地域、期限などで答えが変わる
• 複数根拠型：複数文書の条件を合わせて答える必要がある
• 否定・例外型：「できない条件」「対象外」を問う
• 回答不能型：ナレッジに根拠がなく、推測せず案内すべき
• 更新・競合型：改定前後の文書、矛盾する記述、期限切れの情報がある

評価ケースの配分は、モデル、入力品質、評価指標、許容誤差、実際の利用分布によって変わります。したがって「各カテゴリを同数にすればよい」とは限りません。高リスクだが頻度が低い質問は、利用頻度とは別枠で必ず管理する設計が実務上有効です。

作成手順2：根拠と「期待する主張」を人が確定する

各質問に対して、内容責任者または対象業務に詳しいレビュアーが、正答に必要な根拠箇所を選びます。そのうえで、回答が満たすべき主張を箇条書きにします。

以下は架空の例です。

case_id: policy-014
question: 経費精算はいつまでに申請すればよいですか？（架空の例）
reference_evidence_ids: [expense-rule-v3#sec-4, expense-rule-v3#sec-4-2]
required_claims:
  - 申請期限は利用月の翌月5営業日である
  - 海外出張には別の添付条件がある
forbidden_claims:
  - 領収書が不要である、と断定しない
abstain_policy:
  - 例外の適用可否が質問文だけで判断できない場合は、確認すべき情報を質問する

この形式なら、回答が模範文と完全一致しなくても、「期限」「例外」「不確かな場合の扱い」を含むかを評価できます。また、検索評価ではreference_evidence_idsが上位k件に入ったかを確認できます。

作成手順3：棄却・確認質問のケースを独立して作る

良いRAGは、常に回答を生成するRAGではありません。知識ベースに根拠がない、質問条件が足りない、権限外の情報を求めている場合は、回答を保留して確認・案内へ切り替える必要があります。

評価用に「答えがない質問」を混ぜる目的は、回答率を下げることではなく、根拠がないときの断定を検出することです。回答の根拠性は、回答が取得コンテキストに完全に基づいているかを見る指標であり、ワークロードに応じて他の品質指標との優先度を決める必要があります。Microsoft LearnのRAG評価ガイド

棄却ケースでは、単に期待回答を「分かりません」にしません。次のように採点条件を持たせます。

• 根拠のない固有の数値・期限・手順を作らない
• 不足している条件を明示する
• ユーザーが次に取るべき行動を案内する
• 必要な場合だけ担当窓口・一次情報へ誘導する

作成手順4：開発用・検証用・テスト用を分離する

検索チャンクの分割、埋め込みモデル、リランカー、システムプロンプトを調整しながら同じ問題を何度も見ると、その問題にだけ過適合します。開発中に使うケースと、最終比較にだけ使うケースは分けます。LangSmithのドキュメントも、未知のデータに対する性能低下を避けるため、training・validation・testの分割を挙げています。LangSmith公式ドキュメント

Mojiでは、次の運用を提案します。

1. development：原因調査と日々の改善に使う。失敗例を追加してよい。
2. validation：候補の比較と閾値調整に使う。頻繁には書き換えない。
3. test：リリース判定用。担当者を限定し、評価対象の変更に合わせて安易に編集しない。

さらに、同じ質問の言い換えを別splitへ散らさないことも重要です。質問文が違っても根拠文書・業務シナリオが同じなら、テストの独立性が弱くなります。

作成手順5：評価実行時に残すログを決める

正解データセットだけを保存しても、失敗原因は追えません。各実行で少なくとも質問、取得文書ID・順位・本文、最終回答、モデル名、プロンプト版、埋め込みモデル、リランカー、インデックス版、実行日時を残します。

Ragasの単一ターン用スキーマでは、user_input、retrieved_contexts、response、reference、reference_contextsなどを扱えます。まずはこの入出力を再現可能な形で出力することが、ツール選定より先です。Ragas公式スキーマ

品質確認：公開前に行う5つのチェック

1. 根拠妥当性：質問に対する正解根拠は本当に十分か。改定済み・失効済みの文書を含めていないか。
2. 主張完全性：期待する主張に、条件・例外・単位・期限が抜けていないか。
3. 質問自然性：見出しのコピーではなく、利用者が実際に使う語彙・省略・曖昧さを含むか。
4. ラベル一貫性：同じ「関連」「合格」「棄却」の基準で、複数人が判断できるルーブリックになっているか。
5. 情報管理：不要な個人情報、認証情報、契約上共有できない本文を評価データや外部評価基盤へ入れていないか。

評価者が複数いる場合は、最初から全件を分担するのではなく、一部を重複採点して基準のズレを確認します。意見が割れたケースは「どちらが正しいか」だけで終わらせず、ルーブリックに条件を追加して再利用できる知識にします。

指標は「全体平均」ではなく、失敗分類ごとに見る

一般的な設計上の目安として、検索側では根拠取得率・上位k件の関連性、生成側では根拠性・正確性・完全性・質問への適合性、プロダクト側では棄却の適切さ・引用表示・レイテンシを分けます。RAGASは、コンテキストの関連性、回答の根拠性、回答の関連性など複数次元を評価対象として提示しています。RAGAS原論文

合格ラインを単一スコアで固定するのは避けます。モデル、入力文書の品質、質問カテゴリ、評価器、許容できる誤差、業務リスクによって妥当な水準は変わるためです。LLMを評価器に使う場合も、出力には非決定性があるため、単一点ではなく許容範囲で評価する考え方が示されています。Microsoft LearnのRAG評価ガイド

継続更新の運用テンプレート

評価データセットは一度作って終わりではありません。ナレッジの改定、利用者の質問変化、検索方式・モデル変更により、正解根拠や重要ケースは変わります。

更新時は、ケースを上書きするだけでなく、データセット版・知識スナップショット・評価コード版・モデル設定をセットで記録します。これにより「回答品質が変わった」のか、「評価対象の文書が変わった」のかを区別できます。

リリース前チェックリスト

• 評価の意思決定目的が一文で説明できる
• 質問が実利用のカテゴリと高リスクカテゴリを含む
• 各ケースに根拠箇所と必要主張が付いている
• 回答不能・条件不足・更新競合のケースがある
• development、validation、testの用途が分かれている
• 検索結果と生成回答を実行ログとして保存できる
• 全体平均だけでなくカテゴリ別・失敗別に集計できる
• 文書改定と障害発生時の更新担当者が決まっている
• 個人情報・機密情報の取り扱いを確認している
• データセット、ナレッジ、プロンプト、モデルの各版を記録している

まとめ

RAG評価データセットは、質問と模範回答を集める作業ではありません。質問、正解根拠、必須主張、回答してはいけない条件、棄却方針、知識の時点、実行ログをつなぎ、検索と生成のどちらを直すべきか判断できる状態を作る作業です。

まずは、業務上重要な質問から小さく始め、検索漏れ・根拠逸脱・回答不足・不適切な断定をそれぞれ検出できるケースを作成してください。その後、実際の失敗を評価ケースへ戻し続けることで、RAGの改善を「印象」ではなく再現可能な比較に変えられます。