RAG検索評価の極意：4大指標とデータセット選定で陥る罠をシニアエンジニアが徹底解説

「テスト環境では完璧に動いていたのに、本番リリース後にユーザーから『全く役に立たない』とクレームが殺到する」――これはRAG（Retrieval-Augmented Generation）を開発するエンジニアにとって、最も恐ろしいデッドロックの瞬間である。我々開発者は、手元の数件のクエリで「それらしい回答」が得られただけで満足し、パイプラインを本番にデプロイしてしまいがちだ。しかし、これは暗闇の中で目隠しをしてF1カーを運転するようなものである。RAGのシステムは、検索（Retrieval）と生成（Generation）という、全く異なる二つのギアが噛み合うことで駆動している。最終的な回答が破綻しているとき、その原因は「LLMがコンテキストを理解できなかった（生成の失敗）」のか、それとも「そもそも必要な情報がLLMに渡されていなかった（検索の失敗）」のか。この切り分けができていない開発現場は、深夜の障害対応でスパゲッティコードをこねくり回すような、不毛な泥沼に陥ることになる。

私はシニアエンジニアとして、そしてITジャーナリストとして、多くのプロジェクトがこの「評価の不在」によって自滅していく姿を見てきた。RAGの品質向上における一丁目一番地は、LLMのプロンプト調整ではなく、その前段階である「検索品質の定量評価」に他ならない。検索品質はRAG全体の品質を支える重要な基礎であり、ここが腐っていれば、どんなに優秀なLLM（GPT-4やClaude 3.5）を使おうとも、ハルシネーション（嘘の生成）という名のバグを誘発するだけなのだ。必要な根拠（chunk）を検索段階で100%取得できなければ、LLMがその根拠に基づく正しい回答を生成することは困難極まりない。我々はまず、この「検索品質」を客観的な数値で測る術を身につけなければならない。

検索品質を評価するために、RAG専用の新しい車輪を再発明する必要はない。情報検索（Information Retrieval）の分野で長年培われてきた伝統的な指標であるRecall@k、MRR@k、nDCG@k、MAP@kこそが、我々の強力な武器となる。しかし、これらの指標を「なんとなく」使っていては、システムの真のボトルネックを見誤る。

まず、網羅性を担保する「Recall@k」は、LLMに渡す上位k件のコンテキストに正解が含まれているかを測る。初期検索（リトリーバル）の段階で、例えばRecall@50を高く保ち、その後のリランカー（Reranker）で絞り込むといった二段階構成において、Recallは極めて有効な指標となる。しかし、Recallは「順位を考慮しない」という致命的な弱点を持つ。1位に正解があろうが、50位にギリギリ滑り込もうがスコアは同じなのだ。そこで登場するのが、最初の正解の順位のみに執着する「MRR@k（Mean Reciprocal Rank）」である。これはFAQ検索のように「1つの正しい答えに最速で到達させたい」ユースケースに最適だ。しかし、複雑な社内文書から複数の根拠をかき集める必要があるRAGにおいては、2件目以降の正解を無視するMRRだけでは不完全である。

複数の正解を評価し、かつその重要度（関連度）にグラデーションをつけたい場合に真価を発揮するのが「nDCG@k（normalized Discounted Cumulative Gain）」だ。これは、より重要な情報が上位に配置されているかを対数割引を用いて厳密に評価する、最も美しい指標である。ただし、これを使うには「多段階の関連度ラベル」を人手で作成するという、開発者にとって地獄のようなアノテーションコストが伴う。現実的な妥協点として、正解・不正解の二値評価でありながら、複数の正解がまんべんなく上位にあるかを測る「MAP@k（Mean Average Precision at k）」が、多くのRAG開発現場で現実的な解となるだろう。以下に、これら4つの指標の特性と、RAG開発における適用シーンを整理した。

