前提条件: 要件の収集

明確で包括的なユースケース要件を定義することは、成功する RAG アプリケーションを開発するための重要な第一歩です。 これらの要件には、主に 2 つの目的があります。 まず、RAGが特定のユースケースに最も適したアプローチであるかどうかを判断するのに役立ちます。 RAG が実際に適合している場合、これらの要件はソリューションの設計、実装、および評価の決定を導きます。 プロジェクトの開始時に詳細な要件を収集するために時間を費やすことで、開発プロセスの後半で重大な課題や障害が発生するのを防ぎ、結果として得られるソリューションがエンドユーザーと利害関係者のニーズを満たすことを保証できます。 明確に定義された要件は、これから説明する開発ライフサイクルの後続の段階の基盤となります。

このセクションのサンプル コードについては、GitHub リポジトリを参照してください。

ユースケースはRAGに適していますか?

最初に確認する必要があるのは、RAGがユースケースに適したアプローチであるかどうかです。 RAG に関する誇大宣伝を考えると、あらゆる問題に対する可能な解決策として RAG を考えたくなるかもしれません。 ただし、RAGが適している場合と適していない場合については微妙な違いがあります。

RAGは、次のような場合に適しています。

• LLM のコンテキスト ウィンドウ内に完全には収まらない取得情報 (非構造化情報と構造化情報の両方) の推論

• 複数のソースから情報を統合する（例えば、あるトピックに関するさまざまな記事から要点の要約を生成する）

• ユーザークエリに基づく動的な取得が必要である（たとえば、ユーザークエリが与えられた場合、どのデータソースから取得するかを決定する）

• ユースケースでは、取得した情報に基づいて新しいコンテンツを生成する必要があります（たとえば、質問に答える、説明を提供する、推奨事項を提供するなど）。

RAGは、次の場合に最適ではない可能性があります。

• このタスクでは、クエリ固有の取得は必要ありません。 たとえば、通話トランスクリプトの要約を生成する場合、LLM プロンプトでコンテキストとして個別のトランスクリプトが提供されている場合でも、取得される情報は各要約に対して同じままです。

• 取得する情報セット全体がLLMのコンテキストウィンドウ内に収まる

• 非常に短い待機時間の応答が必要です (たとえば、ミリ秒単位の応答が必要な場合)

• シンプルなルールベースまたはテンプレート化された応答で十分です（たとえば、キーワードに基づいて定義済みの回答を提供する顧客サポートチャットボットなど）。

発見するための要件

RAGがユースケースに適していることを確認したら、具体的な要件を把握するために次の質問を検討してください。 要件は次のように優先順位が付けられます。

🟢 P0: POC を開始する前に、この要件を定義する必要があります。

🟡 P1: 本番運用に進む前に定義する必要がありますが、POC 中に反復的に改良することができます。

⚪P2:要件があるのはうれしいです。

これは、質問の完全なリストではありません。 ただし、RAG ソリューションの主要な要件を把握するための強固な基盤を提供する必要があります。

ユーザーエクスペリエンス

ユーザーがRAGシステムをどのように操作し、どのような応答が期待されるかを定義します

🟢 [P0] RAGチェーンへの典型的なリクエストはどのようなものですか? 潜在的なユーザークエリの例を関係者に尋ねます。

🟢 [P0] ユーザーはどのような回答を期待しますか (短い回答、長い形式の説明、組み合わせなど)?

🟡 [P1] ユーザーはシステムをどのように操作しますか? チャットインターフェイス、検索バー、またはその他のモダリティを介して?

