5 modos de falha de agentes de voz que você vai encontrar na primeira semana — Venky B, Plivo

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: 5 Voice Agent Failure Modes You’ll Hit in Week One — Venky B, Plivo · Canal: AI Engineer · 26:04 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos locais e open source, Modelos multimodais

Resumo

Venky B apresenta falhas comuns que surgem quando agentes de voz passam de prova de conceito para produção, com base na experiência da Plivo em chamadas em escala. Ele aborda latência, transcrições frágeis, coleta de dados, normalização da saída para TTS e problemas de interação como detecção de turnos e interrupções. As recomendações incluem equilibrar custo, inteligência e latência, normalizar transcrições e estruturar dados como campos validados. Também sugere testar cada campo com evals e criar uma camada independente para preparar a saída de voz.

Pontos-chave

• Agentes que funcionam bem em desenvolvimento podem falhar em produção, onde latência e outros problemas afetam a experiência dos usuários.
• Na escolha de modelos, é preciso equilibrar custo, inteligência e latência; modelos open source podem ser uma opção prática para atingir respostas rápidas.
• Transcrições devem ser tratadas como potencialmente frágeis, sobretudo com nomes próprios, números, vocabulário de domínio e idiomas misturados.
• Keyword boosting dinâmico e pós-processamento com um LLM podem melhorar a qualidade das transcrições.
• Estruturar a coleta como campos tipados, com validação e confirmação, pode tornar os dados coletados mais confiáveis.
• Evals no nível de cada campo ajudam a encontrar falhas sem depender apenas de testes end-to-end.
• Uma camada de normalização entre o LLM e o TTS pode tratar emojis, markdown, pronúncia, velocidade, e-mails, moedas e datas.
• A camada de normalização deve reduzir a dependência de um mecanismo TTS específico e facilitar sua substituição.
• Detecção de turnos, interrupções e backchanneling também afetam a qualidade da interação por voz.

Capítulos

Início	Capítulo	Resumo
00:01	Da prova de conceito à produção	O palestrante apresenta a Plivo e descreve por que agentes que parecem funcionar em desenvolvimento começam a falhar em produção.
04:57	Falha 1: latência	A latência afeta a experiência de conversa, e a escolha de modelos exige equilibrar velocidade, custo e inteligência.
13:06	Falha 2: transcrições frágeis	Nomes, números, vocabulário especializado e mudanças de idioma podem comprometer a transcrição e o restante do pipeline.
18:04	Falha 3: coleta de dados	Campos estruturados, validação, confirmação e evals por campo ajudam a coletar dados com mais confiabilidade.
22:19	Falha 4: saída mal preparada para TTS	Uma camada de normalização entre o LLM e o TTS melhora a leitura de texto, números e termos específicos.
25:31	Detecção de turnos e interrupções	O encerramento aborda detecção de turnos, barging e backchanneling como aspectos importantes da interação por voz.

Citações

Aí a produção começa e você vê todos os tipos de modos de falha. — 04:24

Parta do princípio de que suas transcrições serão frágeis. — 13:06

Defina a estrutura antes de perguntar. — 18:35

Normalmente, você quer uma camada de normalização entre o LLM e o que é enviado ao TTS. — 22:19

Conceitos e entidades

• Plivo (empresa): Empresa apresentada como fornecedora de APIs de voz e SMS e de uma plataforma de agentes de IA.
• Venky B (pessoa): Palestrante identificado no título como Venky B, que apresenta padrões de falha observados em agentes de voz.
• Qwen3.5 (modelo): Modelo open source citado como opção para agentes de voz com foco em baixa latência.
• Gemma 4 (modelo): Modelo open source apresentado como uma opção especialmente adequada para usos multilíngues.
• LiveKit (ferramenta): Framework de orquestração citado como base usada por equipes para construir agentes de voz.
• Pipecat (ferramenta): Framework de orquestração citado como alternativa para construir pipelines de agentes de voz.
• Groq (empresa): Empresa citada no contexto de infraestrutura de inferência com geração rápida de tokens e capacidade dedicada.
• Cerebras (empresa): Empresa citada como fornecedora de infraestrutura que pode oferecer baixa latência com capacidade dedicada.
• TTS (conceito): Síntese de fala que transforma a saída textual do agente em áudio.
• Detecção de turnos (conceito): Processo de identificar quando a pessoa terminou de falar para que o agente possa responder.
• backchanneling (conceito): Sinais breves de escuta ou acompanhamento usados durante a conversa para tornar a interação mais natural.

Tradução completa (pt-BR)

00:01 [música] Vamos fazer algumas perguntas rápidas e depois começar. Quantos de nós aqui na sala já criaram agentes de IA de voz? Certo, temos um público bem bom. E quantos de vocês já criaram agentes de IA que foram implantados em produção?

00:34 Nada mal. Certo, legal. Então, vamos falar sobre o que costuma acontecer, certo? Todo mundo está falando de agentes de IA de voz. A solução milagrosa para praticamente tudo no mundo hoje são os agentes de voz. Então, todo mundo está criando um e tentando implantá-lo. Eles parecem ótimos quando você está desenvolvendo no seu ambiente de desenvolvimento, mas, no momento em que você leva isso de uma prova de conceito para produção, as coisas começam a falhar. Vamos percorrer cinco ângulos diferentes sobre como isso acontece.

01:09 Ou sobre o que vimos na Plivo com agentes de voz. Mas, antes disso, uma rápida apresentação minha. Sou Wenke, fundador e CEO. Ela usou o título de gerente de engenharia de agentes; eu me chamo diretor de agentes, em termos de título. Certo, então por que estou qualificado para esta discussão e o que estamos vendo que muitas empresas não conseguem ver?

01:39 Vou falar um pouco sobre nossa trajetória e sobre como chegamos até aqui, e depois vamos começar. Estamos no mercado há cerca de 14 anos. Nossa trajetória começou como uma plataforma de APIs para desenvolvedores e, agora, somos uma empresa de agentes de IA. Começamos com APIs de voz e SMS lá em 2011 e, agora, estamos focados principalmente na nossa oferta de agentes de IA, a stack completa da nossa plataforma.

