Alucinação de IA: por que acontece e como barrar os erros

Um bot de atendimento não deveria inventar uma exceção à política da empresa. Um assistente de relatórios não deveria improvisar um total. Um agente — software que usa um modelo para escolher ações e chamar ferramentas — não deveria adivinhar qual cadastro de cliente alterar. O objetivo prático é impedir que uma resposta ou ação sem respaldo saia da sua aplicação.

Verificado em 17 de outubro de 2026 com base nas orientações dos desenvolvedores dos modelos, na documentação das APIs, nos exemplos de pesquisa e na decisão judicial citados nos links. Os exemplos abaixo são observações atribuídas às respectivas fontes; o validador e o roteiro semanal são recomendações de implementação, não resultados obtidos em produção.

O que é alucinação de IA em LLMs e por que ela acontece?

Uma alucinação de um LLM é uma afirmação falsa ou sem respaldo apresentada como resposta. LLM é a sigla em inglês para grande modelo de linguagem: um modelo treinado para gerar linguagem a partir de padrões em textos. Uma afirmação também pode não ter respaldo nos documentos que você forneceu, mesmo que seja verdadeira em outro contexto.

Pense no modelo como um redator experiente que completa um relatório com os materiais que tem sobre a mesa. Ele consegue escrever um parágrafo convincente para preencher uma lacuna. Isso não significa que o conteúdo desse parágrafo faça parte dos registros da sua empresa.

Prever um texto plausível não é conferir um fato

O artigo de pesquisa da OpenAI sobre por que modelos de linguagem alucinam, publicado em 5 de setembro de 2025, explica que o pré-treinamento ensina a prever texto sem que cada afirmação venha marcada como verdadeira ou falsa. Fatos raros e arbitrários são especialmente difíceis de recuperar a partir de padrões. Etapas posteriores de treinamento melhoram o comportamento, mas a fluência não se transforma em garantia de veracidade.

Para quem desenvolve, a consequência é direta: políticas de produto, situação de contas e estoque precisam estar em fontes oficiais que a aplicação consiga consultar. Tratar a resposta que o modelo guarda na memória como se fosse o banco de dados abre espaço para uma falha evitável.

Contexto ausente ou desatualizado deixa lacunas

O modelo pode nunca ter recebido a informação de que o cliente precisa. Um documento enviado pode estar desatualizado; uma busca pode trazer a edição errada do produto; uma consulta à conta pode falhar. A explicação da Anthropic sobre respostas incorretas do Claude aponta explicitamente a falta de informações recentes como uma fonte de confusão.

É preciso distinguir duas situações. Se o assistente inventa uma política, a falha está na geração. Se reproduz com fidelidade uma política que perdeu a validade, a falha está na gestão das fontes. O cliente recebe uma resposta errada em ambos os casos, mas mudar o prompt não corrige um documento vencido nem uma consulta à conta que deixou de funcionar.

A pressão para responder recompensa o comportamento errado

A OpenAI argumenta que avaliações baseadas apenas em acurácia podem recompensar o chute em vez do reconhecimento da incerteza. Sua própria métrica de sucesso pode repetir esse erro se toda resposta concluída contar como acerto e todo encaminhamento contar como falha.

Um cliente que pede uma data de entrega garantida precisa de uma previsão oficial de envio. Se a transportadora não forneceu essa previsão, explicar exatamente qual informação está faltando é o resultado útil. Recompense esse desfecho nos testes e no painel de operação.

Exemplos de alucinações de IA: quatro falhas para detectar

Classifique as falhas de acordo com o que a aplicação precisa verificar. As categorias se sobrepõem, mas dão a uma equipe pequena pontos concretos para acrescentar checagens.

Fatos inventados: os exemplos dos títulos de tese vêm do relato de pesquisa da própria OpenAI. Reconhecer o nome do pesquisador não preencheu a lacuna sobre o título. No contexto de uma empresa, o equivalente é inventar uma funcionalidade porque produtos semelhantes a oferecem.

