Alucinações em IA: porque acontecem e como as reduzir

Poucos comportamentos da inteligência artificial geram tanta desconfiança como a chamada alucinação: o modelo responde com uma segurança impecável e, mesmo assim, o que diz é falso. Pode inventar um número, atribuir uma citação a alguém que nunca a disse ou descrever a funcionalidade de um produto que não existe. Para quem está a decidir se confia numa ferramenta de IA dentro da empresa, é normalmente aqui que a conversa trava.

O problema não é a IA mentir — mentir implica intenção. O que acontece é mais subtil e, em certo sentido, mais incómodo: o modelo produz texto plausível sem qualquer noção do que é verdadeiro. Enquanto uma pessoa hesita quando não sabe, um modelo de linguagem tende a preencher o vazio com a resposta estatisticamente mais provável, mesmo que não corresponda à realidade.

Este artigo explica, sem jargão a mais, porque é que as alucinações acontecem, onde fazem mais estragos num contexto empresarial e — a parte que interessa a quem tem de implementar — que técnicas reduzem o problema de forma consistente. Não há solução mágica, mas há um conjunto de práticas que transforma um sistema pouco fiável num assistente em que se pode confiar.

O que é, afinal, uma alucinação

Uma alucinação é uma resposta fluente, bem escrita e convincente que, no entanto, é factualmente errada ou não tem fundamento na fonte que deveria sustentá-la. Não se trata de um erro de digitação nem de uma frase mal construída: é conteúdo que parece correto e não é. É exatamente essa aparência de competência que a torna perigosa, porque desarma o sentido crítico de quem lê.

Vale a pena separar dois casos. Há a alucinação factual, em que o modelo afirma algo falso sobre o mundo, e há a alucinação de fidelidade, em que o modelo contradiz ou distorce um documento que lhe foi dado como contexto. A segunda é traiçoeira porque acontece mesmo quando a informação correta estava mesmo ali, à frente do modelo.

Porque é que os modelos inventam

Um modelo de linguagem é, na sua essência, um previsor de palavras. Foi treinado para, dado um texto, estimar qual a continuação mais provável. Não guarda uma base de dados de factos que possa consultar, nem tem um mecanismo interno que verifique se aquilo que gera é verdade. Gera o que soa bem à luz dos padrões que aprendeu.

A isto juntam-se três fontes recorrentes de erro. Primeiro, lacunas e desatualização nos dados de treino: se um tema estava mal representado, o modelo improvisa. Segundo, ambiguidade no pedido: uma pergunta vaga abre espaço para o modelo assumir coisas erradas. Terceiro, uma espécie de pressão para responder sempre — na ausência de instruções em contrário, dizer não sei é raro, e o modelo prefere arriscar uma resposta completa a admitir a incerteza.

Os tipos de alucinação mais frequentes

Reconhecer o tipo de erro ajuda a escolher a defesa certa. Na prática, encontram-se sobretudo estes:

• Factual: datas, valores, nomes ou eventos simplesmente errados.
• De atribuição: citações, estudos ou fontes que soam credíveis mas não existem.
• De contexto: a resposta contradiz o documento que foi fornecido ao modelo.
• De raciocínio: uma cadeia lógica que parece impecável, mas que assenta num passo inválido.
• De instrução: o modelo inventa passos, campos ou regras que ninguém definiu.

Onde doem mais no negócio

Nem todas as alucinações têm o mesmo custo. Num rascunho criativo, uma imprecisão é irrelevante. Já num contexto de decisão, o estrago pode ser sério. No apoio ao cliente, uma promessa inventada sobre prazos ou coberturas cria expectativas que a empresa terá de honrar ou desiludir. No jurídico e no financeiro, uma cláusula ou um cálculo errado pode ter consequências contratuais. Na documentação técnica e na saúde, uma instrução incorreta pode ser diretamente perigosa.

A regra prática é simples: quanto maior a consequência de um erro, mais controlos o sistema precisa. Um assistente que resume notas internas exige menos salvaguardas do que um que responde a clientes em nome da marca.

Ancorar o modelo na realidade

