RAGの検索品質が本当に改善したか、どう測ればいい？

1分要約

• 検索と回答生成は分けて評価する。総合点だけでは、どこが壊れたか分からない。
• 網羅性は Recall@k、最初の有用な結果は MRR、関連度に段階があり順位も重要なら nDCG@k を使う。
• 質問と関連度ラベルをバージョン管理し、すべての検索変更を固定ベースラインと比較する。平均値だけでなく質問タイプ別にも見る。

どんな人向けか

• RAGのチャンク、埋め込み、フィルタ、ハイブリッド検索、reranker、top-k を調整するチーム
• 数件の回答を目視する運用から、再現できるリリースゲートへ進みたいエンジニア
• 検索の失敗と、プロンプトやモデルの失敗を切り分けたいプロダクトチーム

結論

評価を2層に分ける。

1. 検索評価: 正しい根拠を見つけ、十分に上位へ並べられたか
2. 回答評価: 取得した根拠を使い、正確・完全で、根拠のない主張を含まない回答を作れたか

検索評価の最小セットは Recall@k、MRR、nDCG@k。1つの指標だけでは足りない。Recallを上げても、弱いチャンクがコンテキストを埋めれば回答は悪化する。MRRが高くても、複数文書が必要な質問では根拠が欠けることがある。nDCGは関連度の段階と順位を見られるが、ラベルが不正確なら数値も不正確になる。

絶対値で「0.8なら合格」と決めず、固定ベースラインと候補設定を同じ条件で比較する。

解説

検索と回答生成では壊れ方が違う

誤答の原因は少なくとも3つある。

• インデックスに使える根拠がない
• retrieverが根拠を取得できない、または上位へ並べられない
• モデルは正しい根拠を受け取ったが、回答に使えない

end-to-endのjudgeスコアだけでは原因が隠れる。同じ質問を通常の取得コンテキストと、正解の根拠を入れた oracle context で実行する。oracleなら成功し、通常検索だけ失敗するなら、検索かコンテキスト組み立てを直す。両方失敗するなら、プロンプト、モデル、採点方法を調べる。

主要な検索指標は何を表すか

Recall@k は、既知の関連文書・チャンクのうち、上位 k 件に入った割合。根拠の取りこぼしが回答の欠落につながる場合に使う。

MRR（Mean Reciprocal Rank） は、最初の関連結果の順位について 1 / 順位 を計算し、質問全体で平均する。単一回答の検索など、最初の強い結果が重要な場合に向く。

nDCG@k（Normalized Discounted Cumulative Gain） は、関連度の高い結果が上位にあるほど高くなり、理想的な並び順と比較する。関連度を次のように段階評価するときに使いやすい。

• 3: 質問へ直接答える
• 2: 有用な補助根拠
• 1: 関連はあるが不十分
• 0: 無関係

コンテキストのノイズが高コストなら、Precision@k や無関係チャンク率も測る。大量に返せばRecallは上がりやすいが、良い検索とは限らない。

指標を計算する前に評価単位を決める

関連度ラベルを文書、セクション、チャンクのどれに付けるか決める。チャンク境界を変えたのに古いchunk IDを使い続けると、評価セットが壊れる。安定したsource IDと根拠箇所の引用を保存しておくと、再インデックス後もラベルを移しやすい。

ユーザーまで届く各段階を測る。

• rerank前の候補、たとえば上位50件
• rerank後、たとえば上位10件
• モデルへ渡す最終コンテキスト、たとえば4チャンク

これで、rerankerが順位を改善したのか、その後のcontext assemblyで良い根拠を落としたのか分かる。

実務ガイド

Step 1: 質問タイプと失敗コストを分ける

平均を取る前に質問を分類する。

• 単純な事実確認
• 複数文書の統合
• ID、エラーコード、製品名などの厳密一致
• 言い換えや曖昧な質問
• 正解が存在しない質問
• 権限に依存する質問

全体平均が良くても、件数の少ない高リスク領域が全滅していることはある。

Step 2: ラベル付き評価セットを作る

まず30〜100件の代表的な質問を集める。実際の質問、既知の失敗、少数の攻撃的ケースを混ぜる。

判断を再現できる情報を保存する。

{
  "query_id": "billing-017",
  "query": "年間プランはいつ返金できますか？",
  "segment": "policy_lookup",
  "relevance": {
    "refund-policy#annual-plans": 3,
    "billing-faq#cancellations": 2
  },
  "must_not_retrieve": ["tenant-b-private-policy"]
}

曖昧なラベルは業務担当者が確認する。権限が重要なシステムでは、関連文書だけでなく「取得してはいけない文書」も記録する。

Step 3: ベースラインを固定する

検索結果を変える設定をすべて記録する。

• corpus snapshotとindex version
• chunkingルール
• embedding model
• keyword・vector・hybridの重み
• metadata filters
• reranker modelと候補数
• 最終contextの上限

このスナップショットがないと、指標が変わった理由を説明・再現できない。

Step 4: 固定したcutoffで指標を計算する

実際のパイプラインに合わせ、k = 5、10、50 などを選ぶ。最低限、次を出す。

• 根拠の網羅性を見る Recall@k
• 最初の関連結果を見る MRR
• 段階的な関連度と順位を見る nDCG@k
• ノイズを見る無関係チャンク率または Precision@k
• 認可回帰を見る禁止文書の取得件数

