Como criar um agente de voz usando IA (Guia Completo)

Aqui está a verdade que ninguém conta para quem constrói agentes de IA: agentes de voz não precisam do melhor modelo. Tudo o que eles precisam é

TL;DR; se você acha leitura chata ou sua atenção está curta, pode usar o arquivo de skill que fiz para pegar o artigo inteiro e colar no seu agente ➡️https://github.com/codejunkie99/voice-agent-builder

tudo o que você precisa construir é:

• um pipeline em tempo real com um orçamento de latência real
• cinco componentes conectados na ordem certa
• um grounding forte o suficiente para manter o modelo honesto
• um loop de revisão semanal que se acumula

A OpenAI lançou o GPT-Realtime-2 em 7 de maio de 2026. A Salesforce AI Research publicou o artigo VoiceAgentRAG em 1º de março, na mesma semana em que o Deepgram Flux passou de beta para GA. As peças deixaram de ser o problema.

O que continuou sendo o problema é como você as conecta, e o que você escreve para o agente dizer.

Passei os últimos três meses construindo agentes de voz que realmente atendem o telefone. Não vou fingir que foi limpo.

• A primeira versão parecia um quiosque. Descartei em dois dias.
• A segunda versão "agendou" quatro compromissos fantasmas na primeira hora antes que eu percebesse.
• A terceira versão vazou memória porque esqueci de invalidar o cache de contexto depois que o extrator de fundo escreveu novos fatos.
• Quando algo finalmente funcionou, o sistema era a quarta reescrita.

A versão que eu defenderia agora tem um pequeno conjunto de propriedades que vou explicar nas próximas 6.000 palavras.

• O pipeline tem um trabalho dentro de um orçamento. Cinco componentes, abaixo de 700ms de ponta a ponta, sem exceções.
• O conhecimento vive nos seus documentos e é recuperado com um cache de agente duplo, não extraído da cabeça do modelo.
• O design de conversação é a disciplina de escrever para ouvidos, não para olhos. A maioria das equipes trata isso como cosmético. Não é.
• Cada turno escreve um log estruturado que posso reproduzir contra a configuração atual 90 dias depois.

Este artigo é o que esses 90 dias realmente me ensinaram, mais as duas ou três apostas que eu faria primeiro se começasse hoje.🔽🔽

O que um agente de voz realmente é

Um agente de voz não é um chatbot com um microfone acoplado. Não é um wrapper de TTS em torno de uma API de texto.

É um sistema de áudio em tempo real. Com restrição de latência. Cinco componentes coordenando dentro de uma janela de 300 a 800 milissegundos.

O pipeline na ordem em que os eventos realmente acontecem:

1. O usuário fala
2. O áudio é capturado
3. O STT em streaming transcreve palavra por palavra, enquanto a pessoa ainda está falando
4. O agente lê a transcrição e recupera o conhecimento relevante dos seus documentos
5. O LLM gera uma resposta
6. O TTS fala a resposta em voz alta
7. O usuário ouve

Cada uma dessas setas é um componente que você pode escolher, ajustar e trocar.

Tentei construir primeiro do jeito de chatbot. STT completa, envia para o LLM, espera pela resposta completa, envia para o TTS, espera pelo áudio completo, reproduz.

Parecia horrível. Como falar com um quiosque. Dois dias depois, deletei.

O motivo de parecer horrível não é que os números de latência fossem ruins. Eles eram bons no papel. O motivo é que os humanos não conversam em turnos. Eles conversam em fluxos sobrepostos.

• O agente tem que começar a formular uma resposta enquanto o usuário ainda está terminando a frase.
• O TTS tem que começar a falar antes que o LLM termine de escrever.
• O STT tem que continuar ouvindo enquanto o agente está falando, para saber quando calar a boca.

Um agente de voz que não pode ser interrompido não é um agente de voz. É um correio de voz.

As três arquiteturas

Existem apenas três. Escolha pelo que você precisa controlar.

Pipeline encadeado

