Alucinações de LLM em produção: defesa em profundidade semântica

Quando li a reportagem do Sapo.pt sobre o chatbot que quase iniciou uma guerra entre os EUA e a China, minha primeira reação não foi de espanto — foi de reconhecimento. Quem já colocou um LLM em produção sabe: alucinações não são bug eventual, são característica probabilística do sistema. E quando a cadeia de comando confia no output como se fosse verdade absoluta, o resultado é o que vimos: aviões militares no ar e fuzileiros se preparando para abordar uma embarcação.

O caso relatado pela CNN, com fontes anônimas, mostra um padrão que se repete em empresas menores todos os dias: um analista usou IA para cruzar dados abertos com sinais classificados, gerou um relatório, e a estrutura hierárquica engoliu o documento sem questionar. Só perceberam o erro quando a operação já estava em andamento.

O que realmente aconteceu — e por que isso importa para devs

Segundo o Sapo.pt, o analista do Comando de Operações Especiais do Pacífico, sediado no Havai, consultou um chatbot sobre o manifesto de carga de um navio no Médio Oriente. O sistema combinou fontes abertas com informação de interceções de sinais (sigint) e concluiu, sozinho, que a embarcação transportava material ligado a um programa nuclear.

Em seguida, outro agente de IA transformou essa resposta num relatório no formato padrão de inteligência — aquele visual sério, com seções, linguagem técnica e timbre oficial que ninguém questiona. A formatação matou a dúvida.

Para nós, devs, isso é um alerta sobre três coisas:

• Alucinação em pipelines críticos — não basta o modelo “parecer certo”; ele precisa estar certo.
• Confiança indevida na formatação — UI polida gera autoridade percebida.
• Falta de validação humana estruturada — “human in the loop” virou jargão de pitch, não prática.

Por que LLMs alucinam: o mecanismo técnico

Na minha experiência construindo sistemas com GPT-4, Claude e modelos open source, alucinação é consequência direta de três fatores: temperatura alta, contexto insuficiente e prompts mal estruturados. Modelos de linguagem não “sabem” — eles preenchem lacunas estatísticas com a sequência mais provável no espaço de tokens.

Quando você dá a um LLM um prompt ambíguo sobre um manifesto de carga parcial, ele vai completar a informação. Se a temperatura estiver em 0.7, ele vai arriscar uma resposta criativa. Se o system prompt não exigir “responda apenas se tiver certeza”, ele vai inventar.

O caso militar é particularmente grave porque envolveu um esquema de RAG (Retrieval-Augmented Generation) mal calibrado: combinou dados públicos com sigint classificado, mas sem metadata de confiança por fonte. O sistema tratou tudo com o mesmo peso estatístico — e ainda houve um segundo passo, um modelo formatando a saída no padrão oficial, que adicionou mais uma camada de opacidade.

Na Prática: como evitar alucinações em sistemas críticos

Quando construo pipelines com LLMs para clientes, sigo um protocolo de cinco camadas que chamo de “defesa em profundidade semântica”. Vou mostrar o esqueleto em Python:

from dataclasses import dataclass, field
from typing import Optional
import json

@dataclass
class SourceConfidence:
    source_id: str
    reliability: float  # 0.0 a 1.0
    classification: str  # 'open', 'restricted', 'classified'

@dataclass
class VerifiedClaim:
    text: str
    sources: list = field(default_factory=list)
    avg_confidence: float = 0.0
    requires_human_review: bool = True

def validate_llm_output(
    raw_response: str,
    sources: list,
    min_confidence: float = 0.85,
) -> VerifiedClaim:
    """
    Bloqueia claims cuja confiança agregada está abaixo do limiar.
    Força revisão humana antes de propagar para o relatório final.
    """
    if not sources:
        raise ValueError("Claim sem fonte — bloqueado na origem")

    weights = [s.reliability for s in sources]
    # Penaliza fontes abertas de baixa confiança (ruído da internet)
    penalty = sum(0.2 for s in sources if s.classification == 'open' and s.reliability < 0.7)
    avg = sum(weights) / len(weights) - penalty

    # Qualquer informação classificada exige olhar humano
    requires_review = (
        avg < min_confidence
        or any(s.classification == 'classified' for s in sources)
    )

    return VerifiedClaim(
        text=raw_response,
        sources=sources,
        avg_confidence=round(max(avg, 0.0), 3),
        requires_human_review=requires_review,
    )

# Simulação do caso real: o chatbot identifica carga nuclear
sources = [
    SourceConfidence('manifest_pub', 0.6, 'open'),
    SourceConfidence('sigint_intercept', 0.4, 'classified'),
]

claim = validate_llm_output(
    "O navio transporta urânio enriquecido vinculado ao programa X",
    sources,
)

if claim.requires_human_review:
    print("🚨 ALERTA: claim requer revisão humana antes de virar relatório")
    print(f"Confiança média: {claim.avg_confidence}")
    # Em produção: enfileira para analista humano, NÃO segue adiante

