A transcrição parecia certa. A chamada, não. — Depuração de agentes de voz, Arize

Autoria: AI Engineer (Arize) · 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: The Transcript Looked Fine. The Call Wasn’t. — Debugging Voice Agents, Arize · Canal: AI Engineer (Arize) · 17:17 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Fuad, product manager da Arize, explica por que transcrições isoladas não revelam falhas importantes em agentes de voz, como latência, interrupções, erros de transcrição e chamadas de ferramenta incorretas. Ele demonstra como áudio, transcrição, traces e métricas reunidos numa visualização de sessão ajudam a investigar essas falhas. Também apresenta evals específicos de áudio e a importância de associá-los aos spans para filtrar problemas e iniciar investigações. Por fim, descreve um ciclo de observação, avaliação e melhoria contínua, incluindo agentes que podem propor correções e validá-las com traces reproduzidos.

Pontos-chave

Transcrições podem parecer corretas mesmo quando a chamada teve silêncio prolongado, sobreposição de falas ou erro na execução de uma ação.
Investigar agentes de voz exige reunir áudio, transcrição, traces, turnos da conversa e métricas numa única visualização.
Métricas como time to first audio, interrupções, custo de audio tokens e latência ajudam a identificar problemas que não aparecem nos logs de texto.
Convenções semânticas abertas podem normalizar dados de diferentes provedores e facilitar consultas em grande escala.
Evals de áudio devem analisar características como tom, sentimento, precisão, transcription drift e sucesso da tarefa, não apenas a transcrição.
Associar os resultados de evals aos spans permite filtrar falhas e iniciar investigações com mais contexto.
O ciclo proposto para melhorar agentes de voz é observar, avaliar, corrigir e validar as mudanças.
Agentes de SRE poderiam investigar traces, propor correções, testá-las em dev e apresentar um pull request para aprovação.

Capítulos

Início	Capítulo	Resumo
00:01	Por que agentes de voz são difíceis de depurar	O palestrante apresenta o crescimento dos agentes de voz e explica que seus problemas de latência, turn-taking e transcrição não ficam claros em logs de texto.
03:41	O que a transcrição não mostra	O exemplo de uma chamada com pedido de reembolso demonstra por que é necessário combinar áudio, transcript, traces e métricas na análise de uma sessão.
07:20	Traces e reprodução das conversas	A palestra mostra como normalizar dados de provedores, consultar traces e reproduzir o áudio para localizar falhas e chamadas de ferramenta incorretas.
09:58	Evals específicos de áudio	O palestrante destaca evals de tom, sentimento, latência, interrupções, precisão e sucesso da tarefa, aplicados ao áudio e associados aos spans.
13:38	Melhoria contínua e próximos passos	A apresentação propõe observar, avaliar, corrigir e validar, e descreve agentes que poderiam investigar falhas, testar correções e preparar um pull request.

Citações

Se você lesse isso como uma saída de LM, não teria ideia de que algo estava acontecendo. — 03:41

Você não está apenas lendo transcrições; está ouvindo o áudio e entendendo as falhas com o trace aberto ao lado. — 07:52

O ciclo realmente segue observar, avaliar e melhorar. — 13:38

Comece a enxergar seus agentes. Adicione o Open Inference Instrumenter. — 15:44

Conceitos e entidades

voice agents (conceito): Agentes que interagem com usuários por voz e exigem análise conjunta de áudio, turnos, latência e ações.
Arize AI (empresa): Empresa apresentada como provedora de recursos para observar, avaliar e depurar sistemas de IA, incluindo agentes de voz.
Open Inference (conceito): Conjunto aberto de convenções semânticas descrito na palestra para representar e normalizar dados de sistemas de GenAI.
OpenTelemetry (ferramenta): Padrão de observabilidade citado como referência de conformidade para as convenções apresentadas.
Gemini Live (modelo): Oferta de voz do Google citada como exemplo de provedor cujos dados podem ser normalizados.
Grafana (ferramenta): Plataforma mencionada como um backend para o qual os dados de Open Inference podem ser enviados.
Claude (modelo): Assistente mencionado no exemplo de criação de um eval de áudio por meio de uma instrução em linguagem natural.
SRE agent (conceito): Agente hipotético que analisa traces, propõe uma correção e verifica seu efeito em um ambiente de desenvolvimento.
agent experiments (conceito): Recurso da Arize apresentado como uma forma de experimentar com agentes usando traces e validação de mudanças.

Tradução completa (pt-BR)

