A voz em tempo real oferece uma forma fundamentalmente diferente de interagir com aplicativos baseados em IA. Em vez de digitar ou navegar por menus, os usuários falam naturalmente e recebem respostas com ritmo em tempo real e contexto emocional.
Criar uma ótima experiência de voz em tempo real é uma questão de coordenar uma interação ao vivo. É aqui que começa o verdadeiro trabalho de produto. A experiência em tempo real é imediata e natural; criar um aplicativo que sustente essa sensação é um desafio de engenharia específico.
O modelo é apenas uma parte do sistema. Aplicativos em produção precisam de infraestrutura nativa para voz, uma separação clara entre o fluxo da conversa e o raciocínio mais aprofundado e um controle orientado a eventos para gerenciar a sessão conforme ela acontece.
As proteções e a avaliação concentram grande parte das dificuldades que ainda restam. As verificações de segurança precisam acompanhar o áudio ao vivo, e características efêmeras da conversa, como tempo de resposta, tom e fluidez, são difíceis de avaliar com estratégias tradicionais.
Hoje, a maioria dos aplicativos de IA com recursos de voz ainda funciona da mesma maneira: a fala entra, o texto sai, um modelo pensa e uma voz sintetizada lê a resposta. Funciona. Mas a interação parece exatamente o que é: um pipeline, não uma conversa.
A voz em tempo real muda isso. Os usuários falam naturalmente e recebem respostas que transmitem ritmo, tom e contexto emocional. A experiência é mais rápida e fluida do que em pipelines encadeados de conversão de fala em texto, mais próxima de conversar com uma pessoa do que de operar um sistema.
Vimos isso viabilizar experiências de produto com as quais arquiteturas baseadas em pipelines têm dificuldade. Agentes de voz em tempo real podem conduzir atendimentos que, de outra forma, exigiriam menus longos e restritivos de resposta audível interativa e transferências entre departamentos. Eles podem orientar, integrar novos usuários, promover acessibilidade em diferentes meios e muito mais. Sempre que a conversa falada oferecer uma vantagem sobre interfaces baseadas em texto, vale a pena desenvolver uma solução de voz em tempo real.
A maioria dos aplicativos com recursos de voz usa o chamado "método encadeado": um pipeline de modelos separados para conversão de fala em texto, processamento de linguagem e conversão de texto em fala. Esses sistemas funcionam bem e abrem muitas possibilidades, mas o áudio aparece apenas nas extremidades. As etapas distintas impõem estrutura e latência, resultando em uma interação menos natural do que uma conversa real.
A voz em tempo real adota uma abordagem diferente. Em vez de usar modelos distintos para ouvir, pensar e falar, um único modelo realiza as três tarefas nativamente, compreendendo e gerando áudio e transcrições ao mesmo tempo. A entrada e a saída acontecem continuamente, permitindo que o sistema responda com ritmo natural e emoção, preservando a cadência realista de uma conversa ao vivo. Com isso, o tempo de resposta, o tom e o tratamento de interrupções tornam-se elementos centrais do produto.
A experiência em tempo real é atraente porque parece imediata; é difícil porque nada espera sua vez. Viabilizá-la exige mais do que gerar áudio com rapidez e precisão. A parte difícil é todo o resto. O modelo opera dentro de uma sessão ao vivo; tudo ao redor dele — estado, segurança, orquestração e controle — precisa acompanhar a conversa no mesmo ritmo.
Em um aplicativo de voz encadeado, as conversas baseadas em turnos oferecem uma estrutura clara de troca. O usuário fala, o sistema responde e a próxima etapa começa. A voz em tempo real não oferece essa estrutura. As duas partes podem falar ao mesmo tempo ou nenhuma delas fala, e há silêncio. O usuário pode interromper no meio de uma resposta ou fazer outra pergunta antes de o sistema terminar de falar. As interrupções deixam de ser casos extremos e passam a ser um padrão central de interação.
É esse padrão que transforma os aplicativos em tempo real, em sua essência, em um problema de coordenação — e faz com que o sistema ao redor do modelo seja tão importante quanto o próprio modelo.
Viabilizar esse tipo de sistema em escala exige um projeto específico para interações ao vivo, com três elementos recorrentes nos sistemas que chegam à produção.
As sessões de voz em tempo real precisam lidar com streaming de áudio, alternância de turnos, interrupções, ciclo de vida da conexão e execução do agente. Dependendo de onde o aplicativo for implantado, também pode ser necessário oferecer suporte a telefonia. Esses são elementos fundamentais da experiência e essenciais para escalar o aplicativo.
O primeiro requisito é uma camada de sessão nativa para voz. Frameworks de comunicação em tempo real (RTC) fornecem ao aplicativo um ambiente para gerenciar participantes, transmitir áudio e executar agentes em um contexto de telefonia. Em nossa experiência, o Livekit tem sido especialmente útil por oferecer uma stack WebRTC de baixa latência, com cancelamento de ruído de alta qualidade e redução de jitter prontas para uso. Raramente vale a pena assumir a complexidade adicional de implementar essa camada por conta própria.
Uma arquitetura multiagente para voz em tempo real se baseia essencialmente na separação de responsabilidades.
Modelos de voz em tempo real são muito eficazes no streaming de áudio conversacional, mas não são otimizados para raciocínio aprofundado. Tarefas como chamar ferramentas, recuperar informações ou tomar decisões estruturadas se beneficiam da execução por outro modelo.
Um padrão útil é a arquitetura respondedor–pensador.
O respondedor é o agente de voz em tempo real. Ele é responsável por manter a interação ao vivo: ouvir, falar, lidar com interrupções e preservar a fluidez da conversa. Seu projeto prioriza agilidade, clareza e continuidade emocional.
O pensador é um agente separado, equipado com um modelo capaz de raciocínio. Ele opera fora do fluxo principal e executa tarefas como uso de ferramentas, recuperação de informações e planejamento. O respondedor pode acioná-lo quando necessário e incorporar os resultados à conversa.
Em alguns casos, o pensador pode realizar o raciocínio diretamente. Em outros, pode atuar como orquestrador de um conjunto de agentes especializados. A ideia central é que esse trabalho seja realizado por um modelo mais adequado a tarefas de raciocínio.
A vantagem é simples: o respondedor permanece rápido, focado e natural na conversa, enquanto o pensador cuida do trabalho que exige mais tempo, contexto ou estrutura.
Avanços futuros nos modelos de fronteira podem tornar essa abordagem desnecessária, mas, por enquanto, constatamos que esse padrão supera de forma consistente as abordagens com um único agente.
Sistemas de voz em tempo real produzem naturalmente um fluxo contínuo de eventos.
Os usuários começam a falar, fazem pausas e interrompem. As transcrições são atualizadas gradualmente. As respostas são geradas e transmitidas. Resultados externos chegam. As condições da sessão evoluem. Tudo isso pode ser capturado, transmitido e armazenado como eventos importantes que deram origem ao estado atual específico da conversa. Sem esses eventos, perdemos a capacidade de fazer intervenções granulares e direcionadas.
Uma abordagem orientada a eventos oferece uma forma clara de gerenciar isso. O sistema captura os eventos à medida que ocorrem, atualiza o estado da sessão e aciona as ações subsequentes adequadas.
Handlers leves mantêm o fluxo em tempo real responsivo, enquanto tarefas mais complexas — como atualizar máquinas de estado, registrar métricas, remover informações confidenciais, atualizar bancos de dados e encerrar uma sessão — são acionadas de forma assíncrona em segundo plano.
À medida que novos recursos são adicionados, a quantidade dessas tarefas em segundo plano pode crescer rapidamente. Mesmo pequenas mudanças no produto podem introduzir novos fluxos de eventos e dependências. Uma arquitetura bem estruturada para essa concorrência é importante para manter o sistema compreensível e confiável à medida que evolui.
Essa abordagem orientada a eventos também atende a uma questão essencial do produto: moldar a própria conversa. Um sistema de áudio em tempo real faz mais do que gerar respostas: ele gerencia o ritmo, lida com silêncios e interrupções e decide como e quando uma sessão deve terminar. Esses comportamentos fazem parte da experiência do produto e se beneficiam de um projeto explícito.
Conforme o estado da sessão evolui com base no número de turnos, no tempo decorrido ou no comportamento do usuário, o sistema pode fornecer orientações direcionadas ao respondedor. Ele pode orientar o agente a ajudar o usuário a concluir a conversa quando o limite da sessão se aproxima ou fornecer esclarecimentos caso a interação fique estagnada. Essas intervenções são leves, mas fazem a experiência parecer intencional e coesa.
Um sistema bem projetado mantém uma visão clara do estado da sessão: quem está falando, como a conversa está avançando e quais condições foram atendidas. Esse estado, atualizado continuamente pelo fluxo de eventos, permite oferecer a orientação certa no momento certo.
As proteções não são opcionais em sistemas de IA voltados ao usuário. Elas cuidam da segurança, da conformidade, do uso indevido e da confiabilidade. Em um sistema baseado em turnos, há momentos óbvios para aplicá-las: depois que o usuário fala ou antes que uma resposta seja entregue.
A voz em tempo real elimina a maioria desses pontos de verificação convenientes. A entrada do usuário chega continuamente. A saída de áudio pode já estar sendo transmitida. As transcrições concluídas muitas vezes ficam defasadas em relação ao áudio. Se o sistema esperar mensagens completas para verificá-las, a conversa deixa de parecer em tempo real.
Em vez disso, as proteções precisam operar em paralelo à conversa para preservar uma interação natural. Uma abordagem é transmitir o áudio para um buffer enquanto os fragmentos da transcrição são avaliados de forma assíncrona à medida que ficam disponíveis. Assim, as verificações de segurança podem acompanhar um ritmo próximo do tempo real sem bloquear a interação.
Quando uma proteção é acionada, o sistema pode responder dentro do contexto, redirecionando a conversa, ajustando o comportamento ou encerrando a sessão quando necessário. Isso garante que as proteções funcionem em tempo real sem prejudicar a experiência do usuário.
O mais difícil ao avaliar um sistema de conversação em tempo real é que algumas das características mais importantes — tempo de resposta, interrupções, fluidez e tom — não podem ser captadas por testes baseados apenas em transcrições.
Pipelines de avaliação convencionais inserem cenários realistas no sistema, observam as saídas e atribuem pontuações. Em sistemas baseados em texto ou com áudio encadeado, isso é simples: enviar texto e verificar o texto retornado. Em tempo real, a entrada é áudio ao vivo, e as dinâmicas mais importantes da conversa estão na dimensão temporal: como o agente lida com falas simultâneas, com que rapidez responde e como se recupera de uma interrupção.
Os testes manuais — falar diretamente com o agente — captam essas características, mas não são escaláveis. A automação baseada em transcrições é escalável, mas elimina o sinal que diferencia uma boa experiência em tempo real de uma experiência ruim.
Nenhum método é suficiente por si só. Na prática, a solução é combinar abordagens:
Avaliações entre agentes: um segundo agente em tempo real, instruído a assumir uma persona específica de usuário, conversa com o sistema em teste. Um terceiro LLM, atuando como avaliador, pontua a interação. Isso permite testar em escala todo o fluxo de áudio, inclusive o tempo de resposta e o tratamento de interrupções.
Métricas não funcionais: o tempo até o primeiro áudio e a análise de sentimento das transcrições fornecem indicadores quantitativos da qualidade da conversa.
Análise qualitativa manual: continua essencial para detectar problemas não identificados pelas métricas automatizadas, sobretudo quanto ao tom e à naturalidade.
Nenhum método cobre tudo sozinho. Colocar agentes em tempo real em produção exige combinar as três abordagens. Mesmo assim, as ferramentas para avaliar áudio em tempo real ainda são pouco maduras em comparação com as usadas para IA baseada em texto.
A voz em tempo real transforma o produto. O tempo de resposta, as interrupções, o silêncio e a retomada influenciam a experiência tanto quanto as palavras.
Isso significa que o modelo é apenas parte do sistema. Uma solução de voz em tempo real para produção precisa de uma camada de sessão nativa para voz, uma separação clara entre fala e raciocínio e um controle orientado a eventos em torno da sessão ao vivo. As proteções continuam sendo o gargalo de latência, mas abordagens criativas podem preservar grande parte da experiência em tempo real.
A avaliação ainda é o ponto mais fraco da arquitetura. Ainda não há uma forma consolidada de testar as características que tornam agradável uma experiência de voz em tempo real: tempo de resposta, tom, tratamento de interrupções e fluidez da conversa. Enquanto isso não existir, as equipes que usam essa tecnologia precisarão combinar testes automatizados, execuções entre agentes e análises manuais.