Como reduzir alucinação em LLMs no seu código

Em um estudo citado pela própria OpenAI, humanos acertaram 94% das afirmações factuais e modelos de linguagem apenas 58% — o resto era alucinação em LLMs. Ou seja, quase metade das respostas era invenção. Entender por que isso acontece muda a forma de usar IA no trabalho.

O que é alucinação em LLMs e por que ela importa

Alucinação em LLMs é o termo usado na academia para descrever quando um modelo de linguagem grande inventa fatos, funcionalidades, bibliotecas ou referências que não existem, entregando a resposta com tom confiante. O fenômeno é consolidado na literatura, e não é exagero nem meme.

Isso importa porque a resposta inventada chega com a mesma confiança de uma resposta correta. Você não consegue distinguir uma da outra apenas lendo o texto. Em 2024, por exemplo, o mundo jurídico viu o caso da Air Canada, em que um chatbot prometeu ao cliente uma política de reembolso que não existia na prática.

Se você usa IA para escrever código, responder clientes ou produzir conteúdo, o risco é o mesmo: o modelo não marca o que inventou. A pergunta certa não é 'se' a LLM vai alucinar, mas 'quando' e com qual custo para você.

O que os números mostram sobre a taxa de erro

Os estudos mostram taxas de erro relevantes mesmo em modelos de ponta. No artigo Why Language Models Hallucinate, publicado pela OpenAI em 2025, o desempenho humano em afirmações factuais ficou em 94%, enquanto o dos modelos ficou em 58% — ou seja, os modelos inventavam respostas em quase metade das vezes nesse conjunto de testes.

O mesmo tipo de resultado apareceu em benchmarks internos da OpenAI descritos no artigo: em perguntas factuais, o modelo testado respondeu incorretamente em cerca de 48% das vezes, acertou em 42% e se absteve em apenas 9%. Esses números são de modelos anteriores e hoje são melhores, mas o padrão persiste.

Dois pontos do próprio artigo merecem destaque. Primeiro, a conclusão da OpenAI de que a precisão jamais atingirá 100%, mesmo com busca e raciocínio, porque algumas perguntas do mundo real são inerentemente impossíveis de responder. Segundo, a observação de que pode ser mais fácil para um modelo pequeno conhecer os próprios limites do que para um modelo maior.

Por que as LLMs alucinam: o treinamento recompensa o palpite

As LLMs alucinam porque os procedimentos padrões de treinamento e avaliação recompensam o palpite em vez do reconhecimento de incerteza. É a tese central do artigo da OpenAI de 2025: quando a avaliação pontua só acertos e ignora abstenções, o modelo aprende que chutar vale mais do que admitir que não sabe.

Isso explica algo que você talvez já tenha notado. Quando você escreve no prompt 'se não tiver certeza, me diga' ou 'busque uma fonte', o comportamento melhora — em parte porque você está pedindo exatamente o comportamento oposto ao que o treinamento incentivou.

A conclusão prática é desconfortável, mas útil: alucinação não é falha de prompt que você resolve com uma frase mágica. É uma propriedade do sistema, e qualquer solução precisa lidar com incerteza residual em vez de fingir que ela desapareceu.

Pacotes alucinados: o risco direto para quem programa

Quem gera código com IA enfrenta um risco específico e bem documentado: o modelo inventa nomes de pacotes que não existem, ou usa um pacote real com uma funcionalidade que nunca existiu. Isso transforma a alucinação em vetor de ataque, porque invasores registram nomes inventados e esperam o deploy.

A escala do problema foi medida. No estudo We Have a Package for You!, apresentado na USENIX Security em 2025, pesquisadores analisaram 576.000 amostras de código geradas por modelos de linguagem e encontraram 205.000 referências a pacotes completamente alucinados, em linguagens como Python e JavaScript. São números do estudo, não estimativas do autor.

Vale separar os dois modos de falha. Às vezes o modelo inventa o pacote inteiro; outras vezes ele pega um pacote que existe e descreve uma API que não corresponde à realidade. As duas variantes custam horas de depuração — e a segunda pode passar despercebida até produção.

Para reduzir o risco no dia a dia, algumas práticas fazem diferença concreta:

RAG e contexto reduzem, mas não eliminam, o problema

RAG (retrieval-augmented generation) melhora bastante a taxa de acerto, mas não transforma a LLM em algo que nunca mais alucina. A ideia é injetar documentos relevantes junto com o prompt, para que o raciocínio do modelo se apoie em fontes reais em vez de memória falível.

Na prática, porém, a literatura mostra limites. No artigo Benchmarking Large Language Models in Retrieval-Augmented Generation, de 2024, os pesquisadores identificam que até sistemas RAG robustos falham quando o conteúdo relevante está espalhado ou conflitante entre os documentos recuperados. E sempre existe um grau residual de erro que nenhuma técnica remove por completo.

Outro ponto de precisão: quando o sistema guarda o documento original externamente e mantém só um resumo no contexto, o correto é chamá-lo de rastreável — você consegue verificar a fonte, mas não 'reverte' o resumo de volta ao texto original. Verificação e reversibilidade são coisas diferentes, e confundi-las cria falsa sensação de segurança.