A alavanca mais poderosa contra alucinações é não deixar o modelo responder de memória. Em vez disso, recupera-se primeiro a informação relevante de uma fonte fiável — uma base de conhecimento, uma tabela, um conjunto de documentos — e entrega-se essa informação ao modelo como contexto, pedindo-lhe que responda apenas com base nela. É esta a ideia por trás da abordagem RAG (retrieval-augmented generation).

Ancorar as respostas na fonte muda o jogo por duas razões. Reduz a dependência da memória imperfeita do modelo e permite exigir citações: se cada afirmação tem de apontar para um trecho concreto, torna-se fácil verificar — e o próprio modelo tende a inventar menos quando sabe que tem de mostrar de onde tirou a resposta.

Afinar o pedido e os parâmetros

Muito se ganha na forma como se pede. Instruir explicitamente o modelo a responder não sei quando a informação não está no contexto elimina uma boa fatia das invenções. Pedir fontes, delimitar o âmbito e dar exemplos do formato esperado também ajudam. Para tarefas factuais, uma temperature baixa reduz a criatividade e, com ela, a tendência para divagar.

Há ainda um princípio que poupa muitos dissabores: quando existe uma ferramenta fiável para uma tarefa, use-se a ferramenta. Para contas, uma calculadora ou uma consulta em SQL; para dados atuais, uma chamada à API certa. Deixar o modelo adivinhar aquilo que um sistema determinístico saberia com exatidão é pedir para ter problemas.

Verificar, avaliar e manter pessoas no ciclo

Nenhuma técnica isolada elimina o risco, por isso a fiabilidade constrói-se em camadas. Antes de pôr em produção, vale a pena montar um conjunto de avaliação — perguntas com respostas conhecidas — e medir com que frequência o sistema erra. Depois de lançado, monitoriza-se o comportamento real e recolhe-se o feedback de quem o usa.

Para decisões de maior risco, manter um humano no ciclo continua a ser a salvaguarda mais barata face ao custo de um erro. Não significa rever tudo; significa desenhar o fluxo para que as respostas sensíveis passem por validação antes de terem efeito.

Erros comuns de quem implementa

Muitos projetos falham não pela tecnologia, mas por decisões de implementação evitáveis:

• Confiar cegamente na primeira demonstração, que costuma correr bem, e assumir que produção será igual.
• Não pedir nem mostrar fontes, deixando o utilizador sem forma de verificar.
• Não medir a taxa de erro antes e depois de cada mudança.
• Escrever pedidos genéricos, sem contexto nem instrução sobre o que fazer perante a incerteza.
• Não definir o comportamento esperado quando o modelo não sabe — e é aí que ele inventa.

Mini-caso: o assistente que inventava coberturas

Uma empresa de seguros colocou um assistente interno para ajudar a linha de apoio a responder a dúvidas sobre apólices. Na primeira versão, o modelo respondia de memória e, em cerca de uma em cada seis respostas, descrevia coberturas que a apólice em causa não incluía. O risco era evidente: informação errada dada a um cliente sobre aquilo que está ou não coberto.

A equipa reformulou a abordagem. Passou a recuperar o texto exato da apólice relevante e a exigir que cada resposta citasse a cláusula de onde vinha; instruiu o modelo a dizer que não tinha a informação sempre que a cláusula não aparecia; e definiu que casos ambíguos eram encaminhados para um colega humano. A taxa de respostas incorretas caiu para menos de uma em quarenta, e — talvez o mais importante — a confiança da equipa no assistente subiu ao ponto de o passarem a usar todos os dias.

Na prática

Alucinações não são um defeito que desaparece com o próximo modelo; são uma característica de como estes sistemas funcionam. A boa notícia é que se gerem. Ancore as respostas em fontes fiáveis, exija citações, afine os pedidos, use ferramentas para o que é determinístico e mantenha avaliação e supervisão humana onde o erro custa caro. Não se trata de esperar pela perfeição, mas de desenhar o sistema para que, quando errar, erre de forma visível e contida — e para que, na maioria das vezes, não erre de todo.