RAG para agentes de voz em produção: acabe com as alucinações

## RAG para agentes de voz: acabe com as alucinações em chamadas ao vivo

Todo tutorial de "desenvolvimento de chatbot RAG" que existe na internet constrói a mesma coisa: uma caixa de texto, uma base de conhecimento e um bot que cola uma resposta com um pequeno selo de "fonte" logo abaixo. O popular guia no-code de bot de viagens da Voiceflow chega a descrever RAG como "treinar um funcionário novo". Ótimo para um widget de site, em que o usuário vê a citação e pode reler a resposta.

Uma ligação telefônica não tem nada disso. Não há selo de citação. Não há histórico para rolar. Quem liga ouve uma frase falada, em tempo real, e a trata como um compromisso que sua empresa acabou de assumir. Se o seu agente inventa um prazo de reembolso, erra um preço ou confirma um agendamento que não existe, você não tem uma nota de rodapé de "fontes" para se esconder atrás — você tem uma promessa gravada.

Este é o guia de RAG com foco em voz que as explicações genéricas pulam: retrieval que cabe em um orçamento de latência em tempo real, grounding para dados que você não pode mostrar, padrões de recusa e transferência, e como de fato avaliar respostas faladas em busca de alucinação.

## Por que alucinar é pior na voz

Três fatores tornam um fato alucinado mais perigoso numa ligação do que num chat:

1. **Nenhuma citação visível.** No texto, uma resposta errada ao lado de uma fonte linkada convida o usuário a clicar e se autocorrigir. Na voz, a confiança do modelo *é* a interface. Uma frase fluente e errada soa exatamente igual a uma frase fluente e correta.
2. **Tempo real, uma única chance.** O chat permite reler e raciocinar. Quem liga processa a fala linearmente e segue em frente. O erro é absorvido antes que alguém possa apontá-lo.
3. **Compromissos falados viram responsabilidade.** "Sim, você pode cancelar gratuitamente em até 48 horas" é, na prática, a sua política — gravada, com data e hora, e com toda a cara de ser exigível. Modelos de linguagem grandes são treinados para ser prestativos e fluentes, não para se conter. Esse padrão é um problema jurídico ao telefone.

O objetivo do RAG aqui não é "parecer inteligente". É: **dizer apenas o que for recuperável e recusar o resto em voz alta.**

## Arquitetura RAG para um agente de telefone: retrieval dentro do orçamento de latência

A restrição dura na voz é a latência por turno. Pessoas percebem o silêncio a partir de ~800 ms e começam a falar por cima do agente a partir de ~1,2 s. Todo o seu ciclo — ASR → retrieval → LLM → TTS — precisa caber em um **orçamento de aproximadamente 1 segundo** para soar natural.

Uma alocação aproximada para um turno falado:

| Etapa | Orçamento |
|---|---|
| Finalização do ASR (fim da fala) | ~150–300 ms |
| Retrieval (embedding da consulta + busca vetorial + reranking) | **~150–250 ms** |
| Primeiro token do LLM | ~300–500 ms |
| Primeiro áudio do TTS | ~150–300 ms |

O retrieval fica com ~200 ms. Isso elimina padrões ingênuos que os bots de texto usam à vontade:

- **Nada de retrieval multi-hop no meio do turno.** Uma passada de retrieval por turno. Faça a expansão de consulta offline ou em paralelo, nunca em sequência.
- **Pré-aqueça e faça cache dos embeddings.** Gere os embeddings da base de conhecimento com antecedência; ao vivo, só a consulta de quem liga é embedada.
- **Retrieval especulativo.** Dispare o retrieval sobre a transcrição *parcial* do ASR antes do fim da fala e depois confirme. Você recupera 100–200 ms.
- **Faça streaming do LLM para o TTS.** Comece a falar a primeira oração enquanto os tokens seguintes são gerados. Mas o grounding precisa estar resolvido *antes* do primeiro token — não dá para voltar atrás numa frase já falada.

