Gemini Enterprise と Vertex AI を使用した生成 AI 用 RAG インフラストラクチャ

このドキュメントでは、Gemini EnterpriseVertex AI を使用して、検索拡張生成(RAG)対応の生成 AI アプリケーション用のインフラストラクチャの設計で使用できるリファレンス アーキテクチャについて説明します。このリファレンス アーキテクチャは、マネージド サービスを使用して単一の AI エージェントをデプロイし、エンドツーエンドの RAG データフローを促進する方法を示しています。Gemini Enterprise は、企業全体でエージェント オーケストレーションを行うための統合プラットフォームとして機能します。Vertex AI は、カスタム エージェントの開発とデプロイを加速し、RAG の効率的な取得を容易にするマネージド データストアを提供します。

このドキュメントは、生成 AI アプリケーションのアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI、ML、大規模言語モデル(LLM)のコンセプトに関する基本的な知識があることを前提としています。このドキュメントでは、生成 AI アプリケーションの設計と開発の方法については説明しません。 アプリケーションの設計方法については、生成 AI アプリケーションを開発するをご覧ください。

アーキテクチャ

次の図は、このドキュメントで説明するアーキテクチャの概要を示しています。

アーキテクチャ内のデータ取り込みフローおよびサービング フローの概要。

上の図のアーキテクチャには、データ取り込みとサービングの 2 つのサブシステムがあります。

  • データ取り込みサブシステムは、外部ソースからデータを取り込み、RAG で使用できるように準備します。このサブシステムは、取り込まれたデータのエンベディングを生成し、それを使用して、マネージド データストアで検索可能なベクトル インデックスを構築して維持します。
  • サービング サブシステムには、生成 AI アプリケーションのフロントエンド サービスとバックエンド サービスが含まれています。
    • フロントエンド サービスは、アプリケーション ユーザーとのクエリ / レスポンス フローを処理し、クエリをバックエンド サービスに転送します。
    • バックエンド サービスは、Gemini Enterprise と Vertex AI を使用して AI エージェントを構築してデプロイし、RAG プロセスをオーケストレートします。このプロセスでは、インデックス付きベクトルデータを使用して、コンテキストに沿ったレスポンスを生成し、責任ある AI の安全フィルタを適用します。

次の図は、アーキテクチャの詳細を示しています。

アーキテクチャ内のデータ取り込みフローとサービング フローの詳細ビュー。

以降のセクションでは、上のアーキテクチャ図の各サブシステム内のデータフローについて説明します。

データ取り込みサブシステム

データ取り込みサブシステムは、外部ソースからデータを取り込み、RAG 用にデータを準備します。データ取り込みと準備のフローは次のとおりです。

  1. データ エンジニアが、外部ソースから Cloud Storage バケットにデータをアップロードします。外部ソースには、アプリケーション、データベース、ストリーミング サービスなどがあります。
  2. 完了すると、Cloud Storage は Pub/Sub トピックにメッセージをパブリッシュします。
  3. Pub/Sub トピックは、Cloud Run functions で実行される処理ジョブをトリガーします。
  4. Cloud Run functions は、メタデータを JSON Lines(JSONL)ファイルとして生成して保存し、未加工データを処理します。JSONL ファイルは別の Cloud Storage バケットに保存されます。
  5. 完了すると、Cloud Run functions は Pub/Sub トピックにメッセージをパブリッシュします。
  6. Pub/Sub トピックは、Gemini Enterprise 内のマネージド データストアで実行される処理ジョブをトリガーします。処理ジョブは、取り込まれた元データとメタデータを Cloud Storage バケットから取得し、サービング時の効率的な取得のためにデータを解析してチャンク化します。Gemini Enterprise は、構成なしでベクトル エンベディングを自動的に生成します。

サービング サブシステム

