Amazon Web Services ブログ

生成 AI ワークロードにおけるレジリエンス設計

レジリエンスは、あらゆるワークロードの開発において重要な役割を果たしており、生成 AI ワークロードも例外ではありません。生成 AI ワークロードを開発する際には、レジリエンスの観点における独自の考慮事項があります。組織の可用性と事業継続性の要件を満たすためには、レジリエンスを理解し、優先順位を付けて対応することが不可欠です。本ブログ記事では、生成 AI ワークロードを構成する各スタックとそれらの考慮事項について説明します。

生成 AI ワークロードを構成するスタック

生成 AI の魅力の多くがモデルに焦点を当てていますが、完全なソリューションには複数分野の人材、スキル、ツールが必要です。次の図は、a16z（Andreessen Horowitz）が公開している大規模言語モデル (LLM) を利用した新しいアプリケーションスタックを AWS の視点で捉えたものです。

Emerging LLMStack on AWS

従来の AI や機械学習 (ML) を中心としたソリューションと比較すると、生成 AI ソリューションには以下が含まれていることが分かります。

  • 新しいロール – モデルチューナーだけでなく、モデルの開発元やモデルインテグレーターの役割も考慮する必要があります
  • 新しいツール – 従来の MLOps スタックは、プロンプトエンジニアリングやエージェント（他のシステムと対話するツールを呼び出す）に必要な実験の追跡やオブザーバビリティに対応していません

検索拡張生成 (RAG)

従来の AI モデルとは異なり、RAG は外部ナレッジソースを統合することで、より正確でコンテキストに関連したレスポンスを可能にします。RAG を使用する際の考慮事項は以下のとおりです。

  • 外部ナレッジソースからのデータ取得に適切なタイムアウトを設定することは、顧客体験にとって重要です。チャットの最中に切断されることほど、ユーザー体験を損なうものはありません。
  • プロンプトへの入力データが、利用するモデルのトークン数制限内であることを検証してください。
  • プロンプトを信頼できるデータストアに保存してください。万が一プロンプトを紛失した場合やディザスタリカバリ戦略の一環として、プロンプトを保護できます。

データパイプライン

RAG パターンを使用して基盤モデルにコンテキストデータを提供する場合、ソースデータを取り込み、埋め込みベクトルに変換し、ベクトルデータベースに保存できるデータパイプラインが必要です。コンテキストデータを事前に準備している場合はバッチパイプラインになります。新しいコンテキストデータを逐次取り込む場合は低レイテンシパイプラインとなります。バッチパイプラインの場合、一般的なデータパイプラインと比較して、いくつかの課題があります。

データソースには、ファイルシステム上の PDF ドキュメント、CRM ツールのような SaaS (Software as a Service) からのデータ、既存の Wiki やナレッジベースなどが考えられます。これらのソースからの取り込みは、Amazon S3 (Amazon Simple Storage Service) 上のログデータやリレーショナルデータベースにある構造化データなどの一般的なデータソースからの取り込みとは異なり、並列処理のレベルがソースシステムによって制限される可能性があるため、スロットリングを考慮し、バックオフ手法を使用する必要があります。また、ソースシステムの一時的な障害等に備えて、エラー処理とリトライロジックを組み込む必要があります。

埋め込みモデルは、パイプライン内でローカルに実行するか外部モデルを呼び出すかに関わらず、パフォーマンスのボトルネックになる可能性があります。埋め込みモデルは主に GPU 上で実行される基盤モデルであり、そのキャパシティは有限です。モデルをローカルで実行する場合は、GPU 容量に基づいてタスクを割り当てる必要があります。モデルを外部で実行する場合は、外部モデルが飽和状態にならないようにする必要があります。いずれの場合も、達成できる並列度は、バッチパイプラインが利用できる CPU や RAM の量ではなく、埋め込みモデルによって決定されます。

低レイテンシパイプラインの場合、埋め込みベクトルの生成時間を考慮してください。アプリケーションは低レイテンシパイプラインを非同期で呼び出す必要があります。

ベクトルデータベース

ベクトルデータベースには 2 つの機能があります。埋め込みベクトルの保存および、あるベクトルに対して最も近い k 個のマッチングを見つける類似検索を実行することです。また、ベクトルデータベースには大きく分けて次の 3 つのタイプがあります。

  • Pinecone 等のベクトルデータベース専用 SaaS
  • 製品やサービスに組み込まれたベクトルデータベース機能（Amazon OpenSearch Service や Amazon Aurora などの AWS サービスも含まれる）
  • 一時データに使用できるインメモリデータベース（低レイテンシが要求されるシナリオ）

本ブログ記事では、類似性検索機能の詳細については説明しません。これらは重要ですが、システムの機能的な側面であり、レジリエンスに直接影響を与えないためです。その代わり、ストレージシステムとしてのベクトルデータベースのレジリエンスの側面に焦点を当てます。

  • レイテンシ – 高負荷や予測不可能な負荷に対してもパフォーマンスを発揮できますか。そうでない場合、アプリケーションはレート制限やバックオフ、リトライ処理を行う必要があります。
  • スケーラビリティ – いくつベクトルを保持できますか。ベクトルデータベースの容量を超える場合、シャーディングや他のソリューションを検討する必要があります。
  • 高可用性とディザスタリカバリ – ベクトルデータベースは、単一のリージョンで高可用性を実現していますか。別のリージョンにデータをレプリケートして災害復旧目的で使用できますか。埋め込みベクトルは貴重なデータであり、再生成にはコストがかかります。

アプリケーション

