Amazon Web Services ブログ

エンタープライズ向けのマルチテナント型の生成 AI 環境を AWS で構築する

本記事は、2024年11月7日に公開された Build a multi-tenant generative AI environment for your enterprise on AWS を翻訳したものです。


企業が生成 AI の有用なアプリケーションを開発し続けている一方で、チームのサイロ化やワークフローのカスタム化によって展開が遅れることも少なくありません。より迅速に展開するには、企業はしっかりとした運用形態や生成 AI のライフサイクルをシンプルにする包括的なアプローチを必要とします。本シリーズの第1部では、さまざまな事業部門が Amazon Bedrock 上の基盤モデルにアクセスできるように、AI の管理者が生成 AI の SaaS (Software as a Service) のゲートウェイを構築する方法を紹介しました。第2部となる今回は、ソリューションを拡張し、共通の生成 AI のコンポーネントを集約することでイノベーションを加速する方法を紹介します。また、アクセスパターン、ガバナンス、責任ある AI、オブザーバビリティ、Retrieval Augmented Generation (RAG) のような一般的なソリューションの構成についても掘り下げていきます。

このソリューションは、Amazon Bedrock というマネージドサービスを使用し、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった主要な AI 企業が提供する高性能な基盤モデルを、単一の API から選択することができます。また、セキュリティ、プライバシー、責任あるAIを重視した生成 AI のアプリケーションを構築するための幅広い機能も備えています。そして、Amazon API GatewayAWS LambdaAmazon SageMaker など、多数の AWS サービスも使用しています。

マルチテナント型の生成 AI 環境を AWS で構築

企業が求めるマルチテナント型の生成 AI ソリューションでは、企業ポリシーの遵守、テナントおよびデータの分離、アクセスやコストの管理といったことを担保しながら、生成 AI ワークロードの固有の要件や責任ある AI といったガバナンスに対応していく必要があります。そのため、このようなソリューションの構築は、IT チームにとって負担の大きい取組となることが往々にしてあります。

本記事では、主な設計上の考慮事項について説明し、リファレンスアーキテクチャを紹介します。

  • 素早い試行、統一されたモデルへのアクセス、共通の生成 AI コンポーネントの再利用を可能にすることで、生成 AI の展開を加速します。
  • テナント毎にユースケースに応じた適切な設計や実装を柔軟に選択できるようにします。
  • 一元化されたガバナンス、ガードレール、そして制御を実装します。
  • テナント、事業部門、または基盤モデルのプロバイダー毎にモデルの利用やコストの追跡や監査ができるようにします。

ソリューションの概要

ソリューションは2つの部分から構成されています。

  • 生成 AI ゲートウェイ(下図の左側)
  • 事業部門毎等のテナント(下図の右側)

次の図はソリューションの概要を示しています。

生成 AI ゲートウェイ

共有コンポーネントは、生成 AI ゲートウェイの領域に配置されます。共有コンポーネントとは、すべてのテナントで共有される機能のことです。上図の各コンポーネントは、マイクロサービスとして実装され、基本はマルチテナントで、テナント毎の詳細情報は一意のテナント ID で保持されます。一部のコンポーネントは、その機能の種類に基づいてグループに分類されます。

独立したコンポーネントは以下の通りです。

  • HTTPS エンドポイント (HTTPS endpoint) はゲートウェイへのエントリーポイントです。この HTTPS エンドポイントを介して共有サービスとのやりとりが行われます。ソリューションにおける唯一のエントリーポイントとなります。
  • オーケストレーター (Orchestrator) は、HTTPS エンドポイントからのリクエストを受け、実行中のタスクに基づいて対応するマイクロサービスを呼び出す役割を担います。これ自体がマイクロサービスであり、マイクロサービスにおける Saga オーケストレーションパターンに由来したものです。
  • 生成 AI プレイグラウンド (Generative AI Playgroud) は、一時的な試行、複数の基盤モデルとのチャット、ガードレールやモデル評価のような機能の探索的な検証のために、テナントに提供されるUIです。

