Alucinações

O que são “alucinações” em LLMs?

No contexto de modelos de linguagem grandes (large language models, LLMs), uma alucinação é uma saída que é fluente e soa plausível, mas não é sustentada pela entrada do modelo, por suas ferramentas ou por conhecimento confiável sobre o mundo. Alucinações frequentemente aparecem como afirmações confiantes, detalhes fabricados, citações incorretas ou ações inventadas.

Alucinações importam porque LLMs são otimizados para produzir texto provável, e não para garantir afirmações verdadeiras. Mesmo quando um modelo “sabe” algo, ele ainda pode produzir uma continuação incorreta se o prompt, o contexto ou a decodificação o empurrarem para uma alternativa que pareça mais provável.

É útil distinguir alucinações de fenômenos relacionados:

Erros comuns: Um erro simples (por exemplo, aritmética) pode ser uma alucinação se o modelo inventar um resultado com confiança e sem suporte, mas algumas comunidades reservam “alucinação” para fabricação sem suporte em vez de qualquer resposta errada.
Escrita criativa: Inventar detalhes em ficção não é uma alucinação se a tarefa permite imaginação.
Decepção ou mentira: A maioria das alucinações de LLMs não é intencional; elas surgem da geração probabilística de texto e do desalinhamento de objetivos, não de agência.
Recusas e incerteza: Um sistema ideal às vezes diz “Eu não sei” quando falta evidência. Alucinações frequentemente são o modo de falha quando ele não faz isso.

LLMs geralmente são construídos sobre a Arquitetura Transformer e treinados com um objetivo de previsão do próximo token (next-token prediction). Essa base explica muitos comportamentos de alucinação discutidos abaixo.

Tipos de alucinações

Existem diferentes taxonomias; as mais práticas categorizam alucinações pelo que é fabricado e de onde vem o erro.

Alucinações factuais (intrínsecas vs extrínsecas)

Uma divisão comum é:

Alucinação intrínseca: O modelo contradiz o contexto fornecido.
Alucinação extrínseca: O modelo adiciona detalhes que não estão presentes no contexto (que podem ser verdadeiros ou falsos, mas são sem suporte).

Exemplo (intrínseca):

Contexto: “O estudo incluiu 120 participantes.”
Modelo: “O ensaio randomizado recrutou 1.200 participantes…”

Exemplo (extrínseca):

Contexto: “Ada Lovelace escreveu notas sobre a Máquina Analítica.”
Modelo: “Ela as publicou na Nature em 1843…”

Mesmo que a adição extrínseca por acaso seja verdadeira, ela é arriscada em sistemas que exigem fundamentação rastreável.

Alucinações de citação e atribuição

LLMs frequentemente geram:

Artigos, URLs, casos judiciais ou citações inexistentes
Citações que parecem reais, mas com autores/anos errados
Fontes corretas, porém com alegações incorretas atribuídas a elas

Exemplo:

“De acordo com Smith et al. (2021) no The New England Journal of AI, …”

Isso é comum quando um prompt solicita “forneça referências”, mas o modelo não tem acesso a recuperação (retrieval) ou a restrições fortes.

Alucinações de raciocínio (passos inválidos que parecem coerentes)

Modelos podem produzir cadeias de raciocínio plausíveis, porém inválidas, especialmente em tarefas de múltiplas etapas (matemática, lógica, explicações causais).

Exemplo (lógica):

“Como todos os mamíferos põem ovos, golfinhos põem ovos…”
(O modelo inventou uma premissa falsa para sustentar a conclusão.)

Isso pode ocorrer mesmo quando a resposta final está correta — a explicação ainda pode ser fabricada. (Veja também Técnicas de Cadeia de Pensamento & Raciocínio para como elicitar raciocínio interage com confiabilidade.)

Alucinações de ferramenta/ação

Em sistemas aumentados por ferramentas, um modelo pode alucinar:

