Alucinação de IA: por que o modelo inventa com tanta segurança e o que realmente reduz isso

O que você leva deste artigo

• Alucinação vem do desenho do sistema, não de um defeito que um modelo melhor resolve sozinho.
• Benchmarks que dão nota zero para "não sei" ensinam o modelo a chutar, segundo pesquisa da OpenAI.
• A técnica de maior efeito é entregar a fonte junto com a pergunta, em vez de confiar na memória do modelo.
• Pedir "não invente" no prompt tem efeito pequeno e dá falsa sensação de segurança.
• Verificação por código vale mais que verificação por outro modelo quando o dado é checável.
• Nome próprio, data, número e citação são as quatro categorias que mais falham.

O que é, e por que o nome atrapalha

Alucinação é o nome que pegou para descrever o momento em que o modelo afirma algo falso com a mesma naturalidade com que afirma algo verdadeiro. Um artigo de lei que não existe, uma data errada, um estudo científico inventado com autor e ano plausíveis, um recurso que aquele produto nunca teve.

O nome atrapalha porque sugere um estado alterado, uma exceção, algo que sai do normal. Não é isso. Do ponto de vista do sistema, nada de diferente aconteceu. Ele fez exatamente a mesma operação de sempre, prever o próximo pedaço de texto, com a mesma confiança de sempre. Quem separa acerto de erro é você, do lado de fora.

É por isso que não existe um aviso. Não há um medidor interno que dispare "atenção, esta parte eu inventei". A voz é a mesma, a estrutura da frase é a mesma, a fluência é a mesma. Um termo mais preciso seria confabulação: preencher uma lacuna com algo plausível sem perceber que está preenchendo.

Entender essa parte muda a forma de usar a ferramenta. O erro não vem com sinal, então a verificação não pode depender de você notar algo estranho. Ela precisa ser sistemática nos pontos em que errar custa caro.

A causa mais profunda: o treino premia o chute

Em setembro de 2025, pesquisadores da OpenAI publicaram um trabalho que dá a explicação mais direta e mais desconfortável do fenômeno. O título é Why Language Models Hallucinate, e o argumento central é sobre incentivo, não sobre capacidade.

A lógica é a de uma prova de múltipla escolha sem desconto por erro. Se deixar em branco vale zero e chutar vale alguma chance de acertar, o aluno racional chuta em tudo. Os benchmarks usados para avaliar e comparar modelos funcionam quase todos assim: resposta certa pontua, resposta errada não pontua, e "não sei" também não pontua. Do ponto de vista da nota, chutar domina admitir ignorância.

Como esses benchmarks orientam o desenvolvimento e a comparação pública dos modelos, o resultado é um sistema treinado para sempre arriscar. A confiança excessiva não é acidente: é comportamento premiado. Os autores propõem mudar os critérios de avaliação para dar crédito parcial à incerteza bem colocada e penalizar o erro confiante.

A conclusão prática que interessa a quem contrata: alucinação não é um bug que a próxima versão resolve. Modelos novos alucinam menos porque a base melhorou, e continuam alucinando porque o incentivo continua. Quem promete IA que nunca erra está vendendo o que não existe.

Numa prova sem desconto por erro, chutar sempre bate deixar em branco. É exatamente esse o incentivo que treinamos nesses modelos.

Por que sempre erram as mesmas quatro coisas

Existe um padrão claro no que falha, e conhecê-lo permite direcionar a conferência em vez de reler tudo.

Nome próprio e referência é a categoria campeã. Autor de livro, nome de estudo, processo judicial, artigo de norma técnica. O modelo aprendeu a forma de uma citação, e a forma é fácil de reproduzir sem o conteúdo correto. O resultado é uma referência que parece impecável e não existe.

Data e número vêm em seguida. Ano de lei, percentual, valor, versão de produto. São informações que variam muito entre textos parecidos, então o padrão estatístico é fraco justamente onde a precisão importa.

