Implementando uma aplicação de geração de histórias serverless baseado em eventos com ChatGPT e DALL-E

Todas as noites, na hora de dormir, o agendador serverless aciona o aplicativo, iniciando um fluxo de trabalho orientado por eventos para criar e armazenar novas histórias exclusivas geradas por IA com imagens e áudios geradas por IA.

Esses conjuntos de dados são usados para mostrar a história em um site customizado criado com o Next.js hospedado com o AWS App Runner. Depois que a história é criada, uma notificação é enviada ao usuário contendo uma URL para visualizar e ler a história para as crianças.

O aplicativo mencionado nesta postagem do blog demonstra exemplos de mensagens ponto a ponto com Amazon EventBridge Pipes, padrões de publicação/subscrição com o Amazon EventBridge e reação a eventos de captura de dados alterados com o DynamoDB Streams.

Entendendo a arquitetura

A imagem a seguir mostra a arquitetura serverless usada para gerar histórias:

Uma nova história infantil é gerada todos os dias no horário configurado usando o Amazon EventBridge Scheduler (Etapa 1). O EventBridge Scheduler é um serviço capaz de escalar milhões de agendamentos com mais de 200 destinos e mais de 6000 chamadas de API. Este aplicativo de exemplo usa o EventBridge Scheduler para acionar uma função do AWS Lambda todas as noites no mesmo horário (19h15). A função Lambda é acionada para iniciar a geração da história.

As tabelas “Scenes” e “Characters” do Amazon DynamoDB contêm os personagens envolvidos na história e uma cena que é selecionada aleatoriamente durante sua criação. Como resultado, o ChatGPT recebe uma solicitação exclusiva a cada vez. Um exemplo do prompt pode ter a seguinte aparência:

“`
Escreva um título e uma história rimada sobre dois personagens principais chamados Parker e Jackson. A história precisa ser ambientada em uma cena de floresta assombrada e ter pelo menos 200 palavras

“`

Depois que a história é criada, ela é salva na tabela “Histórias” do DynamoDB (Etapa 2).

Depois que a história é criada, isso inicia um evento de captura de dados de alteração usando o DynamoDB Streams (Etapa 3). Esse evento flui por meio de mensagens ponto a ponto com EventBridge Pipes e diretamente para o EventBridge. As transformações de entrada são então usadas para converter o evento do DynamoDB Stream em um evento EventBridge personalizado, que os consumidores posteriores podem compreender. Adotar esse padrão é benéfico, pois nos permite separar os contratos do esquema de eventos do DynamoDB e não fazer com que os consumidores downstream estejam em conformidade com essa estrutura de esquema. Esse mapeamento nos permite permanecer separados dos detalhes da implementação.

Ao acionar o evento StoryCreated no EventBridge, três alvos são acionados para realizar vários processos (Etapa 4). Primeiro, as imagens de IA são processadas, seguidas pela criação do áudio para a história. Por fim, o usuário final é notificado sobre a história concluída por meio do Amazon SNS e de subscrições de e-mail. Esse padrão de distribuição permite que essas tarefas sejam executadas de forma assíncrona e paralelas, permitindo tempos de processamento mais rápidos.

Um tópico do SNS é acionado pelo evento `storyCreated` para enviar um e-mail ao usuário final usando subscrições de e-mail (Etapa 6). O e-mail consiste em um URL com o ID da história que foi criada. Clicar na URL leva o usuário ao aplicativo de front-end hospedado com o App Runner.

Amazon Polly é usado para gerar os arquivos de áudio para a história (Etapa 6). Ao acionar o evento `StoryCreated`, uma função Lambda é acionada e a descrição da história é usada e fornecida ao Amazon Polly. Em seguida, o Amazon Polly cria um arquivo de áudio da história, que é armazenado no Amazon S3. Uma URL pré-assinada é gerada e salva no DynamoDB em relação à história criada. Isso permite que o aplicativo de front-end e o navegador recuperem o arquivo de áudio quando o usuário visualiza a página. A URL pré-assinada tem validade de dois dias, após os quais não pode mais ser acessada ou escutada.

O evento `StoryCreated` também aciona outra função Lambda, que usa a API OpenAI para gerar uma imagem de IA usando DALL-E com base na história gerada (Etapa 7). Depois que a imagem é gerada, ela é baixada e armazenada no Amazon S3. Semelhante ao arquivo de áudio, o sistema gera uma URL pré-assinada para a imagem e a salva no DynamoDB com base na história. O URL pré-assinado só é válido por dois dias, após o qual se torna inacessível para download ou visualização.

