なぜRAG開発は「作ってから」が泥沼なのか
「とりあえず動くRAG（検索拡張生成）システムはできた。でも、これが本当に業務で使える精度なのか自信がない」
実務の現場では、多くのAIエンジニアやプロジェクトマネージャーがこうした課題に直面しています。LangChainやLlamaIndexといったフレームワークを活用すれば、ドキュメントを検索して回答するチャットボットのプロトタイプ自体は、数日、あるいは数時間で構築できる時代になりました。
しかし、そこから本番運用に乗せ、ビジネス上のROI（投資対効果）を生み出すまでの道のりは、想像以上に険しいものです。頻繁なライブラリのアップデートやセキュリティ対応（例えばLangChainにおける脆弱性修正など）といった運用面の課題もありますが、最大のボトルネックとなるのは「精度の評価」です。
従来のソフトウェア開発なら、単体テストや結合テストで「正解」判定を自動化できました。しかし、生成AIが出力する自然言語には、唯一絶対の正解がありません。「てにをは」が違っても意味が通じれば正解かもしれませんし、事実は合っていても口調が不適切なら不正解かもしれません。
「なんとなく動く」から本番品質への高い壁
プロトタイプ段階では、開発チームがいくつか質問を投げてみて「賢く回答できている」と評価して終わるケースが散見されます。しかし、いざ実際のユーザーに使ってもらうと、「この回答、微妙に嘘が混じってる（ハルシネーション）」「参照しているマニュアルのバージョンが古い」といったフィードバックが山のように届きます。
ここから、終わりのない調整作業が始まります。プロンプトエンジニアリングで指示を微調整しては、同じ質問を投げ、回答を目で見て確認する。リトリーバー（検索器）の設定やチャンクサイズを変更しては、また目で見て確認する。この繰り返しのプロセスが、プロジェクトの進行を大きく阻害します。
目視評価が開発スピードを殺す理由
この「目視確認」こそが、開発スピードを劇的に低下させる真因です。
例えば、回答精度を上げるためにプロンプトを修正したとします。その変更が、特定の質問には良くても、別の質問に対して悪影響を与えていないか（リグレッション）、どうやって保証するのでしょうか。
これを保証するためには、過去のテストケース数十件、数百件をすべて人間が読み直す必要があります。これには膨大な時間がかかり、作業者の疲労も蓄積します。数時間もログを見続けていれば、判断力は鈍り、重要なミスも見逃すようになります。
主観的評価の危険性：昨日はOKで今日はNG？
さらに厄介なのが「評価基準のブレ」です。人間の感覚は曖昧です。昨日は「許容範囲」と判断した回答でも、翌日、ステークホルダーから品質について厳しく指摘された直後に見れば「不合格」と判定してしまうかもしれません。
また、評価チーム内で担当者によって判定が割れることも頻発します。これでは、システムが本当に改善しているのか、それとも改悪されているのか、定量的に判断することができません。
この「評価の泥沼」から抜け出し、継続的な改善サイクルを回すための論理的かつ体系的な方法は、評価プロセス自体をコード化し、自動化することです。そこで鍵となるのが、今回解説する評価フレームワーク「RAGAS（RAG Assessment）」です。
AIをAIで評価する：RAGASと「LLM-as-a-Judge」の仕組み
人間が文章を読んで評価するのが非効率であるなら、文章を処理するのが得意なAIに評価を任せるというアプローチが有効です。
この発想が「LLM-as-a-Judge（審査員としてのLLM）」です。OpenAIの最新モデルのような高性能なLLMに、ユーザーの質問、RAGシステムが検索した情報、そして生成された回答を読ませ、「この回答は適切か？」を採点させる手法です。かつて主流だったChatGPTからモデルの世代交代が進み、現在ではより推論能力の高いモデルが審査員役として採用されるケースが増えています。
正解のない文章をどう採点するか
RAGAS（Retrieval Augmented Generation Assessment）は、このLLMによる評価を体系化したオープンソースのフレームワークです。RAGASを使うと、Pythonコード数行で、RAGシステムのパフォーマンスを数値化できます。
RAGASは、単に「良い/悪い」を決めるのではなく、RAGのプロセスを分解して論理的に評価します。RAGは大きく分けて「検索（Retrieval）」と「生成（Generation）」の2段階で構成されています。RAGASもそれに合わせて指標を用意しています。
RAGASが提供する主要な評価指標（Metrics）
RAGASには多くの指標がありますが、実践的な導入において最初に押さえるべきは以下の4つです。
Faithfulness（忠実性）:
生成された回答が、検索してきたドキュメント（コンテキスト）の内容に基づいているかを見ます。ここに嘘が含まれていれば、いわゆる「ハルシネーション（幻覚）」です。Answer Relevance（回答の関連性）:
生成された回答が、ユーザーの質問に対して適切に答えているかを見ます。的外れな回答をしていないかをチェックします。Context Precision（コンテキスト適合率）:
検索結果の中に、回答に必要な情報がどれだけ高いランクで含まれているかを見ます。検索精度の指標です。Context Recall（コンテキスト再現率）:
正解（Ground Truth）を導き出すために必要な情報が、検索結果にちゃんと含まれているかを見ます。
Faithfulness（忠実性）とAnswer Relevance（関連性）の違い
特に重要なのが「Faithfulness」と「Answer Relevance」の違いです。
- Faithfulness: 「与えられた資料の中にないことを勝手に喋っていないか」
- Answer Relevance: 「質問者の意図を汲んでいるか」
例えば、「特定の企業の株価は？」という質問に対し、検索結果に株価情報がないのに「1000円です」と答えたら、Faithfulnessは低くなります（嘘をついているため）。
一方、「特定の企業の株価は？」に対して「今日はいい天気ですね」と答えたら、Faithfulnessは高いかもしれません（嘘はついていないので）が、Answer Relevanceは最悪になります。
まずはこの2つを自動チェックできるようにするだけでも、開発効率は劇的に向上します。
評価パイプライン構築の第一歩：データセットの準備
RAGASのような自動評価フレームワークを導入する際、最初の壁となるのが「評価用データセット」の準備です。「何千件もの完璧なテストデータが必要なのでは？」と身構えてしまうケースも多いですが、実務的なアプローチとしては、まずは数件〜数十件の小規模なセットから始めるのが効果的です。
評価に必要な「3点セット」とは
RAGASで評価を実行するために最低限必要なデータ構造は、非常にシンプルです。以下の3つの要素が揃っていれば、基本的な評価は開始できます。
- question（質問）: ユーザーが入力したクエリ。
- answer（回答）: RAGシステムが生成した応答テキスト。
- contexts（コンテキスト）: 回答生成時にLLMが参照した検索結果（ドキュメントのチャンク）のリスト。
さらに、検索の網羅性（Recall）などを厳密に測定したい場合には、4つ目の要素が必要になります。
- ground_truth（正解データ）: 人間が作成した、あるいは理想とされる回答内容。
テストデータの作り方：手動作成か合成データか
開発の初期段階では、手動で10〜20件程度の「ゴールデンセット」を作成することが推奨されます。システムが絶対に間違えてはいけない重要な質問や、典型的なユースケースをピックアップし、理想的な挙動を定義するためです。
一方で、数百件規模のデータが必要になった場合、すべてを手動で作るのは現実的ではありません。ここで活用したいのが、RAGASが提供する合成データ生成（Synthetic Data Generation）機能です。
ドキュメントをRAGASに読み込ませることで、LLMが「このドキュメントに基づくと、どのような質問が考えられるか？」を推論し、質問・回答・コンテキストのペアを自動生成してくれます。単純な質問だけでなく、推論が必要な複雑な質問も生成できるため、評価のバリエーションを効率的に増やすことが可能です。
Ground Truth（正解データ）はいつ必要なのか
「正解データ（Ground Truth）を用意するリソースがない」という課題は、多くのプロジェクトで共通しています。しかし、RAGASの強力な点は、正解データなしでも測定できる指標（Reference-free metrics）が充実していることです。
特に以下の2つの重要指標は、Ground Truthなしで算出可能です。
- Faithfulness（忠実性）:
answerがcontextsの内容に基づいているか（幻覚を見ていないか）を判定。 - Answer Relevance（回答の関連性）:
answerがquestionに対して適切な回答になっているかを判定。
つまり、既存のチャットログ（質問、回答、参照ドキュメント）さえあれば、正解データを用意せずとも「AIが嘘をついていないか」「会話として成立しているか」をチェックするパイプラインは、すぐにでも構築できるのです。まずはここから始めて、徐々にGround Truth付きのデータを整備していくのが、プロジェクトを停滞させないための現実的なステップです。
実践：RAGASによる自動評価パイプラインの実装
理論を体系的に理解したところで、実際にPythonを使ってRAGASを動かす手順を見ていきましょう。ここではGoogle Colabやローカル環境での動作を想定し、最小構成で評価パイプラインを構築する方法を紹介します。
環境構築とインストール手順
まず、RAGAS本体と、評価に使用するLLMを扱うためのライブラリをインストールします。
pip install ragas langchain openai datasets
※環境によっては langchain-openai などの追加パッケージが必要になる場合があります。
最小構成での評価コード実行（Hello World）
次に、OpenAIのAPIキーを設定し、サンプルデータを使って評価を実行します。
ここでは理解を深めるためにデータを直接コード内に記述していますが、実務ではCSVやJSON、あるいはログデータから読み込む形が一般的です。
import os
import pandas as pd
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
from datasets import Dataset
# OpenAI APIキーの設定
# セキュリティのため、実際の運用では環境変数やシークレット管理機能を利用してください
os.environ["OPENAI_API_KEY"] = "sk-..."
# 評価用データの準備（辞書形式）
# ground_truth（正解データ）がない場合でも、一部の指標は測定可能です
data = {
'question': [
'フランスの首都はどこですか？',
'Pythonの特徴は何ですか？'
],
'answer': [
'フランスの首都はパリです。',
'Pythonは動的型付け言語であり、読みやすい構文が特徴です。'
],
'contexts': [
['フランス共和国は西ヨーロッパに位置する国。首都はパリ。'],
['Pythonは汎用のプログラミング言語。コードの可読性を重視している。']
]
}
# Hugging FaceのDataset形式に変換
dataset = Dataset.from_dict(data)
# 評価の実行
# ここではFaithfulness（忠実性）とAnswer Relevancy（回答の関連性）の2つを測定
results = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy]
)
# 結果の表示
print(results)
このコードを実行すると、バックグラウンドでOpenAIのモデル（デフォルト設定の場合）が「審査員」として呼び出され、各指標のスコア（0〜1の範囲）が算出されます。
注意点：
RAGASは評価のためにLLMのAPIを多数回呼び出します。大量のデータを評価する際は、API利用料（コスト）やレート制限に注意が必要です。また、使用するモデルは設定で変更可能です。最新の仕様や推奨モデルについては、公式ドキュメントをご確認ください。
結果の可視化とpandasでの分析
resultsオブジェクトは辞書のように扱えますが、データ分析ライブラリであるpandasのDataFrameに変換すると、可視化やフィルタリングが容易になります。
# 結果をDataFrameに変換
df = results.to_pandas()
# 表示（主要なカラムのみ抽出）
print(df[['question', 'faithfulness', 'answer_relevancy']])
これだけで、「どの質問に対する回答の精度が低いか」が一目瞭然になります。例えばスコアが0.5を下回るような回答があれば、そこを集中的にチェックしてプロンプトや検索ロジックを改善する、といったPDCAサイクルを回せるようになります。これが、全件目視チェックから解放される第一歩です。
スコアを改善サイクルにどう活かすか
スコアが出たら終わりではありません。むしろ、ここからがスタートです。算出された数値をどう読み解き、システム改善のアクションにつなげるかが、プロジェクトマネージャーやエンジニアにとって重要なポイントとなります。AIはあくまで手段であり、最終的な目的はビジネス価値の創出です。
スコアが低い原因の特定方法
スコアが低い場合、どの指標がボトルネックになっているかによって対策は大きく異なります。数値を漠然と眺めるのではなく、以下の観点で論理的に切り分けを行いましょう。
Faithfulness（忠実性）が低い場合:
AIが検索結果（Context）を無視して、学習済みの知識で勝手に答えたり、情報を捏造（ハルシネーション）したりしています。対策として、プロンプトで「提供されたコンテキストのみに基づいて回答してください」という制約を強めるか、LLMのTemperature（創造性パラメータ）を下げて出力を安定させる必要があります。Answer Relevance（回答の関連性）が低い場合:
質問に対して、回答のピントがずれています。プロンプトの指示が複雑すぎてLLMが混乱しているケースや、検索結果にノイズ（無関係なドキュメント）が含まれすぎていて、的確な回答生成を阻害している可能性があります。
検索精度（Retrieval）が悪いのか生成（Generation）が悪いのか
もしground_truth（正解データ）を用意してcontext_recall（検索再現率）も測定しているなら、問題の所在をより明確に特定できます。
Context Recallが低い場合:
そもそも回答に必要な情報が検索できていません。これはLLMの問題ではなく、検索エンジンの問題です。チャンクサイズ（文章の区切り方）の最適化、キーワード検索とベクトル検索を組み合わせた「ハイブリッド検索」の導入、あるいは検索結果を再順位付けする「リランキング（Reranking）」の追加を検討すべきです。LlamaIndexなどのフレームワークでは多様な検索手法が提供されていますが、最新の推奨手法については公式ドキュメントを確認することをお勧めします。Context Recallは高いが、Faithfulnessが低い場合:
必要な情報は取れているのに、LLMがそれを正しく回答に変換できていません。これはLLMのモデル性能不足か、コンテキストを処理するプロンプトの設計ミスです。より推論能力の高いモデル（例：Claudeの最新モデルやChatGPTの上位モデルなど）への切り替えや、プロンプトの構造化を試みてください。
CI/CDパイプラインへの組み込みイメージ
究極の目標は、この評価プロセスをCI/CDパイプラインに組み込むことです。これはLLMOps（LLM活用のためのDevOps）の第一歩となります。
コードやプロンプトを変更してGitHub等のリポジトリにプッシュした際、自動的にRAGASによる評価ジョブが走り、主要なテストケースのスコアを計測する仕組みを構築します。「平均スコアが前回より下がっていたらマージをブロックする」といったルールを設ければ、品質劣化（デグレ）を未然に防ぐことが可能です。
ここまで体制が整えば、RAG開発は「職人の勘による調整」から、「エンジニアリングによる継続的改善」へと確実に進化します。
まとめ
RAG開発において、評価は避けて通れないプロセスです。しかし、それをすべて人力で行う必要はありません。RAGASのような自動評価フレームワークを活用することで、以下のメリットが得られます。
- 評価時間の短縮: 数時間かかっていた目視確認が、スクリプト実行のみで完了します。
- 客観性の担保: 「なんとなく良さそう」という主観的な評価から、再現性のある数値評価へ移行できます。
- 改善サイクルの高速化: プロンプトや検索ロジックの修正効果を即座に確認できるため、PDCAサイクルが格段に速くなります。
まずは手元のログデータ数件からで構いません。今回紹介したコードを参考に、自動評価の第一歩を踏み出してみてください。その効率性と安心感を一度体験すれば、手動評価のみの運用には戻れなくなるはずです。
次のステップとして、より高度な検索手法である「ハイブリッド検索」や「リランキング」、あるいは自律的に検索クエリを修正する「エージェント型RAG」の実装に進むのも良いでしょう。評価基盤が整っていれば、こうした新しい技術を導入した際の効果測定も容易になり、自信を持ってシステムをアップデートできます。
コメント