ストーリー
田
田中VPoE
Step 4まででRAGの構築と最適化を学んだ。Step 5では「評価と運用」に取り組む。構築したRAGが本当に使えるかどうかを定量的に測定する方法だ
あなた
精度は評価データセットで測ればいいんじゃないですか?
あ
田
田中VPoE
Precision@5やRecallは検索の精度だ。RAGシステム全体の品質はもっと多角的に評価する必要がある。回答は根拠に基づいているか(Faithfulness)、検索結果は質問に関連しているか(Relevance)、コンテキストは正確な情報を含んでいるか(Context Precision)
田
田中VPoE
RAGASというフレームワークがデファクトスタンダードになりつつある。まずはRAGASの評価指標を理解しよう
RAGAS(RAG Assessment)
概要
RAGASはRAGシステムの品質を多角的に評価するフレームワークです。LLMを使って自動評価を行うため、大規模なテストセットでも効率的に評価できます。
4つの主要指標
| 指標 | 評価対象 | 説明 | 値域 |
|---|
| Faithfulness | 回答の忠実性 | 回答が検索結果(コンテキスト)に基づいているか | 0〜1 |
| Answer Relevance | 回答の関連性 | 回答がユーザーの質問に対して適切か | 0〜1 |
| Context Precision | コンテキストの精度 | 検索結果の中で関連する情報が上位にあるか | 0〜1 |
| Context Recall | コンテキストの網羅性 | 回答に必要な情報がすべて検索結果に含まれているか | 0〜1 |
RAGASの評価対象:
質問(Question)──→ 検索結果(Contexts)──→ 回答(Answer)
↑
正解(Ground Truth)
Faithfulness: 回答 ← コンテキスト(根拠に基づいているか)
Answer Relevance: 回答 ← 質問(質問に答えているか)
Context Precision: コンテキスト ← 質問(検索結果は関連しているか)
Context Recall: コンテキスト ← 正解(必要な情報が揃っているか)
各指標の詳細
Faithfulness(忠実性)
Faithfulness評価の仕組み:
Step 1: 回答から主張(claims)を抽出
回答: "RAGではベクトルDBに検索し、コサイン類似度で関連文書を取得します"
→ 主張1: "RAGではベクトルDBに検索する"
→ 主張2: "コサイン類似度で関連文書を取得する"
Step 2: 各主張がコンテキストに基づいているか判定
→ 主張1: コンテキストに記述あり → Supported
→ 主張2: コンテキストに記述あり → Supported
Faithfulness = Supported数 / 総主張数 = 2/2 = 1.0
| スコア | 解釈 |
|---|
| 0.9〜1.0 | 回答がほぼ完全にコンテキストに基づいている |
| 0.7〜0.9 | 一部に根拠のない主張が含まれる |
| 0.7未満 | ハルシネーションが多い。改善が必要 |
Answer Relevance(回答の関連性)
Answer Relevance評価の仕組み:
Step 1: 回答から仮想質問を生成
回答: "Qdrantはコサイン類似度とユークリッド距離をサポートしています"
→ 仮想質問1: "Qdrantがサポートする距離メトリクスは?"
→ 仮想質問2: "Qdrantで使える類似度計算方法は?"
Step 2: 仮想質問と元の質問のEmbedding類似度を計算
元の質問: "Qdrantの距離メトリクスは何がありますか?"
→ 類似度1: 0.95
→ 類似度2: 0.88
Answer Relevance = 類似度の平均 = (0.95 + 0.88) / 2 = 0.915
Context Precision / Recall
| 指標 | 計算方法 | 改善策 |
|---|
| Context Precision | 上位の検索結果に関連情報が集中しているか | Rerankingの改善 |
| Context Recall | 正解に含まれる情報が検索結果でカバーされているか | 検索のRecall改善 |
評価データセットの設計
テストセットの構成
| 要素 | 必須 | 説明 |
|---|
| question | 必須 | テスト質問 |
| ground_truth | 必須 | 正解(期待される回答) |
| contexts | 自動 | RAGが検索したコンテキスト(自動取得) |
| answer | 自動 | RAGが生成した回答(自動取得) |
テストセット作成のベストプラクティス
| 項目 | 推奨 |
|---|
| 件数 | 最低50件、理想は100〜200件 |
| カバレッジ | ドキュメント種別、質問タイプを網羅 |
| 難易度 | 簡単(事実検索)〜難しい(複合推論)を混在 |
| 定期更新 | ドキュメント更新に合わせてテストセットも更新 |
| 実際のクエリ | 本番のユーザークエリログから作成すると現実的 |
その他の評価手法
LLM-as-a-Judge
LLMを評価者として使う手法です。RAGASもこのアプローチを採用しています。
| 評価方法 | 概要 | 利点 | 注意点 |
|---|
| Pointwise | 1つの回答を独立に評価 | シンプル、高速 | 絶対基準の設定が難しい |
| Pairwise | 2つの回答を比較評価 | 相対評価で直感的 | 組み合わせ数が増える |
| Reference-based | 正解と比較して評価 | 客観的 | 正解の作成コストが高い |
人間による評価
| 評価軸 | 基準 |
|---|
| 正確性 | 回答の事実が正しいか |
| 完全性 | 質問に対して十分な情報を含んでいるか |
| 有用性 | ユーザーにとって役に立つ回答か |
| 安全性 | 不適切・有害な内容を含んでいないか |
「自動評価は効率的だが万能ではない。定期的な人間によるスポットチェックも欠かせない。特にFaithfulnessの評価は、LLM自身の判断に限界がある場合がある」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| RAGAS | Faithfulness、Answer Relevance、Context Precision、Context Recallの4指標 |
| Faithfulness | 回答がコンテキストに基づいているか。ハルシネーション検出 |
| 評価データセット | 50〜200件、多様な質問タイプを網羅、定期更新 |
| LLM-as-a-Judge | LLMを自動評価者として活用。人間評価と併用 |
チェックリスト
次のステップへ
次は「RAGモニタリング」を学びます。本番運用中のRAGシステムの品質を継続的に監視する方法を理解しましょう。
推定読了時間: 30分