前提条件: 要件の収集

成功する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アプリケーションで、これらの質問がどのように適用されるのかを確認しましょう:

	検討事項	要件
ユーザー体験	インタラクションのモダリティ典型的なユーザークエリーの例期待されるレスポンスのフォーマット/スタイル不明瞭/不適切なクエリーの対応	Slackと連携するチャットインタフェースサンプルクエリー: "どのようにクラスターの起動時間を短縮できる？" "どのような種類のサポートプランがある？" 可能であればコードのスニペットと適切な文書へのリンクを持つ明確で技術的なレスポンス文脈に沿った提案を行い、必要な場合にはDatabricksサポートエンジニアにエスカレーション
データ	データソースの数とタイプデータのフォーマットとロケーションデータサイズと更新頻度データの品質と一貫性	3つのデータソース Databricksのドキュメント(HTML、PDF) 解決されたサポートチケット(JSON) コミュニティフォーラムの投稿(Deltaテーブル) Unity Catalogに格納され、週次で更新されるデータトータルデータサイズ: 5GB 専任のドキュメント、サポートチームによってメンテナンスされる一貫性のあるデータ構造と品質
パフォーマンス	許容可能な最大レーテンシーコストの制約期待される利用法と同時接続数	最大のレーテンシー: <5秒コスト制約: [機密情報] 期待されるピーク負荷 200同時接続ユーザー
評価	評価データセットの可用性品質メトリクスユーザーフィードバックの収集	評価データセットを作成するために、それぞれの製品のSMEがアウトプットのレビューを支援し、不適切な回答を調整ビジネスKPI サポートチケット解決率の改善サポートチケットにユーザーが費やす時間の削減品質メトリクス LLM審判による回答の正しさと適切性 LLM審判による収集精度ユーザーのOK/NG フィードバック収集 OK/NGを提供するためにSlackを計測
セキュリティ	機微データの対応アクセスコントロール要件	収集ソースに機微データの顧客情報は含めてはならない Databricks CommunityのSSOを通じたユーザー認証
デプロイメント	既存システムとの連携デプロイメントとバージョン管理	Databricksサポートチケットシステムとの連携 Databricksモデルサービングエンドポイントとしてデプロイされるチェーン

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル