Agentes de voz em produção: os 5 modos de falha

Agentes de voz em produção falham em cinco pontos previsíveis: latência, transcrição, coleta estruturada de dados, normalização para o TTS e detecção de turno com barge-in. Venky B, da Plivo, viu esses padrões em bilhões de chamadas por mês e mostra que a maioria dos times acerta no protótipo e quebra depois de ir ao ar.

O que faz agentes de voz em produção quebrarem na primeira semana

Agentes de voz em produção falham por cinco motivos previsíveis: latência acima do limite percebido, transcrição frágil em áudio real, coleta de dados sem estrutura, saída crua enviada direto ao TTS e detecção de turno mal resolvida. Venky B, fundador e CEO da Plivo, plataforma de APIs de voz e SMS que virou negócio de agentes de IA, apresentou esses padrões depois de observar mais de um bilhão de chamadas de voz por mês. A tese dele é simples: o pipeline funciona no laboratório e quebra quando sai do laboratório.

A palestra foi feita em uma conferência de engenharia de IA em 2025, e a transcrição de áudio cometeu erros óbvios no nome do palestrante e da empresa — o que, por ironia, reforça o argumento central. Verbos, siglas e nomes próprios que um humano resolve por contexto quebram qualquer motor de transcrição que dependa só de acústica.

Antes de tratar cada modo de falha, vale entender o recorte de quem está falando. A Plivo opera sobre SIP trunking e camada de streaming de áudio construídas ao longo de 14 anos. Isso significa que a empresa não depende de terceiros para a camada de telefonia e operadora — o que muda o que ela consegue observar sobre onde a falha realmente nasce.

O palestrante classifica a oferta em três produtos: um agente programável baseado em pipeline de fala, um estúdio visual sem código e as APIs de voz e SMS originais. Ele mesmo faz uma ressalva importante sobre o primeiro: não é ainda um modelo verdadeiramente fala-a-fala, e sim um pipeline de fala. Essa distinção importa porque muita falha de latência descrita adiante nasce justamente do número de saltos entre módulos.

Latência em agentes de voz em produção: onde o orçamento de tempo vai embora

O modo de falha mais discutido é a latência, medida principalmente por time to first audio — o tempo entre o fim da fala do usuário e o início da resposta do agente. Segundo o palestrante, a maioria dos projetos mira ficar abaixo de 550 ms, valor que aparece em material de fornecedores, mas acaba entregando entre 750 ms e 1,2 segundos. Acima de 1,2 segundo, o comportamento observado é desligamento da chamada.

Esses números são indicações de produção apresentadas pelo palestrante, não um benchmark independente. Trate-os como referência de ordem de grandeza para calibrar o que você mede, e não como um padrão que um fornecedor específico garante.

O ponto contraintuitivo está no lado do modelo de linguagem. Quase todo avanço recente em capacidade de raciocínio depende de 'thinking' ou cadeia de pensamento estendida. Em um agente de voz, esse recurso precisa ficar desligado se você quiser resposta rápida o suficiente. O palestrante resume a ironia: a inteligência construída na camada de raciocínio fica desligada por padrão quando você precisa de velocidade.

Para equilibrar custo, inteligência e latência, ele organiza as opções em três faixas. A tabela abaixo preserva apenas o que foi dito na palestra, sem generalizar para todos os provedores de cada categoria.

Os números abaixo vêm de medições apresentadas na palestra e devem ser lidos como relato de primeira mão do palestrante, não como benchmark publicado e auditado.

A solução que ele diz ter funcionado melhor na Plivo é usar modelos abertos hospedados pela própria equipe, com foco em ficar consistentemente abaixo de 300 ms. Duas escolhas de arquitetura aparecem nesse caminho, e a escolha entre elas depende do idioma.

Em inglês, os modelos citados funcionam bem. Para público multilíngue, o palestrante aponta vantagem clara para o modelo Gemma da Google, citado como Gemma 4, com base em avaliações de fertilidade de tokens. Fertilidade de tokens aqui significa quantos tokens são necessários para gerar uma palavra naquele idioma — quanto menor, mais rápido o tempo até a palavra.

A diferença relatada é de 2,5 a 3 vezes a favor do Gemma em contextos multilíngues, mantendo as outras variáveis constantes. Esse é um relato de eval interno da Plivo, classificado como medição de primeira mão, não como resultado replicado por terceiros.

Sobre tamanho de modelo, o palestrante recomenda que modelos de mistura de especialistas na faixa de 3 a 4 bilhões de parâmetros funcionam bem prontos de fábrica. A ressalva é relevante: ajuste fino em modelos de mistura de especialistas é difícil e pode degradar o modelo. Se você precisa de ajuste fino para um domínio específico, como saúde, ele recomenda começar em 8 a 12 bilhões de parâmetros hoje.