00:01 [música] >> Pessoal, obrigado por terem vindo. Sei que é hora do almoço, então sei que muitos de vocês também estão tentando comer. Agradeço por terem reservado um tempo e, a todos que estão acompanhando online, obrigado por estarem assistindo também. Meu nome é Fuad. Sou gerente de produto aqui na Arize. Tenho liderado a área de experimentação e uma coisa que tem me interessado bastante são os voice agents.

00:33 Uma rápida enquete levantando a mão: talvez quem está online também possa participar. Quem aqui está criando um voice agent? Alguém? Certo, temos algumas pessoas. Acho que é uma área muito interessante. Vou falar um pouco sobre traces de voz, visualizações de sessões de voz, evals de voz e algumas das novidades da Arize. Mas quero deixar claro que isto não é uma apresentação de produto. O foco é realmente explicar por que os voice agents são invisíveis e como enxergá-los. Vocês podem usar a Arize para isso, ou outra plataforma, mas o que quero que vocês

01:05 levem daqui são alguns dos modos de falha e como vocês podem começar a identificá-los. Então, todos sabemos que os voice agents estão crescendo muito, muito rápido. Tenho alguns tweets aqui que comprovam isso. O GPT real-time acabou de ser lançado. Isso aconteceu literalmente em 7 de maio. Tenho uma captura de tela de um tweet publicado há uma hora pelo CEO da LiveChat falando sobre isso. E a Vercel, em 29 de junho, há apenas alguns dias, falou sobre voice agents na Vercel. Então, como vocês podem ver,

01:36 essa área está crescendo explosivamente, e isso vai começar a ser importante porque, à medida que ela cresce muito rápido, também se torna uma das categorias mais difíceis de depurar. Primeiro, está crescendo explosivamente. Segundo, é bastante frágil. Há muitos modos de falha que vocês não conseguem realmente enxergar. E coisas como latência, alternância de turnos e desvio na transcrição se tornam muito, muito importantes. E o log mente. Se vocês estiverem apenas olhando as transcrições, vou reproduzir um pequeno arquivo de áudio para vocês daqui a pouco. Isso não

02:07 captura o que realmente está acontecendo por baixo dos panos. E, só para dar algumas ideias de casos de uso, há muitos, desde atendimento ao cliente, que acho que são os mais sem graça, até pedidos em drive-thru. Se vocês já foram ao White Castle, eles têm agora um bot chamado Linda. O Bojangles também tem a Bo Linda. A McDonald’s também está fazendo muitas dessas coisas, o que acho muito legal. E, pessoalmente, eu ficaria bem irritado se estivesse no McDonald’s às duas da manhã e recebesse 600 cheeseburgers. Então, vou mostrar a vocês

02:37 um pouco sobre os modos de falha e por que isso realmente importa. Então, este é um exemplo em que a transcrição parece boa, mas a chamada não foi. E, se vocês lerem os logs de texto, o usuário diz: “Preciso de um reembolso do pedido 14.” O agent diz: “Claro. Iniciei um reembolso para o pedido 40.” O usuário diz: “Não, 14.” E parece que o agent se corrigiu. Mas não foi isso que aconteceu, e vou reproduzir a chamada. Ela foi gerada por IA. Vamos ver se funciona. >> Preciso de um reembolso do pedido 14.

03:10 >> Claro. Iniciei um reembolso para o pedido 40. >> Não, 14. >> Seu reembolso foi confirmado. >> Então, se vocês repararem na transcrição, se conseguiram ouvir o áudio, a confirmação do 40 não foi feita pelo agent. Ele meio que interrompeu. E houve um grande pico de latência depois que o usuário pediu o reembolso inicial. Então, o que aconteceu foi que houve 2,4 segundos de silêncio antes de o agent

03:41 responder. O agent falou por cima do cliente. O 14 foi ouvido errado, e, obviamente, o tom robótico e monótono também não ajuda. Então, todos esses são problemas específicos de áudio. Se vocês simplesmente lessem isso como uma saída de LM, não teriam ideia de que algo estava acontecendo. Então, é preciso ver a conversa além da transcrição. Isso significa o áudio, a transcrição e o trace, tudo em um só lugar. A sessão inteira, ou seja, vários turnos de ida e volta entre o usuário e o agent, na mesma visualização de trace.

04:13 E também métricas para isso: qual foi a latência? Qual foi o tempo até o primeiro áudio? Houve interrupções? Análise de sentimento e assim por diante. Essas são algumas das funcionalidades que lançamos no início deste mês no Arize AIX. E o objetivo é aplicar aos voice agents os mesmos workflows que vocês já usam para ajudar seus agentes de programação — processos que hoje são bastante complexos, com harnesses, evals, transferências, subagents e chamadas de ferramentas. Vocês querem começar a trazer algumas dessas melhores

