RAGの評価データセットを作る｜答えられない質問も試験に入れる

RAGの評価データセットは、答えられる質問の正答集だけでは足りません。正答・根拠不足・曖昧質問・権限外を別の質問区分として持ち、区分ごとの期待動作と合否条件を一行に記録すると、答えるべき場面と止まるべき場面を同じ試験で判定できます。

ただし、質問と模範回答だけを並べても、検索の失敗と回答生成の失敗は見分けられません。実行できる評価セットにする条件は、「何を答えたか」に加えて、「どの根拠を取得し、利用者の権限に応じてどう振る舞ったか」を分けて採点できることです。

RAGの評価データセットは質問区分から設計する

正答例を増やすところから始めると、手元の文書に答えがない質問や、質問自体が確定していない場合まで、無理に回答を生成する前提になりがちです。評価対象を先に四つへ分けると、望ましい失敗を不正解と取り違えません。

• 正答：利用者に閲覧権限があり、承認済み文書に回答根拠がある
• 根拠不足：検索対象に、断定に必要な根拠がない
• 曖昧質問：対象、時点、手続きなどが不足し、答えを一つに定められない
• 権限外：根拠文書は存在しても、質問者に内容を開示できない

四区分を使う要点は、根拠不足と権限外を混ぜないことです。前者は知識の限界、後者はアクセス制御の境界であり、期待する応答も調査すべき原因も異なります。曖昧質問には、検索精度の改善より先に質問条件の確認が必要です。

2026年9月21日時点で、NIST AI RMF Coreは、AIシステムの知識限界と、人が出力をどう利用・監督するかの文書化を求めています。また、テストセット、指標、評価に使うツールの詳細を記録し、展開環境に近い条件で基準を測り、知識限界を超えた場合にも安全に失敗できるかを評価対象としています。その要件を業務RAGの試験へ具体化した実務上の提案が、この四区分です。NISTが定めたRAG専用スキーマではありません。

記入例：質問・根拠・権限・期待動作を一行に置く

評価台帳には、質問文に加えて、質問区分、想定利用者、期待する根拠、期待動作、合否条件を同じ行に持たせます。次の表は、社内規程を検索するRAGを想定した記入例です。実在企業の制度や特定製品から切り離し、自社の文書名と権限区分に置き換えられる条件例にしています。

台帳の「期待する根拠」には、模範回答の転記を避け、採点時に照合すべき承認済み文書と該当箇所を記録します。根拠不足の行では、根拠が存在しない状態も試験条件です。権限外の行では、検索基盤に文書があることと、質問者へ渡してよいことを切り離します。

この形なら、同じ文面の質問でも利用者の権限を変えた試験を用意できます。回答内容の一致と、入力条件に応じて回答、確認、保留、拒否のどれを選んだかを併せてレビューできます。

期待値を定める台帳と実行結果は分けて保存します。実行結果にはケースID、実行時の利用者権限、参照した文書の版、取得した箇所、最終回答、各採点面の判定を残します。質問文が同じでも文書や権限が変われば別条件です。再試験で比較できるのは、どの条件で動かしたかを固定できている場合に限られます。

正答は検索と回答を別々に採点する

正答ケースを単一の正誤欄だけで採点すると、誤答の原因が残りません。必要な文書を取得できなかったのか、取得できたのに回答へ反映できなかったのかを分けます。

2026年9月21日時点のMicrosoftによるRAG評価仕様も、最終回答を見るシステム評価と、検索文書を見るプロセス評価を分けています。評価器によって必要な入力も異なり、groundednessには回答とコンテキスト、relevanceには質問と回答、検索評価には質問とコンテキストなどを使います。さらに、回答が文脈から逸脱していないかを見るgroundednessと、正解の重要事項を欠いていないかを見るresponse completenessは別の側面です。

上の採点表はMicrosoft製品の固定スキーマではありません。この公式仕様が示す「回答と検索を別対象として扱う」という考え方を、担当者が原因を切り分けられる判定欄にした提案です。利用する評価ツールが変わっても、質問、取得コンテキスト、最終回答、期待根拠の対応を保存しておけば、どこで期待から外れたかを追えます。

