Databricks生成AIクックブック - 前提条件: 要件の収集

[Prerequisite: Gather requirements — Databricks Generative AI Cookbook](https://ai-cookbook.io/nbs/5-hands-on-requirements.html) [2024/6/24時点]の翻訳です。

:::note warn
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

> [Databricks生成AIクックブック](https://qiita.com/taka_yayoi/items/36c51bce8f33a70cf204)のコンテンツです。

# 前提条件: 要件の収集

![](https://ai-cookbook.io/_images/workflow_gather.png)

成功するRAGアプリケーションを開発する重要な最初のステップは、明確かつ包括的なユースケース要件を定義することです。これらの要件は主に二つの目的に寄与します。最初に、それらが対象のユースケースに対してRAGが最も適しているアプローチなのかどうかを特定する役に立ちます。RAGが本当によくフィットするのであれば、これらの要件はソリューションのデザイン、実装、評価に対する意思決定をガイドします。プロジェクトの最初で詳細な要件を収集することに時間を費やすことで、開発プロセスの後半での課題や揺り戻しを回避することができ、最終的なソリューションがエンドユーザーやステークホルダーのニーズを確実に充足することになります。良く定義された要件は、ウォークスルーする開発ライフサイクルの以降のステージの基礎を提供します。

:::note info
[**コードレポジトリ**](https://github.com/databricks/genai-cookbook/tree/main/rag_app_sample_code)
[こちら](https://github.com/databricks/genai-cookbook/tree/main/rag_app_sample_code)からこのセクションで参照しているすべてのサンプルコードにアクセスすることができます。
:::

## そのユースケースは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では、[モデルサービング](https://docs.databricks.com/ja/machine-learning/model-serving/index.html)による自動でスケールする能力を通じて、このようなスケーラビリティの要件にネイティブで対応できます。

### 評価

*時間をかけてRAGソリューションをどのように評価、改善していくのかを明確にします*

- 🟢 インパクトを与えたいビジネスゴール / KPIは何ですか？ベースラインとなる価値は何で、ターゲットは何ですか？
- 🟢 どのユーザーやステークホルダーが初回、継続的なフィードバックを提供しますか？
- 🟢 生成されたレスポンスの品質を評価するためにどのメトリクスを使うべきですか？
    - **注意:** [Mosaic AI Agent Evaluation](https://docs.databricks.com/ja/generative-ai/agent-evaluation/index.html)は、使用すべき推奨メトリクスセットを提供します。
- 🟡 プロダクションに移行する際に、RAGアプリケーションがうまく回答すべき質問のセットは何ですか？
- 🟡 [評価セット](https://qiita.com/taka_yayoi/items/c7e549323b9fcbb9edec)はありますか？ユーザークエリーと正解の回答、収集すべき適切なサポート文書(オプション)の評価セットを取得することができますか？
- 🟡 ユーザーのフィードバックをどのように収集し、システムに取り込みますか？

### セキュリティ

*すべてのセキュリティ、プライバシーに関する検討事項を特定します*

- 🟢 注意を持って取り扱うべき、機微/機密データはありますか？
- 🟡 ソリューションでアクセスコントロール(制限された文書セットからは特定のユーザーしか収集できない、等)を実装する必要がありますか？

### デプロイメント

*RAGアプリケーションがどのように連携、デプロイ、メンテナンスされるのかを理解します*

- 🟡 RAGソリューションは既存のシステムやワークフローとどのように連携すべきですか？
- 🟡 どのようにモデルはデプロイ、スケール、バージョン管理されるべきですか？
    - **注意:** このようなエンドツーエンドのライフサイクルが、DatabricksでMLflow、Unity Catalog、Agent SDK、モデルサービングを用いてどのように取り扱われるのかをカバーします。

これは、決して質問の完全なリストではないことに注意してください。しかし、あなたのRAGソリューションのキーとなる要件を捕捉する堅牢な基盤を提供するに違いありません。

## 例

例として、我々のカスタマーサポートチームで使用されるDatabricks内部のRAGアプリケーションで、これらの質問がどのように適用されるのかを確認しましょう:

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

- [目次](https://qiita.com/taka_yayoi/items/36c51bce8f33a70cf204#%E7%9B%AE%E6%AC%A1)
- 前のセクション: [Databricksノートブック](https://qiita.com/taka_yayoi/items/424eb455dc2bc99f56f9)
- 次のセクション: [ステップ1: コードレポジトリのクローンと計算資源の作成](https://qiita.com/taka_yayoi/items/501e2a6f675b3236c6d3)

### はじめてのDatabricks

[はじめてのDatabricks](https://qiita.com/taka_yayoi/items/8dc72d083edb879a5e5d)

### Databricks無料トライアル

[Databricks無料トライアル](https://databricks.com/jp/try-databricks)