02:10 Acompanhamos mais de um bilhão de chamadas de voz por mês em todo o mundo. É por isso que vimos muitos desses padrões surgirem, em termos do que acontece com os agentes de voz dos nossos clientes em produção. Somos uma equipe de 90 pessoas e temos 50 milhões em caixa. Curiosidade: esse dinheiro não veio de investidores externos de VC. Tudo isso veio de sermos uma empresa lucrativa e termos colocado esse dinheiro no banco ao longo dos anos. Alguns clientes que atendemos pelo mundo.

02:46 Deixamos alguns logotipos ali. Mas, em termos de oferta, eu dividiria isso principalmente em três categorias. A primeira é uma oferta programável de agente de IA. Chamamos isso de… Bem, é um pipeline de fala, ainda não é um produto de fala para fala de verdade, mas é uma oferta programável. Também temos um estúdio de agentes de IA. É um construtor visual sem código. E, como eu disse, começamos com APIs de voz. Então, obviamente, desenvolvemos isso ao longo dos últimos 14 anos: as camadas de SIP trunking e de streaming de áudio.

03:18 Assim, não dependemos de terceiros para a telefonia nem para a camada de operadora. Esse é o negócio principal que construímos ao longo de todos esses anos, e é sobre ele que nossa plataforma de agentes de IA se apoia. Certo, com isso, vamos ao assunto. Tenho certeza de que, como todos vocês já criaram agentes de IA, já viram isso ou criaram algo parecido de uma forma ou de outra. Vamos dedicar mais tempo a como é o pipeline completo. O que vemos com os clientes é — e tenho certeza de que todos vocês se identificam com isso — que…

03:52 quando alguém pensa em agentes de IA, escolhe alguns desses frameworks de orquestração. Eles fazem um bom trabalho com LiveKit ou Pipecat, constroem seu agente de IA em cima disso e acham que basta orquestrar essas quatro camadas diferentes: speech-to-text, LLM e TTS, com detecção de turno entre elas, e pronto, tudo funciona. Meu agente de IA funciona em uma POC e está pronto para produção. Normalmente, é isso que acontece. Eles medem suas…

04:24 latências, e vocês podem ver alguns valores indicativos neste slide para cada camada, e pensam: “Sim, isso parece bom para o que eu preciso”. Então, posicionam isso como pronto para produção. Aí começam a surgir os problemas em produção, e aparecem vários modos de falha, nos quais vamos passar a maior parte desta palestra. Reservei um tempo no final para perguntas e respostas, caso vocês tenham perguntas, mas vamos direto daqui para os diferentes modos de falha que vemos.

04:57 Vamos começar pelo primeiro, que todo mundo comenta: é o modo de falha mais mencionado, a latência. Acho que hoje temos algumas palestras sobre agentes de IA. Tenho certeza de que todo mundo vai abordar esse modo de falha específico, por isso vou começar por ele, falando sobre como é toda essa experiência para os usuários. Normalmente, a maioria das pessoas…

05:27 mede isso pelo tempo até o primeiro áudio: o tempo entre o usuário parar de falar e o agente começar a falar. E acho que vocês provavelmente já viram isso se criaram agentes de voz: o que parece bom ou natural, o que parece meio irritante ou perceptível e o que é irritante de verdade — são níveis diferentes. Percebemos que a maioria das pessoas quer ficar abaixo de 550, porque é isso que as plataformas, soluções ou camadas anunciam.

06:00 Mas acho que a maioria acaba entre 750 e 1,2. É onde a maioria fica. Os que têm um desempenho muito ruim passam de 1,2, e aí você começa a ver os usuários desligarem. Agora vou compartilhar o que vimos na prática em produção com clientes que usam isso em diferentes camadas, e algumas soluções para esses problemas. A…

06:32 forma como devemos pensar nessa camada é como um equilíbrio entre três fatores: custo, inteligência e latência. E por que estou falando desses três? Porque estão relacionados. Uma das coisas que eu estava comentando há pouco com algumas pessoas é que, no último ano, vimos muitas inovações e um grande salto de inteligência no lado dos LLMs. E a maior parte dessa inteligência veio…

07:02 do raciocínio, do aprendizado por reforço e assim por diante. A ironia dos agentes de voz é que quase sempre o LLM ou o agente que está falando precisa estar com o raciocínio ativado. Então, todos os avanços que tivemos na camada de LLM no último ano não se aplicam aqui. Claro, temos modelos melhores, que seguem melhor as instruções ou fazem melhor tool calling, mas praticamente toda a inteligência desenvolvida na camada de…

07:34 raciocínio fica desativada por padrão se você quiser que o sistema seja rápido o suficiente. Essa é uma das ironias que encontramos. Então, como equilibrar inteligência, custo e latência? Vamos analisar algumas das opções disponíveis no mercado. Estou escolhendo especificamente os LLMs porque, se vocês olharem o gráfico anterior, o LLM é a categoria com maior latência que contribui para o total. E, se olharmos os modelos de fronteira, que acho que a maioria das pessoas escolhe por padrão, os seus modelos da OpenAI…

08:09 Seus Claude, seus Gemini… você sabe, o P50 de TTFT fica em torno de 450 a 500 num bom dia, e pode ter picos, certo? O P90 e o P95 podem facilmente passar de 1,2, 1,3 segundo, e isso não é bom para a experiência geral com o agent. Então, esse é o seu modelo de fronteira. Agora, há outra opção, o Cerebras ou o Groq, famoso e popular por gerar muitos tokens, ou tokens muito rápido,

08:42 certo? Eles funcionam, mas, para obter latência garantida, ou tempo até o primeiro token, é preciso ter capacidade dedicada, e isso é realmente caro. Foi aí que mencionei o custo como uma das coisas a equilibrar, certo? É realmente caro. E, se você conversar com alguém da equipe do Groq ou do Cerebras, vão dizer que é preciso reservar com 12 meses de antecedência para ter capacidade dedicada; eles estão com a agenda lotada para os próximos 12 meses. Então, essa é uma opção bem cara, e você realmente precisa ter certeza de que o modelo que está implantando em algumas dessas camadas de infraestrutura ainda estará disponível daqui a 12 meses,