Que chamou uma ferramenta quando não chamou
Um resultado de ferramenta (por exemplo, “A API retornou 42”) sem de fato invocar a API
Efeitos colaterais (e-mails enviados, tickets criados) que nunca aconteceram

Exemplo:

“Eu já redefini sua senha e enviei a confirmação por e-mail.”
(Nenhuma chamada de ferramenta ocorreu.)

Isso é particularmente importante em LLMs com Uso de Ferramentas, onde o sistema deve tratar resultados de ferramentas como autoritativos e o texto do modelo como não confiável, a menos que seja verificado.

Alucinações de instrução e política

O modelo pode fabricar restrições ou permissões, por exemplo:

“Não tenho permissão para discutir o tópico X” (quando tem)
“A política da sua organização diz…” (quando não há tal política no contexto)
Distorcer regras de segurança ou capacidades do produto

Isso se sobrepõe a falhas discutidas em Seguimento de Instruções e Mitigações de Segurança.

Alucinações conversacionais/de persona

O modelo inventa experiências pessoais, identidades ou acessos:

“Quando eu trabalhei no Hospital Y…”
“Eu examinei seus arquivos privados e…”

Sistemas bem alinhados tentam evitar isso, mas ainda pode aparecer dependendo do prompting e do treinamento.

Alucinações de código

Na geração de código, alucinações incluem:

Inventar APIs ou funções de bibliotecas
Usar nomes corretos com assinaturas erradas
Afirmar que o código foi executado ou testado
Retornar código que não compila em lugar nenhum, mas parece plausível

Exemplo:

# Hallucinated: requests.parse_json does not exist
data = requests.parse_json(response)

Alucinações de código são especialmente comuns sob prompts de pressão de tempo (“rapidamente escreva…”) ou quando o modelo é solicitado a usar bibliotecas desconhecidas (veja Modelos de Código).

Alucinações multimodais (modelos visão-linguagem)

Quando modelos interpretam imagens, eles podem descrever com confiança objetos que não estão presentes, ler texto incorretamente ou inferir contexto errado. Esses erros frequentemente se parecem com “completar padrões” (pattern completion) em vez de percepção cuidadosa.

Por que alucinações ocorrem

Alucinações não são um único bug; elas emergem de múltiplas causas interagindo entre treinamento, inferência e design do sistema.

Desalinhamento de objetivo: previsão do próximo token não é otimização da verdade

O pré-treinamento (pretraining) tipicamente otimiza:

Maximizar a verossimilhança do próximo token dados os tokens anteriores

Isso ensina fortes priors linguísticos e de conhecimento do mundo, mas não impõe explicitamente:

Correção factual
Fundamentação (grounding) no contexto fornecido
Atribuição de fontes
Incerteza calibrada

Assim, quando múltiplas continuações são plausíveis, o modelo tende a escolher o que é linguisticamente provável, e não o que é verificavelmente sustentado.

Isso é fundamental para como LLMs são treinados (veja Pré-treinamento & Leis de Escala).

O modelo é um compressor com perda dos seus dados de treinamento

LLMs armazenam “conhecimento” nos parâmetros de forma distribuída e aproximada. Eles não recuperam registros exatos a menos que sejam aumentados com recuperação. Isso leva a:

Fatos misturados (mistura de entidades semelhantes)
Datas, nomes e números ligeiramente errados
Supergeneralização a partir de padrões comuns

Ruído e ambiguidade nos dados de treinamento

Corpora em escala web contêm:

Páginas desatualizadas
Alegações conflitantes
Ficção apresentada como fato
Erros duplicados ou parafraseados

Mesmo com filtragem, modelos aprendem algumas associações espúrias que podem emergir como alucinações.

Confiança mal calibrada (e o papel do alinhamento)

Ajuste por instruções (instruction-tuning) e otimização por preferências (preference optimization) (por exemplo, RLHF/DPO) empurram modelos para serem:

Prestativos
Fluentes
Responsivos