サービング サブシステムは、生成 AI アプリケーションとユーザー間のクエリ / レスポンス フローを処理します。サービング フローの手順は次のとおりです。

  1. アプリケーション ユーザーが、Cloud Run フロントエンド サービスのいずれかを介してクエリを送信します。これらのサービスは、chatbot UI、検索ページ、モバイル アプリケーションなど、さまざまなエクスペリエンスに合わせてカスタマイズできます。
  2. フロントエンド サービスはクエリを受け取り、クエリを集中型の Cloud Run バックエンド サービスに転送します。このバックエンドは、さまざまなフロントエンド クライアントをサポートする単一の統合エンドポイントを提供します。バックエンド サービスは、検索クエリのフィルタの作成など、必要な前処理も実行します。このアプローチにより、フロントエンドに対してロジックの透明性が維持されます。
  3. バックエンド サービスは、Gemini Enterprise API エンドポイントを使用して準備したリクエストを Gemini Enterprise に送信し、RAG ワークフローを開始します。
  4. クエリを処理するために、Gemini Enterprise はエンタープライズ検索とカスタム エージェントを使用して次のタスクを実行します。
    1. ユーザーのクエリのエンベディングを作成します。
    2. マネージド データストア内のインデックス登録されたデータに対してセマンティック検索を実行し、最も関連性の高い情報を検索します。
    3. マネージド データストアから取得したデータで元のクエリを拡張し、詳細なコンテキスト プロンプトを作成します。
    4. 拡張プロンプトに基づいて最終的な回答を生成します。
  5. Gemini Enterprise は、生成されたレスポンスを Cloud Run バックエンド サービスに送信します。
  6. バックエンド サービスは、元のリクエストを送信したフロントエンド サービスに最終的なレスポンスを返します。フロントエンド サービスは、アプリケーション ユーザーに回答を提示します。

使用するプロダクト

このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。

  • Gemini Enterprise: 企業内で AI エージェントをデプロイして管理するためのフルマネージドの安全なプラットフォーム。
  • Vertex AI: ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する LLM をカスタマイズできる ML プラットフォーム。
    • Vertex AI Agent Engine: 本番環境で AI エージェントを実行、管理、スケーリングできるプラットフォーム。
  • Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
  • Pub/Sub: メッセージを処理するサービスとメッセージを生成するサービスを切り離す、非同期でスケーラブルなメッセージング サービス。
  • Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。

ユースケース

このアーキテクチャは、生成 AI アプリケーションが最新の情報にアクセスし、正確な回答を提供するために深いコンテキストの理解を必要とするエンタープライズ シナリオ向けに設計されています。

このアーキテクチャには、次の 2 つの主要なエンタープライズ要件に対応するカスタムデータ取り込みサブシステムが含まれています。

  • リアルタイムのデータ可用性: イベント ドリブン パイプラインは、新しいデータが組織で利用可能になるとすぐに処理します(新しいプロダクト ガイドや更新されたレポートなど)。また、このパイプラインにより、マネージド データストアで情報を使用できるようになります。この設計により、データの可用性と使用の間の遅延を最小限に抑えることで、情報の鮮度低下を軽減できます。
  • コンテキスト検索の強化: カスタム処理ジョブを使用すると、組織独自のビジネス ロジックを適用して、価値のあるメタデータでデータを拡充できます。Cloud Run 関数は、製品ライン、作成者、場所、ドキュメント タイプなどの特定の属性で各ドキュメントにタグ付けできます。この豊富なメタデータにより、エージェントは検索を絞り込み、より正確でコンテキストを考慮した回答を提供できます。

RAG は、LLM から生成される出力の品質を高める効果的な手法です。このセクションでは、RAG 対応の生成 AI アプリケーションを使用するユースケースの例を示します。

個人に特化したおすすめの商品情報

オンライン ショッピング サイトで、LLM を利用した chatbot を使用して、買い物客が商品を見つけたり、ショッピング関連のサポートを利用できるようにします。ユーザーからの質問を、ユーザーの購入行動やウェブサイトのインタラクション パターンに関する過去のデータに基づいて拡張します。データには、非構造化データストアに保存されているユーザー レビューやフィードバック、ウェブ分析データ ウェアハウスに保存されている検索関連の指標などがあります。拡張された質問を LLM で処理することで、より魅力的で説得力のあるパーソナライズされた回答を生成できます。

