RAG評価とは？Ragas・DeepEval・Faithfulnessメトリクスの実装ガイド【2026年版】

RAG評価とは｜検索拡張生成の品質を継続的に測る仕組み

RAG（Retrieval-Augmented Generation：検索拡張生成）評価とは、RAGシステムが「正しい情報を検索し、その情報に基づいた信頼できる回答を生成しているか」を継続的に測定・改善する仕組みのことです。生成AIアプリケーションでRAGが普及する中で、「動くものは作れたが、良い回答かどうか分からない」という課題が業界共通の壁になっています。RAG評価はこの壁を乗り越え、RAGシステムを本番運用品質まで引き上げるための必須プロセスです。

renueでは広告代理AIエージェント・AI PMOエージェント・Drawing Agentなど複数のAIエージェント事業を運営する立場から、「RAGの精度はEmbedding選定・チャンク分割・リランキング・プロンプト・LLMの組み合わせで決まり、評価なしに改善することは不可能」という現実を実体験から把握しています。本記事では2026年時点のRAG評価の基本概念、主要メトリクス、評価フレームワーク(Ragas/DeepEval/Patronus等)、運用ステップ、renue独自視点の実務知見を体系的に解説します。

なぜRAG評価が難しいのか｜LLM応答の主観性と検索品質の絡み合い

従来のソフトウェアの自動テストと違い、RAG評価は次の理由で難しさがあります。

• 正解が一意でない: 「良い回答」の定義が主観的で、評価者によってブレる
• 検索と生成が絡み合う: 検索が悪いのか、生成が悪いのか切り分けが難しい
• 非決定性: 同じ質問でもLLMの応答は毎回少しずつ違う
• ハルシネーション: 検索結果にない情報をLLMが捏造することがある
• 大量データ: 数百〜数千件のテストケースを人間が判定するのは非現実的
• 進化の早さ: モデル・データ・要件が頻繁に変わるため、評価も継続が必要

これらに対処するため、2024〜2026年にかけて RAG特化の評価フレームワークが急速に成熟しました。中核は「LLM-as-a-judge(別のLLMに判定させる)」という発想です。

RAG評価の核心メトリクス4種類

RAG評価では「検索段階」と「生成段階」の両方を別々のメトリクスで測ります。

1. Faithfulness（忠実性）

生成された回答が、検索された文脈(コンテキスト)に忠実か。LLMが検索結果に書かれていない情報を捏造(ハルシネーション)していないかを測ります。RAG評価で最も重要な指標です。

計測方法: RagasのFaithfulnessは生成された回答を個別の主張(claim)に分解し、検索文脈から推論できる主張の割合を測ります。DeepEvalのFaithfulnessも回答と検索文脈の整合性を評価します。参照した文脈自体が誤っていれば、高スコアでも現実の事実が正しい保証にはなりません。ツール・版・判定モードを記録して比較し、必要な原資料や専門家の確認と区別します。

2. Answer Relevancy（回答の関連性）

生成された回答がユーザーの質問に対して関連性があるかを測ります。Ragasの公式説明は、不完全な回答や不要な詳細を低く評価するとしています。長さだけを測る減点式ではなく、長いという理由だけで必ず低得点になるとはしません。また、関連性は事実の正確さの評価と別です。

計測方法: RagasのAnswer Relevancyは回答から質問を生成し、元の質問と生成された質問の埋め込みのコサイン類似度を平均します。入力はuser_inputとresponseで、正解回答を使うContext Recallとは別のメトリクスです。現在の公式例はcollections APIを使い、旧Metrics APIと分けて説明しています。

3. Context Precision（検索精度）

検索された文脈の中に、回答に必要な情報がどれだけ集中しているか。検索結果に無関係な情報が混じっているとスコアが下がります。

計測方法: 検索された各チャンクが「回答に必要だったか」をLLM-as-judgeで判定し、上位ランクへの集中度を計算。

4. Context Recall（検索網羅率）

正解回答に必要な情報が、検索結果にどれだけ含まれているか。検索が必要な情報を取りこぼしていないかを測ります。

計測方法: RagasのLLMを使うContext Recallは、reference（正解回答）の主張が検索文脈から支持される割合を判定します。正解文脈を使う非LLM版もあり、いずれも比較対象となるreferenceまたはreference_contextsが必要です。すべてのRAG評価が正解データなしで計算できるわけではありません。

4メトリクスの組み合わせで全体像を捉える

測定対象	メトリクス	失敗時の典型症状
検索段階	Context Precision	無関係な文書が混じる
検索段階	Context Recall	必要な文書を取りこぼす
生成段階	Faithfulness	ハルシネーションが出る
生成段階	Answer Relevancy	質問と関係ない冗長な回答

4メトリクスを総合することで「どこに問題があるか」を切り分けられ、改善の方向性が明確になります。