ベースラインと候補で、質問、ラベル、cutoffを変えない。

Step 5: 最終回答を別に評価する

質問ごとに次を保存する。

• 取得したchunk IDとスコア
• モデルへ渡した最終チャンク
• 生成した回答
• 引用したchunk ID
• レイテンシとコスト

そのうえでgroundedness、回答の関連性、completenessを採点する。必須ID、日付、引用の有無、アクセス規則は決定的なチェックを使う。意味的な品質には、固定rubricによる人手評価またはLLM judgeを使う。

Step 6: oracle contextテストを実行する

取得コンテキストを既知の正解根拠へ置き換え、もう一度回答を生成する。

• 通常は失敗、oracleは成功: 検索またはcontext assemblyの問題
• 両方失敗: 回答生成、プロンプト、採点の問題
• 通常は成功、検索指標は低い: ラベル誤りや回答への情報漏れを疑う

曖昧な「RAG品質」の問題を、直せる単位へ絞り込める。

Step 7: 質問タイプ別に回帰ゲートを置く

ベースライン相対の条件を使う。

• 禁止文書の取得は0件
• 規約・安全系のRecall@10を落とさない
• 全体のnDCG@10を大きく悪化させない
• P95レイテンシとコストを合意した予算内に保つ
• 新しく失敗した質問はすべて確認する

集計値と質問単位の差分を両方残す。原因を説明するのは差分の方。

Step 8: 本番の失敗で評価セットを更新する

本番で見つかった失敗、低信頼の回答、引用への苦情、no-answerの誤判定を評価セットへ追加する。長期比較用の固定コアは残し、新しい挙動やドリフトを見る追加セットを回す。

ありがちな落とし穴

• 最終回答だけを評価し、検索失敗のシグナルを失う
• テスト質問をすべて合成し、実際の言い回しを逃す
• 複数文書が必要なのに、関連チャンクを1つだけ正解にする
• chunk IDを変えたのに関連度ラベルを移行しない
• Recall@kを上げるために弱い一致を大量投入する
• 全体平均で権限・no-answer領域の失敗を隠す
• 実行ごとにjudge promptを変える
• テストセットへ過剰適合するまで調整する
• 異なる検索システムのsimilarity scoreを直接比較する
• 関連度だけを見て、index freshness、遅延、コストを無視する

チェックリスト

• [ ] 検索と回答生成を分けて評価している
• [ ] 評価セットに実際の言い回しと既知の失敗がある
• [ ] 質問をタスクとリスクで分類している
• [ ] 根拠に安定したsource IDまたは引用箇所がある
• [ ] 必要に応じて関連度を段階評価している
• [ ] 複数文書の質問では必要な根拠をすべてラベル付けした
• [ ] no-answerと権限依存ケースがある
• [ ] corpus、index、chunking、embedding、filter、rerankerをversion管理している
• [ ] パイプラインに合うcutoffで Recall@k を測っている
• [ ] MRR で最初の有用な結果を追っている
• [ ] nDCG@k で関連度と順位を追っている
• [ ] Precisionまたは無関係チャンク率でノイズを追っている
• [ ] 禁止文書の取得をゼロ許容の指標にしている
• [ ] 最終回答のgroundednessとcompletenessを確認している
• [ ] oracle contextで検索失敗と回答失敗を切り分けている
• [ ] 同じケースと固定ベースラインでリリース判定している
• [ ] 集計値だけでなく質問単位の回帰を確認している
• [ ] 本番の失敗をversion管理された追加セットへ入れている

FAQ

1. RAG検索の主指標はどれにすべき？

用途に合わせる。根拠の網羅性ならRecall@k、最初の回答候補が重要ならMRR、段階的な関連度と順位を見るならnDCG。多くの本番RAGでは、網羅性の指標と順位の指標を最低1つずつ使う。

2. kはいくつにすべき？

実際のパイプラインに合わせる。候補を50件取得し、10件へrerankし、4チャンクをモデルへ渡すなら、そのcutoffを測る。Recall@100だけが高くても、最終コンテキストが悪ければ意味がない。

3. LLM judgeで関連度ラベルを代用できる？

ラベル作成を速め、正解データがない領域を補える。ただし判断の一部は人が確認する。回帰ゲートには、小さくても信頼できるラベル付きコアを残す。

4. 評価セットは何件必要？

まず30〜100件の代表ケースから始め、本番の失敗で増やす。似た質問を大量に集めるより、質問タイプを広くカバーする方が重要。

参考資料

• AI Searchの検索品質評価（Microsoft Learn）
• RAG評価：検索・groundedness・関連性・完全性（Microsoft Learn）
• RAGAS: Automated Evaluation of Retrieval Augmented Generation（EACL 2024）
• Evaluation in information retrieval（Stanford IR book）

内部リンク

• 親記事: AI開発：まずはここから
• 関連:
  • RAGのハイブリッド検索とリランキング設計
  • RAGのチャンク分割とインデックス設計
  • LLM評価と回帰テスト

免責

一般的なエンジニアリング指針です。評価ルールは、自社データ、アクセスモデル、リスク要件に合わせて検証してください。