Mitigue as alucinações do LLM passo a passo

Por que uma alucinação não se «conserta» com um prompt

Antes de mexer na configuração, convém aceitar uma realidade incômoda: as alucinações não são um bug que se elimina com uma instrução mais firme. São um comportamento emergente do funcionamento probabilístico do modelo. Um LLM gera o token mais provável dada uma sequência, não consulta uma base de fatos. Quando o contexto não contém a resposta, o modelo não para: completa com o que estatisticamente se encaixa. Isso significa que qualquer configuração que prometa «zero alucinações» está te vendendo fumaça.

O que você pode fazer é reduzir a superfície onde elas aparecem, detectá-las antes que cheguem ao usuário e degradar o sistema de forma controlada quando a confiança cai. Este artigo é uma sequência de configuração real, com parâmetros concretos, limiares e verificações, para equipes que já têm um LLM em produção ou estão prestes a colocá-lo.

Passo 1: separe os tipos de alucinação antes de configurar qualquer coisa

Nem todas as alucinações são mitigadas da mesma forma. Configurar sem classificar leva a remendar o lugar errado. Distinga pelo menos estas quatro, porque cada uma exige uma camada diferente:

• Factual: o modelo afirma um dado falso (uma data, um número, uma lei). Combate-se com recuperação de contexto e verificação externa.
• De atribuição: inventa uma fonte, um autor ou uma citação. É a mais perigosa em conteúdo editorial porque parece verificável.
• De instrução: ignora uma restrição do sistema (responde em outro idioma, quebra o formato). Combate-se com validação de saída.
• De raciocínio: os passos intermediários são plausíveis, mas a conclusão não se segue. Combate-se com decomposição e verificação de cada passo.

Um caso que vejo repetidamente em equipes de conteúdo: configuram a temperatura em 0 pensando que isso acaba com as invenções de fontes. Reduz a variabilidade, sim, mas um modelo com temperatura 0 continua inventando referências se não tem o dado. A temperatura reduz a dispersão, não a ignorância.

Passo 2: fixe a temperatura e o sampling conforme a tarefa

A configuração do sampling é o primeiro dial real. Não existe um valor universal; existe um valor por tipo de tarefa. Guie-se por esta tabela:

Advertência de especialista: baixar o top_p para 0,5 corta a cauda de tokens improváveis, o que reduz invenções raras, mas também torna o texto mais plano e repetitivo. Em tarefas de extração estruturada, convém combiná-lo com constrained decoding (gramáticas ou esquemas JSON forçados), que é mais eficaz do que qualquer ajuste de temperatura para evitar campos inventados.

Passo 3: monte recuperação com limiar de rejeição

A alavanca mais potente contra a alucinação factual é não deixar o modelo responder de memória. Configure um pipeline RAG (retrieval-augmented generation) com estas decisões explícitas:

1. Fragmentação: fragmentos de 300 a 600 tokens com sobreposição de 10-15%. Fragmentos grandes demais diluem o sinal; pequenos demais perdem o contexto que evita interpretações errôneas.
2. Recuperação híbrida: combine busca semântica (embeddings) com busca léxica (BM25). A semântica falha com identificadores, códigos e nomes próprios; a léxica falha com paráfrases. Juntas cobrem mais.
3. Limiar de similaridade: defina uma pontuação mínima (por exemplo, 0,75 em similaridade de cosseno, ajustada após medir com seu próprio corpus) abaixo da qual o sistema não chama o modelo e retorna uma mensagem de «não tenho informação suficiente».
4. Prompt de contexto fechado: instrua o modelo a responder apenas com os fragmentos recuperados e a indicar explicitamente quando o contexto não cobre a pergunta. Essa instrução não é infalível, mas combinada com o limiar reduz drasticamente as respostas inventadas.

Aqui vai o erro prático que quase todos cometem na primeira vez: configurar o limiar de recuperação alto demais. O sistema começa a rejeitar perguntas legítimas e a equipe, frustrada, o baixa para zero. O limiar correto não se adivinha: calibra-se com um conjunto de 50 a 100 perguntas reais, medindo quantas vezes rejeita uma pergunta que tinha resposta versus quantas vezes responde sem contexto. Sem esse conjunto de calibração, qualquer limiar é um palpite.

Passo 4: instruções de sistema que funcionam (e as que não funcionam)

Frases do tipo «não invente nada» têm eficácia limitada. Funcionam melhor as instruções operativas e verificáveis:

