もうRAG評価で迷わない！Ragas最新メトリクス解説と実践的改善ガイド
- Shogo Umeda
- 10月2日
- 読了時間: 10分
はじめに
RAG（Retrieval-Augmented Generation）は、外部知識を参照してLLMの回答精度を向上させる強力な技術です。
しかし、多くの開発者が「RAGを作ったはいいものの、その性能をどう客観的に評価すればいいのか分からない」という壁に直面しています。
検索結果に不要な情報が混じっている気がする。
たまに事実と異なる回答（ハルシネーション）を生成してしまう。
改善したいが、検索と生成のどちらがボトルネックなのか切り分けられない。
この記事では、RAG評価で広く使われているオープンソースのライブラリRagasを用いて、これらの課題を解決する方法を解説します。
Ragasの主要な評価メトリクスを理解し、自作RAGシステムの課題を特定して改善サイクルを回すための、具体的なノウハウを掴んでいきましょう。
なお、Ragasは標準メトリクス中心の評価フレームワークであり、ドメイン固有の要件（トーン、規制対応など）にはカスタム評価が必要になる場合があります（本稿末尾の「Ragasでカバーしきれない観点とカスタム評価」を参照してください）。
本稿の対象読者
RAG/LLMアプリケーションの開発・評価・運用に携わる方
RAGの品質を定量的に測定し、継続的に改善したい方
なぜRAG評価は難しいのか？
RAGシステムが期待通りに機能しない原因は、主に以下の3つのいずれかに分類できます。
ノイズ（Noise）: 質問と無関係な情報を検索してしまい、回答の精度が下がる。
回収漏れ（Missed Information）: 回答に必要な重要な情報を取り逃してしまい、不完全な回答になる。
幻覚（Hallucination）: 検索した情報から逸脱し、事実に基づかない回答を生成してしまう。
これらの原因を特定するには、RAGのパイプラインを「検索（Retrieval）」と「生成（Generation）」のフェーズに分解し、それぞれの品質を測るメトリクスが必要です。それを実現するのがRagasです。
Ragasとは
Ragasとは、LLMを利用したRAGパイプラインの健全性を測るための様々なメトリクスを提供します。
ここでは特に重要な5つのコアメトリクスを、「検索品質」と「生成品質」の2つのカテゴリに分けて解説します。
なお、Ragasには本稿で扱っていないメトリクス（例: `Context Entities Recall`、`Noise Sensitivity`、マルチモーダル関連 など）も複数存在します。
本稿では、RAGの実務で特に使用頻度が高いメトリクスに絞って解説しています。メトリクス一覧は公式の「Available Metrics」をご参照ください。
Ragasへの入力
Ragasで検索、生成の品質を測るためには以下のようなデータを入力する必要があります。
利用するメトリクスによって必須入力が異なります。
question: ユーザーからの質問
answer: RAGシステムが生成した回答
contexts: 回答の根拠として検索されたコンテキスト
ground_truth: 人間が用意した正解の回答
検索品質を測る
まずは、ユーザーの質問に対して適切な情報を集められているかを確認します。 各メトリクスの目的、必須入力、課題を発見できるか、また、各メトリクスの詳細について以下にまとめます。
メトリクス | 目的 | 必須入力 | どんな課題を発見できるか？ |
Context Relevance | 検索した文脈（コンテキスト）が、そもそも質問に関係あるか | question, contexts | 検索結果に全く無関係な情報が混じっていないか。 基本的な検索アルゴリズムの適合性を確認。 |
Context Precision | 検索した文脈の中に、回答に"本当に必要な"情報がどれだけあるか | question, contexts, ground_truth | 関連はあるが冗長な情報が多く、ノイズになっていないか。検索結果のS/N比を確認。 |
Context Recall | 回答に必要な情報を、漏れなく検索できているか | question, contexts, ground_truth | 複雑な質問に対し、回答の根拠となる情報が不足していないか。情報の網羅性を確認。 |
▼ 各指標の詳細
Context Relevance (コンテキストの関連性)
解釈: スコアが低い場合、検索エンジンがユーザーの質問意図を全く理解できていない可能性があります。
典型的な落とし穴: 曖昧なクエリに対して、無関係なドキュメントを大量に返してしまっているケースがあります。
Context Precision(コンテキストの適合率)
解釈: スコアが高いほど、検索結果のノイズが少ないことを意味します。低い場合は、検索範囲が広すぎる（拾いすぎ）可能性があります。
典型的な落とし穴: 検索でヒットしたドキュメントのチャンク（分割単位）が長すぎて、質問に関係ない部分までコンテキストに含まれてしまうケースがあります。
Context Recall (コンテキストの再現率)
解釈: スコアが高いほど、必要な情報を漏れなく集められていることを意味します。低い場合は、検索アルゴリズムが見つけるべき情報を見つけられていません。
典型的な落とし穴: 専門用語の言い換えや同義語に対応できず、重要な情報を含むドキュメントを検索できていないケースがあります。
生成品質を測る
次に、集めた情報に基づいて、LLMが質の高い回答を生成できているかを確認します。
メトリクス | 目的 | 必須入力 | どんな課題を発見できるか？ |
Faithfulness | 回答が、検索した文脈に忠実か（ハルシネーションの抑制） | question, answer, contexts | LLMが検索結果を無視して、勝手な情報を生成していないか。 回答の信頼性を測る最重要指標。 |
Answer Relevancy | 回答が、ユーザーの質問の意図に沿っているか | question, answer | 回答が冗長だったり、的外れな内容になったりしていないか。 ユーザー体験に直結する指標。 |
▼ 各指標の詳細
Faithfulness (忠実度)
解釈: 最も重要な指標の一つです。スコアが低い場合、たとえ流暢な回答でも、それは信頼できない「ハルシネーション」である可能性が高いです。
典型的な落とし穴: `Context Recall`が低くて情報が不足しているのに、LLMが無理に回答を生成しようとしてハルシネーションを起こす。原因は生成ではなく検索側にあることも多いです。
Answer Relevancy (回答の関連性)
解釈: スコアが低い場合、ユーザーは「質問に答えてくれていない」と感じるでしょう。
典型的な落とし穴: 曖昧な質問に対して、LLMが安全策をとり、一般的で当たり障りのない回答を生成してしまうケースがあります。
【実践】Ragasを使ってみる
1. データの用意
まず、評価用のデータセットを準備します。最初は10〜30件程度の小さなセットで傾向を掴むのがおすすめですが、本サンプルコードでは2件のデータセットを作成します。 前述の通りRagasにはメトリクスごとに対して必須入力に合わせて、以下のようなデータセットを用意します。
question: ユーザーからの質問
answer: RAGシステムが生成した回答
contexts: 回答の根拠として検索された文脈（文字列のリスト）
ground_truth: （`Context Recall`の評価に必要）人間が用意した正解の回答
2. 実行コード例
事前に以下のコマンドで必要なライブラリをインストールし、OpenAIのAPIキーを設定しておきます。
pip install ragas==0.3.5 datasets==4.1.1
export OPENAI_API_KEY=your_api_key Note : 本稿ではRagas 0.3.5を使用しています。バージョンによってAPIが異なる場合がありますので、ご注意ください。
コードの例は下記の通りです。このプログラムを実行すると評価用データセットに対するRagsの評価が出力されます。
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
ContextRelevance,
context_precision,
context_recall,
faithfulness,
answer_relevancy,
)
# 評価用データセット（辞書形式）
data_samples = {
'question': [
'製品Aの保証期間は？',
'ソフトウェアBの推奨OSは？'
],
'answer': [
'製品Aの保証期間は2年です。',
'Windows 11またはmacOS Sonomaが推奨されます。'
],
'contexts' : [
['製品Aの保証は購入日から2年間有効です。', '配送は通常3営業日以内に行われます。'],
['ソフトウェアBはWindowsの場合はWindows 11で動作します。', 'macOSの場合はmacOS Sonomaです。']
],
'ground_truth': [
'製品Aの保証期間は購入日から2年間です。',
'ソフトウェアBを利用するための推奨OSは、Windows 11またはmacOS Sonomaです。'
]
}
dataset = Dataset.from_dict(data_samples)
# 評価の実行
result = evaluate(
dataset,
metrics=[
ContextRelevance(),
context_precision,
context_recall,
faithfulness,
answer_relevancy,
]
)
# 結果をDataFrameで表示
df_result = result.to_pandas()
print(df_result)3. LangfuseでRagasスコアを記録する
Ragasで算出したスコアをLangfuseに記録することで、個々のリクエストのトレースデータと評価結果を紐づけ、継続的な改善サイクルを実現できます。
Langfuseの公式ドキュメントでは、Ragas評価をLangfuseに連携する方法が紹介されています。
詳細な実装方法については上記の公式ドキュメントをご参照いただきたいですが、ここでは簡単に説明します。 基本的な流れは以下の通りです：
トレースの実行: RAGアプリケーションを実行し、その過程（検索、生成など）をLangfuseでトレース（追跡・記録）します。
評価の準備: Langfuseからトレースされたデータ（質問、コンテキスト、回答など）を取得し、Ragas評価フレームワークに渡します。
スコアの算出: Ragasを使い、忠実性（faithfulness）や回答の関連性（answer_relevancy）といったメトリクスに基づいて評価スコアを計算します。
結果の連携: 算出されたスコアを、対応するトレースに紐付ける形でLangfuseに送信し、ダッシュボード上で結果を可視化・分析します。
結果をどう読み解き、次の一手につなげるか？
評価スコアが出たら、次はその数値を元に改善アクションを考えます。
以下によくある課題（症状）と、確認すべきメトリクス、そして具体的な対策をまとめました。
課題（症状） | 確認すべきメトリクス | 主な対策案 |
回答に嘘や間違いが多い | Faithfulness が低い | ・まず`Context Recall`を確認。情報不足が原因の可能性。 ・根拠を明示させるプロンプトにする。 ・不明な場合は「分かりません」と答えるよう指示する。 |
無関係な情報が多く、回答が冗長 | Context Precision が低い Answer Relevancy が低い | ・検索結果の再ランキング（Re-ranking）を導入する。 ・検索で取得するドキュメント数（k）を減らす。 ・ドキュメントのチャンクサイズを短くする。 |
回答が不十分・情報不足 | Context Recall が低い | ・検索で取得するドキュメント数（k）を増やす。 ・クエリ拡張（ユーザーの質問を複数のクエリに変換）を試す。 ・ベクトル検索とキーワード検索を組み合わせる。 |
質問と関係ない回答が返ってくる | Context Relevance が低い | ・埋め込みモデル（Embedding Model）の再検討。 ・ユーザーの質問の意図を明確にする前処理を追加する。 |
Ragasでカバーしきれない観点とカスタム評価
Ragasは、RAGシステムの基本的な性能を標準的に評価するための強力なツールですが、実際のビジネス応用では、以下のような制約があります。
Ragasの制約
事前に定義された評価メトリクスに基づく標準的な評価
ドメイン固有の要件（業界特有のルール、コンプライアンス要件など）への対応が限定的
評価基準の詳細な調整が困難
ブランドトーンや表現スタイルなど、定性的な評価軸への対応
このような場合には、オリジナルの評価基準を作成することが有効です。
例えば、Langfuseを活用することで、以下のようなカスタム評価が可能になります：
金融分野での規制要件への適合性評価
医療分野での専門用語の正確性評価
LangfuseとRagasの使い分けや、カスタム評価基準の作成方法については、リンク先の記事 ： Langfuse で LLM 評価を効率化！活用方法徹底解説 で詳しく解説されていますので、ぜひご参照ください。
まとめ：Ragasで課題を可視化し、Langfuseで改善を加速させる
本稿では、Ragasの主要メトリクスが、RAGシステムの課題をいかに的確に浮かび上がらせるかを解説しました。これは、データドリブンなRAG改善における、欠かすことのできない第一歩です。
しかし、スコアを算出するだけでは、改善活動は始まりません。そのスコアを「いつ、誰が、何を改善した結果なのか」という文脈と共に記録し、チームで共有して初めて、評価は次のアクションに繋がります。
そのための最適な基盤が Langfuse です。
LangfuseにRagasの評価スコアを記録することで、個々のリクエストのトレースデータと評価結果が完全に紐づきます。
例えば、「Context Precisionが低い」という課題が見つかった場合は、Langfuse上でその原因となった検索コンテキストを即座に確認し、次の改善策を立てられます。また、改善後のスコアも再び記録し、A/B比較を実施できます。
このように、Ragasが「What（何を改善すべきか）」を教え、Langfuseが「How（どう改善サイクルを回すか）」を支えることができます。
推測に頼る評価から脱却し、RagasとLangfuseによる継続的な改善サイクルを、ぜひ今日から始めてみてください。
コメント