RAGの評価 — どこが悪いのかを切り分けて測る

RAG の改善が難航する最大の理由は、何が悪いのか分からないまま手を打っていることです。チャンクサイズを変え、リランカを入れ、プロンプトを直し、「前より良くなった気がする」で止まる。この状態から抜け出す唯一の方法が評価の仕組みです。

そして評価設計の要点はただ1つ、検索と生成を分けて測ることです。

横にスクロール

なぜ分けないといけないのか

RAG は2段のパイプラインです。

質問 → [検索] → 文書 → [生成] → 回答

最終回答だけを見て「50点」と分かっても、次にどこを直せばいいか決まりません。検索が正解を引けていないのか、正解を引けているのに生成が活かせていないのか。この2つは対処がまったく違います。

検索が失敗している
  → チャンク設計、ハイブリッド検索、クエリ変換、リランキング

生成が失敗している
  → プロンプト、文脈の並べ方、渡す件数、モデルの選択

分けずに測ると、検索が原因なのにプロンプトを延々といじる、という無駄が生まれます。

検索側の指標

recall@k（再現率）が最重要です。「正解を含む文書が、上位k件の中に入っている割合」を測ります。

recall@k = (上位k件に正解文書が含まれた質問の数) / (全質問数)

なぜ最重要かというと、これが全体の上限を決めるからです。recall@10 が 60% なら、10件を渡す構成でどれだけ生成を頑張っても、40% の質問には正解の情報が届いていません。リランカもプロンプトも、その40%を救えません。

k を変えて測ると、リランキングの1段目で何件取るべきかも決まります。

recall@5  = 55%
recall@10 = 68%
recall@20 = 79%
recall@50 = 84%
recall@100 = 85%   ← 50から先はほぼ増えない

→ 1段目は50件で十分。100件にするコストは無駄

補助的に MRR（正解が何位に来たかの逆数の平均）や nDCG（順位を考慮した利得）を見ると、順位の良し悪しが分かります。recall@k が高いのに MRR が低いなら、候補には入っているが順位が悪い——リランキングが効く典型的な状態です。

生成側の指標

生成側は、性質の違う2つを分けて測ります。

忠実性（faithfulness） は「回答の各主張が、渡した文書から裏付けられるか」です。これが低いのは幻覚で、文書に書いていないことを言っています。信頼性の観点では最も重大な失敗です。

回答関連性（answer relevance） は「回答が質問に答えているか」です。これが低いのは的外れで、文書に忠実だが聞かれたことに答えていない状態です。

忠実性 高 × 関連性 高  → 良い回答
忠実性 高 × 関連性 低  → 文書の内容を正しく述べているが、質問に答えていない
忠実性 低 × 関連性 高  → もっともらしく答えているが、根拠が無い（最も危険）
忠実性 低 × 関連性 低  → 全面的に失敗

忠実性が低く関連性が高い組み合わせが最も危険です。ユーザーから見て良い回答に見えるのに、根拠が無い。出典付きで表示していると、余計に信じられてしまいます。

さらに文脈精度（context precision）——渡した文書のうち実際に使われた割合——を見ると、無駄に多く渡していないかが分かります。これが低いなら文脈圧縮や件数の削減が効きます。

誰が採点するか

検索の指標は正解文書IDと突き合わせるだけなので機械的に測れますが、生成の指標は判断が要ります。実務では LLM-as-a-judge（LLMに採点させる）が現実解です。

忠実性なら「回答を主張の単位に分解し、それぞれが渡した文書から裏付けられるかを判定させる」という形にします。一括で「0〜10点」と聞くより、分解して個別に判定させるほうが安定します。

回帰を検知する仕組みにする

評価は一度きりの測定ではなく、変更のたびに回すものとして組みます。

変更前後で必ず比較する
  recall@k       … 検索の改善は本当に改善か
  忠実性・関連性 … 生成が悪化していないか
  レイテンシ     … 精度と引き換えに体感を壊していないか
  コスト         … 1質問あたりの呼び出し回数とトークン

最後の2行を忘れがちです。クエリ変換や自己改善型RAGは精度を上げますが、LLM呼び出しが増えます。精度が3ポイント上がってレイテンシが3倍になった変更は、多くの場面で採用すべきではありません。4つを並べて初めて意思決定ができます。

そして失敗した質問は必ず個別に読むことです。集計値は方向を教えてくれますが、原因は教えてくれません。recall が落ちた質問を10件読めば、たいてい共通のパターンが見つかります——「表形式の文書で落ちている」「略語のクエリで落ちている」といった発見は、集計値を眺めていても出てきません。

まとめ

• 評価設計の中心は検索と生成を分けて測ること。最終回答だけでは次に何を直すか決まらない。
• 検索側は recall@k が最重要。これが全体の上限を決め、ここが低ければリランカもプロンプトも効かない。k を変えて測れば1段目の取得件数も決まる。
• recall@k は高いのに MRR が低いなら、候補には入っているが順位が悪い＝リランキングが効く状態。
• 生成側は忠実性（文書に基づくか）と回答関連性（質問に答えているか）を分ける。忠実性が低く関連性が高い組み合わせが最も危険。
• LLM採点には長さ・順序・自己選好の偏りがある。人手採点と突き合わせて採点器自体を検証する。
• 変更のたびに精度・レイテンシ・コストを並べて判断する。そして失敗した質問は個別に読む——集計値は原因を教えてくれない。
• ゴールデンセットは50件でも意味がある。完璧を目指して着手しないほうが損失が大きい。