• Serviços separados de STT, LLM e TTS conectados entre si
• Três modelos independentes, cada um especializado em sua função
• O texto flui entre eles
• A latência fica em torno de 600 a 700ms em uma plataforma gerenciada bem ajustada
• Mais controlável, mais depurável, mais fácil de atualizar uma camada de cada vez

Meio-cascata

• O áudio vai diretamente para um modelo multimodal que ouve o áudio, não a transcrição
• Captura frustração na voz de alguém, uma pergunta implícita pelo tom ascendente, uma mudança de idioma no meio da frase
• A saída ainda passa por um TTS especializado para controle de áudio
• A latência cai para 300 a 500ms

Fala-para-fala nativo

• Um modelo, áudio entra, áudio sai
• Sem camada de transcrição, sem transferências de texto
• Todos os grandes laboratórios lançaram um modelo de voz nativo em 2026
• A latência cai para 200 a 300ms, abaixo do limite onde os chamadores param de notar que estão falando com IA

Por onde começar

1. Comece com o pipeline encadeado. As melhores ferramentas existem para ele. Mude para fala-para-fala depois de validar seu produto no pipeline e quiser uma melhoria drástica de latência.
2. Tentei fala-para-fala primeiro para tudo. Foi excelente para fluxos de reserva.
3. Ele desmoronou em um formulário de admissão de 12 etapas porque o modelo único não conseguia manter a máquina de estados na cabeça sem inchaço de contexto no turno nove.
4. Mudei aquele para um pipeline encadeado com uma camada de máquina de estados real e a taxa de conclusão saltou de 61% para 89% em três dias.
5. O escopo das ferramentas por estado foi a correção inteira.

Os cinco componentes que você precisa conectar

Todo pipeline encadeado tem os mesmos cinco componentes. Cinco trabalhos que precisam ser preenchidos antes do seu agente atender a primeira chamada.

Os ouvidos (STT em streaming)

O modelo STT converte o áudio recebido em texto em tempo real, palavra por palavra, enquanto a pessoa ainda está falando. Este é o componente mais importante da sua pilha. Um erro de transcrição aqui se propaga por tudo abaixo.

O que procurar em 2026:

• Precisão em streaming. Precisa ser preciso enquanto a pessoa está falando, não apenas depois que termina.
• Taxa de erro de palavras. 6 a 8% em áudio de produção real é bom. Acima de 12% vai frustrar os usuários em cada terceira chamada.
• Detecção de fim de turno embutida. A maior melhoria de UX de 2026.

Por que a detecção de fim de turno é importante:

• STT genérico retorna transcrições. Não diz quando o falante terminou.
• Sem ela, seu agente interrompe no meio da frase ou espera dois segundos estranhos.
• A onda de 2026 de modelos STT em streaming vem com detecção de fim de turno dentro da mesma rede que produz a transcrição.
• O modelo emite um sinal de turno completo quando decide que o falante terminou.
• O sinal usa contexto semântico, não apenas silêncio acústico. Ele captura desvanecimentos e ignora pausas para respirar.
• Mude para isso se seu provedor já lançou. A pausa antes do agente começar a falar cai de 200 a 400ms em cada turno.

O cérebro (LLM)

O LLM lê a transcrição, o histórico da conversa, o conhecimento recuperado e decide o que dizer. Ele também decide ações, não apenas palavras.

Regras específicas para voz:

• Use o modelo pequeno e rápido, não o principal. Modelos de raciocínio de fronteira levam 1500ms para gerar a primeira palavra. Isso é ar morto. Modelos menores da mesma família quase sempre vencem em turnos de voz.
• Escalone para o modelo grande apenas para chamadas de ferramentas complexas específicas que precisam de planejamento real.
• Limite o prompt do sistema a 800 tokens. Ele recarrega a cada turno. Um prompt de 4000 tokens adiciona latência a cada mensagem.

Chamada de função, em português claro:

• Você define cada função com uma descrição do que ela faz e de quais informações precisa.
• O LLM lê a descrição e decide quando chamá-la com base no estado da conversa.
• Sem árvore de lógica condicional. O LLM combina intenção com função a partir da linguagem natural.

A falha de produção mais comum com chamada de função não é o que você esperaria:

