RAGの信頼性を高める方法: 7つの失敗点と評価フレームワークの深い分析

Retrieval-Augmented Generation (RAG)は、モダンなAIアーキテクチャにおいて重要なフレームワークであり、コンテキストを理解したエージェントを構築する上で不可欠です。

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

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

RAGの解体 – 7つの失敗点（FPs）

研究者 Barnett et alによると、Retrieval Augmented Generation (RAG)システムは、パイプライン全体で7つの特定の失敗点（FPs）に遭遇します。

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

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

パイプラインの順序に従って、各FPを探索しましょう、上から下への進行に従って、図Aを参照してください。

FP1. コンテンツの欠如

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

失敗は、LLMが「知らない」ということを伝える代わりに、妥当な答えを提供するときに発生します。

FP2. 上位ランクのドキュメントを逃した

これは、正しいドキュメントがベクトルストアに存在するが、リトリーバがそれを上位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プロセスの内部メカニズムに焦点を当て、フィードバック関数を使用します。

また、4点のLikertスケール（0-3）を使用して、LLMベースのスコアを提供し、ユーザーのクエリの意図をどの程度満たしているかを反映します。

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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