生産性のためのハンズオンRAG (Japanese Edition)

第6章 RAGアプリケーションの評価

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

RAGを独自に構築する場合（DIY）でも、RAGプラットフォームを利用する場合でも、ユーザがRAGアプリケーションを使用する際に表示されるレスポンスの品質を測定できる必要がある。これはRAG評価と呼ばれ、 システムが適切な文書やチャンクをどれだけ正確に発見するか（検索精度）、そしてそれらの文書やチャンクからレスポンスをどれだけ首尾一貫して正確に生成するか（生成精度）を測定するものである。

詳細に入る前に、RAG評価の2つのタイプを区別しておくと役立つだろう：

オフライン評価

開発サイクル中に実施される。これらは、のデプロイ前にパイプライン設定を最適化するために使用される、詳細かつ多くの場合リソースを大量に消費する評価である。

オンライン評価

実稼働トラフィック上で実施される。これにより、実際のユーザがシステムとどのようにやり取りするかを特定できるが、低遅延のユーザ体験を維持するためには軽量なアプローチが必要となる。

本章では、主にオフラインRAG評価に焦点を当て、その重要性、考慮すべきメトリック、および各メトリックの解釈方法について論じる。続いて、「オンラインRAG評価」では、オンライン評価について簡単に説明し、いくつかのベストプラクティスを紹介する。

RAGはどのように失敗するのか？

RAGアプリケーションの品質を測定するための体系的なアプローチがないことは、単なる技術的な見落としにとどまらない。それはAI戦略全体を損なう可能性のあるビジネスリスクである。RAGに対する構造化された厳格な評価フレームワークがなければ、ハルシネーションや不正確な回答を生成するアプリケーションをデプロイするリスクがあり、最終的にはアプリケーションに対するユーザの信頼を損ない、ビジネスへの利点を低下させることになる。

本番環境では、こうした技術的な失敗は、顧客満足度の低下（顧客満足度スコアの低下として表れる可能性がある）、ネットプロモータースコア（NPS）の低下、 、さらには（多くの場合コストのかかる）コンプライアンスインシデントの増加といった形で現れる。

第1章で学んだように（「RAGスタックの青写真」 および図1-2を参照）、RAGのクエリフローは、少なくとも2つの別個でありながら相互に依存する構成要素、すなわちリトリーバーとジェネレータで構成されている。クエリフロー内のいずれかの構成要素で失敗や性能低下が発生すると、出力品質が低下する可能性がある。

したがって、堅牢な評価戦略とは、クエリフローのすべての構成要素における問題を個別に診断できると同時に、それらの相乗的なパフォーマンスも評価できるものでなければならない。これらの技術的構成要素を、検索および生成の評価基準、ならびにシステムメトリック（「システムメトリック：遅延と稼働時間」で後述する）と関連付けることで、RAGスタックが測定可能なビジネス成果に向けて最適化されていることを保証できる。

検索の失敗

RAGにおいて最も重大かつ一般的な障害の1つは、検索（ ）中に発生するものであり、検索プロセスに欠陥があると、システム全体が機能不全に陥る。ジェネレータLLMがいかに高度であっても、不正確または無関係なコンテキストからは、正確で関連性のある回答を生成することはできない。

注

本番環境では、生成型LLMよりも先にリトリーバーを最適化することを推奨する。基本的なベクトル検索からハイブリッド検索（ベクトル検索＋BM25）への切り替え、あるいはリランカーの追加（ ...