• O LLM não lança um erro quando não consegue chamar uma função. Ele narra a ação.
• "Confirmei sua reserva." Nada foi chamado. O usuário pensa que está reservado. Não está.
• A correção é definir o escopo das ferramentas para o estado atual. Um estado "coletar nome" não deve expor book_appointment. Um estado "confirmar detalhes" não deve expor check_availability.
• A máquina de estados é o trilho de segurança, não o prompt do sistema.

O conhecimento (RAG)

RAG é o mecanismo que permite que seu agente responda a partir dos seus documentos, em vez dos dados de treinamento do modelo.

Por que você não pode pular isso:

• LLMs são treinados na internet pública até uma data de corte.
• Eles sabem muito sobre o mundo. Eles não sabem nada específico sobre seus produtos, preços, políticas, clientes.
• Sem RAG, um agente perguntado "o que tem no plano empresarial?" vai alucinar com confiança.
• Com RAG, ele recupera a resposta real da sua documentação antes de responder.

O mecanismo básico:

• Usuário faz uma pergunta.
• Sistema incorpora a consulta.
• Banco de dados vetorial retorna os trechos de documento mais relevantes.
• Trechos são injetados no contexto do LLM.
• O LLM é instruído a responder apenas a partir desse contexto.

O desafio específico da voz:

• Uma consulta típica de banco de dados vetorial adiciona 50 a 300ms ao pipeline.
• Combinado com STT, LLM e TTS, isso explode seu orçamento de latência.
• A correção é o padrão de cache de agente duplo. Seção inteira sobre isso abaixo.

A boca (TTS)

O TTS converte texto em áudio falado. Parece simples. Na verdade, é um grande diferencial na qualidade percebida.

O que importa:

• Tempo até o primeiro áudio. Um TTS que leva 200ms para começar a falar queima um terço do seu orçamento de latência apenas na camada de saída.
• Qualidade da voz. Humanos são extraordinariamente sensíveis à fala sintética. Artefatos sutis, ritmo não natural, ênfase deslocada, tudo isso é lido como um veredicto sobre todo o sistema.
• Escolha a voz intencionalmente. É um sinal de confiança antes que o usuário tenha ouvido uma frase.

As mãos (Funções e integrações)

Funções são ações que o LLM pode executar no meio da conversa:

• Reservar compromissos
• Consultar status de pedidos
• Enviar SMS de confirmação
• Transferir para um humano
• Atualizar registros no seu CRM

Esta é a mudança arquitetural que torna os agentes de voz modernos dramaticamente mais capazes do que sistemas de "pressione 1 para falar com o faturamento".

O orçamento de latência no qual você precisa se encaixar

A coisa mais importante e não óbvia sobre agentes de voz: cada milissegundo de tempo de processamento é um milissegundo de silêncio que o chamador enfrenta.

A matemática:

• Humanos esperam uma resposta conversacional dentro de 500 a 700ms após terminar uma frase
• Acima de um segundo, parece que o sistema está com dificuldades
• Acima de dois segundos, os chamadores começam a falar por cima do agente

Esses 700ms são todo o seu orçamento, dividido entre todos os componentes.

Orçamento por componente, via rápida vs via lenta:

• Transporte. 20-50ms ponto a ponto. 50-100ms via relays.
• STT primeiro interim. 100-150ms em cache hit. 150-250ms em cache miss.
• Detecção de fim de turno. Integrado ao modelo, ~50ms. Limiar de silêncio, 300-600ms.
• Recuperação RAG. Sub-milissegundo em cache hit. 80-150ms em BM25 local + rerank.
• LLM tempo até o primeiro token. 150-250ms com um modelo pequeno. 400-600ms com um modelo de fronteira.
• TTS tempo até o primeiro áudio. 60-100ms no nível rápido. 150-250ms no nível de qualidade.
• Overhead de rede. 40-80ms total dentro de uma região. 100-160ms total entre regiões.
• Ponta a ponta. ~440ms na via rápida. ~700-900ms na via lenta.

Os dois maiores avanços em 2026:

