Alucinação de LLM em produção: como evitar no código

OpenAI quer pisar no freio, ChatGPT inventou testemunhas e IA já formula alimentos: o que isso significa para quem programa

Três notícias do Olhar Digital desta semana me chamaram atenção não pelo hype, e sim pelo que elas revelam sobre o estado real da engenharia em torno de modelos de linguagem. Tem a OpenAI admitindo publicamente que talvez esteja indo rápido demais, tem um advogado nos EUA multado porque o ChatGPT inventou depoimentos de policiais em um caso de assassinato, e tem IA já entrando em P&D de alimentos identificando combinações que humanos não enxergam. Vou destrinchar cada uma e mostrar onde isso te pega no código.

1. OpenAI cogita desacelerar — e isso é muito mais sério do que parece

Segundo reportagem do Olhar Digital, Sam Altman disse a funcionários que a empresa considera reduzir o ritmo de desenvolvimento de IAs avançadas para acompanhar laboratórios concorrentes. Em tese, parece movimento de prudência. Na prática, é um sinal enorme para quem constrói produto em cima desses modelos.

Na minha experiência, quando o fornecedor de API muda o roadmap de seis em seis meses, todo o seu sistema de prompts, embeddings e fine-tuning vira dívida técnica. Já vi empresa retreinando classificadores inteiros porque um modelo mudou de versão e o output drift quebrou pipelines de produção. Se a OpenAI realmente frear, a janela de obsolescência dos seus modelos atuais aumenta — o que é bom para estabilidade e ruim se você apostou em capacidades de fronteira.

O que eu faria hoje se tivesse um produto rodando em GPT-4/4o/5:

Versionar tudo: fixar o model na chamada de API em variável de ambiente, nunca hardcoded.
Implementar fallback entre modelos: ter um caminho alternativo quando o modelo principal retornar erro 429 ou mudar de versão.
Medir latência e custo por feature: se você não sabe quanto cada endpoint custa por request, uma mudança de pricing da OpenAI te quebra.
Testar saída contra golden dataset: regression test de prompts não é exagero, é higiene.

# Padrão que eu uso em produção para isolar a chamada do modelo
import os
from openai import OpenAI

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

PRIMARY_MODEL = os.getenv("PRIMARY_MODEL", "gpt-4o")
FALLBACK_MODEL = os.getenv("FALLBACK_MODEL", "gpt-4o-mini")

def chat_completion(messages, temperature=0.2):
    try:
        return client.chat.completions.create(
            model=PRIMARY_MODEL,
            messages=messages,
            temperature=temperature,
        )
    except Exception as e:
        # log estruturado aqui
        return client.chat.completions.create(
            model=FALLBACK_MODEL,
            messages=messages,
            temperature=temperature,
        )

Esse padrão simples evita que uma mudança de política na OpenAI derrube seu produto num sábado às 23h.

2. ChatGPT inventou testemunhas em tribunal — e o problema é seu também

A Suprema Corte do Novo México multou um defensor que usou ChatGPT para redigir um recurso criminal. A ferramenta alucinou citações, depoimentos de policiais que nunca existiram e até testemunhas fictícias. O advogado agora responde por má conduta.

Esse caso viraliza, mas a lição técnica é universal: LLMs não sabem a diferença entre “provavelmente verdade” e “verdade”. O modelo gera o token mais provável dado o contexto, e se você pede referências jurídicas brasileiras, ele monta uma colcha de retalhos plausível que pode não existir em lugar nenhum do mundo.

Quando uso LLM para gerar código com citações de documentação externa (links, nomes de funções, parâmetros de API), sempre confiro manualmente. Já peguei modelo inventando parâmetros de função do pandas, SQLAlchemy e até endpoints do AWS SDK. Em um sistema de produção, isso vira bug silencioso.

Na Prática: como blindar seu sistema contra alucinação

Existem três camadas de defesa que eu recomendo, do mais barato ao mais robusto:

Prompt com guardrail explícito: instrua o modelo a responder “não sei” quando não tiver certeza. Parece óbvio, mas 70% dos prompts em produção que eu reviso não fazem isso.
Grounding via retrieval: passe os documentos reais como contexto e force o modelo a citar a fonte. Isso é o famoso RAG.
Verificação automatizada pós-resposta: valide a saída contra sua base de verdade (schema, regex, lookup em banco) antes de devolver ao usuário.

# Exemplo mínimo de grounding com citação forçada
SYSTEM_PROMPT = """Você é um assistente técnico.
Responda APENAS com base no contexto fornecido entre as tags <contexto>.
Se a informação não estiver no contexto, responda exatamente:
'NÃO_ENCONTRADO_NO_CONTEXTO'.
Sempre cite o ID do documento entre colchetes no final da frase."""

CONTEXTO_REAL = """
[doc-001] O pandas 2.0 introduziu copy-on-write como opt-in.
[doc-002] O método DataFrame.it.iterrows() está deprecated desde 2.0.
"""