## Fazendo o grounding da resposta — chunking, reranking e citar dados de conta

O grounding na voz lida com duas classes de dados que seguem regras diferentes.

**Conhecimento estático (políticas, preços, FAQ).** Faça chunks pequenos — 200 a 400 tokens — porque respostas faladas são curtas e um contexto inchado tenta o modelo a sintetizar entre chunks (uma fonte de alucinação). Sempre aplique **reranking** no top-k; um reranker cross-encoder sobre 20 candidatos → top 3 reduz de forma mensurável as respostas tiradas do chunk errado. Entregue 2 ou 3 chunks ao modelo, não 10.

**Dados dinâmicos de conta (status do pedido, saldo, agendamento).** Isso não vem de busca vetorial — é uma chamada de função ao vivo ao seu sistema de registro (via um webhook no estilo `make integration for ai agents`, ou uma API direta). Regra: **o modelo só pode falar valores de campos presentes na resposta da ferramenta.** Se `order.status` estiver ausente, o agente não pode inferir "provavelmente já foi enviado". Estruture o prompt para que os fatos da conta cheguem como JSON tipado e instrua o modelo a citar os campos literalmente.

Como você não pode mostrar uma fonte numa ligação, a "citação" vira **procedência dentro do prompt**: marque cada chunk recuperado com o id da fonte e faça o modelo se condicionar internamente a "responda apenas a partir de blocos CHUNK_ID". Você registra qual chunk gerou a resposta falada para auditoria — a citação é para *você*, não para quem ligou.

## Recusa e escalonamento: "vou te passar para um atendente" ganha de chutar

A jogada antialucinação de maior alavancagem na voz é um bom caminho de recusa. Se o retrieval não retorna nada acima do limiar de confiança, a saída correta não é o melhor palpite — é o escalonamento.

Projete três desfechos explícitos por turno, não dois:

- **Responder** — chunk(s) com grounding acima do limiar → fale o fato fundamentado.
- **Esclarecer** — consulta ambígua → faça uma pergunta curta e recupere de novo.
- **Transferir** — score de retrieval baixo, fora de escopo ou frustração detectada → "quero te dar a informação exata, vou te conectar com um especialista" + [transferência assistida](/glossary/warm-transfer) com contexto.

Amarre o limiar ao score do reranker, não só à similaridade vetorial. E torne a transferência barata: uma ligação que termina em uma transferência limpa é um *sucesso*, não uma falha. Chutar para evitar uma transferência é exatamente como você acaba com a responsabilidade gravada da primeira seção.

## Padrões de prompt que reduzem fatos inventados em ligações

Os `rag prompts` de voz são mais rígidos que os de chat porque não há fonte visível para amortecer uma resposta errada:

- **Proibição de responder de cabeça.** "Você não tem conhecimento além do bloco CONTEXT. Se a resposta não estiver no CONTEXT, diga que vai verificar ou transfira." Declare isso e repita perto do fim do [system prompt](/glossary/system-prompt) (a recência ajuda).
- **Regra de literalidade para dados de conta.** "Cite números, datas e status exatamente como aparecem no resultado da ferramenta. Nunca estime nem arredonde."
- **Sem síntese entre chunks para políticas.** "Responda a partir de um único chunk, o mais relevante. Não combine duas políticas para criar uma nova."
- **Limite de tamanho falado.** "Responda em uma ou duas frases que uma pessoa consiga acompanhar de ouvido." Respostas longas derivam e inventam.
- **Verbo de incerteza explícito.** Dê ao modelo uma saída autorizada — "deixa eu confirmar isso para você" — para que a recusa seja um caminho de tokens disponível, e não um estado de falha.

## Avaliando a saída de um RAG falado

Não dá para colocar RAG de voz em produção no feeling. Monte um harness de avaliação offline sobre as transcrições:

