Vertex AI を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ

Last reviewed 2024-03-29 UTC

このドキュメントでは、検索拡張生成（RAG）対応の生成 AI アプリケーションを実行するインフラストラクチャの設計に使用できるリファレンス アーキテクチャについて説明します。このドキュメントは、生成 AI アプリケーションのデベロッパーと管理者、クラウド アーキテクトを対象としています。このドキュメントは、AI、ML、大規模言語モデル（LLM）のコンセプトに関する基本的な知識があることを前提としています。このドキュメントでは、生成 AI アプリケーションの設計と開発の方法については説明しません。

アーキテクチャ

次の図は、Google Cloud での RAG 対応の生成 AI アプリケーションのアーキテクチャの概要を示しています。

Google Cloud の RAG 対応生成 AI アプリケーションのアーキテクチャの概要。

このアーキテクチャは、相互に接続されている次のコンポーネントから構成されています。

コンポーネント 目的 インタラクション
データ取り込みサブシステム RAG 機能で利用する外部データを準備して処理します。 データ取り込みサブシステムは、データベース レイヤを介してアーキテクチャ内の他のサブシステムと連携しています。
サービング サブシステム 生成 AI アプリケーションとユーザー間のリクエスト / レスポンス フローを処理します。 サービング サブシステムは、データベース レイヤを介してデータ取り込みサブシステムと連携しています。
品質評価サブシステム サービング サブシステムが生成したレスポンスの品質を評価します。 品質評価サブシステムは、サービング サブシステムと直接やり取りし、データベース レイヤを介してデータ取り込みサブシステムと連携しています。
データベース 次のデータを保存します。
  • プロンプト
  • RAG で使用されるデータのベクトル化エンベディング
  • データ取り込みサブシステムと品質評価サブシステムのサーバーレス ジョブの構成
 アーキテクチャ内のすべてのサブシステムがデータベースと連携しています。

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

Google Cloud の RAG 対応生成 AI アプリケーションのアーキテクチャの詳細。

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

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

データ取り込みサブシステムは、ファイル、データベース、ストリーミング サービスなどの外部ソースからデータを取り込みます。アップロードされたデータには品質評価のプロンプトが含まれています。データ取り込みサブシステムは、アーキテクチャに RAG 機能を提供します。次の図は、このアーキテクチャのデータ取り込みサブシステムの詳細を示しています。

Google Cloud の RAG 対応生成 AI アプリケーションのデータ取り込みサブシステム。

データ取り込みフローは次のようになります。

  1. データが Cloud Storage バケットにアップロードされます。データソースは、アップロード、データベースへの取り込み、データのストリーミングを実行するアプリケーション ユーザーになります。
  2. データがアップロードされると、Pub/Sub トピックに通知が送信されます。
  3. Pub/Sub が、アップロードされたデータを処理する Cloud Run ジョブをトリガーします。
  4. Cloud Run が AlloyDB for PostgreSQL データベースに保存されている構成データを使用してジョブを開始します。
  5. Cloud Run ジョブが Document AI を使用して、以降の処理用にデータを準備します。たとえば、データの解析、必要な形式への変換、データのチャンクへの分割などを行います。

  6. Cloud Run ジョブが、Vertex AI Embeddings for Text モデルを使用して、取り込まれたデータのベクトル化エンベディングを作成します。

  7. Cloud Run が、pgvector 拡張機能が有効になっている AlloyDB for PostgreSQL データベースにエンベディングを保存します。次のセクションで説明するように、サービング サブシステムはユーザー リクエストを処理する際に、ベクトル データベース内のエンベディングを使用して、関連するドメイン固有のデータを取得します。

サービング サブシステム

サービング サブシステムは、生成 AI アプリケーションとユーザー間のリクエスト / レスポンス フローを処理します。次の図は、このアーキテクチャのサービング サブシステムの詳細を示しています。

Google Cloud の RAG 対応生成 AI アプリケーションのサービング サブシステム。