Mas “prestativo” pode se tornar “sempre responder”, reduzindo a disposição de dizer “Eu não sei.” Isso pode piorar alucinações se não for equilibrado com calibração e comportamentos de abstenção (abstention) (veja Alinhamento e Métodos de Otimização por Preferências).

A decodificação amplifica continuações plausíveis

Na inferência, o modelo usa uma estratégia de decodificação (temperatura, top-p, beam search, etc.). A amostragem aumenta a diversidade, mas pode aumentar a taxa de alucinações; uma decodificação excessivamente gulosa também pode travar em um caminho errado.

Isso é uma alavanca central discutida em Estratégias de Decodificação.

Limitações de contexto e competição de atenção

Mesmo com contextos longos, modelos podem:

Perder detalhes relevantes (efeitos de “perdido no meio”)
Dar peso excessivo a tokens recentes ou salientes
Sofrer com instruções truncadas ou documentos ausentes

Isso se conecta a Janelas de Contexto. Quando a evidência necessária está ausente ou recebe pouca atenção, o modelo pode preencher lacunas com priors.

Prompts subespecificados e pressão conversacional

Se um usuário pergunta:

“Me dê a receita exata da empresa X no último trimestre e cite fontes.”

…mas nenhuma fonte é fornecida e a recuperação não está disponível, o modelo enfrenta um dilema. Muitos modelos ainda tentarão cumprir, produzindo números e citações fabricados porque o prompt exige especificidade.

Mudança de distribuição e consultas fora de domínio

Quando perguntado sobre domínios de nicho, eventos novos, dados proprietários ou contexto local/não inglês ausente no treinamento, o modelo ainda pode gerar respostas confiantes — especialmente se a pergunta se parecer com templates comuns.

Falhas no pipeline de ferramentas e recuperação (alucinações em nível de sistema)

Em sistemas com recuperação (RAG) ou ferramentas, alucinações podem surgir de:

Recuperação ruim (documentos irrelevantes)
Recuperação ausente (nenhum doc retornado)
Erros de ferramenta (timeouts, resultados parciais)
Modelo ignorando evidências (respondendo a partir da memória paramétrica de qualquer forma)

Essas não são puramente “alucinações do modelo”, mas alucinações do sistema — o usuário final vê a saída incorreta de qualquer maneira.

Estratégias de mitigação (das mais fáceis às mais fortes)

Nenhuma técnica única elimina alucinações. Na prática, sistemas robustos usam mitigações em camadas: restrições de prompt, fundamentação, verificação e monitoramento.

Prompting e design de interação

Prompting não pode garantir verdade, mas pode reduzir alucinações evitáveis.

Padrões eficazes:

Permitir abstenção e exigir sinalização de incerteza
Fazer perguntas de esclarecimento quando faltam entradas
Exigir citar apenas o contexto fornecido
Forçar separação entre “resposta” vs “evidência”

Exemplo de trecho de prompt:

If the answer is not directly supported by the provided context, say:
"I don't know based on the given information."

When you answer, quote the exact sentence(s) from the context that support each claim.
Do not use outside knowledge.

Para sistemas voltados ao usuário, UX importa:

Exibir “Resposta baseada nas fontes fornecidas” vs “Conhecimento geral do modelo”
Fornecer citações clicáveis (e validá-las)
Oferecer um painel de “mostrar evidências” para que usuários possam verificar

Prompting é especialmente eficaz quando combinado com Aprendizado no Contexto por meio de exemplos de boas abstenções.

Controles de decodificação

Ajustes de decodificação podem reduzir “preenchimento criativo”:

Reduzir temperatura
Reduzir top-p / top-k (amostragem mais conservadora)
Usar beam search com cuidado (pode reforçar hipóteses erradas se a massa de probabilidade do modelo estiver enviesada)

Para saídas estruturadas, decodificação restrita (constrained decoding) (por exemplo, esquema JSON, restrições tipo regex) pode evitar alucinações de formato (não alucinações factuais), o que ainda é valioso operacionalmente.

