[SEO 小見出し]
このガイダンスは、ゲームデベロッパーがゲームおよび関連インフラストラクチャ用のノンプレイヤーキャラクター (NPC) の作成プロセスを自動化するのに役立ちます。ここでは、大規模言語モデル (LLM)、Claude 2、Llama 2 などの基盤モデル (FM) と共に Unreal Engine MetaHuman を使用して NPC の会話スキルを向上させます。これにより、各プレイヤーに固有の NPC からのダイナミックな応答が可能になり、スクリプト化されたダイアログが追加されます。このガイダンスでは、大規模言語モデル運用 (LLMOps) 手法を使用することで、LLM の微調整を行うと共に、生成 AI アプリケーションを継続的に統合してデプロイすることで、プロトタイピングと納期を短縮します。同時に、NPC がゲームロアのセキュアなナレッジベースに完全にアクセスできるようにします。
このガイダンスは、概要アーキテクチャ、LLMOps パイプラインアーキテクチャ、基盤モデル運用 (FMOps) アーキテクチャ、およびデータベースハイドレーションアーキテクチャの 4 つの要素で構成されています。
注意: [免責事項]
アーキテクチャ図
-
概要
-
LLMOps パイプライン
-
FMOps パイプライン
-
データベースハイドレーション
-
概要
-
このアーキテクチャ図は、AWS 上で生成 AI NPC をホストするためのワークフローの概要を示しています。
拡大イメージを見る
ステップ 1
ゲームクライアントが、Unreal Engine Metahuman 上で動作する NPC と対話します。
ステップ 2
NPC からの生成テキスト応答に対するリクエストが、Text API Amazon API Gateway エンドポイントに送信されます。NPC からのゲーム固有のコンテキストを必要とするリクエストが、Retrieval-Augmented Generation (RAG) API Gateway エンドポイントに送信されます。ステップ 3
AWS Lambda が、NPC テキストリクエストを処理し、Amazon Bedrock でホストされている LLM に送信します。ステップ 4
ベース LLM と微調整によってカスタマイズされた LLM が、生成テキスト応答を提供します。ステップ 5
生成テキスト応答が Amazon Polly に送信され、Amazon Polly が応答の音声ストリームを返します。音声フォーマットが NPC に返され、ダイアログとして配信されます。ステップ 6
RAG NPC リクエストの場合、Lambda が Amazon Bedrock にリクエストを送信して、ベクトル化された表現を埋め込みモデルから生成します。その後、Lambda が Amazon OpenSearch Service のベクトルインデックスから関連情報を検索します。ステップ 7
OpenSearch Service が、Amazon Bedrock からのリクエストのベクトル化された表現に基づいて生成テキスト応答を拡張する関連コンテキストを提供する類似検索機能を提供します。
ステップ 8
関連コンテキストと元のテキストリクエストが Amazon Bedrock でホストされている LLM に送信され、生成テキスト応答が提供されます。その後、Amazon Polly がダイアログ用の応答を NPC に配信します。ステップ 9
ゲームナラティブライターが、ゲーム固有のトレーニングデータを追加して、FMOps プロセスを使用してカスタムモデルを作成するか、ベクターデータベースをハイドレートするゲームのロアデータを追加します。
ステップ 10
インフラストラクチャエンジニアと DevOps エンジニアが、AWS Cloud Development Kit (AWS CDK) を使用してアーキテクチャをコードとして管理し、Amazon CloudWatch を使用してガイダンスをモニターします。ステップ 1
ゲームクライアントが、Unreal Engine Metahuman 上で動作する NPC と対話します。
ステップ 2
NPC からの生成テキスト応答に対するリクエストが、Text API Amazon API Gateway エンドポイントに送信されます。NPC からのゲーム固有のコンテキストを必要とするリクエストが、Retrieval-Augmented Generation (RAG) API Gateway エンドポイントに送信されます。ステップ 3
AWS Lambda が、NPC テキストリクエストを処理し、Amazon Bedrock でホストされている LLM に送信します。ステップ 4
ベース LLM と微調整によってカスタマイズされた LLM が、生成テキスト応答を提供します。ステップ 5
生成テキスト応答が Amazon Polly に送信され、Amazon Polly が応答の音声ストリームを返します。音声フォーマットが NPC に返され、ダイアログとして配信されます。ステップ 6
RAG NPC リクエストの場合、Lambda が Amazon Bedrock にリクエストを送信して、ベクトル化された表現を埋め込みモデルから生成します。その後、Lambda が Amazon OpenSearch Service のベクトルインデックスから関連情報を検索します。ステップ 7
OpenSearch Service が、Amazon Bedrock からのリクエストのベクトル化された表現に基づいて生成テキスト応答を拡張する関連コンテキストを提供する類似検索機能を提供します。
ステップ 8
関連コンテキストと元のテキストリクエストが Amazon Bedrock でホストされている LLM に送信され、生成テキスト応答が提供されます。その後、Amazon Polly がダイアログ用の応答を NPC に配信します。ステップ 9
ゲームナラティブライターが、ゲーム固有のトレーニングデータを追加して、FMOps プロセスを使用してカスタムモデルを作成するか、ベクターデータベースをハイドレートするゲームのロアデータを追加します。
ステップ 10
インフラストラクチャエンジニアと DevOps エンジニアが、AWS Cloud Development Kit (AWS CDK) を使用してアーキテクチャをコードとして管理し、Amazon CloudWatch を使用してガイダンスをモニターします。 -
LLMOps パイプライン
-
このアーキテクチャ図は、LLMOps パイプラインを AWS にデプロイするプロセスを示しています。
拡大イメージを見る
ステップ 1
インフラストラクチャエンジニアが AWS CDK を使用して、体系化されたインフラストラクチャを構築し、テストします。
ステップ 2
インフラストラクチャコードの更新は AWS CodeCommit リポジトリにコミットされ、Toolchain AWS アカウント内の継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインが呼び出されます。ステップ 3
Docker コンテナや AWS CloudFormation テンプレートなどのインフラストラクチャアセットがコンパイルされ、Amazon Elastic Container Registry (Amazon ECR) と Amazon Simple Storage Service (Amazon S3) に保存されます。ステップ 4
統合とシステムテストの目的で、インフラストラクチャが CloudFormation スタックとして品質保証 (QA) AWS アカウントにデプロイされます。ステップ 5
AWS CodeBuild が、アーキテクチャが機能的であること、および本番デプロイの準備が整っていることを確認する自動テストスクリプトを開始します。ステップ 6
すべてのシステムテストが正常に完了すると、インフラストラクチャが CloudFormation スタックとして本番 (PROD) AWS アカウントに自動的にデプロイされます。
ステップ 7
FMOps パイプラインリソースも CloudFormation スタックとして PROD AWS アカウントにデプロイされます。
ステップ 1
インフラストラクチャエンジニアが AWS CDK を使用して、体系化されたインフラストラクチャを構築し、テストします。
ステップ 2
インフラストラクチャコードの更新は AWS CodeCommit リポジトリにコミットされ、Toolchain AWS アカウント内の継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインが呼び出されます。ステップ 3
Docker コンテナや AWS CloudFormation テンプレートなどのインフラストラクチャアセットがコンパイルされ、Amazon Elastic Container Registry (Amazon ECR) と Amazon Simple Storage Service (Amazon S3) に保存されます。ステップ 4
統合とシステムテストの目的で、インフラストラクチャが CloudFormation スタックとして品質保証 (QA) AWS アカウントにデプロイされます。ステップ 5
AWS CodeBuild が、アーキテクチャが機能的であること、および本番デプロイの準備が整っていることを確認する自動テストスクリプトを開始します。ステップ 6
すべてのシステムテストが正常に完了すると、インフラストラクチャが CloudFormation スタックとして本番 (PROD) AWS アカウントに自動的にデプロイされます。
ステップ 7
FMOps パイプラインリソースも CloudFormation スタックとして PROD AWS アカウントにデプロイされます。
-
FMOps パイプライン
-
このアーキテクチャ図は、FMOps を使用して生成 AI モデルを調整するプロセスを示しています。
拡大イメージを見る
ステップ 1
ゲームのロアテキストドキュメントが S3 バケットにアップロードされます。
ステップ 2
ドキュメントオブジェクトのアップロードイベントによって Amazon SageMaker Pipelines が呼び出されます。ステップ 3
前処理ステップが SageMaker 処理ジョブを実行し、モデルの微調整とモデル評価のためにテキストドキュメントの前処理を行います。ステップ 4
コールバックステップでは、メッセージを Amazon Simple Queue Service (Amazon SQS) キューに送信することで SageMaker Pipelines を他の AWS のサービスと統合できます。メッセージを送信した後、SageMaker Pipelines はキューからの応答を待ちます。ステップ 5
Amazon SQS が、SageMaker Pipelines と AWS Step Functions ワークフロー間のタスクを調整します。ステップ 6
Step Functions ワークフローが LLM の微調整プロセスのオーケストレーションを行います。モデルが微調整されると、Amazon SQS が成功メッセージを SageMaker Pipelines のコールバックステップに送信します。
ステップ 7
モデル評価ステップで SageMaker 処理ジョブが実行され、微調整されたモデルのパフォーマンスが評価されます。調整されたモデルが Amazon SageMaker Model Registry に保存されます。ステップ 8
機械学習 (ML) の担当者が、調整されたモデルをレビューし、本番環境での使用を承認します。ステップ 9
AWS CodePipeline ワークフローが呼び出され、承認済みのモデルが本番環境にデプロイされます。ステップ 1
ゲームのロアテキストドキュメントが S3 バケットにアップロードされます。
ステップ 2
ドキュメントオブジェクトのアップロードイベントによって Amazon SageMaker Pipelines が呼び出されます。ステップ 3
前処理ステップが SageMaker 処理ジョブを実行し、モデルの微調整とモデル評価のためにテキストドキュメントの前処理を行います。ステップ 4
コールバックステップでは、メッセージを Amazon Simple Queue Service (Amazon SQS) キューに送信することで SageMaker Pipelines を他の AWS のサービスと統合できます。メッセージを送信した後、SageMaker Pipelines はキューからの応答を待ちます。ステップ 5
Amazon SQS が、SageMaker Pipelines と AWS Step Functions ワークフロー間のタスクを調整します。ステップ 6
Step Functions ワークフローが LLM の微調整プロセスのオーケストレーションを行います。モデルが微調整されると、Amazon SQS が成功メッセージを SageMaker Pipelines のコールバックステップに送信します。
ステップ 7
モデル評価ステップで SageMaker 処理ジョブが実行され、微調整されたモデルのパフォーマンスが評価されます。調整されたモデルが Amazon SageMaker Model Registry に保存されます。ステップ 8
機械学習 (ML) の担当者が、調整されたモデルをレビューし、本番環境での使用を承認します。ステップ 9
AWS CodePipeline ワークフローが呼び出され、承認済みのモデルが本番環境にデプロイされます。 -
データベースハイドレーション
-
このアーキテクチャ図は、RAG のゲームロアをベクトル化して保存することによるデータベースハイドレーションのプロセスを示しています。
拡大イメージを見る
ステップ 1
データサイエンティストがゲームロアテキストドキュメントを S3 バケットにアップロードします。
ステップ 2
オブジェクトがアップロードされると、SageMaker 処理ジョブを起動する Lambda 関数が呼び出されます。
ステップ 3
SageMaker 処理ジョブが Amazon S3 からテキストドキュメントをダウンロードし、テキストを複数のチャンクに分割します。
ステップ 4
次に、SageMaker 処理ジョブが、Amazon Bedrock 上でホストされている Amazon Titan 埋め込みモデルにテキストの各チャンクを送信して、テキストチャンクのベクトル化された表現を作成します。ステップ 5
次に、SageMaker 処理ジョブが、RAG の目的でテキストチャンクとベクトル表現の両方を OpenSearch Service に取り込みます。
ステップ 1
データサイエンティストがゲームロアテキストドキュメントを S3 バケットにアップロードします。
ステップ 2
オブジェクトがアップロードされると、SageMaker 処理ジョブを起動する Lambda 関数が呼び出されます。
ステップ 3
SageMaker 処理ジョブが Amazon S3 からテキストドキュメントをダウンロードし、テキストを複数のチャンクに分割します。
ステップ 4
次に、SageMaker 処理ジョブが、Amazon Bedrock 上でホストされている Amazon Titan 埋め込みモデルにテキストの各チャンクを送信して、テキストチャンクのベクトル化された表現を作成します。ステップ 5
次に、SageMaker 処理ジョブが、RAG の目的でテキストチャンクとベクトル表現の両方を OpenSearch Service に取り込みます。
Well-Architected Pillars
AWS Well-Architected フレームワークは、クラウドでシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。フレームワークの 6 つの柱により、信頼性が高く、安全かつ効率的で、費用対効果が高く、持続可能なシステムを設計および運用するためのアーキテクチャのベストプラクティスを学ぶことができます。AWS マネジメントコンソールで無料で提供されている AWS Well-Architected Tool を使用し、各柱の一連の質問に回答することで、これらのベストプラクティスに照らしてワークロードを確認できます。
上記のアーキテクチャ図は、Well-Architected のベストプラクティスを念頭に置いて作成されたソリューションの例です。完全に Well-Architected であるためには、可能な限り多くの Well-Architected ベストプラクティスに従う必要があります。
-
オペレーショナルエクセレンスオペレーショナルエクセレンスに関するホワイトペーパーを読む
このガイダンスでは、AWS X-Ray、Lambda、API Gateway、CloudWatch を使用して、Unreal Engine Metahuman クライアントと Amazon Bedrock FM 間の生成 NPC ダイアログに対するすべての API リクエストを追跡します。これにより、ガイダンスのステータスがエンドツーエンドで可視化され、ゲームクライアントからの各リクエストと応答をきめ細かく追跡できるため、問題をすばやく特定して適切に対応することができます。さらに、このガイダンスは、CodePipeline を使用して CDK アプリケーションとして体系化されているため、運用チームと開発者は、適切な変更管理手法を介して障害とバグに対処し、CI/CD パイプラインを使用して、これらの更新や修正をすばやくデプロイできます。
-
セキュリティセキュリティに関するホワイトペーパーを読む
Amazon S3 は、ベクトルへのゲームロアドキュメントの取り込みや、Amazon Bedrock FM の微調整を行いながら、転送中のデータへのアクセスを暗号化するだけでなく、ゲームロアドキュメントを保存するための保護を暗号化します。API Gateway は、NPC とモデル間のすべてのデータの TLS ベースの暗号化を行うことで、Unreal Engine Metahuman と Amazon Bedrock FM 間にセキュリティレイヤーを追加します。最後に、Amazon Bedrock は、AWS 利用規約と AWS 責任ある AI ポリシーの違反をさらに識別および緩和する自動不正検出メカニズムを実装しています。
-
信頼性信頼性に関するホワイトペーパーを読む
API Gateway は、NPC から FM へのリクエストの自動スケーリングとスロットリングを管理します。さらに、インフラストラクチャ全体が CI/CD パイプラインを使用して体系化されているため、複数の AWS アカウントと複数の AWS リージョン全体でリソースを並行してプロビジョニングできます。複数のインフラストラクチャの再デプロイシナリオを同時に実行できるため、AWS リージョンレベルでの障害を克服することができます。API Gateway と Lambda はサーバレスインフラストラクチャリソースとして機能するため、リソース割り当てと API リクエストの使用パターンを手動で管理する必要がなく、ゲーム開発にフォーカスすることができます。
-
パフォーマンス効率パフォーマンス効率に関するホワイトペーパーを読む
Lambda や API Gateway などのサーバーレスリソースは、伸縮性とスケーラビリティの両方を提供することにより、ガイダンスのパフォーマンス効率に貢献します。これにより、ガイダンスは NPC クライアントからの API コールの増減に動的に適応できます。柔軟でスケーラブルなアプローチにより、プロビジョニング済みのインフラストラクチャリソースを手動で管理しなくても、リソースを適切なサイズに調整して最適なパフォーマンスを実現し、API リクエストの予期しない増減に対応できます。
-
コストの最適化コスト最適化に関するホワイトペーパーを読む
ガイダンスを CDK アプリケーションとして体系化することにより、ゲーム開発者は、プロトタイプをすばやく作成して NPC キャラクターを本番環境にデプロイできます。 開発者は、API Gateway REST API を介して Amazon Bedrock FM にすばやくアクセスできます。FM のエンジニアリング、ビルド、および事前トレーニングは必要ありません。プロトタイプをすぐに使用できるので、FM をゼロから構築する時間と運用コストを削減できます。
-
持続可能性持続可能性に関するホワイトペーパーを読む
Lambda は、サーバーレスでスケーラブルなイベント駆動型のアプローチを提供します。専用のコンピューティングリソースをプロビジョニングする必要はありません。Amazon S3 は、このガイダンス全体にわたるすべてのデータの圧縮とともに、データライフサイクルポリシーを実装しており、エネルギー効率の高いストレージを実現します。Amazon Bedrock は、AWS シリコン上で FM をホストし、標準コンピューティングリソースのワットあたりのフォーマンスを向上させます。
免責事項
サンプルコード、ソフトウェアライブラリ、コマンドラインツール、概念の実証、テンプレート、またはその他の関連技術 (私たちの担当者から提供される前述のものを含む) は、AWS カスタマーアグリーメント、またはお客様と AWS との間の関連文書契約 (いずれか該当する方) に基づき、AWS コンテンツとしてお客様に提供されるものです。お客様は、この AWS コンテンツを、お客様の本番アカウント、または本番データもしくはその他の重要なデータで使用すべきではありません。お客様は、サンプルコードなどの AWS コンテンツを、お客様固有の品質管理手法および基準に基づいて、本番グレードでの使用に適したテスト、セキュリティ確保、および最適化を行う責任を負います。AWS コンテンツのデプロイには、Amazon EC2 インスタンスの実行や Amazon S3 ストレージの使用など、AWS の課金対象リソースを作成または使用するための AWS 料金が発生する場合があります。
本ガイダンスにおける第三者のサービスまたは組織への言及は、Amazon または AWS と第三者との間の承認、後援、または提携を意味するものではありません。AWS からのガイダンスは技術的な出発点であり、アーキテクチャをデプロイするときにサードパーティのサービスとの統合をカスタマイズできます。