コンポーネントグループは以下の通りです。

  • コアサービス (Core services) は環境の管理者を主に対象にしたものです。環境の導入、管理、運用に使用されるサービスが含まれています。例えば、テナント、ユーザー、モデルのオンボードとオフボード、各テナントへのクォータの割当、そして認証や認可のマイクロサービスなどです。また、コストや予算の管理、監査、ログ記録などのための監視のコンポーネントも含まれます。
  • 生成 AI モデルコンポーネント (Generative AI model components) には、基礎モデルやカスタムモデルの実行操作のマイクロサービスが含まれます。これらのマイクロサービスは、Amazon Bedrock、Amazon SageMaker、またはサードパーティのモデルプロバイダーを通じて提供される基盤モデルとのやりとりを汎用化します。
  • 生成 AI コンポーネント (Generative AI components) は、生成 AI アプリケーションの構築に必要な機能を提供します。プロンプトのキャッシュ、プロンプトチェーン、エージェント、またはハイブリッド検索などの機能は、これらのマイクロサービスに含まれます。
  • 責任ある AI コンポーネント (Responsible AI components) は、テナント全体にわたって AI の安全かつ責任ある開発を可能にします。ガードレール、レッドチーミング、モデル評価などの機能が含まれます。

テナント

ここでは AI ゲートウェイの機能を使用するテナントについて述べます。各テナントには異なる要件やニーズがあり、そして独自のアプリケーションスタックがあります。生成 AI ゲートウェイにアプリケーションを連携することで、生成 AI 機能をアプリケーションに実装することができます。環境の管理者は生成 AI ゲートウェイにアクセスして、コアサービスと連携します。

ソリューションの概要

このセクションでは、ソリューションの各部についてより詳しく説明します。

HTTPS エンドポイント

これは生成 AI ゲートウェイのエントリーポイントとして機能します。ゲートウェイへの要求は、このポイントを通過します。エンドポイントを設計する際には、さまざまなアプローチがあります。

  • REST API エンドポイント – すべての認証、認可、そしてスロットリングの処理のために API Gatewayなどのサービスを使用して、REST API エンドポイントを設定します。API Gateway はサーバーレスであるため、トラフィックに応じて自動的にスケールします。
  • WebSocket – 長時間の接続には、REST インターフェースの代わりに WebSocket を使用します。この方法により、同期的な REST リクエストのタイムアウト制限が解消されます。WebSocket の採用により、複数回または長時間のやりとりでも接続が維持されます。API Gateway は、WebSocket APIも提供しています。
  • ロードバランサー – もう一つの選択肢は、HTTPS エンドポイントを公開し、リクエストをオーケストレーターにルーティングするロードバランサーを使用することです。このアプローチを実装するには、Application Load Balancer などの AWS サービスを使用できます。Application Load Balancer を使用する利点は、実質的にあらゆるマネージド型、サーバーレス型、またはセルフホスト型のコンポーネントにシームレスにリクエストをルーティングでき、スケールも容易なことです。

テナントとアクセスパターン

事業部門やチームなどのテナントは、共有サービスを利用して API にアクセスし、生成 AI の機能をアプリケーションに導入します。また、本格的なアプリケーションの開発に着手する前に、特定のユースケースに対する生成 AI の適合性を評価するために、プレイグラウンドを適宜使用することもできます。 また、データソース、処理のパイプライン、ベクトルストア、データガバナンスといった機能により、テナントはそれぞれのユースケースで必要となるデータを安全に識別してアクセスすることができます。この段階ではユースケースとデータの分離要件について考慮する必要があります。個人識別情報 (PII) を含むデータへのアクセスが必要になるアプリケーションもある一方、クリティカルでないデータだけを必要とするアプリケーションもあるでしょう。また、運用上の特性やノイジーネイバーのリスクについても考慮する必要があります。

RAG (Retrieval Augmented Generation) を例に取ります。ユースケースやデータの分離要件に応じて、テナントは共有型もしくは個別型のナレッジベースを構築し、データに対してアイテムレベルもしくはリソースレベルでの分離を実装できます。テナントは、アクセス可能なデータソースからデータを選択します。そしてアプリケーションに適したチャンキング手法を選択し、共有されている生成 AI の基盤モデルをデータのエンベッディングに使用して、ベクトルストアにエンベッディングを保存できます。 ユーザーの質問にリアルタイムで回答するために、テナントはキャッシュ機能を実装して、頻繁なクエリに対する待ち時間とコストを削減することができます。さらに、カスタムロジックを実装して、以前のセッション、インタラクションの状態、エンドユーザー固有の情報を取得することもできます。最終的な応答を生成するために、ゲートウェイを通じて、利用可能なモデルやリランキングの機能にアクセスすることができます。

