はじめに

RAGを構築して社内ドキュメント検索やFAQボットをリリースした。ユーザーからは「まあまあ使える」という声もあれば「的外れな回答が返ってくる」という声もある。

プロンプトを修正してみた。チャンク分割の方法を変えてみた。Embeddingモデルを変えてみた。でも、改善されたのかどうかが分からない。

こうした「なんとなく良さそう」「なんとなく悪くなった気がする」という状態でRAGを運用していませんか？

本記事では、LLM-as-a-Judgeという手法とRagasというOSSフレームワークを使い、Amazon Bedrock上のRAGパイプラインを定量的に評価する方法を解説します。

なぜRAGの評価が難しいのか

従来のNLP評価手法(BLEU, ROUGEなど)は、正解文と生成文の単語レベルの一致度を測るものです。
しかしRAGの回答は自然言語であり、同じ意味でも表現が異なることが多いため、これらの指標では正確に品質を測れません。

さらにRAGには検索と生成の2つのステップがあり、問題の切り分けが困難です。

回答の品質が低い
  ├── 検索が悪い？ → 関連文書を取得できていない
  └── 生成が悪い？ → 文書はあるのに回答に活かせていない

「回答がイマイチ」という事象だけでは、チャンク分割を見直すべきなのか、プロンプトを改善すべきなのか判断できません。

LLM-as-a-Judgeとは

LLM-as-a-Judgeは、LLM自身に回答の品質を採点させる手法です。
人間の評価者の代わりにLLMが「この回答は質問に対して適切か」「根拠に基づいているか」を判定します。

従来の評価手法との比較

手法	メリット	デメリット
人手評価	最も正確	コストが高い、スケールしない
BLEU/ROUGE	自動化できる	意味的な一致を測れない
LLM-as-a-Judge	意味レベルで自動評価	Judge自体のバイアスに注意が必要

LLM-as-a-Judgeは人手評価との相関が高いことが複数の研究で報告されており、RAG評価の実用的なアプローチとして注目されています。

注意点

Judgeモデルの品質が評価精度に直結する(高性能なモデルを使うべき)
自身が生成した回答を高く評価しやすいバイアスがある(Self-Enhancement Bias)
回答の順番によるバイアスがある(Position Bias)

これらのバイアスを理解した上で活用することが重要です。

Ragasとは ― RAG評価を「分解」するフレームワーク

Ragas(Retrieval Augmented Generation Assessment)は、RAGパイプラインの品質をコンポーネント単位で評価するPython OSSフレームワークです。

Ragasの最大の強みは、検索の品質と生成の品質を分離して評価できる点です。

主要メトリクス

メトリクス	評価対象	何を測るか	値の意味
Faithfulness	生成	回答が検索された文書に基づいているか	低い→ハルシネーションの可能性
Answer Relevancy	生成	回答が質問に対して的確か	低い→質問と無関係な回答
Context Precision	検索	関連性の高い文書が上位に来ているか	低い→ランキングの問題
Context Recall	検索	正解に必要な情報がすべて検索できているか	低い→検索漏れ

この4つのメトリクスにより、「検索が悪いのか、生成が悪いのか」を定量的に切り分けられます。

評価結果から改善アクションへ

スコアパターン	推定される問題	改善アクション
Faithfulnessだけ低い	生成時のハルシネーション	プロンプト改善、temperatureの調整
Context Recallが低い	検索漏れ	チャンク戦略の見直し、Embeddingモデル変更
Context Precisionが低い	不要な文書が混入	top_kの調整、リランキングの導入
Answer Relevancyが低い	回答が質問とずれている	プロンプトの指示を明確化

構成概要 ― BedrockとRagasの組み合わせ

アーキテクチャ

なぜこの組み合わせか？

Bedrock Knowledge Baseだけでは「検索品質」と「生成品質」の切り分けができない
RagasがBedrockの回答とコンテキストを受け取り、コンポーネント別に評価を行う
評価のJudgeモデルとしてもBedrock上のClaudeを利用できるため、AWS内で完結する

ハンズオン ― Bedrock Knowledge BaseのRAGをRagasで評価する

前提条件

AWSアカウントとクレデンシャル設定済み
Bedrock Knowledge Baseが構築済み(未構築の場合は公式ガイドを参照)
Bedrockモデルアクセスが有効(Claude, Titanなど)
Python 3.10以上

Bedrockの一部モデルは推論プロファイルID(例: apac.anthropic.claude-3-5-sonnet-20240620-v1:0)での呼び出しが必要です。従来のモデルARN形式(arn:aws:bedrock:...)ではValidationExceptionが発生する場合があります。利用可能な推論プロファイルはaws bedrock list-inference-profilesで確認できます。