生成 AI ソリューションの統合において、アプリケーションには、3 つの固有の考慮事項があります。

  • 高いレイテンシの可能性 – 基盤モデルは大きな GPU インスタンス上で実行されることが多いため、GPU 容量が確保できない可能性があります。レート制限、バックオフとリトライ、負荷制限のベストプラクティスを使用してください。高いレイテンシがアプリケーションのメインインターフェースに干渉しないように、非同期処理を利用した設計にします。
  • セキュリティ態勢 – エージェント、ツール、プラグイン、その他の方法を使用してモデルを他のシステムに接続している場合は、セキュリティ態勢に特に注意を払います。モデルはこれらのシステムと予想外の方法でやりとりしようとする可能性があります。たとえば、他のシステムからのプロンプトの受信を制限するなど、標準的なプラクティスである最小特権のアクセス許可に従ってください。
  • 急速に進化するフレームワーク – LangChain のようなオープンソースフレームワークは急速に進化しています。このような成熟度の低いフレームワークから他のコンポーネントを分離するために、マイクロサービスアプローチを使用します。

キャパシティ

キャパシティは、推論とトレーニングモデルのデータパイプラインという 2 つのコンテキストで考えることができます。組織が独自のパイプラインを構築する際にキャパシティが考慮事項となります。ワークロードを実行するインスタンスを選択する際、CPU とメモリが最大の要件の 2 つです。

生成 AI ワークロードをサポートできるインスタンスは、汎用インスタンスタイプよりも入手が難しい場合があります。インスタンスの柔軟性は、キャパシティとキャパシティプランニングに役立ちます。使用可能なインスタンスタイプはリージョンによって異なります。

重要なユーザージャーニーの場合、インスタンスタイプを予約または事前プロビジョニングし、必要なときに利用できるよう検討してください。このパターンにより、レジリエンスのベストプラクティスである静的に安定したアーキテクチャが実現できます。AWS Well-Architected Framework の信頼性の柱における静的安定性の詳細については、静的安定性を使用してバイモーダル動作を防止するを参照してください。

オブザーバビリティ

Amazon SageMaker や Amazon Elastic Compute Cloud (Amazon EC2) 上でモデルをホストする場合は、通常収集するリソースメトリクスである CPU や RAM の使用率に加えて GPU の使用率も注意深く監視します。基盤モデルや入力データが変更されると、GPU 使用率が予期せず変化する可能性があります。GPU メモリが不足するとシステムが不安定な状態になる可能性があります。

スタックの上位では、システム内の呼び出しの流れをトレースして、エージェントとツール間の対話をキャプチャすることも重要です。エージェントとツール間のインターフェースは API コントラクトほど正式に定義されていないため、パフォーマンスのみならず、新しいエラーシナリオを捉えるためにもこれらのトレースを監視する必要があります。モデルやエージェントのセキュリティリスクや脅威を監視するために、Amazon GuardDuty などのツールを使用できます。

埋め込みベクトル、プロンプト、コンテキスト、出力のベースラインとこれらの間の相互作用もキャプチャする必要があります。これらが時間とともに変化する場合、ユーザーがシステムを新しい方法で使用している、コンテキストに渡す参照データが想定問答をカバーできていない、またはモデルの出力が突然変化したことを示している可能性があります。

ディザスタリカバリ

事業継続計画とディザスタリカバリ戦略を策定することは、どのワークロードにとっても必須です。生成 AI ワークロードも例外ではありません。ワークロードに適用可能な障害モードを理解することで、戦略の指針となります。Amazon Bedrock や SageMaker などの AWS マネージドサービスを使用している場合は、そのサービスが復旧用の AWS リージョンで利用可能であることを確認してください。本ブログ記事の執筆時点では、これらの AWS サービスはリージョン間のデータレプリケーションをネイティブでサポートしていないため、ディザスタリカバリのためのデータ管理戦略を検討する必要があります。また、災害時にファインチューニングされたカスタムモデルを利用したい場合、複数のリージョンにおいてファインチューニングを行っておく必要があります。

まとめ

本ブログ記事では、生成 AI ソリューションを構築する際にレジリエンスを考慮する方法について説明しました。生成 AI アプリケーションにはいくつか興味深いニュアンスがありますが、既存のレジリエンスパターンとベストプラクティスは依然として適用できます。あとは、生成 AI アプリケーションの各スタックを評価し、関連するベストプラクティスを適用することが重要です。

生成 AI と AWS サービスでのその利用に関する詳細は、次のリソースを参照してください。

著者について

Jennifer MoranJennifer Moran は、ニューヨークを拠点とする AWS シニアレジリエンシーソリューションアーキテクトです。ソフトウェア開発、アジャイルリーダーシップ、DevOps など、多岐にわたる技術分野で働いた経験を持っています。顧客のレジリエンス向上とその重要性について公に発信することを楽しんでいます。

Randy DeFauwRandy DeFauw は、AWS シニアプリンシパルソリューションアーキテクトです。ミシガン大学で自動運転車両のコンピュータビジョンについて研究し、電気電子工学の修士号を取得しています。また、コロラド州立大学で MBA を取得しています。Randy はソフトウェアエンジニアリングから製品管理まで、テクノロジー分野のさまざまなポジションを歴任してきました。2013 年にビッグデータ分野に参入し、その分野を探索し続けています。機械学習分野のプロジェクトに積極的に取り組んでおり、Strata や GlueCon など、数多くのカンファレンスでプレゼンテーションを行っています。

翻訳は Solutions Architect 北川が担当しました。原文はこちらです。