次の図は、このアプローチでのチャットベースのエージェントアプリケーションの実装例を示しています。テナントのアプリケーションは、生成 AI ゲートウェイ経由で、利用可能な基盤モデルや独自のベクトルストアを使用し、エンドユーザーにパーソナライズされた関連性の高いレスポンスを提示します。

共有サービス

このセクションでは、共有サービスグループについて説明します。

モデルコンポーネント

このコンポーネントグループの役割は、テナントがホストされている場所に関係なく、基盤モデルにアクセスするための統一された API をテナントに提供することです。呼び出しの仕様を汎用化し、アプリケーション開発を加速します。基盤モデルのプロバイダー数や、使用するカスタムモデルの数や種類に応じて、1つまたは複数のコンポーネントで構成されます。以下の図に示します。

テナントが基盤モデルを利用する方法について、AWSではいくつかの選択肢があります。

  • Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazonといった AI 企業が提供する基盤モデルを、単一の API を通じて選択できるフルマネージドなサービスです。サーバーレスなので、インフラストラクチャを管理する必要はありません。また、カスタマイズしたモデルを Amazon Bedrock に持ち込み、サポートされているモデルアーキテクチャに対応するものとしてデプロイすることもできます。
  • SageMaker JumpStart は、AI21 Labs、Cohere、Hugging Face、Meta、Stability AI などのプロバイダーが提供する、公開されている独自仕様の幅広い基盤モデルを提供する機械学習 (ML) のハブです。これらの基盤モデルは、お客さまの AWS アカウントの SageMaker エンドポイントにデプロイできます。
  • SageMaker では、SageMaker のエンドポイントでの推論が可能で、HuggingFace などの公開モデルや独自モデルをデプロイできます。
  • また、Amazon Elastic Kubernetes Service (Amazon EKS) などのコンテナサービスや、セルフマネージドのアプローチで、モデルをAWSのコンピューティングにデプロイすることもできます。

AWS PrivateLink を使用すると、仮想プライベートクラウド (VPC) と Amazon Bedrock および SageMakerのエンドポイント間のプライベート接続を確立できます。

生成 AI アプリケーションコンポーネント

このグループには、生成 AI アプリケーションの固有要件に関連するコンポーネントが含まれています。以下の図に示します。

  • プロンプトカタログ (Prompt catalog) – 効果的なプロンプトを作成することは、大規模言語モデル (LLM) に適切な出力を生成させる上で重要です。プロンプトエンジニアリングは通常反復的なプロセスであり、チームは目標とする結果が得られるまで、さまざまなテクニックやプロンプトの構文を試行します。プロンプトの保存、バージョン管理、追跡、共有のためには、プロンプトカタログを一元管理することが不可欠です。また、本番の手前の環境で評価プロセスを自動化することもできます。新しいプロンプトがカタログに追加されると、評価のパイプラインが起動します。パフォーマンスが向上した場合は、アプリケーションの既存のデフォルトプロンプトは新しいプロンプトに置換されます。Amazon Bedrock を使用すると、Amazon Bedrock Prompt Management で独自のプロンプトを作成して保存できるため、同じプロンプトを異なるワークフローに適用することができ、時間を節約できます。また、サーバーレスのフルマネージド型の NoSQL データベースである Amazon DynamoDB を使用してプロンプトを保存することもできます。
  • プロンプトチェーン (Prompt chaining) – 生成 AI の開発者は、LLM に送信する前に複雑なタスクをサブタスクに分割するために、プロンプトチェーンのテクニックをよく使用します。 共通的なプロンプトチェーンのアーキテクチャの API をテナントに公開する集約型のサービスを利用すると、開発を加速できます。 AWS Step Functions を使用してチェーンのワークフローを構成し、タスクの完了イベントを Amazon EventBridge を使用して監視し、次ステップのトリガーとすることができます。 詳細は、「AI プロンプトチェーンを Amazon Bedrock で実行する」を参照してください。
  • エージェント (Agent) – テナントは複雑なタスクを処理するために自律型エージェントを採用することもあります。 このようなエージェントは、モデル、データソース、API、およびアプリケーション間のやりとりを統合します。 エージェントコンポーネントにより、エージェントの作成、管理、アクセス、および共有が可能になります。 AWSでは、フルマネジードの Amazon Bedrock Agents や、LangChain や LlamaIndex のエージェントなどの任意のツールを使用できます。
  • リランク (Re-ranker) – RAGの設計では、企業内のデータ検索で複数の候補が返されることがよくあります。Cohere の Rerank 2 モデルなどのリランク機能は、事前に定義された基準に基づいて最適な候補を判別するのに役立ちます。テナントが Amazon OpenSearch ServiceAmazon Kendraなどのマネージドサービスの機能を使用することを選択する場合は、このコンポーネントは必要ありません。
  • ハイブリッド検索 (Hybrid search) – RAGでは、必要に応じて、抽出されるドキュメントの品質を向上すべくハイブリッド検索を実行するために、複数のテンプレートを実装したり公開することもできます。このロジックは、ハイブリッド検索コンポーネントに組み込まれます。Amazon OpenSearch Service などのマネージドサービスを使用する場合は、このコンポーネントは必要ありません。