Exemplo (ideia de saída orientada por esquema):

{
  "claim": "string",
  "supporting_quotes": ["string"],
  "source_ids": ["string"],
  "confidence": "low|medium|high"
}

Geração Aumentada por Recuperação (RAG) e fundamentação

Para tarefas com muito conhecimento, a maior mudança é fundamentar respostas em documentos recuperados em vez de na memória paramétrica.

Um loop típico de RAG:

query = user_question
docs = retrieve_top_k(query, k=5)  # search index / vector DB
prompt = render_prompt(question=query, context=docs)
draft = llm(prompt)

# Optional: verify that draft quotes exist in docs, else regenerate/abstain
final = verify_or_rewrite(draft, docs)
return final

Detalhes de engenharia que afetam fortemente alucinações:

Qualidade de recuperação: bons embeddings, busca híbrida, índices específicos de domínio
Estratégia de chunking: chunks pequenos demais perdem contexto; grandes demais diluem relevância
Imposição de citação: exigir aspas e IDs de documento
Prompting centrado em evidências: instruir o modelo a responder apenas a partir do contexto
Comportamento de fallback: quando a recuperação estiver vazia ou com baixa confiança, abster-se ou pedir mais informações

RAG reduz alucinações principalmente quando o sistema de fato impõe fundamentação, e não apenas “fornece contexto e espera que o modelo use”.

Uso de ferramentas para computação e ações verificáveis

Use ferramentas para operações nas quais o modelo é fraco ou não pode executar com segurança “na cabeça”:

Cálculos (calculadora)
Consultas a banco de dados
Hora/tempo/preços atuais
Checagens de política
Criação de ticket / envio de e-mail (com confirmações)

Um padrão robusto de uso de ferramentas é:

O modelo propõe uma chamada de ferramenta
O sistema executa a ferramenta
O modelo resume com base na saída da ferramenta
O sistema bloqueia qualquer alegação de sucesso, a menos que a ferramenta confirme

Isso é central em LLMs com Uso de Ferramentas. Considere também confirmação em duas etapas para ações:

“Estou prestes a redefinir a senha da conta X. Confirmar?”

Verificação pós-geração (auto-checagem e checagem cruzada)

A verificação pode ser feita por:

Checagens baseadas em regras: validar que citações existem; URLs resolvem; texto citado corresponde
Checagens com modelo secundário: pedir a outro modelo (ou ao mesmo modelo com um prompt diferente) que verifique alegações contra fontes
Múltiplas amostras + votação: gerar múltiplas respostas e selecionar a melhor sustentada (caro; ainda pode convergir para a mesma crença errada)
Verificadores externos de fatos: bases de conhecimento, dados estruturados ou classificadores especializados

Isso se relaciona a escalonamento em tempo de inferência em Computação em Tempo de Teste: gastar mais computação para verificar pode reduzir alucinações, mas apenas se o verificador tiver acesso à verdade fundamental (documentos/ferramentas). A auto-verificação apenas com LLM é imperfeita porque o verificador compartilha pontos cegos semelhantes.

Exemplo prático de verificação: checagem de citações

Exigir que cada parágrafo inclua ao menos uma citação
Garantir que cada citação corresponda a um documento recuperado
Garantir que cada trecho citado realmente apareça no texto do documento
Se qualquer checagem falhar, regenerar com instruções mais estritas ou abster-se

Ajuste fino e otimização por preferências para factualidade

Quando você controla o treinamento, pode reduzir alucinações ensinando comportamentos como:

Abster-se quando falta evidência
Preferir respostas fundamentadas com citações
Penalizar citações fabricadas
Produzir incerteza calibrada

Abordagens incluem:

Ajuste fino supervisionado em QA fundamentado e exemplos de recusa (Ajuste Fino)
Otimização por preferências que ranqueia respostas fundamentadas e cautelosas acima de fabricações confiantes (Métodos de Otimização por Preferências)
Adaptação de domínio para que o modelo se alinhe melhor à sua terminologia e documentos (reduzindo chutes fora de domínio)

