前提条件: 要件の収集

評価主導の開発ワークフロー

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

このセクションのサンプル コードについては、 GitHub リポジトリ を参照してください。 リポジトリ コードをテンプレートとして使用して、独自の AI アプリケーションを作成することもできます。

ユースケースは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と統合されたチャットインターフェース。

  • クエリの例: "クラスターの起動時間を短縮するにはどうすればよいですか?"「どんなサポートプランがあるの?」

  • 明確で技術的な回答と、コードスニペット、および必要に応じて関連ドキュメントへのリンク。

  • コンテキストに応じた提案を提供し、必要に応じてサポート エンジニアにエスカレーションします。

データ

  • データソースの番号と種類。

  • データ形式と場所。

  • データ サイズと更新頻度。

  • データの品質と一貫性。

  • Three データソース.

  • 会社のドキュメント(HTML、PDF)。

  • 解決されたサポート チケット (JSON)。

  • コミュニティ フォーラムの投稿 (Delta テーブル)。

  • データは Unity Catalog に保存され、毎週更新されます。

  • 合計データ サイズ: 5 GB。

  • 専任のドキュメントとサポートチームによって維持される一貫したデータ構造と品質。

パフォーマンス

  • 許容可能な最大レイテンシ。

  • コストの制約。

  • 予想される使用量と同時実行性。

  • 最大待機時間の要件。

  • コストの制約。

  • 予想されるピーク負荷。

評価

  • 評価データセットの可用性。

  • Quality メトリクス.

  • ユーザーフィードバックの収集。

  • 各製品領域の対象分野の専門家が、出力のレビューと不正解の調整を支援して評価データセットを作成します。

  • ビジネス KPI。

  • サポート チケットの解決率の向上。

  • サポート チケットあたりのユーザー時間の短縮。

  • Quality メトリクス.

  • LLMが判断した回答の正しさと関連性。

  • LLMは検索精度を判定します。

  • ユーザーが賛成票を投じるか、反対票を投じるか。

  • フィードバック収集。

  • Slackは、親指を立てたり下げたりするようにインストルメント化されます。

セキュリティ

  • 機密データの取り扱い。

  • アクセス制御の要件。

  • 機密性の高い顧客データを取得ソースに含めないでください。

  • Databricks コミュニティ SSO によるユーザー認証。

デプロイメント

  • 既存のシステムとの統合。

  • デプロイとバージョン管理。

  • サポートチケットシステムとの統合。

  • Databricksモデルサービングエンドポイントとしてデプロイされたチェーン。