責任ある AI コンポーネント

このグループには、以下の図に示す責任ある AIの主要コンポーネントが含まれます。

  • ガードレール (Guardrails) – ガードレールは、基盤モデルに組み込まれた保護に加えて、安全対策を実施するのに役立ちます。組織のユーザーに対して汎用的なデフォルトとして適用することも、各ユースケースに特化して適用することもできます。 Amazon Bedrock Guardrails を使用すると、アプリケーションの要件と責任ある AI のポリシーに基づいて、このような保護策を実装することができます。Amazon Bedrock Guardrails により、望ましくないトピックをブロックしたり、有害なコンテンツをフィルタリングしたり、PII やカスタム正規表現などの機密情報を削除またはブロックしてプライバシーを保護することができます。さらに、コンテクストに基づくグラウンドチェックにより、参照ソースとユーザークエリに基づいて、モデルのレスポンスにおけるハルシネーションを検出することができます。ApplyGuardrail API は、Amazon Bedrock 上 の基盤モデル、カスタムの基盤モデル、サードパーティの基盤モデルに対する入力プロンプトとモデルのレスポンスを評価することができ、生成 AI アプリケーションの全体に渡る統合的なガバナンスを実現します。
  • レッドチーミング (Red teaming) – レッドチーミングは、ユーザー経験の低下や悪意ある行為につながりうるモデルの制約を特定するのに役立ちます。LLM は、バックドア攻撃、ポイズニング攻撃、プロンプトインジェクション、ジェイルブレイク、PII 漏洩攻撃、メンバーシップ推論攻撃、勾配漏洩攻撃などのセキュリティおよびプライバシー攻撃に対して脆弱性を持つ可能性があります。テスト用のアプリケーションや自社の従業員で構成するレッドチームを立ち上げることや、既知の脆弱性に対して自動化したりするといった対応ができます。例えば、既知のジェイルブレイクのデータセットを用いてアプリケーションをテストするといったことです。 テスト結果を用いて、Amazon Bedrock Guardrails を調整し、望ましくないトピックをブロックしたり、有害なコンテンツをフィルタリングしたり、機密情報を削除またはブロックしたりすることができます。
  • ヒューマン・イン・ザ・ループ (Human in the loop) – ヒューマン・イン・ザ・ループのアプローチは、モデルの精度や関連性を向上させるために、ML のライフサイクル全体を通じて人間のインプットを収集するプロセスです。人間は、データの作成や注釈付けから、モデルのレビュー、カスタマイズ、評価まで、さまざまなタスクを行えます。SageMaker Ground Truth では、セルフサービスと AWS マネージドサービスが用意されています。セルフサービスでは、データの注釈付の担当者、コンテンツの作成者、そしてプロンプトエンジニア(社内人材、ベンダー人材、またはパブリック人材)が、ローコードの UI を用いてヒューマン・イン・ザ・ループのタスクを迅速化できます。AWS マネージドサービス (SageMaker Ground Truth Plus) は、エンドツーエンドのワークフローのデザインやカスタマイズをし、特定のタスクのトレーニングを受けた専門知識のある AWS マネージドチームを提供し、お客さまのデータ品質、セキュリティ、およびコンプライアンスに関する要件を満たします。Amazon Bedrock のモデル評価を用いて、人間の作業者が複数のモデルからのレスポンスをGround Truthのレスポンスと比較して評価するといった、基盤モデルの評価のジョブを設定できます。評価方法として、サムズアップまたはサムズダウン、5段階評価、2択ボタン、順序付けなどを設定できます。
  • モデルの評価 (Model evaluation) – モデルの評価では、モデルの出力を比較し、下流の生成 AI アプリケーションに最適なモデルを選択できます。自動的な評価、ヒューマン・イン・ザ・ループでの評価、またはその両方を使用できます。Amazon Bedrock でのモデルの評価は、自動的な評価のジョブとヒューマン・イン・ザ・ループでの評価のジョブを設定できます。既存のデータセットを選択するか、独自のカスタムプロンプトのデータセットを投入できます。Amazon SageMaker Clarify を使用すると、Amazon SageMaker JumpStart評価用基盤モデルを評価できます。 テキスト生成、要約、分類、質問応答など、さまざまなタスクに対して、プロンプトのステレオタイプ化、毒性、事実に関する知識、セマンティック堅牢性、正確性など、さまざまな側面からのモデルの評価を設定することができます。そして独自の評価パイプラインを構築したり、fmeval などのツールを使用することができます。
  • モデルの監視 (Model monitoring) – モデルの監視サービスでは、テナントが事前に定義したメトリクスに対するモデルのパフォーマンスを評価できます。モデル監視ソリューションは、リクエストとレスポンスのデータを収集し、評価ジョブを実行し、事前に設定のベースラインに対するパフォーマンスメトリクスを計算し、その結果を保存し、問題が発生した場合はアラートを送信します。

