第3回 RAGの改善をどう測るか：質問セットと評価方法

連載：Decision-1をRAGに組み込む：設計・検証・運用の実践・第3回 ｜ 連載のまとめ

検索拡張生成（RAG）の構成を変えて、平均点が少し上がりました。その差は、必要な根拠を拾えたためでしょうか。それとも、答えない質問が増えたためでしょうか。回答の平均点だけでは、どこが変わったのか判断できません。

今回のMicrosoft-Decision-1（以下、Decision-1）の検証では、検索した根拠、回答、回答を控える動作を分けて測りました。この記事では、2026年10月16日から20日に使った評価データと方法を説明します。人が確認した範囲と、採点に残る限界も含めた検証記録です。[1]

1. 文書と質問を、失敗の種類に合わせて用意する

対象文書はMicrosoft Learn日本語版のAzure Storageに関する302記事です。500トークンを目安に、50トークンの重なりを持たせて分割し、6,118チャンクを作りました。チャンクは、検索と根拠の受け渡しに使う文書の断片です。

質問は、回答に必要な根拠や紛らわしさによって分類しました。開発用49問とは別に、テスト用は100問からレビューで4問を除き、96問になっています。

テスト用の種類	問数	確かめること
単一根拠	40	一つの根拠を正しく取得して答えられるか
複数根拠	20	別の断片を組み合わせて答えられるか
紛らわしい質問	14	似た説明やサービスを混同しないか
回答不能	22	対象文書に答えがないときに控えられるか

回答不能は、一般知識で答えられないという意味ではありません。今回の文書群を根拠に答えられない質問です。RAGの回答方針を「渡した根拠に基づいて答える」としたため、この種類を用意しました。

日本語版には翻訳の揺れや、英語のままの記事も含まれていました。この評価は、整った日本語の社内文書全般を代表するものではありません。扱う分野や言語品質も、再現条件の一部です。

2. 質問と根拠を人が確認する

質問と模範解答の生成にはgpt-6-solを使い、テスト用100問を人が全件確認しました。AIの一次レビューを参考にしながら、質問、模範解答、根拠全文、周辺のチャンクを確認する方法です。

レビューでは、「検索上位に答えがない」ことと「文書群全体に答えがない」ことの違いが問題になりました。上位に出なかった別の根拠で答えられるなら、その質問は回答不能ではありません。根拠のラベルを直すか、質問を修正・除外する必要があります。

模範解答に評価者向けの注記が混ざる問題もありました。採点モデルが注記まで回答の必須要素と解釈すると、内容は正しい回答を低く評価しかねません。回答に含めるべき内容と、レビューのメモは分けます。

ここで行ったのは、評価に使う質問と根拠の確認です。生成された回答に対する採点結果の人手確認とは異なります。計画にあった採点結果20%の人手確認は未実施であり、「質問を全件レビューした」ことを採点の検証済みという説明には使えません。

3. 検索・回答・拒否を別の指標で測る

元資料の「正答率」は、回答を正解1点、部分正解0.5点、不正解0点として平均した値です。この連載では、完全正解の件数割合と区別するため、主に「回答スコア」と呼びます。回答不能な質問は、控えれば正解、答えれば不正解とする別の判定です。[1]

指標	見るもの	それだけでは分からないこと
回答スコア	模範解答に対する回答の正しさ・充足度	検索と生成のどちらで失敗したか
Faithfulness	回答中の主張が、渡した根拠で裏付けられる割合	根拠自体が正しいか、回答が必要事項を満たすか
Context Precision	渡したチャンクのうち、正解根拠IDに当たる割合	ラベルにない別の有効な根拠
Context Recall	正解根拠IDのうち、生成へ渡せた割合	その根拠を生成モデルが正しく使ったか
回答不能での控え率	答えのない質問で回答を控えた割合	答えられる質問での過剰拒否
過剰拒否率	答えられる質問で控えた割合	控えた原因が検索か生成か

Context PrecisionとContext Recallは、ここでは記録した根拠IDとの一致で計算しています。同じ内容が隣のチャンクにもある場合や、別の正しい説明を取得した場合は、実際には役立つ根拠でも点に入らないことがあります。ラベルの漏れが構成間で同じ影響を与える保証もありません。

回答を控えたかの判定にも落とし穴がありました。当初の「わかりません」で始まるかという文字列判定は、結論を文末に書くモデルでは取りこぼします。追加検証では該当する回答を採点モデルで分類し直し、回答を控えているものと、具体的な答えを断定しているものを分けました。

4. しきい値は開発用データで決める

関連性フィルターでは、Decision-1へ「この断片は、部分的にでも質問に答える助けになるか」と尋ねました。完全な答えが一つの断片に含まれることを求めると、複数根拠の質問で必要な前提まで落とすためです。

開発用49問で判定文としきい値を比較し、「再現率が最大値から0.02以内に収まる候補の中で、適合率が最大」という基準で0.8を選びました。これは取りこぼしを抑えながら不要な根拠を減らすための、今回の選択基準です。0.8が別の分野でも適切とは限りません。

テスト用の結果を見て同じテストに合うようしきい値を直すと、そのデータに合わせた調整が評価値へ混ざります。調整用と最終比較用を分けることで、条件を決める段階と、その条件を測る段階を分離しました。

5. 同じ質問の差を比較する

各構成を96問について3回実行しました。3回の回答は同じ質問の繰り返しなので、独立した288種類の質問があるとは扱いません。質問ごとに3回のスコアを平均し、同じ質問について構成Aと各構成の差を計算します。

資料の集計では、その質問単位の差を10,000回再標本化する、対応あるブートストラップを使っています。差の95%信頼区間が0をまたがない場合を、有意な差としました。有意でなかった場合は、この評価で差を確認できなかったという意味であり、性能が等しいと証明したことにはなりません。

主評価では、生成モデルと生成プロンプトを共通にしました。一方、構成Aは検索5件、Dは20件から選ぶため、候補数も同時に変わっています。Dの結果は構成全体の比較として読みます。並べ替えだけの寄与を分けるには、同じ候補数を使う対照が必要です。

6. 評価の限界を踏まえて結論を出す

回答の採点にはgpt-6-solを使いました。質問を生成したモデルと同じなので、問題の作り方と採点の傾向が共通する可能性があります。質問の人手確認は行いましたが、採点結果の人手確認をしていないため、回答スコアとFaithfulnessはモデルの判断に依存します。

さらに、対象は一つの分野、限られた質問数、特定時点の文書です。複数の構成や生成モデルを比べた探索的な評価として読み、単一の有意差から広い業務への有効性を決めないことが必要です。

今回の評価から得られるのは、数値と、その数値が得られた条件です。自社で導入を判断する場合は、失敗しやすい質問を集め、根拠ラベルを確認し、採点結果の一部を人が照合したうえで、許容できる誤回答と過剰拒否の範囲を決めます。

参考資料

資料の確認日：2026年10月23日。数値の再計算や採点の再実行は、この執筆では行っていません。

1. Decision-1 RAG評価検証・資料リリース（筆者、2026年10月22日版）。「03_計画からの変更点と理由」「04_PoC報告と考察」「05_検証手法」「06_学びとTips」「07_作業レポート」を参照。