Alucinação de IA: por que acontece e o que grounding resolve

O modelo não mentiu. Ele completou.

A diferença entre as duas coisas é o que separa demo de produto.

Você abre o ticket, olha o log, e lá está: o agente inventou um número de pedido que nunca existiu. Com confiança. Com formatação bonita. Com um tom que passaria em qualquer review de copy. E o cliente pagante do outro lado acreditou.

Alucinação de IA não é bug do modelo. É ausência de amarra. E a reação padrão — culpar o modelo, trocar de provider, baixar a temperatura, pedir "por favor não invente" — não resolve nada, porque o diagnóstico está errado.

Neste post você vai ver por que o nome "alucinação" atrapalha o diagnóstico, quais técnicas prendem a resposta no dado que é seu, como validar em tempo real em vez de rezar dentro de um try/catch, e o que ainda vai escapar mesmo depois de tudo isso.

TL;DR

O que é: alucinação é o modelo completando texto plausível quando não tem onde se segurar. Comportamento estatístico esperado, não defeito.
O que resolve: grounding (prender no seu dado), structured output com schema estrito, validação em tempo real e citação de fonte verificada.
O que não resolve: trocar de modelo, baixar temperatura, pedir "não invente" no prompt.
Fonte-base: Why Language Models Hallucinate — Kalai, Nachum, Vempala e Zhang (OpenAI + Georgia Tech), setembro de 2025.

Por que "alucinação de IA" é o nome errado do problema

"Alucinação" sugere delírio. Sugere que o modelo teve um surto, viu coisa onde não tinha, saiu do prumo. O nome é ruim porque implica que existe um estado "são" pra onde voltar.

Não existe.

O que acontece é mais chato e muito mais útil de entender: o modelo é um completador. Ele estima o próximo token. Quando a informação que você pediu não está no contexto e não está firme nos pesos, ele não tem um botão de "faltou dado". Ele completa com o que é estatisticamente plausível.

O paper Why Language Models Hallucinate, publicado em setembro de 2025, coloca isso de forma direta: alucinações "originam-se simplesmente como erros de classificação binária". Se afirmação incorreta não é distinguível de fato durante o pré-treino, a pressão estatística natural produz alucinação. Não é mistério. É a matemática funcionando como projetada.

E tem a parte que dói mais. Os autores mostram que a alucinação persiste porque a gente premia o chute:

Language models are optimized to be good test-takers, and guessing when uncertain improves test performance.

Modelo é bom aluno de prova. Em prova de múltipla escolha, chutar tem valor esperado positivo e responder "não sei" vale zero. Os benchmarks que dominam os leaderboards funcionam exatamente assim. O modelo aprendeu a nunca deixar questão em branco porque a gente ensinou ele a nunca deixar questão em branco. Tanto que a mitigação proposta no paper não é um eval novo de alucinação: é mudar o scoring dos benchmarks que já existem.

Repara no que isso muda do seu lado. Se a alucinação nasce de ausência de amarra e de incentivo a chutar, o conserto não está no modelo. Está na arquitetura em volta dele: o que entra no contexto, o formato que você força na saída, e o que você verifica antes de mostrar pro usuário. Isso é engenharia de sistema, não engenharia de prompt. É exatamente essa camada que a gente monta ao vivo no AI Engineering Lab 3ª Edição, nos dias 19 e 20 de setembro, com grounding, tracing, evals e custo em cima de um sistema de pé na tela.

Grounding: prender a resposta no dado que é seu

Grounding é uma ideia simples: a resposta do modelo tem que depender de uma fonte de verdade que você controla, não da memória dele.

A fonte pode ser um documento recuperado, o retorno de uma tool, uma linha do seu banco, o texto de uma política interna. O ponto não é de onde vem. É que exista, que esteja no contexto, e que a instrução deixe explícito que fora dali não vale.

Três amarras resolvem a maior parte dos casos.

1. Restrição explícita de conhecimento externo. A documentação da Anthropic sobre reduzir alucinações é direta: instrua o modelo a usar somente as informações dos documentos fornecidos, não o conhecimento geral. Parece óbvio. Quase ninguém escreve isso no prompt.

2. Permissão para não saber. Mesma doc, e é a técnica de maior retorno por linha de prompt: dar permissão explícita para o modelo admitir incerteza. Lembra do paper? Ele aprendeu que "não sei" vale zero ponto. No seu sistema, "não sei" vale muito mais do que resposta errada — mas você precisa dizer isso em algum lugar.

Responda usando apenas o conteúdo entre <documentos>.
Se a informação necessária não estiver ali, responda exatamente:
"Não encontrei essa informação nos documentos disponíveis."
Não complete com conhecimento geral.

