Como reduzir alucinações

O que é uma alucinação de IA

Alucinação — também chamada de confabulação em documentos técnicos — ocorre quando um sistema generativo produz uma afirmação incorreta, inventada ou não sustentada pelo contexto e a apresenta com aparência de resposta válida. Pode ser um nome, data, lei, cálculo, link, citação, recurso de software, diagnóstico ou descrição de uma imagem que não corresponde ao conteúdo real.

O termo não implica consciência nem experiência semelhante à humana. Modelos de linguagem estimam sequências prováveis de tokens; eles podem construir texto coerente mesmo quando não dispõem da informação necessária. A confiança verbal da resposta não representa uma probabilidade calibrada de estar correta.

Também é importante separar alucinação de outros problemas. Uma opinião contestável não é necessariamente alucinação; uma resposta verdadeira, mas fora do pedido, é falha de relevância; uma recusa indevida é falha de utilidade; um fato antigo pode ser desatualização. Diagnosticar a categoria correta determina a correção adequada.

Por que modelos geram informações falsas

O objetivo básico de muitos modelos é produzir uma continuação provável, não consultar automaticamente um banco perfeito de fatos. O conhecimento está comprimido em parâmetros, pode conter contradições, lacunas e limites temporais. Quando uma pergunta exige um detalhe ausente, o modelo ainda pode completar o padrão linguisticamente.

Ambiguidade aumenta o risco. Nomes parecidos, falta de data, jurisdição indefinida ou premissas falsas levam o sistema a escolher uma interpretação. Instruções que exigem certeza, número específico de fontes ou resposta obrigatória podem pressioná-lo a preencher lacunas.

A alucinação também pode surgir fora do modelo. O mecanismo de busca recupera documento errado; o OCR lê uma tabela de modo incorreto; um índice está desatualizado; a ferramenta falha; o software associa a citação ao trecho errado; a conversa corta contexto. É preciso avaliar o sistema inteiro, não apenas trocar o prompt.

• Conhecimento ausente, incompleto, contraditório ou desatualizado.
• Pergunta ambígua, falsa ou fora do domínio testado.
• Contexto longo, ruidoso, truncado ou mal organizado.
• Recuperação de fonte irrelevante ou insuficiente.
• Ferramenta, integração, OCR ou transformação com erro.
• Configuração que favorece variação quando a tarefa exige precisão.
• Instruções que não permitem perguntar, recusar ou declarar incerteza.

Classifique o risco antes de escolher controles

Nem todo erro tem o mesmo impacto. Uma ideia fictícia para um conto é parte da tarefa; uma referência inventada em pesquisa prejudica credibilidade; uma dose de medicamento incorreta pode causar dano. Avalie severidade, probabilidade, alcance, possibilidade de reversão e capacidade de detecção antes de implantar.

Defina quais afirmações exigem fonte, quais podem ser inferências e quando o sistema deve parar. Em alto risco, a meta não é responder a qualquer custo, mas falhar com segurança. Isso pode significar encaminhar para especialista, mostrar apenas documentos oficiais ou impedir uma ação automática.

Registre tolerância de erro por componente. Um chatbot pode aceitar pequena variação de tom, mas exigir precisão total em identidade do cliente e movimentação financeira. Uma única nota geral de “qualidade” esconde esse contraste.

Melhore a pergunta e permita incerteza

Especifique período, local, público, definição e fonte esperada. Em vez de perguntar “qual é a regra?”, diga qual jurisdição e data interessam. Corrija premissas falsas explicitamente: peça que o modelo primeiro verifique se a entidade, evento ou relação existe.

Autorize três comportamentos: fazer perguntas quando faltar contexto, declarar o que não sabe e recusar uma conclusão sem evidência. Peça níveis separados de fato, inferência e recomendação. Não ordene “responda com certeza” nem “nunca diga não sei”.

Para tarefas documentais, delimite a fonte de verdade e determine uma saída para ausência. Uma boa regra é: responder apenas com o material fornecido, apontar o trecho utilizado e escrever “não encontrado nas fontes” quando o apoio não existir.

Aterre a resposta em fontes confiáveis

