レッスン6：評価とテスト——Recall／MRR／nDCG／Faithfulness／Ragas 実務

このレッスンで学ぶこと

「評価データセットのない RAG は動いているように見えるだけ」の意味を実務に落とす
検索評価指標（Recall@k・MRR・nDCG・Hit Rate）を選び分けられる
生成評価指標（Faithfulness・Answer Relevancy・Context Precision・Context Recall）を理解する
Ragas・TruLens・DeepEval の位置づけを把握する
評価データセット構築（ゴールデンセット・LLM 合成質問・人手アノテーション）ができる
継続評価（シャドウトラフィック・A/B テスト・リグレッション検出）を組み立てられる
誤答の分析軸（検索失敗／文脈不足／プロンプト失敗／モデル失敗）で切り分けられる

前レッスンでは、クエリ理解と生成側プロンプト設計まで扱いました。ここで組み上げた RAG は、いくつかの質問に答えさせてみて、なんとなく良さそうに見えるかもしれません。しかし、感覚的な「良さそう」は、次の改善に繋げられません。評価データセットのない RAG は、動いているように見えるだけ——これが本レッスンの中核メッセージであり、6 個の背骨のうちの 1 つです。

「動いているように見える」と「本当に使える」の差

社内 RAG は、10 個ぐらいの質問に答えさせて「うまく返っている」と判定してリリースされることが少なくありません。しかし、この判定は 2 つの罠に陥ります。

選ばれた質問が偏っている：デモで見せる質問は、うまく答えられそうな質問が選ばれがちです
改善の方向が分からない：うまくいっていない質問があっても、「なぜ」うまくいっていないかが数値で見えないと、改善の手が入りません

評価は、この 2 つの罠を避けるための仕組みです。継続的に、複数の指標で、数十〜数百件のデータセットに対して評価を回す——これが RAG を「本当に使える」水準に育てる唯一の道です。

検索評価指標——「取れているか」を測る

RAG の検索段階（4 段階の 3 つ目）を評価する指標です。1 つのクエリに対して「正解チャンク」が事前に定義されていて、検索で返した順位が正解にどれだけ近いかを測ります。

Recall@k

上位 k 件の中に、正解チャンクが含まれる割合。1 つのクエリに対して正解が 1 つならシンプルに 0 か 1、正解が複数ならその割合。「上位 5 件のどこかに正解があれば OK」なら Recall@5、「上位 10 件」なら Recall@10。RAG では、生成段階に渡す件数（例：5 件）と揃えて設計するのが基本です。

MRR（Mean Reciprocal Rank、平均逆順位）

正解チャンクが最初に現れた順位の逆数の平均。「1 位に正解＝ 1.0」「2 位に正解＝ 0.5」「3 位に正解＝ 0.333」「10 位に正解＝ 0.1」「10 位以内になし＝ 0」。「1 位に近いほど価値が高い」検索を評価するのに向く指標です。

nDCG（normalized Discounted Cumulative Gain）

順位ごとに関連度スコアを割引きながら合計し、理想的な順序との比で正規化。順位に応じた重み付けができ、正解が複数ある場合や、正解の間に「よりよい正解」と「関連度が中程度」といった差がある場合に強い指標です。全文検索の世界で古くから使われています。

Hit Rate（ヒット率）

上位 k 件に 1 つでも正解が含まれる割合。Recall@k と近い概念ですが、正解が 1 つで良いか、複数必要かで扱いが異なる場合があります。

💡 ポイント 検索評価は 1 つの指標だけで判断せず、Recall@5・MRR・nDCG の 3 つ程度を並行して見るのが実務での定番です。「上位に来ているか（MRR）」「上位 k に入っているか（Recall@k）」「順位を精緻に評価（nDCG）」の 3 視点で、検索の弱点が違って見えてきます。

生成評価指標——「答え自体が正しいか」を測る

検索が良くても、生成段階でハルシネーションが起きれば意味がありません。RAG の生成段階を評価する指標です。多くは Ragas フレームワーク（後述）でよく整理されています。

Faithfulness（忠実度）

生成された回答の各主張が、参照情報（コンテキスト）に含まれるか。回答内の 10 の主張のうち 8 つがコンテキストで支持されれば Faithfulness = 0.8、といった具合。ハルシネーションを直接測る指標として、社内 RAG では最重要と言えます。