Amazon Bedrock を使用している場合は、モデル呼び出しのログを有効にして入力と出力のデータを収集し、Amazon Bedrock 評価を使用してモデル評価ジョブを実行できます。あるいは AWS Lambda を使用して独自のロジックを実装したり、fmeval などのオープンソースツールを使用することもできます。SageMaker では、SageMaker のリアルタイムエンドポイントでデータキャプチャを有効にして、SageMaker Clarify を使用してモデルの評価ジョブを実行したり、独自の評価ロジックを実装することができます。Amazon Bedrock と SageMaker はどちらも SageMaker Ground Truthと統合されており、グランドトゥルースのデータ(トレーニングやテストに使用される実際のデータ)や、モデルのレスポンスに対するヒューマンフィードバックの収集に役立ちます。そして AWS Step Functions は、エンドツーエンドのモニタリングワークフローのオーケストレーションに役立ちます。

コアサービス

コアサービスは、管理や運用のコンポーネントやモジュールの集合体です。これらのコンポーネントは、システム運用、リソース管理、ユーザーおよびテナント管理、モデル管理など、さまざまな側面を監視、制御、管理できるように設計されています。これらは次の図に示されています。これらのコンポーネントは、システムの運用、リソース管理、ユーザーおよびテナント管理、モデル管理のさまざまな側面を監視、制御、および管理できるように設計されています。以下の図に示します。

テナントの管理と認証 (Tenant management and identity)

テナント管理は、マルチテナントシステムにおいて重要な要素です。マルチテナントシステムでは、アプリケーションや環境のシングルインスタンスが複数のテナントや顧客に提供され、それぞれが独立した安全な環境で利用されます。テナント管理のコンポーネントは、システム内のテナントの管理や運用を担います。

  • テナントのオンボーディングとプロビジョニング – 新規テナント向けのオンボーディングの再利用可能なプロセスの作成を担います。これには、テナント固有の環境の作成、リソースの割り当て、テナントの要件に基づくアクセス制御の設定が含まれます。
  • テナントの構成とカスタマイズ – 多くのマルチテナントシステムでは、テナント毎に特定のニーズに合わせてアプリケーションや環境を部分的に変更することができます。テナント管理のコンポーネントは、テナントが分離された環境で設定、ブランディング、ワークフロー、その他の設定を変更するためのインターフェースやツールを提供できます。
  • テナントの監視とレポーティング – このコンポーネントは、監視や計測のコンポーネントとリンクしており、テナント固有の使用状況、パフォーマンス、およびリソース消費に関するレポートを作成します。テナントのアクティビティに関するインサイトを提供し、潜在的な問題を特定し、各テナントのキャパシティプランニングやリソース割り当てを容易にします。
  • テナントの料金請求とサブスクリプション管理 – 複数の価格モデルやサブスクリプションプランが存在するソリューションでは、テナント管理のコンポーネントが、各テナントの利用状況、リソース消費量、もしくは契約サービスレベルに基づいて、テナント毎の料金請求やサブスクリプション管理を処理することができます。