09:17 e é um grande investimento e uma grande incógnita. Então, qual é uma opção realista para agents de qualidade adequada para produção, que equilibre essas três coisas? O que funcionou para nós foram os modelos open source. Obviamente, há muitos deles, com diversas variedades e variações para escolher. Estou falando especificamente dos dois com que trabalhamos: Qwen 3.5 e Gemma

09:50 4. São modelos open source de ponta, disponíveis no mercado agora, e fizemos muitos benchmarks sobre como funcionam. Pode ser assustador pensar: “Certo, agora tenho os modelos, preciso hospedá-los, executá-los nas minhas próprias GPUs e por aí vai”. Mas, se você busca consistentemente ficar abaixo de 300 ms, vimos que essa é uma ótima opção para equilibrar latência, custo e inteligência. Agora, um pouco mais de

10:24 detalhes: se você trabalha apenas em inglês, Qwen 3.5 ou Gemma funcionam bem. Mas, se trabalha com vários idiomas, com públicos internacionais e diferentes línguas, Gemma 4 é um modelo muito melhor para isso. Observamos os evals de fertilidade de tokens. Em outras palavras, sem usar jargão: quantos tokens são necessários para gerar uma palavra naquele idioma? Gemma é muito, muito melhor — pelo menos 2,5 a 3 vezes melhor que

10:55 Qwen 3.5 nesse aspecto. Portanto, o tempo até as palavras é muito mais rápido com Gemma, mantendo todo o resto igual, em vários idiomas. Agora, que tamanhos escolher na camada do LLM? A mistura de especialistas costuma funcionar bem. Uma mistura de especialistas de três ou quatro bilhões costuma funcionar bem. O problema com a mistura de especialistas é que, se alguém quiser seguir o caminho do fine-tuning, isso pode ser um desafio, porque fazer fine-tuning de modelos de mistura de especialistas não é fácil. Você pode acabar quebrando o modelo muitas

11:30 vezes. Então, esse é um desafio que vemos com a mistura de especialistas, mas, geralmente, pronta para uso, ela já deixa você 90% mais perto de onde quer chegar, mesmo sem fazer fine-tuning ou qualquer trabalho personalizado no modelo. Essa é a vantagem da mistura de especialistas. Agora, se você quiser fazer fine-tuning e se aprofundar, dizendo: “Olha, estou trabalhando em um domínio específico, como saúde, ou algo assim, certo? E quero ter certeza de que consigo fazer fine-tuning do meu modelo”, deve começar pelo menos com modelos de 8 bilhões ou 12 bilhões

12:00 de parâmetros, pelo menos com o que temos hoje. Talvez daqui a seis meses um modelo de 4 bilhões supere facilmente o modelo de 8 bilhões. Mas, hoje, pelo que observamos, você precisa de um modelo de pelo menos 8 bilhões ou 12 bilhões. Porque você busca duas coisas nesses modelos. Uma, obviamente, é gerar tokens rápido, mas também seguir bem as instruções. Certo. E a segunda é uma taxa de sucesso muito alta em tool calling, porque, se você fizer bem essas duas coisas, então

12:30 você já terá alcançado uns 70%, 80% do caminho sem sequer precisar fazer fine-tuning de nenhum modelo; os modelos funcionarão prontos para uso, certo? Então, essa tem sido a nossa receita. Na verdade, usamos duas variantes: um modelo com fine-tuning para setores específicos e, para a maioria dos casos de uso mais genéricos, um modelo MOE que funciona direto, pronto para uso. Temos mais algumas dicas e truques que vamos abordar nos próximos slides, quando falarmos dos modos de falha, mas é assim que estamos trabalhando com LLMs do ponto de vista da latência. Certo,

13:06 estou com pouco tempo, então vou acelerar. Há algumas outras variantes. As pessoas constroem agents com uma mistura de modelos. O que fazem é usar, para a parte da conversa, um modelo conversacional muito menor, talvez até um modelo de três bilhões de parâmetros, e, para tool calling, um modelo bem maior, a fim de melhorar a taxa de sucesso de tool calling. Desculpe, o segundo ponto é: parta do princípio de que suas transcrições serão frágeis.

13:41 Essa é uma ideia pela qual você deve se guiar ao construir agents de IA, mesmo que tenha o melhor mecanismo de transcrição disponível. E vou mostrar por quê. Os mecanismos de transcrição de ponta disponíveis no mercado costumam apresentar uma taxa de erro de palavras de 4% a 6%. Isso é em conjuntos de evals conhecidos; em chamadas reais e ruidosas, com sotaques diferentes,

14:14 vocabulário específico do domínio e por aí vai, a taxa de erro de palavras costuma chegar aos dois dígitos. Obviamente, você pode fazer fine-tuning: pegar um modelo open source e fazer fine-tuning. Mas vemos que certas coisas costumam dar errado, e há padrões nos problemas. Nomes próprios, jargões, números de telefone — com dígitos aleatórios faltando — e substituições incorretas. Vou mostrar alguns exemplos de como resolver isso com endereços, quando você está tentando coletar um endereço longo. O mecanismo de transcrição pode simplesmente acabar

14:49 omitindo algumas partes. Idiomas alternados. Vou usar como exemplo um idioma que falo, porque foi fácil colocá-lo no slide. Se você pegar o inglês, mas escrito em outro sistema de escrita, é isso que se usa para o hindi: inglês escrito naquele sistema. Já a versão em inglês mesmo é “hello, how are you”. Então, se estou falando com um público de outro país, alterno entre idiomas e o inglês começa a aparecer em outro sistema de escrita, tudo começa a dar errado,

