生成AI関連
Amazon Bedrock Knowledge Base × S3 VectorsでRAGを作って…
RAG（Retrieval-Augmented Generation：検索拡張生成）は、生成AI活用の定番構成になりつつあります。社内ドキュメントを検索してAIに回答させる仕組みを構築した、あるいはこれから構築しようとしている方も多いのではないでしょうか。
一方で、RAGを構築した後に直面しがちな課題があります。
RAGを構築するための情報は増えてきましたが、評価するための情報はまだ十分に整理されていないのが現状です。
本記事では、RAG評価の全体像を整理し、代表的な指標を一つずつ解説します。「まず何を測ればいいのか」が分かる状態をゴールとしています。
対象読者は、RAGを構築した、またはこれから構築する初心者〜中級者の方です。RAGの構築手順そのものについては、下記の記事で解説しています。
RAGとは、ユーザーの質問に対して外部のドキュメントから関連情報を検索（Retrieve）し、その情報をコンテキストとしてLLMに渡して回答を生成（Generate）させる仕組みです。LLMが学習していない社内固有の情報にも対応できるため、企業でのAI活用で広く採用されています。
RAGの処理は、大きく2つのステップに分かれます。
検索の基盤となるエンベディング（埋め込み表現）の仕組みについては、下記の記事で解説しています。
ここで重要なのは、RAGには2つのステップがあるため、評価も2つの軸が必要になるという点です。検索がうまくいっていなければ、いくら優秀なLLMを使っても正しい回答は生成できません。逆に、検索は正確でもLLMが取得した情報を正しく使えなければ、やはり品質は下がります。
この「検索」と「生成」の両面から評価するという考え方が、本記事の基本的な構成です。
RAGの評価は、大きく3つの観点に分類できます。
| 観点 | 評価対象 | 問い | 代表的な指標 |
|---|---|---|---|
| 検索（Retrieval） | 検索コンポーネント | 正しいドキュメントを取得できているか？ | Precision@K, Recall@K, MRR, NDCG |
| 生成（Generation） | 生成コンポーネント | 取得した情報から正しい回答を生成できているか？ | Faithfulness, Answer Relevancy |
| エンドツーエンド | システム全体 | ユーザーの質問に対する最終的な回答品質は十分か？ | Context Relevance, Context Precision, Context Recall |
検索の評価は、情報検索（Information Retrieval）分野で長く研究されてきた指標がそのまま活用できます（Stanford IR講義資料）。一方、生成の評価はRAG特有の観点が求められ、近年新しい指標やフレームワークが提案されています。
以降、それぞれの指標を順番に見ていきます。
まずは、RAGの第1ステップである「検索」の評価指標です。検索が正しく機能しているかどうかは、RAG全体の品質を左右する土台となります。
検索結果の評価は、実は2クラス分類と同じ枠組みで考えることができます。各ドキュメントを「ユーザーの質問に関連があるか/ないか」×「検索で取得したか/しなかったか」で分類すると、以下の4象限になります。
| 関連あり（正解） | 関連なし | |
|---|---|---|
| 取得した | TP（正しく取得） | FP（ノイズ） |
| 取得しなかった | FN（取りこぼし） | TN（正しく除外） |
混同行列の基本概念（Positive/Negativeの設計、True/Falseの意味）については、下記の記事で詳しく解説しています。本記事では深入りせず、RAG検索の文脈での使い方に焦点を当てます。
この4象限から、次の2つの指標が導かれます。
取得した上位K件のドキュメントのうち、実際に関連があるドキュメントの割合です。
Precision@K = 関連ありと判定された取得文書数 / K
計算例: 上位5件を取得し、そのうち3件が関連文書だった場合
Precision@5 = 3 / 5 = 0.6
Precision@Kが高いほど、「取得した文書にノイズが少ない」ことを意味します。なお、Kの値はRAGシステムの設計に依存します。多くのRAGシステムではK=3〜10程度で検索結果を取得するため、その範囲で評価するのが一般的です。
全関連ドキュメントのうち、上位K件で取得できた割合です。
Recall@K = 上位K件に含まれる関連文書数 / 全関連文書数
計算例: 全体で関連文書が4件あり、上位5件の取得結果に3件が含まれていた場合
Recall@5 = 3 / 4 = 0.75
Recall@Kが高いほど、「関連文書の取りこぼしが少ない」ことを意味します。
なお、Precision@KとRecall@Kにはトレードオフの関係があります。Kを大きくすれば（多くの文書を取得すれば）Recallは上がりやすいですが、その分ノイズも増えてPrecisionは下がりやすくなります。逆にKを小さくすればPrecisionは上がりますが、関連文書を取りこぼしてRecallが下がります。
Precision（適合率）とRecall（再現率）のどちらを重視するかは、ビジネス要件によって変わります。
| 重視する指標 | 適したケース | 理由 |
|---|---|---|
| Precision重視 | 社内チャットボット、顧客向けFAQ | ノイズの多い回答はユーザー体験を損なう。関係ない情報が混ざると信頼を失う |
| Recall重視 | 法務・コンプライアンス調査、障害調査 | 見逃しが致命的。多少ノイズが増えても、関連情報を網羅的に取得したい |
| バランス | 一般的な社内ナレッジ検索 | 適度な精度と網羅性の両立が求められる |
Precision@KやRecall@Kは「取得したかどうか」を見る指標ですが、実際のRAGでは取得結果の順序も重要です。関連文書が1位にあるのと5位にあるのとでは、回答品質に差が出ます。ここでは、順序を考慮した2つの指標を紹介します。
MRRは、最初の関連文書が検索結果の何番目に現れるかを評価する指標です。
複数のクエリに対して検索を実行し、各クエリで最初に関連文書が現れた順位の逆数を平均します。
Reciprocal Rank = 1 / (最初の関連文書の順位)
MRR = 全クエリのReciprocal Rankの平均
計算例: 3つのクエリで検索を実行した結果
| クエリ | 最初の関連文書の順位 | Reciprocal Rank |
|---|---|---|
| クエリ1 | 1位 | 1/1 = 1.0 |
| クエリ2 | 3位 | 1/3 ≒ 0.333 |
| クエリ3 | 2位 | 1/2 = 0.5 |
MRR = (1.0 + 0.333 + 0.5) / 3 ≒ 0.611
MRRは「1件だけ正解を見つければいい」ケースに向いています。例えば、社内FAQで「この質問に対する最適な回答が1つあれば十分」という場面では、最初の関連文書が上位にあるかどうかが最も重要です。
一方で、MRRには「最初の1件しか見ない」という限界もあります。2位以降に関連文書が複数あっても評価に反映されません。複数の関連文書を総合的に評価したい場合は、次に紹介するNDCGが適しています。
NDCGは、関連文書が上位にどれだけ集まっているかを評価する指標です。MRRが「最初の1件」に注目するのに対し、NDCGは取得結果全体の順序の質を評価します。
NDCGの考え方を段階的に説明します。
1. 関連度スコア: 各文書に関連度を数値で付与します（例：関連度なし=0, やや関連=1, 非常に関連=2）。
2. DCG（Discounted Cumulative Gain）: 順位が下がるほど割り引く（Discount）ことで、上位の関連文書を高く評価します。
DCG@K = Σ (関連度スコア_i / log2(i + 1)) ※ i = 1, 2, ..., K
3. NDCG: DCGを理想的な並び順のDCG（IDCG）で正規化し、0〜1の範囲にします。
NDCG@K = DCG@K / IDCG@K
なお、DCGの計算式には複数の流派があり、gainの部分を rel_i ではなく 2^{rel_i} – 1 とする定義も広く使われています（Wikipedia: Discounted cumulative gain）。本記事では直感的に理解しやすい rel_i 版を採用しています。
計算例: 上位5件の検索結果の関連度が [2, 0, 1, 0, 1] だった場合
DCG@5 = 2/log2(2) + 0/log2(3) + 1/log2(4) + 0/log2(5) + 1/log2(6)
= 2/1.0 + 0/1.585 + 1/2.0 + 0/2.322 + 1/2.585
= 2.0 + 0 + 0.5 + 0 + 0.387
= 2.887
理想的な並び順 [2, 1, 1, 0, 0] の場合：
IDCG@5 = 2/log2(2) + 1/log2(3) + 1/log2(4) + 0/log2(5) + 0/log2(6)
= 2.0 + 0.631 + 0.5 + 0 + 0
= 3.131
NDCG@5 = 2.887 / 3.131 ≒ 0.922
NDCGは「複数の関連文書をバランスよく上位に出したい」ケースに向いています。例えば、技術的な質問に対して複数のドキュメントを参照して回答を組み立てるRAGシステムでは、関連度の高い文書が上位に集まっているかどうかが回答品質に直結します。
NDCGが1.0に近いほど、理想的な順序に近い検索結果が得られていることを示します。上の計算例では0.922なので、ほぼ理想に近い順序で検索できていると言えます。
ここまで紹介した4つの指標を比較します。
| 指標 | 順序を考慮 | 複数段階の関連度 | 特徴 | 向いているケース |
|---|---|---|---|---|
| Precision@K | ✕ | ✕ | 取得文書のノイズの少なさを測る | ノイズを減らしたい場面 |
| Recall@K | ✕ | ✕ | 関連文書の網羅性を測る | 取りこぼしを減らしたい場面 |
| MRR | ○ | ✕ | 最初の関連文書の順位を測る | 1件の正解で十分な場面 |
| NDCG | ○ | ○ | 上位の関連文書の集中度を測る | 複数の関連文書が必要な場面 |
実務では、まずPrecision@KとRecall@Kで検索の基本性能を確認し、順序が重要な場面ではMRRやNDCGを追加で確認するのが一般的です。
次に、RAGの第2ステップである「生成」の評価指標です。検索で正しいドキュメントを取得できても、LLMがその情報を適切に使って回答を生成できなければ意味がありません。
生成の評価では、主に以下の2つの観点が重要です。なお、RAGAS論文（Shahul Es et al., 2023）では、これらに加えてContext Relevance（取得したコンテキストが質問にどれだけ関連・集中しているか）も中心的な指標として位置づけられています。Context Relevanceは後述するContext Precisionと近い概念で、TruLensフレームワークでも「RAG Triad」の一角として採用されています。
Faithfulnessは、生成された回答が、取得したコンテキスト（検索結果）に基づいているかを測る指標です（Ragas公式ドキュメント）。回答に含まれる主張（claim）を分解し、それぞれがコンテキストから推論可能かどうかを判定します。
Faithfulness = コンテキストで裏付けられる主張の数 / 回答中の主張の総数
なぜ重要か: RAGの大きな利点の一つは、LLMの回答をドキュメントに基づかせることで、ハルシネーション（幻覚）を抑制できる点です。Faithfulnessが低い場合、LLMがコンテキストにない情報を「でっち上げて」回答している可能性があります。
具体例:
コンテキスト（検索で取得した情報）:
「当社の年間休日は125日です。夏季休暇は3日間です。」
LLMの回答:
「当社の年間休日は125日で、夏季休暇は3日間、冬季休暇は5日間です。」
この回答には3つの主張がありますが、「冬季休暇は5日間」はコンテキストに含まれていません。
Faithfulness = 2 / 3 ≒ 0.667
Faithfulnessは1.0に近いほど、コンテキストに忠実な回答が生成されていることを示します。この指標は、RAGAS論文（Shahul Es et al., 2023）で提案されたRAG評価の中核的な指標の一つです。
Answer Relevancyは、生成された回答がユーザーの質問にどれだけ的確に答えているかを測る指標です。
Faithfulnessとの違いを整理すると次のようになります。
| 指標 | 評価する対象 | 問い |
|---|---|---|
| Faithfulness | 回答 ↔ コンテキスト | 回答はコンテキストに基づいているか？ |
| Answer Relevancy | 回答 ↔ ユーザーの質問 | 回答はユーザーの質問に答えているか？ |
コンテキストに忠実であっても、ユーザーの質問に答えていなければ意味がありません。例えば、「有給休暇の申請方法」を聞いているのに「有給休暇の残日数の確認方法」を回答している場合、Faithfulnessは高くてもAnswer Relevancyは低くなります。
Answer Relevancyの測定方法はいくつかありますが、RAGASフレームワーク（Ragas公式ドキュメント）では、回答から逆に質問を生成し、元の質問との意味的な類似度（コサイン類似度）を計算する方法が採用されています。回答が質問に的確に答えているほど、逆生成された質問は元の質問に近くなるという考え方です。
この2つの指標は、検索と生成をつなぐ重要な指標です。検索の指標（Precision@K/Recall@K）が「関連文書を取得できたか」を見るのに対し、Context Precision/Recallは「取得した文書が実際の回答生成にどれだけ役立ったか」を見ます。
取得したコンテキストのうち、関連するコンテキストがどれだけ上位に集中しているかを測る指標です。単に関連コンテキストの割合を見るだけでなく、順位を考慮する点がPrecision@Kとの違いです。
RAGASフレームワーク（Ragas公式ドキュメント）では、各順位での適合率（Precision@k）を関連コンテキストの位置で重み付けして平均する形で定義されています。
Context Precision@K = (1 / 関連コンテキスト数) × Σ (Precision@k × v_k)
※ v_k = k番目のコンテキストが関連なら1、そうでなければ0
※ Precision@k = 上位k件中の関連コンテキスト数 / k
具体例: 「当社の育児休暇制度について教えてください」という質問に対して、5件のドキュメントを取得したとします。
| 順位 | 内容 | 関連性 | Precision@k |
|---|---|---|---|
| 1 | 育児休暇の取得条件と期間 | ○ | 1/1 = 1.0 |
| 2 | 介護休暇の制度概要 | ✕ | —（スキップ） |
| 3 | 育児休暇中の給与・手当 | ○ | 2/3 ≒ 0.667 |
| 4 | 会社の沿革 | ✕ | —（スキップ） |
| 5 | 育児休暇の申請手順 | ○ | 3/5 = 0.6 |
Context Precision@5 = (1.0 + 0.667 + 0.6) / 3 ≒ 0.756
同じ3件の関連文書でも、1位・2位・3位に集中していればスコアは高くなり、下位に散らばっていればスコアは低くなります。この「上位集中度」を測れる点が、単純な割合では捉えられないContext Precisionの強みです。
なお、RAGASフレームワークでは、参照回答（ground truth）と比較する Context Precision と、LLMの生成回答と比較する Context Utilization が区別されています。参照回答を用意できない場合は後者を使います。
Context Precisionが低い場合、関連するドキュメントが下位に埋もれている、またはノイズが多いことを意味します。ノイズの多いコンテキストはLLMの回答品質を下げる原因になるため、検索精度の改善やリランキングの導入が必要です。
理想的な回答に必要な情報が、取得したコンテキストにどれだけ含まれていたかを測ります。Context Precisionと異なり、この指標には参照回答（ground truth）が必要です（Ragas公式ドキュメント）。
Context Recall = 正解に含まれる主張のうちコンテキストで裏付けられる数 / 正解に含まれる主張の総数
具体例: 同じ育児休暇の質問で、あらかじめ用意した参照回答（ground truth）には以下の4つの情報が含まれるべきだったとします。
Context Recall = 3 / 4 = 0.75
Context Recallが低い場合、正しい回答を生成するために必要な情報が検索で取得できていないことを意味します。この場合、検索コンポーネントの改善（チャンク分割の見直し、Embeddingモデルの変更、メタデータフィルタリングの導入など）が必要です。
これら2つの指標は、検索（Retrieval）の指標であるPrecision@K/Recall@Kと名前が似ていますが、評価の観点が異なります。
| 指標 | 何を見ているか | 基準 |
|---|---|---|
| Precision@K / Recall@K | 取得した文書が「質問に関連するか」 | 文書レベルの関連性 |
| Context Precision / Recall | 取得した文書が「回答生成に役立ったか」 | 回答生成への貢献度 |
例えば、質問に関連する文書を取得できていても（Precision@Kが高い）、その文書の内容がLLMの回答に十分活用されなければ、Context Precisionは低くなります。両者を組み合わせることで、「検索は良いが生成で情報を活かせていない」「そもそも検索で必要な情報を取れていない」といった問題の切り分けが可能になります。
RAGの評価指標を紹介してきましたが、自然言語処理（NLP）の分野には、以前から文章の類似度を測る指標が存在します。ここでは代表的な3つの指標と、RAG評価における限界を整理します。
BLEUとROUGEは、生成されたテキストと参照テキスト（正解）をn-gram（連続するn個の単語）の一致度で比較する指標です。
| 指標 | 概要 | もともとの用途 |
|---|---|---|
| BLEU | 生成テキスト中のn-gramが参照テキストにどれだけ含まれるか（Precision寄り） | 機械翻訳の評価 |
| ROUGE | 参照テキスト中のn-gramが生成テキストにどれだけ含まれるか（Recall寄り） | 文書要約の評価 |
これらの指標はもともと機械翻訳や文書要約の評価のために開発されたもので、n-gramの一致度をもとに0〜1のスコアを算出します。スコアが1.0に近いほど、参照テキストとの一致度が高いことを示します。
限界: これらの指標は表面的な単語の一致を見ているため、以下の場面では正しく評価できません。
RAGの回答は自然言語で生成されるため、正解と同じ意味でも異なる表現で回答されることがほとんどです。このため、BLEUやROUGEだけではRAGの回答品質を正確に測ることが難しいのが実情です。
BERTScoreは、BLEUやROUGEの限界を補うために提案された指標で、Embeddingベースの意味的類似度で文章を比較します。
単語レベルのn-gram一致ではなく、BERTなどの事前学習済み言語モデルを用いてトークン（単語）ごとに文脈を考慮したベクトル表現を生成し、候補文と参照文の間でトークン同士の最適なマッチングを行って類似度を計算します（Zhang et al., 2020）。文全体を1つのベクトルにまとめるのではなく、トークン単位で照合する点が特徴で、Precision・Recall・F1の形でスコアが算出されます。
これにより、言い換えや語順の違いにもある程度対応できます。例えば、「会議は10時に始まります」と「10時から会議がスタートします」のように、表面的な単語は異なっても意味が同じ文については、BERTScoreではBLEUやROUGEよりも高いスコアが得られます。ただし、BERTScoreも万能ではなく、文脈に依存する微妙なニュアンスの違いを完全に捉えることは難しい場合があります。
エンベディングの基本については、下記の記事で解説しています。
これらの従来指標には共通の前提があります。それは、参照テキスト（正解）が必要という点です。
RAGの実運用では、質問と正解のペアを大量に用意することが難しい場面も多くあります。社内ナレッジのように正解が明確に定義しづらいケースや、質問のバリエーションが膨大で網羅的な正解データを作りきれないケースが典型的です。
こうした「正解データなしでも評価したい」という課題に対するアプローチとして、次のセクションで紹介する「LLM-as-a-Judge」が注目されています。
ここまで様々な指標を紹介してきましたが、「実際にどう評価すればいいのか」が気になる方も多いと思います。ここでは、評価を実践するための3つのアプローチを紹介します。
LLM-as-a-Judgeとは、LLM自身に「審判役」をさせる評価アプローチです。
従来の評価では、人間の評価者が回答を読み、品質を判定する必要がありました。しかし、これには時間とコストがかかり、大量のデータを評価するにはスケールしません。
LLM-as-a-Judgeでは、評価対象の回答をLLMに渡し、「この回答はコンテキストに基づいているか（Faithfulness）」「この回答は質問に答えているか（Answer Relevancy）」といった観点でスコアリングさせます。
イメージとしては、以下のようなプロンプトをLLMに渡すことで、自動的に評価スコアを得ます。
以下の「質問」「コンテキスト」「回答」を確認し、回答がコンテキストの内容に基づいているかを
1（全く基づいていない）〜5（完全に基づいている）のスケールで評価してください。
【質問】{ユーザーの質問}
【コンテキスト】{検索で取得したドキュメント}
【回答】{LLMが生成した回答}
このように、LLMが「評価者」として機能することで、人間が一件ずつ確認する必要がなくなります。
メリット:
注意点:
なお、Zheng et al. (2023) のMT-benchにおける検証では、GPT-4をジャッジとして使用した場合に人間の評価者との一致率が約80%以上と報告されています（Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena）。ただし、この一致率は使用するジャッジモデルの性能や評価対象によって変動するため、自身のユースケースで精度を確認することが重要です。
RAG評価の指標を一つずつ手動で実装するのは大変です。そこで、これらの指標をまとめて計算できるフレームワークがいくつか公開されています。
| フレームワーク | 特徴 | 主な指標 |
|---|---|---|
| RAGAS | 論文ベースのオープンソースフレームワーク。RAG評価に特化した指標を網羅 | Faithfulness, Answer Relevancy, Context Relevance, Context Precision, Context Recall |
| TruLens | フィードバック関数による評価。評価結果のダッシュボード機能が充実 | Groundedness, Answer Relevance, Context Relevance |
| DeepEval | テストフレームワークとして設計。pytest風のインターフェースで評価を実行 | Faithfulness, Answer Relevancy, Hallucination, Bias 等 |
RAGASは、Shahul Es et al. (2023) の論文「RAGAS: Automated Evaluation of Retrieval Augmented Generation」で提案されたフレームワークで、本記事で紹介したFaithfulness・Answer Relevancy・Context Precision・Context Recallに加え、Context Relevanceなどの指標も一括で評価できます。
各フレームワークの使い方やコード例は本記事のスコープ外としますが、まずは評価指標の意味を理解した上で、自分のユースケースに合ったフレームワークを試してみるのがおすすめです。
なお、どのフレームワークを選ぶかは、以下の観点で判断するのが良いでしょう。
自動指標やLLM-as-a-Judgeでは捉えきれない品質要素もあります。
これらは最終的に人間の判断が必要です。特に、ユーザーが実際にRAGの回答を受け取ったときに「役に立った」と感じるかどうかは、自動指標だけでは測りきれません。
ただし、全件を人間が評価するのはコストが高いため、開発フェーズに応じた使い分けが現実的です。
| フェーズ | 評価手法 | 目的 |
|---|---|---|
| 開発初期 | 自動指標（Precision, Recall等） | パラメータ調整の高速なイテレーション |
| 中期 | LLM-as-a-Judge | スケーラブルな品質チェック |
| リリース前 | 人間による評価 | 最終的な品質保証 |
| 運用中 | 人間による定期サンプリング | 品質の継続的な監視 |
精度に対する考え方（何をどこまで求めるか、人間の判断とAIの役割分担など）については、下記の記事で整理しています。
本記事では、RAGの評価指標を体系的に整理しました。ポイントを振り返ります。
「RAGを構築したが、どう評価すればいいか分からない」という方は、まずPrecision@KとRecall@Kで検索の品質を確認し、FaithfulnessとAnswer Relevancyで生成の品質を確認するところから始めるのが良いでしょう。
大切なのは、「まず測ること」が改善の第一歩だということです。完璧な評価体制を最初から整える必要はありません。測れる指標から測り始め、改善のサイクルを回していくことが、RAGの品質向上への近道です。
また、評価指標はあくまで「改善のための道具」です。指標のスコアを上げること自体が目的ではなく、最終的にはユーザーにとって役立つ回答を返せるRAGシステムを構築することがゴールです。指標を活用しながら、継続的にRAGの品質を高めていきましょう。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