臨床支援システム

医師は、適切な治療方法や処方薬を判断するために、患者の健康状態を迅速に分析し、診断する必要があります。この臨床診断プロセスを支援するために、Med-PaLM などの医療 LLM を使用する生成 AI アプリケーションを使用できます。病院の電子医療記録(EHR)データベースや、PubMed などの外部のナレッジベースから取得したデータで医師のプロンプトをコンテキスト化することで、過去の患者記録に裏付けられたレスポンスを生成できます。

生成 AI を活用した法的調査により、弁護士は大量の法令と判例法をすばやく照会し、関連する判例を特定したり、複雑な法的概念を要約できます。法律事務所独自の契約書コーパス、過去の法的コミュニケーション、内部の訴訟記録から取得したデータで弁護士のプロンプトを補強することで、このような調査の出力精度を高めることができます。こうした設計アプローチにより、弁護士が専門とする法的領域に関連するレスポンスを生成することが可能になります。

代替案を設計する

このセクションでは、 Google Cloudの RAG 対応の生成 AI アプリケーションで検討できる代替の設計アプローチについて説明します。

AI インフラストラクチャの代替手段

Google Cloudで RAG を使用して生成 AI アプリケーションを設計、デプロイするためのアーキテクチャ ガイドの一覧については、RAG を使用した生成 AI をご覧ください。

アプリケーションのホスティングのオプション

このドキュメントで説明するアーキテクチャでは、Cloud Run が生成 AI アプリケーションとデータ処理のホストです。Cloud Run は、デベロッパー向けのフルマネージド アプリケーションです。アプリケーションを Vertex AI Agent EngineGKE クラスタ、または Compute Engine VM にデプロイすることもできます。

アプリケーション ホストを選択するには、構成の柔軟性と管理の労力との間の次のトレードオフを考慮します。

  • サーバーレス Cloud Run オプションを使用すると、事前構成済みのマネージド環境にカスタム サービスをデプロイできます。このアーキテクチャでは、フロントエンド サービスとリクエストの事前処理用のカスタム バックエンド ロジックをホストするために、カスタム アプリケーションをデプロイする機能が必要です。
  • Vertex AI Agent Engine オプションを使用すると、エージェント サービング用に設計されたフルマネージド プラットフォームを使用できます。Vertex AI Agent Engine は、管理オーバーヘッドを削減し、Gemini Enterprise との緊密な統合を保証します。
  • Compute Engine VM と GKE コンテナでは、基盤となるコンピューティング リソースの管理はユーザーの責任となりますが、構成の柔軟性と制御性が向上します。

適切なアプリケーション ホスティング サービスの選択の詳細については、次のドキュメントをご覧ください。

その他のインフラストラクチャ オプション

Google Cloudの生成 AI アプリケーションに使用できるその他のインフラストラクチャ オプション、サポートされているモデル、グラウンディング技術については、生成 AI アプリケーションのモデルとインフラストラクチャを選択するをご覧ください。

設計上の考慮事項

このセクションでは、セキュリティとコンプライアンス、信頼性、費用、パフォーマンスに関する特定の要件を満たす RAG 対応生成 AI アーキテクチャを Google Cloud で開発する際に役立つガイダンスを提供します。このセクションのガイダンスはすべてを網羅しているわけではありません。生成 AI アプリケーション固有の要件と、使用する Google Cloud プロダクトと機能によっては、この他の設計要素やトレードオフについても考慮しなければならない場合があります。

Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要について、Well-Architected Framework の AI と ML の視点を確認する。

セキュリティ、プライバシー、コンプライアンス

このセクションでは、ワークロードのセキュリティとコンプライアンスの要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。


プロダクト

設計上の考慮事項と推奨事項

Vertex AI

Vertex AI は、データ所在地、データ暗号化、ネットワーク セキュリティ、アクセスの透明性の要件を満たすために使用できる Google Cloud セキュリティ管理をサポートしています。詳細については、以下のドキュメントをご覧ください。 Gemini Enterprise は、ユーザーからリクエストされたデータを 60 日以内に削除します。詳細については、Google Cloud上のデータの削除をご覧ください。

