信頼性の高い RAG の構築方法: 7 つの失敗点と評価フレームワークの深い掘り下げ

検索増強生成（Retrieval-Augmented Generation、RAG）は、モダンな AI アーキテクチャにとって重要なフレームワークであり、コンテキストを認識したエージェントを構築するための基本的なフレームワークです。

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

この記事では、7 つの一般的な RAG の失敗点と評価メトリクスについて、実践的なコーディング例を交えて深く掘り下げます。

RAG の崩壊の解剖 – 7 つの失敗点（FPs）

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

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

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

パイプラインのシーケンスに従って、各 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 は 1 つまたは 2 つの情報源しか対処できない場合に発生します。

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 評価メトリクス:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

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

DeepEval は、基準に基づいて重み付けされたスコアを計算します。

LLM をジャッジとして使用する（たとえば、GPT-4o）ことで、各基準に対する LLM の出力を評価します：

DeepEval は、G-eval を活用しています。これは、連鎖的思考（CoT） フレームワークであり、評価のためのマルチステップアプローチを取ります：

1. 基準を定義する（たとえば、「連貫性」、「流暢性」、または「関連性」など）。
2. 評価ステップを生成します（評価用 LLM を使用）。
3. 評価ステップに従い、入力と LLM の出力を分析します。
4. 各基準のスコアの重み付け合計を計算します。

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

• 状況: 複雑なソフトウェア製品のための技術文書化アシスタント（ボット）が、エンジニアチームがコードベースを更新するたびに正常に動作しているようです。
• 問題: ボットがユーザーの質問に正しく答えられることを証明する量的証拠がないことです（あなたはただ「動いている」と思っているだけです…）。
• 解決策: PyTest 関数を CI/CD リグレッションスイートとして Github アクションに統合し、そこで 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 点の Likert スケール（0-3）で評価します。これにより、さまざまな検索結果の品質をランキングすることができます。

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

• 状況: 医療アドバイザー ボットがユーザーの質問に正しく答えますが、ベット入り PDF ベースにないプロのヒントを追加します。
• 問題: 追加のヒントは役立つかもしれませんが、根拠がありません。
• 解決策: TruLens を使用して、スコアのしきい値（score > 0.8 のような）で接地されたフィードバック関数を実装します。

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

Arize Phoenix – サイレント フェイル マップ

Arize Phoenix は、LLM 出力を評価するオープンソースの可観測性ツールであり、複雑な RAG システムも含みます。

Arize AI による OpenTelemetry で構築されており、MLOps のサブセットとして LLM の評価に焦点を当てています。

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

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

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

• 状況: リファンドに適している顧客サポート ボットが、保証請求に対して意味のない回答を提供します。
• 問題: データベースに存在しないデータ（ログで見つけることができない）。
• 解決策: Arize Phoenix を使用して、ベクトル データベースの 3D マップである Umap 埋め込み視覚化 (UEV) を生成し、ドキュメント チャンク上にユーザー クエリを重ねます。
• 期待される結果: ドキュメントが存在しない「暗い領域」にユーザー クエリのクラスターが着地していることを視覚的に確認し、ベクトル ストアにアップロードされていないドキュメントがあることを示します。

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

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

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

• 状況: エンジニア チームがプロンプトを「質問に答える」(ケース A) から、より複雑な 500 語のシステムの指示 (ケース B) にアップグレードします。
• 問題: ケース B のプロンプトの改善によって、ケース A が壊れる可能性があります。
• 解決策: Braintrust を使用して、完璧な例 (たとえば、N = 50) のセットでゴールデン データセットを作成します。エンジニア チームがプロンプトを更新するたびに、Braintrust をサイドバイサイド (SxS) 比較で実行します:

• 期待される結果: ゴールデン データセット (N = 50) の各ケースで、どのケースが改善されたか、または悪化したかを示す差分レポートが表示されます。

まとめ

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

実装戦略: メトリクスを FP にマッピング

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

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

DeepEval と RAGAS は、忠実性メトリクスを活用して、データの完全性の失敗 (FP1、FP4、FP7) を測定できます。

TruLens は、コンテキストの精度/リコールを活用して、コンテキストの関連性を評価し、FP2 を評価します。

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

ユーザー エクスペリエンスの失敗については、DeepEval はカスタム メトリクスを作成してユーザー エクスペリエンスの失敗を評価し、Braintrust はグラウンド トゥルース データセットの比較に優れています。