信頼できるRAGの構築：7つの失敗点と評価フレームワークを詳しく解説

検索拡張生成（RAG）は、モダンなAIアーキテクチャにおいて重要なフレームワークであり、コンテキストを理解したエージェントを構築する上で不可欠です。

しかし、基本的なプロトタイプから本稼働システムへの移行には、データの取得、コンテキストの統合、応答の生成における重大な障害を乗り越える必要があります。

この記事では、7つの典型的なRAGの失敗点と実践的なコーディング例を使用した評価メトリックについて深く掘り下げます。

RAGの障害の構造 ― 7つの失敗点（FP）

研究者 Barnettらによると、検索拡張生成（RAG）システムは、パイプライン全体で7つの特定の失敗点（FPs）に遭遇します。

以下の図は、これらの段階を示しています：

図A. RAGシステムの構築に必要なインデックス作成とクエリ処理。インデックス作成は開発時に、クエリ処理は実行時に行います。本研究で特定された失敗点は赤い枠で示されています（出典）

図Aの左上から右下への流れに沿って、各FPをパイプラインの順に見ていきましょう。

FP1. コンテンツの欠如

コンテンツの欠如は、システムが答えることができない質問が出されたときに発生します。関連する情報が最初から利用可能なベクトルストアに存在しないためです。

LLMが分からないと伝えず、もっともらしいものの誤った回答を返すと、失敗が生じます。

FP2. 正しい文書が上位の検索結果に入らない

これは、正しいドキュメントがベクトルストアに存在するが、検索器が十分に高く順位付けできず、LLMにコンテキストとして渡す上位k件の文書に含まれない状況です。

結果として、正しい情報はLLMに到達しません。

FP3. コンテキストに含まれない（統合戦略の制限）

これは、正しいドキュメントが存在し、ベクトルストアからリトリーブされるが、統合プロセス中に除外される状況です。

これは、リトリーブされたドキュメントが多すぎて、LLMのコンテキストウィンドウ、トークン制限、またはレート制限に収まるようにフィルタリングする必要があるときに発生します。

FP4. 抽出されなかった

これは、LLMがコンテキスト内の正しい情報を抽出できなかった状況です。正しい情報はベクトルストアに存在し、リトリーブおよび統合も成功しています。

これは、コンテキストのノイズが多すぎるか、矛盾した情報を含み、LLMを混乱させる場合に発生します。

FP5. 形式の誤り

これは、ストレージ、リトリーブ、統合、LLMの解釈がすべて成功しているが、LLMがプロンプトで指定された形式の指示（例：テーブル、箇条書きリスト、JSONスキーマ）に従えない状況です。

FP6. 具体性の不適切さ

LLMの出力は技術的には存在しますが、ユーザーのニーズと比較して、一般的すぎるか、または複雑すぎる場合です。

例えば、LLMは、ユーザーが複雑な専門的目標を持って行う質問に対して、シンプルな答えを生成します。

FP7. 不完全な回答

LLMの出力が必ずしも誤ってはいないものの、コンテキストに含まれる重要な情報が欠けている状況です。

例えば、ユーザーが「文書A、B、Cの重要なポイントは何ですか？」という複雑な質問をしても、LLMが一つか二つの情報源しか取り上げない場合です。

FPがRAGパイプラインの性能を損なう仕組み

これらのFPはすべて、RAGパイプラインのパフォーマンスに影響します：

データの整合性と信頼性の問題

不完全または不正な情報が存在すると、システムは信頼できる情報源ではなくなります。主なFPは以下のとおりです：

• FP1（コンテンツの欠如）：答えは最初からドキュメントにありません。
• FP4（抽出されなかった）：LLMはドキュメント内の正しい答えを無視します。
• FP7（不完全）：LLMは重要な部分を欠いた半分の真実を提供します。

リトリーブと効率のボトルネック

RAGパイプラインは、リトリーブと統合段階で重要な情報を逃すと、非効率的になる可能性があります。主なFPは以下のとおりです：

