Respostas de IA em streaming devem ser salvas como mensagens, não como logs

Tese central

O artigo, publicado no blog da Ably, fornecedora do serviço que descreve, defende que respostas de IA em streaming devem ser armazenadas como mensagens, e não como tokens soltos ou como nada. O critério proposto é o "teste do cliente tardio": um cliente que se conecta no meio da resposta, como um navegador recarregado, um segundo dispositivo ou um atendente humano que assume a conversa, precisa receber três coisas: a resposta gerada até ali como um único conteúdo, o status dela (em geração, concluída ou cancelada) e o restante ao vivo, sem lacunas nem trechos duplicados.

Quatro formas de armazenamento

O texto compara quatro padrões.

No primeiro, a entrega efêmera por SSE ou WebSockets, o servidor encaminha cada token uma vez e não guarda cópia. Um cliente que chega tarde não recebe nada gerado antes da conexão. O artigo observa que, para recuperar esse conteúdo, a equipe precisaria de um armazenamento separado para respostas parciais. Também cita o Last-Event-ID e os resumable streams do Vercel AI SDK, que mantêm eventos na memória do servidor produtor e podem se perder se esse servidor parar.

No segundo, os logs de chunks (Redis Streams, NATS JetStream, Electric Durable Streams), cada fragmento é guardado como entrada de um log append-only. Isso permite retomar uma conexão interrompida a partir da última posição recebida. O problema é que o log entrega fragmentos, não um texto legível. Cada consumidor precisa remontar a resposta, tratar duplicatas e detectar a conclusão, ou então é preciso manter um serviço de projeção, que cria uma segunda cópia com sincronização própria. Como logs costumam apagar entradas antigas, o início de uma resposta removido torna a reconstrução impossível.

No terceiro, as atualizações repetidas de registro (Postgres, Supabase, Firestore, Sendbird), o backend reescreve a linha ou documento a cada token. Esse padrão passa no teste, porque um cliente lê a resposta inteira em uma requisição. O custo é a carga de escrita: o artigo calcula que 1.000 respostas a 100 tokens por segundo resultariam em 100 mil atualizações por segundo. Para reduzir a carga, a equipe pode agrupar tokens em lotes, o que diminui as escritas mas aumenta o atraso. Por exemplo, uma descarga a cada 20 tokens faria um atendente ler texto até cerca de 200 ms atrás, a 100 tokens por segundo. Há ainda limites de taxa em APIs de chat e a necessidade de controle de versão. Uma variante usada pela Stream mantém as reescritas parciais em memória e salva apenas a resposta final. Nesse caso, um cliente que entra no meio pode ver um espaço vazio, e a resposta parcial se perde se o backend falhar.

No quarto, as appends de mensagem (Ably), uma resposta vira uma mensagem que cresce. O backend cria a mensagem, recebe um serial e envia appends com os novos tokens. Segundo o texto, o Ably mantém uma cópia atualizada, o banco de dados recebe uma única escrita ao final da resposta e o cliente que entra com rewind ou lê o histórico recebe o conteúdo acumulado, seguido dos appends seguintes.

Comparação e limites

Segundo a tabela do próprio artigo, apenas as atualizações repetidas de registro e as appends de mensagem armazenam uma resposta parcial legível enquanto o modelo ainda gera. Dessas duas, só as appends evitam escritas no banco por token. O texto admite que entrega efêmera e logs de chunks ainda podem ser adequados quando as respostas são curtas ou quando todo cliente lê cada resposta desde o início.

Construir por conta própria

O artigo afirma que implementar appends exige um armazenamento distribuído de appends, e não apenas uma tabela ou uma chave Redis. Seriam necessários quatro acertos: ordenar cada append, manter uma cópia legível sem reescrever o texto inteiro, passar do histórico para o fluxo ao vivo após reconexões e decidir de forma única o desfecho quando conclusão, último append e cancelamento ocorrem ao mesmo tempo. Como essa camada fica no caminho de toda resposta, a equipe também assume capacidade, failover e monitoramento. O texto cita a Doxy.me, cujo VP de Engenharia descreveu a camada anterior como uma "caixa-preta" tão frágil que os engenheiros temiam mexer nela.

Ressalvas do próprio texto

• O Ably garante ordem apenas para um único publicador, por isso o artigo recomenda que cada resposta venha de um só.
• Por padrão, o serviço publica no máximo 25 mensagens por segundo, agrupando appends em janelas de 40 ms. A janela pode variar de 0 a 500 ms. A cobrança é por mensagem, não por token.
• O tamanho máximo de mensagem é 64 KiB nos planos Free e Standard e 256 KiB nos planos Pro e Enterprise.
• O SDK AI Transport é hoje para JavaScript e React. Outras linguagens podem usar appendMessage() no SDK Pub/Sub.
• O histórico fica disponível por 24 horas no plano gratuito e por 72 horas por padrão nos pagos. Por isso, muitos produtos ainda precisam de banco próprio.
• A documentação de atualizações, exclusões e appends aparece com o rótulo de Public Preview, e o artigo pede que se verifique o status de cada SDK.
• Como o texto é material de fornecedor, as afirmações sobre desempenho e disponibilidade, como os 99,999%, são alegações da própria Ably.