Números errados: os exemplos das datas de aniversário, no mesmo relato, mostram por que uma data com aparência de precisão não é evidência. Na sua aplicação, separe números sem respaldo de erros de cálculo. Busque as quantidades nos registros e calcule os totais com código convencional; peça ao modelo que explique o resultado recebido.

Citações falsas: a decisão de 20 de março de 2024 no processo United States v. Cohen descreve três processos inexistentes obtidos com o Google Bard, nome do assistente generativo do Google na época. Uma das supostas referências era United States v. Figueroa-Florez. Um nome de processo plausível e uma citação no formato correto não apontavam para um precedente real.

Argumentos incorretos em chamadas de ferramentas: os autores do Berkeley Function Calling Leaderboard mostram uma chamada com annual_interest_rate: 5 para uma taxa solicitada de 5%, ao lado da representação decimal correta, 0.05. Ambos os valores são números. Uma checagem de tipo, sozinha, não consegue distingui-los. Trata-se de um erro semântico no argumento: nem toda chamada incorreta de ferramenta é um fato inventado, mas ela precisa passar pela mesma revisão antes da execução.

Como reduzir as alucinações antes que cheguem ao cliente

Cerque a geração de evidências e validações e defina o que o sistema deve fazer quando uma delas faltar. Quem desenvolve responde pelas checagens; quem opera responde pela fonte oficial e pelo caminho de escalonamento.

Fundamente as respostas em fontes atuais e pertinentes

A geração aumentada por recuperação, ou RAG, busca materiais externos e fornece ao modelo os trechos relevantes. Ela entrega ao redator o material com que trabalhar. A explicação da Anthropic sobre Contextual Retrieval mostra por que é importante preservar o contexto de um trecho recuperado: um recorte isolado pode omitir a empresa, o período ou o assunto a que se refere.

Para uma funcionalidade de atendimento, escolha a base oficial de políticas e acrescente metadados de produto, região, data de vigência e acesso. Filtre por esses campos antes da geração. Recupere a regra de cancelamento junto com suas exceções; um parágrafo separado da ressalva que o acompanha pode sustentar uma promessa indevida.

Para informações atuais de uma conta, consulte o banco de dados ou o serviço da aplicação. Uma busca em documentos não substitui bem a consulta que informa se o pedido daquele cliente foi enviado. Se essa consulta falhar, retorne um estado de indisponibilidade em vez de substituí-la silenciosamente por conhecimento geral.

Comece com um fluxo simples de recuperação. Use RAG com agentes, em que o modelo pode escolher etapas adicionais de busca, quando as perguntas exigirem consultas complementares em diferentes fontes. As buscas extras precisam de regras de parada e das mesmas checagens de fontes.

O diagnóstico útil é saber se a evidência certa chegou ao modelo. Salve os IDs e as versões das fontes junto com a resposta para que a operação consiga distinguir uma falha de recuperação de um acréscimo sem respaldo.

Transforme o “não sei” em um estado da aplicação

O guia da Anthropic para reduzir alucinações recomenda permitir a incerteza, fundamentar o trabalho em trechos citados, indicar as evidências e remover afirmações sem respaldo. Transforme essas orientações em um contrato de resposta.

Dê ao modelo desfechos explícitos, como answered, needs_clarification e insufficient_evidence. Não exija uma resposta inventada para preencher um campo obrigatório quando não houver resposta. A interface deve converter cada desfecho em algo útil: uma pergunta específica de esclarecimento, uma explicação sobre o registro que falta ou um encaminhamento acompanhado do contexto recuperado.

Uma instrução útil é: “Use apenas as políticas e os registros da conta fornecidos. Se os registros não permitirem determinar a resposta, identifique a informação que falta. Não deduza a elegibilidade a partir de casos semelhantes.” Teste essa instrução com evidências ausentes, não apenas com perguntas fáceis.

Um resultado desconhecido não equivale a uma recusa por segurança, a um tempo limite excedido em uma ferramenta ou a uma solicitação sem autorização. Mantenha esses estados separados nos logs para que cada problema chegue ao responsável certo.

Torne as citações verificáveis por código

Uma citação deve identificar uma evidência que a aplicação já conhece. Faça a etapa de recuperação atribuir IDs às fontes e converta esses IDs em URLs aprovadas no servidor. Evite pedir ao modelo que invente uma bibliografia ou uma URL de destino de memória.

Confira três propriedades distintas:

• Existência: o ID da fonte citada pertence ao material autorizado fornecido para aquela solicitação.
• Citação textual: o trecho citado aparece na versão exata da fonte usada para responder.
• Respaldo: o trecho sustenta aquela afirmação para a situação daquele cliente.

As duas primeiras permitem checagens simples em código. A terceira exige uma regra de domínio, um campo estruturado confiável ou uma revisão separada da relação entre afirmação e evidência. Encontrar a palavra “elegível” em um documento não prova que determinado cliente seja elegível.

A documentação de citações da Anthropic descreve citações vinculadas a documentos que ajudam a localizar evidências. Uma referência à fonte ajuda a auditar a resposta; ela não resolve se a fonte é atual, oficial ou foi interpretada corretamente.

Use saídas estruturadas e depois valide os valores

Saídas estruturadas restringem a resposta a um esquema, isto é, uma definição dos campos e tipos de valores permitidos. Elas facilitam a implementação das checagens na aplicação. O guia de Structured Outputs da OpenAI alerta explicitamente que as saídas ainda podem conter erros e que entradas incompatíveis podem provocar alucinações quando o contrato de resposta não prevê uma alternativa adequada.

Antes de executar uma chamada de ferramenta, valide a operação, os argumentos obrigatórios, as unidades, os valores permitidos, a existência do registro e a permissão de quem fez a solicitação. Determine o tenant e o usuário autenticado no código da aplicação. Quando fizer sentido, deixe o modelo escolher entre registros autorizados; nunca trate um ID de cliente fornecido pelo modelo como prova de acesso.

Uma chamada de ferramenta bem-sucedida também exige uma resposta verdadeira ao cliente. Não diga que um cancelamento foi concluído se a ferramenta retornou um estado pendente ou um erro. Use o status retornado como referência oficial para a mensagem final. O guia de guardrails para agentes de IA do site aborda os limites de ação ao redor desse processo.

Como detectar alucinações de IA com uma checagem executável

Para um campo factual bem delimitado, confira o valor proposto em um registro aprovado e monte a resposta no próprio código. Isso oferece uma garantia mais forte para aquele campo do que avaliar se um texto livre parece coerente.

O exemplo em Python abaixo usa dados fictícios de uma política de atendimento, não uma política real de negócio. Salve-o como verify_answer.py e execute python3 verify_answer.py. Ele usa apenas a biblioteca padrão e não faz chamadas de API.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

A resposta proposta, chat, é reprovada mesmo com uma citação textual autêntica. Se o valor for email, ele passa nessa checagem restrita. É o campo confiável, e não apenas a correspondência do trecho citado, que determina a resposta.

O limite importa: esse validador não consegue determinar se uma explicação em texto livre é verdadeira, se o responsável pela política registrou o fato correto ou se o filtro de acesso aplicado antes funcionou. O ramo unknown valida um formato de resposta permitido, não se era necessário abster-se de responder. Trate essas questões em checagens e avaliações separadas. Para fatos fixos de alto impacto, um template preenchido com dados confiáveis pode eliminar por completo a necessidade de geração.

Avaliações que recompensam respostas certas e paradas necessárias

Uma avaliação, ou eval, é um teste repetível da aplicação em relação ao comportamento esperado. Monte a sua a partir das falhas que afetam clientes e execute-a sempre que mudar o modelo, o prompt, o índice de recuperação, o esquema de uma ferramenta ou uma política.

Registre os desfechos separadamente: resposta correta com respaldo, resposta sem respaldo, abstenção adequada, abstenção desnecessária e ação inválida proposta. Uma média única esconde se a melhora veio de evidências melhores ou apenas da recusa a responder mais perguntas.

Use código convencional para conferir valores exatos, presença das fontes no conjunto autorizado, campos obrigatórios, permissões e resultados das ferramentas. Use um modelo avaliador para questões que dependem da linguagem, como saber se um trecho sustenta uma paráfrase, com exemplos revisados por pessoas para calibrar suas decisões. Um LLM como avaliador é outro modelo sujeito a erros, não uma fonte independente de fatos.

O Promptfoo é uma ferramenta de avaliação cujas asserções avaliadas por modelos incluem a veracidade em relação a uma referência e a fidelidade ao contexto fornecido. Essa distinção é útil: uma resposta pode corresponder a um documento desatualizado e ainda assim estar errada hoje. Use o guia de Promptfoo para montar a estrutura de testes depois de definir o que significa passar em um teste.

Mantenha a solicitação, as evidências recuperadas, os argumentos propostos, o resultado da ferramenta executada e a resposta final juntos no registro de execução de cada teste. Quando um caso falhar, esse registro mostra onde intervir. Trate citações ausentes e argumentos inválidos como falhas explícitas, mesmo que o texto receba uma boa nota do modelo avaliador.

Quais promessas são exageradas?

RAG não torna toda resposta verdadeira. Um trecho útil pode ser recuperado e interpretado de forma errada; um trecho desatualizado pode ser citado com perfeição. Teste a recuperação e a geração separadamente e defina um responsável pela base de fontes.

Uma janela de contexto maior não substitui a seleção das fontes. As orientações da Anthropic sobre engenharia de contexto alertam que a capacidade de recuperar informações e a precisão podem cair à medida que o contexto cresce. Inclua a regra pertinente, suas exceções e as evidências necessárias da conta. Despejar todos os documentos no prompt não é uma política de atualização.

Um segundo modelo dizer “parece correto” não basta como verificação. Dê aos revisores as evidências reais e um critério claro. A concordância sem evidências independentes pode preservar a mesma suposição sem respaldo.

JSON válido não é um certificado de correção. O esquema pode exigir um ID de fonte e um argumento numérico; a aplicação ainda precisa confirmar que a fonte existe e que o número tem o significado certo.

Os limites relevantes são as perguntas que suas fontes não conseguem responder, os campos que suas checagens não conseguem verificar e as ações que você não consegue reverter com segurança. Não existe uma porcentagem universal de alucinação que diga se o seu fluxo de trabalho específico está pronto.

Um roteiro para sua equipe pequena aplicar nesta semana

Aja agora se a funcionalidade faz promessas factuais a clientes ou altera registros do negócio. Se ela apenas produz rascunhos que uma pessoa responsável já confere nas fontes, comece pelo conjunto de avaliação e melhore essa revisão antes de acrescentar uma arquitetura automatizada elaborada. Uma consulta determinística que já retorna campos de uma fonte oficial pode dispensar um modelo.

Este é um plano inicial sugerido, não uma evidência de que uma semana de trabalho garante confiabilidade em produção.

A primeira ação de segunda-feira é escolher uma resposta errada recente e preservar todo o seu registro de execução. Identifique se a evidência estava ausente, desatualizada, foi mal interpretada ou ignorada. Acrescente a menor checagem capaz de detectar essa falha e transforme o incidente em um caso permanente de regressão.

Perguntas frequentes sobre alucinação em LLMs

Para receber guias práticos sobre como criar fluxos de trabalho confiáveis com IA, assine a newsletter.