O critério de avaliação para escolher modelo em voz não é capacidade de raciocínio. São duas coisas: geração rápida de tokens e alta taxa de sucesso em chamada de ferramentas, com boa aderência a instruções. Segundo o palestrante, um modelo que acerta esses dois pontos já resolve 70% a 80% do trabalho sem ajuste fino algum.

Outro padrão citado é dividir o trabalho entre dois modelos: um menor para a parte conversacional e um maior apenas para chamada de ferramentas, elevando a taxa de sucesso nessa etapa crítica.

Transcrição frágil: por que 4% de erro vira dois dígitos no ar

Assuma que a transcrição vai ser frágil — esse é o princípio que o palestrante recomenda adotar antes mesmo de escolher o motor. Os melhores motores chegam a algo entre 4% e 6% de word error rate em conjuntos de avaliação conhecidos, mas chamadas reais e ruidosas com sotaque, vocabulário de domínio e áudio ruim sobem para a casa dos dois dígitos.

O que quebra segue padrões identificáveis, e vale listar separadamente porque a correção de cada um é diferente:

1. Nomes próprios e jargões, que raramente aparecem no vocabulário de treino do motor.
2. Números de telefone, com dígitos faltando ou trocados de forma aleatória.
3. Endereços longos, em que o motor perde partes no meio da coleta.
4. Troca de idioma no meio da frase, ou code-switching, que contamina todas as camadas seguintes.
5. Texto do mesmo idioma escrito em outro alfabeto, o que derruba transcrição, modelo de linguagem e síntese em cascata.

O caso mais didático é o do inglês escrito em devanágari. O palestrante mostra que a frase em inglês grafada nesse alfabeto quebra o motor de transcrição, depois faz o modelo de linguagem responder nesse mesmo alfabeto e, por fim, estraga a síntese de voz. O mesmo vale para hindi escrito em alfabeto latino, e o padrão se repete em árabe, mandarim e japonês.

A receita para o que realmente move a agulha na transcrição tem quatro partes. A primeira é turbinar palavras-chave de forma dinâmica, e não estática: mantenha o vocabulário restrito ao estado atual da conversa, porque uma lista gigante de palavras-chave faz o motor alucinar. A segunda é pós-processar o texto com um modelo de linguagem, que tem contexto de domínio que o motor de transcrição não tem.

Exemplos concretos de pós-processamento ajudam. Um número de telefone transcrito com a letra 'E' no meio vira o dígito 3 quando passa pelo modelo de linguagem; a letra 'l' isolada vira o dígito 1. Nenhum desses erros é visível para quem só olha a saída do motor de transcrição.

A terceira parte é transliterar a saída para normalizar texto multilíngue, usando um modelo de linguagem ou um motor dedicado de transliteração — existem vários de código aberto para essa tarefa. A quarta é enviar sempre o mesmo formato de transcrição limpa para o modelo de linguagem, independentemente de qual motor produziu o texto. Esse desacoplamento é o que permite trocar de motor sem reescrever o agente.

Coleta de dados: trate campos como tipos, não como conversa

Esta é a área em que, segundo o palestrante, de 50% a 60% dos agentes de voz erram feio. O enquadramento que ele propõe é incomum: em vez de um problema de prompt, trate como problema de experiência do usuário, ou mais precisamente como problema de modelo de dados. Em vez de receber transcrição solta e pedir ao modelo que adivinhe o conteúdo, defina a forma do dado antes de fazer a pergunta.

A inspiração vem do ferramental de desenvolvimento: dataclasses do Python, Pydantic, Zod para TypeScript, ou simplesmente campos de formulário em uma interface. O palestrante relata que times que passaram a pensar assim saíram de cerca de 30% para algo entre 95% e 97% de acurácia na coleta, sem ajuste fino de modelo.

Número de telefone é o exemplo mais claro. Se o campo é tipado como telefone, você sabe quantos dígitos ele precisa ter, consegue validar o formato e consegue restringir os valores permitidos. Quando chega a letra 'E' no meio, o agente sabe que aquilo é o dígito 3, confirma com o usuário ou pede para repetir.

Nome difícil de pronunciar exige outro tratamento. O palestrante usa o próprio sobrenome como teste: nenhum humano nem motor vai acertar de primeira, então a solução é regra e confirmação soletrada letra por letra, em vez de repetição de tentativa e erro.

Valores relativos são o segundo ponto de falha dramática. Quando alguém diz 'quarta que vem às 8', o agente precisa resolver três ambiguidades ao mesmo tempo: qual data é essa, se 8 significa manhã ou noite, e em qual fuso horário. O palestrante defende que isso deixa de ser problema aberto quando o campo é declarado como data e hora e o sistema aplica a data corrente como base de cálculo.