サービング サブシステムのリクエスト / レスポンス フローは次のとおりです。

  1. ユーザーが、フロントエンド（chatbot やモバイルアプリなど）を介して生成 AI アプリケーションにリクエストを送信します。

  2. 生成 AI アプリケーションが、自然言語のリクエストをエンベディングに変換します。

  3. アプリケーションが RAG アプローチの取得部分を完了します。

    1. アプリケーションが、データ取り込みサブシステムで維持されている AlloyDB for PostgreSQL ベクトルストアのエンベディングに対してセマンティック検索を実行します。セマンティック検索は、テキストのコンテンツではなく、プロンプトの意図に基づいてエンベディングを見つける際に役立ちます。
    2. アプリケーションが、一致するエンベディングに基づいて取得された元データと元のリクエストを結合し、コンテキスト化されたプロンプトを生成します。

  4. アプリケーションが、Vertex AI で実行される LLM 推論スタックにコンテキスト化されたプロンプトを送信します。

  5. LLM 推論スタックが、生成 AI LLM（基盤 LLM またはカスタム LLM）を使用して、指定されたコンテキストに制約されたレスポンスを生成します。

    1. このアプリケーションは、リクエスト / レスポンス アクティビティのログを Cloud Logging に保存できます。このログは、Cloud Monitoring で表示して、モニタリングに使用できます。Google がログデータにアクセスしたり、ログデータを使用することはありません。
    2. アプリケーションが、オフライン分析のためにレスポンスを BigQuery に読み込みます。

  6. アプリケーションが、責任ある AI フィルタを使用してレスポンスをスクリーニングします。

  7. アプリケーションが、スクリーニングされたレスポンスをフロントエンド経由でユーザーに送信します。

品質評価サブシステム

次の図は、アーキテクチャの品質評価サブシステムの詳細を示しています。

Google Cloud の RAG 対応生成 AI アプリケーションの品質評価サブシステム。

リクエストを受け取ると、品質評価サブシステムは次の処理を行います。

  1. Pub/Sub が Cloud Run ジョブをトリガーします。
  2. Cloud Run が AlloyDB for PostgreSQL データベースに保存されている構成データを使用してジョブを開始します。
  3. Cloud Run ジョブが、AlloyDB for PostgreSQL データベースから評価プロンプトを取得します。プロンプトは、すでにデータ取り込みサブシステムによってデータベースにアップロードされています。

  4. Cloud Run ジョブが、評価プロンプトを使用して、サービング サブシステムが生成したレスポンスの品質を評価します。

    この評価の出力は、事実の正確性や関連性などの指標の評価スコアで構成されます。

  5. Cloud Run が、将来の分析のために評価スコアと、評価されたプロンプトとレスポンスを BigQuery に読み込みます。

使用するプロダクト

前述のアーキテクチャで使用される Google Cloud プロダクトは次のとおりです。

  • Vertex AI: ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する LLM をカスタマイズできる ML プラットフォーム。
  • Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
  • BigQuery: ML、地理空間分析、ビジネス インテリジェンスなどの組み込み機能を使用してデータの管理と分析を支援する、Google Cloud のフルマネージド エンタープライズ データ ウェアハウス。
  • Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloud の内部および外部からアクセスできます。また、冗長性を確保するため、ロケーション間で複製されています。
  • AlloyDB for PostgreSQL: トランザクションと分析のハイブリッド処理など、特に要求の厳しいワークロード向けに設計された、PostgreSQL 対応のフルマネージド データベース サービス。
  • Document AI: ドキュメントから非構造化データを取り出して構造化データに変換するドキュメント処理プラットフォーム。
  • Pub/Sub: メッセージを処理するサービスとメッセージを生成するサービスを切り離す、非同期でスケーラブルなメッセージング サービス。
  • Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
  • Cloud Monitoring: アプリケーションとインフラストラクチャのパフォーマンス、可用性、動作状況を可視化するサービス。

ユースケース

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

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

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

臨床支援システム

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

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

設計上の考慮事項

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

セキュリティとコンプライアンス

このセクションでは、セキュリティとコンプライアンスの要件を満たす RAG 対応の生成 AI アプリケーションを Google Cloud で設計して構築する際に考慮すべき要素について説明します。

プロダクト 設計上の考慮事項
Vertex AI Vertex AI がサポートしている Google Cloud セキュリティ管理により、データ所在地、データ暗号化、ネットワーク セキュリティ、アクセスの透明性の要件を満たすことができます。詳細については、Vertex AI のセキュリティ管理と生成 AI のセキュリティ管理をご覧ください。
Cloud Run

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

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

Cloud Run はデータ所在地の要件を満たすのに役立ちます。Cloud Run コンテナ インスタンスは、選択したリージョン内で実行されます。
AlloyDB for PostgreSQL

デフォルトでは、AlloyDB for PostgreSQL に保存されるデータは、Google が管理する暗号鍵を使用して暗号化されます。お客様が制御、管理する暗号鍵を使用する必要がある場合は、CMEK を使用できます。詳細については、CMEK についてをご覧ください。

AlloyDB for PostgreSQL データベースからデータが漏洩するリスクを軽減するには、VPC Service Controls を使用してサービス境界を作成します。

