O que é alucinação em IA e como reduzi-la

Modelos de linguagem produzem texto fluente, seguro e bem escrito — inclusive quando estão completamente errados. Esse fenômeno de inventar fatos, fontes ou números que parecem plausíveis mas não existem é o que chamamos de alucinação. Para quem constrói produtos com IA, entender por que isso acontece e como mitigar é a diferença entre uma demo bonita e um sistema em que se pode confiar. Este artigo explica a mecânica do problema, mostra as técnicas que realmente funcionam em produção e propõe uma estratégia de defesa em camadas que você pode aplicar hoje.

O que é uma alucinação

Alucinação é quando um modelo gera conteúdo fluente e confiante, porém factualmente incorreto ou não fundamentado em nenhuma fonte real. O termo foi consolidado no levantamento de Ji, Lee, Frieske, Yu, Su, Xu, Ishii, Bang, Madotto e Fung (2023), que organizou o problema na geração de linguagem natural em duas categorias úteis:

O detalhe perigoso é o tom. A alucinação raramente vem hesitante. Ela vem com a mesma segurança de uma resposta correta, o que torna a detecção por parte do usuário muito difícil. Um modelo que dissesse "acho que talvez seja X, mas não tenho certeza" seria fácil de auditar. O problema é que ele costuma afirmar X com a mesma firmeza com que afirma que 2 + 2 = 4.

Vale separar alucinação de outros erros que às vezes são confundidos com ela:

Distinguir esses casos importa porque cada um pede uma mitigação diferente. Tratar tudo como "alucinação" leva a soluções genéricas que não atacam a causa real.

Por que os LLMs alucinam

A causa raiz está na natureza do modelo. Um LLM (Large Language Model) é, no fundo, um preditor da próxima palavra: ele estima qual token é mais provável de vir a seguir, dado o contexto. Ele otimiza plausibilidade linguística, não veracidade. Não há, dentro dele, um banco de dados de fatos com checagem de verdade — há padrões estatísticos aprendidos de texto.

Alguns fatores que aumentam a chance de alucinar:

O papel do treino e do alinhamento

Há uma razão mais sutil, ligada à forma como modelos modernos são ajustados. Durante o alinhamento por feedback humano, avaliadores tendem a premiar respostas completas, úteis e confiantes. Uma resposta que diz "não sei" costuma receber nota menor do que uma resposta detalhada — mesmo que a detalhada esteja errada. Com o tempo, o modelo aprende que soar prestativo é recompensado, e admitir ignorância é punido. Isso cria um viés sistêmico em direção à confiança excessiva.

Outro fator é a calibração. Um modelo bem calibrado atribuiria probabilidade baixa a afirmações sobre as quais tem pouca evidência. Na prática, LLMs frequentemente são mal calibrados: produzem texto com tom de alta certeza mesmo quando a distribuição interna de tokens estava dividida. A confiança expressa no texto nem sempre reflete a confiança estatística real.

Vale uma ressalva conceitual: alucinar não é um "bug" no sentido tradicional. É uma consequência direta de como o modelo funciona. Por isso falamos em reduzir, não em "eliminar".

A técnica mais eficaz: fundamentar com RAG

A estratégia mais poderosa contra alucinação extrínseca é grounding (fundamentação): dar ao modelo as fontes corretas no próprio prompt e instruí-lo a responder apenas com base nelas. É exatamente o que faz o RAG (Retrieval-Augmented Generation).

A ideia foi formalizada por Lewis, Perez, Piktus, Petroni, Karpukhin, Goyal, Küttler, Lewis, Yih, Rocktäschel, Riedel e Kiela (2020): em vez de depender só do que o modelo memorizou, um componente de recuperação busca documentos relevantes e os fornece como contexto para a geração. O modelo deixa de "lembrar de cor" e passa a "ler e responder".

O fluxo, em alto nível:

pergunta → [busca em base de conhecimento] → trechos relevantes
        → [prompt: "responda SÓ com base nestes trechos"] → resposta fundamentada

Na hora de montar esse prompt, instruções explícitas fazem diferença:

Use APENAS as informações do contexto abaixo para responder.
Se a resposta não estiver no contexto, diga "Não encontrei essa informação nas fontes".
Cite o trecho que sustenta cada afirmação.

CONTEXTO:
{trechos_recuperados}

PERGUNTA: {pergunta_do_usuario}

Para colocar isso de pé com chunking, embeddings e busca, o passo a passo está em RAG na prática: dê memória e contexto ao seu LLM. Fundamentar não só reduz invenções como permite citar fontes, o que torna a resposta auditável.

Quando o próprio RAG alucina

Um erro comum é achar que RAG resolve o problema sozinho. Ele reduz drasticamente a alucinação extrínseca, mas introduz novos pontos de falha:

Por isso, a qualidade do RAG depende tanto da recuperação quanto da geração. Medir os dois separadamente — a precisão da busca e a fidelidade da resposta ao contexto — é o que permite diagnosticar onde o sistema está falhando.

Engenharia de prompt que reduz invenções

Mesmo sem RAG, a forma como você pede muda bastante o resultado. Algumas técnicas com bom retorno:

Essas e outras técnicas, aplicadas a tarefas de desenvolvimento, aparecem detalhadas em Prompt engineering para código: como pedir o que você precisa — ali o efeito de instruções precisas sobre a confiabilidade fica bem visível.

Exemplos de prompt antes e depois

Compare uma instrução vaga com uma instrução defensiva:

# Vago — convida o modelo a preencher lacunas
"Quais são os principais artigos sobre teoria X? Liste título, autor e ano."

# Defensivo — abre saída para a incerteza
"Liste apenas artigos sobre teoria X dos quais você tem certeza.
Para cada um, indique seu nível de confiança (alto/médio/baixo).
Se não tiver certeza de um título ou autor, escreva 'não confirmado'
em vez de inventar. É melhor listar menos itens corretos do que muitos
itens duvidosos."

A primeira versão praticamente garante uma lista bonita e parcialmente inventada. A segunda dá ao modelo permissão social para ser honesto sobre os limites do que sabe. Pequenas mudanças de enquadramento como essa têm efeito mensurável.

Decomposição de tarefas

Tarefas grandes alucinam mais. Em vez de pedir "escreva um relatório completo sobre o assunto", quebre em etapas: primeiro levantar fatos verificáveis, depois redigir cada seção a partir desses fatos, depois revisar. Cada etapa menor tem menos espaço para o modelo se desviar, e os pontos de verificação ficam mais claros. Decompor também facilita inserir checagens entre as etapas.

Verificação, guardrails e o humano no loop

Reduzir a probabilidade de alucinar não basta para sistemas críticos. É preciso uma camada de verificação que atue depois da geração:

A regra geral é simples: nunca trate a saída de um LLM como verdade automática em fluxos de alto risco. Trate-a como uma proposta a ser verificada.

Como funciona um guardrail na prática

Um guardrail é uma barreira automática colocada entre a geração e o usuário. Em pseudocódigo, um verificador de fundamentação pode parecer com isto:

def resposta_fundamentada(resposta, trechos):
    # 1) cada afirmação tem suporte nos trechos?
    afirmacoes = extrair_afirmacoes(resposta)
    for a in afirmacoes:
        if not encontra_suporte(a, trechos):
            return rejeitar(motivo=f"sem fonte para: {a}")

    # 2) o formato bate com o esperado?
    if not formato_valido(resposta):
        return rejeitar(motivo="formato inválido")

    return aceitar(resposta)

O ponto importante é que o guardrail é determinístico e independente do modelo que gerou o texto. Ele não confia na boa vontade do LLM; ele verifica. Quando a checagem falha, o sistema pode tentar de novo com um prompt mais restritivo, recuperar mais contexto, ou escalar para um humano — nunca simplesmente entregar a saída suspeita.

Self-consistency e amostragem

