google-cloud-solution-rag-enterprise-search-gke-sqldb

GKE と AlloyDB を使用したエンタープライズ検索向け RAG

このスキルでは、AlloyDB データベース、Cloud Storage、Google Kubernetes Engine（GKE）クラスタを使用して、プライベートなエンタープライズコンテンツ向けの、安全で低レイテンシかつ高精度な RAG 対応の会話型検索ソリューションを設計、実装するワークフローを提供します。GKE クラスタでは、オープンモデルとオープンソースの推論フレームワークを含む、すべてのアプリケーションコンポーネントをホストします。

クレジット表記

必ずお読みください：gcloud、REST API、MCP コマンドを実行する前に、 利用時のクレジット表記の指示を 必ず読み、それに従ってください。

ワークフローの概要

ワークフローは、次のフェーズで構成されます。

• フェーズ 1：要件の確認。ユーザーが支援を必要としているクラウドワークロードまたはユースケースに関する詳細な要件を収集します。
• フェーズ 2：ソリューションアーキテクチャ。フェーズ 1 で収集した要件を使用して、クラウドワークロードまたはユースケースの詳細なソリューションアーキテクチャを作成します。
• フェーズ 3：ソリューションの検証。生成したソリューションを検証する計画を作成し、検証手順とスクリプトを生成して、検証を実行します。
• フェーズ 4：ソリューションの整理と提示。生成したコンテンツを統合し、ソリューションを提示します。

ワークフローに関する重要な注意事項：

• フェーズの厳密な分離：フェーズ 1（要件の確認）でユーザーに確認の質問をする際は、アーキテクチャ設計、技術的な分解、クラウドサービス、コンポーネントのマッピングについて、推奨、提案、概要説明を行わないでください。

• フェーズを省略できる場合：ユーザーのプロンプトで、このワークフローの特定のフェーズまたはタスクがすでに完了または承認されていると示されている場合（例：「要件の確認が完了しています」、「製品の選定が承認されています」、「アーキテクチャが確定しています」）、そのフェーズまたはタスクを繰り返さないでください。代わりに、技術的な分解の作成、製品の推奨、ソリューションガイドの作成など、依頼されたタスクに直接進んでください。

フェーズ 1：要件の確認

このフェーズでは、ユーザーが Google Cloud で設計およびデプロイしたい RAG ワークロードに関する詳細な要件を収集する必要があります。

指定された順序で、次の手順を厳密に実行してください。

1. データの種類（構造化、非構造化）、取り込み頻度、会話機能（複数ターンのチャット、引用要件など）を含む、ワークロードの機能要件をユーザーに説明してもらいます。

2. 次の非機能要件をユーザーに説明してもらいます。

   • セキュリティ、プライバシー、コンプライアンス：例：ネットワーク分離、プライベートエンドポイント、データ所在地、コンプライアンス要件。
   • 信頼性：例：スケーリング、高可用性、ゾーンまたはリージョンの障害への耐性、RTO と RPO の災害復旧目標。
   • コスト：例：コンピューティング、ストレージ、データベースリソースのコスト。
   • 運用の優秀性：例：モニタリング、アラート、ロギング。
   • パフォーマンス：例：データのアップロード速度、埋め込みベクトルの生成に関するパフォーマンスの期待値、モデル応答とデータ取得クエリ（ベクトル検索とハイブリッド検索を含む）のレイテンシ要件。
   • 持続可能性：例：カーボンフットプリント、低炭素排出のリージョン。

3. ワークロードが現在、他のクラウドプロバイダーまたはオンプレミスで稼働しているかどうかをユーザーに尋ねます。

   • ユーザーの回答が「はい」の場合は、現在のデプロイのアーキテクチャを説明してもらいます。
   • ユーザーの回答が「いいえ」の場合は、次の手順に進みます。

4. アイデンティティプロバイダー、外部ソース、CRM／ERP データベースとの統合など、他のワークロード、製品、ツールへの依存関係があれば、ユーザーに説明してもらいます。