• FP2（上位の検索結果に入らない）：埋め込みモデルは上位kの埋め込みを選択できません。
• FP3（統合戦略）：LLMの制限に収まるようにドキュメントをトリミングするスクリプトは、最も重要な部分をドロップします。

ユーザーエクスペリエンスとフォーマットのエラー

正しい出力でも、読みやすさが悪いか、不正な形式の場合、ユーザーエクスペリエンスを損なう可能性があります。主なFPは以下のとおりです：

• FP5（形式の誤り）：LLMは特定の出力形式（例：JSON）に従いません。
• FP6（具体性の不適切さ）：LLMが単純な「はい／いいえ」の質問に長文を返したり、逆に複雑な質問に短すぎる回答を返したりします。

評価スタック：FPを軽減するためのフレームワーク

評価メトリックは、これらのFPを体系的に軽減するように設計されています。

このセクションでは、実践的な使用例を使用した主要なRAG評価メトリックを探索します。

主要なRAG評価メトリック

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – デプロイ前のユニットテスト

DeepEvalは、基準に基づいて加重スコアを計算します。

LLM-as-a-judge（例：GPT-4o）は、LLMの出力に対して各基準を評価します：

DeepEvalは、G-eval、chain-of-thought（CoT）フレームワークを使用して、複数の段階に分けて出力を評価します：

1. 基準を定義する（例：「一貫性」、「流暢性」、「関連性」）
2. 評価ステップを生成します（評価用LLMを使用）。
3. 評価ステップに従い、入力とLLMの出力を分析します
4. 各基準のスコアから期待加重合計を計算します。

実践での一般的なシナリオ

• 状況：複雑なソフトウェア製品のための技術文書化アシスタント（ボット）が、エンジニアチームがコードベースを更新するたびに動作しているようです。
• 問題：ボットがユーザーの質問にまだ答えることができるかどうかについて、定量的な証拠がありません。単に「動いていると思っている」だけです。
• 解決策：PyTest関数をCI/CDリグレッションスイートとしてGithub Actionに統合し、そこでDeepEvalがG-Evalおよびその他のメトリックをテストケース上で実行します：

• 期待される結果：メトリックのスコアのいずれかがしきい値（0.85）を下回った場合、PyTestはAssertionErrorを発生させ、直ちにCIビルドを失敗させ、気付きにくい機能退行が本番環境に入るのを防ぎます。

開発者ノート – DeepEvalのテストケース
LLMTestCaseオブジェクトのセットは、DeepEvalが実行するテストケースを定義します。

実践では、このテストケースには、最も重要なユーザー質問と、リトリーブされたコンテキストとともにラベル付けされた出力が含まれている必要があります。

これらは、JSONまたはCSVファイルからリトリーブできます。

RAGAS ― 干し草の山から針を探す作業の最適化

RAGAS（Retrieval Augmented Generation Assessment）は、合成テストセットを生成することで、人手で注釈を付けたデータセットなしにRAGを評価することを目指します。

それから、主要な評価指標を計算します：

図B. 質問、コンテキスト、回答を適合率、再現率、忠実性、関連性の指標で結ぶRAGAS評価の三角図（作成：Kuriko IWAI）

主要な評価指標は、3つのグループに分類されます：

• 検索パイプライン（黒い実線、図B）：コンテキストの適合率、コンテキストの再現率。
• 生成パイプライン（黒い点線、図B）：忠実性、答えの関連性。
• 正解データ（赤い枠、図B）：答えの意味的類似性、答えの正確性。

実践での一般的なシナリオ

• 状況：法的契約のためのRAGシステムが重要な条項を欠いています。問題は、検索（リトリーバ）か読み取り（ジェネレータ）のどちらにあるか不明です。
• 問題：最適なトップk（リトリーブされるチャンクの数）についての手がかりがありません。
• 解決策：RAGASを使用して、質問と証拠の100ペアで構成されるシンセティックテストセットを作成します。次に、RAGパイプラインをテストセットで実行して、コンテキストの再現率とコンテキストの適合率を計算します：
• 期待される結果：メトリックの結果に応じて、アクションプランは次のようになります：

表1. RAGAS診断アクションプラン – スコアをシステム調整にマッピング。

