第8章: RAG評価 — Ragas・合成データ・LLM-as-Judge

なぜ評価なしの本番投入は必ず事故るのか

「RAGは動いている気がする」だけで本番投入されたシステムは、かなりの高確率で事故ります。 その理由は単純で、RAGは「検索の良し悪し」と「生成の良し悪し」の2軸で失敗する可能性があり、どちらの原因で壊れているかを指標なしでは切り分けられないからです。

graph TD
  Q[ユーザーの苦情: 回答が間違っている] --> D{どこが原因？}
  D --> R1[検索が無関係chunkを返した\n Retrieval問題]
  D --> R2[検索は正しいのにLLMが嘘を言った\n Faithfulness問題]
  D --> R3[質問を誤解した\n Query解釈問題]
  R1 --> F1[Chunking改善\n Embedding変更\n ハイブリッド化]
  R2 --> F2[プロンプト厳格化\n Rerank強化\n モデル変更]
  R3 --> F3[Query変換導入\n HyDE/Multi-query]

  style D fill:#f97316,stroke:#ea580c,color:#fff

Ragasのコア4指標

Ragas はRAG評価のOSSデファクトで、Exploding Gradientsが開発しています。 コア指標はRetrieval側2つ、Generation側2つの4指標で、それぞれ明確な役割があります。

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset

# テストデータ（最低20-50件のQA + Ground Truth）
test_data = {
    "question": ["返品可能期間は？", "送料無料の条件は？", ...],
    "answer":   [generated_answer_1, generated_answer_2, ...],
    "contexts": [retrieved_chunks_1, retrieved_chunks_2, ...],
    "ground_truth": [gt_1, gt_2, ...],
}
dataset = Dataset.from_dict(test_data)

result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result)
# {'faithfulness': 0.88, 'answer_relevancy': 0.91,
#  'context_precision': 0.82, 'context_recall': 0.79}

Faithfulness（忠実性） — ハルシネーション検出の要

Faithfulnessは「生成された回答の各主張が、取得したコンテキストに裏付けられているか」を測ります。 Ragasは回答を複数の「主張（claim）」に分解し、それぞれがコンテキストから導けるかをLLM-as-Judgeで検証します。

1. 回答を主張に分解: 「返品は30日以内で、返金は2週間以内。」→ 主張1「返品期間は30日」主張2「返金期間は2週間」
2. 各主張をコンテキストと照合: LLMに「主張Xはコンテキストで裏付けられるか？」を問う
3. 裏付けられた主張の割合 = Faithfulness

ARES — 統計的信頼区間付き評価

Ragasは手軽だが、LLM-as-Judgeのバイアスで揺れる弱点があります。 ARES（NAACL 2024） は Stanford の研究グループが提案した、より厳密な評価フレームワークです。

合成QAデータ + ファインチューンされたジャッジモデル3種 + PPI（Prediction-Powered Inference）を組み合わせ、 統計的信頼区間付きでRAG品質を評価します。 必要な人手アノテーションは約150件のみで、Ragas比で Context Relevance +59.3pt、Answer Relevance +14.4pt の精度向上を報告しています。

主要評価ツール比較

合成データで評価セットを作る

「評価したいが、Ground Truth付きQAペアが20件もない」という声をよく聞きます。 ここで使えるのが合成データ生成。 Ragasや DeepEval は自社文書から評価用QAペアを自動生成する機能を持っています。

# Ragasのtest set generation（OpenAI 4o-miniなどで実行）
from ragas.testset import TestsetGenerator
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

generator_llm = ChatOpenAI(model="gpt-4o-mini")
critic_llm = ChatOpenAI(model="gpt-4o")
embeddings = OpenAIEmbeddings()

generator = TestsetGenerator.from_langchain(
    generator_llm=generator_llm,
    critic_llm=critic_llm,
    embeddings=embeddings,
)

testset = generator.generate_with_langchain_docs(
    documents=docs,
    test_size=50,
    distributions={
        "simple": 0.5,      # 単一チャンクで答えられる
        "reasoning": 0.25,  # 推論が必要
        "multi_context": 0.25,  # 複数chunkが必要
    },
)

合成データは完璧ではありませんが、人手アノテーションと組み合わせることで大幅に評価コストを下げられます。 合成データで方向性を掴み、重要な10〜20件だけ人手でレビュー・修正するのが実務的なバランスです。

日本語RAG評価データセット

日本語でRAGを評価するなら、hotchpotch氏が整備した2つのデータセットが事実上の標準です。

LLM-as-Judgeの3大落とし穴

Ragas含む多くの評価フレームワークはLLM-as-Judge（GPT-4/Claudeに関連性・忠実性をスコアさせる）に依存しています。 便利ですが、既知のバイアスがあるため鵜呑みにしてはいけません。

1. Position bias: 選択肢の提示順で評価が変わる（最初の選択肢に有利）
2. Verbosity bias: 長い回答を「詳細で良い」と過大評価
3. Self-enhancement bias: 同じモデル系列の出力を優遇する

対策として、(1) Pairwise比較で両方向の順序を試す、(2) Rubricを明示したプロンプトにする、(3) 複数モデル（GPT-4 + Claude + Gemini）のアンサンブルでジャッジする、といった工夫が有効です。

評価ワークフロー — 最小構成の立ち上げ方

1. 20〜50件のゴールデンQAを人手で作る（想定ユーザー質問＋期待回答＋正解ソース）
2. 合成データで100〜500件に増強（Ragas testset generation）
3. 現在のRAGパイプラインを評価セットで回し、Ragas 4指標のベースラインを取得
4. 改善施策（Chunking変更、Rerank追加、Contextual Retrieval適用等）ごとに同じ評価セットで再計測
5. Phoenix/LangSmithでトレースを観測し、特定の失敗ケースを深掘り
6. 本番トラフィックから定期的にサンプリングして評価セットに追加（データドリフト対策）

次章への導線

評価基盤ができたら、精度を更に押し上げるAdvanced RAG技術を導入する準備が整いました。 次章では、2024〜2026年に台頭したGraphRAG、Self-RAG、Corrective RAG、Agentic RAGといった高度パターンを、実装コストと適合ケースとともに詳説します。