04:44 práticas para os voice agents também. Primeiro, é preciso criar traces. É preciso ver cada span individual. É preciso ver o áudio ao vivo e reproduzi-lo diretamente no trace. É muito importante ter todos esses dados no mesmo lugar para que vocês possam começar a depurar as coisas. Vocês querem ver as entradas e as saídas. É claro que querem ver a transcrição, mas também querem ver métricas específicas, como mencionei: tempo até o primeiro token, custo dos tokens de áudio, eventos de interrupção. E, por fim, vocês querem ver as relações entre esses elementos. Não querem vê-los apenas como uma lista. Vocês

05:15 querem ver algumas das relações entre eles, certo? Então, a Arize oferece uma visualização de trace única, na qual vocês podem reproduzir o áudio diretamente, visualizar a transcrição, ver a latência ali mesmo, acompanhar a conversa entre o usuário e o assistant e também ver as evals ali mesmo. Isso oferece uma ferramenta muito, muito poderosa para depuração. Por baixo dos panos, o que fizemos foi mapear as convenções semânticas para áudio para o Open

05:46 Inference. Então, se vocês não conhecem, a Arize foi a primeira a disponibilizar o Open Inference, em 2023. É o primeiro conjunto de convenções semânticas totalmente open source que mapeia o que acontece com a GenAI para um conjunto de convenções compatível com OTel. Digo isso para destacar que é open source, gratuito e mapeia praticamente qualquer um dos principais modelos fundamentais ou provedores de modelos. Vocês podem pegar isso e enviar para um backend do Grafana. É totalmente gratuito. Não estou fazendo propaganda do produto aqui; estou apenas explicando um pouco do

06:18 trabalho de engenharia necessário para mapear coisas como eventos de WebSocket para um conjunto de convenções semânticas fáceis de entender. Assim, vocês podem começar a ver coisas como o ciclo de vida da sessão, a entrada de áudio, a transcrição, os itens da conversa, a saída e também o ciclo de vida da resposta e a contagem de tokens. Então, sim, houve um trabalho de engenharia de verdade por trás disso. É tudo open source. Mapeamos todos os modelos fundamentais para vocês. Isso permite que vocês não dependam de um provedor específico e tenham um

06:49 esquema consultável. Essas convenções semânticas normalizam provedores de modelos distintos, como o OpenAI real-time ou o Gemini Live do Google, em um conjunto de esquemas que vocês podem consultar. E, se já tentaram depurar uma chamada de cliente às duas da manhã, sabem como é importante poder consultar milhares, milhões ou até bilhões de traces que chegam. Sabem como é importante conseguir chegar à parte que precisam ver, filtrá-la e ordenar por

07:20 isso. Tudo isso se torna extremamente importante. E, quando novos modelos são lançados, vocês também querem poder trocar de provedor e garantir que seus sistemas continuem funcionando. Assim, não é preciso criar uma análise personalizada para cada fornecedor. Há um único instrumentador automático. Ele captura tudo o que acabei de mencionar. E, por fim, vocês querem poder reproduzir a conversa inteira. Eu reproduzi o áudio para vocês no começo, mas o ID da sessão é essencialmente o que reúne cada turno na linha do tempo, formando a chamada completa com

07:52 cada evento de websocket enviado com algumas tags indicando se é o usuário ou o assistente. Na verdade, você pode reproduzir o áudio diretamente na interface, a partir do trace. Sem ferramentas externas. Sem exportações. Basta reproduzi-lo diretamente do trace. Isso permite ver quem falou e quando. Quando o agent fez uma pausa, onde foi interrompido, onde o usuário foi interrompido, quais ferramentas o agent realmente acionou e quando fez isso. E isso realmente dá início a uma mudança de paradigma: você não está apenas lendo transcrições, está ouvindo o áudio, está realmente

08:23 entendendo os casos de falha com o trace aberto bem ao lado. E vou mostrar rapidamente uma prévia de como isso fica no Arize. Como podem ver aqui, este é um exemplo de um agent que pode chamar uma ferramenta para obter informações sobre um evento climático específico. Você pode ver exatamente quando o agent inicia essa chamada de ferramenta, junto com o restante do áudio. Isso permite depurar falhas nessa chamada de ferramenta enquanto ouve o áudio da sessão. Assim, você não precisa mais olhar para eventos desconexos de sistemas distintos

08:53 mas pode ver a árvore completa do trace de tudo o que aconteceu naquela sessão. Então, sobre aquela sessão real, vimos alguns problemas, certo? No primeiro turno: “Oi, preciso de ajuda com o pedido, um reembolso do pedido 14.” Vimos um tempo até o primeiro áudio de 2,4 segundos de silêncio, o que realmente prejudica a experiência do usuário. No terceiro turno, vimos que o agent falou por cima da fala do usuário, o que não pega bem para nenhum assistente, especialmente um que está tentando ajudar. E

09:25 por fim, se você olhar a chamada de ferramenta, também vai conseguir entender que o reembolso foi processado para o pedido 40, e não para o 14. Isso é um erro enorme, e ver isso diretamente na chamada de ferramenta é muito importante. Cada uma dessas coisas ficaria invisível em um log de texto. Mas, com a visualização da sessão, você pode percorrer o áudio e encontrar esses pontos de falha nas ferramentas e também no que o agent está fazendo. A próxima coisa sobre a qual quero falar rapidamente são os evals específicos de

09:58 áudio. Mencionei alguns deles. Acho que a análise de tonalidade e de sentimento é muito importante. Você precisa conseguir classificar a emoção do usuário com base no áudio em si. Uma transcrição não consegue fazer isso por você. É muito fácil olhar para uma transcrição e achar que ela parece estar tudo bem, mas a tonalidade realmente importa. Positivo, neutro, negativo — não apenas um palpite. A latência é muito importante em áudio e importa em alguns casos de uso. Os modelos estão melhorando. Existem arquiteturas JetBar, etc. Mas o tempo até o primeiro

10:30 áudio ainda é muito importante para os SLAs de atendimento ao cliente. E você precisa conseguir sinalizar os casos que não cumprem esses SLAs. Também precisa sinalizar coisas como as interrupções que mencionei, imprecisões, desvios na transcrição e o sucesso da tarefa. E você precisa conseguir executar esses evals diretamente no áudio, usando evals baseados em modelos de áudio. Os evals de LLM as a judge em uma transcrição só são bons até certo ponto. Avaliar o áudio subjacente é muito importante. E temos as ferramentas disponíveis

11:02 no Arize para fazer isso e damos suporte a todas as principais plataformas de áudio, acompanhando o lançamento de novos modelos. Então, de novo, evals específicos para áudio realmente importam. Não são apenas evals baseados em transcrição. E, quando você começa a ampliar seus evals de LLM as a judge, ou até passa a usar agent as a judge para tarefas complexas — por exemplo, fazer verificações de RBAC para garantir que o agent realmente acessou o sistema ao qual deveria ter acesso —, a capacidade de executar esses workflows de agent as a judge no Arize começa a se tornar

11:33 muito importante. Estamos vendo a indústria se afastar de um LLM as a judge que apenas analisa uma transcrição ou mesmo um áudio e passar a acessar ferramentas e sistemas de terceiros, além de incorporar algumas dessas informações de avaliação. É muito fácil começar a usar evals no Arize por meio de skills. É literalmente tão simples quanto dizer: “Ei, Claude, crie um eval de áudio para mim, para análise de sentimento usando GPT audio, e detecte um tom de frustração do usuário nesses trechos de áudio.”

12:04 E o Arize cuida de todo o resto. Por trás, a CLI consegue consultar spans, fazer algumas análises de trace, filtrar os spans específicos de áudio, criar o eval, fazer o deploy e aplicá-lo aos traces e spans do seu sistema. E é por isso, em parte, que o Arize existe. Claro, você pode fazer isso por conta própria, mas, ao tentar consultar bilhões de spans com latência de consulta abaixo de um segundo, isso fica muito difícil — assim como fazer o deploy desses evals em tempo real, à medida que os dados chegam. Então,

12:36 é muito importante pontuar os spans enquanto os usuários estão interagindo com a sua plataforma. E a última coisa que vou mencionar é que você também quer esses evals nos próprios spans, porque assim passa a conseguir fazer consultas e filtragens realmente complexas nos seus dados. Desse modo, você não fica apenas olhando para uma falha e procurando informações em um sistema externo. Você tem as pontuações dos evals junto do áudio exato que está analisando. É por isso que isso é tão poderoso no Arize: poder ver os resultados dos evals diretamente nos spans

13:07 relevantes ajuda você a entender por completo o que está dando errado na interação com o usuário. E então você pode iniciar workflows a partir disso. Assim, evals e monitors associados a esses evals podem iniciar agents de investigação que começam automaticamente a analisar quais chamadas de ferramenta estão deturpando informações, onde meu agent está falhando? Será que ele está capturando uma área de produto para a qual não foi programado? Há um novo caso extremo para o qual preciso programar meu agent? Talvez eu precise expor