デフォルトでは、AlloyDB for PostgreSQL インスタンスは SSL 接続のみを受け入れます。AlloyDB for PostgreSQL データベースへの接続をさらに保護するには、AlloyDB for PostgreSQL Auth Proxy コネクタを使用します。Auth Proxy コネクタは Identity and Access Management（IAM）ベースの接続認可を提供します。256 ビット AES 暗号による TLS 1.3 接続を使用して、クライアントとサーバーの ID を検証し、データ トラフィックを暗号化します。詳細については、AlloyDB for PostgreSQL Auth Proxy についてをご覧ください。Java、Python、Go を使用して作成した接続の場合は、Auth Proxy コネクタではなく、適切な言語コネクタを使用します。

AlloyDB for PostgreSQL は、データ所在地の要件を満たすのに役立ちます。データは、指定したリージョン内で保存または複製されます。
BigQuery

BigQuery には、データへのアクセスの制御、機密データの保護、データの正確性と整合性の確保に使用できる多くの機能が用意されています。詳細については、BigQuery のデータ ガバナンスの概要をご覧ください。

BigQuery は、データ所在地の要件を満たすのに役立ちます。データは指定したリージョンに保存されます。
Cloud Storage

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

Cloud Storage は、バケットとオブジェクトにアクセスするためのユーザー権限を付与する 2 つのシステムをサポートしています。1 つは IAM、もう 1 つはアクセス制御リスト（ACL）です。ほとんどの場合は IAM の使用をおすすめします。これにより、バケットレベルとプロジェクト レベルで権限を付与できます。詳細については、アクセス制御の概要をご覧ください。

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

Cloud Storage は、データ所在地の要件を満たすのに役立ちます。データは、指定したリージョン内で保存または複製されます。
Pub/Sub

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

データ所在地の要件がある場合、メッセージ データが特定のロケーションに保存されるように、メッセージ ストレージ ポリシーを構成できます。
Document AI デフォルトでは、保存データは Google 管理の暗号鍵で暗号化されます。お客様が制御、管理する暗号鍵を使用する必要がある場合は、CMEK を使用できます。詳細については、Document AI のセキュリティとコンプライアンスをご覧ください。
Cloud Logging

このリファレンス アーキテクチャで使用されるすべての Google Cloud サービスで、管理アクティビティ監査ログがデフォルトで有効になっています。これらのログには、Google Cloud リソースの構成やメタデータを変更する API 呼び出しなどのアクションが記録されます。

BigQuery では、データアクセス監査ログがデフォルトで有効になっています。このアーキテクチャで使用される他のサービスでは、データアクセス監査ログを有効にできます。このログでは、リソースの構成やメタデータを読み取る API 呼び出しや、ユーザー提供のリソースデータの作成、変更、読み取りを行うユーザー リクエストを追跡できます。

データ所在地の要件を満たすために、指定したリージョンにログデータを保存するように Cloud Logging を構成できます。詳細については、ログをリージョン化するをご覧ください。

AI アプリケーションで考慮すべきセキュリティ原則に関する一般的なガイダンスについては、Google のセキュア AI フレームワークの概要をご覧ください。

信頼性

このセクションでは、Google Cloud で RAG 対応の生成 AI アプリケーション用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。

プロダクト 設計上の考慮事項
Cloud Run

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

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

デフォルトでは、AlloyDB for PostgreSQL クラスタは自動フェイルオーバーによる高可用性（HA）を提供します。プライマリ インスタンスには、リージョン内の 2 つの異なるゾーンに配置された冗長ノードがあります。この冗長性により、ゾーンの停止に対してクラスタの堅牢性が確保されます。

リージョン停止からの復旧を計画するには、クロスリージョン レプリケーションを使用します。
BigQuery

BigQuery に読み込むデータは、指定したリージョン内の 2 つのゾーンに同期的に保存されます。この冗長性により、ゾーン停止時のデータ消失を防ぐことができます。

BigQuery の信頼性に関する機能の詳細については、信頼性についてをご覧ください。
Cloud Storage Cloud Storage バケットは、リージョン、デュアルリージョン、マルチリージョンの 3 つのロケーション タイプのいずれかに作成できます。リージョン バケットに格納されたデータは、リージョン内の複数のゾーン間で同期的に複製されます。高可用性を実現するには、デュアルリージョンまたはマルチリージョン バケットを使用します。この場合、データはリージョン間で非同期で複製されます。
Pub/Sub

メッセージ トラフィックの一時的な急増を管理するには、パブリッシャーの設定でフロー制御を構成します。

失敗したパブリッシュを処理するには、必要に応じて再試行リクエスト変数を調整します。詳細については、リクエストを再試行するをご覧ください。
Document AI Document AI はリージョン サービスです。データはリージョン内の複数のゾーンに同期的に保存されます。トラフィックは、ゾーン間で自動的にロードバランスされます。ゾーンが停止しても、データは失われません。リージョンが停止した場合、Google が問題を解決するまで Document AI は使用できなくなります。

費用の最適化

