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

aqui está a verdade que ninguém conta para quem constrói IA: agentes de voz não precisam

do melhor modelo. tudo que eles precisam é

TLDR; se você acha leitura chata ou sua capacidade de atenção já era, você pode usar o skill file que eu fiz para pegar o artigo inteiro e colar no seu agente ➡️https://github.com/codejunkie99/voice-agent-builder

tudo que você precisa construir é:

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

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 saiu do 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 funcionou, o sistema era a quarta reescrita.

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

• O pipeline tem um trabalho dentro de um orçamento. Cinco componentes, menos 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.
• Design de conversação é a disciplina de escrever para ouvidos, não para olhos. A maioria dos times trata isso como cosmético. Não é.
• A cada turno, um log estruturado é escrito que eu 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 de novo hoje.🔽🔽

O que realmente é um agente de voz

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

É um sistema de áudio em tempo real. Restrito por 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 conhecimento relevante dos seus documentos
5. O LLM gera uma resposta
6. O TTS lê 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 do jeito de chatbot primeiro. O STT completa, envia para o LLM, espera a resposta completa, envia para o TTS, espera o áudio completo, toca.

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

O motivo de parecer horrível não é que os números de latência fossem ruins. Eles estavam 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 do LLM terminar de escrever.
• O STT tem que continuar ouvindo enquanto o agente fala, 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 com base no que você precisa controlar.

Pipeline encadeado

• Serviços separados de STT, LLM e TTS conectados
• Três modelos independentes, cada um especializado em sua função
• Texto flui entre eles
• 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 por vez

Semi-cascata

• Á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 troca de idioma no meio da frase
• A saída ainda passa por um TTS especializado para controle de áudio
• Latência cai para 300 a 500ms

Fala para fala nativo

• Um modelo, áudio entra, áudio sai
• Sem camada de transcrição, sem passagem de texto
• Todo grande laboratório lançou um modelo de voz nativo em 2026
• Latência cai para 200 a 300ms, abaixo do limite em que os chamadores param de perceber 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 provar seu produto no pipeline e quiser uma melhoria de latência em degrau.
2. Tentei fala para fala primeiro para tudo. Foi excelente para fluxos de agendamento.
3. Falhou 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. Escopo de 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 que seu agente atenda sua primeira chamada.

Os ouvidos (STT em streaming)

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

O que procurar em 2026:

• Precisão em streaming. Precisa ser precisa enquanto a pessoa fala, 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 integrada. A maior melhoria de UX de 2026.

Por que a detecção de fim de turno importa:

• 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. Captura quando a pessoa vai parando de falar 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. Também decide ações, não apenas palavras.

Regras específicas para voz:

• Use o modelo pequeno e rápido, não o carro-chefe. Modelos de raciocínio de fronteira levam 1500ms para gerar a primeira palavra. Isso é ar morto. Modelos menores da mesma família quase sempre ganham em turnos de voz.
• Escalone para o modelo grande apenas para chamadas de ferramenta complexas 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ê espera:

• O LLM não lança um erro quando não consegue chamar uma função. Ele narra a ação.
• "Eu confirmei seu agendamento." Nada foi chamado. O usuário pensa que está agendado. 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 estado é a barra 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 documentos mais relevantes.
• Trechos são injetados no contexto do LLM.
• Instrui-se o LLM a responder apenas a partir desse contexto.

O desafio específico para 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 diferenciador 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 a fala sintética. Artefatos sutis, ritmo não natural, ênfase deslocada — tudo isso é lido como um veredito sobre todo o sistema.
• Escolha a voz intencionalmente. É um sinal de confiança antes de o usuário ouvir uma frase.

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

Funções são ações que o LLM pode realizar durante a conversa:

• Agendar 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 aperte-1-para-faturamento.

O orçamento de latência em que você precisa caber

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 fica esperando.

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 dificuldade
• 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 cada componente.

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

• Transporte. 20-50ms ponto a ponto. 50-100ms via relays.
• Primeiro resultado do STT. 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.
• Tempo até o primeiro token do LLM. 150-250ms com modelo pequeno. 400-600ms com modelo de fronteira.
• Tempo até o primeiro áudio do TTS. 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 pista rápida. ~700-900ms na pista 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 atualização individual que você pode fazer este ano.
2. Pré-busca especulativa com cache de agente duplo. Leva a recuperação de "miss com busca vetorial" para "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 a 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 documentos relevantes para cada previsão
• Armazena-os em um cache local na memória antes que o usuário termine de ouvir a resposta atual

O agente de frente (Falante Rápido)

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

Números de benchmark do artigo

• 75% das consultas acertam o cache
• Aceleração de 316× 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 que o usuário está ouvindo como seu tempo de computação. O momento em que ele começa a ouvir a resposta atual é o momento em que você começa a se preparar para a próxima pergunta.

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 acertam o cache parecem mais rápidos do que os representantes humanos do call center que o agente substitui.

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

Você pode ter o STT mais rápido, o LLM menor, o cache RAG mais inteligente. Se seu agente não souber falar, 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. A duração média da atenção humana para informação falada é de 8 a 10 segundos. Uma resposta de 15 segundos é longa demais. 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 cobrança", o agente diz "problema de cobrança" de volta. Não "disputa financeira" ou "questão 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". TTS rotineiramente pronuncia números formatados de forma errada.
• Limite o prompt do sistema a 800 tokens. Ele recarrega a cada turno.

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