主要なRAG評価フレームワーク【2026年版】

フレームワーク	提供企業	特徴	適合シーン
Ragas	Ragas	RAG評価のデファクト標準・Faithfulness/Context Precision/Recall/Answer Relevancy などを統合	RAG評価の出発点・OSS
DeepEval	Confident AI	pytest互換・TDD的にRAG評価をCI/CDに組み込み可能。原14+という件数の対象版・数え方は未確認。使用するメトリクスの現行要件と判定モードを確認	開発チーム・CI/CD統合
TruLens	TruEra	フィードバック関数ベース・LangChain統合	LangChainユーザー
Patronus AI	Patronus	エンタープライズ向け・規制対応・高品質ベンチマーク	金融・医療など規制業界
LangSmith Evaluation	LangChain Inc.	LangChain統合・データセット管理・人間レビュー	LangChainベースの開発
Langfuse Evals	Langfuse	OSS・観測性と評価を統合	OSS志向・セルフホスト
Arize Phoenix	Arize AI	本番ログから評価を回せる・トレース統合	本番運用フェーズ
OpenAI Evals	OpenAI	OpenAIエコシステム標準	OpenAI中心の開発
Maxim AI	Maxim AI	評価・実験・本番監視のオールインワン	SaaS型統合
Promptfoo	Promptfoo	OSS・YAMLベースの評価設定	軽量導入・PoC

LLM-as-a-Judge の活用と限界

RAG評価では LLM-as-a-Judge(別のLLMに判定を任せる)を利用できます。Ragas・DeepEval・LangSmith等を使う場合も、すべてのメトリクスが同じ判定方法ではありません。例えばRagasには非LLM版のContext Recallがあり、DeepEvalは判定モードごとのFaithfulnessを説明しています。採用するツール・版・メトリクス・判定方法を固定して比較してください。

LLM-as-a-Judgeの利点

• ヒューマン評価の原「数十〜数百倍」は、質問数・回答長・判定モデル・並列数・人間側の手順と実測出典が未確認。全条件の速度保証にせず、同じ評価対象と基準で測定する
• 正解回答を用意せず評価できるメトリクスもある(reference-free)。Answer Relevancyや検索文脈とのFaithfulnessと、正解回答/文脈が必要なContext Recallを区別する
• 大量のテストケースを継続的に評価できる
• 主観のブレを抑えやすい(同じプロンプトを使えば再現性が高い)

限界・注意点

• 判定LLMにもバイアスがある(自社モデルを甘く採点する傾向)
• 評価コストが意外にかかる(評価対象1件につき複数のLLM呼び出し)
• 専門領域(医療・法務)では人間専門家の評価が必須
• 判定LLMが古いと評価品質が劣化する

renueでは「LLM-as-a-Judgeで継続評価＋月1回は人間によるサンプル監査」というハイブリッド運用を推奨しています。

RAG評価の運用ステップ

1. 評価データセットの整備: 50〜500件の代表的な質問と期待回答(または正解文書)を集める
2. フレームワーク選定: Ragas(出発点) / DeepEval(CI/CD) / LangSmith(LangChain使用時) など
3. 初回評価ベースラインの取得: 現状のスコアを計測し、改善前の数値として記録
4. 改善サイクル: Embeddingモデル変更・チャンク分割調整・リランキング追加・プロンプト改善などを試し、再評価
5. 継続的なモニタリング: 本番運用後も定期的に評価を回し、品質劣化を早期検知
6. ユーザーフィードバックの統合: 自動評価と実ユーザーの 👍/👎 を組み合わせて総合判断

renueの視点｜RAG本番運用で見えた6つの実務原則

renueでは複数のAIエージェント事業でRAGを本番運用してきた実体験から、RAG評価について次の6つの実務原則を確立しています。

(1) 評価データセットを最初に作る: RAG実装より先に評価データセットを作るくらいの優先度。50〜100件の代表的な質問・期待回答を整備してから本格実装に入ります。これがないと「改善したか劣化したか」が分からず、永遠に手探りになります。

(2) Faithfulness を最優先メトリクスにする: ハルシネーションは事業リスクに直結するため、Faithfulnessが基準値を下回った場合はリリース判断を見直す運用が有効とされています。Context Precision/Recallは改善の方向性を示す参考値として扱います。

(3) 検索段階と生成段階を別々に評価する: 「精度が悪い」を漠然と捉えるのではなく、4メトリクスで「検索が悪いのか・生成が悪いのか」を切り分けます。原因特定なしに闇雲に改善すると効率が悪い。

(4) CI/CD に評価を組み込む: Embedding変更・プロンプト変更・モデル変更のたびに自動で評価が走る仕組みを CI/CD に組み込みます。DeepEval は pytest 互換でこの統合が容易です。

