[Subtítulo para SEO]
Esta Orientação ajuda os desenvolvedores de jogos a automatizar o processo de criação de um personagem não jogável (NPC) para seus jogos e a infraestrutura associada. Ela usa o Unreal Engine MetaHuman, junto com modelos de base (FMs), por exemplo, os grandes modelos de linguagem (LLM) Claude 2 e Llama 2, para melhorar as habilidades de conversação do NPC. Isso leva a respostas dinâmicas do NPC que são exclusivas para cada jogador, adicionando ao diálogo com script. Ao usar a metodologia de operações de grande modelo de linguagem (LLMOps), esta Orientação acelera a prototipagem e o tempo de entrega, integrando e implantando continuamente a aplicação de IA generativa, além de ajustar os LLMs. Tudo isso para ajudar a garantir que o NPC tenha acesso total a uma base de conhecimento segura da lore do jogo.
Esta Orientação inclui quatro partes: uma arquitetura de visão geral, uma arquitetura de pipelines LLMOps, uma arquitetura de operações de modelo de base (FMOps) e uma arquitetura de hidratação de banco de dados.
Observação: [Isenção de responsabilidade]
Diagrama de arquitetura
-
Visão geral
-
Pipeline LLMOps
-
Pipeline FMOps
-
Hidratação do banco de dados
-
Visão geral
-
Este diagrama de arquitetura mostra uma visão geral do fluxo de trabalho para hospedar um NPC de IA generativa na AWS.
Clique para aumentar
Etapa 1
Os clientes do jogo interagem com o NPC em execução no Unreal Engine Metahuman.
Etapa 2
As solicitações de respostas de texto geradas pelo NPC são enviadas para um endpoint de API de texto do Amazon API Gateway. As solicitações que exigem contexto específico do jogo do NPC são enviadas para um endpoint de geração aumentada de recuperação (RAG) do API Gateway.Etapa 3
O AWS Lambda processa as solicitações de texto do NPC e as envia para LLMs hospedados no Amazon Bedrock.Etapa 4
LLMs básicos e LLMs personalizados por meio de ajustes finos fornecem uma resposta de texto gerada.Etapa 5
A resposta de texto gerada é enviada para o Amazon Polly, que, por sua vez, retorna um fluxo de áudio da resposta. O formato de áudio é retornado ao NPC para ser entregue como diálogo.Etapa 6
Para solicitações de RAG NPC, o Lambda envia a solicitação ao Amazon Bedrock para gerar uma representação vetorizada do modelo de incorporação. O Lambda então busca informações relevantes em um índice vetorial do Amazon OpenSearch Service.Etapa 7
O OpenSearch Service fornece um recurso de pesquisa por similaridade para fornecer um contexto relevante que aumenta a solicitação de texto gerada com base na representação vetorizada da solicitação do Amazon Bedrock.
Etapa 8
O contexto relevante e a solicitação de texto original são enviados aos LLMs hospedados no Amazon Bedrock para fornecer uma resposta de texto gerada. O Amazon Polly então entrega a resposta ao NPC para diálogo.Etapa 9
Os escritores de narrativas de jogos adicionam dados de treinamento específicos do jogo para criar modelos personalizados usando o processo de FMOps, ou adicionam dados da lore do jogo para hidratar o banco de dados de vetores.
Etapa 10
Engenheiros de infraestrutura e DevOps gerenciam a arquitetura como código usando o AWS Cloud Development Kit (AWS CDK) e monitoram a Orientação usando o Amazon CloudWatch.Etapa 1
Os clientes do jogo interagem com o NPC em execução no Unreal Engine Metahuman.
Etapa 2
As solicitações de respostas de texto geradas pelo NPC são enviadas para um endpoint de API de texto do Amazon API Gateway. As solicitações que exigem contexto específico do jogo do NPC são enviadas para um endpoint de geração aumentada de recuperação (RAG) do API Gateway.Etapa 3
O AWS Lambda processa as solicitações de texto do NPC e as envia para LLMs hospedados no Amazon Bedrock.Etapa 4
LLMs básicos e LLMs personalizados por meio de ajustes finos fornecem uma resposta de texto gerada.Etapa 5
A resposta de texto gerada é enviada para o Amazon Polly, que, por sua vez, retorna um fluxo de áudio da resposta. O formato de áudio é retornado ao NPC para ser entregue como diálogo.Etapa 6
Para solicitações de RAG NPC, o Lambda envia a solicitação ao Amazon Bedrock para gerar uma representação vetorizada do modelo de incorporação. O Lambda então busca informações relevantes em um índice vetorial do Amazon OpenSearch Service.Etapa 7
O OpenSearch Service fornece um recurso de pesquisa por similaridade para fornecer um contexto relevante que aumenta a solicitação de texto gerada com base na representação vetorizada da solicitação do Amazon Bedrock.
Etapa 8
O contexto relevante e a solicitação de texto original são enviados aos LLMs hospedados no Amazon Bedrock para fornecer uma resposta de texto gerada. O Amazon Polly então entrega a resposta ao NPC para diálogo.Etapa 9
Os escritores de narrativas de jogos adicionam dados de treinamento específicos do jogo para criar modelos personalizados usando o processo de FMOps, ou adicionam dados da lore do jogo para hidratar o banco de dados de vetores.
Etapa 10
Engenheiros de infraestrutura e DevOps gerenciam a arquitetura como código usando o AWS Cloud Development Kit (AWS CDK) e monitoram a Orientação usando o Amazon CloudWatch. -
Pipeline LLMOps
-
Este diagrama de arquitetura mostra os processos de implantação de um pipeline LLMOps na AWS.
Clique para aumentar
Etapa 1
Engenheiros de infraestrutura criam e testam a infraestrutura codificada usando o AWS CDK.
Etapa 2
As atualizações do código de infraestrutura são confirmadas no repositório do AWS CodeCommit, invocando o pipeline de integração e implantação contínuas (CI/CD) na conta de cadeia de ferramentas da AWS.Etapa 3
Os ativos de infraestrutura, como contêineres do Docker e modelos do AWS CloudFormation, são compilados e armazenados no Amazon Elastic Container Registry (Amazon ECR) e no Amazon Simple Storage Service (Amazon S3).Etapa 4
A infraestrutura é implantada na conta de garantia de qualidade (QA) da AWS como uma pilha do CloudFormation para integração e teste do sistema.Etapa 5
O AWS CodeBuild inicia scripts de teste automatizados que verificam se a arquitetura está funcional e pronta para implantação de produção.Etapa 6
Após a conclusão bem-sucedida de todos os testes do sistema, a infraestrutura é automaticamente implantada como uma pilha do CloudFormation na conta de produção (PROD) da AWS.
Etapa 7
Os recursos do pipeline FMOps também são implantados como uma pilha do CloudFormation na conta de PROD da AWS.
Etapa 1
Engenheiros de infraestrutura criam e testam a infraestrutura codificada usando o AWS CDK.
Etapa 2
As atualizações do código de infraestrutura são confirmadas no repositório do AWS CodeCommit, invocando o pipeline de integração e implantação contínuas (CI/CD) na conta de cadeia de ferramentas da AWS.Etapa 3
Os ativos de infraestrutura, como contêineres do Docker e modelos do AWS CloudFormation, são compilados e armazenados no Amazon Elastic Container Registry (Amazon ECR) e no Amazon Simple Storage Service (Amazon S3).Etapa 4
A infraestrutura é implantada na conta de garantia de qualidade (QA) da AWS como uma pilha do CloudFormation para integração e teste do sistema.Etapa 5
O AWS CodeBuild inicia scripts de teste automatizados que verificam se a arquitetura está funcional e pronta para implantação de produção.Etapa 6
Após a conclusão bem-sucedida de todos os testes do sistema, a infraestrutura é automaticamente implantada como uma pilha do CloudFormation na conta de produção (PROD) da AWS.
Etapa 7
Os recursos do pipeline FMOps também são implantados como uma pilha do CloudFormation na conta de PROD da AWS.
-
Pipeline FMOps
-
Este diagrama de arquitetura mostra o processo de ajuste de um modelo de IA generativa usando FMOps.
Clique para aumentar
Etapa 1
Os documentos de texto da lore do jogo são enviados para um bucket do S3.
Etapa 2
O evento de upload do objeto do documento invoca o Amazon SageMaker Pipelines.Etapa 3
A etapa de pré-processamento executa um trabalho de processamento do SageMaker para pré-processar os documentos de texto para ajuste e avaliação do modelo.Etapa 4
A etapa de retorno de chamada permite que o SageMaker Pipelines se integre a outros serviços da AWS enviando uma mensagem para uma fila do Amazon Simple Queue Service (Amazon SQS). Depois de enviar a mensagem, o SageMaker Pipelines espera por uma resposta da fila.Etapa 5
O Amazon SQS gerencia a fila de mensagens que coordena as tarefas entre o fluxo de trabalho do SageMaker Pipelines e do AWS Step Functions.Etapa 6
O fluxo de trabalho do Step Functions orquestra o processo de ajuste fino do LLM. Depois que um modelo é ajustado, o Amazon SQS envia uma mensagem de êxito de volta para a etapa de retorno de chamada do SageMaker Pipelines.
Etapa 7
A etapa de avaliação do modelo executa um trabalho de processamento do SageMaker para avaliar a performance do modelo ajustado. O modelo ajustado é armazenado no Registro de Modelos do Amazon SageMaker.Etapa 8
Os profissionais de machine learning (ML) analisam o modelo ajustado e o aprovam para uso em produção.Etapa 9
Um fluxo de trabalho do AWS CodePipeline é invocado para implantar o modelo aprovado na produção.Etapa 1
Os documentos de texto da lore do jogo são enviados para um bucket do S3.
Etapa 2
O evento de upload do objeto do documento invoca o Amazon SageMaker Pipelines.Etapa 3
A etapa de pré-processamento executa um trabalho de processamento do SageMaker para pré-processar os documentos de texto para ajuste e avaliação do modelo.Etapa 4
A etapa de retorno de chamada permite que o SageMaker Pipelines se integre a outros serviços da AWS enviando uma mensagem para uma fila do Amazon Simple Queue Service (Amazon SQS). Depois de enviar a mensagem, o SageMaker Pipelines espera por uma resposta da fila.Etapa 5
O Amazon SQS gerencia a fila de mensagens que coordena as tarefas entre o fluxo de trabalho do SageMaker Pipelines e do AWS Step Functions.Etapa 6
O fluxo de trabalho do Step Functions orquestra o processo de ajuste fino do LLM. Depois que um modelo é ajustado, o Amazon SQS envia uma mensagem de êxito de volta para a etapa de retorno de chamada do SageMaker Pipelines.
Etapa 7
A etapa de avaliação do modelo executa um trabalho de processamento do SageMaker para avaliar a performance do modelo ajustado. O modelo ajustado é armazenado no Registro de Modelos do Amazon SageMaker.Etapa 8
Os profissionais de machine learning (ML) analisam o modelo ajustado e o aprovam para uso em produção.Etapa 9
Um fluxo de trabalho do AWS CodePipeline é invocado para implantar o modelo aprovado na produção. -
Hidratação do banco de dados
-
Este diagrama de arquitetura mostra o processo de hidratação do banco de dados vetorizando e armazenando a lore dos jogadores para o RAG.
Clique para aumentar
Etapa 1
Um cientista de dados faz o upload dos documentos de texto da lore do jogo em um bucket do S3.
Etapa 2
O upload do objeto invoca uma função do Lambda para iniciar um trabalho de processamento do SageMaker.
Etapa 3
Um trabalho de processamento do SageMaker faz download do documento de texto do Amazon S3 e divide o texto em vários blocos.
Etapa 4
Depois, o trabalho de processamento do SageMaker envia cada bloco de texto para um modelo de incorporação do Amazon Titan hospedado no Amazon Bedrock para criar uma representação vetorizada dos blocos de texto.Etapa 5
Em seguida, o trabalho de processamento do SageMaker ingere o bloco de texto e a representação de vetores no OpenSearch Service para RAG.
Etapa 1
Um cientista de dados faz o upload dos documentos de texto da lore do jogo em um bucket do S3.
Etapa 2
O upload do objeto invoca uma função do Lambda para iniciar um trabalho de processamento do SageMaker.
Etapa 3
Um trabalho de processamento do SageMaker faz download do documento de texto do Amazon S3 e divide o texto em vários blocos.
Etapa 4
Depois, o trabalho de processamento do SageMaker envia cada bloco de texto para um modelo de incorporação do Amazon Titan hospedado no Amazon Bedrock para criar uma representação vetorizada dos blocos de texto.Etapa 5
Em seguida, o trabalho de processamento do SageMaker ingere o bloco de texto e a representação de vetores no OpenSearch Service para RAG.
Pilares do Well-Architected
O AWS Well-Architected Framework ajuda a entender as vantagens e as desvantagens das decisões tomadas durante a criação de sistemas na nuvem. Os seis pilares do Framework permitem que você aprenda as melhores práticas de arquitetura, a fim de projetar e operar sistemas confiáveis, seguros, eficientes, econômicos e sustentáveis. Com a Ferramenta AWS Well-Architected, disponível gratuitamente no Console de Gerenciamento da AWS, você pode avaliar suas workloads em relação às práticas recomendadas ao responder a uma série de questões para cada pilar.
O diagrama de arquitetura acima exemplifica a criação de uma solução pautada nas melhores práticas do Well-Architected. Para ser totalmente Well-Architected, é preciso respeitar a maior quantidade possível das melhores práticas desse framework.
-
Excelência operacionalLeia o whitepaper sobre excelência operacional
Esta Orientação usa o AWS X-Ray, o Lambda, o API Gateway e o CloudWatch para rastrear todas as solicitações de API para o diálogo de NPC gerado entre o cliente do Unreal Engine Metahuman e o FM do Amazon Bedrock. Isso fornece visibilidade de ponta a ponta do status da Orientação, permitindo que você rastreie de maneira granular cada solicitação e resposta do cliente do jogo para que você possa identificar rapidamente os problemas e reagir de acordo. Além disso, esta Orientação é codificada como um aplicação do CDK usando o CodePipeline para que as equipes de operações e os desenvolvedores possam solucionar falhas e bugs por meio de metodologias apropriadas de controle de alterações e implantar rapidamente essas atualizações ou correções usando o pipeline de CI/CD.
-
SegurançaLeia o whitepaper sobre segurança
O Amazon S3 fornece proteção criptografada para armazenar a documentação da lore do jogo em repouso, além do acesso criptografado aos dados em trânsito, enquanto ingere a documentação da lore do jogo no vetor ou faz o ajuste fino de um FM do Amazon Bedrock. O API Gateway adiciona uma camada adicional de segurança entre o Unreal Engine Metahuman e o FM do Amazon Bedrock ao fornecer criptografia baseada em TLS de todos os dados entre o NPC e o modelo. Por fim, o Amazon Bedrock implementa mecanismos automatizados de detecção de abuso para identificar e mitigar ainda mais as violações da Política de uso aceitável da AWS e da Política de IA responsável da AWS.
-
ConfiabilidadeLeia o whitepaper sobre confiabilidade
O API Gateway gerencia o controle de utilização e o ajuste de escala automático automatizados de solicitações do NPC para o FM. Além disso, como toda a infraestrutura é codificada usando pipelines de CI/CD, você pode provisionar recursos em várias contas e regiões da AWS em paralelo. Isso permite vários cenários simultâneos de reimplantação de infraestrutura para ajudar você a superar falhas na região da AWS. Como recursos de infraestrutura sem servidor, o API Gateway e o Lambda permitem que você se concentre no desenvolvimento de jogos em vez de no gerenciamento manual de alocação de recursos e dos padrões de uso para solicitações de API.
-
Eficiência de performanceLeia o whitepaper sobre eficiência da performance
Recursos sem servidor, como o Lambda e o API Gateway, contribuem para a eficiência da performance da Orientação, fornecendo elasticidade e escalabilidade. Isso permite que a Orientação se adapte dinamicamente a um aumento ou uma diminuição nas chamadas de API do cliente NPC. Uma abordagem elástica e escalável ajuda você a dimensionar corretamente os recursos para otimizar a performance e lidar com reduções ou aumentos imprevistos nas solicitações de API, sem precisar gerenciar manualmente os recursos de infraestrutura provisionados.
-
Otimização de custosLeia o whitepaper sobre otimização de custos
A codificação da Orientação como uma aplicação do CDK oferece aos desenvolvedores de jogos a capacidade de criar protótipos e implantar rapidamente seus personagens NPC na produção. Os desenvolvedores obtêm acesso rápido aos FMs do Amazon Bedrock por meio de uma API REST do API Gateway sem precisar projetar, criar e pré-treiná-los. A entrega rápida de protótipos ajuda a reduzir o tempo e os custos operacionais associados à criação de FMs do zero.
-
SustentabilidadeLeia o whitepaper sobre sustentabilidade
O Lambda fornece uma abordagem de tecnologia sem servidor, escalável e orientada a eventos sem precisar provisionar recursos de computação dedicados. O Amazon S3 implementa políticas de ciclo de vida de dados junto com a compressão de todos os dados nesta Orientação, permitindo um armazenamento energeticamente eficiente. O Amazon Bedrock hospeda FMs no chip da AWS, oferecendo melhor performance por watt de recursos computacionais padrão.
Recursos de implementação
O código de amostra é um ponto de partida. Ele é validado para o setor, é prescritivo, mas não definitivo, e mostra o que há por trás de tudo para ajudar você a começar.
Conteúdo relacionado
[Título]
Aviso de isenção de responsabilidade
O código de exemplo, as bibliotecas de software, as ferramentas de linha de comando, as provas de conceito, os modelos ou outra tecnologia relacionada (incluindo qualquer uma das anteriores fornecidas por nossa equipe) são fornecidos a você como Conteúdo da AWS nos termos do Contrato de Cliente da AWS ou o contrato por escrito pertinente entre você e a AWS (o que for aplicável). Você não deve usar esse Conteúdo da AWS em suas contas de produção, na produção ou em outros dados essenciais. Você é responsável por testar, proteger e otimizar o Conteúdo da AWS, como código de exemplo, conforme apropriado para uso em nível de produção com base em suas práticas e padrões específicos de controle de qualidade. A implantação de Conteúdo da AWS pode gerar cobranças da AWS para criar ou usar recursos cobráveis, como executar instâncias do Amazon EC2 ou usar armazenamento do Amazon S3.
As referências a serviços ou organizações terceirizadas nesta orientação não implicam em endosso, patrocínio ou afiliação entre a Amazon ou a AWS e terceiros. A orientação da AWS é um ponto de partida técnico, e você pode personalizar sua integração com serviços de terceiros ao implantar a arquitetura.