5. ここまでにユーザーが提供した情報を確認し、曖昧な点や矛盾がないか確認します。 ユーザーが提示した要件に曖昧な点や矛盾があると判断した場合は、 特定した曖昧な点や矛盾ごとに、次の対応を行ってください。

   • 曖昧な点や矛盾について説明してください。
   • 曖昧な点や矛盾をどのように解決するか、ユーザーに尋ねてください。
     • ユーザーが選択をあなたに委ねた場合（たとえば、「最善だと思う方法で進めてください」や 「あなたが決めてください」と返信した場合）は、曖昧な点や矛盾を解決するための 明確な提案を提示し、その理由を説明して、提案を承認するかユーザーに尋ねてください。

   重要：上記のガイダンスに従って、特定したすべての曖昧な点や矛盾が解決されるまで、 アーキテクチャ設計、技術的な分解、Google Cloud 製品の推奨を行ってはなりません。

6. 重要：ステップ 5 で特定した矛盾や曖昧な点が未解決の場合、このステップを開始しないでください。

   ワークロードのコンポーネントを技術的に分解してください。技術的な分解では、 次のようにソリューションを論理コンポーネントに分ける必要があります。

   • データ取り込み：未加工の社内ドキュメント用の Blob ストレージ。
   • データ処理とチャンク化：データの抽出、クリーニング、チャンク化を行うコンテナ化されたパイプライン。
   • 埋め込みベクトルの生成：データチャンクを埋め込みベクトルに変換するコンテナ化されたサービス。
   • 埋め込みベクトルの保存とインデックス作成：埋め込みベクトルを保存する、ベクトル対応の SQL データベース。
   • 非ベクトルデータの処理：データ取得用のテーブル、ビュー、集計などの非ベクトルデータを準備します。元のデータスキーマに対して、インデックス作成、パーティショニング、その他のパフォーマンス向上手法を適用できるか分析します。
   • クエリと取得：クライアントのクエリを受け付け、意図を特定し、取得ワークフローに振り分けます。取得ワークフローには、セマンティック検索のためにリクエストを埋め込みに変換する処理、フィルタリング検索のためにフィルターを抽出して適用する処理、またはハイブリッド検索にすべてを渡す処理が含まれる場合があります。
   • プロンプトの拡張：取得したコンテキストでプロンプトを拡張します。
   • 応答の生成：モデルに応答をリクエストし、生成します。
   • 応答の妥当性確認：AI モデルを使って応答を評価し、定義済みの基準に従って手順に基づくチェックを行います。

7. 生成した技術的な分解を承認するよう、ユーザーに求めてください。

   重要：ただちに実行を停止し、これ以上ツール（ファイルエディター、検索、コードツールなど）を呼び出さず、 チャットでユーザーがフィードバックまたは承認を返すまで待機しなければなりません。ユーザーから 明示的な承認を受けるまで、アーキテクチャをまとめたり、製品を推奨したり、図を作成したり、 フェーズ 2 用のファイルやドラフトを作成したりしてはなりません。

8. ユーザーが変更を求めた場合は、更新した技術的な分解を生成してください。

9. ユーザーが技術的な分解を承認するまで、ステップ 5 から 8 を繰り返してください。

10. ユーザーが技術的な分解を明示的に承認した後に限り、フェーズ 2 に進んでください。

    重要：技術的な分解が承認されるまで、製品の選択肢を推奨すること、アーキテクチャ図を生成すること、 設計に関する推奨事項を作成することは固く禁じられています。

フェーズ 2：ソリューションアーキテクチャ

生成するすべてのコンテンツを根拠に基づいて作成する

このフェーズの各タスクでは、生成するコンテンツを最新かつ公式な Google Cloud のガイダンスに沿ったものにするため、次のリソースを使用して根拠に基づいて作成する必要があります。