3. Extração de citação literal antes da resposta. Para documentos longos, a recomendação é inverter a ordem: peça as citações literais primeiro, depois a análise em cima delas. Você força o modelo a passar pelo texto real antes de raciocinar, em vez de raciocinar e depois procurar respaldo.

E o RAG, onde entra nisso? Como uma das amarras — a que resolve o caso específico "o dado é grande demais pro contexto e muda com frequência". RAG é o mecanismo de recuperação. Grounding é a propriedade que você quer. Dá pra ter grounding sem RAG (uma tool call num endpoint, uma query no banco) e dá pra ter RAG sem grounding nenhum: recupera cinco chunks, ignora os cinco e responde de cabeça. Se essa base ainda não está firme, o que é RAG cobre o funcionamento, e seu RAG não funciona? as causas reais cobre o que quebra na prática.

Validação em tempo real vs. rezar no try/catch

Grounding aumenta a chance da resposta ser certa. Não garante formato, e não garante que o conteúdo bate com a fonte.

É aqui que a maioria dos sistemas em produção tem um try/catch em volta de um json_decode e uma prece. Funciona até o dia em que o modelo devolve o JSON com uma vírgula sobrando, ou manda status como string livre quando o seu enum esperava um de três valores.

Duas camadas resolvem isso, e elas são bem diferentes entre si.

Camada 1: garantia de formato na decodificação

Structured output com schema estrito não é "pedir bonitinho pro modelo devolver JSON". Com strict: true, a OpenAI compila o seu JSON Schema em uma gramática livre de contexto e, a cada token gerado, mascara qualquer token que violaria o schema. O modelo literalmente não consegue emitir saída fora do formato. Nos evals da OpenAI, isso deu 100% de aderência ao schema.

Repara na diferença: JSON mode promete JSON sintaticamente válido. Structured output estrito promete o seu schema — campos presentes, tipos certos, enums respeitados. É garantia de parser, não de sorte.

response = client.chat.completions.create(
    model="gpt-5",
    messages=[...],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "resposta_suporte",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "resposta": {"type": "string"},
                    "encontrou_no_contexto": {"type": "boolean"},
                    "trechos_usados": {
                        "type": "array",
                        "items": {"type": "string"},
                    },
                },
                "required": [
                    "resposta",
                    "encontrou_no_contexto",
                    "trechos_usados",
                ],
                "additionalProperties": False,
            },
        },
    },
)

Olha o campo encontrou_no_contexto. Ele existe pra te dar um sinal binário barato: quando vier false, você nem renderiza a resposta — dispara o fallback. Formato garantido te dá onde pendurar decisão de produto.

Camada 2: verificação de conteúdo antes de entregar

Formato certo com conteúdo inventado continua sendo problema.

A métrica que fecha esse buraco é faithfulness: quebra a resposta em afirmações atômicas e checa, uma a uma, se o contexto recuperado sustenta cada uma. O score é a fração sustentada. É o que frameworks como o RAGAS calculam, e o que times que rodam eval em produção usam como gate — resposta abaixo do limiar não sai da API, vai pro caminho de fallback.

O ponto de arquitetura aqui é o quando. Isso roda antes da resposta chegar no usuário, não num dashboard que alguém abre na segunda-feira. Um verificador barato — modelo pequeno, prompt curto, só "esta afirmação está sustentada por este trecho? sim ou não" — cabe no orçamento de latência da maioria dos produtos.

E o mesmo dataset serve no CI. Se você quer o caminho de eval contínuo antes do deploy, tem um post inteiro sobre montar esse pipeline.

▪ Clã Beer and Code

Não só acompanhe as novidades — domine. Engenharia de IA na prática, ao vivo, toda semana, na maior comunidade do Brasil.

Entrar no Clã

Citação de fonte: o padrão que corta reclamação de cliente

Citação faz duas coisas ao mesmo tempo, e a segunda é a que importa pro negócio.

A primeira: melhora a resposta. Quando o modelo precisa apontar de onde tirou cada afirmação, ele passa pelo texto em vez de completar pela memória.

A segunda: transfere a auditoria pro usuário. O cliente que desconfia clica na fonte e resolve sozinho. Isso muda o custo do erro. Sem citação, erro vira ticket. Com citação, erro vira o usuário percebendo em dois segundos que aquele trecho não responde a pergunta dele.

E dá pra medir. A Anthropic reporta que a Endex, ao trocar citação feita na unha por citações nativas da API, levou alucinação de fonte e problema de formatação de 10% para 0%, com 20% mais referências por resposta. Nas avaliações internas da Anthropic, citação nativa supera implementação custom em até 15% de acurácia de recall. O mecanismo é chato de propósito: a API quebra o documento em sentenças e devolve o cited_text, o trecho literal — não um número de página que o modelo achou plausível.

