RAG アプリケーションの評価と監視の概要
評価と監視は、RAG アプリケーションがユース ケースによって指定される *品質、コスト、待機時間の要件に合わせて実行されているかどうかを理解するための重要なコンポーネントです。 技術的には、評価は開発中に行われ、監視はアプリケーションが運用環境にデプロイされた後に行われますが、基本的なコンポーネントは似ています。
非構造化データに対する RAG は、アプリケーションの品質に影響を与える多くのコンポーネントを備えた複雑なシステムです。 単一の要素を調整すると、他の要素に連鎖的に影響を及ぼす可能性があります。 たとえば、データの書式設定の変更は、取得されたチャンクと、関連する応答を生成する LLM の機能に影響を与える可能性があります。 そのため、アプリケーション全体に加えてアプリケーションの各コンポーネントを評価し、それらの評価に基づいて繰り返し調整することが重要です。
評価と監視: 従来の ML と生成 AI
RAG を含めて、生成 AI アプリケーションの評価と監視は、いくつかの点で従来の機械学習とは異なります。
| トピック | クラシック ML | 生成 AI |
|---|---|---|
| メトリック | メトリックは、機能のドリフト、精度、リコール、待機時間など、コンポーネントの入力と出力を評価します。 コンポーネントは 1 つしかないため、全体的なメトリック == コンポーネント メトリックです。 | コンポーネント メトリックは、精度 @ K、nDCG、待機時間、毒性など、各コンポーネントの入力と出力を評価します。 複合メトリックは、複数のコンポーネントがどのように相互作用するかを評価します。忠実性は、チェーン入力、チェーン出力、内部レトリバーの出力を必要とするレトリバーからの知識に対するジェネレーターの準拠度を測定します。 全体的なメトリックは、システムの全体的な入力と出力 (応答の正確性や待機時間など) を評価します。 |
| 評価 | 回答は決定論的に "正しい" または "間違っている" です。 決定論的メトリックが機能します。 | 回答は "正しい" または "間違っている" ですが、次の点に注意してください。• 正しい回答が多数あります (非決定論的)。 • いくつかの正しい回答は、より正しいものです。 必要なもの: • 確証を得るための、人間からのフィードバック。 • 評価をスケーリングするための LLM 判定メトリック。 |
評価と監視のコンポーネント
RAG アプリケーションの品質、コスト、待機時間を効果的に評価して監視するには、いくつかのコンポーネントが必要です。
- 評価セット: RAG アプリケーションを厳密に評価するには、アプリケーションの使用目的を表す、厳選された一連の評価クエリ (およびできれば出力) が必要です。 これらの評価例は、困難で多様であり、変化する使用状況と要件を反映するように更新される必要があります。
- メトリック定義: 測定しないものを管理することはできません。 RAG の品質を向上させるには、ユース ケースの品質の平均を定義することが不可欠です。 アプリケーションによっては、重要なメトリックに、応答の精度、待機時間、コスト、または主要な利害関係者からの評価が含まれる場合があります。 各コンポーネント、コンポーネントが相互にやり取りする方法、およびシステム全体を測定するメトリックが必要です。
- LLM ジャッジ: LLM 応答のオープンエンドの性質を考えると、評価するたびにすべての応答を読み取って、出力が正しいかどうかを判断することはできません。 追加の異なる LLM を使用して出力を確認すると、評価をスケーリングし、追加のメトリックを計算するのに役立ちます。たとえば、何千ものコンテキスト トークンに対する応答の根拠です。これは、人間の評価者が実質的に規模に応じた評価を行うのは不可能です。
- 評価ハーネス: 開発中に評価ハーネスを使用すると、評価セット内のすべてのレコードに対してアプリケーションをすばやく実行し、LLM ジャッジとメトリック計算を通じて各出力を実行するのに役立ちます。 この手順では内部開発ループを ”ブロック“ するので特に困難であるため、速度が最も重要です。 優れた評価ハーネスは、この作業を可能な限り並列化し、多くの場合、追加のインフラストラクチャ (LLM 容量の追加など) を起動します。
- 利害関係者向け UI: 開発者が、開発中のアプリケーションのコンテンツにおけるドメインの専門家ではない場合があります。 アプリケーションの品質を評価できる人間の専門家からのフィードバックを収集するには、アプリケーションと対話して詳細なフィードバックを提供できるようにするインターフェイスが必要です。
- 運用トレース ログ: 運用開始後は、大量の要求/応答と各応答の生成方法を評価する必要があります。 たとえば、低品質の回答の根本原因が、取得手順によるか、ハルシネーションによるかを把握する必要があります。 運用ログでは、継続的な監視と、運用環境で発生する問題の早期検出と診断を可能にするために、入力、出力、およびドキュメント取得などの中間手順を追跡する必要があります。
これらのドキュメントは、「RAG 品質の評価」でもっと詳しく評価について取り上げます。