15:24 desde o mecanismo de transcrição até a camada do LLM e além, porque muitas vezes o LLM começa a produzir respostas naquele sistema de escrita, e aí o TTS se atrapalha. Certo. Isso é muito importante, é preciso ter cuidado. Se você quiser construir seu agent sem depender do mecanismo de transcrição, precisa criar uma camada que normalize tudo isso, certo? Vamos falar das soluções daqui a pouco. Há também o outro caso: hindi escrito com alfabeto latino, ou romano, certo? Ou seja, é hindi, mas parece inglês, o que também atrapalha tudo que vem depois. Esses são apenas

15:58 exemplos. Isso se aplica a, sabe, árabe, mandarim, japonês e outras línguas. Praticamente qualquer idioma. Então, o que realmente faz diferença na camada de transcrição? Para nomes próprios, recomendamos usar não apenas o reforço de palavras-chave, que muitos mecanismos de transcrição oferecem, permitindo inserir palavras específicas no mecanismo, mas também o reforço dinâmico de palavras-chave. Isso significa não manter a palavra-chave durante toda a chamada. Adicione-a dinamicamente quando você

16:29 achar que precisa dela como resposta, para obter a maior precisão possível. Isso significa que, em diferentes estados da chamada, o mecanismo de transcrição terá palavras-chave diferentes reforçadas durante as diferentes fases, certo? E vimos que isso funciona melhor, porque, se você simplesmente poluir o contexto do mecanismo de transcrição com um monte de palavras-chave, ele vai começar a alucinar de novo, certo? Então, é isso que normalmente vemos funcionar melhor. Sim, faça o pós-processamento das transcrições com um LLM, certo? Porque o LLM tem contexto do domínio. O mecanismo de transcrição não tem. Então, muitas

17:02 das palavras que ele reconheceria — vou dar alguns exemplos — talvez não façam sentido. Esta é a transcrição de um número de telefone feita por um mecanismo de transcrição. Certo? O que você acha que é esse E? Certo? Se você mostrar isso a um LLM, ele sabe que é um três. Da mesma forma, aquele ali é o dígito um. Então, muitas vezes, o mecanismo de transcrição pode errar isso, mas, quando você faz o pós-processamento com a camada do LLM, ele corrige isso imediatamente para fins de coleta de dados. E, por fim, como eu disse, a transliteração é

17:33 a saída do seu reconhecimento de fala, que, por ser multilíngue, também é normalizada usando um LLM; primeiro, você faz a transliteração ou usa algum tipo de mecanismo neural de transliteração. Há muitos disponíveis como open source. Basta escolher um, certo? Ele fará todo esse trabalho para você. Envie transcrições limpas de forma consistente ao seu LLM, independentemente do mecanismo de transcrição. Certo. O terceiro problema que costumamos ver é a coleta de dados. É aí que eu

18:04 acho que 50 a 60% dos agentes de IA erram bastante. Gostamos de pensar nisso como um problema de UX, mas específico da voz. Então, pense em modelos de dados, não em uma transcrição chegando a um LLM para ele tentar descobrir o que foi dito. Vamos nos inspirar um pouco — suponho que a maioria de nós aqui seja desenvolvedora — no Python, com suas classes de dados, no Pydantic, no Zod, do TypeScript, ou nos campos de

18:35 formulários da interface. Se começarmos a pensar a partir dessa formulação do problema, vimos a precisão subir de 30% para cerca de 95% na coleta de dados, quando se começa a pensar dessa maneira. Então, defina o formato antes de perguntar, certo? Em vez de deixar a resposta em aberto, dá para restringi-la? Um número de telefone pode ser um campo do tipo número de telefone? Ao fazer isso, você sabe quantos dígitos ele precisa ter. Dá para validar isso. E que tipos de

19:08 valores permitidos podem existir? No exemplo anterior, se aparecer um E no meio de um número de telefone e você souber que é um número de telefone, dá para presumir imediatamente que é um três e confirmar com o usuário, ou saber que é um erro, validar e pedir que o usuário repita, certo? Então, acho que esse é um dos padrões comuns que vimos aqui na coleta de dados. O nome é um caso interessante. Escolhi um nome difícil de pronunciar,

19:40 como este. Não há como uma pessoa acertar, e um mecanismo de transcrição também não vai acertar, não importa quantas vezes você tente, certo? Então, quando começar a pensar nisso como campos, com regras e mecanismos de confirmação da grafia, letra por letra, aí sim você consegue acertar. Caso contrário, vai dar muito errado na coleta por chamada de voz. E esse é apenas um exemplo do que estou falando sobre a parte da coleta de dados. Outro caso em que as coisas dão muito errado

20:14 é com valores relativos. Datas são um exemplo. Se alguém disser “quarta-feira da semana que vem, às 8”, 8 pode significar 8h da manhã ou 8h da noite, e ainda é preciso descobrir a que data isso corresponde. Novamente, isso se torna um problema bem delimitado. Se você souber que esse é um campo de data e hora, que está coletando um campo de data e hora, e então usar a data atual para determinar a que valor isso corresponde, certo? Então, é assim que você deve garantir que faz isso com uma combinação do LLM, do tool calling e da ferramenta

20:44 de tool calling, que faz boa parte do trabalho pesado por você no que diz respeito aos campos. Sim. Depois, você executa isso como um teste de unidade. Todos os seus evals precisam começar a tratar esses campos como testes de unidade. E, desde que seus testes de unidade validem os dados e sejam aprovados, seu agent será confiável e consistente. Você não precisa executar centenas de casos de teste de ponta a ponta do agent só para descobrir que a coleta de um campo

21:15 está com problemas. Faça a avaliação no nível do campo e no nível dos testes de unidade. E, como eu disse, acho que essa forma de pensar torna tudo mais estruturado, em vez de esperar que, se eu incluir um monte de texto no prompt e continuar mudando alguns caracteres do prompt a cada vez, de alguma forma minha engenharia de prompt vá deixar o LLM muito mais ajustado às instruções e, por mágica, ele comece a seguir algumas dessas regras. Na verdade, como eu disse,