1. Detecção de fim de turno integrada ao modelo. Remove 200 a 400ms de cada turno. A maior melhoria que você pode fazer este ano.
2. Pré-busca especulativa com cache de agente duplo. Transforma a recuperação de "cache miss com busca vetorial" para "cache hit com consulta em cache" em aproximadamente 40% dos turnos.

Todo o resto é erro de arredondamento comparado a esses dois.

O padrão RAG de agente duplo

RAG padrão dentro de um loop de voz é um problema. A consulta ao banco de dados vetorial leva 80 a 300ms e explode seu orçamento de latência em cada turno.

A resposta da pesquisa de 2026 vem do artigo VoiceAgentRAG da Salesforce AI Research, publicado em março. A percepção é simples.

• Em uma conversa real, a próxima pergunta geralmente é previsível a partir da atual.
• Alguém perguntando sobre preços provavelmente vai perguntar sobre o nível empresarial em seguida.
• Alguém perguntando sobre instalação provavelmente vai perguntar sobre compatibilidade depois.

Então você executa dois agentes ao mesmo tempo.

O agente de fundo (Pensador Lento)

• Executa enquanto o usuário está ouvindo a resposta atual
• Prevê as três a cinco perguntas de acompanhamento mais prováveis usando o LLM
• Pré-busca trechos de documento relevantes para cada previsão
• Armazena-os em um cache de memória local antes que o usuário termine de ouvir a resposta atual

O agente de primeiro plano (Falador Rápido)

• Lida com a próxima pergunta ao vivo verificando primeiro o cache de memória
• Uma consulta ao cache leva tempo sub-milissegundo vs 110ms para uma chamada remota ao banco de dados vetorial
• Se o cache tem a resposta, pule o banco de dados completamente
• Se o cache não tem, recorra ao banco de dados e armazene esse resultado em cache para a próxima vez

Números de referência do artigo

• 75% das consultas encontram o cache
• 316× de aceleração na recuperação em cache hits (0,35ms vs 110ms)
• 16 segundos de latência cumulativa economizados em 200 consultas

O princípio para lembrar: use o tempo de escuta do usuário como seu tempo de computação. O momento em que eles começam a ouvir a resposta atual é o momento em que você começa a se preparar para a próxima pergunta deles.

Tentei RAG vetorial simples dentro do loop de voz na minha primeira versão. Adicionou 110ms por turno.

Matou a sensação de conversa. Mudei para o padrão de cache de agente duplo na semana seis. Os 40% dos turnos que encontram o cache parecem mais rápidos do que os atendentes humanos do call center que o agente substitui.

Design de conversação é a disciplina que a maioria dos construtores pula

Você pode ter o STT mais rápido, o LLM menor, o cache RAG mais inteligente. Se seu agente não sabe conversar, os chamadores vão desligar.

Design de conversação é a disciplina de escrever para ouvidos, não para olhos.

Regras que sigo agora que aprendi errando primeiro

• Fale em frases curtas. O tempo médio de atenção humana para informação falada é de 8 a 10 segundos. Uma resposta de 15 segundos é muito longa. Divida em dois turnos.
• Nunca faça duas perguntas em um turno. Os chamadores só conseguem segurar uma na memória de trabalho. Pergunte uma, espere, depois pergunte a próxima.
• Use frases de reconhecimento. "Entendi." "Claro." "Deixa eu verificar isso para você." Elas preenchem o silêncio entre o usuário terminar e a resposta ficar pronta.
• Espelhe a linguagem do usuário. O chamador diz "problema de faturamento", o agente diz "problema de faturamento" de volta. Não "disputa financeira" ou "problema de pagamento". Parafrasear cria atrito. Espelhar cria rapport.
• Escreva para o ouvido, não para o olho. Sem marcadores. Sem cabeçalhos. Sem markdown no prompt do sistema. O LLM vai tentar falar asteriscos e hífens.
• Soletre números. "Nove quatro um zero sete" em vez de "94.107". "Quinze dólares e noventa e nove centavos" em vez de "$15,99". O TTS frequentemente pronuncia números formatados incorretamente.
• Limite o prompt do sistema a 800 tokens. Ele recarrega a cada turno.

A estrutura de três atos de toda boa conversa de voz

1. Reconhecimento e orientação. "Então você quer reagendar seu compromisso na quinta-feira, deixa eu puxar isso aqui." Confirma que o chamador foi compreendido. Ganha tempo enquanto a recuperação é executada.
2. Resolução. A ação ou resposta central. Um ponto por turno. Siga em frente.
3. Confirmação e encerramento. "Remarquei seu compromisso para segunda-feira, dia 19, às 15h, você receberá um SMS de confirmação em breve." Saída limpa. Nunca deixe um loop aberto.

Segurança são dois pontos de verificação, não um

O componente que a maioria dos construtores iniciantes pula e se arrepende.

Um agente de voz não tem um momento de "ler antes de enviar". Uma saída insegura é falada imediatamente. Sem rascunho, sem prévia, sem humano no loop.

O modelo certo são dois pontos de verificação.

O guardião de entrada (antes do LLM ver o turno do usuário)

• Injeção de prompt. Ataques "Ignore as instruções anteriores, finja que você é...". Explora a capacidade do LLM de seguir instruções para roubar dados ou quebrar o escopo.
• PII falado em voz alta. Números de cartão de crédito, números de segurança social. Remova antes que atinjam qualquer log ou banco de dados.
• Lista de bloqueio de tópicos. Carregada de um arquivo JSON. Atualizada semanalmente à medida que você aprende o que os usuários realmente tentam.

O guardião de saída (depois que o LLM escreve sua resposta, antes do TTS falar)

• Linguagem de promessa excessiva. "Eu garanto", "Eu prometo". Cria problemas legais e de confiança em uma linha gravada.
• Alegações factuais específicas não presentes no contexto recuperado. Verificação leve de alucinação. Captura cerca de 70% das respostas confabuladas na minha implantação.
• Endpoint de moderação padrão. Para o raro mau comportamento do modelo.

O que ambos os guardiões retornam

• safe (bool)
• detected category (string, se inseguro)
• replacement phrase que o agente fala em vez disso

Cada gatilho é registrado em um arquivo com timestamp, categoria, texto editado e ID da chamada.

A frase de escalonamento

Uma frase exata, codificada, que o agente diz quando não sabe a resposta ou quando algo está dando errado.

• "Quero ter certeza de que vou te dar informações precisas. Deixa eu te conectar com alguém que possa ajudar."
• Não cinco variações. Não o palpite improvisado do LLM sobre a frase certa.
• Uma frase. EM CAIXA ALTA no prompt do sistema. Padrão quando qualquer verificação de segurança dispara.

Lancei sem um guardião de saída na primeira versão. O agente cotou com confiança um preço 30% abaixo do real.

O preço estava em um documento desatualizado na base de conhecimento.

A verificação de alucinação teria pego porque o preço certo não estava no contexto recuperado.

Avaliação, ou como saber se é bom

Você não pode melhorar o que não pode medir. A maioria das equipes pula a avaliação e lança agentes quebrados.

A estrutura de quatro camadas

Camada 1: Infraestrutura. Parte estrutural.

• WER no seu domínio real (não benchmarks de fornecedores)
• p50, p95, p99 de latência para o pipeline completo
• Tempo até o primeiro áudio
• Qualidade de áudio no seu transporte

Camada 2: Execução. O agente fez o que foi solicitado.

• Taxa de sucesso da tarefa
• Precisão da chamada de ferramenta
• Correção dos parâmetros
• Fundamentação da resposta
• Use LLM-como-juiz em um modelo pequeno e rápido. Quatro perguntas de sim/não: respondeu corretamente, manteve-se fundamentado, soou natural para voz, foi apropriadamente conciso.

Camada 3: Comportamento do usuário. Parece natural conversar?

• Taxa de recuperação de interrupção
• Taxa de nova solicitação
• Duração média do turno
• Número de reparos conversacionais
• Amostre 20 chamadas por semana. Leia as transcrições reais. Você verá padrões em menos de dez.

Camada 4: Resultado de negócio. Resolve o problema?

