[Subtítulo de SEO]
Esta guía ayuda a los desarrolladores de videojuegos a automatizar el proceso de creación de un personaje no jugable (NPC) para sus juegos y la infraestructura asociada. Utiliza Unreal Engine MetaHuman, junto con modelos fundacionales (FM), como los modelos de lenguaje de gran tamaño (LLM) Claude 2 y Llama 2, para mejorar las habilidades conversacionales de los NPC. Esto da lugar a respuestas dinámicas por parte de un NPC que son únicas para cada jugador y se suman a los diálogos guionizados. Al utilizar la metodología de operaciones de modelos de lenguaje de gran tamaño (LLMOps), esta guía acelera la creación de prototipos y el tiempo de entrega al integrar e implementar continuamente la aplicación de IA generativa, además de ajustar los LLM. Todo ello mientras permite garantizar que el NPC tenga acceso total a una base de conocimientos segura sobre la historia del juego.
Esta guía incluye cuatro partes: una arquitectura general, una arquitectura de canalización de LLMOps, una arquitectura de operaciones de modelos fundacionales (FMOps) y una arquitectura de hidratación de bases de datos.
Tenga en cuenta lo siguiente: [Descargo de responsabilidad]
Diagrama de la arquitectura
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
-
Información general
-
Canalización de LLMOps
-
Canalización de FMOps
-
Hidratación de bases de datos
-
Información general
-
En este diagrama de arquitectura, se muestra un flujo de trabajo general para alojar un NPC de IA generativa en AWS.
Paso 1
Los clientes del juego interactúan con el NPC que se ejecuta en Unreal Engine Metahuman.
Paso 2
Las solicitudes de respuestas de texto generadas por el NPC se envían a un punto de conexión de Amazon API Gateway de API de texto. Las solicitudes que requieren un contexto específico para el juego por parte del NPC se envían a un punto de conexión de API Gateway de generación aumentada por recuperación (RAG).Paso 3
AWS Lambda administra las solicitudes de texto del NPC y las envía a los LLM alojados en Amazon Bedrock.Paso 4
Los LLM básicos y los LLM personalizados mediante ajustes precisos generan una respuesta de texto.Paso 5
La respuesta de texto generada se envía a Amazon Polly que, a su vez, devuelve una secuencia de audio de la respuesta. El formato de audio se devuelve al NPC para que lo entregue como diálogo.Paso 6
En el caso de las solicitudes de RAG del NPC, Lambda envía la solicitud a Amazon Bedrock para generar una representación vectorizada a partir del modelo de incrustaciones. A continuación, Lambda busca información relevante en un índice vectorial de Amazon OpenSearch Service.Paso 7
OpenSearch Service brinda una capacidad de búsqueda de similitudes para proporcionar un contexto relevante que aumente la solicitud de texto generada en función de la representación vectorizada de la solicitud de Amazon Bedrock.
Paso 8
El contexto relevante y la solicitud de texto original se envían a los LLM alojados en Amazon Bedrock para generar una respuesta de texto. Amazon Polly luego entrega la respuesta al NPC para que dialogue.Paso 9
Los escritores de la narrativa agregan datos de entrenamiento específicos del juego para crear modelos personalizados mediante el proceso de FMOps o agregan datos de la historia del juego para hidratar la base de datos vectorial.
Paso 10
Los ingenieros de infraestructura y DevOps administran la arquitectura como código con AWS Cloud Development Kit (AWS CDK) y supervisan la guía con Amazon CloudWatch. -
Canalización de LLMOps
-
En este diagrama de arquitectura, se muestran los procesos de implementación de una canalización de LLMOps en AWS.
Paso 1
Los ingenieros de infraestructura crean y prueban la infraestructura codificada con AWS CDK.
Paso 2
Las actualizaciones del código de la infraestructura se envían al repositorio de AWS CodeCommit e invocan el proceso de integración e implementación continuas (CI/CD) dentro de la cuenta de AWS de la cadena de herramientas.Paso 3
Los activos de infraestructura, como los contenedores de Docker y las plantillas de AWS CloudFormation, se compilan y almacenan en Amazon Elastic Container Registry (Amazon ECR) y Amazon Simple Storage Service (Amazon S3).Paso 4
La infraestructura se implementa para la integración y las pruebas del sistema en la cuenta de AWS de garantía de calidad (QA) como una pila de CloudFormation.Paso 5
AWS CodeBuild inicia scripts de prueba automatizados que verifican que la arquitectura es funcional y está lista para su implementación en producción.Paso 6
Tras completar correctamente todas las pruebas del sistema, la infraestructura se implementa automáticamente como una pila de CloudFormation en la cuenta de AWS de producción (PROD).
Paso 7
Los recursos de la canalización de FMOps también se implementan como una pila de CloudFormation en la cuenta de AWS de PROD.
-
Canalización de FMOps
-
En este diagrama de arquitectura, se muestra el proceso de ajuste de un modelo de IA generativa mediante FMOps.
Paso 1
Los documentos de texto sobre la historia del juego se cargan en un bucket de S3.
Paso 2
El evento de carga del objeto del documento invoca a Canalizaciones de Amazon SageMaker.Paso 3
En el paso de procesamiento previo, se ejecuta un trabajo de procesamiento de SageMaker a fin de preprocesar los documentos de texto para el ajuste y la evaluación del modelo.Paso 4
La etapa de devolución de llamada permite a Canalizaciones de Amazon SageMaker integrarse con otros servicios de AWS mediante el envío de un mensaje a una cola de Amazon Simple Queue Service (Amazon SQS). Tras enviar el mensaje, Canalizaciones de Amazon SageMaker espera una respuesta de la cola.Paso 5
Amazon SQS administra la cola de mensajes que coordina las tareas entre Canalizaciones de SageMaker y el flujo de trabajo de AWS Step Functions.Paso 6
El flujo de trabajo de Step Functions organiza el proceso de ajuste del LLM. Una vez que se ha ajustado un modelo, Amazon SQS envía un mensaje de éxito a la etapa de devolución de llamada de Canalizaciones de SageMaker.
Paso 7
El paso de evaluación del modelo ejecuta un trabajo de procesamiento de SageMaker para evaluar el rendimiento del modelo ajustado. El modelo ajustado se almacena en el Registro de modelos de Amazon SageMaker.Paso 8
Los profesionales de machine learning (ML) revisan el modelo ajustado y lo aprueban para su uso en producción.Paso 9
Se invoca un flujo de trabajo de AWS CodePipeline para implementar el modelo aprobado en producción. -
Hidratación de bases de datos
-
En este diagrama de arquitectura, se muestra el proceso de hidratación de la base de datos mediante la vectorización y el almacenamiento de la historia del juego para la RAG.
Paso 1
Un científico de datos carga documentos de texto sobre la historia del juego en un bucket de S3.
Paso 2
La carga del objeto invoca una función de Lambda para iniciar un trabajo de procesamiento de SageMaker.
Paso 3
El trabajo de procesamiento de SageMaker descarga el documento de texto de Amazon S3 y lo divide en varios fragmentos.
Paso 4
A continuación, el trabajo de procesamiento de SageMaker envía cada fragmento de texto a un modelo de incrustaciones de Amazon Titan alojado en Amazon Bedrock para crear una representación vectorizada de los fragmentos de texto.Paso 5
A continuación, mediante el trabajo de procesamiento de SageMaker, se incorporan tanto el fragmento de texto como la representación vectorial en OpenSearch Service para la RAG.
Pilares de Well-Architected
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
AWS Well-Architected Framework le permite comprender las ventajas y desventajas de las decisiones que tome durante la creación de sistemas en la nube. Los seis pilares de este marco permiten aprender las prácticas recomendadas arquitectónicas para diseñar y explotar sistemas confiables, seguros, eficientes, rentables y sostenibles. Con la Herramienta de AWS Well-Architected, que se encuentra disponible gratuitamente en la Consola de administración de AWS, puede revisar sus cargas de trabajo con respecto a estas prácticas recomendadas al responder a un conjunto de preguntas para cada pilar.
El diagrama de arquitectura mencionado es un ejemplo de una solución que se creó teniendo en cuenta las prácticas recomendadas de una buena arquitectura. Para tener completamente una buena arquitectura, debe seguir todas las prácticas recomendadas de buena arquitectura posibles.
-
Excelencia operativa
En esta guía, se utiliza AWS X-Ray, Lambda, API Gateway y CloudWatch para realizar un seguimiento de todas las solicitudes de API relacionadas con el diálogo del NPC generado entre el cliente de Unreal Engine Metahuman y el FM de Amazon Bedrock. Esto proporciona una visibilidad integral del estado de la guía, lo que le permite realizar un seguimiento detallado de cada solicitud y respuesta del cliente del juego para que pueda identificar rápidamente los problemas y actuar en consecuencia. Además, esta guía se codifica como una aplicación de CDK que utiliza CodePipeline para que los equipos de operaciones y los desarrolladores puedan abordar las fallas y los errores mediante las metodologías de control de cambios adecuadas e implementar rápidamente estas actualizaciones o correcciones mediante la canalización de CI/CD.
-
Seguridad
Amazon S3 ofrece protección cifrada para almacenar la documentación de la historia del juego en reposo, además del acceso cifrado a los datos en tránsito, al tiempo que incorpora la documentación de la historia del juego en el vector o ajusta con precisión un FM de Amazon Bedrock. API Gateway agrega una capa adicional de seguridad entre Unreal Engine Metahuman y el FM de Amazon Bedrock al proporcionar un cifrado basado en TLS de todos los datos entre el NPC y el modelo. Por último, Amazon Bedrock implementa mecanismos automatizados de detección de abusos para identificar y mitigar las infracciones de la Política de uso aceptable de AWS y la Política de IA responsable de AWS.
-
Fiabilidad
API Gateway administra el escalado automático y la limitación de las solicitudes del NPC al FM. Además, dado que toda la infraestructura se codifica mediante canalizaciones de CI/CD, puede aprovisionar recursos en varias cuentas de AWS y varias regiones de AWS en paralelo. Esto habilita varios escenarios simultáneos de reimplementación de la infraestructura para ayudar a superar los errores a nivel de región de AWS. Como recursos de infraestructura sin servidor, API Gateway y Lambda le permiten centrarse en el desarrollo de videojuegos en lugar de administrar manualmente los patrones de asignación y uso de recursos para las solicitudes de API.
-
Eficiencia en el rendimiento
Los recursos sin servidor, como Lambda y API Gateway, contribuyen a la eficiencia del rendimiento de la guía, ya que proporcionan elasticidad y escalabilidad. Esto permite que la guía se adapte de forma dinámica a un aumento o disminución de las llamadas a la API desde el cliente de NPC. Un enfoque elástico y escalable le permite ajustar correctamente el tamaño de los recursos para lograr un rendimiento óptimo y abordar los aumentos o disminuciones imprevistos en las solicitudes de API, sin tener que administrar manualmente los recursos de infraestructura aprovisionados.
-
Optimización de costos
La codificación de la guía como una aplicación de CDK brinda a los desarrolladores de juegos la posibilidad de crear prototipos e implementar rápidamente sus NPC en producción. Los desarrolladores obtienen acceso rápido a los FM de Amazon Bedrock a través de una API de REST de API Gateway sin tener que diseñarlos, crearlos ni entrenarlos previamente. La creación rápida de prototipos permite reducir el tiempo y los costos operativos asociados con la creación de FM desde cero.
-
Sostenibilidad
Lambda proporciona un enfoque sin servidor, escalable y basado en eventos sin tener que aprovisionar recursos informáticos dedicados. Amazon S3 implementa políticas de ciclo de vida de los datos junto con la compresión de todos los datos incluidos en esta guía, lo que da lugar a un almacenamiento eficiente desde el punto de vista energético. Amazon Bedrock aloja FM en chips de AWS y, de este modo, ofrece un mejor rendimiento por vatio de recursos informáticos estándar.
Recursos de implementación
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
El código de muestra es un punto de partida. Está validado por el sector, es prescriptivo pero no definitivo, y le permite profundizar en su funcionamiento para que le sea más fácil empezar.
Contenido relacionado
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
[Título]
Descargo de responsabilidad
El código de muestra; las bibliotecas de software; las herramientas de línea de comandos; las pruebas de concepto; las plantillas; o cualquier otra tecnología relacionada (incluida cualquiera de las anteriores que proporcione nuestro personal) se brinda como contenido de AWS bajo el Contrato de cliente de AWS, o el contrato escrito pertinente entre usted y AWS (lo que sea aplicable). No debe utilizar este contenido de AWS en sus cuentas de producción, ni en producción ni en otros datos críticos. Es responsable de probar, proteger y optimizar el contenido de AWS, como el código de muestra, según corresponda para el uso de grado de producción en función de sus prácticas y estándares de control de calidad específicos. La implementación de contenido de AWS puede incurrir en cargos de AWS por crear o utilizar recursos con cargo de AWS, como ejecutar instancias de Amazon EC2 o utilizar el almacenamiento de Amazon S3.
Las referencias a servicios u organizaciones de terceros en esta Guía no implican un respaldo, patrocinio o afiliación entre Amazon o AWS y el tercero. La orientación de AWS es un punto de partida técnico, y puede personalizar su integración con servicios de terceros al implementar la arquitectura.