A consequência prática para testes é grande. Em vez de rodar centenas de casos ponta a ponta para descobrir que um campo está quebrado, você avalia cada campo no nível de teste unitário. Enquanto seus testes de campo passam, o comportamento tende a ser repetível — porque o que quebra é a coleta, não a personalidade do agente.

O palestrante é direto sobre a alternativa: ficar ajustando o prompt por alguns caracteres esperando que o modelo passe magicamente a seguir instruções é o caminho caro e instável. Quebrar o contexto do que o agente faz naquele ponto específico da conversa é o caminho que ele diz ter funcionado.

Normalização entre o LLM e o TTS: o que evita pronúncia errada

Não envie a saída bruta do modelo de linguagem direto para a síntese de voz. O palestrante defende uma camada de normalização entre as duas etapas, construída do seu lado, e não delegada ao motor de TTS — mesmo reconhecendo que existem bons motores no mercado.

A razão é portabilidade. Se você depende do motor de TTS para interpretar e-mail, moeda e data, trocar de fornecedor ou lidar com indisponibilidade do primeiro motor vira reescrita. Com a normalização na sua camada, a troca é transparente para o agente.

A lista de limpezas básicas inclui remover emoções, emojis e marcação Markdown antes de qualquer síntese. Alguns frameworks de orquestração já fazem isso quando você liga as flags certas, mas o palestrante alerta: se você constrói o pipeline do zero ou usa outro framework, configure isso explicitamente.

Dicionários personalizados são o segundo item. Praticamente todo motor de TTS oferece algum mecanismo de pronúncia para palavras próprias, marcas e siglas. Sem configurar isso, o agente vai ler siglas como se fossem palavras e errar nomes de forma consistente.

O terceiro item é controle de velocidade em trechos críticos. Quando o agente precisa soletrar um e-mail, um telefone ou um nome, reduzir a velocidade para algo em torno de 0,8x ou 0,7x melhora a inteligibilidade de forma perceptível.

O teste pessoal que o palestrante adota é simples e revelador: se o agente não consegue pronunciar o sobrenome dele nem o nome da própria empresa, já falhou no básico. Ele relata que vários motores pronunciam o nome da empresa como 'pivo' ou variações parecidas. Para produtos de atendimento ao cliente, a recomendação é expor esse controle ao cliente final, para que ele mesmo ajuste pronúncias do próprio negócio.

Detecção de turno e barge-in: o que separa conversa de monólogo

Os dois últimos modos de falha — detecção de turno e barge-in com backchanneling — foram apresentados de forma resumida por falta de tempo na palestra. Ainda assim, a posição do palestrante é clara: são problemas resolvíveis em pipeline de fala, sem depender de um modelo fala-a-fala dedicado.

Detecção de turno é decidir quando o usuário terminou de falar. Errar para mais cria pausas que parecem lentidão e alimentam o problema de latência percebida descrito antes. Errar para menos faz o agente interromper o usuário no meio da frase.

Barge-in é o comportamento oposto: o usuário interrompe o agente, e o sistema precisa parar de falar, registrar o que foi dito e responder à nova informação. Backchanneling é o que humanos fazem naturalmente com sons curtos como 'sim', 'entendi' ou 'hã' para sinalizar escuta ativa sem tomar o turno.

O palestrante afirma que pipelines de fala conseguem entregar esses três comportamentos sem um modelo fala-a-fala, e que essa é a abordagem adotada na Plivo. Trate como posição de fornecedor, não como resultado independente. Vale notar também que a própria oferta foi descrita como pipeline de fala, e não como produto fala-a-fala.

Como testar e evoluir um agente de voz sem depender de prompt

A conclusão prática defendida na palestra é transformar cada campo coletado em um teste unitário e avaliar por campo, não só de ponta a ponta. Isso reduz o custo de diagnóstico e torna o comportamento do agente mais repetível quando o volume cresce.

Vale posicionar o conselho contra o cenário real de 2026. Modelos multilíngues abertos evoluem rápido, e o palestrante reconhece que um modelo de 4 bilhões de parâmetros pode superar um de 8 bilhões em poucos meses. As recomendações de tamanho têm prazo de validade curto e devem ser revalidadas a cada troca de geração.

O mesmo vale para latência de modelos de fronteira. Os números de time to first token citados na palestra são indicações de uma conversa de fornecedor, não uma medição pública auditada. Meça com a sua carga, no seu idioma e no seu perfil de áudio antes de decidir.

Três hábitos reduzem risco de forma desproporcional. Primeiro, medir latência por etapa, e não só o total. Segundo, manter a normalização e a transliteração fora do motor de transcrição. Terceiro, versionar o vocabulário de palavras-chave por estado da conversa, porque lista estática e longa degrada a transcrição.