Answer Relevancy（回答関連度）

回答がユーザーのクエリに対して的を射ているか。回答が長々と関連薄い情報を並べていないか、といった観点。LLM に「この回答からクエリを 3 つ生成して」と頼み、元クエリとの意味的近さで測定する実装もあります。

Context Precision（コンテキスト精度）

検索で取得したコンテキストの中で、実際に回答に必要だったチャンクが上位に来ているか。ノイズが混入していると値が下がります。上位候補にノイズが多いと、Lost in the Middle 問題も含めて後段の精度に悪影響を与えるため、検索設計改善の指標として使えます。

Context Recall（コンテキスト再現度）

「回答に必要だった情報」のうち、検索で取れたコンテキストにカバーされている割合。事前に「理想の回答」を用意し、その回答内の各主張がコンテキストで裏付けられているかで測ります。Faithfulness と Context Recall はセットで見るのが実務のコツで、両方が高ければ「取れて、忠実に答えている」ことになります。

追加の指標

Ragas・TruLens・DeepEval のような評価フレームワークは、上記以外にも「Answer Correctness（正解との一致度）」「Answer Semantic Similarity」「Aspect Critique（不適切表現の検出）」など多数の指標を持ちます。すべてを追う必要はなく、社内 RAG では Faithfulness・Answer Relevancy・Context Precision・Context Recall の 4 つを軸に、必要に応じて追加するのが実務的です。

評価フレームワーク——Ragas・TruLens・DeepEval

RAG 評価に特化した OSS の代表格です。2026 年 7 月時点で広く使われるものを紹介します。

Ragas：Explodinggradients が主導する OSS。「Faithfulness」「Answer Relevancy」「Context Precision」「Context Recall」の概念を体系化し、業界標準の位置づけ。日本語対応の実装も整いつつある
TruLens：TruEra が主導する OSS。RAG に加えてエージェント評価にも対応。ダッシュボードとロギングに強い
DeepEval：Confident AI が主導する OSS。Pytest 風の記述で単体テスト感覚で評価を書ける。CI に組み込みやすい設計

これらは競合というより「補完的」に使われることが多いです。Ragas で指標定義、DeepEval で CI 統合、TruLens でダッシュボード観察、といった組み合わせも実務で見られます。

📝 補足 これらの評価フレームワークは、多くの指標を「LLM に採点させる」実装で提供します（LLM as a Judge）。この設計は便利ですが、採点用 LLM の質が低いと評価結果もぶれます。社内 RAG では、採点 LLM は精度の高いモデル（GPT-4／Claude Sonnet／Opus 系や、精度検証されたモデル）を使うことが多く、コストも見積もりに入れます。

評価データセット構築——ゴールデンセットの作り方

評価はデータセットが命です。データセットの品質が、評価そのものの品質を決めます。

ゴールデンセット（Golden Set）

「代表的な質問と、期待される回答、参照すべき正解チャンク」のセット。人間が丁寧に作った、いわばテストの模範解答。50〜200 件が最初の目安で、質問の分布は実運用の想定に合わせます。

質問の種類（規程・FAQ・議事録探索・数値照会）ごとに、バランスよく含める
正解が明確な質問と、答えにくい質問（フォールバックが期待される質問）の両方を含める
権限別のケース（管理職しか見えない情報を一般社員が聞いた場合など）も含める

LLM 合成質問

社内文書から LLM に「この文書について問える質問を 3 つ生成して」と頼み、質問と答えのペアを大量生成する手法です。数を稼ぐのに有効ですが、LLM が生成した質問は「文書に書いてあることをそのまま問う」偏りがあるため、実際のユーザーの言い回しとはずれます。ゴールデンセットの補助として使い、実運用ログとの併用が有効です。

人手アノテーション

実運用ログや専門家が作った質問に対して、人間が「正解チャンク」をラベル付けする手法です。品質は最も高い一方、コストがかかります。ゴールデンセットの中核はここで作ります。

実運用ログの活用

社内 RAG が動き始めたら、ユーザーが実際に投げた質問と、その回答の評価（サムズアップ／ダウンなど）を蓄積します。これがゴールデンセットの追加候補になり、指標の分布を実運用に合わせられます。