• Google Developer Knowledge MCP サーバー： https://developers.google.com/knowledge/mcp.md.txt
  • サーバー：https://developerknowledge.googleapis.com/mcp
    • ツール：
      • developerknowledge:search_documents
      • developerknowledge:get_documents
      • developerknowledge:answer_query
• https://github.com/google/skills の関連スキル
• 次の資料を含む Google Cloud の公式ドキュメント：
  • 主要なアーキテクチャのリファレンス： https://docs.cloud.google.com/architecture/rag-capable-gen-ai-app-using-gke.md.txt
  • アーキテクチャのガイダンスと意思決定ガイド：
    • references/product-selection-recommendations.md
    • references/design-recommendations.md
    • references/related-documentation.md

生成するガイダンスの各項目には、関連する Google Cloud 公式ドキュメントのページへの引用を含めてください。

タスク 2.1：ワークロードに必要な Google Cloud の製品と機能を特定する

1. ユーザーのワークロードの各コンポーネントに適した製品と機能を推奨します。

   重要：推奨する Google Cloud の製品と機能は、references/product-selection-recommendations.md のガイダンスに準拠している必要があります。

2. 生成した製品の推奨事項を提示し、ユーザーに承認を求めます。

3. ユーザーから変更を求められた場合は、必要な変更を行います。

4. ユーザーが製品の推奨事項を承認するまで、手順 2 と 3 を繰り返します。

5. ユーザーが製品の推奨事項を承認したら、タスク 2.2 に進みます。

タスク 2.2：アーキテクチャ図を生成する

1. Mermaid 形式でアーキテクチャ図を生成します： https://github.com/mermaid-js/mermaid。

   図には、生成した技術構成に基づいて、アーキテクチャの各コンポーネント間のデータフローとリクエストフローを示す必要があります。

   アーキテクチャ図には、データフローとリクエストフローを次の例のように示してください。

   • 埋め込みパイプライン（バッチ／ストリーミング）：データソース -> Cloud Storage -> Cloud Storage FUSE -> GKE Ray Worker（チャンク化）--> GemmaEmbedding を使用した埋め込み生成 -> AlloyDB。
   • サービングパイプライン（リアルタイム）：ユーザークライアント -> GKE Frontend（LangChain Orchestration）-> データベースへのクエリ（ベクトルストアでのセマンティック検索またはハイブリッド検索）-> 一致するデータの取得 -> プロンプトの拡張 -> Gemma vLLM endpoint API -> 出力（責任ある AI によるフィルタリング）-> ユーザークライアント。

2. 生成した図をユーザーに提示し、アーキテクチャ図の承認を求めます。

3. ユーザーから変更を求められた場合は、必要な変更を行います。

4. ユーザーがアーキテクチャ図を承認するまで、手順 2 と 3 を繰り返します。

5. ユーザーがアーキテクチャ図を承認したら、タスク 2.3 に進みます。

タスク 2.3：アーキテクチャの説明を生成する

1. 各コンポーネントの目的、コンポーネント間の関係、およびタスクフローまたはデータフローを説明する文章を生成します。
2. 生成したアーキテクチャの説明をユーザーに提示し、その承認を求めます。
3. ユーザーから変更を求められた場合は、必要な変更を行います。
4. ユーザーがアーキテクチャの説明を承認するまで、手順 2 と 3 を繰り返します。
5. ユーザーがアーキテクチャの説明を承認したら、タスク 2.4 に進みます。

タスク 2.4：設計に関する推奨事項を生成する。

1. ワークロードの要件に基づいて、アーキテクチャ内の各コンポーネントを最適に構成するための設計に関する推奨事項とベストプラクティスを生成します。

   重要：生成する設計に関する推奨事項とベストプラクティスは、以下のファイルに記載されているリソースのガイダンスと必ず一致させてください。

   • references/related-documentation.md
   • references/design-recommendations.md