Outra técnica de verificação é gerar a mesma resposta várias vezes e comparar. Se o modelo produz respostas divergentes para a mesma pergunta factual, isso é sinal de baixa confiança real. Para perguntas com resposta única e verificável, a resposta que aparece com mais frequência entre as amostras costuma ser a mais confiável. Essa estratégia custa mais tokens, mas é valiosa em pontos críticos do fluxo.

Medir antes de confiar

Você não consegue reduzir o que não mede. Para saber se suas mitigações funcionam, é preciso avaliar a taxa de alucinação de forma sistemática — montar um conjunto de perguntas com respostas conhecidas, rodar o sistema e medir quantas saídas são fiéis às fontes. Esse trabalho de avaliação é o tema de Como avaliar aplicações de LLM (LLM evals).

Sem evals, "melhorar a confiabilidade" vira achismo. Com evals, você compara versões de prompt, modelos e estratégias de RAG por número, e descobre se aquela mudança realmente reduziu invenções ou só pareceu reduzir.

O que medir, concretamente

Algumas métricas úteis para acompanhar:

Esses números transformam discussões subjetivas ("achei que ficou melhor") em comparações objetivas entre versões. E permitem definir um limiar de aceitação: abaixo de tal taxa de fidelidade, a versão não vai para produção.

Uma estratégia em camadas

Não existe bala de prata. Na prática, sistemas confiáveis combinam várias defesas:

Cada camada reduz a probabilidade de uma alucinação chegar ao usuário. Juntas, elas transformam um modelo intrinsecamente "criativo demais" em um componente que se pode operar com responsabilidade.

Adequando o rigor ao risco

Nem todo sistema precisa de todas as camadas. Um assistente de brainstorming, onde invenções até ajudam, dispensa guardrails pesados. Já um assistente que responde sobre dosagem de medicamentos exige fundamentação obrigatória, verificação por fonte e revisão humana. O bom design começa por classificar o custo de um erro: quanto maior o dano de uma alucinação chegar ao usuário, mais camadas você adiciona. Aplicar o mesmo rigor extremo a tudo encarece o produto sem retorno; aplicar rigor de menos onde o erro custa caro é negligência.

Perguntas frequentes

Dá para eliminar a alucinação por completo? Não, dado o estado atual da tecnologia. Alucinação é consequência de como LLMs funcionam. O objetivo realista é reduzi-la a níveis aceitáveis para o caso de uso e conter o que escapa.

Um modelo maior alucina menos? Em geral, modelos maiores e mais recentes alucinam menos em temas comuns, mas continuam alucinando em temas raros, recentes ou muito específicos. Tamanho ajuda, mas não substitui fundamentação e verificação.

Aumentar a temperatura piora a alucinação? Temperatura mais alta aumenta a aleatoriedade da geração, o que tende a aumentar invenções em tarefas factuais. Para respostas que exigem precisão, temperatura baixa é mais segura; para tarefas criativas, temperatura alta é desejável.

RAG sozinho resolve? Reduz muito a alucinação extrínseca, mas não elimina. RAG mal calibrado pode recuperar trechos errados ou ser ignorado pelo modelo. Por isso ele anda junto com prompts defensivos, verificação e evals.

Como sei se meu sistema melhorou? Medindo. Sem um conjunto de avaliação com respostas conhecidas, qualquer julgamento sobre confiabilidade é impressão. Com evals, a melhoria vira número comparável entre versões.

Conclusão

Alucinação não é um defeito acidental dos LLMs — é o reflexo de modelos que otimizam fluência, não verdade. Por isso, o objetivo realista é reduzir e conter, não eliminar. As ferramentas existem e funcionam: fundamentar respostas com RAG, escrever prompts que permitem dizer "não sei", verificar saídas programaticamente, manter humanos no loop em domínios sensíveis e, acima de tudo, medir a confiabilidade com evals. Adeque o rigor ao risco: quanto maior o custo de um erro, mais camadas de defesa. Construir com IA de forma séria é, em boa parte, construir as camadas de defesa que cercam essa tendência a inventar.

Referências