指標が決まっても、評価に使う「データセット」の選定を誤れば、すべての計算は無意味なノイズと化す。MS MARCOやBEIR、日本語であればJQaRAといった公開データセットは、モデルのベースライン評価には有用だが、これをそのまま自社のビジネスドメインに適用するのは危険極まりない。

日本国内のエンタープライズRAGの動向に目を向けると、株式会社ラックが提唱する「社内規程集を対象とした生成AIのRAG評価プロセス」や、ソフトバンクが実践する「Vertex AIを活用したRAGとファインチューニングの統合的アプローチ」など、極めて実践的な取り組みが始まっている。ラックの事例では、社内規程という極めて厳密な文書群に対し、どのようなクエリを投げ、どの段落が正解（qrels）であるかを定義するプロセスが詳細に検証されている。社内規程RAGにおいては、「第3条の第2項」といったピンポイントな情報が正解となるため、一般的なWeb検索用のデータセットでチューニングされた検索エンジンでは、全く歯が立たない。また、ソフトバンクの挑戦が示すように、検索（RAG）の評価と、LLMのファインチューニング（FT）は表裏一体である。検索品質の評価指標（例えばnDCG@k）が低い状態でLLMをファインチューニングしても、モデルは「存在しない情報から回答を捏造する」訓練を積むことになり、結果としてハルシネーションを悪化させる。

我々が実務で直面するのは、公開データセットのような「綺麗に整備されたqrels（正解表）」が存在しないという現実だ。社内のPDFやWordから抽出したノイズだらけのcorpusに対し、誰が正解ラベルを貼るのか。このアノテーションコストを削減するために、LLMを用いて擬似的なクエリと正解ペアを自動生成する手法（LLM-as-a-Generator）も注目されているが、その生成されたデータセット自体の品質評価という、新たな無限ループが待ち受けている。正解として登録されていない文書が、実はユーザーにとって有益な「隠れた正解」である可能性を、我々は常に考慮しなければならない。

「完璧な評価データセットができるまで、開発を止めるべきか？」――否、我々エンジニアが明日から取るべき実践的な処方箋は、アジャイルな「ゴールデンデータセット」の構築である。まずは、本番環境で想定される代表的なユーザーの質問（クエリ）を、開発メンバーやドメインエキスパートの手で「最低50件、できれば100件」泥臭く洗い出すことだ。検算可能な正解を定義し、それぞれのクエリに対して「絶対にLLMに渡さなければならない社内文書のchunk」を、手動でqrelsとして紐付ける。この「最小構成のゴールデンデータセット」を作成することが、すべてのスタートラインとなる。

このデータセットを用いて、まずはRecall@5とMRR@5を計測する。これが0.8を下回るようであれば、ベクトル検索の埋め込みモデル（Embedding）の選定、チャンクサイズ（Chunking Strategy）の分割ルール、あるいはハイブリッド検索（キーワード検索とベクトル検索の融合）の重み付けが間違っている証拠だ。LLMのプロンプトを1文字いじる前に、検索エンジンのインデックス設計を見直さなければならない。

しかし、ここで私は業界全体に痛烈な問いを投げかけたい。我々はいつまで、この「検索と生成の切り分け評価」という泥臭い作業を、個々のエンジニアの職人芸に委ね続けるのだろうか。LLMの進化スピードに対し、RAGの評価基盤（Evaluation Harness）の整備は圧倒的に遅れている。自動評価ツールは存在するが、それらが算出するスコアと、人間のビジネス要件における「納得感」との間には、依然として深い溝が存在する。我々が目指すべきは、単に「nDCGの数値を0.1上げる」ことではない。その数値の向上が、現場のユーザーの「業務効率化」にどう結びついているのかを、定量的かつ定性的に証明し続けることだ。この評価のサイクルをCI/CDパイプラインに組み込み、検索エンジンのアップデートごとに自動でリグレッションテストが走る仕組みを構築すること。それこそが、RAGを「おもちゃ」から「エンタープライズのインフラ」へと昇華させる、我々シニアエンジニアの使命ではないだろうか。