21:47 vimos chegar a uma precisão de 95% a 97% sem precisar fazer fine-tuning de um modelo. E o truque é basicamente dividir o contexto do que o agent está fazendo naquele momento em estados específicos pelos quais o agent está passando. Certo, vou passar por isso rapidamente, por causa do tempo. Vejo que tenho mais três minutos. Espero que seja um erro, mas vamos deixar assim. Certo.

22:19 Então, essa é a quarta área em que vemos problemas. A maioria das pessoas pega a saída do LLM e a envia para um TTS. Obviamente, há muitos TTS bons no mercado que dão conta de boa parte do trabalho pesado, mas muitas vezes algo dá errado. O que recomendamos, e o que vimos funcionar, é ter uma camada de normalização entre o LLM e o que é enviado para um TTS. Não envie a saída do LLM diretamente para um TTS, certo? E vamos

22:49 passar por alguns exemplos. O básico é remover emojis e markdown antes de qualquer síntese no TTS. A maioria dos pipelines de orquestração faz isso; por exemplo, LiveKit ou Pipecat fariam isso por você se você ativasse algumas opções. Mas, se você não os estiver usando ou estiver construindo tudo do zero, certifique-se de configurar isso explicitamente, porque você não quer que um emoji apareça no que será lido em voz alta, nem que o markdown apareça. Certo. Acho que alguns outros casos comuns

23:19 são dicionários personalizados. A maioria dos mecanismos de TTS oferece isso: como pronunciar palavras personalizadas, sejam nomes próprios, marcas, siglas e assim por diante. Então, configure-os ao passar do LLM para a saída do TTS, porque, se não fizer isso, vai errar. Vou mostrar um exemplo de como testamos isso. A outra coisa é que a maioria dos mecanismos também permite ajustar a velocidade. Então, se você sabe que está pronunciando uma entidade, diminua a velocidade. Faça seu agent falar mais devagar, para 0,8x ou 0,7x, para que ele consiga

23:54 como articular essa entidade específica e não errar a pronúncia de um e-mail, de um número de telefone ou de um nome, letra por letra. E, sim, normalize todas as coisas confusas, certo? E-mails, moedas, datas. Não deixe isso por conta do TTS. A maioria faz isso, mas não deixe por conta do TTS. Crie sua camada de normalização do seu lado, para que, se amanhã você achar que precisa trocar de TTS ou, por qualquer motivo, o primeiro ficar fora do ar e você quiser usar outro TTS, consiga, de certa forma, não

24:28 depender nativamente do mecanismo do TTS, mas fazer isso internamente para gerenciar tudo. E então, sim, acho que não estou com meu crachá aqui, mas meu sobrenome não está nele. Então, meu primeiro teste é: se ele não consegue pronunciar meu sobrenome ou o nome da minha empresa, já está falhando. Meu sobrenome é Balas Subramanion, e, se você não consegue pronunciá-lo usando um agente de IA de voz, isso já é um critério para mim. Eu sei que…

24:58 o agente vai errar muitas palavras que precisam ser soletradas no dia a dia. A segunda é o nome da nossa empresa, Plivo. Muitos mecanismos pronunciam como “pivo” ou “pleo”, e assim por diante. Mas acho que, especificamente, conseguir controlar isso no seu pipeline é extremamente importante. E, se você estiver criando um produto voltado para o cliente, ofereça essa opção aos seus clientes. Certo, vou passar rapidamente pelos dois últimos slides. Estou…

25:31 passando bastante do tempo. A detecção de troca de turno. Acho que esse é um tópico à parte, mas vou mostrar rapidamente todos os pontos para vocês poderem dar uma olhada. E, se precisarem conversar depois, podemos falar sobre isso. Certo. Vou deixar isso na tela por uns cinco segundos e depois podemos conversar sobre isso à parte. Já estou bem além do tempo. E o último ponto é a interrupção e os sinais de escuta. Acho que se fala muito sobre modelos de fala para fala que fazem parte disso, mas conseguimos ver como fazer tudo isso em pipelines de fala para fala

26:04 . Não é necessário um modelo de fala para fala para fazer tudo isso. De novo, vou só colocar isso no slide e encerrar por aqui. Certo, acho que não temos tempo para perguntas; podemos conversar à parte, se vocês tiverem um tempo. Mas espero que isso tenha sido útil e dado algumas ideias sobre o que estamos vendo em produção, com bilhões de chamadas em grande escala. Certo, obrigado.

Transcrição original

[00:01] [music] Let’s just do a couple of quick questions and then we’ll jump right in. Uh, how many of us in the room here have built voice AI agents? Okay, that’s a that’s a pretty good audience here. And how many of you guys have built AI agents that have been deployed in production?

[00:34] Not bad. Okay, cool. So, uh we’ll talk about what typically happens, right? Like everyone’s talking about wise AI agents. Uh the you know, one pill solution to pretty much everything in the world today uh is is wise agents. So, everyone’s building one and trying to deploy that. They sound great when you’re sort of building that in your dev sort of landscape and then the moment you take this to from a proof of concept to production things start failing. Uh so we’ll walk through these five different angles of like how

[01:09] uh or what we have seen uh at PO with VIA agents but just before that a quick uh intro from from my side uh I am Wenke the founder and CEO uh she used the title agent engineering manager u I’m calling myself chief agent officer uh from a from a title standpoint u okay so what is what is uh you know why why are even qualified for this this discussion and and like uh what what are we seeing

[01:39] that a lot of companies don’t get to see? I I’ll talk a bit about our journey in terms of like how we’ve uh come along so far and then jump right in. Uh you know we were we’ve been around for about 14 years. Our journey has been a developer API platform and then now an uh you know an AI agent business. We started with voice and SMS APIs back in the day uh 2011 and then uh you know now we are primarily focused on our AI agent offering uh the the full stack on our

[02:10] platform. We we see over a billion voice calls each month across the globe. Uh and which is where we’ve seen a lot of these uh you know patterns emerge in terms of like how when we work with our customers what happens on their voice agents in in production. Uh we’re a uh 90 member team and uh we’ve we have uh 50 million funding in the bank. Fun fact, this is not from external VC investors. This is all from being a profitable company having put that cash in the bank over over these years. Uh some customers we we power across the