TruLens – フィードバックループの専門家

TruLensは、最終的な出力だけでなく、RAGプロセスの内部メカニズムに焦点を当て、フィードバック関数を使用します。

また、応答が質問の意図をどの程度満たしているかを示すLLMベースのスコアを、4段階のリッカート尺度（0～3）で算出します。このため、異なる検索結果の品質を順位付けする用途に優れています。

実践での一般的なシナリオ

• 状況：医療アドバイザーボットがユーザーの質問に正しく答えますが、内容を検証済みのPDF資料にはない助言を付け加えます。
• 問題：追加の助言は役立つかもしれませんが、参照資料に根拠がありません。
• 解決策：TruLensを使用して、スコアのしきい値（例：score > 0.8）とともに、根拠性を評価するフィードバック関数を実装します。

• 期待される結果：LLMが、リトリーブされたチャンクに含まれない情報を含む応答を生成した場合、TruLensはレコードをダッシュボードにフラグ付けします。

Arize Phoenix ― 気付きにくい失敗の地図

Arize Phoenixは、オープンソースの可観測性と評価ツールであり、複雑なRAGシステムを含むLLM出力を評価するために使用されます。

Arize AIによってOpenTelemetryで構築されており、LLM評価をMLOpsの一部と位置付け、可観測性に重点を置いています。

RAG評価の文脈では、Phoenixは、埋め込み分析で優れています。高次元のベクトル埋め込みを2D/3D空間に減らすために、Uniform Manifold Approximation and Projection（UMAP）を使用します。

この埋め込み分析は、失敗したクエリが意味的にグループ化されているかどうかを数学的に明らかにし、ベクトルデータベースにギャップがあることを示します。

実践での一般的なシナリオ

• 状況：返金についてはうまく機能しますが、保証請求については意味のない回答を提供する顧客サポートボット。
• 問題：ベクトルデータベースにデータの穴があります（ログでは見つかりません）。
• 解決策：Arize Phoenixを使用して、ユーザークエリをドキュメントチャンクにオーバーレイする3DマップであるUEV（UMAP埋め込み視覚化）を生成します。
• 期待される結果：ドキュメントが存在しない「暗い」領域にユーザークエリのクラスターが視覚的に表示され、ベクトルストアにアップロードされていないドキュメントがあることを示します。

Braintrust – プロンプト回帰の安全ネット

Braintrustは、クロスモデル比較を使用して、高頻度のイテレーションサイクルに適しています。

実践での一般的なシナリオ

• 状況：開発チームが「質問に答えてください」というプロンプト（ケースA）を、500語の複雑なシステム指示（ケースB）に変更します。
• 問題：ケースBに向けたプロンプトの改善で、ケースAの動作が意図せず壊れる可能性があります。
• 解決策：BraintrustでN件の理想的な例を含む正解データセットを作成します（例：N = 50）。チームがプロンプトの一語でも更新するたびに、Braintrustで並列比較（SxS）を実行します。

• 期待される結果：正解データセット（N = 50）の各ケースについて、改善・悪化した箇所を正確に示す差分レポートが得られます。

まとめ

適切な評価フレームワークを使用することで、RAGは、ユーザーの質問に最も関連するコンテキストをLLMに提供する競争力のあるツールになり得ます。

実装戦略：メトリックを失敗点にマッピング

万能の解決策はありませんが、表2は、記事で説明した各FPに適用する評価メトリックを示しています：

表2. 失敗点軽減マトリックス – どのツールがどのFPを解決するか？

DeepEvalとRAGASは、データの整合性の問題（FP1、FP4、FP7）を測定するために、忠実性メトリックを活用できます。

TruLensは、コンテキストの適合率/リコールを使用して、出力に関連するコンテキストを評価します。効果的にFP2を評価します。

Arize Phoenixは、リトリーブプロセスの視覚的なトレースを提供し、ドキュメントが統合中に失われたかどうかを簡単に確認できます（FP3）。

UXの失敗の場合、DeepEvalはカスタムメトリックを作成してUXの失敗を評価します。一方、Braintrustはグラウンドトゥルースデータセットの比較で優れています。