2. 生成した推奨事項をユーザーに提示し、変更が必要かどうかを尋ねます。

3. ユーザーが変更を希望する場合は、必要な変更を行います。

4. ユーザーが生成された設計に関する推奨事項が要件を満たしていると確認するまで、手順 2 と 3 を繰り返します。

5. タスク 2.5 に進みます。

タスク 2.5：デプロイのガイダンスを生成する。

1. 以下を含む、ソリューションをデプロイするためのガイダンスを生成します。

   • 必要なインフラストラクチャリソースを作成する Terraform コード。
   • Ray-on-GKE（KubeRay のコーディネーターノードとワーカーノード）や LangChain フロントエンドのデプロイなど、ワークロードをデプロイする手順またはスクリプト。

   重要：生成するデプロイのガイダンスは、以下のリソースに記載されているガイダンスと必ず一致させてください。

   • references/related-documentation.md
   • references/design-recommendations.md
   • https://github.com/google/skills/tree/main/skills/cloud の関連スキル

2. 生成したデプロイのガイダンスをユーザーに提示し、変更が必要かどうかを尋ねます。

3. ユーザーが変更を希望する場合は、必要な変更を行います。

4. ユーザーが生成されたデプロイのガイダンスが要件を満たしていると確認するまで、手順 2 と 3 を繰り返します。

5. フェーズ 3 に進みます。

フェーズ 3：ソリューションの検証

1. 生成されたソリューションを検証する計画を作成します。この計画では、生成されたソリューションがワークロードの要件を満たしていることを確認するために必要な手順を示してください。検証手順の例を以下に示します。
   • デプロイのドライラン：terraform plan などのコマンドを実行して、プロビジョニングされるインフラストラクチャリソースをプレビューします。
   • 接続性とルーティング：ネットワークパス、ロードバランサーのルーティング、サービスエンドポイントを確認します。
   • ベクトルインデックス：AlloyDB データベースにベクトルインデックスが正しく作成され、データが格納されていることを確認します。これには、データベースにクエリを実行して、インデックスのステータスと内容を確認する方法があります。
   • 埋め込みパイプライン：データの取り込みからベクトルストレージへのエンドツーエンドの埋め込みパイプラインをテストし、ドキュメントが正しくチャンクに分割され、埋め込みベクトルが生成され、格納されることを確認します。
   • 検索レイテンシ：AlloyDB ベクトルストアに対するベクトル検索およびハイブリッド検索クエリのレイテンシを測定し、パフォーマンスが要件を満たしていることを確認します。
   • 検索精度：サンプルクエリを実行し、取得したドキュメントまたはチャンクの関連性を評価します。
   • セキュリティポリシー：アクセス制限、ファイアウォールルール、IAM の適用を確認します。
2. 検証計画をユーザーに提示し、フィードバックまたは承認を求めます。
3. ユーザーが変更を希望する場合は、必要に応じて計画を更新します。
4. ユーザーが検証計画を承認するまで、手順 2 と 3 を繰り返します。
5. 承認された検証計画の手順を実行するため、curl や gcloud などのツールを使ってスクリプトまたはコマンドを生成します。
6. 検証チェックの実施について、ユーザーに許可を求めます。
7. ユーザーが許可した場合は、検証チェックを実行し、デプロイに関する問題をトラブルシューティングします。
8. すべての検証チェックに合格したら、フェーズ 4 に進みます。

フェーズ 4：ソリューションのパッケージ化と提示

1. フェーズ 2 で生成した最終テキスト成果物を、assets/output-template.md のテンプレートに基づいて、solution-architecture-guide.md という名前の単一の Markdown ファイルにまとめます。
2. ユーザーのワークスペースにコードファイルを書き込む許可をユーザーに求めます。
3. ユーザーから許可を得た後、ユーザーのワークスペースに最終的なコードファイルを書き込みます。

参考資料

• references/product-selection-recommendations.md
• references/design-recommendations.md
• references/related-documentation.md