🟡 [P1] ハットトーンやハットスタイルは、生成された応答を取るべきか? (フォーマル、会話、テクニカル?

🟡 [P1] アプリケーションは、あいまいなクエリ、不完全なクエリ、または無関係なクエリをどのように処理する必要がありますか? そのような場合、何らかの形式のフィードバックやガイダンスを提供する必要がありますか?

⚪[P2]生成された出力に特定のフォーマットまたはプレゼンテーション要件はありますか? 出力には、チェーンの応答に加えてメタデータを含める必要がありますか?

データ

RAG ソリューションで使用されるデータの性質、ソース、品質を決定します。

🟢 [P0] 使用できるソースは何ですか?

各データソースについて:

• 🟢 [P0] データは構造化データですか、それとも非構造化データですか?

• 🟢 [P0] 取得データのソース形式は何ですか（例：PDF、画像/表を含むドキュメント、構造化されたAPIレスポンス）？

• 🟢 [P0] そのデータはどこにありますか?

• 🟢 [P0] 利用可能なデータ量はどれくらいですか?

• 🟡 [P1] データはどのくらいの頻度で更新されますか? これらの更新はどのように処理する必要がありますか?

• 🟡 [P1] 各データソースに既知のデータ品質の問題や不整合はありますか?

この情報を統合するために、在庫テーブルを作成することを検討してください。次に例を示します。

データソース	ソース	ファイルの種類	サイズ	更新頻度
データソース 1	Unity Catalogボリューム	JSON	10 GB	日次
データソース 2	パブリックAPI	XMLの	NA (API)	リアルタイム
データソース 3	SharePoint	PDF、.docx	500メガバイト	毎月

パフォーマンスの制約

RAG アプリケーションのパフォーマンスとリソースの要件を取得します。

🟡 [P1] 応答を生成するための最大許容レイテンシーはどれくらいですか?

🟡 [P1] 最初のトークンまでの最大許容時間はどれくらいですか?

🟡 [P1] 出力がストリームである場合、合計レイテンシが高くても許容されますか?

🟡 [P1] 推論に利用できるコンピュートリソースにはコスト制限がありますか？

🟡 [P1] 予想される使用パターンとピーク負荷はどのようなものですか?

🟡 [P1] システムは並列にいくつのユーザーまたはリクエストを処理できる必要がありますか? Databricks モデルサービングによる自動スケーリング機能を通じて、このようなスケーラビリティ要件をネイティブに処理します。

評価

RAG ソリューションが時間の経過とともにどのように評価され、改善されるかを確立します。

🟢 [P0] 影響を与えたいビジネス目標/KPIは何ですか? ベースライン値と目標値は何ですか?

🟢 [P0] 最初のフィードバックと継続的なフィードバックを提供するユーザーまたは利害関係者は誰ですか?

🟢 [P0] 生成された応答の品質を評価するにはどのようなメトリックを使用する必要がありますか? Mosaic AI Agent Evaluation では、使用に推奨されるメトリックのセットが提供されます。

🟡 [P1] RAG アプリが本番運用に進むために得意でなければならない一連の質問は何ですか?

🟡 [P1] [評価セット]は存在しますか? ユーザークエリの評価セットと、グラウンドトゥルースの回答、および(オプションで)取得する必要がある正しいサポートドキュメントを取得することは可能ですか?

🟡 [P1] ユーザーからのフィードバックはどのように収集され、システムに組み込まれますか?

セキュリティ

セキュリティとプライバシーに関する考慮事項を特定します。

🟢 [P0] 注意して取り扱う必要がある機密データはありますか?

🟡 [P1] ソリューションにアクセス制御を実装する必要がありますか (たとえば、特定のユーザーは制限されたドキュメント セットからのみ取得できる)?

配備

RAG ソリューションがどのように統合、展開、保守されるかを理解します。

🟡 RAG ソリューションを既存のシステムやワークフローとどのように統合すればよいですか?

🟡 モデルをどのようにデプロイ、スケーリング、バージョン管理する必要がありますか? このチュートリアルでは、Databricks MLflow、Unity Catalog 、 AgentSDK 、およびモデルサーバーを使用して、 でエンドツーエンドのライフサイクルを処理する方法について説明します。

例

例として、 Databricksの顧客サポート チームが使用するこの RAG アプリケーションの例にこれらの質問がどのように当てはまるかを考えてみましょう。

エリア	考慮事項	要件
ユーザーエクスペリエンス	インタラクションモダリティ。 一般的なユーザー クエリの例。 想定される応答の形式とスタイル。 曖昧なクエリや無関係なクエリの処理。	Slackと統合されたチャットインターフェイス。 クエリの例: 「クラスターの起動時間を短縮するにはどうすればよいですか?」 「どのようなサポート プランがありますか?」 コードスニペットと、必要に応じて関連ドキュメントへのリンクを含む、明確で技術的な応答。 状況に応じた提案を提供し、必要に応じてサポートエンジニアにエスカレーションします。
データ	データソースの数と種類。 データの形式と場所。 データのサイズと更新頻度。 データの品質と一貫性。	3 つのデータソース。 会社のドキュメント(HTML、PDF)。 解決されたサポート チケット (JSON)。 コミュニティ フォーラムの投稿 ( Deltaテーブル)。 データはUnity Catalogに保存され、毎週更新されます。 合計データサイズ:5GB。 専任のドキュメントとサポートチームによって維持される一貫したデータ構造と品質。
パフォーマンス	許容可能な最大レイテンシー。 コストの制約。 想定される使用量とコンカレンシー。	最大待機時間の要件。 コストの制約。 予想されるピーク負荷。
評価	評価データセットの可用性。 品質メトリックス。 ユーザーフィードバックの収集。	各製品分野の専門家が出力を確認し、誤った回答を調整して評価データセットを作成します。 ビジネス KPI。 サポートチケットの解決率の向上。 サポートチケットあたりのユーザー時間の削減。 品質メトリックス。 LLM が判断した回答の正確性と関連性。 LLM は検索精度を判断します。 ユーザーは賛成票または反対票を投じます。 フィードバックの収集。 Slackは、親指を立てたり下げたりできるようにインストルメント化されます。
セキュリティ	機密データの処理。 アクセス制御の要件。	取得ソースには機密性の高い顧客データは含まれません。 Databricks コミュニティ SSO によるユーザー認証。
デプロイメント	既存のシステムとの統合。 デプロイとバージョン管理。	サポートチケットシステムとの統合。 Databricksモデルサービング エンドポイントとしてデプロイされたチェーン。

次のステップ

ステップ 1 から始めましょう。コード リポジトリをクローンしてコンピュートを作成します。