このセクションでは、Google Cloud で RAG 対応の生成 AI アプリケーションを設定して運用する際の費用を最適化するためのガイダンスを示します。

プロダクト 設計上の考慮事項
Cloud Run

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

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

デフォルトでは、AlloyDB for PostgreSQL クラスタのプライマリ インスタンスは高可用性（HA）です。インスタンスにはアクティブ ノードとスタンバイ ノードがあります。アクティブ ノードに障害が発生すると、AlloyDB for PostgreSQL は自動的にスタンバイ ノードにフェイルオーバーされます。データベースに HA が必要ない場合は、クラスタのプライマリ インスタンスを基本インスタンスにすることでコストを削減できます。基本インスタンスはゾーンの停止に対して堅牢ではありません。メンテナンス オペレーション中のダウンタイムが長くなります。詳細については、基本インスタンスを使用してコストを削減するをご覧ください。

AlloyDB for PostgreSQL インスタンスの CPU とメモリの要件を予測できる場合は、確約利用の割引を受けることで費用を節約できます。詳細については、AlloyDB for PostgreSQL の確約利用割引をご覧ください。
BigQuery BigQuery では、クエリを実行する前に費用を見積もることができます。クエリ費用を最適化するには、ストレージとクエリ計算を最適化する必要があります。詳細については、費用の見積もりと管理をご覧ください。
Cloud Storage データ取り込みサブシステムへのデータの読み込みに使用する Cloud Storage バケットには、ワークロードのデータ保持とアクセス頻度の要件に基づいて適切なストレージ クラスを選択します。たとえば、Standard Storage クラスを選択してオブジェクトのライフサイクル管理を使用すると、オブジェクトを低コストのストレージ クラスに自動的にダウングレードしたり、設定した条件に基づいてオブジェクトを削除することで、ストレージ費用を制御できます。
Cloud Logging

ログの保存費用を管理するには、次の操作を行います。

  • 不要なログエントリを除外またはフィルタして、ログの量を減らします。詳細については、除外フィルタをご覧ください。
  • ログエントリの保持期間を短縮します。詳細については、カスタム保持期間を構成するをご覧ください。

パフォーマンス

このセクションでは、パフォーマンス要件を満たす RAG 対応の生成 AI アプリケーションを Google Cloud で設計して構築する際に考慮すべき要素について説明します。

プロダクト 設計上の考慮事項
Cloud Run デフォルトでは、各 Cloud Run コンテナ インスタンスに 1 つの CPU と 512 MiB のメモリが割り当てられます。Cloud Run ジョブのパフォーマンス要件に応じて、CPU の上限とメモリの上限を構成できます。
AlloyDB for PostgreSQL

データベースのクエリ パフォーマンスを分析して改善できるように、AlloyDB for PostgreSQL には Query Insights ツールが用意されています。このツールを使用すると、パフォーマンスをモニタリングして、問題のあるクエリの原因をトレースできます。詳細については、Query Insights の概要をご覧ください。

データベースのステータスとパフォーマンスの概要を取得し、ピーク時の接続数や最大レプリケーション ラグなどの詳細な指標を表示するには、システム分析情報ダッシュボードを使用します。詳細については、AlloyDB for PostgreSQL システム分析情報ダッシュボードを使用してインスタンスをモニタリングするをご覧ください。

プライマリ AlloyDB for PostgreSQL インスタンスの負荷を軽減し、読み取りリクエストを処理する容量をスケールアウトするには、クラスタに読み取りプール インスタンスを追加します。詳細については、AlloyDB for PostgreSQL のノードとインスタンスをご覧ください。
BigQuery

BigQuery では、クエリ実行グラフを使用してクエリのパフォーマンスを分析し、スロット競合やシャッフル割り当ての不足などの問題に関するパフォーマンス分析情報を取得できます。詳細については、クエリのパフォーマンス分析情報を取得するをご覧ください。

クエリのパフォーマンス分析情報で特定した問題に対処したら、入力データと出力データの量を減らすなどの手法でクエリをさらに最適化できます。詳細については、クエリ計算を最適化するをご覧ください。
Cloud Storage 大きなファイルをアップロードするには、並列複合アップロードと呼ばれる方法を使用できます。この方法では、サイズの大きいファイルがチャンクに分割されます。チャンクは Cloud Storage に並行してアップロードされ、その後、クラウドでデータが再構成されます。ネットワーク帯域幅とディスク速度が制限要因になっていない場合は、並列複合アップロードが通常のアップロード オペレーションよりも高速になる可能性があります。ただし、この方法にはいくつかの制限事項があり、費用にも影響が及びます。詳細については、並列複合アップロードをご覧ください。

次のステップ

協力者

著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー

その他の関係者: