Por dentro de um agente de voz: STT, LLM, TTS e latência

O que acontece entre a fala e a resposta

Quando um cliente fala com um agente de voz, a impressão é de uma conversa simples: ele pergunta, o agente responde. Por trás dessa simplicidade existe um caminho técnico com várias etapas — o som da voz precisa virar texto, o texto precisa virar uma resposta, e a resposta precisa virar voz de novo. Tudo em tempo real, enquanto o cliente espera do outro lado.

Esse caminho é o que separa um agente de voz que funciona de um que ninguém quer usar. E a variável decisiva é menos óbvia do que parece: importa muito a inteligência do modelo, mas importa ainda mais o tempo de resposta. No chat, uma pausa de alguns segundos passa despercebida — o cliente está lendo, digitando, fazendo outra coisa. Por voz, a mesma pausa quebra o ritmo da conversa. O cliente pergunta "alô?", acha que a chamada caiu, desliga.

Esse processo pode ser construído de duas formas: com o pipeline em cascata, que encadeia três modelos especializados (STT → LLM → TTS), e os modelos realtime, que surgiram como alternativa. As duas resolvem o mesmo problema de formas diferentes — e, nas duas, a fluidez da conversa depende de como as etapas se encaixam.

O pipeline em cascata: STT → LLM → TTS

A arquitetura clássica de um agente de voz é uma cascata de três etapas especializadas. Cada uma resolve um problema diferente, e a saída de uma alimenta a entrada da seguinte.

1. STT — a fala vira texto

A primeira etapa é o STT (speech-to-text, ou reconhecimento de fala): um modelo que ouve o áudio do cliente e o transcreve em texto, em tempo real. A transcrição vai sendo produzida enquanto o cliente ainda está falando, palavra a palavra.

Transcrever é só metade do trabalho do STT. A parte que pouca gente percebe até esbarrar nela é saber quando o cliente terminou de falar. Numa conversa entre duas pessoas, esse julgamento é instintivo — percebemos a entonação caindo, a frase se completando, a pausa que indica "sua vez". Um agente de voz precisa fazer esse mesmo julgamento, chamado de detecção de fim de turno. Se o agente espera demais, a conversa fica lenta. Se espera de menos, ele atropela o cliente no meio da frase. Os sistemas modernos combinam a análise do áudio (silêncio, entonação) com a análise do texto transcrito (a frase está gramaticalmente completa?) para acertar esse ponto.

2. LLM — o texto vira resposta

Com a transcrição pronta, entra o LLM (large language model, o mesmo tipo de modelo por trás dos assistentes de IA de texto). Ele recebe a pergunta transcrita junto com o contexto da conversa — o que já foi dito, as instruções do agente — e gera a resposta.

Num agente de atendimento, essa etapa inclui um passo a mais: antes de responder, o modelo consulta a base de conhecimento da empresa — os documentos, FAQs e políticas que a empresa cadastrou. A resposta sai fundamentada no conteúdo real da empresa, e não no conhecimento genérico do modelo. Esse é o mesmo mecanismo usado no chat; voz e chat compartilham a mesma base, o que muda é o canal.

3. TTS — a resposta vira voz

A última etapa é o TTS (text-to-speech, ou síntese de voz): um modelo que converte o texto da resposta em áudio com voz natural — com entonação, ritmo e pausas que soam humanas. A qualidade dos modelos de síntese atuais é um dos motivos de o atendimento por voz com IA ter se tornado viável: a voz robótica e arrastada das URAs antigas ficou no passado.

O ponto estrutural dessa arquitetura: as três etapas são sequenciais. O TTS precisa do texto do LLM, que precisa da transcrição do STT. E cada etapa adiciona o seu tempo de processamento à conta. É aqui que entra o problema central dos agentes de voz.

Por que a latência define a experiência

Numa conversa entre duas pessoas, o intervalo entre uma pessoa terminar de falar e a outra começar a responder é curto — frações de segundo. Esse ritmo é tão enraizado que qualquer desvio chama atenção: uma pausa longa demais sugere que a pessoa não ouviu, não entendeu, ou que a ligação caiu.