13:38 uma nova ferramenta. Tudo isso se torna possível quando você tem os resultados diretamente nos spans. Então, vou só destacar isso e encerrar com esta ideia: o mesmo ciclo que você usa para melhorar ferramentas como coding agents agora também precisa ser aplicado à voz. E esse ciclo consiste em observar, avaliar e melhorar. A partir dele, você pode criar ciclos de melhoria contínua realmente interessantes na plataforma Arize ou em outra

14:09 plataforma, se preferir. A ideia é que, depois de observar e ter os dados disponíveis, você avalie e tenha as pontuações junto das suas observações. Então pode iniciar correções, sejam correções feitas por você ou automaticamente por um agent em seu nome. Depois, pode começar a verificar e validar essas correções. Também acabamos de lançar os agent experiments no Arize. Você pode pensar nos agent experiments como algo parecido com o Postman com tracing. Imagine um cenário em que o áudio

14:42 dos usuários é transmitido em streaming, rastreado automaticamente, e a plataforma tem avaliações em tempo real que pontuam essas interações automaticamente. Além disso, você tem agents de SRE — não um engenheiro de verdade que você contrata, mas um agent de SRE que analisa os traces, entende os modos de falha, formula uma hipótese de correção e então implementa uma correção para você em dev, reproduzindo os traces que falharam nesse endpoint corrigido e rastreando tudo para validar que a latência realmente diminuiu. E você acorda

15:12 de manhã, olha para um PR e vê que ele descreve um problema. “Ei, descobri por que a latência estava alta. Acontece que não estávamos truncando os resultados das ferramentas, então estávamos passando informação demais para o agent. O context ficou sobrecarregado. Implementei o algoritmo de truncamento. Fiz o deploy. Também coloquei isso em funcionamento em dev. Testei com os traces que falharam. Aqui está o relatório. Veja como a latência diminuiu.” E você acorda de manhã com tudo isso pronto e só precisa clicar em aprovar ou rejeitar o PR. Esse é o futuro que eu

15:44 acho que é isso que queremos ver na Arize: software que se autocorrige e melhoria contínua como realidades para todos que estão criando agents. E acho que tornar isso possível para voz é muito, muito importante. Então, comecem a observar seus agents. Adicionem o Open Inference Instrumenter. Open source, gratuito e compatível com OTEL. Vocês podem enviá-lo para qualquer backend. Então, usem Arize, não usem Arize, mas comecem a rastrear seu áudio. A segunda parte é começar a fazer essa análise, e recomendamos a Arize para isso. Criem uma conta gratuita. Vou deixar um

16:16 código no fim da minha apresentação para vocês se inscreverem e ganharem um ano gratuito do plano Pro. Mas comecem a verificar o tempo até o primeiro áudio. Comecem a verificar as interrupções. E comecem a avaliar como essas interações estão acontecendo de fato e se estão atendendo aos seus casos de uso. Seja uma eval de tom ou de latência, tentem usar as skills da Arize para criar essa eval. Temos alguns documentos preparados para vocês, caso queiram acompanhar. Há vários exemplos e cookbooks prontos. E tragam a voz para o mesmo nível de rigor que o resto da sua

16:46 stack. Vocês não aceitariam que isso acontecesse no nível de um agente de programação. Não aceitariam que acontecesse com um agent capaz de executar operações com ações na Robinhood. Também não deveriam aceitar isso, embora os riscos possam parecer um pouco menores, no caso de um agent do McDonald’s que está pedindo seu cheeseburger. E vou terminar por aqui. Por favor, continuem criando. Também entrem em contato comigo pelo Twitter. Ainda chamo de Twitter, não de X. Pelo Twitter ou pelo LinkedIn. Adoraria conversar e ouvir sobre alguns dos casos de uso que vocês estão desenvolvendo, para podermos adicionar

17:17 mais ecos à nossa biblioteca e garantir que isso seja útil para vocês. E, se acharam esta palestra útil e querem começar a investigar seus voice agents, há um código gratuito na tela. Ele dá a vocês um ano do Voice Pro grátis. O código é i a w f 2026; vocês podem começar a rastrear seus voice agents. Muito obrigado. Meu nome é Ali. Ficarei disponível para responder a perguntas por alguns minutos, mas agradeço muito por terem me ouvido. Um abraço.

Transcrição original

[00:01] [music] >> Folks, thanks for coming in out. I know it’s lunch time, so I know a lot of you folks are trying to eat as well. Appreciate you making the time and for everyone listening online, thanks for tuning in as well. Uh my name’s Fuad. I’m a product manager here at Arize. Uh I’ve been leading up kind of the experimentation side of the house and one thing that I’ve been really interested in is voice agents. Uh

