[Sottotitolo SEO]
Questa Guida aiuta gli sviluppatori di giochi ad automatizzare il processo di creazione di un personaggio non giocante (NPC) per i proprio giochi e l'infrastruttura associata. Utilizza Unreal Engine MetaHuman, insieme ai modelli di fondazione (FM), ad esempio i modelli linguistici di grandi dimensioni (LLM) Claude 2 e Llama 2, per migliorare le capacità di conversazione degli NPC. Ciò porta a risposte dinamiche da parte dell'NPC uniche per ogni giocatore, che si aggiungono ai dialoghi programmati. Utilizzando la metodologia per la gestione operativa dei modelli linguistici di grandi dimensioni (LLMOps), questa Guida accelera la prototipazione e i tempi di consegna integrando e implementando continuamente l'applicazione di IA generativa, insieme alla messa a punto degli LLM. Il tutto contribuendo a garantire che l'NPC abbia pieno accesso a una base di conoscenza sicura della narrativa del gioco.
Questa Guida include quattro parti: un'architettura panoramica, un'architettura di pipeline LLMOps, un'architettura delle operazioni dei modelli di fondazione (FMOps) e un'architettura di idratazione del database.
Nota: [Disclaimer]
Diagramma dell'architettura
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
-
Panoramica
-
Pipeline LLMOps
-
Pipeline FMOps
-
Idratazione del database
-
Panoramica
-
Questo diagramma di architettura mostra una panoramica del flusso di lavoro per l'hosting di un NPC di IA generativa su AWS.
Fase 1
I client di gioco interagiscono con l'NPC in esecuzione sull'Unreal Engine MetaHuman.
Fase 2
Le richieste di risposte testuali generate dall'NPC vengono inviate a un endpoint Gateway Amazon API di API di testo. Le richieste che necessitano di un contesto specifico del gioco da parte dell'NPC vengono inviate a un endpoint Gateway APIdi Retrieval Augmented Generation (RAG).Fase 3
AWS Lambda gestisce le richieste NPC di testo e le invia a LLM ospitati su Amazon Bedrock.Fase 4
Gli LLM di base e gli LLM personalizzati tramite ottimizzazione forniscono una risposta testuale generata.Fase 5
La risposta testuale generata viene inviata ad Amazon Polly, che a sua volta restituisce un flusso audio della risposta. Il formato audio viene restituito all'NPC per essere consegnato come dialogo.Fase 6
Per le richieste RAG NPC, Lambda invia la richiesta ad Amazon Bedrock per generare una rappresentazione vettoriale a partire dal modello di incorporamento. Lambda cerca, quindi, le informazioni pertinenti da un indice vettoriale del Servizio OpenSearch di Amazon.Fase 7
Servizio OpenSearch fornisce una funzionalità di ricerca per similarità per fornire un contesto pertinente che aumenta la richiesta di testo generata in base alla rappresentazione vettoriale della richiesta di Amazon Bedrock.
Fase 8
Il contesto pertinente e la richiesta di testo originale vengono inviati agli LLM ospitati su Amazon Bedrock per fornire una risposta testuale generata. Amazon Polly fornisce, dunque, la risposta all'NPC per il dialogo.Fase 9
Gli autori della narrativa del gioco aggiungono dati di addestramento specifici per creare modelli personalizzati con il processo FMOps o aggiungono dati sulla narrativa del gioco per idratare il database vettoriale.
Fase 10
Gli ingegneri dell'infrastruttura e DevOps gestiscono l'architettura come codice utilizzando il Kit di sviluppo per il cloud AWS (AWS CDK) e monitorano la Guida utilizzando Amazon CloudWatch. -
Pipeline LLMOps
-
Questo diagramma di architettura mostra i processi di implementazione di una pipeline LLMOps su AWS.
Fase 1
Gli ingegneri dell'infrastruttura creano e testano l'infrastruttura codificata utilizzando AWS CDK.
Fase 2
Gli aggiornamenti al codice dell'infrastruttura vengono salvati nel repository AWS CodeCommit, richiamando la pipeline di integrazione continua e di implementazione continua (CI/CD) all'interno dell'account AWS Toolchain.Fase 3
Le risorse dell'infrastruttura, come i contenitori Docker e i modelli AWS CloudFormation, vengono compilate e archiviate in Amazon Elastic Container Registry (Amazon ECR) e Amazon Simple Storage Service (Amazon S3).Fase 4
L'infrastruttura viene implementata nell'account AWS di controllo qualità (QA) come stack di CloudFormation per l'integrazione e il test di sistema.Fase 5
AWS CodeBuild avvia script di test automatici che verificano che l'architettura sia funzionale e pronta per l'implementazione in produzione.Fase 6
Una volta completati con successo tutti i test di sistema, l'infrastruttura viene automaticamente implementata come stack CloudFormation nell'account AWS di produzione (PROD).
Fase 7
Anche le risorse della pipeline FMOps vengono implementate come stack CloudFormation nell'account AWS PROD.
-
Pipeline FMOps
-
Questo diagramma di architettura mostra il processo di ottimizzazione di un modello di IA generativa utilizzando FMOps.
Fase 1
I documenti di testo relativi alla narrativa del gioco vengono caricati in un bucket S3.
Fase 2
L'evento di caricamento dell'oggetto del documento richiama le Pipeline Amazon SageMaker.Fase 3
La fase di pre-elaborazione esegue un processo di elaborazione SageMaker per pre-elaborare i documenti di testo per l'ottimizzazione e la valutazione del modello.Fase 4
La fase di chiamata consente a Pipeline SageMaker di integrarsi con altri servizi AWS inviando un messaggio a una coda Amazon Simple Queue Service(Amazon SQS). Dopo aver inviato il messaggio, Pipeline SageMaker attende una risposta dalla coda.Fase 5
Amazon SQS gestisce la coda di messaggi che coordina le attività tra le Pipeline SageMaker e il flusso di lavoro di AWS Step Functions.Fase 6
Il flusso di lavoro Step Functions orchestra il processo di ottimizzazione dell'LLM. Una volta che l'ottimizzazione del modello è stata completata, Amazon SQS invia un messaggio di successo alla fase di chiamata di Pipeline SageMaker.
Fase 7
La fase di valutazione del modello esegue un processo di elaborazione SageMaker per valutare le prestazioni del modello ottimizzato. Il modello ottimizzato è memorizzato nel registro dei modelli Amazon SageMaker.Fase 8
I professionisti del machine learning (ML) esaminano il modello ottimizzato e lo approvano per l'uso in produzione.Fase 9
Viene richiamato un flusso di lavoro AWS CodePipeline per implementare il modello approvato in produzione. -
Idratazione del database
-
Questo diagramma di architettura mostra il processo di idratazione del database vettorializzando e archiviando la narrativa dei giocatori per la RAG.
Fase 1
Un data scientist carica documenti di testo relativi alla narrativa del gioco in un bucket S3.
Fase 2
Il caricamento dell'oggetto richiama una funzione Lambda per avviare un processo di elaborazione SageMaker.
Fase 3
Un processo di elaborazione SageMaker scarica il documento di testo da Amazon S3 e lo divide in più blocchi.
Fase 4
Il processo di elaborazione SageMaker invia, quindi, ogni blocco di testo a un modello di incorporamento di Amazon Titan ospitato su Amazon Bedrock per creare una rappresentazione vettoriale dei blocchi di testo.Fase 5
Successivamente, il processo di elaborazione SageMaker inserisce sia il blocco di testo sia la rappresentazione vettoriale nel Servizio OpenSearch per RAG.
Principi di Well-Architected
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
Il framework AWS Well-Architected consente di valutare i pro e i contro delle decisioni prese durante il processo di creazione di sistemi nel cloud. I sei principi del framework consentono di apprendere le best practice architetturali per la progettazione e il funzionamento di sistemi affidabili, sicuri, efficienti, convenienti e sostenibili. Grazie allo strumento AWS Well-Architected, disponibile gratuitamente nella Console di gestione AWS, puoi rivedere i tuoi carichi di lavoro rispetto a queste best practice rispondendo a una serie di domande per ciascun principio.
Il diagramma dell'architettura sopra riportato è un esempio di una soluzione creata tenendo conto delle best practice Well-Architected. Per essere completamente Well-Architected, dovresti seguire il maggior numero possibile di best practice.
-
Eccellenza operativa
Questa Guida utilizza AWS X-Ray, Lambda, Gateway API e CloudWatch per tracciare tutte le richieste API per il dialogo NPC generato tra il client di Unreal Engine MetaHuman e il FM di Amazon Bedrock. Ciò fornisce una visibilità completa sullo stato della Guida, consentendoti di tracciare in modo granulare ogni richiesta e risposta dal client di gioco in modo da poter identificare rapidamente i problemi e agire di conseguenza. Inoltre, questa Guida è codificata come applicazione CDK utilizzando CodePipeline in modo che i team operativi e gli sviluppatori possano risolvere errori e bug attraverso appropriate metodologie di controllo delle modifiche e implementare rapidamente questi aggiornamenti o correzioni utilizzando la pipeline CI/CD.
-
Sicurezza
Amazon S3 fornisce una protezione crittografata per l'archiviazione della documentazione relativa alla narrativa dei giochi inattiva, oltre all'accesso crittografato per i dati in transito, mentre inserisce la documentazione relativa all'universo narrativo del gioco nel vettore o ottimizza un FM di Amazon Bedrock. Gateway API aggiunge un ulteriore livello di sicurezza tra Unreal Engine MetaHuman e il FM di Amazon Bedrock fornendo la crittografia basata su TLS di tutti i dati tra l'NPC e il modello. Infine, Amazon Bedrock implementa meccanismi automatici di rilevamento degli abusi per identificare ulteriormente e mitigare le violazioni della Politica di utilizzo accettabile di AWS e della Politica di IA responsabile di AWS.
-
Affidabilità
Gateway API gestisce il dimensionamento automatico e la limitazione delle richieste dell'NPC nel FM. Inoltre, poiché l'intera infrastruttura è codificata utilizzando pipeline CI/CD, è possibile effettuare il provisioning delle risorse su più account AWS e più regioni AWS in parallelo. Ciò consente vari scenari di re-implementazione simultanea dell'infrastruttura per aiutarti a superare i guasti a livello di regione AWS. Essendo risorse infrastrutturali serverless, Gateway API e Lambda consentono di concentrarsi sullo sviluppo di giochi anziché gestire manualmente l'allocazione delle risorse e i modelli di utilizzo per le richieste API.
-
Efficienza delle prestazioni
Le risorse serverless, come Lambda e Gateway API, contribuiscono all'efficienza prestazionale della Guida fornendo elasticità e scalabilità. La Guida si adatta, pertanto, dinamicamente all'aumento o alla diminuzione delle chiamate API dal client NPC. Un approccio elastico e scalabile consente di dimensionare correttamente le risorse per ottenere prestazioni ottimali e affrontare aumenti o diminuzioni imprevisti delle richieste API, senza dover gestire manualmente le risorse dell'infrastruttura predisposte.
-
Ottimizzazione dei costi
La codifica della Guida come applicazione CDK offre agli sviluppatori di giochi la possibilità di prototipare e implementare rapidamente i propri personaggi NPC in produzione. Gli sviluppatori possono accedere rapidamente ai FM di Amazon Bedrock tramite una REST API di Gateway API senza doverli progettare, creare e pre-addestrare. La realizzazione di prototipi rapidi aiuta a ridurre i tempi e i costi operativi associati alla creazione di FM da zero.
-
Sostenibilità
Lambda fornisce un approccio serverless, scalabile e basato sugli eventi senza dover fornire risorse di elaborazione dedicate. Amazon S3 implementa policy sul ciclo di vita dei dati insieme alla compressione per tutti i dati in questa Guida, consentendo uno storage efficiente dal punto di vista energetico. Amazon Bedrock ospita FM su processore AWS, offrendo migliori prestazioni per watt di risorse di calcolo standard.
Risorse per l'implementazione
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
Il codice di esempio è un punto di partenza. È convalidato dal settore, prescrittivo ma non definitivo, ed è il punto di partenza per iniziare a lavorare.
Contenuti correlati
![](https://d1.awsstatic.com/apac/events/2021/aws-innovate-aiml/2022/eng/innovate-aiml-22-UI_Gradient-Divider.082bb46e8d9654e48f62bf018e131dd8ec563c4e.jpg)
[Titolo]
Avvertenza
Il codice di esempio, le librerie software, gli strumenti della linea di comando, le proof of concept, i modelli e le altre tecnologie correlate (comprese tutte le tecnologie di cui sopra fornite dal nostro personale) vengono forniti all'utente sotto forma di contenuto AWS ai sensi dell'Accordo cliente AWS o del relativo accordo scritto stipulato tra l'utente e AWS (a seconda dei casi). Non bisogna utilizzare il contenuto AWS in questione negli account di produzione o sui dati di produzione o altri dati fondamentali. L'utente è responsabile dei test, della sicurezza e dell'ottimizzazione del contenuto AWS, come il codice di esempio, in modo appropriato per l'utilizzo in produzione sulla base delle pratiche e degli standard di qualità specifici. L'implementazione del contenuto AWS può comportare costi AWS per la creazione o l'utilizzo di risorse AWS addebitabili, quali le istanze Amazon EC2 in esecuzione o l'archiviazione Amazon S3.
Eventuali riferimenti a servizi o organizzazioni di terze parti contenuti in questa guida non implicano alcuna approvazione, sponsorizzazione o affiliazione tra Amazon o AWS e dette terze parti. La guida di AWS è un punto di partenza tecnico e l'integrazione con servizi di terze parti può essere personalizzata al momento dell'implementazione dell'architettura.