[02:46] globe. Uh you know, we’ve just left some some logos in there. But primarily from an offering standpoint, u I would sort of cohort this into three different buckets. One is a programmable AI agent offering. We call it uh I mean it’s a speech pipeline, not a true speech-to-pech product yet, but that’s a that’s a programmable offering. We also have an AI agent studio. It’s a no code visual uh builder. And then we like I said, we started with voice APIs. So we obviously have built this out over the last 14 years, the SIP trunking and the

[03:18] audio streaming layers. So we don’t rely on other folks for the telefony or the carrier layer. Like that’s the breadandbut business we’ve built over all these years and and that’s on top of which our AI uh agent platform sits. Okay, with that uh let’s get into this, right, which I’m I’m sure since you guys have all built AI agents, you’ve all seen this or you know built this in in one manner or another and we’ll spend more time on this in terms of like how uh the entire pipeline looks, right? Uh what we see with customers is and and

[03:52] I’m sure you guys can all relate to this is you know anyone thinking about AI agents what they do is they pick a bunch of these orchestration frameworks and they do a pretty good job live kit or a pipecat you know build their AI oen on top of that uh they think they can just sort of orchestrate these different four layers speechtoext lm uh and and TTS with turn detection in between and we’re off to the races like my AI engine agent works in a in a P and it’s good to work in production. Uh typically that’s what happens. They sort of measure their

[04:24] latencies and you can see some indicative latencies on on this slide at at each layer and they’re like yeah this this uh seems good for me for what I need. So let let’s position production and then the the production w uh sort of start to kick in and and you see all sort of failure modes which we are going to spend you know most of the time on on in this talk at least. Uh I’ve kept some time at the end for Q&A if you guys want to have uh you know questions but we’ll jump right in from from this to uh you know different failure modes we see.

[04:57] Let’s start with you know the first one which everyone talks about like this is the most spoken about failure mode which is latency. U I think we have a few AI agent talks today or AI agent talks today. Um I’m pretty sure like everyone everyone’s going to touch upon this specific failure mode which is why I’m bringing this right up uh in in terms of uh you know some like how this entire experience is for uh users right uh typically most folks

[05:27] measure this by time to first audio so the time when you user stop speaking to your agent starts speaking right and I think you’ve you’ve probably seen this if you guys have built voice agents on, you know, what uh good or natural feels like, what uh sort of annoying feels like or noticeable feels like, and then what annoying feels like, which is, you know, different tiered steps. Uh we notice, you know, most people want to be under 550 cuz that’s what’s advertised

[06:00] by, you know, platforms or uh you know, solutions or or or or layers. But I think most end up between 750 to 1.2. uh that’s where most of the folks end up at. Uh the really bad performing ones end up you know more than 1.2 and then you start to see users uh hang up. Uh now I I’ll share with you like what we’ve seen practically in in uh production with uh customers using this with at at different layers and then you know solutions to uh some of these. The

[06:32] way we want to think about this layer is sort of a balance between these three which is cost, intelligence and latency, right? And and and why do I bring these three up? Because they’re sort of interrelated. I think one of the things I was just chatting with uh you know a couple of folks outside one of the things last one year we’ve seen lot of innovations lot of intelligence spike on the LLM side of uh things right and most of the you know intelligence has come in

[07:02] in terms of thinking or uh you know reinforcement learning and and so on and so forth the irony with voice agents is like almost always your the the LLM or the agent that’s talking has to have thinking turned Right. So all the advancements we’ve had in the LLM layer in the last one year like none of that even apply here now. Right? You obviously you have you know better models that can do you know better instruction following or tool calling but pretty much all of your intelligence that’s been built in on the

[07:34] thinking layer is all off by default if you want it to be fast enough. So so that’s one of the ironies that we come up with. So then how do you sort of balance intelligent cost and latency? Let’s let’s look at some of these uh you know options uh that are out there in the market right so and I’m specifically picking LLM because if you looked at the previous chart LLM is u you know sort of your highest latency bucket that adds to this right and uh if you look at you know frontier models which I think most folks start by default your your openi

[08:09] your clouds your geminis u you know p50 ttfftd is roughly around 450 to 500 on on a good day and it can get spiky, right? It can it can uh you know P90 P95 can go easily upwards of 1.2 1.3 seconds even uh and and that’s not good for the overall agent experience. So so that so that’s your frontier model. Now there’s another options which is your your cerebrus or or the gro that is famous and popular for spitting out a lot of tokens or or tokens very fast,

[08:42] right? uh these work but for you to get dedicated latency or time to first token on these you need dedicated capacity and that is really expensive that’s where I spoke about the cost uh as as being one of the things to balance right it’s really expensive and then like you talk to anyone from the gro team or the cerebrus team they’ll tell you you need to book 12 months in advance for dedicated capacity they’re booked out for the next 12 months so so that’s that’s a pretty expensive option and then you really need to be sure that the model you’re deploying on some of these infra layers uh will be here 12 months

[09:17] from now and and it’s a it’s a big investment and a big unknown. So, so what’s a realistic option for production grade uh agents that are that are good quality and end up balancing uh three of these u this is what has worked for us u which is the open source models u there are obviously a lot of them in terms of like the variety and and variations you can pick I’m specifically talking about the two we work with u quen 3.5 and gemma

[09:50] four. These are uh you know kind of cutting edge open source models right uh out in the market right now and we’ve done a lot of benchmarking around this in how they work. It it can be scary to think like okay I have the models now I have to host them you know run them on my own GPUs and so on and so forth but if you are consistently targeting under 300 ms u this we’ve seen this to be a a great option to balance between latency cost and intelligence now some more deep

[10:24] dive here if you’re doing only English uh quen 3.5 or GMA both work fine but if you’re doing multilingual uh right international audiences different languages uh Gemma 4 is a much better model for that uh we’ve seen uh token fertility evals essentially what that means is if if I were to dejargonize that is like how many tokens does it take to generate one word in that language okay so Gemma is much much better at least 2.5 to 3x better than

