Um aplicativo de chat com IA é uma interface de conversa por texto na qual o usuário digita uma mensagem, o aplicativo a envia para um serviço capaz de acionar um modelo de IA e, em seguida, exibe a resposta do modelo ao usuário.
Em muitos produtos, a resposta chega como um fluxo de dados (stream); assim, o usuário vê os tokens aparecerem progressivamente, em vez de ter de esperar pela resposta completa.
Para simplificar o cenário, imagine uma pequena equipe interna utilizando um único aplicativo web que se comunica com um serviço de backend, o qual, por sua vez, aciona um provedor de modelos.
Com um único servidor, o fluxo funciona como um ciclo. O cliente envia a mensagem do usuário para um servidor de API; esse servidor carrega a conversa para obter contexto, aciona o provedor de modelos e, finalmente, retorna a resposta do assistente ao cliente.
O armazenamento do histórico da conversa é importante mesmo neste modelo base, pois uma atualização da página não deve apagar o chat. O servidor de API persiste cada mensagem do usuário e do assistente, utilizando essas mensagens armazenadas para dar continuidade à mesma conversa na interação seguinte.
Abaixo, apresentamos o ciclo de interação única que estamos construindo como modelo base.
O diagrama envolve quatro funções. O cliente coleta a entrada e renderiza o fluxo de dados; o servidor de API gerencia o ciclo de vida da requisição; o armazenamento de conversas preserva as mensagens para que o histórico da conversa persista após uma atualização da página; e a API do modelo gera os tokens do assistente, que o servidor repassa ao cliente.
O escopo funcional limita-se a um chat de texto simples. Não há ferramentas, imagens ou uploads de arquivos; portanto, as únicas tarefas por turno de interação são armazenar mensagens, montar o contexto e chamar o modelo.
Agora, considere um número que sobrecarrega um servidor individual. Com 2.000 usuários simultâneos realizando 2 turnos de interação por minuto, o backend lida com cerca de turnos de usuário por segundo, o que se traduz em uma ordem de grandeza equivalente de chamadas paralelas ao modelo.
Esse número gera dois indicadores de requisitos não funcionais aos quais o restante do projeto precisará responder. A latência torna-se evidente, pois as chamadas ao modelo dominam o tempo total de processamento (de ponta a ponta), e o custo torna-se um fator crítico, visto que o sistema paga por cada requisição e por cada token gerado.
Mesmo antes do escalonamento, a arquitetura base pode ser claramente dividida em blocos reutilizáveis, cada um com uma responsabilidade específica.