Aí vem a pegadinha, e ela é grande: citação existir não prova que a citação sustenta a afirmação. Trabalho recente sobre citation grounding avaliou cinco sistemas e encontrou de 13% a 21% de citações alucinadas. Aponta pro documento certo, cai no parágrafo adjacente, não sustenta a claim.

Então o padrão completo tem três passos, e o terceiro é o que quase todo mundo pula:

O modelo emite a citação.
Você valida programaticamente que cada referência aponta pra uma fonte que você realmente enviou no contexto, e remove as que não apontam.
Você verifica que o trecho citado contém a afirmação. Aqui entra o verificador barato de novo.

O passo 2 é dez linhas de código e pega a referência fabricada. O passo 3 é uma chamada de modelo pequeno e pega a citação que existe mas não sustenta. Sem os dois, você tem citação decorativa.

O que ainda vai escapar (e como falhar de forma segura)

Nada disso zera. Quem promete zero está vendendo.

O estudo do RegLab de Stanford é o melhor lembrete disponível. Ferramentas comerciais de pesquisa jurídica construídas por Thomson Reuters e LexisNexis, com RAG, com citação, com décadas de dado proprietário estruturado e vendidas como "hallucination-free", erraram ou responderam com grounding incorreto entre 17% e 33% das consultas num teste preregistrado com 202 queries avaliadas por especialistas.

Empresa grande. Dado proprietário. Time sério. E ainda assim.

Então o critério pra botar o sistema na frente de cliente pagante não é "não alucina". São quatro outros.

Você sabe quando não sabe. Um sinal explícito de "não encontrei" no schema, com fallback definido, vale mais que dez pontos de acurácia média.

O erro tem teto. Escreva o que o sistema faz sozinho e o que exige humano. Responder dúvida sobre horário de funcionamento: automático. Emitir valor de multa contratual: rascunho com aprovação. A régua é o custo do erro, não a confiança aparente do modelo.

O erro é rastreável. Trace com o contexto recuperado, o prompt final, a saída bruta e o resultado do verificador. Sem isso, quando o cliente reclamar, você vai debugar por adivinhação.

O erro é medido. Um dataset de casos reais rodando a cada mudança. Todo ajuste de prompt e toda troca de modelo é deploy sem teste até você ter isso.

Falhar de forma segura é decisão de produto tomada no código. Não é efeito colateral de um prompt bem escrito.

FAQ rápido

Baixar a temperatura para 0 resolve alucinação de IA? Não. Temperatura 0 torna a saída determinística, não verdadeira. Se falta amarra no dado real, o modelo completa com a mesma invenção, sempre igual. Você troca erro aleatório por erro reprodutível — o que ajuda a debugar, mas não conserta nada.

Modelo maior alucina menos? Menos na média, e não o suficiente pra você parar de amarrar. O paper da OpenAI mostra que a raiz está no objetivo de treino e no jeito que os benchmarks pontuam, e nenhum dos dois é resolvido por escala. Modelo melhor sobe o piso. A arquitetura em volta é que define o teto.

Se meu RAG está bom, ainda preciso de validação? Precisa. RAG entrega o contexto certo. Nada nele garante que o modelo usou aquele contexto. Faithfulness mede exatamente o buraco entre "o trecho certo estava lá" e "a resposta se apoia nele".

Quanto custa em latência colocar verificação em tempo real? Depende do que você verifica. Validar referência contra as fontes enviadas é código puro, custo zero. Verificar sustentação de claim com um modelo pequeno costuma custar centenas de milissegundos e uma fração do preço da chamada principal, e você pode rodar só nas respostas que o schema marcou como sensíveis.

Conclusão

Alucinação de IA não é falha moral do modelo. É o comportamento esperado de um completador que não tem onde se segurar, treinado num regime que premia chute.

O conserto é arquitetura, em camadas. Grounding prende a resposta no seu dado. Structured output com schema estrito garante saída parseável e cria onde pendurar decisão. Validação em tempo real derruba o que não se sustenta antes de sair. Citação verificada transfere a auditoria pro usuário.

Nenhuma dessas camadas é opcional se o sistema vai encostar em cliente pagante. E nenhuma delas te entrega zero. O que elas entregam é a coisa que realmente importa: um sistema que erra dentro de um limite que você escolheu, avisa quando não sabe, e deixa rastro pra você consertar.

Se o que você precisa agora é o recorte de produto — quanto custa o erro, como priorizar onde amarrar primeiro — por que a IA alucina e como reduzir alucinação no seu produto cobre esse lado. Este aqui foi sobre a arquitetura que segura a resposta.

Prompt bonito não faz isso. Engenharia faz.