2.3. 評価とモニタリング

あなたのRAGアプリケーションが、あなたのユースケースにおいて求められる品質、コスト、レーテンシーの要件をRAGアプリケーションを達成しているのかどうかを理解するためには、評価とモニタリングは重要なコンポーネントとなります。技術的には、評価は開発時に行われ、モニタリングはアプリケーションがプロダクションにデプロイされた後に行われますが、基本的なコンポーネントは類似しています。

非構造化データに対するRAGは、アプリケーション品質にインパクトを与える数多くのコンポーネントを持つ複雑なシステムです。いかなる単体の要素を調整することで、他のコンポーネントに影響が伝播します。例えば、データフォーマットの変更は、収集されるチャンクや適切なレスポンスを生成するLLMの能力に影響を与えます。このため、これらの評価に基づいて繰り返し改善するためには、アプリケーション全体に加えてそれぞれのコンポーネントを評価することが重要になります。

RAGを含む生成AIアプリケーションの評価とモニタリングは、いくつかの観点で従来の機械学習とは異なります:

	従来の機械学習	生成AI
メトリクス	コンポーネントの入力と出力を評価するメトリクス。例えば、特徴量のドリフト、精度/再現率、レーテンシーなど。単一のコンポーネントしかないので、全体的なメトリクス==コンポーネントのメトリクスとなります。	それぞれのコンポーネントの入力と出力を評価するコンポーネントメトリクス。例えば、precision @ K、nDCG、レーテンシー、毒性など。複数のコンポーネントがどのように作用するのかを評価する複合メトリクス。例えば、チェーンの入出力、内部のリトリーバの出力を必要とするリトリーバからの知識に生成器が準拠度合いを計測する公正性。システムの全体的な入出力を評価する全体メトリクス。例えば、回答の正確性、レーテンシー。
評価	回答は決定論的に"正しい"か"間違っている"か。 →決定論的メトリクスが使えます。	回答は"正しい"か"間違っているか"ですが: 多くの正しい回答(非決定論的) いくつかの正しい回答はより正しい →確信を持つためには人間のフィードバックが必要 →評価をスケールさせるためにはLLMが判断するメトリクスが必要

アプリケーションの品質、コスト、レーテンシーの効果的な評価には、いくつかのコンポーネントが必要となります:

評価セット: あなたのRAGアプリケーションを厳密に評価するためには、アプリケーションの意図した用途を表現するキュレーションされた評価クエリー(理想的には出力も含む)セットが必要となります。これらの評価サンプルは、困難で、多岐に渡り、変化する使用法や要件を反映するようにアップデートされるべきです。
メトリックの定義: 計測しないものを管理することはできません。RAGの品質を改善するためには、あなたのユースケースにおいて何が品質を意味するのかを定義することが重要です。アプリケーションに応じて、重要なメトリクスにはレスポンスの正確性、レーテンシー、コスト、キーとなるステークホルダーからのレーティングが含まれます。それぞれのコンポーネント、複数のコンポーネントがどのように作用し合うのか、システム全体を計測するメトリクスが必要となります。
LLM審判: LLMレスポンスのオープンエンドな性質のため、出力が適切かどうかを評価するために、毎回単体のレスポンスを読み込むことは不可能です。出力をレビューするために追加の異なるLLMを用いることで、人間の評価者の評価では効果的にスケールすることが困難な数千のトークンのレスポンスなどに基づいた追加のメトリクスの評価、計算をスケールさせる助けとなります。
評価のハーネス: 開発過程で評価を組み込むことによって、あなたの評価セットのすべてのレコードに対してクイックにあなたのアプリケーションをクイックに実行する助けとなり、それぞれの出力に対してあなたのLLM審判とメトリックの計算処理を実行できるようになります。このステップはあなたの内部的な開発ループを"ブロック"するので、特に困難なものとなり、スピードが非常に重要になります。優れた評価ハーネスは、この処理を可能な限り並列化し、多くの場合、それを行うためにより多くのLLMキャパシティのような追加のインフラストラクチャを起動することになります。
ステークホルダーが使用するUI: 開発者として、あなたは開発しているアプリケーションのコンテンツに関するドメイン専門家ではない場合があります。あなたのアプリケーション品質を評価できる人間の専門家からフィードバックを収集するために、彼らがアプリケーションを操作し、詳細なフィードバックを提供できるインタフェースが必要になります。
プロダクショントレースのロギング: プロダクションに移行したら、それぞれのレスポンスがどのように生成されているのかに加え、より多くのリクエスト/レスポンスを集中的に評価する必要が出てきます。例えば、品質の低い回答が収集ステップにあるのか、あるいはハルシネーションであるのかに関する根本原因を知る必要が出てくるでしょう。あなたのプロダクション環境のロギングでは、プロダクション環境で生じる問題の継続モニタリング、早期検知、診断を可能とするために、入力、出力、中間ステップのついせきがひつようとなります

より詳細はセクション4 RAGの品質の評価でカバーします。

目次
前のセクション: 2.2. 収集、拡張、生成(RAGチェーン)
次のセクション: 2.4. ガバナンスとLLMops

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル