Como evitar alucinações em agentes de IA de atendimento

Alucinação, em modelos de linguagem, é uma resposta plausível e fluente que não corresponde aos fatos. Em atendimento, é o agente que inventa um horário, confirma uma condição que não existe ou descreve um serviço que a empresa não oferece. O problema é grave porque a resposta parece certa: o cliente acredita, age com base nela e a empresa descobre depois.

Não existe um botão que elimine alucinações. Existe um conjunto de medidas que, combinadas, reduzem o problema a um nível operacionalmente aceitável. Este artigo descreve as causas mais comuns em atendimento e as medidas que funcionam.

Por que agentes de atendimento alucinam

1. Falta de informação. O modelo recebe uma pergunta cuja resposta não está no contexto e preenche a lacuna com o que parece provável.
2. Informação contraditória. A base de conhecimento tem duas versões de um fato, e o modelo escolhe uma, ou mistura as duas.
3. Instruções sem limites. Sem uma orientação clara de "se não souber, diga que não sabe", o modelo tende a responder sempre.
4. Pergunta ambígua. O cliente escreve pouco, a recuperação traz o trecho errado, e a resposta é construída sobre ele.
5. Pressão por fluência. Modelos são otimizados para respostas bem escritas. Uma resposta bem escrita e errada é o resultado natural quando faltam fatos.

Medidas que reduzem alucinações

1. Base de conhecimento como fonte primária

Fazer o agente responder a partir de trechos recuperados da base (RAG) em vez da memória do modelo é a medida com maior efeito. Com fatos concretos no contexto, o modelo tem menos espaço para inventar. Veja como funciona RAG em agentes de IA.

2. Instrução explícita para não responder sem informação

As instruções do agente devem dizer, de forma direta, que ele só responde com base no conhecimento fornecido e que, na ausência de informação, deve dizer que não sabe e oferecer a transferência. Essa instrução isolada resolve uma parte grande dos casos.

3. Limites de escopo

Assuntos em que um erro custa caro (valores, prazos contratuais, saúde, jurídico) podem ser retirados do escopo do agente e enviados sempre para uma pessoa. O agente não alucina sobre o que não tenta responder.

4. Base limpa, sem contradições

Uma base pequena e consistente produz menos erros do que uma base grande com versões conflitantes. Revise o que entra e retire o que está desatualizado. O guia como construir uma base de conhecimento descreve o processo.

5. Testes com casos salvos

Monte um conjunto de perguntas com a resposta esperada, incluindo perguntas cuja resposta correta é "não sei" ou "vou transferir". Rode o agente contra esse conjunto antes de publicar e depois de cada mudança. Na Cavori, isso é feito no simulador, com as conversas avaliadas resposta por resposta e salvas como casos de teste.

6. Transferência para humano como rede de segurança

Quando o cliente pede uma pessoa, quando o assunto sai do escopo ou quando a base não tem a resposta, a conversa deve ir para a equipe. A transferência com o histórico completo evita que uma resposta incerta vire uma resposta errada. Veja transferência para humano.

7. Acompanhamento depois de publicar

Observar as conversas reais revela alucinações que os testes não pegaram e assuntos que faltam na base. O portal da Cavori mostra os assuntos que o agente ainda precisa aprender; cada um é uma lacuna a fechar antes que vire uma resposta inventada.

O que não resolve

• Fine-tuning para ensinar fatos. Fatos ajustados nos pesos do modelo continuam sujeitos a erro e ficam impossíveis de corrigir pontualmente. Veja RAG vs fine-tuning.
• Pedir ao modelo para "não alucinar". A instrução útil é específica: responder só com base no conhecimento fornecido e transferir na ausência de informação.
• Publicar e esperar reclamações. Os erros mais caros são os que o cliente não reporta.

Um checklist antes de publicar

1. A base de conhecimento cobre as perguntas mais frequentes e não tem contradições.
2. As instruções dizem para responder só com base no conhecimento e transferir quando não souber.
3. Assuntos de alto risco estão fora do escopo do agente.
4. Existe um conjunto de casos de teste, incluindo perguntas sem resposta na base.
5. A equipe sabe quem assume as transferências.
6. Há uma rotina para revisar os assuntos sem resposta depois da publicação.

Na Cavori, esses pontos correspondem a etapas do produto: base por empresa, limites montados com a Vori, simulador com casos salvos, transferência com histórico completo e portal com os assuntos a aprender. A página segurança descreve como separação de dados e controle humano se encaixam nesse desenho.