提案のソリューションでは、リクエストを行うユーザーの認証フローも必要となります。AWS IAM Identity Center を使用すると、作業ユーザーを作成または連携し、AWS アカウントとアプリケーションに渡ってアクセスを一元管理できます。 Amazon Cognito を使用すると、ビルトインのユーザーディレクトリ、お客さまのエンタープライズディレクトリ、およびその他のコンシューマーアイデンティティプロバイダーから、ユーザーを認証および認可することができます。AWS Identity and Access Management (IAM) は、細粒度のアクセス制御を可能にします。IAM を使用して、どのユーザーがどの基盤モデルやリソースにアクセスできるかを指定し、最小権限でのアクセス許可を保つことができます。

例えば、Cognito でよくあるシナリオの1つとして、ユーザープールを用いて API Gateway と Lambda でリソースにアクセスするといったものがあります。次の図では、ユーザーが Amazon Cognito ユーザープールにサインインすると、アプリケーションが JSON Web トークン (JWT) を受け取ります。ユーザープールのグループを使用して、グループの権限を IAM ロールにマッピングすることで、API Gateway での権限を制御することができます。ユーザープールのトークンを API Gateway へのリクエストに含めて送信し、Amazon Cognito のオーソライザーとしての Lambda ファンクションで検証することができます。詳細は、「Amazon Cognito ユーザープールをオーソライザーとして使用してREST API へのアクセスを制御する」を参照してください。

APIへのアクセスの制御で、認証や認可に API キーを使用しないことをお勧めします。代わりに、IAM ロール、Lambda オーソライザー、または Amazon Cognito ユーザープールを使用してください。

モデルのオンボーディング (Model onboarding)

生成 AI ゲートウェイの重要な点は、基礎モデルやカスタムモデルへの統制されたアクセスをテナント全体で可能にすることです。Amazon Bedrock で利用可能な基盤モデルの場合、テナントがアクセスできる承認済みのモデルの許可リストを、モデルのオンボーディングコンポーネントが保持します。

Amazon DynamoDB などのサービスを使用して、許可リストに登録されたモデルを追跡することができます。同様に、Amazon SageMaker にデプロイされたカスタムモデルの場合、コンポーネントは、DynamoDB のレジストリテーブルのエントリから、どのテナントがどのモデルバージョンにアクセスしているかを追跡します。

アクセス制御を強化するために、Amazon API Gateway と AWS Lambda オーソライザーを併用することができます。テナントのアプリケーションがモデルを呼び出す API をコールすると、Lambda オーソライザーがテナントの ID を確認し、DynamoDB レジストリテーブルに照らして要求されたモデルへのアクセス権限があるかどうかをチェックします。アクセスが許可された場合、一時的なクレデンシャルが発行され、テナントの権限が許可されたモデルのみに適用されます。これにより、テナントがアクセス権限のないモデルにアクセスするのを防ぎます。認可のロジックは、組織のモデルへのアクセスのポリシーやガバナンスの要件に基づいてカスタマイズできます。このアプローチは、モデルの運用終了をサポートします。DynamoDB のレジストリテーブルの許可リストから、すべてのテナントもしくは特定のテナントのモデルを管理することで、コードを変更することなく、リストに含まれていないモデルが自動的に使用できなくなります。

モデルのレジストリ (Model registry)

モデルのレジストリは、カスタムモデルのさまざまなバージョンの管理や追跡に役立ちます。 Amazon SageMaker Model Registry や Amazon DynamoDB などのサービスは、利用可能なモデル、関連するモデルのアーティファクト、そしてリネージ(系統)の追跡に役立ちます。モデルのレジストリは、以下の機能を提供します。

  1. バージョンの管理 – 生成AIのモデルのさまざまなバージョンを追跡します。
  2. モデルのリネージや来歴 – トレーニングデータ、ハイパーパラメータ、モデルアーキテクチャ、モデルの来歴や特性を記述する関連するメタデータなどの情報を含め、各モデルのバージョンのリネージや来歴を追跡します。
  3. モデルのデプロイとロールバック – 新しいモデルのバージョンを本番環境にデプロイして利用可能にし、また必要に応じて以前のバージョンへのロールバックを可能にします。これにより、システムの運用を中断することなく、モデルをシームレスに更新または復元することができます。
  4. モデルのガバナンスとコンプライアンス – モデルのバージョンが適切に文書化され、監査され、関連するポリシーやレグレーショ制に準拠していることを確認します。これは、規制産業やコンプライアンス要件が厳しい環境で特に有用です。

オブザーバビリティ

オブザーバビリティは、アプリケーションの健全性の監視、問題のトラブルシューティング、基盤モデルの使用、パフォーマンスやコストの最適化には不可欠です。

ログの取得と監視 (Logging and monitoring)