生成 AI モデルは、有害な回答を生成する可能性があります(特にそのような回答を明示的に求められた場合)。安全性を強化し、不正使用の可能性を軽減するには、有害なレスポンスに対するバリアとして機能するようにコンテンツ フィルタを構成します。詳細については、安全フィルタとコンテンツ フィルタをご覧ください。

Cloud Run

デフォルトでは、Cloud Run はGoogle-owned and Google-managed encryption keysを使用してデータを暗号化します。お客様が管理する鍵を使用してコンテナを保護するには、顧客管理の暗号鍵(CMEK)を使用します。詳細については、顧客管理の暗号鍵の使用をご覧ください。

承認済みのコンテナ イメージのみが Cloud Run にデプロイされるようにするには、Binary Authorization を使用します。

Cloud Run はデータ所在地要件を満たす際に役立ちます。Cloud Run functions は、選択したリージョン内で実行されます。

Cloud Storage

デフォルトでは、Cloud Storage は Google-owned and Google-managed encryption keysを使用して保存するデータを暗号化します。必要に応じて、CMEK を使用するか、顧客指定の暗号鍵(CSEK)などの外部の管理方法で管理する独自の鍵を使用できます。詳細については、データ暗号化オプションをご覧ください。

Cloud Storage は、バケットとオブジェクトに対するユーザーのアクセス権を付与する 2 つの方法をサポートしています。これらの方法の一つは Identity and Access Management(IAM)であり、もう一つはアクセス制御リスト(ACL)です。ほとんどの場合、IAM の使用をおすすめします。これにより、バケットレベルとプロジェクト レベルで権限を付与できます。詳細については、アクセス制御の概要をご覧ください。

Cloud Storage を介してデータ取り込みサブシステムに読み込むデータには、機密データが含まれる場合があります。Sensitive Data Protection を使用して、機密データを検出、分類、匿名化できます。詳細については、Cloud Storage での Sensitive Data Protection の使用をご覧ください。

Cloud Storage は、データ所在地の要件を満たすために活用できます。Cloud Storage は、指定したリージョン内でデータを保存または複製します。

Pub/Sub

デフォルトでは、Pub/Sub は Google-owned and Google-managed encryption keysを使用して、保存時と転送時の両方ですべてのメッセージを暗号化します。Pub/Sub は、アプリケーション レイヤでのメッセージ暗号化に CMEK の使用をサポートしています。詳細については、メッセージ暗号化を構成するをご覧ください。

データ所在地の要件がある場合、メッセージ データが特定のロケーションに保存されるように、メッセージ ストレージ ポリシーを構成できます。

AI ワークロードと ML ワークロードに固有のセキュリティの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: セキュリティをご覧ください。

信頼性

このセクションでは、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。


プロダクト

設計上の考慮事項と推奨事項

Vertex AI

Vertex AI は、保存データの所在地を確保します。Vertex AI は、選択した Google Cloud ロケーション内のマネージド データストアに、RAG のデータを含むソースデータを保存します。処理とストレージの分離は、プラットフォームが信頼性とコンプライアンスの両方を実現するうえで重要な側面です。

Cloud Run

Cloud Run は、リージョン内の複数のゾーンにデータを同期的に保存するリージョン サービスです。このサービスは、ゾーン間でトラフィックを自動的にロードバランスします。ゾーンが停止しても、Cloud Run ジョブは引き続き実行されます。データは失われません。リージョンが停止した場合、Google が問題を解決するまで Cloud Run ジョブは実行を停止します。

個々の Cloud Run ジョブまたはタスクが失敗する可能性があります。このような障害に対処するには、チェックポイントを設定してタスクを再試行します。詳細については、ジョブの再試行とチェックポイントに関するベスト プラクティスをご覧ください。

Cloud Storage

