AssemblyAI detalha os testes de carga de agentes de voz antes do lançamento

A AssemblyAI publicou um guia técnico sobre como testar um agente de voz antes do lançamento, argumentando que o desempenho da demonstração em uma única chamada de sala silenciosa não reflete as condições de produção. No post, publicado em 2026-10-20, a empresa diz que as equipes devem reproduzir suas chamadas reais mais difíceis por todo o pipeline no pico projetado de concorrência e medir a precisão da entity, latência P95 , conexões rejeitadas e custo por tarefa concluída.

O que o guia diz para testar

O artigo diz que o teste de carga deve cobrir toda a pilha de voz — voz para texto, LLM, texto para fala, chamadas de ferramentas e telefonia — e deve separar concorrência, taxa de transferência e duração da sessão, pois cada um falha de forma diferente. A AssemblyAI afirma que uma campanha de callback que abre centenas de chamadas em uma janela curta pode atingir um limite diferente de uma carga de concorrência de longa duração, e que a maioria das equipes testa apenas o primeiro caso. O guia também recomenda quatro perfis: estado estacionário, rampa linear, pico e absorção.

Os exemplos da AssemblyAI focam em entradas semelhantes a produções, em vez de áudio limpo. A postagem diz que as equipes devem construir um corpus a partir de suas piores chamadas, incluindo compressão telefônica 8 kHz, conteúdo pesado em entidades, como números de conta e códigos de confirmação, sotaques reais, ruído de fundo, interrupções e falsos começos. Também alerta que rótulos de transcrição humana podem conter omissões ou limpezas que distorcem métricas de erro de palavra, e diz que a precisão das entidades deve ser ponderada acima da precisão das palavras ao pontuar fluxos de trabalho de voz.

Capacidade, faturamento e modos de falha

O artigo diz que o teste deve provar que as sessões fecham de forma limpa e que o aumento de atividades permanece dentro dos limites do provedor. Nas APIs de streaming e Voice Agent do AssemblyAI, as sessões são cobradas pelo tempo conectado, e o guia diz que a capacidade é determinada por conta. Para streaming, o post diz que o limite é para novas sessões por minuto e pode ser escalado automaticamente em contas pagas; para a API do Voice Agent, diz que o limite é para sessões simultâneas.

A AssemblyAI também diz que os testes de carga devem levar em conta o comportamento de faturamento. O post diz que o tempo ocioso é faturável, uma sessão de streaming que não está explicitamente fechada pode fechar automaticamente após três horas e ser cobrada pelo período completo, e fechar um socket do Voice Agent sem enviar session.end deixa uma janela de retomada de 30 segundos que também é faturável. A empresa diz que custo por tarefa concluída é uma métrica melhor do que custo por hora, porque um agente mais barato, porém menos eficaz, ainda pode se tornar mais caro na prática.

Métricas de referência e números de referência

O guia recomenda reportar percentis em vez de médias e fornece limiares-alvo para várias métricas, incluindo P95 abaixo de 500 ms para atraso de finalização, P95 menos de 1.5 segundos para latência de turno de ponta a ponta, P95 abaixo de 500 ms para idas e volta por chamada de ferramenta, zero rejeições no pico planejado e abaixo de 0.5% sessões perdidas. Também diz que as equipes devem separar as medições da fase de rampa e da fase de sustentação, pois a latência pode piorar durante a rampa.

Para ilustrar comparações de precisão, a AssemblyAI cita seu benchmark de voice-agent em inglês de 12,460 cenários roteirizados. Nesse benchmark, a empresa afirma que Universal-3.6 Pro Realtime registrou 5.19% taxa de erro de palavra e 14.4% de identidade, comparado ao Deepgram Flux EN em 13.50% e 30.1%, ElevenLabs Scribe v2 em 7.78% e 18.5%, e Deepgram Nova-3 em 8.64% e 26.1%. O post também cita um subconjunto de números de telefone em 2.4% versus 11.5% para Deepgram Flux EN. Além disso, faz referência ao benchmark independente de STT aberto da Pipecat, que, segundo ele, encontrou uma taxa de erro semântico de palavra 0.80% agrupada e um atraso mediano 307 ms na transcrição final, enquanto observa a visão da Pipecat de que pequenas lacunas entre os principais serviços podem não ser significativas.

Guiamento do arnês e manuseio de limite

AssemblyAI inclui código de exemplo tanto para sua API de streaming quanto para a API do Voice Agent, com ênfase em sincronizar o áudio em tempo real, esperar pela confirmação da sessão antes de enviar o áudio e contar a concorrência máxima somente após o servidor confirmar que a sessão está ativa. O post diz que sessões podem ser rejeitadas no momento da conexão e que sessões rejeitadas devem ser contadas em vez de serem tentadas novamente em um teste de carga. Também alerta que os blocos de áudio devem permanecer dentro do tamanho permitido pela API e que o fluxo deve ser terminado explicitamente para que o teste não vaze sessões faturáveis.

Para o planejamento, a empresa diz que as equipes devem fixar o modelo de fala em vez de depender dos modelos padrão mais recentes, benchmark de modelos de reserva no mesmo corpus e estabelecer limiares de rollback antes do lançamento. O artigo termina com um plano de lançamento de um semana e uma lista de verificação de prontidão para produção que abrange carga e concorrência, monitoramento, benchmarking nos dados da equipe e questões sobre contratos, como limites de taxa, unidades de faturamento, regiões de processamento de dados e metas de resposta de suporte.