Grounding significa ligar a resposta a informação verificável. Pode ocorrer com documentos anexados, pesquisa na web, banco corporativo ou RAG — recuperação de trechos antes da geração. A fonte deve ser adequada à pergunta: lei no portal oficial, dado no órgão produtor, especificação na documentação da versão e pesquisa no artigo original.

RAG não garante verdade. É preciso cuidar de ingestão, OCR, divisão em trechos, metadados, filtros de acesso, busca híbrida, reranking e atualização. Se a recuperação não encontra o trecho certo, um gerador eloquente apenas encobre o problema. Mostre as evidências recuperadas e permita resposta vazia.

Citações devem ser localizáveis e relevantes. O fato de uma URL existir não prova que ela sustenta a frase. Verifique título, autoria, data, versão, trecho e relação entre alegação e evidência. Para conteúdo atual, registre a data da consulta.

1. Escolher fontes autorizadas e definir prioridade entre elas.
2. Preservar título, versão, data, seção e permissões na ingestão.
3. Testar se perguntas conhecidas recuperam o trecho correto.
4. Exigir citação por alegação e resposta de ausência.
5. Abrir uma amostra de citações e conferir no original.
6. Monitorar atualização, documentos conflitantes e falhas de acesso.

Use ferramentas para fatos, cálculos e ações

Quando a tarefa exige informação atual, conecte busca ou base oficial. Para aritmética, estatística ou conversão, use calculadora ou código. Para estoque, cadastro e agenda, consulte o sistema responsável. O modelo deve interpretar e apresentar o resultado, não fingir que executou uma consulta inexistente.

Valide argumentos e retornos das ferramentas. Uma chamada pode usar unidade errada, filtro incompleto ou identificador de outro cliente. Exiba confirmação antes de ações irreversíveis e aplique autorização fora do modelo. Se a ferramenta falhar, o sistema deve informar a falha, não completar com uma suposição.

Ferramentas ampliam também o risco de prompt injection: páginas, e-mails e documentos podem conter instruções adversárias. Trate conteúdo externo como dado não confiável, limite permissões e separe decisão de execução.

• Busca para fatos recentes ou obscuros.
• Calculadora ou código para operações numéricas.
• Banco autorizado para registros corporativos.
• Schema estruturado para campos e tipos obrigatórios.
• Validador determinístico para regras que não admitem variação.
• Confirmação humana para ação sensível ou irreversível.

Decomponha, extraia evidências e verifique

Divida tarefas complexas em etapas observáveis. Primeiro localizar evidências, depois construir uma tabela de alegações, então redigir e por fim verificar cada frase. Isso facilita encontrar em qual etapa ocorreu a falha e evita que uma síntese fluente esconda fonte insuficiente.

Em documentos longos, peça trechos literais com página ou seção antes da interpretação. Na checagem, examine nomes, datas, números, citações, relações causais e conclusões. Uma segunda chamada do mesmo modelo pode ajudar a encontrar problemas, mas não é validação independente; use fonte, código ou especialista.

Para decisões importantes, adote revisão humana com responsabilidade definida. O revisor precisa de acesso às evidências e tempo para conferir, não apenas de um botão “aprovar”. Automação que sobrecarrega a revisão transforma a pessoa em formalidade.

Controle geração, formato e consistência

Temperatura menor pode reduzir variação, mas não transforma uma crença errada em verdade. Limites de tokens evitam saídas intermináveis, porém podem cortar ressalvas. Saída estruturada melhora conformidade de campos, não garante que os valores estejam corretos.

Use schemas, enumerações e validação para tarefas de extração e classificação. Rejeite campos fora do domínio e aplique regras de negócio em código. Para respostas textuais, uma rubrica explícita pode exigir cobertura, fonte, concisão e incerteza.

Não confunda consistência com exatidão. Um sistema pode repetir o mesmo erro em todas as execuções. Teste várias amostras quando a variabilidade importa e compare com referência independente.

Meça alucinação e capacidade de se abster

Monte um conjunto de avaliação com perguntas respondíveis, não respondíveis, ambíguas, desatualizadas e adversariais. Inclua casos reais, erros históricos e diferentes grupos de usuários. Para cada item, preserve a fonte de verdade e a resposta aceitável.