Step 1: 環境セットアップ

mkdir bedrock-ragas-eval
cd bedrock-ragas-eval
python3 -m venv .venv
source .venv/bin/activate

pip install ragas langchain-aws boto3 pandas

Step 2: テストデータセットを準備する

評価には「質問」「正解(Ground Truth)」のペアが必要です。実際のユースケースに合わせて作成してください。

# test_dataset.py
"""テストデータセットの定義"""

test_questions = [
    "Amazon S3のストレージクラスにはどのような種類がありますか？",
    "S3のバージョニング機能とは何ですか？",
    "S3のライフサイクルポリシーで何ができますか？",
    "S3のクロスリージョンレプリケーションの設定方法は？",
    "S3 Glacierからデータを復元する方法は？",
]

ground_truths = [
    "S3にはS3 Standard、S3 Intelligent-Tiering、S3 Standard-IA、S3 One Zone-IA、S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archiveの7つのストレージクラスがあります。",
    "バージョニングはオブジェクトの複数バージョンを同一バケットに保持する機能です。誤削除や上書きからの復旧が可能になります。",
    "ライフサイクルポリシーを使用すると、オブジェクトのストレージクラスの自動移行や、有効期限切れオブジェクトの自動削除ができます。",
    "レプリケーション元バケットでバージョニングを有効にし、レプリケーションルールで送信先バケットとIAMロールを指定して設定します。",
    "復元リクエストをAPIまたはコンソールから発行します。Glacier Flexible Retrievalでは迅速取り出し(1-5分)、標準取り出し(3-5時間)、大容量取り出し(5-12時間)の3つのオプションがあります。",
]

テストデータセットの品質が評価精度に直結します。実際のユーザーが投げそうな質問を10〜50件程度用意するのが実用的です。

Step 3: Bedrock Knowledge Baseから回答を取得する

# retrieve_answers.py
"""Bedrock Knowledge Baseから回答とコンテキストを取得"""

import boto3


def retrieve_and_generate(knowledge_base_id, model_arn, question, custom_prompt=None):
    """Knowledge Baseに質問してRAGの回答とコンテキストを取得する"""
    client = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")

    kb_config = {
        "knowledgeBaseId": knowledge_base_id,
        "modelArn": model_arn,
        "retrievalConfiguration": {
            "vectorSearchConfiguration": {
                "numberOfResults": 5
            }
        },
    }

    # カスタムプロンプトが指定された場合は生成設定に追加
    if custom_prompt:
        kb_config["generationConfiguration"] = {
            "promptTemplate": {
                "textPromptTemplate": custom_prompt
            }
        }

    response = client.retrieve_and_generate(
        input={"text": question},
        retrieveAndGenerateConfiguration={
            "type": "KNOWLEDGE_BASE",
            "knowledgeBaseConfiguration": kb_config,
        },
    )

    # 回答テキスト
    answer = response["output"]["text"]

    # 検索されたコンテキスト(引用元)
    contexts = []
    for citation in response.get("citations", []):
        for ref in citation.get("retrievedReferences", []):
            text = ref.get("content", {}).get("text", "")
            if text:
                contexts.append(text)

    # カスタムプロンプト使用時はcitationsにcontextが含まれない場合がある
    # その場合はretrieve APIで別途取得する
    if not contexts:
        retrieve_response = client.retrieve(
            knowledgeBaseId=knowledge_base_id,
            retrievalQuery={"text": question},
            retrievalConfiguration={
                "vectorSearchConfiguration": {
                    "numberOfResults": 5
                }
            },
        )
        for result in retrieve_response.get("retrievalResults", []):
            text = result.get("content", {}).get("text", "")
            if text:
                contexts.append(text)

    return answer, contexts


def collect_rag_responses(knowledge_base_id, model_arn, questions, custom_prompt=None):
    """全テスト質問に対してRAGの回答を収集する"""
    answers = []
    contexts = []

    for i, question in enumerate(questions):
        print(f"[{i+1}/{len(questions)}] {question[:40]}...")
        answer, ctx = retrieve_and_generate(
            knowledge_base_id, model_arn, question, custom_prompt
        )
        answers.append(answer)
        contexts.append(ctx)

    return answers, contexts

Step 4: Ragasで評価を実行する

# evaluate_rag.py
"""RagasによるRAG評価の実行"""

