Como criar agentes de voz que não desmoronam quando você os interrompe — Jesse Hall, LiveKit
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: How to Build Voice Agents That Don’t Fall Apart When You Interrupt - Jesse Hall, LiveKit · Canal: AI Engineer · 20:26 · Assistir no YouTube
Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos multimodais
Jesse Hall explica por que agentes de voz em tempo real precisam ser avaliados como conversas completas, e não pela classificação isolada de cada modelo. Ele aborda como medir a latência que as pessoas realmente percebem, manter a conversa enquanto ferramentas trabalham em segundo plano e detectar quando o usuário terminou de falar. Para escolher uma combinação de modelos adequada, propõe testar o agente completo com simulações realistas e repetir os testes ao trocar os modelos. A apresentação também recomenda transformar falhas encontradas em cenários de regressão e testar continuamente os resultados, a segurança e as interações.
Pontos-chave
Seção intitulada “Pontos-chave”- Agentes de voz são sistemas em tempo real; não basta conectá-los a um chatbot com saída de áudio.
- Classificações de modelos isolados não indicam qual combinação funcionará melhor em uma conversa real.
- Meça o tempo até o primeiro áudio e até a primeira frase, não apenas o tempo até o primeiro byte ou token.
- Agentes devem manter a conversa enquanto chamadas a ferramentas são executadas em segundo plano.
- A detecção de turnos deve considerar características do áudio, como ritmo, entonação e pitch, além da transcrição.
- O orçamento de latência vai da última sílaba do usuário à primeira resposta audível do agente.
- Simule usuários que mudam de ideia, interrompem, murmuram e falam com ruído de fundo.
- Avalie o resultado final e também os passos executados, incluindo chamadas desnecessárias ou alucinadas a ferramentas.
- Use entradas idênticas ao comparar combinações de modelos e crie um benchmark específico para cada agente e caso de uso.
- Transforme falhas descobertas em cenários de regressão e repita os testes.
Capítulos
Seção intitulada “Capítulos”| Início | Capítulo | Resumo |
|---|---|---|
| 00:01 | Por que agentes de voz desmoronam quando são interrompidos | A apresentação introduz os desafios de conversas em tempo real e o maior risco de erros em situações financeiras. |
| 03:24 | A complexidade dos modelos e dos pipelines de voz | Hall apresenta a LiveKit e compara o pipeline tradicional de três modelos com modelos speech-to-speech. |
| 07:08 | Latência percebida e ferramentas em segundo plano | A palestra recomenda medir o início do áudio e da primeira frase e permitir que o agente continue conversando enquanto ferramentas trabalham. |
| 12:27 | Detecção de turnos e orçamento de latência | O apresentador explica como reconhecer quando o usuário ainda está falando e como o tempo entre turnos afeta a naturalidade. |
| 15:36 | Como comparar combinações de modelos com simulações | Hall descreve testes repetidos com cenários realistas e entradas idênticas para construir benchmarks específicos para cada agente. |
| 19:20 | Checklist para melhorar agentes de voz | A conclusão reúne recomendações para validar informações, testar a conversa completa e transformar falhas em cenários de regressão. |
Citações
Seção intitulada “Citações”Operador, aperte zero; me passe para uma pessoa. — 01:08
Um byte não é a mesma coisa que áudio. — 07:08
A pergunta é: quão humano pode ser o agente dentro dessa janela de latência? — 14:34
Um agente de voz não é apenas um chatbot com um alto-falante conectado. — 18:49
Conceitos e entidades
Seção intitulada “Conceitos e entidades”- LiveKit (empresa): Empresa que oferece uma infraestrutura e um framework open source em tempo real para agentes que podem ouvir, ver e falar.
- Jesse Hall (pessoa): Apresentador que explica como construir e avaliar agentes de voz mais naturais.
- OpenAI (empresa): Empresa cuja funcionalidade Advanced Voice Mode do ChatGPT é citada como exemplo de agente de voz.
- cascaded pipeline (conceito): Arquitetura tradicional de agente de voz que combina speech-to-text, LLM e text-to-speech.
- speech-to-speech models (conceito): Modelos que substituem o pipeline tradicional ao processar fala e gerar fala diretamente.
- turn detection (conceito): Detecção de quando o usuário terminou de falar, levando em conta a transcrição e características do áudio.
- time to first audio (conceito): Métrica do tempo até o usuário começar a ouvir a resposta do agente.
- time to first sentence (conceito): Métrica do tempo até o LLM produzir a primeira frase que o modelo de text-to-speech pode começar a falar.
- time to first byte (conceito): Métrica de latência que mede o tempo até o primeiro byte, mas que não indica necessariamente quando o usuário ouvirá áudio.
- Gemma 4 31B (modelo): Modelo que obteve a melhor classificação no benchmark apresentado para o agente de recepção de hotel.
- LiveKit inference (ferramenta): Serviço de inferência da LiveKit, apresentado como otimizado para cargas de trabalho de voz.
Tradução completa (pt-BR)
Seção intitulada “Tradução completa (pt-BR)”00:01 [música] >> Certo, vamos falar sobre agentes de voz. E a maioria dos agentes com que lidamos no dia a dia faz coisas em segundo plano, certo? Eles escrevem código para nós, fazem pesquisas. Damos algo para eles fazerem, uma tarefa, e vamos embora; voltamos depois, e não nos importamos muito se demorarem mais 10 segundos,
00:34 mais 10 minutos, às vezes talvez 10 horas, certo? E esperamos isso. Mas, em algum momento do último ano, mais ou menos, você provavelmente interagiu com outro tipo de agente: um agente em tempo real. Talvez quando ligou para a farmácia, talvez quando ligou para a companhia aérea. Conversei com um desses outro dia, quando liguei para uma concessionária. E, em algum momento dessa conversa, você fez a coisa mais humana possível. Falou por cima dele. Interrompeu-o. Confundiu-o. E a conversa inteira desmoronou, simplesmente
01:08 não pareceu natural. E então você fez o que eu faço todas as vezes: “Atendente, aperte zero”, tipo, “me passe para uma pessoa”, certo? Então, como corrigimos isso? Como tornamos esses agentes o mais humanos possível? E, por exemplo, no setor financeiro, e se a pessoa que ligou estivesse ligando para agendar um pagamento e mudasse o valor do pagamento no meio da conversa, mudasse a data, e o agente não acompanhasse, certo? É aí que começamos a ter problemas, especialmente no setor financeiro.
01:42 O risco é muito maior, certo? Então, como corrigimos isso? Vamos falar sobre como criar agentes de voz com jeito humano para serviços financeiros. Quando pensamos em criar um bom agente de voz, uma das primeiras coisas que vêm à mente é a latência. Precisamos que ele seja o mais rápido possível, certo? Bem, a latência é parte da equação. A latência tem um orçamento finito, e vamos falar sobre isso. Mas a palavra-chave aqui é “com jeito humano”. Como tornamos esses agentes de voz o mais humanos possível? Esse é o objetivo. Então, há várias pessoas que estão
02:17 falando sobre voz ultimamente. Algumas delas talvez sejam familiares. Temos esse cara, Sam. Ele está empolgado com modelos de voz. Ele diz que eles estão começando a mudar a forma como interagimos com a IA. Não é verdade? E então temos esse nome estranho aqui no canto inferior direito, Swyx. Não sei se já ouviram falar dele. Ele diz que essa é a modalidade original. A modalidade correta para alinhar a AGI às nossas intenções é uma IA de voz muito boa
02:49 e a engenharia. Essa é uma afirmação bem ousada. E então, como diz Get, aprendemos a falar antes de aprender a ler. Certo? A voz é a interface mais natural que temos. Então, como podemos torná-la o mais natural e humana possível? Levantem a mão rapidinho: quem aqui já criou um agente de voz e fez o deploy em produção? Certo, estou vendo algumas mãos. Então, alguns de vocês conhecem os desafios que podem enfrentar ao fazer isso. Outros aqui que nunca criaram um talvez tenham visto um exemplo muito bom
03:24 de um. Vocês já usaram o modo de voz avançado do ChatGPT para conversar com o ChatGPT? Certo, legal. Aproveitando o assunto: a OpenAI escolheu a LiveKit para dar suporte a essa funcionalidade. Então, é um ótimo caso de uso ou um ótimo exemplo de um bom agente de voz. A LiveKit é o framework e a infraestrutura open source de tempo real para esses agentes com jeito humano. Agentes
03:56 que conseguem ouvir, ver e falar com uma pessoa do outro lado. Portanto, na verdade, não estamos falando apenas de voz. Há várias maneiras de interagir com agentes: voz, vídeo, fluxos de dados, até IA física. Também temos uma divisão de robótica, mas a voz é o ponto de entrada, é a modalidade mais natural, e é onde há muitos desafios. Então, hoje vamos nos concentrar apenas na voz. Em um agente de voz tradicional, há o que chamamos de pipeline em cascata. São três modelos
04:28 que trabalham juntos. Temos o modelo de fala para texto, o LLM e o modelo de texto para fala. E todos precisam funcionar em conjunto. Também existem esses outros modelos, modelos em tempo real, modelos de fala para fala, certo? Eles substituem esse pipeline. Mas esse conceito é mais recente. Está melhorando, mas ainda não está pronto para todos os casos de uso, certo? Mesmo assim, temos o pipeline tradicional com três modelos e os modelos de fala para fala. Há tantas opções e tanta complexidade. Por onde começar? E aqui estão as opções
05:00 entre as quais podemos escolher: centenas de modelos, dezenas de provedores. Levantem a mão rapidinho: quem já escolheu um modelo com base em um ranking? Você escolhe o modelo que está no topo do ranking e é esse que vai usar, certo? Bem, vamos falar sobre por que isso não funciona para agentes em tempo real. Não podemos simplesmente escolher modelos do topo de um ranking, porque os rankings avaliam esses modelos e componentes individualmente, mas o que lançamos é uma conversa. Precisamos conseguir avaliá-los em conjunto. Então, vamos falar sobre como fazer isso. Vamos analisar um cenário. Suponhamos que uma pessoa ligue
05:32 querendo pagar a conta. Ela diz: “Quero pagar no dia 3”. Mas o modelo de fala para texto entende “dia 30”. Então, o LLM passa a planejar para o dia 30, e isso vai para o sistema. O LLM não tem como saber que o modelo de reconhecimento de fala errou. E, assim, todos esses erros vão se acumulando a partir daí. E o ranking não consegue nos mostrar isso. Não consegue avaliar isso porque estava analisando os modelos individualmente, certo? Além disso, esses rankings
06:04 avaliam os modelos com base em áudio limpo. Mas as pessoas ligam pelo viva-voz, no trânsito, com crianças no banco de trás, certo? Então, precisamos conseguir avaliar nossos próprios agentes com base em casos de uso e exemplos do mundo real. Digamos, então, que caiamos nessa armadilha do ranking. Simplesmente escolhemos um modelo. A primeira pergunta que as pessoas fazem é sempre: “Qual modelo devo escolher?”. Então, usam um ranking e escolhem um modelo, mas a pergunta que deveríamos
06:34 fazer é: “Qual stack devo lançar para o meu caso de uso?”. E é isso que vamos descobrir. Como respondemos a essa pergunta? Antes de responder, digamos que você escolheu alguns modelos e começou a medir o desempenho deles. Vamos dizer que está testando seu provedor de TTS. No painel, o provedor de TTS informa o tempo até o primeiro byte. E esse valor parece muito rápido: 210 milissegundos até o primeiro byte. É muito rápido.
07:08 Mas testamos muitos provedores populares que, depois desse primeiro byte, ficam até três quartos de segundo em silêncio. Então, um byte não equivale a áudio. O que estamos realmente procurando é o tempo até o primeiro áudio. Quanto tempo leva para a pessoa começar a ouvir alguma coisa? É o tempo até o primeiro áudio que deveríamos medir, não o tempo até o primeiro byte. Então, imagine que o pagamento foi processado e você pergunta: “Meu pagamento foi processado?” E então você ouve dois segundos de silêncio. Isso não é muito tranquilizador, certo? Precisamos conseguir medir esse intervalo que a pessoa ouve. Agora, acontece o mesmo com os modelos de linguagem grandes. O tempo até o primeiro token é o que obtemos em texto. É uma medição baseada em texto, mas tokens também não equivalem a áudio, certo? Seu TTS não pode começar a falar a partir de um token. Um modelo de texto para fala precisa, na verdade, de uma frase inteira para começar a falar.
07:41 o pagamento foi concluído?” E então você ouve 2 segundos de silêncio. Isso não é muito tranquilizador, certo? Então, precisamos conseguir medir esse intervalo que a pessoa ouve. Agora, a mesma coisa vale para os LLMs. Então, o tempo até o primeiro token é o que temos no texto. É uma medida baseada em texto, mas os tokens também não equivalem ao áudio, certo? O TTS não pode começar a falar a partir de um token. Um modelo de TTS, ou seja, de conversão de texto em fala, na verdade precisa de uma frase inteira para começar a falar.
08:15 E então, o que precisamos medir é, na verdade, o tempo até a primeira frase. Porque um LLM que produz tokens muito rápido nem sempre é o mesmo LLM que produz a primeira frase mais rápido. Então, o tempo até a primeira frase é o que devemos observar. Outra coisa que a maioria dos rankings não mede é que esses agents precisam fazer coisas. Eles não estão aqui só para conversar conosco. Precisam conseguir fazer coisas no backend. Precisam consultar uma transação, verificar um pagamento
08:46 status, abrir uma contestação, certo? E isso leva tempo: 2, 10, 40 milissegundos. Então, como lidamos com isso? Como escondemos 40 segundos ou mais de latência? Bem, não podemos. Essa é a resposta: não podemos. Mas pergunte a si mesmo: o que uma pessoa faria nessa situação? Uma pessoa simplesmente ficaria em silêncio enquanto o sistema está fazendo alguma coisa? Não, ela diria: “Me dê um segundo. Vou consultar isso. O sistema está um pouco lento, mas já está quase pronto.” Ou continuaria
09:18 e faria outra pergunta enquanto o sistema está fazendo algo no backend. Esse é o comportamento humano, realizar várias tarefas ao mesmo tempo, certo? Nós conseguimos fazer isso. Então, por que os agents não podem realizar várias tarefas ao mesmo tempo e fazer isso também? Bem, essa era uma pergunta capciosa, porque eles podem. E devem. Devem ser capazes de fazer isso. E esta é a estrutura disso. Este é o único código que vou mostrar nesta palestra, mas esta é uma chamada de ferramenta normal, e uma linha faz toda a diferença. Esta linha, esta atualização, este async await, este await desta chamada de ferramenta
09:51 é todo o truque, e é isso que devolve o microfone ao agent. Isso permite que a conversa e a ferramenta deixem de compartilhar uma thread. Agora são separadas. E é isso que, mais uma vez, torna o agent mais parecido com uma pessoa, porque ele consegue manter a conversa enquanto algo acontece no backend. Então, não acreditem só na minha palavra. Tenho uma demonstração rápida aqui; vamos ouvir e ver como soa. >> Obrigado por ligar para o The Gilded Rose Hotel. Como posso ajudar?
10:23 >> Sim, gostaria de reservar um quarto. >> Para quais datas? >> Na semana que vem, de quarta a sexta. >> De quarta-feira, 30 de julho, a sexta-feira, 1º de agosto? >> Isso mesmo. >> Quantos hóspedes ficarão hospedados? >> Dois. >> Tenho quarto com duas camas queen, quarto com cama king, quarto com duas camas queen, uma suíte ou a cobertura. >> Você prefere vista para a cidade ou para o oceano? >> Oceano.
10:54 >> Qual é o seu nome para a reserva? >> Jesse Hall. >> Jesse Hall? >> Sim. >> Qual é o seu e-mail? >> me@me.com >> me@me.com está correto? >> Isso mesmo. >> E seu número de telefone? >> 555-123-4567 >> 555-123-4567?
11:25 >> Isso mesmo. >> Vou precisar de um cartão de crédito para garantir o quarto. Qual é o número? >> Vamos parar por aqui. Certo, vocês perceberam que a conversa continuou. Não houve pausas estranhas. Eu até interrompi, e ele simplesmente continuou, certo? Não desandou nem pareceu artificial em momento algum. E aqui podemos ver as chamadas de ferramenta que estão acontecendo ao longo do caminho e as coisas que ele está fazendo. Ele está realmente se comunicando com um backend e salvando cada
11:55 informação que eu forneço. Mas o que ele faz é não esperar o backend dizer: “Certo, isso foi salvo. Agora pode passar para o próximo.” “Certo, isso foi salvo. Passe para o próximo.” Ele passa imediatamente para a próxima coisa. Mantém a conversa fluindo. E se, por algum motivo, uma chamada de ferramenta retornasse um erro ou algo assim, ele se corrigiria. Diria: “Deixe-me verificar isso ou aquilo, o que quer que tenha acontecido, certo?” E, na pior das hipóteses, se estivesse tendo problemas, ele realmente me encaminharia a uma pessoa, nesse
12:27 caso, certo? É assim que nossos agents devem funcionar. Agora, há mais um aspecto: o agent saber quando falar e quando ouvir, quando continuar ouvindo. Isso se chama detecção de turno. O LiveKit tem um detector de turno integrado que não escuta apenas a transcrição, como a maioria dos detectores de turno. Ele também escuta o áudio. Escuta o ritmo, o tom e a entonação. E
12:58 publicamos os números sobre isso. A principal alternativa ainda interrompe os usuários e os corta 9,9% das vezes. No nosso caso de uso, a nossa faz isso 4,5% das vezes. Testamos com o nosso agent de hotel e outros. E esse foi o resultado que obtivemos nos nossos casos de uso. Tudo isso é open source. Você pode executar esses evals com seu conjunto de dados e ver quais números obtém. Veja se consegue números melhores, mais altos, aqui. E, mais uma vez, esta é apenas uma pequena peça do quebra-cabeça para tornar esses
13:31 voice agents mais parecidos com pessoas: eles saberem quando parar de falar ou quando ouvir. Por exemplo, se eu estivesse tentando fazer um pagamento e dissesse que gostaria de pagar 500 e 55,23 dólares, certo? A maioria dos detectores de turno teria parado em 500, porque viu 500 na transcrição e viu uma pausa de dois segundos: “Ele deve ter terminado”, certo? Mas o nosso teria ouvido minha entonação, percebido que eu ainda não tinha terminado de falar e teria esperado.
14:02 Então, vamos olhar agora para esse orçamento de latência, essa lacuna. É o intervalo entre a última sílaba de quem está ligando e a primeira resposta audível do agent. O detector de turno decide quando a pessoa terminou de falar, o modelo de linguagem começa a preparar uma resposta com base em uma transcrição provisória, e então o TTS começa a gerar o áudio assim que pode. E assim, cada modelo que você escolhe, cada função, cada transferência, tudo
14:34 isso acontece dentro desta janela, e essa janela tem um limite, um tamanho fixo. Então, se você conseguir ficar mais ou menos dentro de 1,5 segundo, a chamada ainda funciona, a conversa se mantém. Com 1,5 segundo, ela começa a parecer um pouco estranha. Mas, se você conseguir chegar a 500 ou 600 milissegundos entre esses dois turnos, é aí que ela realmente começa a parecer mais humana. Então, aquela pergunta de antes — quão rápido posso ir? —, precisávamos apenas ir
15:05 cada vez mais rápido. Essa não é a resposta. A resposta é: quão parecido com uma pessoa eu consigo fazer um agent dentro desta janela de latência? Então, mais uma vez, latência é um orçamento, e sabemos como nos manter dentro dele. Mas como podemos ser o mais parecidos possível com pessoas? Esse é o objetivo. Então, se juntarmos tudo isso, aquela pergunta — qual modelo devo escolher? —, nunca foi algo que pudéssemos responder. Mais uma vez, esses rankings não podem responder, porque se baseiam nos
15:36 modelos, mas nós estamos entregando uma conversa. Então, vamos responder à pergunta de verdade: como podemos escolher os modelos? Quais modelos devemos escolher? É isto que precisamos fazer: testar a conversa. Pegamos um agent completo e funcional. Aquele recepcionista de hotel que vocês ouviram há pouco: pegamos esse. Ele tem um backend real. É de verdade, não é só uma demonstração. Ele funciona mesmo. E é open source. Vocês podem conferir. Então, pegamos esse agent e o testamos com pessoas simuladas que ligam. Essas pessoas podem tentar alcançar objetivos, mudar de ideia e
16:08 interromper. Podem falar de forma indistinta. Podemos adicionar ruído de fundo. Podemos garantir que este seja um cenário do mundo real e executar todas essas simulações de usuários com aquele agent. Podemos executar simulações baseadas em texto, que testam apenas a lógica de negócios. Ou também podemos executar simulações baseadas em áudio, que testam os recursos de reconhecimento de fala. Testam a alternância de turnos. O pipeline de voz inteiro é testado ali. Então, usamos os cenários, e o cenário deve descrever o que a pessoa que está ligando quer e o que
16:41 as ações que o agent deve realizar, qual deve ser o resultado. E então damos uma pontuação a isso. Avaliamos esses resultados. No benchmark de hotelaria, por exemplo, a reserva correta foi registrada no banco de dados? Em um benchmark financeiro, o valor autorizado correto foi cobrado? E então verificamos esses agents. Garantimos que todos os resultados sejam alcançados. E não damos uma pontuação com base apenas na conclusão, porque sabemos que os agents podem manipular as métricas de conclusão. Precisamos garantir que eles tomaram as medidas certas. Precisamos fazer
17:11 com que eles tenham feito isso. Eles deram 10 passos quando deveriam ter dado apenas dois? Eles alucinaram uma chamada de função? Essas são as coisas que precisamos testar em toda a conversa. Depois, trocamos a stack. Mantemos o mesmo agent e os mesmos cenários, mas mudamos os modelos. E executamos esse ciclo novamente. A entrada é idêntica: todos os modelos recebem exatamente a mesma entrada, byte por byte. Trocamos os modelos e executamos o ciclo. Trocamos os modelos novamente e executamos o ciclo
17:43 continuamente, repetidas vezes. Nesse ponto, estamos criando um benchmark personalizado para nosso caso de uso, para nosso agent. Agora há tantos benchmarks quanto agents. Você executa isso com o seu e descobre quais modelos funcionam melhor na sua situação. Essa é a única maneira de descobrir qual modelo é o melhor para você. É assim que você encontra surpresas. Um modelo que responde mais rápido é o modelo certo para você, não é? E, surpreendentemente, esse modelo
18:16 talvez não seja o que está no topo do ranking. Mas é o melhor para o seu caso de uso. E, mais uma vez, esses benchmarks, as simulações e toda essa metodologia são open source. Então, você pode conferir por conta própria, executar com o seu agent e ver como ele se sai. Estes são os resultados desse benchmark no nosso agent de hotelaria. Este é o LLM que ficou em primeiro lugar para o nosso agent de recepção de hotel: Gemma 4 31B na inference do LiveKit. Note que, na segunda linha, o mesmo
18:49 modelo, Gemma 4 31B, em outro provedor, foi mais lento. O LiveKit otimiza o serviço de inference para cargas de trabalho de voz. E o LiveKit é agnóstico em relação a modelos, então você pode usar qualquer modelo que quiser. Mais uma vez, você conecta esses modelos e descobre qual deles funciona melhor para o seu caso de uso. Agora, se você se lembrar de uma coisa desta palestra, lembre-se disto: um agent de voz não é apenas um chatbot com um alto-falante conectado. Há muito
19:20 mais complexidade envolvida. É um sistema em tempo real que precisa responder como uma pessoa. Precisamos torná-lo o mais humano possível. E, quando o avaliamos desse ponto de vista, conseguimos construí-lo dessa forma. Aqui está uma lista de verificação. Você pode tirar uma foto. Precisamos definir o limite de latência que a pessoa que liga percebe. Medir o tempo até o primeiro áudio e o tempo até a primeira frase. Confirmar datas importantes. Quando se trata de dinheiro, precisamos garantir que essas verificações estejam em vigor. Verificar a identidade antes que uma conta seja acessada.
19:54 Continuar ouvindo enquanto ferramentas lentas são executadas. Manter a conversa em andamento. E então executar repetidamente a conversa completa em simulações. Testar o estado final, as proteções de privacidade, chamadas de ferramenta desnecessárias e a alternância de turnos. Todas essas coisas. E, quando você encontrar essas falhas, transforme-as em cenários de regressão e continue testando, repetidas vezes. Então, comece com um desses workflows ou com uma falha que seja importante para você. Continue iterando. Execute-o. Ouça a conversa. Confira o que
20:26 aconteceu no backend. Espero que, em um futuro muito próximo, todos nós liguemos para um desses agents de voz, falemos por cima dele, o confundamos, e ele simplesmente acompanhe a conversa, proporcionando uma experiência muito humana. Esse é o nosso objetivo, mas aqui está o que preciso de cada um de vocês: preciso que vocês construam isso. Obrigado. >> Uhu!
Transcrição original
[00:01] [music] >> Um all right, we’re going to talk about voice agents. And most of the agents that we deal with on a day-to-day basis, um they they do things in the background, right? They they write code for us, they do research, we give them something to do, a task, and we walk away, we come back, and we don’t really care if they take an extra 10 seconds,
[00:34] an extra 10 minutes, maybe sometimes 10 hours, right? Um and we expect that. But at some point in the last year or so, you have probably interacted with another kind of agent, a real-time agent. Maybe when you called your pharmacy, maybe uh when you called the airline. I talked to one just the other day when I called a car dealership. And at some point in that conversation, you did the the most human-like thing possible. You spoke over it. You interrupted it. You confused it. And the entire conversation fell apart, it just
[01:08] didn’t feel natural. And then you did what I do every single time, operator, hit zero, like get me to a human, right? So, how do we fix that? How do we make these agents as human-like as possible? Um and so, like in in a um a finance space, what if your caller was calling to schedule a payment, and they changed the the payment amount midway through, they changed the date, um and and the agent didn’t keep up with it, right? That is where we start having issues, especially in the finance space.
[01:42] The the the the risk is much higher, right? So, how do we fix that? So, we’re going to talk about how can we build human-like voice agents for financial services. And when you think about building a good voice agent, one of the first things that comes to mind is latency. We need it to be as fast as possible, right? Well, latency is part of the equation. Latency has a finite budget, and we’ll talk about what that is. Um but the keyword here is human-like. How do we make these voice agents as human-like as we can? That’s the goal. So, there’s quite a few people that are
[02:17] talking about voice lately. Um some of these might look familiar. We’ve got this this guy Sam. Um he’s excited about voice models. He says uh that they’re starting to change the way they that we interface with AI. Isn’t that true? And then this this um weird name here in the bottom right, Swyx. I don’t know if you’ve heard of him. Um he says oh uh that this is the OG modality. Um the correct modality for aligning AGI to our intents is very good voice AI
[02:49] engineering. That’s that’s that’s a pretty bold statement there. And then like get here says we learn to speak before we learn to read. Right? Voice is the most natural interface that we have. So, how can we make it as natural as possible and human-like as possible? Quick show of hands, who who here has ever built a voice agent and deployed it to production? All right, I see a few hands. All right, so some of you know the challenges that you might face when doing this. Um others here who have not built one, maybe you have um seen a very good
[03:24] example of one. Have you ever used ChatGPT’s advanced voice mode to have a conversation with ChatGPT? Okay, so that’s that’s cool. Segue here that OpenAI actually chose LiveKit to power that that functionality there. So, it’s a very good example of a good use case or a good uh good example of a good voice agent. Um LiveKit is the open-source real-time framework and infrastructure for these human-like agents. Um agents
[03:56] that can hear, see, and speak to a person on the other end. And so, we’re not just talking about voice, actually. Um there’s there’s multiple ways to interact with with agents, voice, video, data streams, uh even physical AI. We have a robotics division as well, but voice is the entry point voice is is the most natural modality, and voice is where there’s a lot of challenges. So, we’re going to focus just on voice today. So, in a traditional voice uh voice agent, you have what’s called a cascaded pipeline. This is three models
[04:28] that work together. You’ve got your speech-to-text model, your LLM, and your text-to-speech model. And these all have to work in unison. And there are also these other models, these real-time models, speech-to-speech models, right? And they replace that pipeline. But that’s a newer concept. Um it’s it’s getting better, but it’s not quite there for every use case yet, right? But even then, we’ve got the traditional pipeline with three models, we’ve got the speech-to-speech models. There’s so many things to choose from, so much complexity. Where do we even get started? And here’s what we have to
[05:00] choose from. Hundreds of models, dozens of providers, and quick show of hands here, who has ever picked a model based on a leaderboard? Like you pick them whatever model’s at the top of the leaderboard, that’s what we’re going to use, right? Well, we’re going to talk about why that does not work for real-time agents. We can’t just pick models off the top of a leaderboard. Um because leaderboards, they score these models, these components, but we’re shipping a conversation. We need to be able to score them together. So, we’re going to talk about how we can do that. So, let’s go through a scenario here. Let’s let’s suppose that a caller
[05:32] uh wants to pay their bill. And they say, “I want to pay on the 3rd.” But the speech-to-text model hears the 30th. And then the LLM is planning now for the 30th, and that goes into the system. The LLM doesn’t know any better. It doesn’t know that the speech detects model got it wrong. And so all of those errors flow downhill from there. And so the the the leaderboard, it can’t show us this. It can’t judge this because it just was looking at it individual models, right? And so also these leaderboards, they
[06:04] score these models based on clean audio. But your callers, they’re calling on the speakerphone in traffic with kids in the backseat, right? So we need to be able to score our own agents based on real-world use cases and examples. So let’s let’s say that we fall into this leaderboard trap. We just pick a model. Um then the the first question that people ask is always, you know, which model should I pick? So they use a leaderboard, they pick a model, but that the actual question that we should be
[06:34] asking is which stack should I ship for my use case? And so that is what we’re going to figure out. How do we answer that question? So before we answer that question, let’s say that you have picked some models and you start measuring. How are these models performing? Let’s uh say you’re you’re testing your TTS provider. And TTS provider on the dashboard, it’s it’s uh reporting time to first byte. And that looks really fast, 210 milliseconds time to first byte. That’s super fast.
[07:08] Um but we’ve actually tested lots of popular providers that are shipping up to 3/4 of a second of silence after that first byte. So a byte does not equal audio. So what we’re actually looking for is time to first audio. How much time does it take for our user to actually start hearing something? So time to first audio is what we should be measuring, not time to first byte. Um so imagine, you know, the payment went through and and and you you’re asking, you know, um you know, did my
[07:41] payment go through?” And then you hear 2 seconds of silence. That’s not very reassuring, right? So, we need to be able to measure this this gap that the caller hears. Now, the same story for lang- uh large language models. So, time to first token is what we get in text. It’s it’s a text-based measurement, but tokens do not equate to audio, either, right? Your TTS can’t start speaking on a token. A TTS model text-to-speech model actually needs an entire sentence to start speaking.
[08:15] Um and so, that’s what we need to measure is actually time to first sentence. Um because a an LLM that is very fast at producing tokens is not always the same LLM that produces the first sentence the fastest. So, time to first sentence is what we should be looking at. And then another thing that most leaderboards don’t measure is these these agents, they need to do things. They’re not just there to chat with us. They need to be able to do things on the back end. They have to look up a transaction, uh check for a payment
[08:46] status, submit a dispute, right? And so, these take time, 2 10 40 milliseconds. And and so, how do we handle that? How how do we hide 40 seconds or more of latency? Well, we can’t. That The answer is we can’t. But ask yourself, what would a human do in the situation? So, is a human just going to go silent while the system is doing something? No, they’re going to say, you know, “Give give me a second. I’m looking that up. Um system’s running a little slow, almost there.” Or they’re going to move
[09:18] on and they’re going to ask another question while the system is doing something in the back end. So, that’s that that’s the human-like behavior, multitasking, right? We can do that. So, why can’t agents multitask and do that? Well, that was a trick question because they can. They should. They should be able to. And this is the shape of that. Um this is the only code that I’m going to show you uh in this in this talk, but this is a normal tool call and the the one line is what makes the difference here. Um, this one line, this update, this async await, this awaiting this tool
[09:51] call is is the whole trick here and this is what’s handing the mic back to the agent. This is allowing the conversation and the tool to stop sharing a thread. They’re just they’re separate now. And so um, this is what again makes the agent more human like because it’s able to keep the conversation going as something is going on in the back end. So, don’t don’t take my word for it. I’ve got a quick demo here and we’ll listen and see what it sounds like. >> Thank you for calling The Gilded Rose Hotel. How can I help you?
[10:23] >> Yeah, I’d like to book a room. >> What dates are you looking at? >> Uh, next week, Wednesday through Friday. >> Next Wednesday, July 30th to Friday, August 1st? >> That’s right. >> How many guests will be staying? >> Two. >> I have queen two beds, king double queen, a suite or the penthouse? >> Would you prefer a city or ocean view? >> Ocean.
[10:54] >> May I have your name for the booking? >> Jesse Hall. >> Is that Jesse Hall? >> Yes. >> What’s your email? >> me@me.com >> Is me@me.com correct? >> That’s right. >> And your phone number? >> 555-123-4567 >> Is that 555-123-4567?
[11:25] >> That’s right. >> I’ll need a credit card to hold the room. What’s the the number? >> We’ll stop here. Okay, so you notice here that the conversation kept going. There were no awkward pauses. Um I even interrupted it and it just kept rolling with it, right? It It didn’t ever fall apart or feel unnatural. And we see here, you can see the the tool calls that are happening along the way and the things that it’s doing. It’s actually communicating with a back end and it’s saving every uh
[11:55] piece of information that I’m giving it. But what it’s doing is it’s not waiting for the back end to say, “Okay, that’s saved. Now you can move on to the next one.” “Okay, that’s saved. Move on to the next one.” It’s moving on to the next thing immediately. It’s keeping the conversation going. And if for some reason a tool call would have come back with an error or something, it would have then corrected itself. It would have said, “Let me Let me verify this or that, whatever happened, right?” And worst case scenario, if it was having issues, it would uh it would actually uh um pass me over to a human in that in that
[12:27] uh scenario then, right? So, this is how our agents should operate. Now, there’s one more um axis of this, and that is knowing the agent knowing when to speak and when to to listen, when to keep listening. And so, this is called turn detection. And so, LiveKit has a um a built-in turn detector that doesn’t only listen to the transcript like most turn detectors do. It also listens to the audio. It listens to the rhythm, the pitch, the intonation. And
[12:58] we published the numbers on this. The the leading um um alternative still interrupts and cuts users off 9.9% of the time. And ours, 4.5% in our use case. We ran it against the our hotel agent and others. And that hap And that is what the numbers that we got for our use cases. This is all open source. You can actually run these e-vals and run this against your data set and see what numbers you get. See if you get a um uh better uh increased numbers here. And this is just one small piece of the puzzle again to make these
[13:31] voice agents more human-like. Them knowing when to stop talking or when to listen. For instance, if if I were trying to make a payment and I said I’d I’d like to pay 500 and $55.23, right? Most of the turn detectors would have stopped at 500 because they saw 500 on the transcript and they saw 2 second pause, I must be done, right? But ours would have heard my inflection, knew I wasn’t done talking, and it would have waited for me.
[14:02] So, let’s look now at that latency budget, that the gap. This is the gap between the caller’s last syllable and the agent’s first audible response. So, the turn detector decides when the caller is done, the language model begins preparing a response based on a provisional transcript, and then the TTS starts generating that audio as soon as it can. And so, every model that you choose, every function, every handoff, all of
[14:34] that is right here within this window, and this window has a finite number, a fixed window, a fixed size. And so, if you can stay roughly inside 1 and 1/2 seconds, the call still holds, the conversation holds. It’s starting to feel a little off at 1 and 1/2 seconds. But if you can get down to 5 or 600 milliseconds between this the two turns, that’s when it really starts to feel human-like. And so, that question before, how fast can I go? We just needed to get
[15:05] to go faster and faster. That’s not the answer. The answer is how human-like of an agent can I fit within this latency window. So, again, latency, that’s a budget, and and we know how how to fit into that, but how can we be as human-like as possible? That’s the goal. So, if we add all this up, that that question, which model should I pick? We That was never something that we could answer because these scores, again, these leaderboards, they can’t answer that because they’re basing it off the
[15:36] models, but we are shipping a conversation. So, let’s answer that actual question. How can we pick the models? Which models should we pick? So, this is what we have to do. We test the conversation. We take a complete working agent So, that hotel receptionist that you heard just a minute ago, we took that. It has a real back end. Um it’s an actual It’s not just a demo. It actually works. Uh and it’s open source. You can check it out. So, we take that agent and we put simulated callers against it. And these callers can pursue goals. They can change their mind. They can
[16:08] interrupt. They can mumble. We can add background noise. We can make sure that this is a real-world scenario, and we run all of these simulated users against that agent. Um we can run text-based simulations, which just tests our business logic. Or we can also run audio-based simulations that tests the speech recognition capabilities. It tests turn-taking. The entire um the entire voice pipeline is what’s tested there. And so, we take the scenarios, and the scenario should describe what the caller wants and what
[16:41] actions the agent should take, what the outcome should be. And then we score that. We score those outcomes. And so, in the hotel benchmark, you know, did the correct reservation hit the database? In a financial benchmark, you know, did the correct authorized amount get charged, right? And so, we we check these agents. We make sure that every all the outcomes are met. And then we don’t score it based on just the completion alone, right? Because we know that agents can game completions, right? We have to make
[17:11] sure that they took the right steps. Did they take 10 steps when they only should have taken two steps, right? Did they hallucinate a function call? These are the things that we have to test, the entire conversation there. And then, we swap the stack out. We We have the same agent, the same scenarios, but we change the models. And then, we run that loop again. The identical input Every model sees identical input byte for byte. We swap the models, we run the loop. We swap the models again, we run the loop
[17:43] continuously over and over, and we are building at that point a benchmark, a personalized benchmark, for our use case, for our agent. So, there are as many benchmarks now as there are agents. You run this against yours, and you find out which models work best for your situation. That is the only way to find out which model is best for you. Now, this is how you catch surprises. Um a model that that gets the answer for you the quickest is the right model for you, right? And surprisingly, that model
[18:16] may not be the model that that’s at the top of the leaderboard, right? But it’s best for your use case. And again, these benchmarks, the simulations, all this this methodology, it’s all open source. So, you can You can check it out for yourselves, you can run it against your agent, and see how yours performs. And so, here is the results of that benchmark on our hotel agent. This is the LLM that ranked the highest for our hotel receptionist agent. That’s Gemma 4 31B on LiveKit inference. You notice on the second line, the same
[18:49] model, Gemma 4 31B on another provider, was slower. So, LiveKit optimizes its inference serving for voice workloads. And LiveKit is model agnostic, so you can use any model that you want. So, again, you plug those models in, and you figure out which one is work it will work best for your use case. Now, if you remember one thing from this this entire talk, remember this that a voice agent isn’t just a chatbot with a speaker attached. It’s There’s so much
[19:20] more complexity there. It’s a real-time system and that needs to respond like a person. We need to make it as human-like as possible. And and and when we evaluate it from that viewpoint, we will be able to to build that. And so, here’s a checklist. You can take a take a photo here. We need to set our latency budget that the caller hears. Measure time to first audio, time to first sentence. Confirm critical dates. Anything that’s financial money, we need to make sure that we have those those checks in place. Verify identity before
[19:54] an account is accessed. Keep listening while slow tools run. Keep the conversation going. And then run the complete conversation repeatedly through simulations. Test the final state, privacy safeguards, unnecessary tool calls, turn-taking. All these things and then when you find these failures, you turn those into regression scenarios and you keep testing over and over again. So, start with one one of those workflows or failures that you care about. Keep Keep iterating then. Run it. Listen to the conversation. Check what
[20:26] happened on the back end. At some point in the very near future, I hope, that we all call one of these voice agents and we talk over it. We confuse it and it just rolls with it and it’s and it’s a very human-like experience. That’s That’s our goal, but here’s what I need from each and every one of you. I need you to go build that. Thank you. >> Woo!