No caso de uma falha na geração de áudio ou imagem, o aplicativo de front-end ainda carrega a história, mas não exibe a imagem ou o áudio ausentes naquele momento. Isso garante que o front-end possa continuar funcionando e fornecer valor. Se você quiser ter mais controle e acionar o evento de notificação do usuário somente quando todas as tarefas paralelas forem concluídas, o padrão de mensagens do agregador pode ser considerado.

Hospedagem do aplicativo front-end Next.js com o AWS App Runner

Next.js é usado pelo aplicativo de front-end para renderizar páginas renderizadas do lado do servidor (SSR) que podem acessar as histórias da tabela do DynamoDB, que são hospedadas no AWS App Runner após serem conteinerizadas.

O AWS App Runner permite que você implante aplicativos web e APIs em contêineres com segurança, sem precisar de nenhum conhecimento prévio sobre contêineres ou infraestrutura. Com o App Runner, os desenvolvedores podem se concentrar em seus aplicativos, enquanto o serviço gerencia a inicialização, a execução, o escalonamento e o balanceamento de carga do contêiner. Após a implantação, o App Runner fornece uma URL segura para os clientes começarem a fazer solicitações HTTP.

Com o App Runner, você tem duas opções principais para implantar seu contêiner: conexões de código-fonte ou imagens de origem. O uso de conexões de código-fonte concede ao App Runner permissão para extrair o arquivo de imagem diretamente do código-fonte e, com a implantação automática configurada, ele pode reimplantar o aplicativo quando as alterações são feitas. Como alternativa, as imagens de origem fornecem ao App Runner a localização da imagem em um registro de imagem, e essa imagem é implantada pelo App Runner.

Neste aplicativo de exemplo, o CDK implanta o aplicativo usando a construção DockerImageAsset com a construção App Runner. Depois de implantado, o App Runner cria e carrega a imagem de front-end no Amazon Elastic Container Registry (ECR) e a implanta. Os consumidores downstream podem acessar o aplicativo usando a URL segura fornecida pelo App Runner. Neste exemplo, a URL é usado quando a notificação do SNS é enviada ao usuário quando a história está pronta para ser visualizada.

Conceder permissão ao contêiner de front-end para a tabela do DynamoDB

Para conceder permissão ao aplicativo Next.js para obter histórias da tabela Stories no DynamoDB, as funções da instância do App Runner são configuradas. Essas funções são opcionais e podem fornecer as permissões necessárias para que o contêiner acesse os serviços da AWS exigidos pelo serviço de computação.

Se quiser saber mais sobre o AWS App Runner, você pode explorar o workshop gratuito.

Escolhas e suposições de design

O recurso Time to Live (TTL) do DynamoDB é ideal para a curta duração das histórias geradas diariamente. O DynamoDB trata da exclusão de histórias após dois dias definido pelo atributo TTL em cada história. Depois que uma história é excluída, ela se torna inacessível por meio das URLs geradas.

Usar URLs pré-assinados do Amazon S3 é um método para conceder acesso temporário a um arquivo no S3. Esse aplicativo cria URLs pré-assinados para o arquivo de áudio e imagens geradas que duram 2 dias, após os quais os URLs dos itens do S3 se tornam inválidos.

As transformações de entrada são usadas entre streams do DynamoDB e eventos do EventBridge para dissociar os esquemas e eventos consumidos pelos destinos downstream. Consumir os eventos como eles estão é conhecido como padrão “conformista” e nos associa aos detalhes de implementação dos streams do DynamoDB com consumidores posteriores do EventBridge. Isso permite que o aplicativo permaneça desacoplado dos detalhes da implementação e permaneça flexível.

Conclusão

A adoção da tecnologia de inteligência artificial (IA) aumentou significativamente em vários setores. O ChatGPT, um grande modelo de linguagem que pode entender e gerar respostas semelhantes às humanas em linguagem natural, e o DALL-E, um sistema de geração de imagens que pode criar imagens realistas com base em descrições textuais, são exemplos dessa tecnologia. Esses sistemas demonstraram o potencial da IA para fornecer soluções inovadoras e transformar a maneira como interagimos com a tecnologia.

Esta postagem do blog explora maneiras pelas quais você pode utilizar os serviços serverless  da AWS com o ChatGTP e o DALL-E para criar um aplicativo de geração de histórias baseado em Next.js hospedado com o App Runner. O EventBridge Scheduler é usado para acionar o processo de criação da história e, em seguida, reagir aos eventos de captura de dados alterados com streams do DynamoDB e EventBridge Pipes, além de usar o Amazon EventBridge para distribuir tarefas de computação para processar notificações, imagens e arquivos de áudio.

Você pode encontrar a documentação e o código-fonte desse aplicativo no GitHub.

Para obter mais recursos de aprendizado serverless, visite Serverless Land.