Amazon CloudWatch は強力なモニタリングとオブザーバビリティのサービスであり、API Gateway、Amazon Bedrock、Amazon SageMaker、カスタムサービスなどのアプリケーションコンポーネントからのログを収集・分析できます。CloudWatch でスタック全体にわたるログからテナント ID を特定することで、生成 AI ゲートウェイのパフォーマンスや健全性に関するインサイトをテナントレベルで得ることができ、問題が深刻化する前に、問題を特定して解決することができます。予期しない挙動が発生した場合に通知を受け取るよう、アラームを設定することもできます。Amazon SageMaker と Amazon Bedrock は、AWS CloudTrail と統合されています。

計測 (Metering)

計測は、ソリューションのさまざまな部分から運用や使用のデータやパフォーマンスメトリクスを収集、集約、分析するのに役立ちます。従量課金制やサブスクリプションベースのモデルを提供するシステムでは、テナント毎に正確に請求するためにリソース消費を測定して報告するといった計測が重要となります。

このソリューションでは、コストを効果的に管理し、リソースの使用率を最適化するために、基盤モデルの使用状況を追跡する必要があります。 使用したモデル、入力されたトークン数、出力として生成されたトークン数、使用された AWS リージョン、チームに関連するタグの適用など、関連する情報を収集することで、コスト配分や請求処理を合理化することができます。基盤モデルとのやりとりを構造化データとして記録し、利用情報を収集することができます。次の図は、Lambda 関数がテナント毎の情報を Amazon CloudWatch に記録しながら、Amazon Bedrock を呼び出す実装を示しています。Amazon Bedrock の呼び出しにより、AWS CloudTrail のイベントが生成されます。

監査 (Auditing)

AWS Lambda 関数を使用して Amazon CloudWatch からのデータを集約し、S3 バケットに保存して長期保存やさらなる分析を行うことができます。Amazon S3 は、耐久性、拡張性、コスト効率に優れたオブジェクトストレージソリューションであり、大量のデータを保存するのに最適です。実装の詳細については、このシリーズの第1部の「Amazon Bedrock での基盤モデルのコストと使用状況の追跡を備えた社内 SaaS サービスの構築」を参照してください。

Amazon S3 にデータが保存された後、Amazon Athena、AWS Glue Data CatalogAmazon QuickSight などの AWS のアナリティクスサービスを使用して、コストや使用のパターンを明らかにし、レポートを生成し、傾向を可視化します。そしてリソースの割り当て、予算の予測、コスト最適化戦略といったことに基づいて意思決定を行うことができます。AWS Glue Data Catalog(一元的なメタデータリポジトリ)と Amazon Athena(インタラクティブなクエリサービス)を使用すると、Amazon S3 に保存されたデータに対して、SQL クエリを直接実行することができます。以下の例では、Athena での各テナントのモデル毎の使用とコストについて示します。

企業全体への展開

以下は、組織内の多くの事業部門やチームにこのソリューションをスケールさせる場合の設計上の考慮事項です。

  • アカウントの制限 – これまで単一の AWS アカウントでゲートウェイソリューションを展開する方法について説明してきました。チームがゲートウェイに次々と参加し、LLM の利用を拡大していくと、さまざまなコンポーネントがAWSアカウントの制限に達し、ボトルネックとなっていく可能性があります。生成 AI ゲートウェイは、1つの AWS アカウントが1つの事業部門に対応するようにして、複数の AWS アカウントを展開していくことをお勧めします。その理由は、一般的には大企業の各事業部門は自律的であり、そして数十から数百のチームを抱えている可能性があるからです。さらに各事業部門は、他の事業部門とのデータの共有を制限する厳格なデータプライバシーポリシーを定めている場合もあります。本番環境のアカウントに加えて、各事業部門はテスト環境やインテグレーション環境のAWSアカウントも保有する可能性もあります。
  • 本番および非本番のワークロード – ほとんどの場合、事業部門等のテナント側のチームは、開発、テスト、本番の各環境でこのゲートウェイを使用したいと考えるでしょう。組織の運用モデルに大きく依るものですが、本番環境のゲートウェイに負荷をかけたり、非本番環境のデータを混在したりすることなく、チームが自由に実験を行えるよう、ゲートウェイにも専用の開発、テスト、本番環境を用意することを推奨しています。これにより、非本番環境のゲートウェイの制限値を本番環境よりも低く設定できるというメリットも得られます。
  • RAG のデータコンポーネントの取り扱い – RAG ソリューションを実装する際には、すべてのデータ関連のコンポーネントをテナント側で管理することをお勧めします。各テナントには、独自のデータ制約、更新サイクル、フォーマット、用語、および権限グループがあります。データソースの管理責任をゲートウェイに割り当てると、スケーラビリティが妨げられる可能性があります。ゲートウェイは各テナントのデータソースの固有の要件に対応できないため、おそらくは最低限の共通項目を処理することになるでしょう。したがって、データソースおよび関連コンポーネントはテナント側で管理することをお勧めします。
  • 車輪の再発明の回避 – このソリューションは、モデル評価、ガードレール、プロンプトカタログ、監視など、独自のコンポーネントを構築および管理できます。Amazon Bedrock などのサービスは、セキュリティ、プライバシー、責任ある AI を最初から備えた生成 AI アプリケーションを構築するために必要な機能を提供しています。バランスの取れたアプローチを取り、極力 AWS ネイティブの機能を使用して運用コストを削減することをお勧めします。
  • スリムな生成 AI ゲートウェイの維持 – ビジネスロジックの保持という観点で、このゲートウェイをスリムに保つことを提案します。ゲートウェイに、特定のテナントに対するビジネスルールを追加すべきではなく、既に取り上げたような運用データ以外のテナント固有のデータを保持することは避けるべきです。