from ragas import evaluate
from ragas.metrics import (
    Faithfulness,
    ResponseRelevancy,
    LLMContextPrecisionWithoutReference,
    LLMContextRecall,
)
from ragas.llms import LangchainLLMWrapper
from ragas.embeddings import LangchainEmbeddingsWrapper
from ragas.dataset_schema import SingleTurnSample, EvaluationDataset
from langchain_aws import ChatBedrock, BedrockEmbeddings

from test_dataset import test_questions, ground_truths
from retrieve_answers import collect_rag_responses


def main():
    # ===== 設定 =====
    knowledge_base_id = "<YOUR_KNOWLEDGE_BASE_ID>"
    model_arn = "<YOUR_INFERENCE_PROFILE_ID>"  # 例: apac.anthropic.claude-3-5-sonnet-20240620-v1:0
    region = "ap-northeast-1"

    # ===== Step 1: RAG回答を収集 =====
    print("RAG回答を収集中...")
    answers, contexts = collect_rag_responses(
        knowledge_base_id, model_arn, test_questions
    )

    # ===== Step 2: Ragasデータセットを構築 =====
    samples = []
    for q, a, c, gt in zip(test_questions, answers, contexts, ground_truths):
        sample = SingleTurnSample(
            user_input=q,
            response=a,
            retrieved_contexts=c,
            reference=gt,
        )
        samples.append(sample)

    eval_dataset = EvaluationDataset(samples=samples)

    # ===== Step 3: Judge用のLLMとEmbeddingを設定 =====
    judge_llm = LangchainLLMWrapper(
        ChatBedrock(
            model_id="<YOUR_INFERENCE_PROFILE_ID>",  # 例: apac.anthropic.claude-3-5-sonnet-20241022-v2:0
            region_name=region,
            model_kwargs={"max_tokens": 4096},
        )
    )
    judge_embeddings = LangchainEmbeddingsWrapper(
        BedrockEmbeddings(
            model_id="amazon.titan-embed-text-v2:0",
            region_name=region,
        )
    )

    # ===== Step 4: 評価メトリクスを定義 =====
    metrics = [
        Faithfulness(),
        ResponseRelevancy(),
        LLMContextPrecisionWithoutReference(),
        LLMContextRecall(),
    ]

    # ===== Step 5: 評価実行 =====
    print("Ragas評価を実行中...")
    results = evaluate(
        dataset=eval_dataset,
        metrics=metrics,
        llm=judge_llm,
        embeddings=judge_embeddings,
    )

    # ===== 結果表示 =====
    print("\n" + "=" * 50)
    print("評価結果")
    print("=" * 50)

    df = results.to_pandas()
    metric_columns = [
        "faithfulness",
        "answer_relevancy",
        "llm_context_precision_without_reference",
        "context_recall",
    ]
    for col in metric_columns:
        if col in df.columns:
            print(f"  {col}: {df[col].mean():.3f}")

    # 質問ごとの詳細
    print("\n質問ごとの詳細:")
    print(df[["user_input"] + metric_columns].to_string())

    # CSVに保存
    df.to_csv("evaluation_results.csv", index=False)
    print("\n結果をevaluation_results.csvに保存しました")


if __name__ == "__main__":
    main()

Step 5: 評価を実行する

python evaluate_rag.py

Ragas v0.4系ではragas.metricsからのimportやLangchainLLMWrapperに対してDeprecationWarningが表示されますが、動作に問題はありません。将来のv1.0でragas.metrics.collectionsへの移行が予定されています。

評価結果の例

==================================================
評価結果
==================================================
  faithfulness: 0.858
  answer_relevancy: 0.673
  llm_context_precision_without_reference: 0.700
  context_recall: 0.800

この結果から以下のことが読み取れます。

メトリクス	スコア	解釈
Faithfulness	0.858	回答は概ね検索文書に基づいている(ハルシネーション少)
Answer Relevancy	0.673	回答が質問に対してやや冗長・不正確な傾向
Context Precision	0.700	検索結果の上位に関連文書が来ているが改善余地あり
Context Recall	0.800	必要な情報は概ね取得できている

→ この場合、検索よりも生成側に改善余地があると判断できます。特にAnswer Relevancyが0.673と低く、回答が冗長になっている可能性があります。またFaithfulnessも0.858で、検索結果にない情報を補足してしまうケースがありそうです。プロンプトを調整して改善を試みましょう。

Step 6: 改善して再評価する(評価サイクル)

生成側のスコア(Faithfulness, Answer Relevancy)を改善するため、プロンプトテンプレートをカスタマイズします。

Step 3で作成したcollect_rag_responsesはcustom_prompt引数を受け取れるようになっています。カスタムプロンプトを定義して渡すだけです。

