Prerequisite: Gather requirements — Databricks Generative AI Cookbook [2024/6/24時点]の翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricks生成AIクックブックのコンテンツです。
前提条件: 要件の収集
成功するRAGアプリケーションを開発する重要な最初のステップは、明確かつ包括的なユースケース要件を定義することです。これらの要件は主に二つの目的に寄与します。最初に、それらが対象のユースケースに対してRAGが最も適しているアプローチなのかどうかを特定する役に立ちます。RAGが本当によくフィットするのであれば、これらの要件はソリューションのデザイン、実装、評価に対する意思決定をガイドします。プロジェクトの最初で詳細な要件を収集することに時間を費やすことで、開発プロセスの後半での課題や揺り戻しを回避することができ、最終的なソリューションがエンドユーザーやステークホルダーのニーズを確実に充足することになります。良く定義された要件は、ウォークスルーする開発ライフサイクルの以降のステージの基礎を提供します。
そのユースケースはRAGにフィットしますか？
最初に確立すべきことは、RAGがあなたのユースケースに非常に適しているのかどうかということです。RAG周辺のハイプによって、すべての問題に適用可能なソリューションと見てしまうかもしれません。しかし、RAGが適している場合とそうでない場合に関しては微妙な違いがあります:
以下のようなケースではRAGがフィットします:
- LLMのコンテキストウィンドウに完全に収まらない収集情報(非構造化と構造化の両方)に対する理由付け
- 複数ソースからの情報の合成(あるトピックに関する異なる記事から得られるキーポイントのサマリーの生成など)
- ユーザークエリーに基づく動的収集が必要(ユーザークエリーに対して、どのデータソースから収集するのかを特定する)
- ユースケースでは、収集した情報に基づいて新しいコンテンツを生成する必要がある(質問への回答、説明の提供、推奨の提示)
逆に、以下のケースではRAGはベストフィットとは言えないかもしれません:
- タスクではクエリー固有の収集を必要としない。例えば、電話の会話の要約生成など。それぞれの会話がLLMプロンプトの文脈として提供されたとしても、収集される情報はサマリーごとに同じになります。
- 収集した情報全体がLLMのコンテキストウィンドウに収まる。
- 極端に低レーテンシーのレスポンスが求められる(msのレスポンスが必要な場合など)
- シンプルなルールベースやテンプレートによるレスポンスで十分(キーワードに基づいて事前定義済みの回答を提供するカスタマーサポートチャットbotなど)
特定すべき要件
あなたのユースケースにおいて、RAGが本当にグッドフィットすることが確認できたら、具体的な要件を補足するために以下の質問を検討しましょう。我々はそれぞれの要件に対して優先度付けを行いました:
- 🟢 P0: POCをスタートする前にこの要件を定義すべきです
- 🟡 P1: プロダクションに行く前に定義すべきですが、POCを通じて繰り返し改善することができます
- ⚪️ P2: あったら良い要件です
ユーザー体験
ユーザーがどのようにRAGシステムとやりとりするのか、どのような種類のレスポンスが期待されるのかを特定します
- 🟢 RAGチェーンに対する典型的なリクエストはどのようなものでしょうか？可能性のあるユーザークエリーの例について、ステークホルダーに質問しましょう。
- 🟢 ユーザーはどのような種類のレスポンス(短い回答、長い形態の説明、組み合わせ、それ以外)を期待するでしょうか？
- 🟡 ユーザーはシステムとどのようにやりとりしますか？チャットインタフェースを通じて、検索バー、他のモダリティ？
- 🟡 生成されるレスポンスはどのような口調、スタイル？(フォーマル、会話型、技術的など)
- 🟡 アプリケーションは曖昧、不完全、不適切なクエリーにどのように対応すべき？そのような場合には何かしらのフィードバックやガイドを提供すべき？
- ⚪ 生成されるアウトプットに対する特定のフォーマットや表現の要件はありますか？アウトプットにはチェーンのレスポンスに加えて何かしらのメタデータを追加すべきですか？
データ
RAGソリューションで使用されるデータの性質、ソース、品質を特定します
- 🟢 利用できるソースは？
- それぞれのデータソースに対して:
- 🟢 データは構造化か非構造化か？
- 🟢 収集データのソースフォーマット(PDF、画像/表を持つ文書、構造化されたAPIのレスポンスなど)は？
- 🟢 データはどこにある？
- 🟢 どれだけのデータを利用できる？
- 🟡 どの程度の頻度でデータが更新されるのか？それらの更新に対応すべきか？
- 🟡 それぞれのデータソースにおいて既知のデータ品質問題や非一貫性はあるのか？
これらの情報をまとめるためのインベントリテーブルを作成することを検討しましょう。例えば:
| データソース | ソース | ファイルタイプ | サイズ | 更新頻度 |
|---|---|---|---|---|
| Data source 1 | Unity Catalogボリューム | JSON | 10GB | 日次 |
| Data source 2 | 公開API | XML | n/a (API) | リアルタイム |
| Data source 3 | SharePoint | PDF、DOCX | 500MB | 月次 |
パフォーマンスの制約
RAGアプリケーションのパフォーマンス、リソース要件を捕捉します
- 🟡 レスポンスの生成で許容できる最大のレーテンシーは？
- 🟡 最初のトークン生成に許容できる最長時間は？
- 🟡 アウトプットがストリーミングされている場合、より大きいレーテンシーが許容できるのか？
- 🟡 推論時に利用できる計算リソースにコストの制限があるのか？
- 🟡 どのような利用パターンとピーク負荷が予測されるのか？
- 🟡 システムではどれだけの同時接続ユーザーやリクエストに対応できるべきか？
- 注意: Databricksでは、モデルサービングによる自動でスケールする能力を通じて、このようなスケーラビリティの要件にネイティブで対応できます。
評価
時間をかけてRAGソリューションをどのように評価、改善していくのかを明確にします
- 🟢 インパクトを与えたいビジネスゴール / KPIは何ですか？ベースラインとなる価値は何で、ターゲットは何ですか？
- 🟢 どのユーザーやステークホルダーが初回、継続的なフィードバックを提供しますか？
- 🟢 生成されたレスポンスの品質を評価するためにどのメトリクスを使うべきですか？
- 注意: Mosaic AI Agent Evaluationは、使用すべき推奨メトリクスセットを提供します。
- 🟡 プロダクションに移行する際に、RAGアプリケーションがうまく回答すべき質問のセットは何ですか？
- 🟡 評価セットはありますか？ユーザークエリーと正解の回答、収集すべき適切なサポート文書(オプション)の評価セットを取得することができますか？
- 🟡 ユーザーのフィードバックをどのように収集し、システムに取り込みますか？
セキュリティ
すべてのセキュリティ、プライバシーに関する検討事項を特定します
- 🟢 注意を持って取り扱うべき、機微/機密データはありますか？
- 🟡 ソリューションでアクセスコントロール(制限された文書セットからは特定のユーザーしか収集できない、等)を実装する必要がありますか？
デプロイメント
RAGアプリケーションがどのように連携、デプロイ、メンテナンスされるのかを理解します
- 🟡 RAGソリューションは既存のシステムやワークフローとどのように連携すべきですか？
- 🟡 どのようにモデルはデプロイ、スケール、バージョン管理されるべきですか？
- 注意: このようなエンドツーエンドのライフサイクルが、DatabricksでMLflow、Unity Catalog、Agent SDK、モデルサービングを用いてどのように取り扱われるのかをカバーします。
これは、決して質問の完全なリストではないことに注意してください。しかし、あなたのRAGソリューションのキーとなる要件を捕捉する堅牢な基盤を提供するに違いありません。
例
例として、我々のカスタマーサポートチームで使用されるDatabricks内部のRAGアプリケーションで、これらの質問がどのように適用されるのかを確認しましょう:
| 検討事項 | 要件 | |
|---|---|---|
| ユーザー体験 |
|
|
| データ |
|
|
| パフォーマンス |
|
|
| 評価 |
|
|
| セキュリティ |
|
|
| デプロイメント |
|
|
- 目次
- 前のセクション: Databricksノートブック
- 次のセクション: ステップ1: コードレポジトリのクローンと計算資源の作成