O treinamento ajuda, mas não substitui recuperação e verificação quando a correção é crítica.

Monitoramento, avaliação e guardrails operacionais

Mitigação é incompleta sem medição. Táticas comuns de avaliação:

Benchmarks de factualidade adaptados ao seu domínio
Testes de atribuição em RAG: o modelo consegue responder e citar o chunk correto?
Prompts adversariais: perguntas ambíguas, casos de contexto ausente, armadilhas de citação
Revisão humana para saídas de alto risco
Telemetria: acompanhar taxa de abstenção, taxa de validade de citações, erros reportados por usuários

Guardrails em produção:

Limiares de confiança que encaminham para revisão humana
Fallbacks de “sem resposta” para recuperação vazia
Registro de chamadas de ferramentas e documentos-fonte para auditorias

Orientação prática por aplicação

Suporte ao cliente e assistentes corporativos

Use RAG sobre bases de conhecimento aprovadas; desative respostas estilo “web geral” a menos que explicitamente solicitado.
Imponha “responder apenas a partir das fontes” para perguntas de política.
Encaminhe casos incertos ou com baixa recuperação para um agente humano.

Análise de dados e relatórios

Nunca permita que o modelo invente números. Force todas as métricas a virem de ferramentas/consultas.
Exija que o modelo produza os resultados de SQL/chamada de ferramenta junto com explicações.
Valide totais e unidades automaticamente.

Geração de código

Incentive o modelo a referenciar a documentação oficial quando disponível, ou forneça as assinaturas de API no contexto.
Adicione compilação/testes no loop; trate a saída do modelo como um rascunho até que os testes passem.
Fixe versões de bibliotecas; muitas “alucinações de API” são incompatibilidades de versão.

Domínios de alto risco (médico, jurídico, finanças)

Use fundamentação e verificação estritas; prefira resumos extrativos em vez de respostas livres.
Forneça limitações explícitas de escopo e exija citações.
Aplique camadas adicionais de segurança (veja Mitigações de Segurança) e supervisão humana.

Trade-offs e equívocos comuns

“Temperatura mais baixa corrige alucinações.” Reduz aleatoriedade, mas não garante verdade; um modelo pode produzir deterministicamente a mesma alegação errada.
“Citações garantem correção.” Modelos podem alucinar citações ou atribuir alegações incorretamente; citações devem ser validadas contra o texto recuperado.
“Modelos maiores não alucinam.” Escala ajuda em muitos regimes, mas alucinações persistem — especialmente para fatos de nicho, eventos recentes e contexto ausente.
“Se soa confiante, deve ser verdade.” Fluência não é evidência. Alucinações frequentemente são mais perigosas quando mais eloquentes.
Abstenção vs utilidade: Sistemas que se abstêm mais alucinam menos, mas podem frustrar usuários. Bons designs equilibram prestatividade com incerteza calibrada.

Resumo

Alucinações são um resultado previsível de como LLMs são treinados e decodificados: eles geram texto plausível, não verdade garantida. Alucinações aparecem em múltiplas formas — fabricação factual, citações falsas, raciocínio inválido, relatos incorretos de ferramenta/ação e invenções de código/API — e são amplificadas por contexto ausente, confiança mal calibrada e fundamentação fraca.

Uma mitigação eficaz é em camadas:

Padrões de prompt e UX que permitam abstenção e exijam evidências
Decodificação conservadora quando apropriado
Fundamentação por recuperação/ferramentas com imposição, não apenas “contexto útil”
Etapas de verificação (checagem de citações, confirmação de ferramenta, checagem de fatos)
Ajuste fino e otimização por preferências que recompensem comportamento fundamentado
Avaliação e monitoramento contínuos em produção

Projetar para confiabilidade significa tratar o modelo como um gerador poderoso que precisa ser fundamentado, checado e auditado — especialmente onde a correção importa.