A tabela abaixo compara as principais mitigações e o que cada uma entrega de verdade:

O caso Air Canada: alucinação virou passivo jurídico

A alucinação em produção pode custar dinheiro real. Em 2024, a Air Canada foi condenada no Canadá a indenizar um passageiro que foi enganado pelo chatbot da companhia: o bot afirmou que ele poderia pedir reembolso retroativo de uma tarifa, o que não correspondia à política oficial da empresa.

O detalhe que torna o caso referência é o argumento da defesa — a companhia chegou a alegar que o chatbot era 'uma entidade legal separada' responsável pelas próprias respostas. O tribunal rejeitou a tese e manteve a indenização, como noticiou a BBC.

Para quem implementa chatbots em empresa, a lição é dupla. Primeiro, não existe garantia de que a IA responderá sempre com base em fatos. Segundo, um chatbot com capacidades agênticas — como oferecer desconto — cria superfície de abuso: um usuário malicioso pode insistir até o modelo conceder algo que a regra de negócio jamais permitiria. Em sistemas de produção, prefira respostas ancoradas em documentação verificável e mantenha ações sensíveis fora do alcance do modelo.

Como usar IA sem ser enganado por ela

É possível usar IA agressivamente no trabalho sem acreditar cegamente nela — a resposta é montar um ferramental de proteção ao redor do modelo. Ninguém deveria parar de usar LLMs por causa da alucinação; a questão é criar guarda-corpos que verifiquem o que o modelo produz.

Para uso pessoal, a técnica mais simples é pedir explicitamente que o modelo use a busca. No ChatGPT, por exemplo, frases em inglês como 'use your search tool' fazem o modelo pesquisar na internet e devolver fontes clicáveis, em vez de responder de memória.

Para código, exija verificação executável. Peça que a IA escreva um teste que falha antes do código, rode os testes e ajuste até passarem — TDD com IA reduz o espaço para invenção, porque o compilador e os testes não mentem.

Para chatbots de produção, o desenho muda um pouco e vale seguir uma sequência ordenada:

1. Limpe e expanda o prompt. Use um passo de prompt engineering para corrigir erros de português do usuário e transformar a pergunta em algo detalhado.
2. Recupere a documentação interna. Com técnicas de RAG, busque os trechos da documentação da empresa que respondem à pergunta.
3. Monte o prompt final com citação obrigatória. Instrua o modelo a citar exatamente a frase do documento que responde, e depois explicá-la.
4. Avalie com um LLM como juiz. Pesquise por 'AI judge faithfulness': um segundo modelo avalia se a resposta é fiel ao documento fornecido, e não uma invenção.
5. Bloqueie o que passar do filtro. Se a verificação reprovar, o sistema responde com o texto canônico da documentação em vez da resposta gerada.

Nenhuma dessas camadas promete perfeição — e é justamente por isso que funcionam: elas assumem que o modelo pode mentir e verificam cada resposta antes de ela chegar ao cliente.

Perguntas frequentes sobre alucinação em LLMs

• Alucinação em LLMs vai desaparecer com modelos maiores? Não. O artigo da OpenAI de 2025 conclui que a precisão jamais atingirá 100%, independentemente do tamanho do modelo ou da capacidade de busca e raciocínio, porque algumas perguntas reais não têm resposta única verificável.

• Prompt com 'se não tiver certeza, diga' resolve o problema? Ajuda, mas não resolve. O artigo da OpenAI explica que o treinamento padrão recompensa o palpite contra o reconhecimento de incerteza, então instruções melhoram o comportamento apenas parcialmente.

• O que são pacotes alucinados? São nomes de bibliotecas inventados por modelos de código. No estudo da USENIX Security de 2025, 205.000 referências a pacotes inexistentes apareceram em 576.000 amostras de código gerado, criando risco de supply chain.

• RAG elimina a alucinação? Não. O benchmark de RAG de 2024 mostra que sistemas de recuperação melhoram bastante os resultados, mas falham quando a informação está fragmentada ou conflitante entre documentos. Sempre resta um grau residual de erro.

• Posso ser processado por resposta alucinada do chatbot da minha empresa? O caso da Air Canada em 2024 mostra que sim, a empresa responde pelo que o chatbot promete ao cliente. Ancore respostas em documentação verificável e mantenha ações sensíveis fora do modelo.

Transforme vídeos como este em artigos com o Skala Blog

A ideia central deste artigo é que conhecimento confiável exige fonte verificável — e muita gente tem exatamente esse tipo de conteúdo trancado dentro de vídeos, como aulas de system design, cursos como o Crazystack Typescript ou o Bootcamp do Dev Doido do crazystack.com.br, e explicações técnicas do Gustavo Dev Doido. Vídeo é ótimo para ensinar, mas difícil de citar, buscar e revisar depois.

O Skala Blog resolve esse caminho: você cola a URL de um vídeo do YouTube, a ferramenta transcreve o conteúdo e gera um artigo estruturado, pronto para você revisar e publicar. Se o seu melhor material está no formato falado, transformá-lo em texto é o jeito mais direto de deixá-lo verificável — ao contrário do que uma LLM sem fonte faria.

Source video