[00:33] quick show of hands here, maybe online too. Who here is building a voice agent? Anyone? Got Okay, we got a couple. Uh I think it’s a really cool space. I’ll be talking a little bit about voice traces, session views of voices, voice evals, and some of the stuff that’s new in Arize. But I do want to kind of mention this isn’t a product pitch. This is, you know, really on why voice agents are invisible and how to see them. You can use Arize to do that, you can use another platform, but what I want you

[01:05] guys to take away from this is some of the failure modes and how you can actually start to see that. So, we all know voice agents are growing really, really fast. Have a few tweets up uh kind of proving this. GPT real-time just dropped. That was literally May 7th. Uh I have a screenshot from a tweet an hour ago from the LiveChat CEO talking about some of this. Uh and Vercel on June 29th, which is only a couple days ago, um on voice agents in Vercel. So, as you can tell,

[01:36] uh this space is exploding fast and that is going to start to matter because as the space grows really fast, it is also one of the hardest to debug categories. So, first off, it’s exploding. Second off, it’s pretty fragile. There’s a lot of failure modes you can’t really see. Um and uh things like latency, turn-taking, and transcription drift become really, really important. Uh, and the log lies. If you’re just looking at transcripts, I’ll play a little audio file for you guys in a second. Uh, it doesn’t really

[02:07] capture what’s actually going on under the hood. And just to give you guys some ideas of use cases, um, there’s a lot of them from customer support, I think, which are the more boring ones, down through drive-thru ordering. If you’ve been to White Castle, they have a a bot called Linda now. Uh, Bojangles has uh, Bo Linda as well. There’s McDonald’s is doing a lot of these as well, which I think is pretty cool. And personally, I’d be pretty pissed off if I was at McDonald’s at 2:00 a.m. and I got 600 cheeseburgers. So, I think I’ll show you

[02:37] a little bit about the failure modes and why it actually matters. So, uh, this is an example where the transcript looks fine, but the call wasn’t. And if you read the text logs, you know, user says, “I need a refund for order 14.” Agent says, “Sure. Started a refund for order 40.” User says, “No, 14.” And it looks like the agent corrected itself. But, this wasn’t actually the case, and I’m going to I’m going to play the call. It’s AI-generated. Let’s see if it works. >> I need a refund for order 14.

[03:10] >> Sure. I’ve started a refund for order 40. >> No, 14. >> Your refund is confirmed. >> So, if you notice in the transcript, if you could hear the audio there, uh, it wasn’t, you know, the the the confirm- confirmation on the on the 40 wasn’t actually done by the agent. It kind of interrupted. Uh, and there was a big, uh, kind of latency spike, uh, after the user asked for the initial refund. Um, so, we what actually happened was that two 2.4 seconds of dead air before the agent

[03:41] actually responded. The agent talking over the caller. 14 misheard, and obviously, the flat robotic tone is is not a a look, either. Um, so, these are all audio specific issues. If you just read this from an LM output, you would have no idea anything is going on. So, what you need to do is you need to see the conversation beyond just the transcript. Um, so that means the audio, the transcript, and the trace all in one place. The session as a whole, so multiple turns from the user back and forth in

[04:13] the same in the same trace view. And then metrics on those, so what was the latency like? What was the time to first audio like? Were there any interruptions? Sentiment analysis, et cetera. And these are some of the features we’ve just released at the beginning of this month in Arize AIX. Uh, and really the point of this is the same workflows that you’re running now to help your coding agents, uh, which are, you know, pretty complex processes now with harnesses, evals, uh, handoffs, and subagents, tool calls, you want to start to bring some of those best

[04:44] practices into your voice agents as well. So, first off, you got to trace it. You got to see each individual span. Um, you got to see the live audio and play it inline from your trace. Really matters to have all this data in the same place so you can start to debug things. Uh, you want to see inputs and outputs. You want to see the transcript, obviously, but you also want to see, you know, specific metrics like I mentioned, like time to first token, uh, audio token cost, interruption events. And then finally, you want to see linkage between these. You don’t want to just see these as a list. You

[05:15] actually want to see some of the linkage between things, right? So, Arize gives you that one trace view where you can actually play the audio inline, view the transcript, view latency inline, see the conversation turn between the user, uh, and the assistant, uh, and see your evals inline as well. And this gives you a really, really powerful tool to debug. Under the hood, what this looks like is we’ve actually mapped, uh, the semantic conventions for audio onto open

[05:46] inference. So, if you guys aren’t familiar, Arize is first to market with open inference in 2023. It is the first set of semantic conventions that is completely open source that maps kind of what is happening with GenAI to an OTel-compliant set of conventions. And I say this to say it’s open source, it’s free, and it maps pretty much any of the major foundational models or model providers. You guys can go rip this and send it to a Grafana back end. Completely free to use. Not pitching the product here, just explaining some of