• Em vez de «seja preciso», use «cite o fragmento de contexto do qual sai cada afirmação; se não houver fragmento, responda ‘não consta'».
• Em vez de «não alucine», use «se a pergunta exigir dados posteriores ao seu conhecimento ou não presentes no contexto, diga isso antes de responder».
• Adicione um formato de saída com campos obrigatórios: resposta, fontes (lista de fragmentos usados), confiança (alta/média/baixa). O campo de fontes força o modelo a se comprometer e facilita a verificação automática.

O que não funciona: empilhar dez restrições negativas no prompt de sistema. A partir de certo número, o modelo começa a ignorar as primeiras ou a se restringir demais e rejeitar pedidos válidos. Priorize três ou quatro regras críticas e valide cada uma com testes.

Passo 5: verificação de saída antes de mostrar ao usuário

A configuração não termina no modelo. Adicione uma camada de validação programática entre a resposta e o usuário:

• Validação de esquema: se você espera JSON, rejeite qualquer saída que não cumpra o esquema. Não tente repará-la com outro prompt sem marcar a falha.
• Verificação de entidades: extraia nomes, datas e números da resposta e compare-os com o contexto recuperado. Se uma entidade não aparece em nenhuma fonte, marque-a.
• Verificação de citações: se o modelo cita um documento, verifique se esse documento existe no seu índice e se o fragmento citado está nele. As citações inventadas são detectadas assim com alta confiabilidade.
• Segunda passada com outro modelo ou prompt: um modelo menor atuando como verificador pode apontar afirmações não sustentadas. Não é infalível e adiciona latência, mas em fluxos de conteúdo editorial compensa.

Nuance importante: a verificação automática tem falsos positivos. Um verificador rígido demais rejeitará respostas corretas que parafraseiam o contexto em vez de citá-lo literalmente. Configure o verificador para comparar significado, não correspondência exata de strings, ou você terá um sistema que rejeita tudo.

Passo 6: defina o comportamento de degradação

Um sistema maduro sabe o que fazer quando não está seguro. Configure explicitamente estes estados:

1. Confiança alta: resposta direta com fontes.
2. Confiança média: resposta com advertência visível e links para as fontes para verificação humana.
3. Confiança baixa: não responder; oferecer reformular a pergunta ou encaminhar para um humano.
4. Falha de validação: registrar o caso completo (prompt, contexto recuperado, saída, motivo da rejeição) para análise posterior.

O registro é a parte mais esquecida e a mais valiosa. Sem um log de falhas, você não pode melhorar limiares nem prompts; só pode rezar. Segundo a documentação dos principais provedores de modelos, a avaliação contínua com conjuntos de teste próprios é a única forma confiável de medir se suas mudanças reduzem alucinações ou apenas as deslocam.

Passo 7: meça com um conjunto de teste próprio, não com benchmarks públicos

Os benchmarks genéricos não refletem seu domínio. Configure um conjunto de avaliação com três tipos de casos: perguntas que seu sistema deve responder corretamente, perguntas fora de escopo que deve rejeitar e perguntas com pegadinha (premissas falsas) que deve corrigir. Execute esse conjunto toda vez que mudar temperatura, prompt, modelo ou limiar de recuperação.

Duas métricas mínimas: taxa de invenção (respostas com afirmações não sustentadas dividido entre respostas dadas) e taxa de rejeição correta (perguntas fora de escopo rejeitadas dividido entre perguntas fora de escopo). Se você otimizar apenas a primeira, o sistema acabará rejeitando tudo; se otimizar apenas a segunda, responderá inventando. Elas se movem em tensão e é preciso vigiá-las juntas.

O que esta configuração não resolve

Transparência total: mesmo com tudo o que foi dito acima bem montado, restam alucinações residuais. Os casos mais difíceis de controlar são as alucinações de raciocínio em perguntas que exigem vários passos encadeados, as que surgem de contexto recuperado ambíguo (documentos que se contradizem entre si) e as que aparecem quando o usuário pressiona o modelo com premissas falsas persistentes. Em domínios regulados (saúde, jurídico, financeiro), nenhuma configuração substitui a revisão humana; o sistema pode auxiliar, mas a responsabilidade pela afirmação final não é delegável ao modelo.

A expectativa realista não é zero alucinações, mas alucinações detectadas antes de causar dano, com um sistema que sabe quando se calar. Essa é a configuração que você pode defender diante de um cliente ou de um auditor.