このドキュメントでは、 Google Cloudで GraphRAG 生成 AI アプリケーション用のインフラストラクチャを設計する際に役立つリファレンス アーキテクチャについて説明します。このドキュメントは、インテリジェントな情報検索システムを構築して管理するアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI、グラフデータ管理、ナレッジグラフのコンセプトに関する基本的な知識があることを前提としています。このドキュメントでは、GraphRAG アプリケーションの設計と開発に関する具体的なガイダンスは提供していません。
GraphRAG は、検索拡張生成（RAG）に対するグラフベースのアプローチです。RAG は、ベクトル検索を使用して取得したコンテキストに関連するデータでプロンプトを拡張することで、AI 生成のレスポンスをグラウンディングします。GraphRAG は、ベクトル検索とナレッジグラフ クエリを組み合わせて、さまざまなソースからのデータの相互接続性をより適切に反映するコンテキスト データを取得します。GraphRAG を使用して拡張されたプロンプトは、より詳細で関連性の高い AI レスポンスを生成できます。
アーキテクチャ
次の図は、 Google Cloudでの GraphRAG 対応の生成 AI アプリケーションのアーキテクチャを示しています。
上の図のアーキテクチャは、データ取り込みとサービングの 2 つのサブシステムで構成されています。以降のセクションでは、サブシステムの目的と、サブシステム内およびサブシステム間のデータフローについて説明します。
データ取り込みサブシステム
データ取り込みサブシステムは、外部ソースからデータを取り込み、GraphRAG 用にデータを準備します。データ取り込みと準備のフローは次のステップで構成されます。
- データは Cloud Storage バケットに取り込まれます。このデータは、データ アナリストがアップロードしたり、データベースから取り込んだり、任意のソースからストリーミングしたりできます。
- データが取り込まれると、Pub/Sub トピックにメッセージが送信されます。
- Pub/Sub が、アップロードされたデータを処理する Cloud Run 関数をトリガーします。
- Cloud Run 関数は、Vertex AI の Gemini API と LangChain の
LLMGraphTransformerなどのツールを使用して、入力ファイルからナレッジグラフを構築します。 - この関数は、ナレッジグラフを Spanner Graph データベースに保存します。
- この関数は、LangChain の
RecursiveCharacterTextSplitterや Document AI のレイアウト パーサーなどのツールを使用して、データファイルのテキスト コンテンツを粒度の細かい単位に分割します。 - この関数は、Vertex AI Embeddings API を使用して、テキスト セグメントのベクトル エンベディングを作成します。
- この関数は、ベクトル エンベディングと関連するグラフノードを Spanner Graph に保存します。
ベクトル エンベディングは、セマンティック検索の基盤となります。ナレッジグラフ ノードを使用すると、複雑なデータ関係とパターンをトラバースして分析できます。
サービング サブシステム
サービング サブシステムは、生成 AI アプリケーションとユーザー間のクエリ / レスポンス ライフサイクルを管理します。サービング フローには次のステップが含まれます。
- ユーザーが Vertex AI Agent Engine にデプロイされた AI エージェントに自然言語クエリを送信します。
- エージェントは次のようにクエリを処理します。
- Vertex AI Embeddings API を使用して、クエリをベクトル エンベディングに変換します。
- エンベディング データベースでベクトル類似度検索を実行して、クエリに関連するグラフノードを取得します。
- ナレッジグラフをトラバースして、クエリに関連するデータを取得します。
- 元のクエリと取得したグラフデータを組み合わせて、プロンプトを拡張します。
- AI アプリケーション ランキング API を使用して、グラフ データベースから取得されたノードとエッジで構成される結果をランク付けします。ランキングは、クエリとの意味的な関連性に基づいて行われます。
- Gemini API Vertex AI を呼び出して結果を要約します。
- その後、エージェントは要約された結果をユーザーに送信します。
Cloud Logging では、クエリ / レスポンスのアクティビティ ログを保存して表示できます。また、Cloud Monitoring を使用してログベースのモニタリングを設定できます。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google プロダクトとツールを使用します。
- Spanner Graph: Spanner のスケーラビリティ、可用性、整合性の機能を提供するグラフ データベース。
- Vertex AI: ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する LLM をカスタマイズできる ML プラットフォーム。
- Cloud Run functions: 単一目的の関数を Google Cloudで直接実行できるサーバーレス コンピューティング プラットフォーム。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
- Pub/Sub: メッセージを処理するサービスとメッセージを生成するサービスを切り離す、非同期でスケーラブルなメッセージング サービス。
- Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
- Cloud Monitoring: アプリケーションとインフラストラクチャのパフォーマンス、可用性、動作状況を可視化するサービス。
ユースケース
GraphRAG は、さまざまな業界のユースケースでインテリジェントなデータ取得を容易にします。このセクションでは、医療、金融、法律サービス、製造業におけるユースケースをいくつか説明します。
ヘルスケア、医薬品: 臨床判断の支援
臨床意思決定支援システムでは、GraphRAG は医療文献、患者の電子医療記録、薬物相互作用データベース、臨床試験の結果から得られた膨大な量のデータを統合して、統一されたナレッジグラフを作成します。臨床医や研究者が患者の症状や現在の投薬についてクエリを実行すると、GraphRAG はナレッジグラフをトラバースして、関連する病状と薬物相互作用の可能性を特定します。また、患者の遺伝子プロファイルなどの他のデータに基づいて、パーソナライズされた治療推奨事項を生成することもできます。このタイプの情報検索では、キーワード一致よりもコンテキストが豊富で、証拠に基づいた回答が得られます。
金融サービス: 金融データの統合
金融サービス企業は、ナレッジグラフを使用して、アナリスト レポート、収益発表、リスク評価などのさまざまなソースからのデータを統合された構造化されたビューでアナリストに提供します。ナレッジグラフは、企業や役員などの重要なデータ エンティティを特定し、エンティティ間の重要な関係をマッピングします。このアプローチにより、相互接続された豊富なデータのウェブが提供され、より深く効率的な財務分析が可能になります。アナリストは、複雑なサプライ チェーンの依存関係、競合他社間で重複する取締役会のメンバーシップ、複雑な地政学的リスクへのエクスポージャーなど、これまで隠されていたインサイトを発見できます。
法律サービス: ケースの調査と判例の分析
法律分野では、GraphRAG を使用して、前例、法令、判例法、規制の更新、内部文書に基づいて、パーソナライズされた法的推奨事項を生成できます。弁護士は訴訟の準備をする際に、特定の法的論点、類似の訴訟に関する過去の判決、新しい法律の影響について、ニュアンスのある質問をすることができます。GraphRAG は、利用可能な法的知識の相互接続性を活用して、関連する判例を特定し、その適用可能性を説明します。また、法的概念、法令、司法解釈の関係を追跡することで、反論を提案することもできます。このアプローチにより、法律実務家は従来の知識検索方法よりも徹底的かつ正確な分析情報を得ることができます。
製造とサプライ チェーン: 組織の知識を解き放つ
製造とサプライ チェーンのオペレーションには、高い精度が求められます。必要なレベルの精度を維持するために必要な知識は、多くの場合、何千もの密度の高い静的な標準作業手順書（SOP）に埋もれています。工場の生産ラインや機械が故障した場合や、物流上の問題が発生した場合、エンジニアや技術者は、問題の診断とトラブルシューティングを行うために、関連性のない PDF ドキュメントを検索して重要な時間を無駄にすることがよくあります。ナレッジグラフと会話型 AI を組み合わせることで、埋もれた組織の知識をインタラクティブな診断パートナーに変えることができます。
代替案を設計する
このドキュメントで説明するアーキテクチャはモジュール式です。要件に応じて、アーキテクチャの特定のコンポーネントを調整して、代替のプロダクト、ツール、テクノロジーを使用できます。
ナレッジグラフの構築
LangChain の LLMGraphTransformer ツールを使用すると、ナレッジグラフをゼロから構築できます。allowed_nodes、allowed_relationships、node_properties、relationship_properties などの LLMGraphTransformer パラメータを使用してグラフ スキーマを指定すると、結果のナレッジグラフの品質を向上させることができます。ただし、LLMGraphTransformer は一般的なドメインからエンティティを抽出する可能性があるため、医療や製薬などのニッチなドメインには適していない可能性があります。また、組織にナレッジグラフを構築するための堅牢なプロセスがすでに存在する場合は、このリファレンス アーキテクチャに示されているデータ取り込みサブシステムは省略可能です。
ナレッジグラフとベクトル エンベディングの保存
このドキュメントのアーキテクチャでは、ナレッジグラフとベクトル エンベディングのデータストアとして Spanner を使用します。エンタープライズ ナレッジグラフがすでに別の場所（Neo4j などのプラットフォーム）に存在する場合は、エンベディングにベクトル データベースの使用を検討してください。ただし、このアプローチでは管理の労力が追加で必要になり、費用も高くなる可能性があります。Spanner は、グラフ構造とベクトル エンベディングの両方に対して、統合されたグローバルに整合性のあるデータストアを提供します。このようなデータストアにより、統合データ管理が可能になり、コスト、パフォーマンス、セキュリティ ガバナンス、運用効率の最適化に役立ちます。
エージェントのランタイム
このリファレンス アーキテクチャでは、エージェントは Vertex AI Agent Engine にデプロイされます。Vertex AI Agent Engine は、AI エージェント用のマネージド ランタイムを提供します。検討できるその他のオプションには、Cloud Run と Google Kubernetes Engine（GKE）があります。これらのオプションについては、このドキュメントでは扱いません。
RAG を使用したグラウンディング
ユースケース セクションで説明したように、GraphRAG を使用すると、多くのシナリオでグラウンディングのためのインテリジェントなデータ取得が可能になります。ただし、プロンプトの拡張に使用するソースデータに複雑な相互関係がない場合は、RAG が生成 AI アプリケーションに適している可能性があります。
次のリファレンス アーキテクチャは、ベクトル対応のマネージド データベースまたは専用のベクトル検索プロダクトを使用して、 Google Cloud で RAG に必要なインフラストラクチャを構築する方法を示しています。
- Vertex AI とベクトル検索を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ
- Vertex AI と AlloyDB for PostgreSQL を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ
- GKE と Cloud SQL を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、推奨事項について説明します。
このセクションのガイダンスはすべてを網羅しているわけではありません。ワークロードの要件と、使用する Google Cloud およびサードパーティのプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、ワークロードのセキュリティとコンプライアンスの要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| プロダクト | 設計上の考慮事項と推奨事項 |
|---|---|
| Vertex AI | Vertex AI は、データ所在地、データ暗号化、ネットワーク セキュリティ、アクセスの透明性の要件を満たすために使用できる Google Cloud セキュリティ管理をサポートしています。詳細については、以下のドキュメントをご覧ください。 生成 AI モデルは、特にそのような回答を明示的に求められた場合、有害な回答を生成する可能性があります。安全性を強化し、不正使用の可能性を軽減するには、有害なレスポンスに対するバリアとして機能するようにコンテンツ フィルタを構成します。詳細については、安全性フィルタとコンテンツ フィルタをご覧ください。 |
| Spanner Graph | デフォルトでは、Spanner Graph に保存されるデータは Google-owned and Google-managed encryption keysを使用して暗号化されます。お客様が制御、管理する暗号鍵を使用する必要がある場合は、顧客管理の暗号鍵（CMEK）を使用できます。詳細については、CMEK についてをご覧ください。 |
| Cloud Run functions | デフォルトでは、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 つのシステムをサポートしています。1 つは Identity and Access Management（IAM）、もう 1 つはアクセス制御リスト（ACL）です。ほとんどの場合は IAM の使用をおすすめします。これにより、バケットレベルとプロジェクト レベルで権限を付与できます。詳細については、アクセス制御の概要をご覧ください。 Cloud Storage を介してデータ取り込みサブシステムに読み込むデータには、機密データが含まれる場合があります。Sensitive Data Protection を使用して、機密データの検出、分類、匿名化を行うことができます。詳細については、Cloud Storage での Sensitive Data Protection の使用をご覧ください。 Cloud Storage は、データ所在地の要件を満たすために活用できます。データは、指定したリージョン内で保存または複製されます。 |
| Pub/Sub | Pub/Sub はデフォルトで Google-owned and Google-managed encryption keysを使用して、保存時と転送時の両方ですべてのメッセージを暗号化します。Pub/Sub は、アプリケーション レイヤでのメッセージ暗号化に CMEK の使用をサポートしています。詳細については、メッセージ暗号化を構成するをご覧ください。 データ所在地の要件がある場合、メッセージ データが特定のロケーションに保存されるように、メッセージ ストレージ ポリシーを構成できます。 |
| Cloud Logging | このリファレンス アーキテクチャで使用されるすべての Google Cloud サービスで、管理アクティビティ監査ログがデフォルトで有効になっています。これらのログには、Google Cloud リソースの構成やメタデータを変更する API 呼び出しなどのアクションが記録されます。 このアーキテクチャで使用される Google Cloud サービスでは、データアクセス監査ログを有効にできます。これらのログでは、リソースの構成やメタデータを読み取る API 呼び出しや、ユーザー提供のリソースデータの作成、変更、読み取りを行うユーザー リクエストを追跡できます。 データ所在地の要件を満たすために、指定したリージョンにログデータを保存するように Cloud Logging を構成できます。詳細については、ログをリージョン化するをご覧ください。 |
AI ワークロードと ML ワークロードに固有のセキュリティの原則と推奨事項については、 Google Cloud Well-Architected Framework の AI と ML の視点: セキュリティをご覧ください。
信頼性
このセクションでは、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。
| プロダクト | 設計上の考慮事項と推奨事項 |
|---|---|
| Vertex AI | Vertex AI は、Gemini モデルの動的共有割り当て（DSQ）をサポートしています。DSQ は、従量課金制のリクエストを柔軟に管理し、割り当てを手動で管理したり、割り当ての増加をリクエストしたりする必要をなくします。DSQ は、特定のモデルとリージョンで使用可能なリソースをアクティブな顧客に動的に割り当てます。DSQ では、個々の顧客に事前定義された割り当て上限はありません。 リクエスト数が割り当てられた容量を超えると、エラーコード 429 が返されます。ビジネス クリティカルで常に高いスループットが求められるワークロードの場合は、プロビジョニングされたスループットを使用してスループットを予約できます。複数のリージョンまたは国でデータを共有できる場合は、グローバル エンドポイントを使用できます。 |
| Spanner Graph | Spanner は、高いデータ可用性とグローバルなスケーラビリティを実現するように設計されています。リージョン停止時でも可用性を確保するために、Spanner にはマルチリージョン構成が用意されています。この構成では、複数のリージョンにまたがる複数のゾーンにデータが複製されます。Spanner には、これらの組み込みの復元機能に加えて、包括的な障害復旧戦略をサポートする次の機能が用意されています。
詳細については、障害復旧の概要をご覧ください。 |
| Cloud Run functions | Cloud Run はリージョン サービスです。データはリージョン内の複数のゾーンに同期的に保存されます。トラフィックは、ゾーン間で自動的にロードバランスされます。ゾーンが停止しても、Cloud Run は引き続き実行され、データは失われません。リージョンが停止した場合、Google が問題を解決するまでサービスは実行を停止します。 |
| Cloud Storage | Cloud Storage バケットは、リージョン、デュアルリージョン、マルチリージョンの 3 つのロケーション タイプのいずれかに作成できます。リージョン バケットに保存されるデータは、リージョン内の複数のゾーン間で同期をとって複製されます。高可用性を実現するには、デュアルリージョンまたはマルチリージョン バケットを使用します。この場合、データはリージョン間で非同期で複製されます。 |
| Pub/Sub | メッセージ トラフィックの一時的な急増中にエラーが発生しないようにするには、パブリッシャーの設定でフロー制御を構成して、パブリッシュ リクエストのレートを制限します。 失敗したパブリッシュの試行を処理するには、必要に応じて再試行リクエスト変数を調整します。詳細については、リクエストを再試行するをご覧ください。 |
| アーキテクチャのすべてのプロダクト | Google Cloudにワークロードをデプロイしたら、Active Assist を使用して、クラウド リソースの信頼性をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 |
AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。
費用の最適化
このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。
| プロダクト | 設計上の考慮事項と推奨事項 |
|---|---|
| Vertex AI | Vertex AI の費用を分析して管理するには、秒間クエリ数（QPS）と秒間トークン数（TPS）のベースラインを作成し、デプロイ後にこれらの指標をモニタリングすることをおすすめします。ベースラインは、容量計画にも役立ちます。たとえば、ベースラインは、プロビジョンド スループットが必要なタイミングを判断するのに役立ちます。 生成 AI アプリケーションに適切なモデル を選択することは、費用とパフォーマンスの両方に直接影響する重要な決定です。特定のユースケースでパフォーマンスと費用の最適なバランスを実現するモデルを特定するには、モデルを繰り返しテストします。最も費用対効果の高いモデルから始めて、より強力なオプションに徐々に移行することをおすすめします。 プロンプト（入力）の長さと生成されたレスポンス（出力）の長さは、パフォーマンスと費用に直接影響します。短く、直接的で、十分なコンテキストを提供するプロンプトを作成します。モデルから簡潔なレスポンスを取得するようにプロンプトを設計します。たとえば、「2 文で要約して」や「3 つの要点をリストアップして」などのフレーズを含めます。詳細については、プロンプト設計のベスト プラクティスをご覧ください。 入力トークン数が多い繰り返しコンテンツを含むリクエストの費用を削減するには、コンテキスト キャッシュ保存を使用します。 関連する場合は、バッチ予測を検討してください。バッチ リクエストは、標準リクエストよりも低価格で課金されます。 |
| Spanner Graph | マネージド オートスケーラーを使用して、CPU 使用率とストレージのニーズに基づいて Spanner Graph データベースのコンピューティング容量を動的に調整します。小規模なワークロードでも、最小容量が必要になることがよくあります。 予測可能で安定したベースラインのコンピューティング容量には、確約利用割引（CUD）を購入します。CUD では、コンピューティング容量の 1 時間あたりの費用を確約することを条件に、大幅な割引が適用されます。 障害復旧またはコンプライアンスのためにバックアップを別のリージョンにコピーする場合は、ネットワークの下り（外向き）料金を考慮してください。費用を削減するには、必要なバックアップのみをコピーします。 |
| Cloud Run functions | Cloud Run functions を作成するときに、割り当てるメモリと CPU の量を指定できます。費用を抑えるには、デフォルトの（最小）CPU とメモリの割り当てから始めます。パフォーマンスを向上させるには、CPU の上限とメモリ上限を構成して割り当てを増やします。詳細については、以下のドキュメントをご覧ください。 CPU とメモリの要件を予測できる場合は、CUD を使用して費用を節約できます。 |
| Cloud Storage | データ取り込みサブシステムの Cloud Storage バケットには、ワークロードのデータ保持とアクセス頻度の要件に基づいて適切なストレージ クラスを選択します。たとえば、ストレージ費用を管理するには、Standard クラスを選択して オブジェクトのライフサイクル管理を使用します。このアプローチにより、指定した条件に基づいて、オブジェクトの低コスト ストレージ クラスへのダウングレードやオブジェクトの削除を自動的に行うことができます。 |
| Cloud Logging | ログの保存費用を管理するには、次の操作を行います。
|
| アーキテクチャのすべてのプロダクト | Google Cloudにワークロードをデプロイしたら、Active Assist を使用して、クラウド リソースの費用をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 |
Google Cloud リソースの費用を見積もるには、Google Cloud の料金計算ツールを使用します。
AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。
パフォーマンスの最適化
このセクションでは、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| プロダクト | 設計上の考慮事項と推奨事項 |
|---|---|
| Vertex AI |
生成 AI アプリケーションに適切なモデル を選択することは、費用とパフォーマンスの両方に直接影響する重要な決定です。特定のユースケースでパフォーマンスと費用の最適なバランスを実現するモデルを特定するには、モデルを繰り返しテストします。最も費用対効果の高いモデルから始めて、より強力なオプションに徐々に移行することをおすすめします。 プロンプト（入力）の長さと生成されたレスポンス（出力）の長さは、パフォーマンスと費用に直接影響します。短く、直接的で、十分なコンテキストを提供するプロンプトを作成します。モデルから簡潔なレスポンスを取得するようにプロンプトを設計します。たとえば、「2 文で要約して」や「3 つの要点をリストアップして」などのフレーズを含めます。詳細については、プロンプト設計のベスト プラクティスをご覧ください。 Vertex AI プロンプト オプティマイザーを使用すると、プロンプトのパフォーマンスを大規模に迅速に改善して最適化できるため、手動で書き換える必要がなくなります。オプティマイザーを使用すると、さまざまなモデルでプロンプトを効率的に調整できます。 |
| Spanner Graph | Spanner Graph のパフォーマンスを最適化するための推奨事項については、次のドキュメントをご覧ください。 |
| Cloud Run functions | デフォルトでは、各 Cloud Run 関数インスタンスに 1 つの CPU と 256 MiB のメモリが割り当てられます。パフォーマンス要件に応じて、CPU とメモリの上限を構成できます。詳細については、以下のドキュメントをご覧ください。 パフォーマンスの最適化に関するガイダンスについては、Cloud Run の一般的な開発のヒントをご覧ください。 |
| Cloud Storage | 大きなファイルをアップロードするには、並列複合アップロードを使用できます。この方法では、サイズの大きいファイルがチャンクに分割されます。チャンクは Cloud Storage に並行してアップロードされ、その後、クラウドでデータが再構成されます。ネットワーク帯域幅とディスク速度が制限要因になっていない場合は、並列複合アップロードが通常のアップロード オペレーションよりも高速になる可能性があります。ただし、この方法にはいくつかの制限事項があり、費用にも影響が及びます。詳細については、並列複合アップロードをご覧ください。 |
| アーキテクチャのすべてのプロダクト | Google Cloudにワークロードをデプロイしたら、Active Assist を使用して、クラウド リソースのパフォーマンスをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 |
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。
デプロイ
Google Cloudで GraphRAG がどのように機能するかを確認するには、GitHub から次の Jupyter ノートブック（GraphRAG on Google Cloud With Spanner Graph and Vertex AI Agent Engine）をダウンロードして実行します。
次のステップ
- Spanner Graph と LangChain を使用して GraphRAG アプリケーションを構築する。
- 生成 AI アプリケーションのモデルとインフラストラクチャを選択する。
- RAG 対応生成 AI アプリケーションのインフラストラクチャを設計する:
- Google Cloudの AI ワークロードのアーキテクチャ原則と推奨事項については、Well-Architected Framework: AI と ML の視点をご覧ください。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Tristan Li | プリンシパル アーキテクト、AI/ML
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
その他の寄稿者:
- Ahsif Sheikh | AI カスタマー エンジニア
- Ashish Chauhan | AI カスタマー エンジニア
- Greg Brosman | プロダクト マネージャー
- Cloud AI、プロダクト マネージャー | Lukas Bruderer
- Nanditha Embar | AI カスタマー エンジニア
- Piyush Mathur | プロダクト マネージャー、Spanner
- Smitha Venkat | AI カスタマー エンジニア