[Sous-titre SEO]
Le présent guide permet aux développeurs de jeux d'automatiser le processus de création d'un personnage non-joueur (PNJ) pour leurs jeux et l'infrastructure associée. Il utilise Unreal Engine MetaHuman, ainsi que des modèles de fondation (FM), tels que les grands modèles de langage (LLM) Claude 2 et Llama 2, pour améliorer les compétences conversationnelles des PNJ. Il en résulte des réponses dynamiques de la part du PNJ qui sont propres à chaque joueur, ce qui vient enrichir les dialogues scénarisés. Grâce à la méthodologie Large Language Model Ops (LLMOps), le présent guide accélère le prototypage et les délais de livraison en intégrant et en déployant en continu l'application d'IA générative, tout en affinant les modèles de langage volumineux (LLM). Tout en veillant à ce que le PNJ ait un accès complet à une base de connaissances sécurisée sur les éléments de l'univers du jeu.
Le présent guide comprend quatre parties : une architecture de synthèse, une architecture de pipeline LLMOps, une architecture Foundation Model Operations (FMOps) et une architecture d'hydratation de base de données.
Veuillez noter : [Clause de non-responsabilité]
Diagramme d'architecture
-
Présentation
-
Pipeline LLMOps
-
Pipeline FMOps
-
Hydratation de la base de données
-
Présentation
-
Le présent diagramme d'architecture présente une vue d'ensemble du flux de travail pour héberger un PNJ d'IA générative sur AWS.
Cliquer pour agrandir
Étape 1
Les clients du jeu interagissent avec le PNJ qui utilise Unreal Engine Metahuman.
Étape 2
Les demandes de réponses textuelles générées par le PNJ sont envoyées à un point de terminaison d'API de texte Amazon API Gateway. Les requêtes qui nécessitent un contexte spécifique au jeu de la part du PNJ sont envoyées à un point de terminaison API Gateway de génération augmentée par extraction (RAG).Étape 3
AWS Lambda gère les demandes de texte des PNJ et les envoie aux LLM hébergés sur Amazon Bedrock.Étape 4
Les LLM de base et les LLM personnalisés grâce à un réglage fin fournissent une réponse textuelle générée.Étape 5
La réponse textuelle générée est envoyée à Amazon Polly, qui renvoie à son tour un flux audio de la réponse. Le format audio est renvoyé au PNJ pour être transmis sous forme de dialogue.Étape 6
Pour les requêtes RAG PNJ, Lambda soumet la demande à Amazon Bedrock pour générer une représentation vectorisée à partir du modèle d'intégration. Lambda recherche ensuite les informations pertinentes à partir d'un index vectoriel Amazon OpenSearch Service.Étape 7
OpenSearch Service fournit une fonctionnalité de recherche de similarité afin de fournir un contexte pertinent qui augmente la demande de texte générée en fonction de la représentation vectorisée de la demande provenant d'Amazon Bedrock.
Étape 8
Le contexte pertinent et la demande de texte d'origine sont envoyés aux LLM hébergés sur Amazon Bedrock pour fournir une réponse textuelle générée. Amazon Polly transmet ensuite la réponse au PNJ pour qu'il y ait un dialogue.Étape 9
Les auteurs de récits de jeux ajoutent des données d'entraînement spécifiques au jeu pour créer des modèles personnalisés à l'aide du processus FMOps ou ajoutent des données sur les éléments de l'univers du jeu pour hydrater la base de données vectorielles.
Étape 10
Les ingénieurs de l'infrastructure et du DevOps gèrent l'architecture sous forme de code à l'aide de l'AWS Cloud Development Kit (AWS CDK) et surveillent le guide à l'aide d'Amazon CloudWatch.Étape 1
Les clients du jeu interagissent avec le PNJ qui utilise Unreal Engine Metahuman.
Étape 2
Les demandes de réponses textuelles générées par le PNJ sont envoyées à un point de terminaison d'API de texte Amazon API Gateway. Les requêtes qui nécessitent un contexte spécifique au jeu de la part du PNJ sont envoyées à un point de terminaison API Gateway de génération augmentée par extraction (RAG).Étape 3
AWS Lambda gère les demandes de texte des PNJ et les envoie aux LLM hébergés sur Amazon Bedrock.Étape 4
Les LLM de base et les LLM personnalisés grâce à un réglage fin fournissent une réponse textuelle générée.Étape 5
La réponse textuelle générée est envoyée à Amazon Polly, qui renvoie à son tour un flux audio de la réponse. Le format audio est renvoyé au PNJ pour être transmis sous forme de dialogue.Étape 6
Pour les requêtes RAG PNJ, Lambda soumet la demande à Amazon Bedrock pour générer une représentation vectorisée à partir du modèle d'intégration. Lambda recherche ensuite les informations pertinentes à partir d'un index vectoriel Amazon OpenSearch Service.Étape 7
OpenSearch Service fournit une fonctionnalité de recherche de similarité afin de fournir un contexte pertinent qui augmente la demande de texte générée en fonction de la représentation vectorisée de la demande provenant d'Amazon Bedrock.
Étape 8
Le contexte pertinent et la demande de texte d'origine sont envoyés aux LLM hébergés sur Amazon Bedrock pour fournir une réponse textuelle générée. Amazon Polly transmet ensuite la réponse au PNJ pour qu'il y ait un dialogue.Étape 9
Les auteurs de récits de jeux ajoutent des données d'entraînement spécifiques au jeu pour créer des modèles personnalisés à l'aide du processus FMOps ou ajoutent des données sur les éléments de l'univers du jeu pour hydrater la base de données vectorielles.
Étape 10
Les ingénieurs de l'infrastructure et du DevOps gèrent l'architecture sous forme de code à l'aide de l'AWS Cloud Development Kit (AWS CDK) et surveillent le guide à l'aide d'Amazon CloudWatch. -
Pipeline LLMOps
-
Ce diagramme d'architecture montre les processus de déploiement d'un pipeline LLMOps sur AWS.
Cliquer pour agrandir
Étape 1
Les ingénieurs d'infrastructure créent et testent l'infrastructure codifiée à l'aide d'AWS CDK.
Étape 2
Les mises à jour du code d'infrastructure sont enregistrées dans le référentiel AWS CodeCommit, en invoquant le pipeline d'intégration et de déploiement continus (CI/CD) au sein du compte AWS Toolchain.Étape 3
Les actifs d'infrastructure, tels que les conteneurs Docker et les modèles AWS CloudFormation, sont compilés et stockés dans Amazon Elastic Container Registry (Amazon ECR) et Amazon Simple Storage Service (Amazon S3).Étape 4
L'infrastructure est déployée sur le compte AWS d'assurance qualité (QA) sous forme de pile CloudFormation à des fins d'intégration et de test du système.Étape 5
AWS CodeBuild lance des scripts de test automatisés qui vérifient que l'architecture est fonctionnelle et prête à être déployée en production.Étape 6
Une fois tous les tests des systèmes terminés avec succès, l'infrastructure est automatiquement déployée sous forme de pile CloudFormation dans le compte AWS Production (PROD).
Étape 7
Les ressources du pipeline FMOps sont également déployées sous forme de pile CloudFormation dans le compte PROD AWS.
Étape 1
Les ingénieurs d'infrastructure créent et testent l'infrastructure codifiée à l'aide d'AWS CDK.
Étape 2
Les mises à jour du code d'infrastructure sont enregistrées dans le référentiel AWS CodeCommit, en invoquant le pipeline d'intégration et de déploiement continus (CI/CD) au sein du compte AWS Toolchain.Étape 3
Les actifs d'infrastructure, tels que les conteneurs Docker et les modèles AWS CloudFormation, sont compilés et stockés dans Amazon Elastic Container Registry (Amazon ECR) et Amazon Simple Storage Service (Amazon S3).Étape 4
L'infrastructure est déployée sur le compte AWS d'assurance qualité (QA) sous forme de pile CloudFormation à des fins d'intégration et de test du système.Étape 5
AWS CodeBuild lance des scripts de test automatisés qui vérifient que l'architecture est fonctionnelle et prête à être déployée en production.Étape 6
Une fois tous les tests des systèmes terminés avec succès, l'infrastructure est automatiquement déployée sous forme de pile CloudFormation dans le compte AWS Production (PROD).
Étape 7
Les ressources du pipeline FMOps sont également déployées sous forme de pile CloudFormation dans le compte PROD AWS.
-
Pipeline FMOps
-
Le présent diagramme d'architecture montre le processus de réglage d'un modèle d'IA générative à l'aide de FMOps.
Cliquer pour agrandir
Étape 1
Les documents texte relatifs aux éléments de l'univers du jeu sont chargés dans un compartiment S3.
Étape 2
L'événement de téléchargement de l'objet du document invoque Amazon SageMaker Pipelines.Étape 3
L'étape de prétraitement exécute une tâche de traitement SageMaker pour prétraiter les documents texte à des fins de réglage et d'évaluation du modèle.Étape 4
L'étape de rappel permet à SageMaker Pipelines de s'intégrer à d'autres services AWS en envoyant un message à une file d'attente Amazon Simple Queue Service (Amazon SQS). Après avoir envoyé le message, SageMaker Pipelines attend une réponse de la part de la file d'attente.Étape 5
Amazon SQS gère la file d'attente de messages qui coordonne les tâches entre les SageMaker Pipelines et le flux de travail AWS Step Functions.Étape 6
Le flux de travail Step Functions orchestre le processus d'ajustement du LLM. Une fois qu'un modèle a été affiné, Amazon SQS renvoie un message de réussite à l'étape de rappel de SageMaker Pipelines.
Étape 7
L'étape d'évaluation du modèle exécute une tâche de traitement SageMaker pour évaluer les performances du modèle affiné. Le modèle réglé est enregistré dans le Registre des modèles Amazon SageMaker.Étape 8
Les experts en machine learning (ML) évaluent le modèle optimisé et l'approuvent pour une utilisation en production.Étape 9
Un flux de travail AWS CodePipeline est appelé pour déployer le modèle approuvé en production.Étape 1
Les documents texte relatifs aux éléments de l'univers du jeu sont chargés dans un compartiment S3.
Étape 2
L'événement de téléchargement de l'objet du document invoque Amazon SageMaker Pipelines.Étape 3
L'étape de prétraitement exécute une tâche de traitement SageMaker pour prétraiter les documents texte à des fins de réglage et d'évaluation du modèle.Étape 4
L'étape de rappel permet à SageMaker Pipelines de s'intégrer à d'autres services AWS en envoyant un message à une file d'attente Amazon Simple Queue Service (Amazon SQS). Après avoir envoyé le message, SageMaker Pipelines attend une réponse de la part de la file d'attente.Étape 5
Amazon SQS gère la file d'attente de messages qui coordonne les tâches entre les SageMaker Pipelines et le flux de travail AWS Step Functions.Étape 6
Le flux de travail Step Functions orchestre le processus d'ajustement du LLM. Une fois qu'un modèle a été affiné, Amazon SQS renvoie un message de réussite à l'étape de rappel de SageMaker Pipelines.
Étape 7
L'étape d'évaluation du modèle exécute une tâche de traitement SageMaker pour évaluer les performances du modèle affiné. Le modèle réglé est enregistré dans le Registre des modèles Amazon SageMaker.Étape 8
Les experts en machine learning (ML) évaluent le modèle optimisé et l'approuvent pour une utilisation en production.Étape 9
Un flux de travail AWS CodePipeline est appelé pour déployer le modèle approuvé en production. -
Hydratation de la base de données
-
Ce diagramme d'architecture illustre le processus d'hydratation de la base de données par vectorisation et stockage des éléments de l'univers du joueur pour RAG.
Cliquer pour agrandir
Étape 1
Un scientifique des données télécharge des documents texte relatifs aux éléments de l'univers du jeu dans un compartiment S3.
Étape 2
Le chargement de l'objet appelle une fonction Lambda pour lancer une tâche de traitement SageMaker.
Étape 3
Une tâche de traitement SageMaker télécharge le document texte depuis Amazon S3 et divise le texte en plusieurs parties.
Étape 4
La tâche de traitement SageMaker soumet ensuite chaque bloc de texte à un modèle d'intégration Amazon Titan hébergé sur Amazon Bedrock afin de créer une représentation vectorisée des segments de texte.Étape 5
La tâche de traitement SageMaker intègre ensuite à la fois le bloc de texte et la représentation vectorielle dans OpenSearch Service pour RAG.
Étape 1
Un scientifique des données télécharge des documents texte relatifs aux éléments de l'univers du jeu dans un compartiment S3.
Étape 2
Le chargement de l'objet appelle une fonction Lambda pour lancer une tâche de traitement SageMaker.
Étape 3
Une tâche de traitement SageMaker télécharge le document texte depuis Amazon S3 et divise le texte en plusieurs parties.
Étape 4
La tâche de traitement SageMaker soumet ensuite chaque bloc de texte à un modèle d'intégration Amazon Titan hébergé sur Amazon Bedrock afin de créer une représentation vectorisée des segments de texte.Étape 5
La tâche de traitement SageMaker intègre ensuite à la fois le bloc de texte et la représentation vectorielle dans OpenSearch Service pour RAG.
Piliers AWS Well-Architected
Le cadre AWS Well-Architected vous permet de comprendre les avantages et les inconvénients des décisions que vous prenez lors de la création de systèmes dans le cloud. Les six piliers du cadre vous permettent d'apprendre les bonnes pratiques architecturales pour concevoir et exploiter des systèmes fiables, sécurisés, efficaces, rentables et durables. Grâce à l'outil AWS Well-Architected Tool, disponible gratuitement dans la console de gestion AWS, vous pouvez examiner vos charges de travail par rapport à ces bonnes pratiques en répondant à une série de questions pour chaque pilier.
Le diagramme d'architecture ci-dessus est un exemple de solution créée en tenant compte des bonnes pratiques Well-Architected. Pour être totalement conforme à Well-Architected, vous devez suivre autant de bonnes pratiques Well-Architected que possible.
-
Excellence opérationnelleLire le livre blanc sur l'excellence opérationnelle
Grâce aux technologies AWS X-Ray, Lambda, API Gateway et CloudWatch, ce guide suit toutes les demandes d'API entre le client Unreal Engine Metahuman et Amazon Bedrock FM pour la génération des dialogues des PNJ. Vous bénéficiez ainsi d'une vision globale du fonctionnement du guide, ce qui vous permet d'analyser chaque requête et réponse du client de jeu de manière à identifier rapidement des problèmes et une réaction immédiate pour une expérience de jeu optimale. En outre, le présent guide est codifié en tant qu'application CDK utilisant CodePipeline afin que les équipes opérationnelles et les développeurs puissent corriger les erreurs et les bogues grâce à des méthodologies de contrôle des modifications appropriées et déployer rapidement ces mises à jour ou correctifs à l'aide du pipeline CI/CD.
-
SécuritéLire le livre blanc sur la sécurité
Amazon S3 garantit une protection chiffrée pour le stockage de la documentation sur les éléments de l'univers du jeu et assure le chiffrement des données en transit. De plus, l'intégration de la documentation dans le modèle vectoriel ou le peaufinage d'un modèle Amazon Bedrock FM s'effectue en toute sécurité. API Gateway renforce la sécurité entre Unreal Engine Metahuman et le modèle Amazon Bedrock FM en chiffrant toutes les données échangées entre le PNJ et le modèle grâce au protocole TLS. Enfin, Amazon Bedrock Enfin, Amazon Bedrock intègre des mécanismes automatisés de détection des abus afin d'identifier et d'atténuer davantage les violations des politiques d'AWS en matière d'utilisation acceptable et d'IA responsable.
-
FiabilitéLire le livre blanc sur la fiabilité
API Gateway gère l'autoscaling et la limitation des requêtes du PNJ au FM. De plus, grâce à l'utilisation de pipelines CI/CD, l'infrastructure entière est codifiée, ce qui permet de provisionner des ressources simultanément sur plusieurs comptes et régions AWS. Cette approche facilite la mise en place de scénarios de redéploiement d'infrastructure en cas d'incident au niveau d'une région AWS, garantissant ainsi la continuité de service. En tant que ressources d'infrastructure sans serveur, API Gateway et Lambda vous permettent de vous concentrer sur le développement de jeux au lieu de gérer manuellement l'allocation des ressources et les modèles d'utilisation pour les demandes d'API.
-
Efficacité des performancesLire le livre blanc sur l'efficacité des performances
Les ressources sans serveur, telles que Lambda et API Gateway, contribuent à l'efficacité des performances du guide en fournissant à la fois élasticité et capacité de mise à l'échelle. Le présent guide peut ainsi s'adapter dynamiquement à une augmentation ou à une diminution des appels d'API provenant du client PNJ. Une approche élastique et évolutive vous permet de dimensionner correctement les ressources pour optimiser les performances et faire face à des augmentations ou des baisses imprévues des demandes d'API, sans avoir à gérer manuellement les ressources d'infrastructure provisionnées.
-
Optimisation des coûtsLire le livre blanc sur l'optimisation des coûts
En transformant le guide en une application CDK, les développeurs de jeux vidéo peuvent rapidement prototyper et déployer leurs personnages PNJ en production. Les développeurs peuvent accéder rapidement à Amazon Bedrock FMs à partir d'une API REST API Gateway sans avoir à les concevoir, à les créer et à les former au préalable. La production rapide de prototypes permet de réduire le temps et les coûts d'exploitation associés à la création de FM à partir de rien.
-
Développement durableLire le livre blanc sur le développement durable
Lambda propose une approche sans serveur, évolutive et pilotée par les événements sans avoir à fournir de ressources de calcul dédiées. Avec Amazon S3, l'ensemble des données décrites dans ce guide est soumis à des politiques de cycle de vie et de compression, garantissant un stockage économe en énergie. Amazon Bedrock héberge des modèles de fondation (FM) sur du silicium AWS, offrant ainsi de meilleures performances par watt de ressources de calcul standard.
Ressources d'implémentation
L'exemple de code est un point de départ. Il s'agit d'un document validé par l'industrie, prescriptif mais non définitif, et d'un aperçu pour vous aider à commencer.
Contenu connexe
[Titre]
Avis de non-responsabilité
Les exemples de code, les bibliothèques de logiciels, les outils de ligne de commande, les preuves de concept, les modèles ou toute autre technologie connexe (y compris tout ce qui précède qui est fourni par notre personnel) vous sont fournis en tant que contenu AWS en vertu du contrat client AWS ou de l'accord écrit pertinent entre vous et AWS (selon le cas). Vous ne devez pas utiliser ce contenu AWS dans vos comptes de production, ni sur des données de production ou autres données critiques. Vous êtes responsable des tests, de la sécurisation et de l'optimisation du contenu AWS, tel que les exemples de code, comme il convient pour une utilisation en production, en fonction de vos pratiques et normes de contrôle de qualité spécifiques. Le déploiement de contenu AWS peut entraîner des frais AWS pour la création ou l'utilisation de ressources payantes AWS, telles que l'exécution d'instances Amazon EC2 ou l'utilisation du stockage Amazon S3.
Les références à des services ou organisations tiers dans ce guide n'impliquent pas une approbation, un parrainage ou une affiliation entre Amazon ou AWS et le tiers. Les conseils fournis par AWS constituent un point de départ technique, et vous pouvez personnaliser votre intégration avec des services tiers lorsque vous déployez l'architecture.