Meça precisão factual — proporção de alegações corretas —, fidelidade ao contexto, correção e cobertura das citações, taxa de respostas sem apoio e comportamento de abstenção. Uma boa abstenção ocorre quando faltam dados; uma abstenção excessiva reduz utilidade. Analise ambos os lados.

Pondere por severidade. Errar uma cor e errar uma contraindicação não têm o mesmo peso. Relate resultados por segmento e tipo de falha, não apenas uma média. Refaça testes após mudar modelo, prompt, fontes, índice ou ferramenta.

Proteja contra fontes maliciosas e contexto contaminado

Uma resposta pode parecer alucinada quando o sistema seguiu instruções escondidas em uma página, PDF, e-mail ou resultado de ferramenta. Prompt injection indireta tenta transformar dado recuperado em comando. Marcação e instruções ajudam, mas não constituem barreira de segurança suficiente.

Aplique listas de ferramentas permitidas, menor privilégio, validação de parâmetros, isolamento, filtros de saída e confirmação para ações de alto impacto. Não exponha segredos ao contexto se o modelo não precisa deles. Registre a origem de cada trecho e trate conteúdo externo como não confiável.

Teste documentos que mandam ignorar regras, revelar dados ou executar ações. O comportamento seguro é preservar instruções autorizadas, citar a fonte e pedir confirmação quando houver conflito.

Monitore em produção e aprenda com incidentes

Avaliação anterior ao lançamento não cobre toda a variedade real. Registre versão do modelo, prompt, fontes, ferramentas, latência e decisão de revisão, respeitando privacidade. Crie canal para usuários sinalizarem erro e um procedimento para triagem, correção e comunicação.

Amostre respostas para revisão, acompanhe métricas por versão e estabeleça alertas para quedas. Novos documentos, mudança de política, atualização do modelo ou alteração no índice podem criar regressões. Use casos de incidentes como testes permanentes.

Tenha fallback: busca simples, resposta baseada em documento, encaminhamento humano, pausa da função ou retorno a versão anterior. Em alto risco, capacidade de interromper rapidamente é parte da qualidade.

1. Detectar e registrar o caso com contexto autorizado.
2. Classificar tipo, causa, severidade e alcance.
3. Corrigir fonte, prompt, ferramenta, código ou política apropriada.
4. Criar teste de regressão com o caso sanitizado.
5. Reavaliar casos relacionados antes de publicar.
6. Monitorar a correção e comunicar impacto quando necessário.

O que não funciona sozinho

Não basta pedir “seja verdadeiro”, solicitar muitas fontes, mandar o modelo revisar a própria resposta ou trocar automaticamente para o modelo mais caro. Essas medidas podem ajudar em alguns contextos, mas falham sem evidência e avaliação. Confiança exibida pelo modelo também pode ser mal calibrada.

Uma citação não é selo de verdade; RAG não é banco infalível; revisão humana não funciona sem acesso à fonte; aviso genérico ao usuário não transfere responsabilidade. Qualidade nasce de camadas complementares.

O objetivo realista é reduzir frequência e impacto, aumentar detecção e garantir falha segura. Para uso crítico, não permita que a saída do modelo seja a única base de decisão.

Checklist de confiabilidade

Aplique o checklist ao sistema completo. Se uma pergunta essencial não puder ser respondida, reduza o escopo ou mantenha o fluxo em revisão humana. Documente quem é responsável por fonte, avaliação, aprovação e incidente.

1. Finalidade, risco e tolerância de erro estão definidos.
2. Fontes autorizadas, atuais e acessíveis foram escolhidas.
3. O sistema pode perguntar, declarar ausência e se abster.
4. Alegações e citações são localizáveis no original.
5. Cálculos e regras determinísticas usam ferramentas ou código.
6. Entradas externas são tratadas como não confiáveis.
7. Conjunto de testes inclui ausência, ambiguidade e casos adversariais.
8. Métricas separam exatidão, fidelidade, citação e abstenção.
9. Há revisão responsável, logs adequados, fallback e plano de incidente.