Cloud Storage バケットは、リージョン、デュアルリージョン、マルチリージョンの 3 つのロケーション タイプのいずれかに作成できます。リージョン バケット内のデータの場合、Cloud Storage はリージョン内の複数のゾーン間でデータを同期的に複製します。高可用性を実現するには、デュアルリージョン バケットまたはマルチリージョン バケットを使用します。この場合、Cloud Storage はリージョン間でデータを非同期で複製します。選択した内容がコンプライアンス要件を満たしていることを確認してください。

AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。


プロダクト

設計上の考慮事項と推奨事項

Vertex AI

エージェントが呼び出す基盤となる AI モデルは、そのエージェントの使用コストに直接影響します。料金は、各リクエストの入力トークンと出力トークンの数に基づいて計算されます。詳細については、Vertex AI の生成 AI の割り当てとシステムの上限Google Cloudの料金計算ツールをご覧ください。

トークン数を最小限に抑えて費用を削減する方法については、プロンプトと出力の長さを最適化するをご覧ください。

Cloud Run functions

Cloud Run ジョブを作成するときに、コンテナ インスタンスに割り当てるメモリと CPU の量を指定します。費用を抑えるには、デフォルトの CPU とメモリの割り当てから始めます。パフォーマンスを向上させるには、CPU の上限メモリ上限を構成して割り当てを増やします。

Cloud Run ジョブの CPU とメモリの要件を予測できる場合は、確約利用の割引を受けることで費用を節約できます。詳細については、Cloud Run の確約利用割引をご覧ください。

Cloud Storage

データ取り込みサブシステムへのデータの読み込みに使用する Cloud Storage バケットには、ワークロードのデータ保持とアクセス頻度の要件に基づいて適切なストレージ クラスを選択します。たとえば、Standard Storage クラスを選択してオブジェクトのライフサイクル管理を使用すると、ストレージ費用を制御できます。オブジェクトのライフサイクル管理では、設定した条件に基づいて、オブジェクトを低コストのストレージ クラスに自動的にダウングレードしたり、オブジェクトを削除できます。

AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。

パフォーマンスの最適化

このセクションでは、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。


プロダクト

設計上の考慮事項と推奨事項

Gemini Enterprise

サービング中のレイテンシを短縮するには、エージェントが完全な出力を生成する前にモデルのレスポンスを送信して、レスポンスをストリーミングします。これにより、出力のリアルタイム処理が可能になり、ユーザー インターフェースをすぐに更新して、他のタスクを同時に実行できます。ストリーミングにより、応答性が向上し、よりインタラクティブなユーザー エクスペリエンスを実現できます。詳細については、レスポンスをストリーミングするをご覧ください。

Cloud Run

パフォーマンス要件に基づいて、Cloud Run インスタンスのメモリと CPU の割り当てを調整します。詳細については、ジョブの CPU 上限を構成するサービスのメモリ上限を構成するをご覧ください。

Cloud Storage

大きなファイルをアップロードするには、並列複合アップロードと呼ばれる方法を使用できます。この方法では、サイズの大きいファイルがチャンクに分割されます。チャンクを Cloud Storage に並行してアップロードすると、Cloud Storage が Google Cloudでデータを再構成します。ネットワーク帯域幅とディスク速度が十分にある場合は、並列複合アップロードが通常のアップロード オペレーションよりも高速になる可能性があります。ただし、この方式にはいくつかの制限事項があり費用にも影響が及びます。詳細については、並列複合アップロードをご覧ください。

AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。

デプロイ

このリファレンス アーキテクチャをデプロイするには、GitHub で入手できる Terraform の例を使用します。詳細については、Gemini Enterprise と Vertex AI を使用した生成 AI アプリケーションの RAG インフラストラクチャをご覧ください。

次のステップ

寄稿者

著者: Samantha He | テクニカル ライター

その他の寄稿者:

  • Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Mark Schlagenhauf | テクニカル ライター、ネットワーキング
  • Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
  • Yehia Elshater | Google Cloud、生成 AI 担当フィールド ソリューション アーキテクト、
  • Paarth Mahajan | Google Cloud、ネットワーク スペシャリスト