[06:18] the real engineering work it takes to map things like web socket events to an easily understandable set of semantic conventions. So, you can start see things like the session life cycle, the audio input, the transcript, conversation items, the output, and then the response life cycle and token counts as well. And so, yeah, real engineering work went behind this. It’s all open source. We’ve mapped all the foundational models for you. What this allows you to do is you can now be provider agnostic and have one

[06:49] queryable schema. So, those semantic conventions normalize sort of these disparate model providers, whether it’s OpenAI, real-time, or Google with Gemini Live into a set of schema that you can query. And if you’ve ever tried to debug at 2:00 a.m. off of a customer call, you know how important it is to be able to query across thousands, millions, even billions of traces that are coming in. You know how important it is to actually get to the part that you need to see, to filter that, to sort by

[07:20] that. All that becomes incredibly important. And, you know, as new models drop, you also want to be able to swap in new providers and make sure that your systems are still functioning. So, no bespoke parsing per vendor. It’s one auto instrumenter. It captures every single thing that I just mentioned. And then finally, you want to be able to replay the whole conversation. So I play I played the audio for you guys in the beginning of this, but the session ID is essentially what stitches every turn into the timeline, the full call with

[07:52] every websocket event that’s submitted with some tags on whether it’s the user or the assistant. You can actually play the audio in the UI directly from the trace. No external tooling. No exports. Just play it straight from the trace. That allows you to see who spoke when. When the agent paused, where it got cut off, where the user got cut off, what tools the agent actually went and called when it did this. And so this really starts the paradigm shift, which is you’re not just reading transcripts, you’re listening to audio, you’re really

[08:23] understanding the failure cases from there with the trace open right next to it. And um I’ll just show you kind of quick quick sneak preview of what this looks like in Arise. As you can see here, this is an example of like you know an agent that can call to get a specific weather event. You can actually see when the agent kicks off that tool call in line with the rest of the audio. And this allows you to debug failures of that tool call while you’re looking at the session audio. So you’re no longer looking at disparate events from distant

[08:53] systems, but you’re actually looking at the entire trace tree for everything that happened in that session. So that real session, few issues that we saw, right? Turn one, “Hi, need help with the order, a refund for order 14.” We saw you know kind of that time to first audio of 2.4 seconds of dead air, which really impacts the user experience. We saw in turn three that the agent actually spoke over the caller’s interaction, which is not a good look for any assistant, especially one that’s trying to be helpful. And

[09:25] then ultimately if you look at the tool call, you’ll be able to also understand that the refund was processed for order 40 and not 14. Um which is a huge huge mistake and actually seeing that live in the tool call is really really important. And every single one of these things would be invisible in a text log. But with the session view you can actually scrub the audio and find those failure surfaces within the tools, within what the agent is doing as well. The next thing I want to talk about real quick is evals that are specific to

[09:58] audio. So I kind of mentioned a few of them. I think tonality and sentiment analysis is really important. You want to be able to classify user emotion based on the actual audio. Transcript can’t do this for you. It’s very very easy to look at a transcript and see that it it, you know, looks fine, but tonality really matters. Positive, neutral, negative, not just a guess. Latency is really really important in audio and it’s important in a few use cases. Models are getting better. There’s, you know, jet bar architectures, etc. But time to first

[10:30] audio SLAs are still really important for customer service use cases. And you want to be able to flag things that are breaking that. You also want to flag things like I mentioned like interruptions, inaccuracy, transcription drift, and the task success. Um And you want to be able to run these evals directly against the audio with evals that are based on audio models. So, you know, LLM as a judge evals on a transcript are only so good. But actually evaling the underlying audio is really important. And so, um we have kind of the tooling available

[11:02] in Arise to be able to do that and we’re supporting all the major audio platforms as well as they come out with new models. So again, evals specific to audio really matter. They’re not just transcription based evals. And as you start to scale up your LLM as a judge evals or even move to agent as a judge that are doing like complex tasks like, for example, doing our back checks to making sure the agent actually access the system it was supposed to have access to. Being able to run these agent as a judge workflows in Arise, starts to become

[11:33] really important and we’re kind of seeing the industry move away from, you know, just an LM as a judge analyzing a transcript or even analyzing audio, but actually accessing tools, accessing third-party systems, and hydrating some of that evaluation information inside of it. So, really easy to get started with evals in Arise through skills. It is literally as simple as, “Hey Claude, create an audio eval for me for sentiment analysis using GPT audio and catch frustrated user tone on those