def responder(pergunta, contexto):
    prompt = f"<contexto>\n{contexto}\n</contexto>\n\nPergunta: {pergunta}"
    resposta = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": prompt},
        ],
        temperature=0,  # zero criatividade quando o objetivo é fidelidade
    )
    return resposta.choices[0].message.content

Note o temperature=0. Quando o objetivo é extrair informação factual e não criatividade, zero é seu amigo. temperature=0.7 nesse cenário é pedir para o modelo inventar com confiança.

Erros Comuns que eu vejo em devs lidando com LLM

Confiar em avaliação manual única. “Ah, testei 5 prompts e funcionou.” LLM tem distribuição de saída enorme. Teste 100+, meça com métrica objetiva (exact match, BLEU, ou LLM-as-judge).
Não tratar alucinação de schema. Se você pede JSON e o modelo devolve JSON com campo a mais ou tipo trocado, seu código explode. Use response_format={"type": "json_schema", ...} com schema estrito.
Misturar temperatura alta com system prompt factual. Quer determinismo? Zero. Quer brainstorm? 0.7+. Nunca misture.
Ignorar custo de input. Muitos devs otimizam só output. Em sistemas RAG com muitos documentos, o custo de input domina. Use reranking e corte contexto irrelevante.
Não versionar prompts. Prompt é código. Coloque em arquivo, commite, revise em PR. Parece exagero até o dia que alguém muda uma palavra e o pipeline inteiro desanda.

3. IA formulando alimentos — o paralelo com P&D de software

A última notícia da lista fala de IA identificando combinações de ingredientes para novos produtos alimentícios. A tecnologia não “inventa do nada”, ela mapeia relações em bases de dados de composição, sabor, textura e custo para sugerir candidatos que atendam objetivos pré-definidos.

Esse é exatamente o mesmo padrão de design generativo que já uso em código: definir objetivos e restrições, deixar o modelo explorar o espaço de soluções, validar contra métricas. É a mesma lógica por trás de ferramentas como GitHub Copilot Workspace ou Cursor Composer — você descreve o objetivo, o sistema propõe candidatos e você filtra.

Na engenharia de software, isso aparece em:

Test generation: ferramentas que sugerem casos de teste a partir de cobertura e histórico de bugs.
API design assistida: LLMs que sugerem contratos REST baseado em padrões do seu próprio codebase.
Refactoring suggestions: identificar código duplicado ou padrões problemáticos em escala.

O ponto em comum: a IA não substitui o engenheiro, ela expande o espaço de busca. Você ainda decide, ainda valida, ainda responde pelo produto.

FAQ — perguntas que devs realmente fazem

1. Como evitar que meu chatbot invente informações como o advogado do caso do Novo México?
Implemente RAG com citação obrigatória, force temperatura zero para tarefas factuais, valide a saída contra uma base de verdade e, quando o contexto não tiver a resposta, ensine o modelo a recusar em vez de fabular.

2. Se a OpenAI desacelerar, meus modelos vão ficar obsoletos?
Não necessariamente. Modelos mais antigos continuam recebendo updates de preço e disponibilidade por um bom tempo. O risco real é ficar preso a um modelo sem suporte quando seu produto já depende dele. Por isso a importância de monitorar deprecation notices e ter plano B sempre.

3. Vale a pena usar GPT-5 ou fico no 4o mesmo?
Depende da tarefa. Para tarefas onde você precisa de raciocínio encadeado forte (análise de código complexa, planejamento multi-step), os modelos de fronteira valem o custo extra. Para classificação simples, extração de entidades ou transformação de texto, o 4o-mini ou até um modelo local de 7B rodando via Ollama resolve e custa uma fração.

4. Como eu sei se meu LLM está alucinando em produção?
Você precisa de um conjunto de validação com respostas conhecidas e rodar avaliações periódicas. Bibliotecas como deepeval, ragas ou promptfoo automatizam isso. Sem métrica objetiva, você só descobre a alucinação quando o cliente reclama.

5. E se eu não tiver budget para API paga?
Modelos locais via Ollama, LM Studio ou vLLM rodando em workstation com GPU decente (uma RTX 4090 roda Llama 3.1 70B quantizado). Para a maioria das tarefas de um dev, 70B quantizado em Q4 entrega qualidade próxima do GPT-4o em muitos benchmarks e com latência controlada.

O que eu levo dessas três notícias

OpenAI freando não é evento catastrófico, é sinal de mercado amadurecendo. Advogado multado por alucinação é alerta para qualquer um que automatiza geração de texto em área regulada. IA formulando alimentos confirma que o padrão “definir objetivo + deixar modelo explorar + humano valida” virou metodologia padrão em qualquer P&D — inclusive em software.

Se você trabalha com IA em produção hoje, três coisas são não-negociáveis: temperatura baixa para tarefas factuais, validação automatizada de saída e versionamento de prompt. Tudo o mais é otimização em cima dessa base.

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