Debugging retrieval quality — Databricks Generative AI Cookbook [2024/6/26時点]の翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricks生成AIクックブックのコンテンツです。
収集品質のデバッグ
収集品質のデバッグ方法
あなたが実施した根本原因分析によって、収集の改善が対応すべき根本原因であることがわかったのでこのページを参照しています。
収集の品質は、RAGアプリケーションにおいてまず間違いなく、最も重要なコンポーネントとなります。与えられたクエリーに対して最も適切なチャンクが返却されなかったら、LLMは高品質なレスポンスを生成するために必要な情報にアクセスすることができません。このため、貧弱な収集は、不適切、不完全、幻覚を伴うアウトプットにつながります。このステップでは、背後のデータを分析するための手動の工数が必要となります。Mosaic AIを用いることで、データプラットフォーム(Unity CatalogやVector Search)と実験トラッキング(MLflow LLM evaluationやMLflow tracing)の間の密連携によって、これは非常に簡単なものになります。
手順
収集の品質問題に対応するためのステップバイステップのプロセスを以下に示します:
-
B_quality_iteration/01_root_cause_quality_issuesノートブックを開きます。 - 収集品質問題があるレコードのMLflow traceをロードするためのクエリーを使用します。
- それぞれのレコードに対して、収集されたチャンクを手動で検証します。可能であれば、正解の収集ドキュメントとそれらを比較します。
- 低品質の収集によるクエリー間でのパターンや共通的な問題を探します。例には以下のようなものがあります:
- ベクトルデータベース全体で適切な情報が不足している。
- 収集クエリーに対して返却されるチャンク/ドキュメントの数が不十分。
- チャンクが小さすぎて、十分なコンテキストに欠けている。
- チャンクが大きすぎて、複数かつ関係のないトピックが含まれている。
- エンべディングモデルがドメイン固有の用語の意味論的類似性を捕捉することに失敗している。
- 特定した問題に基づき、潜在的な根本原因と対応する修正方法について仮説を立てる。このガイドに関しては、以下の貧弱な収集品質の一般的な理由の一覧をご覧ください。
- 修正方法を実装、評価するために変更の実装と評価のステップに従います。
- これには、データパイプラインの修正(チャンクサイズの修正、別のエンべディングモデルを試すなど)やRAGチェーンの修正(ハイブリッド検索の実装、より多くのチャンクの収集など)が含まれることがあります。
- 依然として収集品質が不十分である場合には、期待されるパフォーマンスが得られるまで、次のより有望な修正策を特定するまでステップ4-5を繰り返します。
- チェーン全体で対応すべき他の根本原因が他にないのかを特定するための根本原因分析を再実行します。
貧弱な収集品質の一般的な理由
潜在的なこれらの修正方法は、大きく分けて3つに分類されます:
-
の変更 -
の変更 -
の変更
変更の種類に応じて、変更の実装と評価の異なるステップに従うことになります。
| 収集の問題 | デバッグのステップ | 修正案 |
|---|---|---|
| チャンクが小さすぎる |
|
|
| チャンクが大きすぎる |
|
|
| チャンクに取得元のテキストに関する十分な情報が含まれていない |
|
|
| エンべディングモデルがユーザークエリーのドメイン、キーフレーズを正確に理解していない |
|
|
| ベクトルデータベースに適切な情報が欠けている |
|
|
| 収集クエリーが貧弱に処理されている |
|
|
- 目次
- 前のセクション: ステップ5: 品質問題の根本原因の特定
- 次のセクション: 生成品質のデバッグ