Alucinação de IA de voz é, disparado, o maior motivo pelo qual agentes de voz corporativos travam no piloto e nunca chegam à produção. Não é latência. Não é sotaque. Não é SIP. Um chatbot de texto que inventa uma política de reembolso é um incômodo que a pessoa pode reler e descartar. Um agente de voz que diz, em tom caloroso, confiante e humano, "Yes, your appointment is confirmed for Tuesday at 3pm" — quando esse horário não existe — é um passivo que seu time de operações descobre quando o cliente aparece num escritório vazio.
Este é o manual de engenharia para colocar no ar um agente de voz factual: grounding rígido para que o modelo só fale a partir da verdade recuperada, saída estruturada forçada nos turnos transacionais, um andaime de recusa para que "não sei" seja um desfecho de primeira classe, RAG de baixa latência que cabe no orçamento de um turno de voz e um harness de eval de IA de voz que comprove o grounding antes de você apontar números de telefone reais para ele.
Por que a modalidade de voz amplifica o risco de alucinação
A mesma alucinação de LLM que é tolerável no chat vira perigo no telefone por três razões estruturais.
Não há histórico para revisar. No chat, as pessoas leem em diagonal, releem e pegam o modelo se contradizendo duas mensagens acima. A voz é efêmera — uma vez dita, a afirmação some, e o único registro está na memória do cliente (geralmente errada) ou numa transcrição que ninguém lê até surgir uma disputa. Não há pista visual de que o agente está inseguro.
A própria voz é um sinal de confiança. Prosódia, ritmo e uma voz de TTS natural são registrados pelo cérebro humano como competência. Em CX, quem liga avalia consistentemente como mais precisos os agentes que soam seguros, independentemente de terem acertado. Sua camada de TTS é, na prática, um amplificador de confiança parafusado a um modelo que não faz ideia de quando está errado.
A pressão do turno empurra o modelo a se comprometer. Um agente de voz não pode ficar 4 segundos em silêncio enquanto "pensa" — o vazio quebra a conversa. Então a decodificação acontece sob pressão de latência, o modelo preenche a lacuna, e preencher a lacuna é exatamente quando LLMs confabulam. O mesmo orçamento de tempo que faz a voz parecer humana (veja nosso trabalho sobre arquitetura de voz abaixo de 300 ms) é o orçamento que tenta o modelo a chutar.
Juntando tudo: a voz pega o pior modo de falha de um LLM e remove todas as travas que a pessoa tinha antes. É por isso que precisão de agente de voz com IA é um problema de arquitetura, não de ajuste de prompt.
Os quatro modos de falha que você realmente precisa conter
Conselho genérico do tipo "reduza alucinações" é inútil, porque as quatro formas pelas quais um agente de voz mente têm raios de dano e soluções diferentes.
- Política inventada. "You can return that any time within 90 days." O prazo real é 30 dias. O modelo interpolou um número plausível. Solução: responder apenas a partir de recuperação — veja a próxima seção.
- Preço inventado. *"That plan is
49 a month."* São US59. Números são os tokens de maior risco que um LLM emite: baratos de gerar e caros quando saem errados. Solução: forçar saída estruturada — nunca deixe preços passarem por geração de texto livre. - Confirmação falsa. "You're all set, confirmation number A-4471." Nenhuma reserva foi gravada. O modelo narrou uma chamada de ferramenta bem-sucedida que nunca aconteceu (ou alucinou o ID antes de a ferramenta responder). Solução: grounding no resultado da ferramenta — o agente só pode confirmar o que a API de fato retornou.
- Escalonamento falso / promessa falsa. "I'm transferring you to a specialist who'll call back within the hour." Essa fila não existe. Solução: andaime de recusa mais uma allowlist das ações que o agente está realmente conectado para executar.
Amarre cada guardrail que você construir a um desses quatro. Se um controle não reduz nenhum deles, é teatro.
Grounding rígido: respostas só por recuperação e saída estruturada forçada
O princípio central: o trabalho do modelo é redigir fatos recuperados, não lembrá-los. A memória paramétrica — o que o LLM "sabe" do pré-treinamento — fica proibida para responder perguntas de negócio.
Para turnos informativos (política, horários, preços, elegibilidade), use um padrão de recuperação para IA de voz em que o system prompt proíba afirmações sem fonte:
You answer ONLY using the <context> block. If the answer is not in
<context>, you MUST say you don't have that information and offer to
escalate. Never use prior knowledge. Never estimate, infer, or round.
Every factual claim must be traceable to a context snippet.
Esse prompt sozinho é necessário, mas não suficiente — prompts vazam. Para turnos transacionais (qualquer coisa que envolva preço, data, quantidade, ID ou um compromisso de sim/não), pare de gerar texto livre por completo e force saída estruturada. Faça o modelo emitir um objeto tipado que sua aplicação valida e converte em fala de forma determinística:
{
"name": "quote_plan",
"schema": {
"type": "object",
"properties": {
"plan_id": { "type": "string", "enum": ["basic", "pro", "enterprise"] },
"price_cents":{ "type": "integer" },
"source_doc_id": { "type": "string" }
},
"required": ["plan_id", "price_cents", "source_doc_id"],
"additionalProperties": false
}
}
Depois é o seu código — não o modelo — que busca price_cents na tabela de preços indexada por plan_id, e se recusa a falar se source_doc_id não for um documento real. O modelo escolhe qual plano; o sistema é dono do número. Um preço inventado se torna estruturalmente impossível, porque o modelo nunca é a fonte dos dígitos.
A mesma disciplina mata as confirmações falsas. O agente não pode dizer "está confirmado" a partir de uma string gerada. Ele emite uma chamada de ferramenta book_appointment, espera a resposta real da API, e uma linha de confirmação em template é preenchida com o objeto de reserva retornado. Sem resultado de ferramenta, sem confirmação — ponto final. Essa é a extensão natural da abordagem de máquina de estados que descrevemos ao construir agentes de IA determinísticos: turnos transacionais são estados com transições tipadas, não papo aberto.
Andaime de recusa: transformar "não sei" num desfecho elegante e projetado
A maioria das alucinações é o modelo se recusando a recusar. Ele prefere inventar a admitir uma lacuna, porque nada na conversa recompensa admitir. Você precisa projetar a saída de emergência.
Uma boa recusa faz três coisas: não finge, mantém a simpatia e encaminha quem ligou para algum lugar útil. Monte isso explicitamente:
# Refusal policy
If <context> does not contain the answer, do NOT guess. Respond with:
1. A brief, friendly acknowledgement ("That's a good question—")
2. An honest gap statement ("—I don't want to give you the wrong
number on that.")
3. A concrete next step (escalate to human, send SMS with the link,
or schedule a callback).
Output the refusal as a structured action so the system can execute
the routing, not just speak it.
Combine o prompt com uma ação de recusa estruturada, para que o sistema decida o roteamento e o modelo não consiga prometer uma transferência inexistente:
{
"action": "refuse_and_route",
"reason": "no_grounding",
"route": "human_handoff", // must be in the configured allowlist
"spoken": "I don't want to give you a wrong answer on that, so let me get you to a specialist."
}
route é validado contra os canais que você de fato conectou. Se human_handoff não estiver configurado para essa linha, o sistema rebaixa para a próxima rota disponível (retorno de ligação, SMS) em vez de deixar o agente narrar uma ficção. É assim que você elimina o modo de falha nº 4. Bem feita, uma recusa elegante aumenta o CSAT — quem liga confia mais em um agente que conhece seus limites do que em um que erra com confiança metade das vezes.
RAG de baixa latência para voz: fazer o grounding caber no orçamento do turno
Grounding não vale nada se estourar o orçamento de latência e o agente ficar mudo. A voz te dá um teto de round-trip de aproximadamente 800 ms–1,2 s antes de a conversa parecer quebrada, e o RAG tem que viver dentro disso, não em cima. Mire em menos de 200 ms de p90 na recuperação, para que o grosso do orçamento fique com ASR, LLM e TTS.
Três coisas deixam o RAG de voz rápido o bastante:
- Busca híbrida, não vetorial pura. Combine BM25/palavra-chave com embeddings densos e funda os rankings (reciprocal rank fusion). Quem liga fala SKUs, nomes de plano e apelidos de políticas — tokens lexicais exatos que a recuperação só densa erra. A híbrida os recupera. Mantenha o modelo de embeddings pequeno e quantizado; você não precisa de um reranker de 7B no caminho quente.
- Faça chunks para o ouvido, não para o olho. RAG web faz chunks de 500 a 1000 tokens. Para voz, faça chunks do tamanho de uma resposta falada — 1 a 3 frases, autocontidas, sem "como mostrado na tabela acima". Um chunk deve ser algo que o TTS consiga ler em voz alta na íntegra e que faça sentido. Guarde um campo
answercurto e falável junto ao texto de origem. - Pré-aqueça e faça cache. Faça cache dos embeddings das principais intenções, mantenha o índice em memória e coloque o serviço de recuperação junto ao orquestrador para evitar um salto entre regiões. A mesma engenharia de latência que aplicamos a SIP e a pipelines de mídia vale aqui: cada fronteira de rede é um imposto que você paga em todo turno.
Uma divisão prática de p90 dentro de um orçamento de 1 s: finalização do ASR ~150 ms, recuperação ~180 ms, primeiro token do LLM ~250 ms, primeiro áudio do TTS ~200 ms — com streaming, para que quem ligou ouça fala antes de a resposta inteira ser decodificada.
O harness de eval de voz: comprovar o grounding antes de ir ao ar
Você não entrega precisão de agente de voz com IA no feeling. É preciso um harness offline que pontue o agente sobre transcrições reais separadas do treino e que trave os deploys. Quatro métricas importam:
- Factualidade — cada afirmação é verdadeira em relação à fonte de referência?
- Grounding — cada afirmação é sustentada pelo contexto recuperado que o agente realmente tinha? (Uma afirmação pode ser verdadeira sem estar fundamentada — isso é sorte, não sistema.)
- Correção da recusa — quando a resposta não era recuperável, o agente recusou em vez de inventar? E, no sentido inverso, ele deixou de recusar em excesso perguntas respondíveis?
- Integridade transacional — toda confirmação falada correspondeu a um resultado real de ferramenta?
Monte o harness a partir de transcrições de produção anonimizadas (ou roteiros de red team) rotuladas com a resposta de referência e com a informação de se ela era respondível. Pontue cada turno com uma checagem determinística quando possível e com um LLM como juiz quando não:
def score_turn(turn, ground_truth):
claims = extract_claims(turn.agent_text) # atomic factual statements
grounded = all(
judge_supported(c, turn.retrieved_context) # LLM-judge: entailment
for c in claims
)
factual = all(judge_matches(c, ground_truth) for c in claims)
if not ground_truth.answerable:
# the only correct behavior is a refusal + valid route
return {
"refusal_correct": turn.action == "refuse_and_route"
and turn.route in ALLOWED_ROUTES,
"hallucinated": len(claims) > 0, # any claim here is a hallucination
}
return {
"grounded": grounded,
"factual": factual,
"over_refused": turn.action == "refuse_and_route",
}
Agregue numa taxa de grounding e numa taxa de alucinação, defina um gate de release (por exemplo, taxa de alucinação < 0,5% no conjunto separado, correção da recusa > 98%) e reprove o deploy se uma mudança de prompt ou de modelo regredir esse número. Rode a suíte a cada troca de modelo — um modelo base "melhor" pode trocar grounding por fluência sem avisar. Isso é teste de regressão para a verdade, e é o artefato que transforma "achamos que está preciso" num número que dá para mostrar a um cliente.
Guardrails em produção: limiares de confiança e humano no circuito
Evals offline pegam formatos conhecidos de falha. A produção precisa de redes de segurança ao vivo para os desconhecidos.
- Limiares de confiança na recuperação. Se a pontuação fundida do melhor chunk recuperado ficar abaixo de um piso, trate como "sem grounding" e roteie para a recusa — não responda a partir de uma correspondência fraca. Uma recuperação fraca é uma alucinação esperando para ser falada.
- Humano no circuito nas intenções de alto risco. Marque as intenções por raio de dano. Horários e endereço da loja: autonomia total. Cancelamentos, reembolsos acima de um limite, perguntas médicas ou jurídicas, qualquer coisa que movimente dinheiro ou assuma um compromisso: exija um caminho validado por ferramenta, uma releitura de confirmação ("Just to confirm, you want to cancel order 4471 — yes or no?") ou uma transferência assistida. A autoridade do agente deve escalar de forma inversa ao custo de errar.
- Registre cada afirmação com sua fonte. Toda afirmação factual falada deve carregar no log da chamada o
source_doc_idde onde veio. Quando surgir uma disputa, você responde "o que o agente disse e por quê" em segundos, em vez de adivinhar. Isso também alimenta seu conjunto de eval — disputas de produção são os casos separados de maior valor que você vai conseguir.
Empilhe tudo isso e os quatro modos de falha não têm onde se esconder: política inventada e preço inventado são bloqueados pelo grounding e pela saída estruturada, confirmações falsas pela vinculação ao resultado da ferramenta, escalonamentos falsos pela allowlist de rotas — e qualquer coisa nova dispara um limiar de confiança que leva a uma recusa elegante.
Como a Finn resolve isso de fábrica
Os agentes de voz da Finn já vêm fundamentados por padrão: resposta só por recuperação, saída estruturada forçada em todo turno transacional, uma camada de recusa-e-roteamento ligada aos seus canais reais de escalonamento e recuperação híbrida abaixo de 200 ms dentro do orçamento do turno de voz. O harness de eval acompanha a plataforma — aponte para suas transcrições e obtenha um número de grounding e de alucinação antes de uma única chamada ao vivo. Quer ver sua taxa de alucinação nos seus próprios dados de chamadas? Agende uma demo técnica da Finn.
Perguntas frequentes
Só engenharia de prompt consegue conter a alucinação de IA de voz? Não. Um prompt de grounding é necessário, mas vaza sob carga. Você precisa de saída estruturada forçada nos turnos transacionais, vinculação ao resultado da ferramenta nas confirmações e um gate de eval. Prompts reduzem a taxa; a arquitetura elimina o modo de falha.
Qual a diferença entre factualidade e grounding? Factualidade pergunta "a afirmação é verdadeira?". Grounding pergunta "a afirmação é sustentada pelo contexto que o agente de fato recuperou?". Uma afirmação pode ser verdadeira por sorte e ainda assim não fundamentada — isso significa que seu sistema chegou à resposta certa pelo motivo errado e uma hora vai chegar à errada. Acompanhe as duas; use o grounding como gate.
Quão rápido o RAG precisa ser para voz? Mire em menos de 200 ms de p90 na recuperação, para caber num round-trip conversacional de ~800 ms–1,2 s sem causar silêncio. Use busca híbrida (palavra-chave + vetor), embeddings pequenos e quantizados, índice em memória e coloque a recuperação junto ao orquestrador.
Como sei que meu agente de voz não vai alucinar antes de ir ao ar? Rode um harness de eval offline sobre transcrições rotuladas e separadas, pontuando factualidade, grounding, correção da recusa e integridade transacional. Defina um gate de release (por exemplo, taxa de alucinação abaixo de 0,5%) e rode de novo a cada mudança de prompt ou de modelo.