• Taxa de contenção (percentual de chamadas resolvidas sem um humano)
• Taxa de transferência
• CSAT
• Taxa de resolução na primeira chamada
• Otimize para contenção. Ela se correlaciona com todo o resto e é a mais fácil de medir sem instrumentação.

Composição do conjunto de teste

Construa antes de lançar. Mínimo de 50 conversas.

• 40% caminho feliz
• 30% casos extremos
• 15% tratamento de erros
• 10% adversário (injeção de prompt, tentativas de jailbreak)
• 5% variação acústica (ruído de fundo, sotaque carregado, viva-voz)

Para cada cenário:

• Qual ferramenta deveria ter sido chamada
• Com quais parâmetros
• O que o agente deveria ter dito

O loop de revisão semanal

Toda segunda-feira de manhã. 30 minutos.

1. Puxe as métricas
2. Amostre 20 chamadas (7 escaladas, 7 resolvidas, 6 aleatórias)
3. Leia as transcrições
4. Nomeie o tipo de falha mais comum
5. Faça uma mudança (uma variável de cada vez, sempre)
6. Teste A/B por 48 horas
7. Implemente o vencedor

Fundamentação é um sistema de confiança

A maioria dos construtores pensa em RAG como um recurso de desempenho, uma maneira de obter respostas mais precisas. Esse enquadramento o subestima.

Em um agente de voz, a precisão de cada resposta é uma declaração direta sobre o quão confiável seu produto é. Um chamador que ouve uma resposta errada sobre preço, cobertura ou política, dita com confiança em uma voz de som natural, não ficará apenas frustrado. Ele se sentirá enganado.

A implementação da promessa de confiança tem quatro partes.

1. Fonte da verdade

• Seus documentos, não os dados de treinamento do modelo
• O prompt do sistema tem que dizer isso explicitamente, EM CAIXA ALTA: RESPONDA APENAS A PARTIR DO CONTEXTO FORNECIDO
• O modelo ainda vai derivar para o conhecimento geral às vezes, mas a instrução explícita reduz a taxa em uma ordem de grandeza

1. Recusa elegante

• Quando o agente não encontra uma resposta, ele diz isso diretamente
• A frase exata importa
• "Quero ter certeza de que vou te dar informações precisas, deixa eu verificar isso" compra uma transferência elegante
• "Não tenho certeza" soa como incompetência
• "Com base nas minhas informações" soa como uma evasiva de advogado
• Escolha uma frase, codifique-a, nunca deixe o LLM improvisar aqui

1. Resposta consciente da confiança

• O score BM25 mais alto nos trechos recuperados é um proxy útil para confiança
• Score acima de 0,6: agente responde com confiança
• Score de 0,3 a 0,6: agente responde, mas adiciona uma ressalva "eu acho"
• Score abaixo de 0,3: agente não responde, oferece transferência
• Mudança de 20 linhas no código de construção do prompt do sistema. Reduz alucinações aproximadamente pela metade.

1. Higiene da base de conhecimento

• Documentos desatualizados produzem respostas desatualizadas, que são respostas perigosas
• Executo uma auditoria na sexta-feira: leio os 5% inferiores das respostas com pontuação de confiança da semana
• Metade das vezes a resposta estava certa, mas a recuperação encontrou um trecho desatualizado
• Atualize o trecho, reincorpore, na próxima semana está mais tranquilo

O que observar

Seis modos de falha que vão te atingir.

VAD no pipeline em vez do transporte

• Problema. O agente dispara na própria saída TTS, entra em um loop de interrupção ou falha em detectar o fim do turno completamente.
• Solução. O analisador VAD vai no transporte. Sempre. Emparelhe com um guardião de eco que ignore transcrições STT que correspondam à saída recente do assistente.

Ferramentas disponíveis no estado errado

• Problema. O LLM chama book_appointment em um estado que ainda está coletando o nome do paciente. Ou inventa uma reserva que nunca aconteceu.
• Solução. Defina o escopo das ferramentas por estado. Um estado, apenas suas próprias funções. A máquina de estados é o trilho de segurança, não o prompt do sistema.