Detalhe específico de produto ou empresa é a terceira. Se a informação não estava suficientemente presente no material de treino, o modelo preenche com o que seria razoável para uma empresa daquele tipo. E o recente é a quarta: tudo que aconteceu depois do corte de treinamento é reconstruído por analogia, a menos que o sistema busque na hora.

Repare no que essas quatro categorias têm em comum: todas são exatamente o que se copia de uma resposta para dentro de um documento sem reler. Por isso o dano é desproporcional ao número de erros.

O que reduz de verdade, em ordem de efeito

A técnica de maior impacto, e não é perto, é entregar a informação junto com a pergunta. Em vez de perguntar ao modelo o que diz a política de troca da sua empresa, você manda a política no próprio pedido e pede uma resposta baseada nela. O trabalho deixa de ser lembrar e passa a ser ler, e ler é o que ele faz bem.

Isso, feito de forma automática e em escala, tem nome: RAG. Um sistema busca os trechos relevantes na sua base, cola no pedido e o modelo responde só com aquilo. Não elimina o erro, porque o modelo ainda pode interpretar mal ou extrapolar, mas muda a natureza do problema: de invenção livre para leitura de um material que você controla.

A segunda técnica é exigir a citação do trecho. Peça que cada afirmação venha acompanhada do pedaço exato do documento em que ela se apoia. Isso ajuda de duas formas: dificulta a invenção livre e, principalmente, torna a conferência rápida, porque quem revisa não precisa procurar, só comparar.

A terceira é autorizar explicitamente o não sei. Instruções do tipo "se a informação não estiver nos documentos fornecidos, responda que não está disponível e pare" funcionam melhor do que a proibição genérica de inventar, porque dão uma saída aceitável em vez de só fechar uma porta.

• Efeito alto: mandar a fonte junto com a pergunta, em vez de confiar na memória do modelo.
• Efeito alto: exigir o trecho literal que sustenta cada afirmação.
• Efeito médio: autorizar a resposta "não está no material fornecido" como saída válida.
• Efeito médio: validar por código o que é checável, como CPF, data, valor e existência de cadastro.
• Efeito baixo: pedir no prompt para não inventar, sem mudar mais nada.

O que quase não funciona, mas todo mundo tenta

Vale gastar um parágrafo em cada, porque essas três táticas dominam os tutoriais e dão uma sensação de segurança que não corresponde ao resultado.

Pedir para não inventar. Colocar "não invente informações" no prompt tem efeito pequeno. O modelo não está inventando de propósito: ele não sabe que está. A instrução pede um comportamento que depende de uma consciência que o sistema não tem.

Perguntar se ele tem certeza. Quando você questiona, ele frequentemente muda a resposta, e isso parece autocorreção. Não é. É o efeito do treinamento que premia concordar com o usuário. Ele muda com a mesma facilidade quando estava certo, o que é pior: você acabou de destruir uma resposta boa.

Pedir para o modelo revisar a si mesmo. Ajuda em coerência e em erro de lógica, e ajuda pouco em fato, porque a segunda passada tem exatamente a mesma limitação da primeira. Onde o dado é verificável por código ou por consulta a um sistema, verificar por código vale muito mais do que verificar por outro modelo.

Como decidir onde isso importa na sua empresa

Nem toda tarefa exige o mesmo rigor, e tratar tudo com rigor máximo mata o ganho. A pergunta certa não é se o modelo pode errar, é quanto custa cada erro e quem percebe.

Existem tarefas em que a alucinação praticamente não incomoda, porque toda a informação necessária está na entrada e a saída é conferida na hora. Resumir uma reunião cujo áudio está ali, reescrever um texto que você vai reler, sugerir títulos, organizar uma lista bagunçada. O erro aparece na cara de quem pediu.

E existem tarefas em que a alucinação é inaceitável sem barreira: qualquer coisa que envolva valor, prazo contratual, orientação de saúde, informação jurídica, ou texto que vai direto ao cliente sem passar por ninguém. Aqui o modelo entra como rascunho e a decisão fica com a pessoa, ou o dado sai de um sistema e o modelo só escreve em volta.