1. Reconhecimento e orientação. "Então você quer reagendar seu compromisso de quinta-feira, deixa eu puxar isso aqui." Confirma que o chamador foi entendido. Ganha tempo enquanto a recuperação roda.
2. Resolução. A ação ou resposta principal. Um ponto por turno. Avance.
3. Confirmação e encerramento. "Eu reagendei 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 momento de "ler antes de enviar". Uma saída insegura é falada imediatamente. Sem rascunho, sem pré-visualização, sem humano no loop.

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

O guardião de entrada (antes de o 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 falada em voz alta. Números de cartão de crédito, números de seguro social. Redija antes que atinjam qualquer log ou banco de dados.
• Lista de bloqueio de tópicos. Carregada de um arquivo JSON. Atualizada semanalmente conforme você aprende o que os usuários realmente tentam.

O guardião de saída (depois de o LLM escrever sua resposta, antes de o TTS falá-la)

• 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)
• categoria detectada (string, se inseguro)
• frase de substituição que o agente fala

Cada gatilho registra em um arquivo com timestamp, categoria, texto redigido 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 conectar você com alguém que possa ajudar."
• Não cinco variações. Não é o palpite improvisado do LLM sobre a frase correta.
• Uma frase. EM MAIÚSCULAS no prompt do sistema. Fallback quando qualquer verificação de segurança dispara.

Eu lancei sem um guardião de saída na primeira versão. O agente citou 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 correto não estava no contexto recuperado.

Avaliação, ou como saber se está 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. Encanação.

• 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 faz o que foi pedido.

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

Camada 3: Comportamento do usuário. Parece natural falar com ele?

• Taxa de recuperação de interrupção
• Taxa de re-prompt
• Duração média do turno
• Contagem 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 (porcentagem de chamadas resolvidas sem humano)
• Taxa de transferência
• CSAT
• Taxa de resolução na primeira chamada
• Otimize para contenção. Correlaciona-se com todo o resto e é o 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% adversarial (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 escalonadas, 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. Implante 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 subestima isso.

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 com 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 maiúsculas: RESPONDA APENAS A PARTIR DO CONTEXTO FORNECIDO
• O modelo ainda vai tender ao conhecimento geral às vezes, mas a instrução explícita reduz a taxa em uma ordem de magnitude

1. Recusa graciosa

• 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 graciosa
• "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 ciente de confiança

• A pontuação máxima do BM25 nos trechos recuperados é um proxy útil para confiança
• Pontuação acima de 0,6: agente responde com confiança
• Pontuação de 0,3 a 0,6: agente responde mas adiciona uma hesitação "acho que"
• Pontuação 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
• Eu faço uma auditoria às sextas-feiras: leio os 5% inferiores das respostas com pontuação de confiança da semana
• Metade das vezes a resposta estava correta, mas a recuperação encontrou um trecho desatualizado
• Atualize o trecho, reincorpore, na próxima semana fica mais tranquilo

O que observar

Seis modos de falha que vão te atingir.

VAD no pipeline em vez do transporte

• Problema. Agente dispara com sua própria saída de 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. LLM chama book_appointment em um estado que ainda está coletando o nome do paciente. Ou inventa um agendamento que nunca aconteceu.
• Solução. Escopo de ferramentas por estado. Um estado, apenas suas próprias funções. A máquina de estado é a barra 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. 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. LLM aceita "joao@" como um e-mail real na chamada 12. Rejeita um válido com sinal de mais na chamada 47.
• Solução. Validação vive em Python. Regex para e-mail, parser de data para datas, verificação de comprimento de nome, uma resposta de "repergunte" quando a validação falha.

Contexto cresce sem limites em uma chamada longa

• Problema. Latência p95 aumenta ao longo da semana sem mudanças no código. No turno 20 você está enviando 12K tokens por turno.
• Solução. Janela deslizante dos últimos N turnos mais prompt do sistema. Ou redefinições de contexto baseadas em marcos no final de cada etapa discreta.

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 mesmo assim.
• Solução. Expansão do alfabeto fonético da OTAN com tags SSML de pausa. Soa mais lento. Lê corretamente na primeira vez.

Coisas que eu faria diferente

• Construir o esquema de log de turnos no dia um, não na semana quatro. O endpoint de reprodução é a ferramenta mais valiosa que construí e a construí depois que precisei dela.
• Usar detecção semântica de fim de turno desde o início em vez de lutar com limiares de silêncio.
• Migrar para uma máquina de estado real no dia em que o prompt do sistema ultrapassar 300 palavras. Não tente codificar uma máquina de estado em prosa.
• Parar de validar em prompts. O LLM não é um parser. Python é um parser. Use Python.
• Armazenar em cache os cinco documentos RAG mais prováveis no início da chamada. Pular a busca vetorial dentro do loop de turnos.
• Construir o portão de conversa fiada antes de construir a recuperação. "Oi" é a vitória de 200ms mais barata do sistema.
• Executar o conjunto de avaliação antes da primeira chamada de produção. Mínimo de 50 conversas.
• Colocar uma fila de extração durável desde o dia um. Uma tabela pending_extractions no Postgres com um único worker de repetição leva 200 linhas e economiza uma parada real.
• Executar um juiz LLM assíncrono a cada 50ª chamada. Pontuar em fundamentação, relevância, brevidade. Canalizar para um dashboard. O desvio é real.
• Executar o loop de revisão semanal. Amostrar 20 chamadas toda segunda-feira. Fazer uma mudança. Teste A/B. Implantar o vencedor.

Conclusão

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

Equipes que lançam os tratam assim. Equipes que lançam seis meses atrasadas pensam que um prompt melhor corrige 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 custou um fim de semana. O sistema de produção levou dez semanas. Desde então, ele vem melhorando a cada dia, sem que eu precise mexer nele. O usuário não mede isso. Ele só 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 retirada do Pinterest.

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

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

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