[10:55] quen 3.5 from that perspective so your time to words is much faster on Gemma or everything else equal right on a on a multilingual basis. Now what sizes do you pick at the LLM layer? Uh the mixture of expert usually works fine. Uh the three or four billion mixture of expert usually works fine. The the problem with mixture of expert is like if anyone goes down wants to go down the direction of fine-tuning that can be a challenge uh because fine-tuning mixture of experts models are not easy. Uh you can end up breaking the model uh a a lot

[11:30] of times. So, so that’s one challenge we see with Make sure experts, but usually out of the box, it gets you 90% closer to where you want to be like even without any fine-tuning or or or custom work done on the model. Uh so that’s the advantage of mixer experts. Uh now, if you want to fine-tune and and you you want to go deeper and say like look, I’m working for a specific domain, healthcare, what have you, right? uh and I want to make sure I I’m able to fine-tune my model. You want to start at least with uh the 8 billion 12 billion

[12:00] at least uh from where we are today. Maybe maybe six months from now a 4 billion 4 billion model beats the 8 billion model uh hands down. But for today uh what we’ve seen is you minimum need a 8 billion or 12 billion model. Uh cuz you’re looking for two things in these models. One obviously fast tokens but uh good instruction following. Okay. And the second thing is like very high uh success ratio in tool calling because if you can do these two things well then

[12:30] you are on to like 70 80% there from not even having to fine-tune it fine-tune any model like models will work out of the box right u so so that’s uh been our recipe we’ve actually uh we run two flavors one a fine tune model for specific industries and then for uh you know most generic use cases uh MOE model just works out of the box. Uh there are a few more tips and tricks we’ll talk about in the upcoming slides where we see failure models, but but that’s where we stand from a from a latency LLM standpoint. Um all right,

[13:06] I’m running tight on time, so I’m going to fast track this. U now there are a couple of other flavors in this. Uh people build agents with a a mixture of models. What they do is you know for u the the talking part of it they have a conversational model which is a much lower smaller model and then you know maybe even a three billion model and then for tool calling they have a much larger model so that they have a improved tool calling success ratio there. Uh sorry the second one is uh assume your transcriptions are going to be brittle

[13:41] like that’s that’s uh something you want to sort of uh live by when you’re building AI agents even if you have the best transcription engine out there and I I I’ll show you why right like the the the state-of-the-art transcription engines out out in the market u you know sort of get you to four to 6% word error rate right and this is on known eval sets on real world noisy calls with you know sort of uh accents like people having different sort of accents uh

[14:14] domain vocabulary and so on and so forth like those usually end up in the double digits from a word erate perspective right uh now you obviously you can fine-tune you know pick up an open source model and fine-tune uh but we see typically like what breaks here often and there are patterns s here in terms of what breaks. So, proper nouns, jarens, uh phone numbers like random missing digits with phone numbers, uh wrong substitutions. I I’ll walk through some examples of like how you solve for these addresses when you’re trying to collect a long address. Uh you know, the the transcription engine could just end

[14:49] up missing some parts of it. Code switch languages. I I’ll just take a example of a language I speak because that’s was easy for me to put on the slide. uh where you know like if you were to sort of take English but written in a different script uh that’s what’s used for Hindi right like this is English written in that script right whereas like the actual English version of this is hello how are you so if if I’m addressing an audience in a different country where I have code switched languages and I start getting my English in a different uh sort of script everything starts breaking from

[15:24] the transcription engine to the LLM layer and then beyond because your LLM starts then producing output in that sort of script a lot of times and then your TTS messes up. Okay. So, so this is uh very important to be careful about and if you want to build your agent independent of the transcription engine, you need to build a layer that normalizes all of this, right? We’ll talk about solutions in a minute. And there is the other case which is Hindi in Latin or or or you know Roman, right? Which is like this is Hindi but it reads English which again messes up everything uh you know downstream. Those are just

[15:58] examples. This applies to, you know, Arabic, Mandarin, uh, Japanese, what have you. Uh, pretty much any language. So, what actually moves the needle with a at the transcription layer? Uh, for prop proper nouns, we recommend uh you using not just keyword boosting. I think a lot of transcription engine engines provide you keyword boosting where you can put in specific words into their engine, but doing dynamic keyword boosting. What that means is don’t keep the keyword for the entire state of the call. just add that dynamically when you

[16:29] think you need that as an answer so that you get the highest accuracy. Meaning at different states of the call, the transcription engine will have different uh keywords boosted during different phases, right? Uh and that’s what we’ve seen works best because if you just pollute your context of the transcription engine with tons of keywords, it’ll start hallucinating again, right? So, so that’s what we see typically working best. Uh yeah, post-process post-process your transcripts with an LLM, right? Cuz your LLM has domain context. Your transcription engine does not. So a lot

[17:02] of words that it would say uh I’ll give you some examples may not make sense. This is transcription like a phone number from a transcription engine. Right? Like what do you think that E is? Right? If you give it to an LM, it knows that’s a three. Similarly, like what that one is, it’s a digit one. So, so your transcription engine a lot of times could mess that up, but when you postprocess it with the LLM layer, it’ll instantly correct that from a collection standpoint. I mean, uh, and and the last one, like I said, uh, transliteration is

[17:33] your ST output that’s sort of u, you know, multilingual also gets normalized using either an NLM you first transliterated or, you know, use some kind of a neural uh, transliteration engine. There are a lot of them open source. You can just pick one of them, right? Uh that would do all of that work for you. Send cleaned transcripts consistently independent of the transcription engine to your LLM. All right. The third one we typically see is collecting data. This is where I

[18:04] think 50 to 60% of AI agents mess up pretty badly. Uh and like we like to think of it as a UX problem. Uh but just for voice. So think data models uh and not a transcript coming into an LLM and and trying to figure out what the transcript said. So let’s take some inspiration from uh I’m assuming most of us are developers here um you know take inspiration from Python’s data classes pantic zod from Typescript or form