答えられない質問には、それぞれ別の合格条件を置く

「回答しなかった」を一括して合格にするのも危険です。根拠不足なのに権限を理由に拒否すれば、文書整備の不足を見落とします。権限外なのに「情報が見つからない」と返せば、アクセス制御が働いたのか、単なる検索失敗なのか判断できません。

根拠不足は、断定を止められたか

検索結果が空だった場合に加え、関連文書は取得したものの、質問への断定材料が書かれていない場合も含めます。合格条件は、もっともらしい補完をしないこと、根拠不足を明示すること、許可された確認先や次の手続きを案内することです。評価台帳には「返してはいけない断定」も書いておくと、表現が違っても判定がぶれにくくなります。

曖昧質問は、必要な条件を聞き返せたか

曖昧さを推測で埋める回答を避け、回答を確定するための情報を尋ねられたかを見ます。「詳しく教えてください」だけでは、何が不足しているかが利用者に伝わりません。対象の手続き、適用時点、利用者の立場など、その質問で欠けている条件を期待動作欄に具体化します。

権限外は、内容を漏らさず境界を示せたか

拒否文に加え、検索結果と生成過程も採点対象にします。最終回答が拒否でも、制限対象の本文がモデルへ不要に渡されていないかを確認できる形にします。また、文書の存在、要約、引用断片が応答へ混ざらないことを合否条件に含めます。権限のある利用者では正答、権限のない利用者では非開示となる対のケースを置けば、知識不足との混同を避けられます。

2026年9月21日時点で、Google Cloudの生成AI運用指針は、ユースケースを反映したカスタム評価データセットに、重要なケース、平均的なケース、エッジケースを含める必要があるとしています。同指針は、機密情報の抽出や出力操作を狙うプロンプトを想定し、情報漏えいと敵対的プロンプトのテストケースも評価セットへ含めるよう示しています。特定の合否文言を指定する資料ではありませんが、通常の正答と権限境界の双方を試す根拠になります。

評価を実行できる状態にする確認表

台帳を書いた後は、モデルを動かす前に採点可能性を確認します。

• 各質問に四区分のいずれかが付いている
• 想定利用者と、その質問で適用する閲覧権限が書かれている
• 正答では期待根拠、根拠不足では根拠が足りない状態が特定されている
• 曖昧質問では回答に必要な確認事項、権限外では開示してはいけない内容が書かれている
• 検索結果と最終回答を別々に保存し、別々に判定できる
• 合否条件が、模範回答との文面一致を避け、根拠と期待動作に結び付いている

一つでも欠けるなら、実行回数を増やす前に台帳を直すべきです。特に想定利用者が空欄の権限外ケースは、何をもって非開示とするか決められません。期待根拠が曖昧な正答ケースも、検索と生成のどちらを修正すべきか判定できません。

評価設計の前に対象業務や責任者を整理する必要がある場合は、AI導入の進め方ガイドで課題定義から実装までの流れを確認できます。評価結果をPoCの判定から運用条件へ引き継ぐ観点はAI PoCを本番運用につなげる方法が参考になります。

答えない条件まで仕様にする

RAGの評価データセットを自社で実行できる条件は、質問区分、利用者の権限、期待する根拠、期待動作、合否条件が一行で対応し、検索と回答を別々に採点できることです。正答には根拠に沿った回答、根拠不足には断定の停止、曖昧質問には条件の確認、権限外には非開示という別々の合格を置きます。

最初の作業として、既存の質問を四区分へ分け、表の空欄を埋めます。正答例の追加はその後です。空欄になった「期待根拠」や「権限」が、そのまま文書整備や運用設計で先に決めるべき条件になります。自社の業務に合わせた評価台帳と導入条件を整理したい場合は、FDE型支援の無料相談・AI活用診断で、課題定義から実装、定着までを具体化できます。

FDE・AI実装ガイドへ戻る