RAGの品質評価は「検索の良し悪し」と「生成の良し悪し」を切り分けて測る必要がある、意外と難しい領域です。FaithfulnessやContext Precisionといった主要メトリクスを知らないまま改善を進めると、どの施策が効いたのか判断できずに迷走しがちです。本記事ではRAG評価の基本指標、評価ツールの比較、評価パイプラインのCI/CD組み込み方までを実務ベースで整理します。測れないものは改善できない、という原則に立ち返りましょう。
RAGの評価はなぜ難しいのか
RAGの品質評価が難しい理由は大きく2つあります。第一に、RAGは検索と生成の2段階から構成されており、どちらに問題があるのかを切り分けずにスコアを出しても改善に結びつきません。例えば「回答が不正確」という現象の背後には、「必要な文書が検索結果に含まれていない」「含まれているが生成で活用されていない」「活用されているが表現が不適切」といった複数の原因が潜んでいる可能性があります。
第二に、生成タスクは正解が一意に定まらないため、正解一致率のような単純な指標では評価できません。そこで登場したのがLLM-as-Judgeの考え方で、評価専用のプロンプトをLLMに解かせ、複数の観点で定量スコアを出すのが現在の主流です。これにより人手評価のコストを大きく削減しつつ、一定の再現性を確保できます。
【RAG評価の対象範囲】
[RAG全体品質]
|
+------------+------------+
| |
v v
[検索品質] [生成品質]
| |
+-------+-------+ +--------+--------+
| | | | | |
v v v v v v
Precision Recall MRR Faithful Relevancy Harmful
(精度) (網羅性) (順位) (忠実度) (関連性) (有害)
※ 検索段階と生成段階の切り分けが評価改善のカギ
検索品質の評価メトリクス
検索品質のメトリクスは、「本当に関連する情報が上位に来ているか」を測ります。代表的な指標としてContext Precision、Context Recall、MRR(Mean Reciprocal Rank)の3つを押さえておけば、基礎的な診断は可能です。
| メトリクス | 定義 | 計算方法 | 理想値 | 改善手段 |
|---|---|---|---|---|
| Context Precision | 取得チャンクのうち関連する割合 | 関連チャンク数 / 取得チャンク数 | 0.8以上 | リランキング、メタデータフィルタ |
| Context Recall | 必要情報が取得できた割合 | 取得された関連情報 / 正解情報 | 0.9以上 | ハイブリッド検索、クエリ拡張 |
| MRR | 正解が何位で取得されたか | 1 / 正解チャンクの順位 | 0.7以上 | リランキング、エンベディング改良 |
| Hit Rate@K | 上位K件に正解が含まれる割合 | 正解を含む質問数 / 全質問数 | 0.9以上 | K値調整、検索強化 |
# RagasでContext Precisionを計測する
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import context_precision
data = {
"question": ["有給休暇の付与ルールは?"],
"contexts": [["勤続半年で10日付与。その後勤続年数に応じて増加します。"]],
"ground_truth": ["勤続半年で10日、その後年数ごとに1〜2日増加"],
}
ds = Dataset.from_dict(data)
result = evaluate(ds, metrics=[context_precision])
print(result)
生成品質の評価メトリクス
生成品質のメトリクスは「回答が検索結果に忠実か」「質問にちゃんと答えているか」「有害な内容を含まないか」を測ります。Faithfulness(忠実度)とAnswer Relevancy(関連性)は、ほとんどのRAG評価で必ず見るべき2大指標です。
| メトリクス | 定義 | 計算方法 | 理想値 | 改善手段 |
|---|---|---|---|---|
| Faithfulness | 回答がコンテキストに基づくか | コンテキスト支持率(LLM-as-Judge) | 0.9以上 | プロンプト改善、出典強制 |
| Answer Relevancy | 回答が質問に合致するか | 質問-回答の埋め込み類似度 | 0.85以上 | プロンプト設計、検索強化 |
| Answer Correctness | 正解との一致度 | 正解との意味的一致(LLM判定) | 0.8以上 | 総合的改善 |
| Harmfulness | 有害内容を含むか | 有害検知モデル / LLM判定 | 0.0 | ガードレール、フィルタ |
# RagasでFaithfulnessを計測する
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
data = {
"question": ["育児休業の申請は何日前までに必要ですか?"],
"answer": ["育児休業の申請は開始予定日の1ヶ月前までに人事部へ提出が必要です。"],
"contexts": [[
"育児休業を希望する社員は、開始予定日の1ヶ月前までに所定の申請書を人事部へ提出する。"
]],
"ground_truth": ["開始の1ヶ月前までに人事部へ申請"],
}
ds = Dataset.from_dict(data)
result = evaluate(ds, metrics=[faithfulness, answer_relevancy])
print(result)
評価ツールの比較
RAG評価のツールはここ数年で選択肢が大きく広がりました。代表的な4つを比較し、自社要件に合うものを選びましょう。
| ツール | 対応メトリクス | OSS/商用 | LLM-as-Judge | CI/CD連携 | 日本語対応 |
|---|---|---|---|---|---|
| Ragas | RAG特化メトリクス | OSS | あり | 容易(Python API) | 対応(プロンプト調整推奨) |
| DeepEval | 幅広いLLMアプリ評価 | OSS | あり | pytest統合 | 対応 |
| TruLens | Triad評価、可観測性 | OSS | あり | ダッシュボード内蔵 | 対応 |
| LangSmith | LangChainとの統合 | 商用(無料枠あり) | あり | SaaS完結 | 対応 |
Ragasは軽量でRAGに特化しているため、まず入れてみるには最適な選択肢です。DeepEvalはpytestとの統合が強く、CI/CDにすっきり組み込みたい現場と相性が良いでしょう。TruLensは可観測性のダッシュボードが充実しており、運用フェーズでのメトリクス継続監視に向きます。LangSmithはLangChainを使っているなら最小の手間で導入できる商用ソリューションです。
評価パイプラインの設計と運用
評価メトリクスを導入したら、次はテストデータセットの整備と評価の自動化です。まずは本番で想定される質問を20〜50件手動で作成し、期待する回答と参照すべき文書(正解ドキュメント)を紐づけます。LLMに「このコンテキストから質問と模範回答を生成してください」と依頼することで、テストケースを半自動で増やすことも可能です。
評価は単発で終わらせず、CI/CDに組み込んでコード変更やプロンプト変更のたびに自動実行するのが理想です。Faithfulness 0.85以上、Context Precision 0.8以上といった閾値を設定し、基準を下回ったらマージをブロックするルールを整えると、RAGの品質回帰を早期に検出できます。
# 評価パイプラインの自動実行スクリプト
import json
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision
def run_eval(test_cases: list, threshold: dict) -> bool:
ds = Dataset.from_list(test_cases)
result = evaluate(ds, metrics=[faithfulness, answer_relevancy, context_precision])
scores = result.to_pandas().mean().to_dict()
print("Scores:", scores)
failed = [k for k, v in threshold.items() if scores.get(k, 0) < v]
if failed:
print(f"NG: しきい値未達のメトリクス = {failed}")
return False
print("OK: すべてのメトリクスが閾値を満たしました")
return True
with open("testset.json", encoding="utf-8") as f:
cases = json.load(f)
ok = run_eval(cases, {
"faithfulness": 0.85,
"answer_relevancy": 0.85,
"context_precision": 0.80
})
exit(0 if ok else 1)
まとめ――「測れないものは改善できない」
- RAGは検索と生成の2段階に分けて評価することで原因切り分けが可能
- 最重要メトリクスはContext PrecisionとFaithfulnessの2つ
- Ragas、DeepEval、TruLens、LangSmithから要件に合うツールを選ぶ
- 評価パイプラインをCI/CDに組み込み、品質回帰を早期検知する体制を構築
DE-STKでは評価データセットの構築からCI/CD統合、継続的なRAG品質モニタリングまでを伴走支援しています。RAGの品質が安定しない組織はぜひご相談ください。
よくある質問(FAQ)
Q. RAGの評価で最も重要なメトリクスは?
Faithfulness(回答が検索結果に忠実か)とContext Precision(検索結果が質問に関連しているか)の2つが最重要です。Faithfulnessが低ければハルシネーション、Context Precisionが低ければ検索精度に問題があることを示します。この2つを起点に、必要に応じてRecallやRelevancyを追加していくのが効率的な評価設計です。
Q. RAGの評価テストデータはどう作成すべきですか?
本番で想定される質問パターンを20〜50件手動で作成し、期待する回答と参照すべき文書を紐づけます。LLMを使ってテストケースを自動生成し、人間がレビューする方法も効率的です。少数でも多様性を担保し、典型質問とエッジケースの両方をカバーすることを意識してください。
Q. Ragasとは何ですか?
RAGシステムの品質を自動評価するオープンソースフレームワークです。Faithfulness、Answer Relevancy、Context Precision、Context RecallなどのRAG特化メトリクスを、LLM-as-Judgeで自動計測できます。Pythonから数行で呼び出せるため、PoCからCI/CD統合まで幅広いフェーズで使いやすいのが特徴です。