[18:35] fields in the UI right like if you start thinking of it from that problem statement we have seen accuracy grow up from grow from 30% to like 95% from a data collection standpoint when you start thinking in that manner. So like decide your shape before you ask, right? Like instead of keeping it open-ended, can you keep it constrained? So can can a phone number be a phone number type field? The moment you do that, right, you know like how many digits it needs to have. You can do validation on on top of that, right? And then what sort of

[19:08] allowed values can even be there. So in the previous example we saw if an E comes in in middle of a phone number and you know it’s a phone number you instantly know like either you smart guess that to three and confirm that with a user or you know that’s an error and then you validated that and asked the user to repeat again right so so that’s I think one of the common patterns we’ve seen here from from a a collection pattern name I think is the is the interesting one I’ve just picked a you know a a hard to pronounce name

[19:40] like There’s no way a human is going to get this right and and no way a transcription engine will get this right. How many ever times you do this right? So the moment you start thinking of this as fields and then have rules and then confirmation mechanisms on on spelling this uh you know sort of uh letter by letter only then you kind of get it right otherwise it’s going to mess up pretty badly in terms of how you collect this on a voice call and and that’s just an example of you know what u I’m talking about in terms of the the data collection piece of it. Another place where it goes badly

[20:14] dramatically is relative uh values. Date being one of the examples. If somebody says next week uh Wednesday 8, 8 could mean 8:00 a.m. 8:00 p.m. and then figuring out what that date actually is. Again, now becomes a very constrained problem. If you knew this was a datetime field and I I’m collecting a datetime field and then you take the current date and then figure out what this value would be bases that, right? So, so that’s how you want to make sure like uh you do this with a combination of the LLM with the tool calling and the tool

[20:44] calling is doing a lot of this heavy lifting for you from a from a field standpoint. Yeah. And then you make you you run like this from a unit test perspective. So all of your u evals need to start treating these fields as unit tests. And as long as your unit tests uh sort of validate and pass, you know, your agent is going to be uh sort of reliable and repeatable. You don’t, you know, run uh hundreds of end to end agent test cases just to find out, you know, one field

[21:15] collection is broken. You do your eval at a field level and a unit test uh level. And then yeah, like I said, I think u you this this mindset makes everything more structured instead of hoping I’ll put a ton of prompt, keep changing, you know, the prompt by a few uh characters every time and somehow my prompt engineering is going to make LLM much more instruction tuned and sort of magically start following some of these things. So in fact u like I said right

[21:47] like we have seen us get to 95 97% accuracy without having to fine-tune a model right and then and the trick is basically like just breaking down your context of what the agent is doing at that point with specific u states of what the agent is going through. All right u I’m just going to quickly u skip through this from a time standpoint. I just see I got three more minutes. Um hopefully that’s a bug but but we’ll leave it at that. Okay. Um

[22:19] so so this is the fourth area where we see issues coming in. Most folks take the LLM output and then we send it to a TTS. Obviously I think there are a lot of good TTS’s in the market that take care of a lot of heavy lifting but a lot of times it it messes up. Uh what we recommend and what we’ve seen is you usually want to have a normalization layer between your LLM and what is fed to a TTS. You don’t send your LLM output directly to a TTS, right? And and we’ll

[22:49] just walk through some examples. The basics which is strip emojis uh markdown before before any synthesis into the TTS. Most orchestration pipelines do this like you know a live kit or a pipecat would do that for you if you just set a few flags. So I but but just make sure if you’re not using them or buildings from scratch that you’ve set this explicitly because you don’t want an emoji showing up on on on something read out or you know markdown showing up there. Okay. I think I think some more common

[23:19] ones uh custom uh dictionaries most TTS engines provide this to you like how to pronounce custom words whether it’s you know proper nouns brands uh acronyms and so on and so forth. So set those in uh when you go from your LLM to your TTS output because if you don’t, you’re going to mess that up. And I I’ll I’ll show you an example of like how we test that. Uh the the other one is like most engines also give you speed. So if you know you’re pronouncing an entity, slow down. Have your agent slow down. So at point 8x or 7x so that it it’s able to

[23:54] like inunciate on that specific entity and and doesn’t mess up how it’s pronouncing an email or a phone number or a name letter by letter and yeah just normalize all the messy stuff right like emails currency dates don’t leave it to the TTS to do it uh most of them do it but don’t leave it to the TTS to do it like build your normalization layer at your end so that tomorrow you think you need to switch TTS or you know for whatever reason the first one’s down and you want to use another TTS you’re able to sort of not

[24:28] rely natively on the TTS’s engine but you are building this in-house uh for for this to be managed and then yeah u I think I don’t have my batch here but I I don’t have my last name on that so my first test is if it cannot pronounce my last name or my company’s name it’s already dropping the ball so my last name is uh Balas Subramanion and if you cannot pronounce that using a voice AI agent uh like that’s a check for me. I I know like uh

[24:58] you know the agent will mess up a lot of words that uh you know need to be spelled out day by day. The second one is our company name Po. So a lot of engines pronounce pronounce it pivo or uh pleo and and so on and so forth. But but I think specifically being able to control this in your pipeline is super critical. And then if you’re building a if you’re building a customerf facing product then then um you know sort of give this option to your customers. All right I’m just going to skim through the the the last two slides. U I’m I’m

[25:31] running badly over time. Uturn detection. I think this is it own separate topic but I’m just going to quickly pull up all the points so you guys can skim through that and if if you need a chat u after this we can we can talk about this. Right. Uh I’m just going to leave that for like five seconds and then and then we can chat about this offline. I’m quite over time. And then the the the last one is uh bargin and and back channeling. I think there’s a lot of talk around speech to speech models that do some of this, but we’ve been able to see how we could do all of this in speech to speech

[26:04] pipelines. You really don’t need a speech to speech model to do all of this up. Uh again, I’ll just I just put put this up on the slide and and sort of close at that. Um all right I don’t think we have time for questions we can take them offline if you have any time but uh hopefully this was helpful and gave you some insights on uh what we are seeing in productions uh with billions of calls at scale. All right thanks