- **Fidelidade (faithfulness)** — toda afirmação da resposta é sustentada pelo contexto recuperado? Pontue com um LLM juiz sobre pares (contexto, resposta). Meta >0,95.
- **Groundedness / relevância da resposta** — a resposta usou o chunk recuperado ou ignorou e saiu improvisando?
- **Taxa de alucinação** — % de respostas que contêm uma afirmação ausente do contexto. Essa é a sua métrica-guia; acompanhe por release como um error budget.
- **Precisão/recall da recusa** — ele transferiu quando devia e *não* transferiu quando tinha a resposta? Recusa em excesso destrói a experiência do cliente; recusa de menos é o risco jurídico.
- **Hit@k do retrieval** — antes de culpar o LLM, confirme se o chunk certo chegou a ser recuperado. A maioria das "alucinações" é falha de retrieval.

Rode isso sobre um golden set de transcrições reais a cada deploy. Adicione cada alucinação de produção ao conjunto como teste de regressão.

## Construir ou comprar: o que a Finn resolve versus fazer por conta própria

Montar o seu próprio stack de RAG de voz significa assumir: infraestrutura de retrieval abaixo de um segundo, reranking, streaming de ASR/TTS, [barge-in](/glossary/barge-in), a máquina de estados de recusa/transferência, a transferência assistida e um harness de avaliação de transcrições — e depois manter tudo isso dentro do orçamento de latência em toda ligação. Isso são meses de `ai agent development`, não um tutorial de fim de semana.

A Finn entrega a camada de grounding de voz pronta: retrieval ajustado ao orçamento do turno, function calling em dados de conta com grounding literal por campo, recusa e transferência assistida embutidas, e transcrições por ligação que você pode jogar direto na avaliação. Você traz a base de conhecimento e o sistema de registro; a Finn mantém as respostas faladas factuais.

## Links internos
- `/blog/ai-voice-agent-vs-ivr-enterprise-guide` — onde a URA determinística termina e a IA de voz fundamentada começa
- `/blog/how-to-manage-high-call-volumes-without-hiring-more-agents-2026` — a economia da deflexão que faz o grounding valer a pena
- `/blog/ai-voice-agent-pricing-comparison-2026` — custo por minuto do stack de retrieval + LLM + TTS
- `/blog/blog-draft-your-help-desk-ends-at-the-ticket-where-voice-ai-closes-the-loop-2026-a9e2754c` — fechando o ciclo depois da ligação

## FAQ
_Emit as FAQ JSON-LD (schema.org/FAQPage)._

**P: O que é RAG em um agente de voz?**
R: A [geração aumentada por recuperação](/glossary/retrieval-augmented-generation) fundamenta a resposta falada do agente nas suas próprias políticas, preços e dados de conta recuperados no momento da ligação — assim ele fala fatos da sua base de conhecimento em vez de palpites do modelo.

**P: Como evitar alucinações do LLM em uma ligação telefônica?**
R: Recupere e faça reranking antes de responder, oriente o modelo a falar apenas a partir do contexto recuperado, cite os campos da conta literalmente e transfira para um humano quando a confiança do retrieval estiver baixa.

**P: Quanta latência o RAG adiciona a um turno de voz?**
R: Reserve ~150–250 ms para o retrieval dentro de um turno total de cerca de 1 segundo. Pré-aqueça os embeddings, rode uma única passada de retrieval, faça reranking de um conjunto pequeno de candidatos e comece o retrieval no ASR parcial para não estourar o orçamento.

**P: Como medir alucinação em respostas faladas?**
R: Pontue as transcrições em fidelidade e groundedness com um LLM juiz, acompanhe a taxa de alucinação como um error budget e meça precisão/recall da recusa mais o hit@k do retrieval em um golden set a cada release.

Quer respostas de voz factuais sem construir você mesmo o stack de retrieval, recusa e avaliação? **Veja como a Finn fundamenta cada ligação — agende uma demo em hirefinn.ai.**