---
title: "Como domar a 'amnésia seletiva' dos LLMs e Evitar a Ilusão do Contexto Infinito"
author: "Ricardo Pupo Larguesa"
date: "2026-05-07 09:00:00-03"
category: "Na Prática"
url: "http://scale.press/portal/aintuicao/post/2026/05/07/como-domar-a-amnesia-seletiva-dos-llms-e-evitar-a-ilusao-do-contexto-infinito/md"
---

Todo dia alguém comemora que o modelo de linguagem da vez agora aceita uma janela de um milhão de tokens, inclusive eu. Na prática, quem desenvolve software com inteligência artificial sabe a verdade: jogar um livro inteiro no prompt é pedir para o modelo ter amnésia seletiva no meio do caminho. O fenômeno *Lost in the Middle*, onde a IA ignora sumariamente o que está no meio do texto, continua sendo um dos maiores geradores de alucinações.

## O Custo de Detectar a Mentira

Ontem, analisando o paper [Low-Cost Black-Box Detection of LLM Hallucinations via Dynamical System Prediction](https://arxiv.org/abs/2605.05134) (arXiv:2605.05134), de Dan Wilson e Mohamed Akrout, encontrei uma tentativa matemática engenhosa para baratear essa conta. O método padrão para checar se a IA está inventando dados, como o SelfCheckGPT, exige rodar a mesma requisição várias vezes e comparar se as respostas entram em contradição. Isso queima tokens e aumenta a latência.

A sacada deste novo estudo é tratar a geração de texto como um sistema dinâmico. Usando a Teoria do Operador de Koopman (abordagem matemática que permite analisar sistemas dinâmicos não lineares através de uma perspectiva linear), os pesquisadores analisam a trajetória dos embeddings em uma única passagem (single-sample pass). Fatos reais e alucinações tomam "caminhos" geométricos diferentes no espaço latente. Quando o sistema identifica a rota da alucinação pelo *Differential Residual Score*, ele bloqueia a resposta. É matemática de alto nível resolvendo nossos problemas com os boletos de APIs.

## A Heurística que Recomendo para Prompts de 100k Tokens

Ainda assim, detectar alucinação é tratar a consequência. A engenharia real deve focar na causa. Quando você precisa enviar 100 mil tokens para um modelo, empilhar parágrafos é garantia de falha. A técnica que recomendo e uso exaustivamente é o *Context Priming & Structure Anchor*.

Os modelos processam melhor quando encontram fronteiras físicas claras no texto. [Essa mudança na forma de pensar o contexto é inevitável na evolução da engenharia de prompt](https://scale.press/portal/aintuicao/post/2026/05/04/engenharia-de-contexto-30-como-o-prompt-para-devs-precisa-mudar-para-modelos-recorrentes). A dica para separar dados de instruções é o uso intensivo de tags XML, organizando a requisição nas seguintes camadas:

  <system_instructions>    Você é um analista especialista. Sua tarefa é [DESCREVER OBJETIVO].    Diretrizes fundamentais:    1. Priorize as informações contidas em <knowledge_base>.    2. Se a resposta não estiver nos dados, diga que não sabe.    3. Use o formato de saída definido em <output_format>.  </system_instructions>  <context_and_background>    [Insira aqui o contexto do projeto ou o histórico necessário para a IA entender as nuances da tarefa]  </context_and_background>  <knowledge_base>    <document id="01" type="pdf">      [Conteúdo massivo aqui...]    </document>    <document id="02" type="csv">      [Mais dados aqui...]    </document>  </knowledge_base>  <output_format>    Sua resposta deve seguir rigorosamente este formato:    - Resumo Executivo    - Tabela de Metadados  </output_format>  <user_query>    [Sua pergunta específica ou comando final aqui]  </user_query>A lógica aqui é diretiva: instruções críticas no topo, a massa de dados confinada no meio e a requisição final fechando o bloco, garantindo que seja a última coisa processada na memória de trabalho de curto prazo do modelo.

## Extraindo a Densidade e Cortando Custos

Quando a tarefa exige resumir ou analisar documentos complexos sem perder detalhes sutis, recorro à técnica de *Chain of Density* (CoD). Ela obriga o modelo a iterar o próprio texto, injetando entidades e fatos omitidos na versão anterior sem inchar a contagem final de palavras. A IA é forçada a trocar verbosidade por precisão factual.

Mas o questionamento primário deve sempre ser arquitetural. Na [T2S](http://t2s.com.br), evitamos que empresas gastem rios de dinheiro em inferência de contexto longo apenas por preguiça de estruturar os dados da empresa. [A resposta mais escalável e barata para memória de longo prazo continua sendo o RAG](https://scale.press/portal/aintuicao/post/2026/03/06/rag-adaptativo-por-que-a-memoria-de-trabalho-e-o-proximo-salto-da-ia) (Retrieval-Augmented Generation) ou o GraphRAG. Em vez de enviar toda a base de conhecimento a cada nova requisição, usamos um banco de dados vetorial ou em grafos para pescar e injetar apenas os trechos exatos que o modelo precisa para aquela pergunta específica. E para histórico de conversas extensas, a *Summarization Memory* resolve 90% dos casos: resume-se os diálogos antigos e mantém apenas a versão condensada no contexto ativo.

Janelas de contexto gigantes são ferramentas poderosas, mas não são substitutas de uma boa arquitetura de software. Enviar dados desorganizados para o modelo só garante que ele produza respostas erradas de forma mais rápida e cara.

Se você lida com essas limitações no código do dia a dia, detalho esses e outros padrões estruturais no meu livro [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt). Para debatermos os reais gargalos das aplicações em IA, me acompanhe nas redes: [conecte-se por aqui](https://linktr.ee/ricardo.pupo).