Esse código é deliberadamente simples. Em produção, você adicionaria logging estruturado, tracing distribuído, versionamento de prompts e um "circuit breaker" que para o pipeline quando a taxa de alucinações detectadas ultrapassa X%.

Comparando abordagens: o que cada provedor entrega (e o que deixa na sua mão)

O ponto é: nenhum LLM pronto de fábrica resolve o problema da alucinação em cadeia. Você constrói a defesa.

Erros Comuns que devs cometem (e que custam caro)

Em mais de uma década programando, vi os mesmos erros se repetirem em cada hype cycle. Com IA generativa não é diferente.

• Tratar a temperatura como detalhe estético. Temperatura 0.9 em produção crítica é pedir para seu sistema mentir com confiança. Para tarefas de extração e classificação, uso 0 ou no máximo 0.2.
• Confiar em markdown bonito. O segundo passo do caso militar foi usar IA para formatar o relatório no padrão oficial. Foi exatamente isso que convenceu os oficiais. Saída formatada demais sem provenance = armadilha.
• Não versionar prompts. Mudou o system prompt em produção sem controle de versão? Você acabou de alterar o comportamento de todo o sistema sem rastrear. Git para prompts não é opcional — é higiene.
• Pular o "chain of verification". Peça para o modelo confirmar suas próprias afirmações num segundo passo, contra as fontes originais. Caro em tokens, barato em processos judiciais e em noites mal dormidas.
• Human-in-the-loop só no PowerPoint. Ter um humano "no loop" que aprova 200 relatórios por hora não é controle — é teatro de compliance.
• Esquecer o "I" do RAG. Retrieval-Augmented Generation pressupõe retrieval bom. Se seu índice de vetores retorna lixo, o LLM vai enriquecer o lixo com confiança.

Implicações para o seu código do dia a dia

Você pode pensar "não trabalho com inteligência militar" — e tá certo. Mas se você usa Copilot, Cursor ou qualquer wrapper de LLM em produção, seja um chatbot de suporte, um extrator de dados de PDFs ou um agente que envia e-mails, você tem o mesmo problema em escala menor.

Recomendo três mudanças concretas que aplico nos meus projetos:

1. Adicione um campo confidence_score em toda resposta LLM que vá para um usuário final. Quem decide com a informação precisa saber quão confiável ela é.
2. Nunca gere output crítico sem log da fonte original. Se o LLM citou um documento, salve o ID do documento e o trecho. Permite auditoria e reprocessamento.
3. Implemente um "abstain" explícito. Treine seus prompts para dizer "não sei" quando o contexto for insuficiente. Modelos fazem isso muito melhor com instrução direta do que com prompt esperto.

FAQ — Perguntas que devs reais estão fazendo

Como sei se meu sistema está alucinando em produção?

Implemente um conjunto de "golden questions" — perguntas cujas respostas corretas você conhece — e rode contra o sistema semanalmente. Se a taxa de acerto cair, você tem regression de prompt ou de modelo. Na minha experiência, isso detecta drift antes dos usuários reclamarem.

Fine-tuning resolve o problema da alucinação?

Não. Fine-tuning ajusta estilo, formato e tom de domínio. Não ensina o modelo a "saber" o que ele não sabe. Para evitar alucinação, o caminho é arquitetura: RAG bem feito, abstention training e validação contra fontes.

Vale a pena usar um LLM menor com RAG em vez de um gigante sem?

Em 90% dos casos que vi, sim. Um modelo de 7B bem ajustado com retrieval decente supera um modelo proprietário de 200B com prompt genérico em tarefas específicas. Menos alucinações, menor custo, mais controle.

Como o caso dos EUA deve mudar a regulação de IA?

Provavelmente vai acelerar a discussão sobre AI liability em sistemas críticos. A UE já tem o AI Act; nos EUA ainda não há equivalente federal robusto. Casos assim criam pressão política para que exista.

Dá para usar IA em relatórios oficiais com segurança?

Dá, com camadas. Use IA para rascunho, validação semântica automática, revisão humana com checklist explícito e metadata de proveniência em cada afirmação. Sem essas camadas, é roleta russa institucional — e o caso do Pentágono é a prova.

O que levo desse caso para o meu trabalho

A lição mais dura da reportagem do Sapo.pt não é sobre geopolítica — é sobre arquitetura. Quando a cadeia de comando confia num documento gerado por IA sem auditar sua origem, o problema não é a IA. É o processo.

Cada vez que você coloca um LLM em produção, está essencialmente publicando um estagiário brilhante que inventa 15% dos fatos com convicção total. Seu trabalho como engenheiro é construir as cercas em volta dele — versionamento de prompts, validação de fontes, abstention explícita, circuit breakers de qualidade.

E sobre os EUA e a China: felizmente, desta vez, o "quase" foi o desfecho. Aviões voltaram, fuzileiros não abordaram o navio, e a diplomacia ficou intacta. Mas a próxima vez pode não ter final feliz — e isso vale tanto para o Pentágono quanto para o seu próximo deploy numa sexta-feira às 18h.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.