[12:04] audio spans.” And Arise will kind of take care of all the rest for you. The CLI under the hood is able to query spans, do some trace analysis, filter for the spans that are audio specific, actually create that eval, deploy it, and put it against traces and spans in your actual system. And this is part of why Arise exists. Yes, of course, you can do this yourself, but when you’re trying to query, you know, billions of spans with sub-second query latency, it becomes really hard and also deploying these live evals as they come in. So,

[12:36] you’re scoring them while users are actually interacting with your platform is really important. And then the final thing I’ll mention is you also want these evals on the spans themselves because then you start to be able to do really complex querying and filtering across your data. So, you’re not just looking at a failure and looking up in an external system. You actually have the eval scores in line with the exact audio that you’re looking at. And that’s why some of this is really powerful in Arise. Being able to see those eval outputs directly on the spans

[13:07] that are relevant helps you kind of get a full understanding of what is going wrong with the user interaction. And then you can kick off workflows from that. So, evals and monitors attached to those evals can kick off investigation agents that automatically start to dive into, you know, what tool calls and misrepresenting, Um, where is my agent failing? Is it capturing, you know, maybe a product surface area that I didn’t code it for? Is there a new edge case I need to code for in my agent? Maybe I need to expose

[13:38] a new tool. All those become um, possible once you have the results directly on the spans. And so, I’ll I’ll just kind of flag and and end with this thought. The same loop that you’re doing to improve some of these tools like coding agents, we now need to do for voice. And the loop really follows observe, evaluate, and improve. And then from that loop, you can start to get some really really cool continuous improvement loops within the Arize platform or within another

[14:09] platform if you choose to use it as well. Um, and the idea is once you observe and you have the data available to you, then you evaluate and you have the scores in line with your observations. Then you can start to kick off fixes, whether they’re fixes that you make or whether they’re fixes that an agent is automatically making on behalf of you. And then you can start to verify and validate those fixes. So, we just released agent experiments as well in Arize. Agent experiments, you could think of it kind of like Postman with tracing. So, imagine a world where you have audio

[14:42] streaming in from your users, it’s automatically traced, you have live evaluations in the platform that are automatically scoring those interactions. And then you have SRE agents, so not an actual engineer that you hire, but an SRE agent that’s looking through the traces, understanding the failure modes, hypothesizing a fix, and then actually standing up a fix for you in dev, replaying those failed traces for you against that fixed endpoint, tracing that to validate that the latency actually decreases. And you wake

[15:12] up in the morning, you look at a PR, the PR has a description of a problem. Hey, I found out why the latency was high. Turns out we were not truncating our tool results, and so we were passing in way too much information to the agent. Context got overloaded. I introduced the truncation algorithm. I shipped it. I actually stood it up in dev. I tested against the traces that failed. Here’s the report card. Here’s how latency decreased. And you wake up in the morning and all of this is ready for you, and you just click approve or deny on the PR. That is the future that I

[15:44] think we want to see at Arize, where self-healing software and continuous improvement are realities for everyone who’s building agents. And I think making that possible for voice is really, really important. So, start seeing your agents. Add the Open Inference Instrumenter. Open source, free to use, OTEL compliant. You can send it to any back end. Um so, use Arize, don’t use Arize, start tracing your audio. The second part of this is actually starting to do that analysis, and we would recommend Arize to do that. Sign up for a free account. Uh I’ll have a

[16:16] code up at the end of my presentation for you guys to sign up for a a free year of pro. Um but start checking time to first audio. Start checking your interruptions. And start evaluating um how these interactions are actually going and whether they’re accomplishing your use cases. Whether it’s a tone or latency eval, um try using the Arize skills to actually create that eval. Uh we have some docs set up for you if you want to follow along. Bunch of examples and cookbooks ready. Uh and bring voice into the same rigor as the rest of your

[16:46] stack. You wouldn’t be okay with this happening at the coding agent level. You wouldn’t be okay with it happening uh for an agent that’s able to execute stocks on Robinhood. You shouldn’t be okay with it, uh though the stakes might seem a little lower, for a McDonald’s agent that’s ordering your cheeseburger, either. Um and so I’ll end with that. Please, please keep building. Please connect with me also on Twitter. I still call it Twitter, not X. Uh on Twitter or LinkedIn. Would love to kind of talk and hear about some of the use cases you guys are building towards so we can add

[17:17] more echos to our library and make sure this is useful for you. And if you found this talk useful and you want to start investigating your voice agents, there is a free code up on the screen. It gives you a year of Voice Pro for free. It’s a i w f 2026 and you can get started and start tracing your voice agents. So thank you very much. My name is Ali. I’ll be available for questions for a couple minutes after but really appreciate you guys listening. Cheers.