Caso 03 · Trabalhos selecionados
Atender o tráfego de um assistente de IA sem manter uma conexão aberta
- Entregue e integrado — nenhum resultado de produção é reivindicado
Redesenhei o caminho de requisição de um assistente de atendimento com IA para que uma conversa seja enfileirada e consultada por sondagem em vez de ficar presa numa conexão síncrona — entregue e integrado.
- Papel
- Senior Web Developer
- Capacidades
- IA aplicada · Arquitetura · Confiabilidade
- Área
- Plataforma de e-commerce em produção com assistente de IA
- Mudança
- Caminho síncrono → fila com sondagem pelo navegador
Contexto
Uma plataforma de e-commerce em produção com um assistente de atendimento com IA servindo seus clientes, ao lado dos fluxos de negócio já estabelecidos da própria plataforma.
Problema e indefinição
Existe um descompasso estrutural no centro de todo produto com LLM: um turno de modelo de linguagem leva rotineiramente dezenas de segundos, e tudo por onde uma requisição web passa a caminho desse modelo — gateways, firewalls, proxies — tem um orçamento de tempo pensado para requisições de milissegundos. Um desenho síncrono tem, portanto, dois modos de falha ao mesmo tempo. O óbvio é que uma resposta lenta pode estourar algum limite do caminho. O que as pessoas não veem é que, enquanto roda, ela ocupa esse caminho, então o próximo cliente espera atrás. Os dois parecem iguais de fora: a IA está lenta. ⛔ Nenhum dos dois é problema de modelo.
Meu papel
Meu papel: trabalho no sistema de atendimento com IA da empresa — estrutura de conhecimento, roteamento de respostas, integração de ferramentas, gestão de sessões, avaliação, controles de segurança e escalonamento para uma pessoa — e projetei e entreguei a mudança no caminho de requisição descrita aqui. Também mantenho a plataforma de e-commerce em volta dela.
Levantamento
A pergunta útil não era «como deixamos o modelo mais rápido», mas «o que neste caminho espera que uma requisição termine rápido, e o que acontece com todo mundo enquanto uma não termina?». Responder isso muda o problema de ajuste de modelo para arquitetura de conexão.
Arquitetura e trade-offs
Sair do tratamento síncrono. A requisição vai para uma fila; o navegador consulta a cada poucos segundos e mostra a resposta quando fica pronta. Nada mantém conexão aberta, então nenhum teto de tempo do caminho governa a conversa, e os clientes são atendidos em paralelo, ⛔ não em fila atrás uns dos outros. O custo é um cliente um pouco mais complexo e um estado de espera visível — uma troca que eu faria de novo, porque a alternativa falha em silêncio e de forma injusta.
Implementação e integração
Trabalhadores de fila no framework que a plataforma já usava, com sondagem pelo navegador e tratamento de retentativa e erro em volta das chamadas ao modelo. Vieram junto mais dois controles: sessões ociosas expiram — uma conversa em silêncio recebe um toque e, se não houver resposta, ela fecha e libera a capacidade que segurava — e requisições mais leves são roteadas para modelos menores em vez de toda chamada ir para o maior, que é o controle de custo de inferência mais simples que não degrada as respostas que importam.
Controles de produção
Retentativa e tratamento de erro em volta das chamadas ao modelo; gestão do ciclo de vida das sessões; e uma abordagem de avaliação sendo desenhada por dentro, ⛔ não parafusada depois — incluindo correção quando uma única resposta precisa buscar e combinar várias informações, e comportamento sob sondagem adversária e de engenharia social. Essa avaliação está sendo construída, ⛔ não é endurecimento já entregue: estou descrevendo um desenho, ⛔ não reivindicando um resultado.
Impacto
O redesenho está pronto e integrado à plataforma. Nenhum número de desempenho é publicado sobre este trabalho, e nenhum será — não tenho um resultado de produção que possa reivindicar com honestidade.
Aprendizado reaproveitável
Quando um recurso de IA é descrito como lento, meça o caminho antes de mexer no modelo. Na minha experiência o modelo costuma estar fazendo o que sempre fez, e o que mudou a experiência do usuário foi a arquitetura em volta dele — e a solução quase sempre é parar de manter uma conexão aberta.
Evidência pública
Tudo acima é o que pode ser discutido publicamente. O que fica retido, e o que está sendo preparado:
Nada do assistente do cliente é publicado — nem sua estrutura de conhecimento, nem prompts, nem conjunto de avaliação, nem qualquer número de desempenho. Os mecanismos descritos acima são genéricos e não são propriedade daquele cliente; uma implementação independente sobre conteúdo meu é um sistema diferente e não tem relação com o negócio daquele empregador.
Este é o método por trás disso
As respostas saem deste site. Ele vai dizer quando um projeto não vale a pena ser construído.