É por isso que na ROO3 vale uma regra fixa em projeto: valor não é calculado por modelo de linguagem. A conta é feita em código, que é determinístico e testável, e o modelo entra para explicar o resultado em português. Errar dinheiro é a categoria de erro que nenhuma economia de tempo compensa.

Um desenho de sistema que aguenta o erro

Sistema confiável com IA não é o que impede o erro, é o que sobrevive a ele. A diferença está em três camadas que trabalham juntas.

Na entrada: o modelo recebe o material necessário em vez de depender da memória, e o material vem recortado para o que importa. Documento inteiro na janela é convite para o modelo se perder no meio e preencher lacuna com invenção.

Na saída: tudo que é checável por máquina é checado por máquina. Se o modelo devolveu um CNPJ, valide o formato e a existência. Se devolveu um valor, recalcule. Se devolveu uma referência a um documento, confira se aquele trecho existe mesmo no documento. Essa verificação custa quase nada e pega a maior parte dos erros graves.

No fluxo: um ponto de conferência humana posicionado onde o custo do erro é alto, e não em toda etapa. Revisar tudo anula o ganho e cansa a pessoa, que passa a aprovar no automático depois de duas semanas. Revisar o que importa mantém a atenção onde ela vale.

Se você está desenhando um processo assim agora e quer definir onde ficam essas barreiras no seu caso, é exatamente essa a conversa da consultoria em IA da ROO3. E se o problema é escolher o modelo, as medições públicas estão reunidas no AI Benchmark.

Perguntas frequentes

Por que a IA inventa em vez de dizer que não sabe?

Porque o treinamento e a avaliação premiam o chute. Pesquisadores da OpenAI mostraram em 2025 que os benchmarks usados para comparar modelos dão zero tanto para a resposta errada quanto para o "não sei", o que torna arriscar sempre melhor do que admitir ignorância do ponto de vista da nota.

Modelos mais novos alucinam menos?

Alucinam menos, e continuam alucinando. A base de conhecimento melhora e o raciocínio melhora, mas o incentivo que premia respostas confiantes continua. Nenhuma versão resolve o problema por completo, então o desenho do sistema em volta continua sendo necessário.

Adianta pedir no prompt para a IA não inventar?

Adianta pouco. O modelo não sabe que está inventando, então a instrução pede um comportamento que depende de uma percepção que ele não tem. Funciona melhor autorizar explicitamente a resposta "não está no material fornecido" e entregar o material junto da pergunta.

RAG elimina a alucinação?

Não elimina, muda de natureza. Com RAG o modelo responde a partir de trechos que você controla, o que reduz muito a invenção livre, mas ele ainda pode interpretar mal um trecho ou extrapolar além do que está escrito. É a técnica de maior efeito, não uma garantia.

Onde os erros aparecem com mais frequência?

Em quatro categorias: nome próprio e referência, como autor e número de processo; data e número, como ano de lei e percentual; detalhe específico de produto ou empresa; e qualquer coisa recente demais para estar no treinamento. São justamente os itens que costumam ser copiados sem releitura.

Perguntar "você tem certeza?" corrige a resposta?

Não de forma confiável. O modelo tende a mudar a resposta quando questionado porque o treinamento premia concordar com o usuário, e ele muda com a mesma facilidade quando a resposta original estava certa. Questionar pode destruir uma resposta boa.

Fontes

• Kalai, Nachum, Vempala e Zhang: Why Language Models Hallucinate (arXiv, 2025)
• OpenAI: Why language models hallucinate

Rodrigo Fávaro

Fundador da ROO3, agência de marketing e tecnologia em São José do Rio Preto. Constrói produtos com IA em produção (Tobia, gerar.app, Pense Mercado) e mantém o AI Benchmark, ranking público de modelos de IA. Veja a consultoria em IA da ROO3.

X @rodmf LinkedIn rodrigofavaro