Um agente de voz é julgado por esse mesmo padrão. O cliente não vê o pipeline; ele só sente a espera. Somar o tempo do STT, do LLM (incluindo a consulta à base de conhecimento) e do TTS, um atrás do outro, produziria pausas longas demais para uma conversa confortável. Por isso, os sistemas de voz bem construídos não esperam cada etapa terminar — eles sobrepõem as etapas:

• Transcrição contínua — o STT transcreve enquanto o cliente fala, em vez de esperar a frase terminar para começar. Quando o cliente conclui, a transcrição já está praticamente pronta.
• Streaming entre as etapas — o LLM gera a resposta em fluxo (palavra a palavra), e o TTS começa a falar as primeiras palavras antes de o restante da resposta existir. O cliente ouve o início da resposta enquanto o final ainda está sendo gerado.
• Tratamento de interrupções — em conversa real, uma pessoa interrompe a outra o tempo todo. O cliente começa a falar no meio da resposta do agente, e o agente precisa parar de falar, ouvir, e levar em conta que a resposta ficou pela metade. Sem isso, o cliente fica preso ouvindo uma resposta até o fim, sem conseguir intervir.

A soma dessas técnicas é o que faz a conversa parecer natural — inclusive nas condições em que clientes reais conversam: com ruído de fundo, mudando de ideia no meio da frase, cortando a resposta para já fazer a pergunta seguinte. É para esse cenário que a arquitetura de um agente de voz precisa ser construída.

Modelos realtime: a alternativa ao pipeline

Nos últimos anos surgiu uma segunda arquitetura: os modelos realtime (também chamados de speech-to-speech). Em vez de três etapas especializadas, um único modelo processa o áudio diretamente — ouve a voz e gera voz, sem passar pelas conversões intermediárias de texto como etapas separadas.

As vantagens são reais:

• Menos latência estrutural — como não há fronteiras entre etapas, o tempo das transições some da conta.
• Percepção do que o texto não captura — hesitação, tom de voz, ironia, urgência. Uma transcrição escreve "tá ótimo"; o modelo realtime percebe se foi dito com satisfação ou com sarcasmo.
• Entonação mais natural na resposta — o modelo decide como falar junto com o que falar, em vez de entregar um texto pronto para outro modelo vocalizar.

E as limitações também são reais:

• Menos controle sobre cada etapa — na cascata, cada componente pode ser escolhido, ajustado e trocado de forma independente: o melhor STT para português brasileiro, a voz de TTS com o sotaque desejado, o LLM mais adequado ao caso. No modelo realtime, o pacote vem fechado.
• Ecossistema mais novo — a variedade de modelos, vozes e idiomas ainda é menor que a do ecossistema em cascata, que teve mais tempo para amadurecer.

Na prática, são duas arquiteturas com perfis diferentes — e a escolha depende do caso. Operações que precisam de controle fino sobre a voz e o comportamento de cada etapa tendem à cascata; casos em que a naturalidade da conversa pesa mais tendem ao realtime. Os dois caminhos estão evoluindo rápido, e a distância entre eles muda a cada geração de modelos.

O que isso muda para quem usa a Sintue

Toda essa engenharia — pipeline, streaming, detecção de turno, interrupção, modelos realtime — é o tipo de problema que vale a pena entender, e que raramente vale a pena construir do zero.

Na Sintue, as duas arquiteturas estão disponíveis: o agente de voz pode rodar em pipeline em cascata, com voz e modelos configuráveis, ou em modelo realtime, quando a naturalidade da conversa é prioridade. Nos dois casos, o agente consulta a mesma base de conhecimento da empresa e encaminha para a equipe humana com o histórico completo quando o caso exige.

Para a empresa, o trabalho se resume a criar o agente, subir os documentos e instalar o widget no site — o guia de configuração mostra cada etapa. O canal de voz passa a atender os clientes sem fila e em qualquer horário, com toda essa engenharia já resolvida.