RAG ソリューションを評価する

完了

Tip

詳細については、「 テキストと画像 」タブを参照してください。

RAG アプリケーションはパイプラインであるため、良い答えだけでは、ソリューション全体がうまく機能することを証明することはできません。 評価では、取得した情報とそこから生成された応答の両方を調べる必要があります。

取得の評価

検索の評価では、検索システムが有用なソース コンテンツを返すかどうかを確認します。

コンテキスト取得の図。

代表的な質問のセットについては、次の点を考慮してください。

  • 関連性: 取得したチャンクは質問に対処しますか?
  • カバレッジ: 完全な回答に必要なすべての情報が存在しますか?
  • ランキング: 最も強い結果は弱い結果よりも優先されますか?
  • セキュリティと鮮度: コンテンツはユーザーに対して承認されており、まだ最新ですか?

正しい情報が取得されない場合、生成プロンプトだけを変更しても問題は解決しません。 ソース コンテンツ、チャンク境界、メタデータ、クエリ処理、検索戦略、またはランク付けを改善することが必要になる場合があります。

生成を評価する

生成の評価では、モデルで取得されたコンテキストがどのように使用されるかが考慮されます。

応答生成の図。

生成されたコンテンツを評価する際の考慮事項は次のとおりです。

  • Groundedness: 取得したコンテンツで各要求がサポートされていますか?
  • 関連性: 応答はユーザーの質問に直接答えますか?
  • 完全性: 答えはコンテキスト内の重要な情報を含みますか?
  • 引用の品質: 引用文献は、関連するクレームをサポートするソースを指していますか?
  • 適切な不確定性: コンテキストが不十分な場合、アプリケーションは推測を避けますか?

有用なテスト セットには、現実的な質問、予想されるソースの一節、許容できる回答の基準が含まれています。 また、あいまいな質問、データに回答のない質問、古いドキュメント、未承認の情報の取得の試行など、困難なケースも含める必要があります。

品質、待機時間、コストのバランスを取る

より多くのチャンクを取得して処理すると、カバレッジが向上しますが、プロンプト サイズ、応答時間、コストも増加します。 コンテキストが多すぎると、モデルが最も関連性の高い証拠に焦点を当てるのが難しくなる可能性もあります。 したがって、RAG 設計では、応答の品質と待機時間とコストのバランスを取る必要があります。

バランス条件の図。

実際の使用状況を監視すると、未回答の質問、弱い引用、低速な検索、コンテンツ品質の変化が明らかになります。 これらの観測値を使用してパイプラインを改善し、データ、モデル、プロンプト、または取得設定が変更されるたびに再評価します。