継続評価——シャドウトラフィック・A/B テスト・リグレッション検出

評価は「リリース前に 1 回」ではなく、継続的に回し続けることが重要です。

シャドウトラフィック

本番の質問を、変更前の RAG と変更後の RAG の両方に流し、結果を比較する。ユーザーには変更前の回答だけを返し、変更後の結果は評価用に蓄積。リスクなく本番トラフィックで評価できるのが利点。

A/B テスト

ユーザーの一部（例：10%）に変更後を返し、残りに変更前を返して、実際の評価（採用率・サムズアップ率）を比較する。実際のユーザー行動での判断ができる。

リグレッション検出

CI や日次バッチで、ゴールデンセットに対する各指標を計測し、閾値を下回ったらアラートを飛ばす仕組み。チャンキング方式・埋め込みモデル・プロンプト・リランクの何かを変更したとき、指標がどう動いたかを機械的に検出できる。

評価パイプラインの図

flowchart TB
  D[ゴールデンセット]
  L[実運用ログ]
  D --> Off[オフライン評価<br/>日次バッチ]
  L --> Off
  Off --> M[指標ダッシュボード<br/>Faithfulness・Recall・MRR]
  L --> A[A/B テスト<br/>ユーザー分割]
  L --> Sh[シャドウ<br/>並行実行]
  A --> M
  Sh --> M
  M --> R[リグレッション<br/>検出]
  R -.-> Alert[アラート]

誤答の分析軸——失敗の切り分け

回答が期待と違ったとき、原因は 4 か所に分けて考えます。

検索失敗：正解チャンクが上位候補に入らなかった。→ チャンキング方式・埋め込みモデル・ハイブリッド比率・リランクを見直す
文脈不足：チャンクは取れたが、必要な情報が別チャンクに散在していた。→ チャンクサイズを大きくする、親子チャンクを導入、要約チャンクを追加
プロンプト失敗：情報は渡ったが、生成 LLM が誤って解釈した。→ プロンプトの指示を明確化、番号引用の強制、断片順序の調整
モデル失敗：生成 LLM そのものの性能限界。→ 上位モデルへの切り替え、あるいは Faithfulness 低下の許容判断

「うまくいっていない」を「4 か所のどこか」に分類する習慣が、RAG の継続改善で最も効きます。この分類は 1 つのフレームワークで機械化できず、失敗ケースを目で見て振り分ける工程が必要です。ゴールデンセットの失敗率が 5% を超えたら、月に 1 回はこの分類作業を行うのが実務の勘所です。

中核メッセージの再確認

本レッスンで扱った内容を、中核メッセージに戻して整理します。

評価データセットのない RAG は「動いているように見える」だけ——本レッスンで最も強調した中核メッセージ。ゴールデンセット 50〜200 件を最初に作ることが、その後のあらゆる改善の土台になる
RAG の 8 割は LLM の外側で決まる——評価指標を通して見ると、モデル固有の問題より、チャンキング・検索・プロンプトの改善で数値が動く場面が圧倒的に多い
PoC は 8 割成功する、定着で 8 割詰まる——PoC 段階のデモ質問と、実運用ログを継続評価する体制の間には、深い隔たりがある

まとめ

検索評価は Recall@k・MRR・nDCG・Hit Rate の 4 指標。1 つに絞らず並行して見る
生成評価は Faithfulness・Answer Relevancy・Context Precision・Context Recall の 4 指標を軸にする
評価フレームワークは Ragas・TruLens・DeepEval。補完的に使うのが実務
ゴールデンセットは 50〜200 件を最初に作る。LLM 合成・実運用ログ・人手アノテーションを組み合わせる
継続評価はシャドウトラフィック・A/B テスト・リグレッション検出の 3 本柱
誤答は「検索失敗／文脈不足／プロンプト失敗／モデル失敗」の 4 分類で振り分ける
評価は「動いているように見える」を「本当に使える」に変える唯一の道

次のレッスンでは、社内 RAG を「安全に社内に展開する」ための必須設計——権限伝播、PII マスキング、監査ログ、ガバナンス、契約・法令の観点を扱います。ここまでの技術的な設計を、社内でリリースできる形に仕立てる段です。

確認クイズ

このレッスンの内容の理解度をチェックしましょう。