Manipulador de função lança exceção e nunca chama o callback de resultado

• Problema. O LLM fica esperando por um resultado de ferramenta que nunca chega. Ou alucina um.
• Solução. Todo manipulador envolve em try/except. Todo ramo envia um resultado de volta. Toda falha tem um fallback falado. Nunca um resultado vazio.

Validar dados do usuário no prompt em vez de no código

• Problema. O LLM aceita "joão@" como um email real na chamada 12. Rejeita um válido com um sinal de mais na chamada 47.
• Solução. A validação vive em Python. Regex para email, analisador de data para datas, verificação de comprimento de nome, uma resposta de nova solicitação quando a validação falha.

Janela de contexto cresce sem limites em uma chamada longa

• Problema. A latência p95 deriva para cima ao longo da semana sem mudanças no código. No turno 20, você está enviando 12 mil tokens por turno.
• Solução. Janela deslizante dos últimos N turnos mais prompt do sistema. Ou resets de contexto baseados em marcos no final de cada estágio discreto.

TTS lê códigos e IDs literalmente

• Problema. Código de confirmação "A3X7" sai "a três ex sete" sem pausa. O paciente pede para repetir de qualquer maneira.
• Solução. Expansão do alfabeto fonético da OTAN com tags de pausa SSML. Soa mais lento. Lê corretamente na primeira vez.

Coisas que eu faria diferente

• Construa o esquema de log de turno no primeiro dia, não na quarta semana. O endpoint de reprodução é a ferramenta mais valiosa que construí e a construí depois que precisei dela.
• Use detecção semântica de fim de turno desde o início em vez de lutar com limiares de silêncio.
• Mude para uma máquina de estados real no dia em que o prompt do sistema ultrapassar 300 palavras. Não tente codificar uma máquina de estados em prosa.
• Pare de validar em prompts. O LLM não é um analisador sintático. Python é um analisador sintático. Use Python.
• Armazene em cache os cinco documentos RAG mais prováveis no início da chamada. Pule a busca vetorial dentro do loop de turno.
• Construa o portão de conversa fiada antes de construir a recuperação. "Oi" é o ganho mais barato de 200ms no sistema.
• Execute o conjunto de avaliação antes da primeira chamada de produção. Mínimo de 50 conversas.
• Coloque uma fila de extração durável desde o primeiro dia. Uma tabela pending_extractions no Postgres com um único trabalhador de repetição leva 200 linhas e te salva de uma parada real.
• Execute um juiz LLM assíncrono a cada 50ª chamada. Pontue em fundamentação, relevância, brevidade. Envie para um dashboard. A deriva é real.
• Execute o loop de revisão semanal. Amostre 20 chamadas toda segunda-feira. Faça uma mudança. Teste A/B. Implemente o vencedor.

Conclusão

Agentes de voz parecem IA. Eles funcionam como sistemas em tempo real.

Equipes que lançam os tratam dessa forma. Equipes que lançam seis meses atrasadas pensam que um prompt melhor resolve um problema de sistema.

Assuma o controle do seu pipeline. Assuma o controle dos seus logs. Mantenha-os em arquivos simples, onde qualquer falha está a uma reprodução de distância.

O primeiro agente me levou um fim de semana. O sistema de produção levou dez semanas. E desde então, ele tem melhorado a cada dia, sem que eu precise mexer nele. O usuário não mede isso. Ele percebe que o agente respondeu "obrigado" sem fazê-lo esperar.

Avisos e Divulgações

Este artigo foi pesquisado e escrito pelo autor e editado por um modelo de IA. A miniatura foi tirada do Pinterest.

Este artigo foi pesquisado e escrito pelo autor enquanto trabalhava com agentes de voz em infraestrutura mais aprofundada.

Ele é baseado em anotações em constante evolução e pesquisa aprofundada usando Perplexity, Claude e ChatGPT, juntamente com design de sistemas e design de API de alguns livros universitários de nível de graduação.

Foi minuciosamente editado por Minimax M2.7 e Claude Opus 4.7 para corrigir erros gramaticais e de formatação.