5 mentiras que todo LLM te conta — e como o Context Engineering corrige cada uma
Semana passada eu perdi 40 minutos numa integração de pagamento porque o Claude Sonnet 4.6 me disse, com todas as letras, que o endpoint da API do PagBank aceitava idempotency_key no header. Aceita. Só que o nome do header é X-Idempotency-Key e não Idempotency-Key, e o LLM inventou o formato mais “parecido com Stripe” que ele conhecia. Voltei duas vezes na doc oficial pra ter certeza que eu não estava enlouquecendo.
Não estava. O LLM mentiu.
Depois de mais ou menos 6 meses fazendo Context Engineering pra valer, eu comecei a catalogar as mentiras que os LLMs contam. Elas caem em 5 categorias. 4 têm solução técnica de baixo custo. 1 é impossível de resolver sem trocar de modelo. Este post é o mapa que eu queria ter tido quando comecei.
As 5 mentiras (spoiler: só uma é “de propósito”)
Antes de virar solução, vamos nomear cada uma. Nome importa: se você chama tudo de “alucinação”, você aplica a mesma receita pra tudo e falha em 4 casos de 5.
Mentira 1: Hallucination clássico (o Idempotency-Key de propósito errado)
O LLM inventa uma API, um parâmetro, um método, um SDK. Prevê o próximo token com base em padrões de auth, pagamentos, filas — e escolhe o mais provável dentro do que ele “vê”. Sem instrumentação, ele não distingue “eu sei” de “eu chuto”.
Um estudo interno da Anthropic mostrou que o Sonnet 4 respondia com Specificity 4,2/5 sobre uma ferramenta ficcional chamada PropelAuth — invenção pura. A Factual Accuracy era 0,6/5. Modelo grande, mentira polida.
Mentira 2: Knowledge cutoff (o “React 19 tem esse hook”)
O modelo tem uma data de corte no treinamento. Tudo que aconteceu depois é opaco pra ele. Sonnet 4.6 tem cutoff de aproximadamente fevereiro de 2025 — então se você pergunta sobre um recurso que saiu em maio de 2025, ele vai chutar baseado no que existia antes, sem te avisar que é chute.
Essa é a mentira que mais me pegava no ano passado. Hoje eu automatizei uma regra: se a pergunta envolve versão de biblioteca ou feature recente, o system prompt força o modelo a rodar uma busca web antes de responder.
Mentira 3: Context loss no meio da sessão longa
Você dá 40 mil tokens de contexto (specs, RFCs, código legado), pergunta sobre a linha 12 mil, e o modelo “esquece” ou lembra errado. Não é limite de janela — cabe. É que a atenção nem sempre chega lá com a mesma intensidade que chega no início e no fim.
Anthropic tem um paper interno sobre esse “lost in the middle” que muita gente já reproduziu. O jeito de detectar é embaraçosamente simples: você faz o modelo citar o trecho antes de responder. Se ele parafraseia sem citar, provavelmente está inventando.
Mentira 4: Tool bluff (a mentira do agent)
Essa é nova e a mais perigosa em contexto agentic. Você dá 12 ferramentas ao agent (search, edit, run, deploy…), e ele “chama” uma ferramenta descrevendo o resultado que a chamada teria retornado — mas nunca chamou. Só simulou o output.
Eu peguei isso duas vezes em produção com o Claude Code fazendo refactor. O agent “leu” um arquivo que nunca leu (o resultado da tool call estava vazio), e continuou como se tivesse lido. A saída ficou plausível o suficiente pra passar review, e só quebrou em runtime.
Mentira 5: Source fake (a que não tem solução técnica)
Você pede referências, ele te dá 3 links https://arxiv.org/abs/2401.XXXXX que existem em formato mas não existem em conteúdo. Ou cita “Smith et al. 2023” pra um paper que ninguém escreveu.
Essa mentira é diferente porque não é o LLM “chutando dentro do domínio dele”. Ele está fabricando metadados de coisas que nem existem. Nenhuma técnica de prompt engineering consegue corrigir totalmente essa classe. A única solução que funciona pra mim hoje é usar um modelo diferente pra tarefas que exigem citação real (Perplexity, um search-grounded model, ou verificar manualmente cada link).
Como o Context Engineering corrige 4 delas em minutos
As 4 primeiras têm uma coisa em comum: o modelo tem contexto suficiente pra fazer a coisa certa, mas o comportamento padrão dele empurra pra chutar. Context Engineering é o trabalho de mudar esse padrão.
Aqui está o que eu uso, na ordem de custo de implementação:
Para hallucination (5 minutos): adicione ao system prompt “Se você não tem certeza de um nome de API, parâmetro ou método, diga ‘não tenho certeza’ e sugira que o usuário verifique a documentação oficial. Não invente.”
Só isso muda Sonnet 4 de Honesty 0,2/5 pra Honesty 3,7/5 no benchmark da Anthropic. Nunca vi um ganho tão grande com tão pouco esforço. Se o seu system prompt não tem essa linha, você está deixando dinheiro na mesa.
Para cutoff (10 minutos): dê ao modelo uma tool de busca web e adicione ao system prompt “Se a pergunta envolve versões, releases ou recursos anunciados depois de [data-cutoff], use a tool web_search antes de responder.” A parte crítica é o “antes de responder” — sem isso, ele responde primeiro e busca depois só pra “confirmar”.
Para context loss (15 minutos): obrigue citação. “Antes de responder, cite o trecho exato do documento em que sua resposta se baseia, entre aspas triplas.” Se o modelo não consegue citar, ele não pode responder. Isso quebra o loop de “eu me lembro vagamente” que causa a mentira 3.
Para tool bluff (30 minutos + logs): instrumente. Loggue toda tool call com input, output, timestamp. Faça o agent ler seu próprio log antes de continuar (Verifique se a tool call anterior de fato retornou dados válidos antes de prosseguir). E se você usa Claude Code, ative o --verbose — os tool calls que não aconteceram ficam visíveis no diff.
A tabela que eu queria ter tido no primeiro dia
| Mentira | Custo de corrigir | Técnica principal | Efeito |
|---|---|---|---|
| 1. Hallucination | 5 min | ”Permission to say I don’t know” no system prompt | Honesty 0,2 → 3,7 |
| 2. Cutoff | 10 min | Tool web_search obrigatória antes de responder | ~90% dos casos |
| 3. Context loss | 15 min | Citação obrigatória antes de resposta | Reduz drasticamente |
| 4. Tool bluff | 30 min + logs | Logs de tool call + auto-verificação do agent | Detectável, não invisível |
| 5. Source fake | sem solução | Trocar de modelo (search-grounded) ou verificar manual | Só evitável, não corrigível |
Onde o Sonnet 4.6 ainda me pega
Mesmo com essas 4 técnicas em produção há 6 meses, o Sonnet 4.6 ainda me pega na mentira 5 uma vez por semana. Não em código — em referências. Se eu peço “cite 3 papers sobre X”, ele me dá 3 títulos que soam certos, com autores que existem, sobre um paper que não foi escrito.
Aprendi a nunca copiar citação de LLM sem abrir o link. É lento. É chato. É a única defesa.
Pra tudo o resto, Context Engineering é o multiplicador de produtividade mais barato que eu conheço. Um system prompt de 200 palavras bem colocado economiza mais debug do que 3 dias refatorando código.
Fechando
Se você tá começando com LLM em produção, faça esse experimento hoje: pegue o system prompt do seu projeto principal e cheque quantas das 4 técnicas acima estão lá. Se estiver zero, você provavelmente tem 4 mentiras rodando em silêncio no seu backend agora mesmo.
E se você tiver ideia de como corrigir a mentira 5 sem trocar de modelo, me manda mensagem. Ainda não achei.
Referências: Anthropic — Reduce hallucinations / Anthropic — Prompting best practices / dados do experimento PropelAuth extraídos do Context Engineering (ken imoto, 2026).
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Este artigo foi útil?