IMPROVED_PROMPT = """あなたはAWSの技術ドキュメントに基づいて質問に回答するアシスタントです。
以下のルールに従って回答してください:

- 検索結果に含まれる情報のみを使用し、推測や補足は行わないでください
- 質問に対して簡潔かつ的確に回答してください
- 箇条書きを活用し、要点を明確にしてください

検索結果:
$search_results$

ユーザーの質問: $query$

上記の検索結果のみに基づいて、簡潔に回答してください。"""

# custom_prompt引数にプロンプトを渡して再実行
answers, contexts = collect_rag_responses(
    knowledge_base_id, model_arn, test_questions, custom_prompt=IMPROVED_PROMPT
)

同じスクリプトで再評価した結果:

メトリクス                                  改善前    改善後    差分
faithfulness                               0.858    0.906   +0.048 ↑
answer_relevancy                           0.673    0.689   +0.016 ↑
llm_context_precision_without_reference    0.700    0.800   +0.100 ↑
context_recall                             0.800    0.800    0.000 →

Faithfulnessが0.858→0.906に改善しました。「検索結果に含まれる情報のみを使用」という指示によりハルシネーションが減少したことが数値に表れています。Context Precisionも0.700→0.800に向上しました。

一方、Answer Relevancyは0.673→0.689とほぼ横ばいでした。回答の簡潔さはまだ改善の余地があります。この場合、次の改善サイクルとして「回答は3文以内で」といったより具体的な制約を加える、あるいはモデル自体を変更するなどのアプローチが考えられます。

このように、どの施策がどのメトリクスに効いたか(あるいは効かなかったか)を定量的に把握できるのがRagas評価の最大の価値です。

カスタムプロンプト使用時はretrieveAndGenerateのcitationsにコンテキストが含まれない場合があります。その際はretrieve APIで別途コンテキストを取得してください。

どこに導入できるか ― 実践ユースケース

1. 開発フェーズ: パラメータチューニングのA/Bテスト

チャンクサイズ、top_k、プロンプトなどのパラメータ変更の効果を定量比較
「なんとなく良くなった」ではなく「Faithfulnessが0.85→0.92に改善」と説明できる

2. リリース判定: 品質ゲートとしての活用

CI/CDパイプラインに評価を組み込み、品質スコアが閾値を下回る場合はデプロイをブロックします。

# ci_quality_gate.py
"""CI/CDパイプラインでの品質ゲート(例)"""

THRESHOLDS = {
    "faithfulness": 0.80,
    "answer_relevancy": 0.80,
    "llm_context_precision_without_reference": 0.70,
    "context_recall": 0.70,
}

def check_quality_gate(results):
    """評価結果が閾値を満たすか判定する"""
    df = results.to_pandas()
    passed = True
    for metric, threshold in THRESHOLDS.items():
        if metric not in df.columns:
            continue
        score = df[metric].mean()
        status = "PASS" if score >= threshold else "FAIL"
        if score < threshold:
            passed = False
        print(f"  {metric}: {score:.3f} (threshold: {threshold}) [{status}]")
    return passed

3. 運用監視: 定期評価による品質劣化検知

ナレッジベースのドキュメントが追加・更新されると、検索品質が変動する可能性があります。週次や月次で評価を回し、スコアの推移をモニタリングします。

対象	検知できること
ドキュメント追加後	新規文書がノイズになっていないか
モデル更新後	生成品質が維持されているか
プロンプト変更後	意図した改善が実現されているか

4. 社内RAG: FAQボット・ナレッジ検索の継続改善

社内RAGではユーザーからのフィードバック(👍/👎)を収集し、低評価の質問をテストデータセットに追加していくことで、評価の精度と網羅性を継続的に高められます。

ユーザーフィードバック → テストデータセット追加 → Ragas評価 → 改善 → 再評価

まとめ

本記事では、Amazon BedrockのKnowledge BaseとRagasを組み合わせたRAG評価パイプラインを紹介しました。

ポイント:

LLM-as-a-JudgeはLLMが回答を自動採点する手法で、人手評価に近い精度を自動化できる
Ragasは検索と生成を分離して評価でき、問題の原因特定に直結する
Bedrock + Ragasの組み合わせにより、AWS内で完結する評価パイプラインが構築できる
開発時のA/Bテスト、リリース判定、運用監視などRAGのライフサイクル全体で活用できる

RAGの品質管理を「なんとなく」から「定量的」に変えることで、改善サイクルが回り始めます。まずは小さなテストデータセットから始めてみてください。