おわりに

生成 AI のマルチテナントのアーキテクチャは、複数のユースケースやチームに渡って生成 AI の利用を拡大しながら、セキュリティ、ガバナンス、コスト管理を維持するのに役立ちます。本記事では、生成 AI の導入を加速させるための参考となるマルチテナントのアーキテクチャを紹介しました。共通的な生成 AI コンポーネントの標準化と、それらを共有サービスとして公開する方法について説明しました。また、提案のアーキテクチャでは、ガバナンス、セキュリティ、オブザーバビリティ、責任ある AI といった主要な観点についても取り上げました。最後に、このアーキテクチャを多くのチームに拡張していく際の主な考慮事項について説明しました。 このトピックについてさらに詳しくお知りになりたい方は、以下もご覧ください。

著者について

Anastasia Tzeveleka は、AWSのシニア生成 AI/ML スペシャリストソリューションアーキテクトです。EMEA 全域のお客さまが AWS サービスを使用して基盤モデルを構築し、スケーラブルな生成 AI および機械学習のソリューションを構築できるよう支援しています。
.
.
.
.

Hasan Poonawala は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトとして、ヘルスケアおよびライフサイエンス業界のお客さまを担当しています。AWS での生成 AI および機械学習アプリケーションの設計、デプロイ、およびスケールを支援しています。クラウド上での機械学習、ソフトウェア開発、およびデータサイエンスで、合計15年以上の業務経験があります。余暇は自然探索や友人や家族との時間を大切にしています。
.
.

Bruno Pistone は、ミラノを拠点とする AWS のシニア生成 AI および ML スペシャリストソリューションアーキテクトです。 お客さまと共同し、お客さまの技術的なニーズを深く理解し、AWS クラウドと Amazon Machine Learning スタックを最大限に活用する AI および機械学習ソリューションの設計を支援しています。 専門分野は、機械学習全般、機械学習の商用化、生成 AI です。 友人と過ごす時間や新しい場所を探索することを楽しんでおり、新しい場所への旅行も好んでいます。
.
.

Vikesh Pandey は、金融サービスを専門とするプリンシパル生成 AI/ML ソリューションアーキテクトで、お客さまが生成 AI/ML プラットフォームやソリューションを構築し、数百人から数千人のユーザーに拡張することを支援しています。余暇には、さまざまなブログフォーラムに投稿したり、子供と一緒にレゴを組み立てたりするのが好きです。
.
.
.

Antonio Rodriguez は、Amazon Web Servicesのプリンシパル生成 AI スペシャリストソリューションアーキテクトです。あらゆる規模の企業が抱える課題の解決、イノベーションの導入、Amazon Bedrock による新たなビジネスオポチュニティの創出を支援しています。仕事以外では、家族と過ごしたり、友人とスポーツを楽しんだりしています。
.
.
.

翻訳者について

川口賢太郎 (Kentaro Kawaguchi) は、プロフェッショナルサービスのシニア CS&O アドバイザリーコンサルタントで、デジタル戦略立案とそれに即した組織の変革に注力しています。CCoEAI CoE などの xCoE の組成支援などに従事しています。