このドキュメントでは、Google Kubernetes Engine（GKE）、Cloud SQL、および Ray、Hugging Face、LangChain などのオープンソース ツールを使用して、検索拡張生成（RAG）対応の生成 AI アプリケーションを実行するインフラストラクチャの設計に使用できるリファレンス アーキテクチャについて説明します。このリファレンス アーキテクチャを試すために、GitHub にサンプル アプリケーションと Terraform 構成が用意されています。
このドキュメントは、オープンソースのツールとモデルを使用して、RAG 対応の生成 AI アプリケーションを迅速に構築してデプロイすることを必要とするデベロッパーを対象としています。GKE と Cloud SQL の使用経験があり、AI、ML、大規模言語モデル（LLM）の概念を理解していることを前提としています。このドキュメントでは、生成 AI アプリケーションの設計と開発の方法については説明しません。
アーキテクチャ
次の図は、Google Cloud での RAG 対応の生成 AI アプリケーションのアーキテクチャの概要を示しています。
このアーキテクチャには、サービング サブシステムとエンべディング サブシステムが含まれています。
- サービング サブシステムは、アプリケーションとユーザー間のリクエスト / レスポンス フローを処理します。このサブシステムには、フロントエンド サーバー、推論サーバー、責任ある AI（RAI）サービスが含まれます。サービング サブシステムは、ベクトル データベースを介してエンベディング サブシステムと連携します。
- エンべディング サブシステムは、アーキテクチャの RAG 機能を実現します。このサブシステムは、次の処理を行います。
- Google Cloud、オンプレミス、その他のクラウド プラットフォームのデータソースからデータを取り込みます。
- 取り込まれたデータをベクトル エンベディングに変換します。
- エンベディングをベクトル データベースに保存します。
次の図は、アーキテクチャの詳細を示しています。
上の図に示すように、フロントエンド サーバー、推論サーバー、エンベディング サービスは、Autopilot モードでリージョン GKE クラスタにデプロイされます。RAG のデータは Cloud Storage バケットを介して取り込まれます。このアーキテクチャでは、エンベディングの保存とセマンティック検索を行うためのベクトル データベースとして、pgvector 拡張機能を備えた Cloud SQL for PostgreSQL インスタンスを使用します。ベクトル データベースは、高次元ベクトルを効率的に保存、取得できるように設計されています。
以下の各セクションでは、アーキテクチャの各サブシステム内のコンポーネントとデータフローについて説明します。
エンベディング サブシステム
エンベディング サブシステムでのデータのフローは次のとおりです。
- 外部ソースと内部ソースのデータは、人間のユーザーまたはプログラムによって Cloud Storage バケットにアップロードされます。アップロードされるデータは、ファイル、データベース、ストリーミング データのいずれかです
- （アーキテクチャ図には示されていません）。データ アップロード アクティビティによって、Pub/Sub などのメッセージ サービスに公開されるイベントがトリガーされます。メッセージ サービスがエンベディング サービスに通知を送信します。
- エンベディング サービスは、データ アップロード イベントの通知を受け取ると、次の処理を行います。
- Cloud Storage FUSE CSI ドライバを使用して Cloud Storage バケットからデータを取得します。
- アップロードされたデータを読み取り、Ray Data を使用して前処理します。前処理には、データをチャンク化して、エンベディング生成に適した形式に変換することが含まれます。
- Ray ジョブを実行し、同じクラスタにデプロイされている intfloat/multilingual-e5-small などのオープンソース モデルを使用して、前処理済みデータのベクトル化されたエンベディングを作成します。
- ベクトル化されたエンベディングを Cloud SQL for PostgreSQL ベクトル データベースに書き込みます。
次のセクションで説明するように、サービング サブシステムはユーザー リクエストを処理する際に、ベクトル データベース内のエンベディングを使用して、関連するドメイン固有のデータを取得します。
サービング サブシステム
サービング サブシステムのリクエスト / レスポンス フローは次のとおりです。
- ユーザーがウェブベースのチャット インターフェースから自然言語のリクエストをフロントエンド サーバーに送信します。フロントエンド サーバーは GKE で実行されます。
- フロントエンド サーバーは、次の処理を行う LangChain プロセスを実行します。
- エンベディング サービスが使用するのと同じモデルとパラメータを使用して、自然言語リクエストをエンベディングに変換します。
- ベクトル データベースでエンベディングのセマンティック検索を実行して、関連するグラウンディング データを取得します。セマンティック検索は、テキストのコンテンツではなく、プロンプトの意図に基づいてエンベディングを見つける際に活用できます。
- 元のリクエストと取得したグラウンディング データを組み合わせて、コンテキスト化されたプロンプトを作成します。
- コンテキスト化されたプロンプトを GKE で実行される推論サーバーに送信します。
- 推論サーバーは、Hugging Face TGI サービス フレームワークを使用して、Mistral-7B-Instruct や Gemma オープンモデルなどのオープンソースの LLM を提供します。
LLM がプロンプトに対するレスポンスを生成し、推論サーバーがレスポンスをフロントエンド サーバーに送信します。
Cloud Logging では、リクエスト / レスポンスのアクティビティのログを保存して表示できます。また、Cloud Monitoring を使用してログベースのモニタリングを設定できます。生成されたレスポンスを BigQuery に読み込んで、オフライン分析を行うこともできます。
フロントエンド サーバーが RAI サービスを呼び出して、必要な安全フィルタをレスポンスに適用します。Sensitive Data Protection や Cloud Natural Language API などのツールを使用して、レスポンス内の機密コンテンツの検出、フィルタ、分類、匿名化を行うことができます。
フロントエンド サーバーが、フィルタリングされたレスポンスをユーザーに送信します。
使用するプロダクト
前述のアーキテクチャで使用されている Google Cloud プロダクトとオープンソース プロダクトの概要は次のとおりです。
Google Cloud プロダクト
- Google Kubernetes Engine（GKE）: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できる Kubernetes サービス。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloud の内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
- Cloud SQL: Google Cloud 上の MySQL、PostgreSQL、SQL Server データベースのプロビジョニング、運用、管理を支援するフルマネージド リレーショナル データベース サービス。
オープンソース プロダクト
- Hugging Face Text Generation Inference（TGI）: LLM をデプロイして提供するためのツールキット。
- Ray: AI と Python のワークロードのスケーリングを支援するオープンソースの統合コンピューティング フレームワーク。
- LangChain: LLM を利用したアプリケーションの開発とデプロイを行うためのフレームワーク。
ユースケース
RAG は、LLM から生成される出力の品質を高める効果的な手法です。このセクションでは、RAG 対応の生成 AI アプリケーションを使用するユースケースの例を示します。
個人に特化したおすすめの商品情報
オンライン ショッピング サイトで、LLM を利用した chatbot を使用して、買い物客が商品を見つけたり、ショッピング関連のサポートを利用できるようにします。ユーザーからの質問を、ユーザーの購入行動やウェブサイトのインタラクション パターンに関する過去のデータに基づいて拡張します。データには、非構造化データストアに保存されているユーザー レビューやフィードバック、ウェブ分析データ ウェアハウスに保存されている検索関連の指標などがあります。拡張された質問を LLM で処理することで、より魅力的で説得力のあるパーソナライズされた回答を生成できます。
臨床支援システム
医師は、適切な治療方法や処方薬を判断するために、患者の健康状態を迅速に分析し、診断する必要があります。この臨床診断プロセスを支援するために、Med-PaLM などの医療 LLM を使用する生成 AI アプリケーションを使用できます。病院の電子医療記録（EHR）データベースや、PubMed などの外部のナレッジベースから取得したデータで医師のプロンプトをコンテキスト化することで、過去の患者記録に裏付けられたレスポンスを生成できます。
効率的な法律調査
生成 AI を活用した法的調査により、弁護士は大量の法令と判例法をすばやく照会し、関連する判例を特定したり、複雑な法的概念を要約できます。法律事務所独自の契約書コーパス、過去の法的コミュニケーション、内部の訴訟記録から取得したデータで弁護士のプロンプトを補強することで、このような調査の出力精度を高めることができます。こうした設計アプローチにより、弁護士が専門とする法的領域に関連するレスポンスを生成することが可能になります。
設計上の考慮事項
このセクションには、セキュリティとコンプライアンス、信頼性、費用、パフォーマンスに関する特定の要件を満たす、GKE でホストされる RAG 対応の生成 AI アーキテクチャを開発し実行する際に活用できるガイダンスを掲載しています。このセクションのガイダンスはすべてを網羅しているわけではありません。アプリケーション固有の要件と、使用する Google Cloud プロダクトと機能によっては、考慮すべき追加の設計要素やトレードオフが存在する場合があります。
このリファレンス アーキテクチャのオープンソース ツール（Hugging Face TGI など）に関する設計ガイダンスについては、各ツールのドキュメントをご覧ください。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、セキュリティ、プライバシー、コンプライアンスの要件を満たす RAG 対応の生成 AI アプリケーションを Google Cloud で設計して構築する際に考慮すべき要素について説明します。
| プロダクト | 設計上の考慮事項 |
|---|---|
| GKE |
Autopilot の運用モードでは、GKE がクラスタを事前構成し、セキュリティのベスト プラクティスに沿ってノードを管理するため、ユーザーはワークロード固有のセキュリティに注力できます。詳しくは以下をご覧ください。 GKE で実行されているアプリケーションのアクセス制御を強化するには、Identity-Aware Proxy（IAP）を使用します。IAP は GKE Ingress リソースと統合され、適切な Identity and Access Management（IAM）ロールを付与された認証済みユーザーのみがアプリケーションにアクセスできるようにします。詳細については、GKE での IAP の有効化をご覧ください。 デフォルトでは、GKE のデータは、Google が所有し、Google 管理の鍵を使用して保存時と転送中に暗号化されます。機密データのセキュリティをさらに強化するため、Cloud KMS で所有、管理する鍵を使用して、アプリケーション レイヤでデータを暗号化できます。詳細については、アプリケーション レイヤで Secret を暗号化するをご覧ください。 Standard GKE クラスタを使用する場合は、次の追加のデータ暗号化機能を使用できます。
|
| Cloud SQL |
アーキテクチャ内の Cloud SQL インスタンスには、公共のインターネットからアクセス可能である必要はありません。Cloud SQL インスタンスへの外部アクセスが必要な場合は、SSL / TLS または Cloud SQL Auth Proxy コネクタを使用して外部接続を暗号化できます。Auth Proxy コネクタは、IAM を使用して接続の認可を行います。このコネクタは、256 ビット AES 暗号による TLS 1.3 接続を使用して、クライアントとサーバーの ID を検証し、データ トラフィックを暗号化します。Java、Python、Go、Node.js を使用して作成した接続の場合は、Auth Proxy コネクタではなく、適切な言語コネクタを使用します。 デフォルトでは、Cloud SQL は Google が所有し管理するデータ暗号鍵（DEK）と鍵暗号鍵（KEK）を使用して保存データを暗号化します。お客様が制御、管理する KEK を使用する必要がある場合は、顧客管理の暗号鍵（CMEK）を使用できます。 Cloud SQL Admin API への不正アクセスを防止するには、VPC Service Controls を使用してサービス境界を作成します。 データ所在地の要件を満たすように Cloud SQL を構成する方法については、データ所在地の概要をご覧ください。 |
| Cloud Storage |
デフォルトでは、Cloud Storage に保存されるデータは Google が所有し、Google 管理の鍵を使用して暗号化されます。必要に応じて、CMEK を使用するか、顧客指定の暗号鍵（CSEK）などの外部の管理方法で管理する独自の鍵を使用できます。詳細については、データ暗号化オプションをご覧ください。 Cloud Storage は、バケットとオブジェクトに対するユーザーのアクセスを制御するための 2 つの方法をサポートしています。これらの方法の 1 つは IAM、もう 1 つはアクセス制御リスト（ACL）です。ほとんどの場合は IAM の使用をおすすめします。これにより、バケットレベルとプロジェクト レベルで権限を付与できます。詳細については、アクセス制御の概要をご覧ください。 Cloud Storage を介してデータ取り込みサブシステムに読み込むデータには、機密データが含まれる場合があります。このようなデータを保護するには、Sensitive Data Protection を使用してデータを検出、分類、匿名化します。詳細については、Cloud Storage での Sensitive Data Protection の使用をご覧ください。 Cloud Storage からデータが漏洩するリスクを軽減するには、VPC Service Controls を使用してサービス境界を作成します。 Cloud Storage は、データ所在地の要件を満たすために活用できます。データは、指定したリージョン内で保存または複製されます。 |
| このアーキテクチャのすべてのプロダクト |
このリファレンス アーキテクチャで使用されるすべての Google Cloud サービスで、管理アクティビティ監査ログがデフォルトで有効になっています。Cloud Logging からログにアクセスし、そのログを使用して Google Cloud リソースの構成やメタデータを変更する API 呼び出しなどのアクションをモニタリングできます。 このアーキテクチャのすべての Google Cloud サービスで、データアクセス監査ログもデフォルトで有効になっています。これらのログを使用して、以下の対象をモニタリングできます。
|
AI アプリケーションで考慮すべきセキュリティ原則に関する一般的なガイダンスについては、Google のセキュア AI フレームワークの概要をご覧ください。
信頼性
このセクションでは、Google Cloud で RAG 対応の生成 AI アプリケーション用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。
| プロダクト | 設計上の考慮事項 |
|---|---|
| GKE |
このアーキテクチャで使用される Autopilot 運用モードでは、GKE は次の組み込みの信頼性機能を備えています。
GKE クラスタの自動スケーリングで必要なときに十分な GPU 容量を使用できるようにするには、予約を作成して使用します。予約により特定のリソースに対して特定のゾーンで容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約済みリソースは、プロビジョニングや使用が行われなくても料金が発生します。詳細については、予約済みゾーンリソースの使用をご覧ください。 |
| Cloud SQL |
ベクトル データベースがデータベースの障害やゾーンの停止に対して堅牢性を有する状態を確保するには、HA 構成の Cloud SQL インスタンスを使用します。プライマリ データベースに障害が発生した場合や、ゾーンが停止した場合、Cloud SQL は別のゾーンのスタンバイ データベースに自動的にフェイルオーバーします。データベース エンドポイントの IP アドレスを変更する必要はありません。 Cloud SQL インスタンスが SLA の対象となるようにするには、推奨されるオペレーション ガイドラインに従ってください。たとえば、CPU とメモリがワークロードに適したサイズであることを確認し、ストレージの自動増量を有効にします。詳細については、オペレーション ガイドラインをご覧ください。 |
| Cloud Storage | Cloud Storage バケットは、リージョン、デュアルリージョン、マルチリージョンの 3 つのロケーション タイプのいずれかに作成できます。リージョン バケットに保存されるデータは、リージョン内の複数のゾーン間で同期をとって複製されます。高可用性を実現するには、デュアルリージョンまたはマルチリージョン バケットを使用します。この場合、データはリージョン間で非同期で複製されます。 |
費用の最適化
このセクションでは、Google Cloud で RAG 対応の生成 AI アプリケーションを設定して運用する際の費用を最適化するためのガイダンスを示します。
| プロダクト | 設計上の考慮事項 |
|---|---|
| GKE |
Autopilot モードでは、GKE はワークロードの要件に基づいてクラスタのインフラストラクチャの効率を最適化します。費用を管理するために、リソースの使用率の継続的なモニタリングや容量の管理を行う必要はありません。 GKE Autopilot クラスタの CPU、メモリ、一時ストレージの使用量を予測できる場合は、確約利用割引を受けることで費用を節約できます。詳細については、GKE の確約利用割引をご覧ください。 アプリケーションの実行費用を削減するには、GKE ノードで Spot VM を使用します。Spot VM は標準 VM よりも低価格ですが、可用性は保証されません。Spot VM を使用するノードの利点、GKE での動作、そうしたノードでのワークロードのスケジューリング方法については、Spot VM をご覧ください。 費用最適化のガイダンスについて詳しくは、コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスをご覧ください。 |
| Cloud SQL |
高可用性（HA）構成を使用すると、ゾーンまたはインスタンスが使用できなくなった場合に Cloud SQL データベースのダウンタイムを短縮できます。ただし、HA 構成インスタンスの費用はスタンドアロン インスタンスよりも高額になります。ベクトル データベースに HA が必要ない場合は、スタンドアロン インスタンスを使用すると費用を削減できますが、ゾーンの停止に対しては堅牢ではありません。 Cloud SQL インスタンスが過剰にプロビジョニングされているかどうかを検出し、Active Assist が提供する Cloud SQL の費用に関する分析情報と推奨事項を使用して課金を最適化することが可能です。詳細については、オーバープロビジョニングされた Cloud SQL インスタンスを削減するをご覧ください。 Cloud SQL インスタンスの CPU とメモリの要件を予測できる場合は、確約利用割引を受けることで費用を節約できます。詳細については、Cloud SQL の確約利用割引をご覧ください。 |
| Cloud Storage | データ取り込みサブシステムへのデータの読み込みに使用する Cloud Storage バケットには、適切なストレージ クラスを選択します。ストレージ クラスを選択する場合は、ワークロードのデータ保持とアクセス頻度の要件を考慮してください。たとえば、ストレージ費用を管理するには、Standard クラスを選択して オブジェクトのライフサイクル管理を使用します。これにより、設定した条件に基づいて、オブジェクトの低コスト ストレージ クラスへのダウングレードやオブジェクトの削除を自動的に行うことができます。 |
Google Cloud リソースの費用を見積もるには、Google Cloud の料金計算ツールを使用します。
パフォーマンスの最適化
このセクションでは、パフォーマンス要件を満たす RAG 対応の生成 AI アプリケーションを Google Cloud で設計して構築する際に考慮すべき要素について説明します。
| プロダクト | 設計上の考慮事項 |
|---|---|
| GKE |
ワークロードのパフォーマンス要件に基づいて、Pod に適したコンピューティング クラスを選択します。推論サーバーとエンベディング サービスを実行する Pod には、nvidia-l4 などの GPU マシンタイプを使用することをおすすめします。 |
| Cloud SQL |
Cloud SQL インスタンスのパフォーマンスを最適化するには、インスタンスに割り当てられている CPU とメモリがワークロードに対して十分な容量であることを確認します。詳細については、アンダープロビジョニング状態の Cloud SQL インスタンスを最適化するをご覧ください。 近似最近傍（ANN）ベクトル検索のレスポンス時間を改善するには、フラット圧縮による反転ファイル（IVFFlat）インデックスまたは階層ナビゲーション可能なスモール ワールド（HNSW）インデックスを使用します。 データベースのクエリ パフォーマンスを分析して改善できるように、Cloud SQL には Query Insights ツールが用意されています。このツールを使用すると、パフォーマンスをモニタリングして、問題のあるクエリの原因をトレースできます。詳細については、Query Insights を使用してクエリのパフォーマンスを改善するをご覧ください。 データベースのステータスとパフォーマンスの概要情報を取得し、ピーク時の接続数やディスク使用率などの詳細な指標を表示するには、システム分析情報ダッシュボードを使用します。詳細については、システム分析情報を使用してシステム パフォーマンスを向上させるをご覧ください。 |
| Cloud Storage | 大きなファイルをアップロードするには、並列複合アップロードと呼ばれる方法を使用できます。この方法では、サイズの大きいファイルがチャンクに分割されます。チャンクは Cloud Storage に並行してアップロードされ、その後、クラウドでデータが再構成されます。ネットワーク帯域幅とディスク速度が制限要因になっていない場合は、並列複合アップロードが通常のアップロード オペレーションよりも高速になる可能性があります。ただし、この方法にはいくつかの制限事項があり、費用にも影響が及びます。詳細については、並列複合アップロードをご覧ください。 |
デプロイ
このリファレンス アーキテクチャに基づくトポロジーをデプロイするには、GitHub のリポジトリで入手できるオープンソースのサンプルコードをダウンロードして使用します。サンプルコードは、本番環境でのユースケースを想定したものではありません。このコードを使用して、RAG 対応の生成 AI アプリケーションの AI インフラストラクチャの設定を試すことができます。
このサンプルコードは、次のことを行います。
- ベクトル データベースとして機能する Cloud SQL for PostgreSQL インスタンスをプロビジョニングします。
- 指定した GKE クラスタに、Ray、JupyterHub、Hugging Face TGI をデプロイします。
- ウェブベースの chatbot サンプル アプリケーションを GKE クラスタにデプロイし、RAG 機能を検証できるようにします。
サンプルコードの使用手順については、コードの README をご覧ください。サンプルコードの使用時にエラーが発生し、そのエラーに関して公開されている GitHub の問題が存在しない場合は、GitHub で問題を作成してください。
このサンプルコードでは、課金対象の Google Cloud リソースをデプロイします。コードの使用が完了したら、不要になったリソースを削除します。
次のステップ
- 以下の GKE ベスト プラクティス ガイドを確認する。
- GKE の GPU で Hugging Face TGI を使用して Gemma オープンモデルを提供する方法を学習する。
- 生成 AI レスポンスのグラウンディングに関する Google Cloud のオプションを確認する。
- Vertex AI を使用して RAG 対応の生成 AI アプリケーションのインフラストラクチャを構築する方法を学習する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー
その他の関係者:
- Anna Berenberg | エンジニアリング フェロー
- Ali Zaidi | ソリューション アーキテクト
- Bala Narasimhan | グループ プロダクト マネージャー
- Bill Bernsen | セキュリティ エンジニア
- Brandon Royal | アウトバウンド プロダクト マネージャー
- Cynthia Thomas | プロダクト マネージャー
- Geoffrey Anderson | プロダクト マネージャー
- Gleb Otochkin | Cloud アドボケイト、データベース
- Jack Wotherspoon | ソフトウェア エンジニア
- Julie Amundson | シニアスタッフ ソフトウェア エンジニア
- Kent Hua | ソリューション マネージャー
- Kavitha Rajendran | AI / ML スペシャリスト、ソリューション アーキテクト
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Megan O'Keefe | Cloud Platform 評価チーム、業界の競合状況に関する責任者
- Mofi Rahman | Google Cloud アドボケイト