Nada disso exige ajuste fino. O palestrante relata que a maior parte do ganho de acurácia vem de estrutura e validação, não de treinar modelo. Ajuste fino fica reservado para domínios específicos em que o vocabulário e as regras de negócio já estão mapeados.

Perguntas frequentes

• O que é considerado boa latência em agentes de voz em produção? O palestrante relata que a maioria dos projetos mira abaixo de 550 ms de time to first audio, mas entrega entre 750 ms e 1,2 segundo. Acima de 1,2 segundo, o comportamento observado é desligamento da chamada. São indicações de produção, não um benchmark auditado.

• Por que desligar o raciocínio do modelo em um agente de voz? Porque a resposta precisa começar rápido. Segundo o palestrante, os avanços recentes em cadeia de pensamento ficam desligados por padrão em agentes de voz, já que a latência adicional inviabiliza a conversa.

• Modelos abertos substituem modelos de fronteira em voz? O palestrante afirma que modelos abertos hospedados localmente funcionaram melhor na Plivo para ficar abaixo de 300 ms, equilibrando custo, inteligência e latência. É relato de fornecedor, não resultado independente.

• Por que a transcrição erra tanto em nomes e telefones? Porque motores de transcrição operam com contexto acústico limitado. A recomendação é pós-processar o texto com um modelo de linguagem que tenha contexto de domínio e usar palavras-chave dinâmicas por estado da conversa.

• Como um agente de voz deve coletar um endereço ou nome difícil? Tratando o dado como campo tipado, com regras de validação e confirmação soletrada letra por letra. O palestrante relata que essa mudança levou a coleta de cerca de 30% para 95% ou mais de acurácia.

• Qual a diferença entre latência e detecção de turno? Latência é quanto tempo o agente demora para começar a falar depois que o usuário termina. Detecção de turno é justamente decidir quando o usuário terminou, e erro nessa decisão aparece como lentidão ou interrupção indevida.

• É preciso ajustar fino um modelo para um agente de voz funcionar bem? Não segundo o palestrante. Alta taxa de sucesso em chamada de ferramentas e boa aderência a instruções resolvem a maior parte do trabalho. Ajuste fino fica para domínios muito específicos, com modelos de 8 a 12 bilhões de parâmetros.

• Dá para fazer tudo isso sem usar um modelo fala-a-fala? O palestrante afirma que sim, e cita barge-in e backchanneling como comportamentos implementáveis em pipeline de fala. A própria oferta da empresa foi descrita como pipeline de fala, não como modelo fala-a-fala.

• Onde isso se conecta com o ecossistema de desenvolvimento no Brasil? Comunidades como o Crazystack Typescript e iniciativas como o Bootcamp do Dev Doido, do Gustavo Dev Doido, ajudam quem constrói produto a organizar pipelines, tipos e testes antes de ir para produção. O link https://crazystack.com.br reúne esse material. A Skala Blog também cobre temas de engenharia aplicada.

Do protótipo ao piloto: um roteiro em três etapas

Se você quer aplicar o que a palestra descreve, a ordem importa mais que a ferramenta escolhida. Comece pelo modelo de dados, porque ele é o que mais muda a acurácia percebida pelo usuário.

1. Declare os campos que o agente precisa coletar antes de escrever prompt, com tipo, validação e regra de confirmação para cada um. Trate cada campo como um teste unitário separado, e não como parte de um teste ponta a ponta.
2. Construa a camada de normalização entre modelo de linguagem e síntese, incluindo limpeza de Markdown e emojis, dicionário de pronúncia e controle de velocidade em trechos soletrados.
3. Meça latência por etapa e reavalie a escolha de modelo a cada troca de geração, porque as recomendações de tamanho e os números de latência citados na palestra envelhecem rápido.

Transforme a palestra em material de referência

A palestra de Venky B é rica em detalhe oral que se perde fácil: os intervalos de latência, a ordem das camadas, a diferença entre turbinar palavras-chave de forma estática e dinâmica. Conteúdo assim costuma viver só em vídeo, e quem precisa consultar depois acaba revendo o mesmo trecho várias vezes.

Se você tem aulas, entrevistas ou explicações gravadas com esse tipo de densidade técnica, dá para transformar esse material em um artigo estruturado, com seções, listas e perguntas frequentes, sem perder o que foi dito. No Skala Blog o fluxo é direto: você cola a URL do vídeo do YouTube, o conteúdo é transcrito e vira um artigo pronto para revisão.

O resultado serve tanto para consulta interna do time quanto para publicar o conhecimento que hoje está preso em uma gravação.

Source video