(5) 評価コストの管理: LLM-as-a-Judgeはメトリクス・判定方法によって複数のモデル呼び出しや埋め込み処理を行います。原の500件を月100〜500回評価する案は、延べ5万〜25万ケースの計画例で、一般的な必要頻度ではありません。「評価頻度×サンプル数」に、各メトリクスの実際の呼び出し回数・入力/出力トークン数と単価を掛け、再試行・埋め込み・基盤費等も試算します。Geminiの公式料金もモデル、入力/出力、キャッシュやBatch等の条件で異なるため、Flashという系列名だけで一律に安価と保証しません。

(6) 月1回は人間による監査サンプル: LLM-as-a-Judgeを過信せず、月1回 10〜30件を人間が目視確認し、判定LLMの精度を検証します。判定LLMがズレ始めたら早期に気付けます。

RAG評価でよくある失敗パターン

• 失敗1: 評価データセットがない — 「動く」だけで本番投入し、品質劣化に気付けない
• 失敗2: メトリクス1つだけで判断 — Faithfulness だけ見て Context Recall を無視するなど、片面評価で間違った改善判断をする
• 失敗3: 評価データセットが古い — 初回作成後に更新せず、現実のトラフィックと乖離する
• 失敗4: LLM-as-a-Judge の判定LLM選定ミス — 安価LLMで評価して判定品質が低い、または高価LLMで評価コスト爆発
• 失敗5: 人間レビューの欠如 — 自動評価だけを信じて、判定LLMの誤判定に気付かない
• 失敗6: 改善サイクルがない — 評価はするが改善アクションに繋がらない「測定するだけ」

業種別の RAG 評価の重点

業種	重点メトリクス	業界特有の評価項目
カスタマーサポート	Faithfulness, Answer Relevancy	トーン・誤情報リスク
法務・契約書	Faithfulness, Context Recall	条項の正確な引用
医療	Faithfulness 厳格	規制情報の正確性
金融	Faithfulness, Context Precision	数値の正確性
社内ナレッジ検索	Context Recall	取りこぼしの少なさ
EC・商品レコメンド	Answer Relevancy	ユーザー文脈との適合

よくある質問（FAQ）

Q1. RAG評価のフレームワークはどれを選ぶべきですか？

初心者・OSS志向ならRagas、CI/CD組み込み重視ならDeepEval、LangChain使用なら LangSmith Evaluation が定番です。エンタープライズ規制対応なら Patronus、本番運用統合なら Arize Phoenix が適合します。

Q2. 評価データセットは何件作るべきですか？

最低50件、理想は500件です。少なすぎるとバラつきが大きく、多すぎると評価コストが膨らみます。「代表的なパターンを網羅する」という観点で質を優先してください。

Q3. 自動評価と人間評価のどちらを優先すべきですか？

両方必要です。自動評価で日次・週次の継続モニタリング、人間評価で月次の精度検証、というハイブリッドが現実解です。

Q4. 評価コストはどれくらいかかりますか？

500件のテストケースを月10回評価する計画例は延べ5,000ケースです。原の月数千円〜数万円は、対象モデル・メトリクス数・1ケースの呼び出し回数・入力/出力トークン数・為替・実測出典が未確認で、一律の料金ではありません。利用するモデルの公式料金を使い、延べケース数と処理量から試算し、本番運用の実費を確認してください。

Q5. renueはRAG評価の導入支援を提供していますか？

はい、renueは複数のAIエージェント事業で RAG を本番運用してきた実体験を活かし、評価データセット整備、フレームワーク選定、CI/CD統合、運用サイクル定着までの一気通貫支援を提供しています。

関連記事

• プロンプト vs RAG vs ファインチューニング 完全比較2026
• LLM Observability・評価・ガードレール完全ガイド2026
• Function Calling完全ガイド2026
• LiteLLM完全ガイド2026
• LLM API徹底比較2026
• 生成AIセキュリティ完全ガイド2026

RAG評価・LLMアプリ品質管理のご相談はrenueへ

renueは複数のAIエージェント事業を本番運用する技術コンサルティング企業です。RAG評価データセットの整備、フレームワーク選定、CI/CD統合、運用サイクル定着、ハルシネーション削減などをご検討の方はお気軽にお問い合わせください。

本記事の参考情報

• Ragas公式: List of available metrics
• DeepEval公式: Faithfulness Metric
• DeepEval公式: Ragas Metrics
• DeepEval公式: RAG Evaluation Guide
• Prem AI: RAG Evaluation Metrics, Frameworks & Testing 2026
• Patronus AI: RAG Evaluation Metrics Best Practices
• Maxim AI: 5 Best RAG Evaluation Tools 2026
• LangSmith Docs: Evaluate a RAG application

あわせて読みたい

• AIコンサルティングの4つの型
• AI導入の相談前に準備すべき5つのこと