Context rot em LLMs: RAG vs contexto longo em 2026

O que é context rot em LLMs

Context rot é a queda medida na precisão de um modelo de linguagem grande conforme a entrada cresce, bem antes de a janela de contexto encher. Ele nasce da atenção espalhada por mais tokens, de distratores que se parecem com a resposta e de um treinamento que raramente recompensa o raciocínio em comprimentos extremos. A solução é enviar menos: recuperar e reordenar, limpar saídas antigas de ferramentas, compactar ou reiniciar sessões longas e medir o seu próprio orçamento seguro em vez de confiar na ficha técnica.

A Chroma Research colocou números nisso em 18 modelos em julho de 2025, e o termo se popularizou a ponto de a própria documentação da Anthropic agora defini-lo: "Conforme a contagem de tokens cresce, a precisão e o recall se degradam, um fenômeno conhecido como context rot." Uma janela anunciada maior eleva o teto do que você pode enviar. Ela não promete a mesma precisão no topo dessa faixa que na base.

A versão prática, para quem precisa decidir o que construir: a janela de contexto documentada é o que você tem permissão de enviar. Sua janela utilizável é onde o modelo ainda alcança a sua barra de qualidade. São números diferentes, e o segundo costuma ser uma fração do primeiro.

Essa diferença é o motivo de o argumento que circulou pelos canais de engenharia no fim de 2024 e no início de 2025 ("RAG está obsoleto agora, é só colar tudo lá dentro") ter envelhecido mal. As janelas realmente chegaram. A Anthropic torna 1M tokens o padrão no Claude Opus 5.5, no Sonnet 5.5 e no novo Haiku 5.5. Os modelos GPT-6 da OpenAI carregam uma janela de 1.05M tokens, dos quais 922K podem ser de entrada. O Gemini 3.1 Pro e o Gemini 3.8 Flash do Google aceitam cerca de 1M tokens de entrada. O Llama 4 Scout da Meta documenta 10M. O que não chegou foi um modelo que use todas as partes da sua janela igualmente bem.

Então a pergunta interessante deixou de ser "qual dos dois vence" e virou "qual padrão serve para este formato de dado, este orçamento de latência, este requisito de frescor e esta conta". É isso que o resto deste texto responde, começando pelo que a pesquisa mediu e por como corrigir o problema.

---

O que a pesquisa de context rot da Chroma mostrou

A manchete ("context rot existe") não faz jus ao trabalho. Em Context Rot: How Increasing Input Tokens Impacts LLM Performance, um relatório técnico publicado em 14 de julho de 2025 e o estudo a que a maioria das pessoas se refere quando fala em "o artigo do context rot", Kelly Hong, Anton Troynikov e Jeff Huber conduziram experimentos controlados em 18 modelos: Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5 e Haiku 3.5; o3, GPT-4.1 com suas versões mini e nano, GPT-4o, GPT-4 Turbo e GPT-3.5 Turbo; Gemini 2.5 Pro, 2.5 Flash e 2.0 Flash; e três tamanhos do Qwen3. Nem todo modelo rodou em todos os experimentos, por causa de limites de janela e de orçamento de raciocínio. O kit de replicação deles no GitHub permite rodar tudo de novo.

Quatro achados importam para a arquitetura.

O desempenho se degrada de forma desigual conforme a entrada cresce. Se você veio aqui atrás do gráfico do context rot, o formato é o ponto: não existe uma curva única. O próprio resumo da Chroma é que os modelos "não usam o seu contexto de forma uniforme; em vez disso, o seu desempenho fica cada vez menos confiável conforme o comprimento da entrada cresce". Quão rápido, e onde, depende do modelo e da tarefa, e é por isso que uma verificação pontual em um tamanho de contexto diz quase nada sobre o comportamento em outro. O time de engenharia da Anthropic descreve o mesmo padrão como "um gradiente de desempenho, e não um penhasco abrupto".

O tamanho da queda é grande. No LongMemEval, um benchmark de perguntas e respostas conversacionais, o time reduziu o conjunto a 306 prompts e comparou duas versões de cada um. A versão focada contém apenas o material relevante e tem em média cerca de 300 tokens. A versão completa enterra a mesma resposta na conversa ao redor e tem em média cerca de 113K tokens. O desempenho se degradou de forma consistente nas versões completas. Os modelos Claude mostraram a maior diferença, e a Chroma atribui boa parte dela à abstenção: o Claude Opus 4 e o Sonnet 4 muitas vezes se recusaram a responder em vez de chutar. Mesma pergunta, mesmo modelo, mesma resposta presente na entrada. A principal mudança foi quanto texto irrelevante veio junto.

A similaridade molda a queda. Quando a agulha é semanticamente menos parecida com a pergunta (a Chroma mediu isso com similaridade de embeddings), a precisão cai mais rápido conforme a entrada cresce. Distratores que se parecem com a resposta também prejudicam: até um único deles reduz o desempenho em relação à linha de base só com a agulha, e quatro deles agravam a queda. A posição, por outro lado, fez pouca diferença nesta tarefa. A Chroma não viu variação notável entre 11 posições da agulha, embora Liu et al. (2024), "Lost in the Middle", na TACL tenha encontrado uma curva em U em perguntas e respostas sobre vários documentos, na qual o meio de um contexto longo é sistematicamente subponderado.

Enchimento coerente prejudicou mais do que enchimento embaralhado. Este é o resultado que deveria mudar a forma como os engenheiros pensam. A intuição diz que um palheiro coerente deveria ser mais fácil de vasculhar do que um bagunçado. A Chroma encontrou o oposto, de forma consistente, nos 18 modelos: embaralhar as frases do palheiro e destruir seu fluxo lógico melhorou o desempenho. Por que isso acontece continua em aberto, e a Chroma vai só até dizer que a estrutura de uma entrada poderia influenciar como o mecanismo de atenção é aplicado. A parte acionável não precisa de mecanismo: enchimento coerente e dentro do assunto não é automaticamente inofensivo.

Mais um detalhe para levar para produção: os modos de falha são específicos de cada modelo. Sob distratores, os modelos Claude apresentaram as menores taxas de alucinação, com o Claude Sonnet 4 e o Opus 4 especialmente conservadores e inclinados a se abster quando incertos, enquanto os modelos GPT apresentaram as maiores e tenderam a responder com confiança, e de forma errada. Se você está escolhendo entre eles, está em parte escolhendo qual falha prefere depurar.

A Chroma não é o único time medindo isso. Se você procura um benchmark de context rot parecido com a sua carga de trabalho, estes são os principais:

Essa última linha é a que vale lembrar: mesmo quando um modelo recupera perfeitamente cada passagem relevante, uma entrada mais longa ainda custa precisão.

Para uma porta de entrada mais leve, Hamel Husain recebeu Kelly Hong para percorrer a pesquisa e publicou um resumo anotado dessa conversa. As conclusões batem com as do relatório: o desempenho não é uniforme entre os comprimentos de contexto, a forma como você apresenta a informação importa, e a engenharia de contexto deliberada é a alavanca.

---

Por que o contexto longo falha: o mecanismo

O mecanismo importa porque ele prevê quais cargas de trabalho quebram.

A atenção do Transformer roda um softmax sobre pares de tokens. Conforme o comprimento da sequência cresce, a atenção se espalha por mais posições. Mesmo com codificações de posição relativa como RoPE ou ALiBi, o denominador do softmax cresce e o peso disponível para qualquer token individual encolhe. Em 1M tokens, o token certo compete com outros 999,999 por um orçamento finito. Os engenheiros da Anthropic chamam isso de "orçamento de atenção": "Cada novo token introduzido consome parte desse orçamento."

As codificações de posição esticam o alcance sem remover o problema. O RoPE se degrada ao extrapolar muito além do comprimento de treinamento, então um modelo treinado em sequências de 32K e implantado em 1M está fazendo uma extrapolação que a matemática por baixo não sustenta totalmente. A Meta, por exemplo, fez o pré-treinamento e o pós-treinamento do Llama 4 Scout em 256K e documenta uma janela de 10M, então tudo o que passa de 256K depende de generalização de comprimento. YaRN, interpolação de posição e escalonamento NTK-aware ajudam, e nenhum deles produz um modelo que use 1M tokens tão bem quanto usa 32K.

Há também um problema de dados de treinamento. Mesmo quando um modelo treina em sequências longas, exemplos que exigem raciocínio genuíno ao longo de 800K tokens são raros. Os modelos aprendem a usar as partes do contexto que os dados de treinamento os ensinaram a usar.

Portanto, o context rot é uma propriedade da arquitetura e da distribuição de treinamento, e não um bug que a próxima versão corrige. Modelos futuros vão empurrar a fronteira mais para frente, e o formato da degradação vai persistir.

---

Terminação prematura: o que a pesquisa de 2026 acrescentou

O resultado novo mais útil desde a primeira publicação deste artigo veio do trabalho com agentes de horizonte longo, e não de trabalho com benchmarks.

Em Diagnosing and Mitigating Context Rot in Long-horizon Search, publicado pela primeira vez em junho de 2026 e revisado a fundo em agosto, Shijie Xia, Yikun Wang, Zhen Huang e Pengfei Liu estudaram quatro modelos de ponta de pesos abertos (GLM-4.7, GLM-5.0, Qwen3.5-397B-A17B e MiniMax-M2.5) em três benchmarks de busca profunda: BrowseComp, xbench-DeepSearch e BrowseComp-Plus, que faz buscas num corpus local fixo. Os modelos fechados ficaram de fora porque seus traços de raciocínio são criptografados. A versão revisada dá nome a um modo de falha que a literatura anterior tinha pulado: a terminação prematura. Sob um contexto grande, os modelos desistem, ou devolvem uma resposta errada que eles mesmos marcam como incerta, muito antes de esgotarem a janela. Controlando pela dificuldade da consulta, os autores descobriram que a taxa de terminação prematura sobe com o comprimento do contexto.

Isso reenquadra o problema. Context rot cobre duas falhas diferentes, e elas pedem correções diferentes. Se o modelo não consegue mais encontrar a agulha, melhore a precisão. Se o modelo para de procurar, ele precisa de espaço e de motivo para continuar explorando. Para um agente que faz busca em vários passos, confundir as duas custa semanas.

O segundo achado deles é o que vale roubar. Eles testaram sete métodos de gerenciamento de contexto em três famílias (compactação, poda e isolamento por meio de subagentes) e concluíram que esses métodos funcionam principalmente como estratégias de escalonamento em tempo de teste: ao cortar a taxa de terminação prematura, eles compram mais exploração para o modelo. Qual família ajuda depende do modelo. No modelo agêntico mais forte que eles compararam, o Qwen3.5-397B-A17B, isolar o trabalho em subagentes teve o melhor resultado. No mais fraco, o GLM-4.7, os subagentes ficaram entre as piores opções, e manter só os resultados de ferramentas mais recentes junto com um resumo deu o melhor equilíbrio entre precisão e custo. Os autores também construíram uma estratégia de filtragem consciente do comportamento para amostragem paralela que elevou a precisão média em 2.6 a 4.9 pontos percentuais em três métodos de agregação.

Se você roda agentes em sessões longas, acompanhe com que frequência os seus desistem cedo. É uma métrica barata e quase ninguém a instrumenta.

Outros três preprints de 2026, publicados entre julho e o início de outubro, empurram na mesma direção. Context as an Environment guarda as saídas das ferramentas como variáveis numa sessão Python persistente e deixa entrar no contexto só o que o agente imprime; com o mesmo modelo Qwen3.8-Max por baixo, ele marcou 86.7 por cento no benchmark LOCA com 256K tokens, contra 65.3 por cento de um agente que resume o próprio histórico. Stateless Language Agents reconstrói o contexto a cada chamada a partir do estado mantido pelo harness, em vez de carregar a conversa adiante, e em otimização de kernels alcançou o desempenho final da linha de base mais forte com mais de 84 por cento menos tokens. E o CompactionRL trata a compactação como uma habilidade a ser treinada, e não como um recurso acoplado depois: o modelo GLM-4.5-Air do CompactionRL marcou 6.6 pontos a mais no SWE-bench Verified do que o mesmo modelo base com compactação adicionada em tempo de inferência. São preprints, mas concordam quanto à direção: mantenha pequeno o conjunto de trabalho e torne o modelo bom em mantê-lo pequeno.

---

Como corrigir o context rot em agentes e ferramentas de chat

Toda correção que funciona faz a mesma coisa: coloca menos tokens, e melhores, na frente do modelo. O time de engenharia da Anthropic resume isso numa linha em Effective context engineering for AI agents: "O contexto, portanto, deve ser tratado como um recurso finito com retornos marginais decrescentes." O que muda é onde você aplica a regra.

Se você constrói apps ou agentes com LLM:

• Envie menos, e escolha bem. Recupere, reordene e descarte o que a tarefa não precisa. O guia de contexto longo do Google diz o mesmo: "Em geral, se você não precisa que os tokens sejam passados ao modelo, é melhor evitar passá-los."
• Coloque os documentos longos primeiro e a pergunta por último. Para entradas de 20K tokens ou mais, o guia de prompting da Anthropic recomenda os documentos no topo e a consulta no fim, observando que consultas no fim "podem melhorar a qualidade da resposta em até 30 por cento em testes". Ele também sugere pedir ao modelo que cite as passagens relevantes antes de responder. O Google dá a mesma orientação de posicionamento para o Gemini.
• Limpe resultados de ferramentas obsoletos. Resultados de busca antigos e despejos de arquivos são os tokens mais baratos de apagar. A Anthropic chama a limpeza de resultados de ferramentas de "uma das formas de compactação mais seguras e de toque mais leve" e a oferece como edição de contexto, que por padrão começa a limpar em 100,000 tokens de entrada e mantém os três usos de ferramenta mais recentes.
• Compacte antes de a janela encher, e teste o resumo. A API da Anthropic oferece compactação por limiar (gatilho padrão: 150,000 tokens de entrada) e, desde setembro de 2026, compactação sob demanda. A Responses API da OpenAI compacta no lado do servidor quando você define um compact_threshold dentro de context_management, e também expõe um endpoint de compactação avulso. Um resumo perde informação, então confira o que ele descarta. O conselho da Anthropic é começar maximizando o recall e depois cortar o que for supérfluo.
• Mantenha regras e estado fora do resumo. The Compaction Cliff in Long-Running AI Agent Memory, um artigo do CIKM 2026 publicado no arXiv em agosto, descobriu que o prompt de compactação do Claude Code, rodando no Sonnet 4.6, preservou 53 por cento das regras de segurança de configurações de agentes em produção depois de uma rodada e 10 por cento depois de cinco. A correção dos autores fixa as regras de segurança e os procedimentos palavra por palavra e comprime o resto por tipo, e manteve 96 por cento de recall ao longo de cinco rodadas. Então fixe as regras num lugar que o agente relê e guarde o progresso em notas, numa ferramenta de memória ou no git, e não no histórico do chat.
• Empurre a exploração para subagentes. Um subagente gasta o próprio contexto na busca e devolve "um resumo condensado e destilado do seu trabalho (muitas vezes de 1,000-2,000 tokens)", nas palavras da Anthropic. Mas teste no seu modelo: no artigo sobre terminação prematura, os subagentes tiveram o melhor resultado no mais forte dos dois modelos comparados e ficaram entre os piores no mais fraco. Explicamos como subagentes, skills e hooks se encaixam no nosso guia de engenharia agêntica.
• Meça por tamanho de contexto. Pontue a sua própria avaliação em vários comprimentos de entrada e registre as desistências antecipadas. Sem isso, toda correção acima é um chute.

A Anthropic publicou números para a combinação. Numa avaliação interna de busca agêntica, a ferramenta de memória da Anthropic combinada com a edição de contexto melhorou o desempenho em 39 por cento em relação à linha de base, e a edição de contexto sozinha, em 29 por cento. Num teste de busca na web com 100 turnos, a edição de contexto cortou o consumo de tokens em 84 por cento. São números de um fornecedor sobre o próprio produto, então leia-os como uma direção, e não como uma promessa.

Se você usa assistentes de chat ou agentes de código:

• Um chat por tarefa. O guia de boas práticas do Claude Code diz: "Uma sessão limpa com um prompt melhor quase sempre supera uma sessão longa com correções acumuladas." O guia do Codex da OpenAI concorda: "Mantenha um chat por unidade coerente de trabalho."
• Recomece depois de duas correções fracassadas. Essa é a regra prática do próprio Claude Code: rode /clear e escreva um primeiro prompt melhor, que inclua o que você aprendeu.
• Compacte nos seus termos. Claude Code, Codex e Cursor resumem automaticamente perto do limite. Compactar antes, com uma instrução de foco (por exemplo, /compact Focus on the API changes), te dá voz sobre o que sobrevive. O Claude Code avisa que "instruções detalhadas do início da conversa podem se perder", então regras persistentes pertencem a um arquivo que o agente relê, como o CLAUDE.md, e não ao chat.
• Fique de olho no medidor. O /context no Claude Code mostra o que está enchendo a janela, e o /status no Codex mostra quanto dela você já usou. O Cursor põe um anel de contexto ao lado da caixa de entrada, que abre um detalhamento quando você clica nele.

Comandos e padrões mudam entre versões, então considere a tabela válida para outubro de 2026 e confira a documentação da sua ferramenta depois de uma atualização.

---

Onde o RAG ainda vence

Diante de tudo isso, a geração aumentada por recuperação continua merecendo seu lugar. Eis onde ela segue vencendo.

Corpora de vários documentos em escala. Se a sua base de conhecimento tem 50,000 documentos somando 500M tokens, ela não cabe em janela nenhuma. Recuperação é a única arquitetura viável.

Frescor e atualidade. Bancos vetoriais atualizam de forma incremental. Um prompt de contexto longo precisa ser reconstruído sempre que o conteúdo muda. Para qualquer coisa que se atualize de hora em hora (notícias, catálogos, tíquetes de suporte, código), a recuperação lida com a mudança de forma barata.

Custo. O custo de entrada escala com os tokens de entrada e, acima de certos limiares, escala pior do que linearmente. Se 95 por cento das suas consultas podem ser respondidas a partir de 5K tokens relevantes, a recuperação sai várias vezes mais barata sem perda de precisão.

Citação e proveniência. A recuperação te entrega uma lista estruturada de fontes que você pode exibir, linkar e ordenar, enquanto ancorar uma resposta de contexto longo em fontes específicas exige encanamento extra. É a mesma razão pela qual uma ferramenta de leitura que guarda a passagem e a sua fonte vence uma que guarda um resumo: quando você faz perguntas sobre tudo o que salvou no Glasp, cada resposta pode apontar de volta para a fonte de onde ela veio.

Controle de acesso e multi-inquilino. Se o seu corpus tem visibilidade por usuário, por inquilino ou por papel, você não pode despejar tudo. A recuperação filtra por política antes de o modelo ver qualquer coisa. Isso é inegociável em B2B.

Raciocínio entre corpora. Quando a resposta atravessa uma thread do Slack, uma página do Notion, uma issue do Linear e um PR do GitHub, a recuperação é a ponte.

Se qualquer um desses casos se aplica, o RAG não é opcional. A pergunta passa a ser como tornar a recuperação boa, e não se você deve fazê-la.

---

Onde o contexto longo vence

O contexto longo tem cargas de trabalho em que ele é simplesmente a resposta certa.

Raciocínio profundo em um único documento. Ler um contrato de 100 páginas e responder cruzando cláusulas. Analisar um artigo. Percorrer uma teleconferência de resultados. Quando a resposta conecta dois parágrafos separados por 80 páginas, o chunking costuma cortar o elo.

Compreensão de código dentro de um repositório. Boa parte das tarefas de código precisa de imports, tipos, definições e pontos de chamada ao mesmo tempo. Fatiar por arquivo perde as relações entre arquivos.

Continuidade conversacional. Sessões longas de agente se beneficiam de um histórico de verdade. Recuperação sobre histórico de conversa é frágil, porque em geral você precisa dos últimos 50 turnos, e não dos 50 semanticamente mais parecidos.

Raciocínio exploratório quando você ainda não sabe a consulta. Se você não consegue escrever a consulta com antecedência, fica difícil mirar a recuperação. O contexto longo deixa o modelo navegar.

Referência cruzada dentro de uma unidade coerente. Um capítulo de livro-texto, um artigo, uma petição jurídica. Fatiar e remontar essas coisas tende a perder o argumento.

Heurística grosseira: se os seus dados são um único documento lógico e cabem dentro do seu orçamento seguro medido, o contexto longo é a arquitetura mais limpa.

---

O padrão híbrido em que a maioria dos times acaba

O padrão de 2026 para sistemas sérios não é nem RAG puro nem contexto longo puro. Recupere um conjunto substancial, mas limitado, de tokens, e então raciocine sobre eles.

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

Cada estágio cobre o modo de falha do outro. A recuperação reduz a algo administrável um corpus grande demais para qualquer janela. Raciocinar sobre todo o conjunto recuperado restaura o raciocínio entre chunks que o RAG clássico de top-5 joga fora.

A decisão que sustenta tudo é o tamanho do conjunto recuperado. Poucos tokens demais e você só reconstruiu o RAG de top-5. Tokens demais e você está na zona de context rot, pagando mais por uma resposta pior. Uma regra prática que funciona, e que a próxima seção transforma em medição: planeje um orçamento seguro em torno de 20 a 40 por cento da janela documentada e depois verifique isso nos seus próprios dados. Para um modelo com janela de 200K, são 40K a 80K. Para um modelo com janela de 1M, são 200K a 400K, que, por coincidência, é mais ou menos onde a cobrança muda na OpenAI e no Gemini 3.1 Pro.

---

Ajustando o híbrido: números e heurísticas

Estas não são verdades universais. São pontos de partida que se sustentam em produção.

Tamanho do chunk. De 500 a 1,500 tokens para prosa. De 200 a 500 para código, por função ou bloco lógico. De 1,500 a 3,000 para texto jurídico ou acadêmico, em que o contexto interno ao chunk carrega significado. Sobreponha de 10 a 20 por cento.

Recuperação top-k. Puxe mais do que você vai enviar. Recupere os 50 a 200 melhores e depois reordene. Um cross-encoder custa mais por par do que um modelo de embedding e é dramaticamente melhor em relevância de granularidade fina.

Proporção entre rerank e contexto. Fique com os 20 a 100 melhores chunks depois do rerank. O número exato decorre do tamanho do chunk e do seu orçamento seguro.

Recuperação híbrida. Combine denso e esparso (BM25, SPLADE) com fusão recíproca de rankings (RRF). Denso sozinho perde correspondências exatas como SKUs, códigos de erro e nomes próprios. Esparso sozinho perde paráfrases.

Dois desses parâmetros merecem mais do que um marcador, porque é neles que os times perdem precisão sem perceber.

O primeiro é o seu orçamento de contexto seguro, e a única forma honesta de defini-lo é medir. Monte um pequeno conjunto de avaliação com perguntas que exijam raciocínio sobre vários chunks e então pontue a precisão com 16K, 32K, 64K, 128K e 256K de contexto empilhado. Pegue o maior tamanho que ainda passa da sua barra e opere 20 por cento abaixo dele para ter folga. Esse número medido deve cair perto da regra de 20 a 40 por cento acima e, quando não cair, confie na sua avaliação em vez da heurística. Se você ainda não tem um harness de avaliação, o nosso guia sobre o stack de evals para LLMs cobre o ferramental.

O segundo é o que acontece quando você troca de modelo, e foi isso que pegou vários times de surpresa em 2026. O tokenizador da Anthropic mudou com o Claude Opus 4.7, e o mesmo texto agora corresponde a algo entre 1.0 e 1.35 vezes a quantidade de tokens de antes, dependendo do conteúdo, o que a Anthropic resume como cerca de 30 por cento a mais. O Haiku 5.5, lançado em 7 de outubro, também usa o tokenizador mais novo, então um pipeline que sobe do Haiku 4.5 conta cerca de 30 por cento mais tokens para o mesmo texto. Seus documentos não cresceram. Seu orçamento encolheu. Se você fixou um teto de tokens um ano atrás e trocou o modelo por baixo dele, aquele teto significa outra coisa agora, e nada nos seus logs vai avisar.

Pule a recuperação por completo quando a consulta pedir isso. "Resuma o documento que acabei de enviar" é uma tarefa de documento único. Detecte esses casos com um classificador pequeno, pule a recuperação, economize latência e evite trazer ruído sem relação.

Camadas de sumarização e poda. Para históricos muito longos, comprima o material mais antigo antes da montagem. Resumos também custam tokens, então meça se eles de fato ajudam.

---

Antipadrões que os engenheiros continuam entregando

Algumas armadilhas se repetem com frequência suficiente para merecerem nome.

"É só jogar tudo no contexto." Tentador depois de cada lançamento que dobra a janela. A degradação é silenciosa, então você passa nas verificações pontuais e falha em produção exatamente nas consultas que precisavam de raciocínio entre contextos. Rode uma avaliação no seu tamanho alvo antes de entregar.

"Sempre use RAG." Recuperação reflexa perde os casos de documento único. Indexar um PDF de 50 páginas e puxar os 5 melhores chunks costuma ser melhor do que nada e perde para simplesmente enviar o PDF.

"Ignore a contagem de tokens do contexto montado." Os times definem o top-k como "o que couber" e três meses depois descobrem que o prompt médio deles tem 350K tokens, que a precisão escorregou em silêncio e que a conta dobrou num limiar que ninguém leu. Trate o tamanho do contexto montado como métrica de primeira classe e configure alertas para ele.

"Deixe a compactação automática cuidar disso." A compactação automática mantém uma sessão viva. Ela não a mantém precisa. Resumos descartam instruções, e o artigo do Compaction Cliff viu a retenção das regras cair rodada após rodada. Decida o que precisa sobreviver e guarde isso fora da conversa.

"Pule as avaliações porque o modelo agora é bom." Trocas de modelo mudam qual arquitetura é a certa e, às vezes, mudam a sua contabilidade de tokens por baixo. Reavalie quando os modelos mudarem.

"Suponha que uma falha silenciosa é uma falha segura." Sob distratores, alguns modelos alucinam e outros se abstêm, e em trabalho de horizonte longo alguns simplesmente param cedo. Saiba qual é o caso do seu, e instrumente para isso.

---

O que mudou em 2026: modelos, preços e compactação

A maior parte do que vem a seguir mudou entre setembro e o início de outubro de 2026, quando Anthropic, OpenAI e Google lançaram modelos novos, e nem tudo aponta para o mesmo lado.

A linha de modelos se renovou. A Anthropic lançou o Claude Fable 5.1 em 1º de setembro, o Opus 5.5 em 22 de setembro, o Sonnet 5.5 em 28 de setembro e o Haiku 5.5 em 7 de outubro, todos com janelas de 1M tokens. A OpenAI lançou o GPT-6 Astra em 3 de setembro, o GPT-6 Sol e o Luna em 22 de setembro e o GPT-6.1 Sol em 29 de setembro, cada um com uma janela de 1.05M e até 922K tokens de entrada. O Google colocou o Gemini 3.8 Flash em disponibilidade geral em 2 de setembro, enquanto o Gemini 3.1 Pro continua sendo um modelo em preview.

As melhores pontuações de recuperação deram um salto, e a distância entre os modelos é enorme. No OpenAI MRCR v2, o teste de 8 agulhas da própria empresa, a OpenAI informa 96.3 por cento para o GPT-6 Astra entre 512K e 1M tokens, contra 73.8 por cento do GPT-5.6 Sol. O model card do Google avalia o Gemini 3.1 Pro no MRCR v2 (8 agulhas) do próprio Google, um conjunto de dados diferente apesar do nome igual: 84.9 por cento na média até 128K e 26.3 por cento em 1M. Então a diferença entre fornecedores é um sinal, não um resultado de confronto direto. Os dois conjuntos de números são medidos pelos próprios fornecedores (a OpenAI informa a melhor pontuação em qualquer nível de esforço de raciocínio), e o MRCR mede a capacidade de encontrar e reproduzir a passagem certa, não de raciocinar ao longo de um documento. O context rot não foi embora. Virou algo que você precisa medir modelo a modelo.

Os penhascos de preço agora são diferentes em cada fornecedor. A OpenAI ainda reprecifica a requisição inteira acima de 272K tokens de entrada e, nos modelos GPT-6, isso significa "2x nas tarifas de entrada e de cache e 1.5x na saída". O GPT-6.1 Sol vai de $2 e $10 por milhão de tokens de entrada e de saída para $4 e $15, e o GPT-6 Astra, de $10 e $50 para $20 e $75. Os $4 e $20 do GPT-5.6 Sol são um preço promocional que vale pelo menos até 21 de novembro de 2026 e, acima do mesmo limiar de tokens, sobem para $8 e $30. O Google cobra os prompts do Gemini 3.1 Pro acima de 200K a $4 e $18 em vez de $2 e $12, mas o Gemini 3.8 Flash não tem essa faixa. A Anthropic cobra a janela inteira de 1M pelas tarifas padrão no Claude 4.6 e posteriores ("Uma requisição de 900k tokens é cobrada pela mesma tarifa por token que uma requisição de 9k tokens", segundo a sua página de preços), com uma exceção: no Haiku 5.5, prompts acima de 100,000 tokens custam cinco vezes mais, $0.50 e $2.50 em vez de $0.10 e $0.50.

A compactação virou produto. As configurações já foram cobertas nas correções acima. O que mudou é que agora os fornecedores fazem a compactação por você. A documentação da Anthropic recomenda a sua nova compactação sob demanda "onde quer que esteja disponível". A Responses API da OpenAI devolve o contexto compactado como um item opaco que não foi feito para ser lido por humanos, e a sua Agents API, em beta pública desde 10 de setembro, diz: "A OpenAI cuida da orquestração da sessão, da compactação do contexto e da recuperação de falhas." Mas repare no valor padrão: um fornecedor com uma janela de um milhão de tokens começa a compactação por limiar em 150K.

O cache ficou mais barato. Continua sem resolver o context rot. Leituras de cache custam um décimo do preço base de entrada na maioria dos modelos da Anthropic, um vigésimo no Opus 5.5 e no Sonnet 5.5, e um quadragésimo no Fable 5.1. A OpenAI cobra um décimo na maioria dos modelos e um vigésimo no GPT-6.1 Sol e, desde o GPT-5.6, cobra as escritas em cache a 1.25 vezes a tarifa de entrada. O cache torna consultas repetidas sobre conteúdo estável muito mais baratas. Ele não muda o que o modelo faz com uma entrada longa e, na OpenAI, tokens em cache dobram de preço acima de 272K, assim como a entrada sem cache.

O que não mudou é o resultado de fundo. Modelos melhores deslocam a curva, uma janela maior sozinha não conserta nada, e você ainda precisa de recuperação para cargas de trabalho com dados frescos, multi-inquilino e de várias fontes.

Essa é a mesma disciplina que aparece na engenharia de contexto em geral: o que você deixa de fora do prompt importa tanto quanto o que você coloca. É também por isso que a camada de recuperação merece o mesmo escrutínio de qualquer outro caminho de entrada, já que a injeção indireta de prompt chega através de documentos recuperados, e não através dos seus usuários.

---

Um framework de decisão que você pode aplicar hoje

Percorra isto de cima a baixo para qualquer funcionalidade nova com LLM.

Passo 1: qual é o tamanho do seu corpus?

• Abaixo de 100K tokens no total: pule a recuperação, use contexto longo.
• De 100K a 1M tokens: depende do frescor, vá para o Passo 2.
• Acima de 1M tokens: recuperação é obrigatória.

Passo 2: quão frescos os dados precisam ser?

• De hora em hora ou mais rápido: recuperação. Reconstruir prompts longos é caro demais.
• De diário a semanal: qualquer um dos padrões funciona.
• Estático: contexto longo com cache de prompt é barato e limpo.

Passo 3: qual é o formato da consulta?

• Raciocínio profundo em um único documento: puxe para contexto longo.
• Síntese entre vários documentos: puxe para híbrido.
• Consulta pontual ou busca de fato: puxe para RAG clássico.
• Exploratório: contexto longo se o conjunto de documentos for limitado, senão híbrido.

Passo 4: você precisa de citação ou de controle de acesso?

• Sim para qualquer um dos dois: recuperação é obrigatória. Adaptar citações e filtragem por usuário num design só de contexto longo é doloroso.

Passo 5: qual é o seu orçamento de latência?

• Abaixo de 1 segundo: RAG clássico.
• De 1 a 5 segundos: híbrido é viável.
• Acima de 5 segundos: qualquer padrão funciona.

Passo 6: qual é o seu piso de precisão em consultas longas?

• Alta precisão em raciocínio de vários passos acima de 50K tokens: híbrido com reranker.
• Melhor esforço: o RAG clássico costuma bastar.

Passo 7: onde o seu prompt montado cai em relação ao penhasco de preço?

• Abaixo de 272K na OpenAI, abaixo de 200K no Gemini 3.1 Pro, abaixo de 100K no Claude Haiku 5.5 ou, nos demais casos, abaixo do seu orçamento seguro medido: tudo bem.
• Pairando perto de uma dessas linhas: adicione um reranker e corte o conjunto recuperado. Você normalmente vai obter uma resposta melhor e uma conta menor ao mesmo tempo.

Passo 8: isso vai rodar como uma sessão longa ou como um agente?

• Sim: decida de antemão o que é limpo (resultados antigos de ferramentas), o que é compactado, o que fica fora da conversa (regras, progresso) e quando o agente recomeça do zero. Registre as desistências antecipadas.
• Não: requisições de uma única chamada só precisam dos Passos 1 a 7.

A maioria dos sistemas em produção acaba no híbrido, porque cargas de trabalho reais carregam pelo menos uma restrição que quebra o contexto longo puro (multi-inquilino, frescor, custo, citação) e pelo menos uma que quebra o RAG puro de top-k (raciocínio em documento único, consultas entre contextos, exploração).

Existe uma versão humana dessa mesma habilidade. Decidir o que merece entrar na frente de um processo de raciocínio é o que leitores atentos sempre fizeram à mão, e destacar é essa decisão tornada explícita. O destacador web do Glasp guarda as passagens que você julgou dignas de guardar em vez da página inteira, o que é recuperação com um reranker humano. Se você quiser apontar as suas próprias ferramentas para esse conjunto, o conector MCP do Glasp expõe seus destaques diretamente para um LLM. Escrevemos mais sobre essa configuração em transformando suas anotações em um servidor MCP.

---

Perguntas frequentes

O que é context rot em LLMs?

Context rot é a queda medida em quão bem um LLM usa a sua entrada conforme essa entrada cresce, bem antes de a janela de contexto encher. A precisão em recuperação e em raciocínio cai de forma desigual, em graus diferentes para modelos diferentes, e mais rápido quando o texto distrator se parece com a resposta. A Chroma descobriu que um palheiro coerente prejudicou mais do que um embaralhado em todos os 18 modelos que testou, e a documentação da Anthropic agora define o termo diretamente: "Conforme a contagem de tokens cresce, a precisão e o recall se degradam, um fenômeno conhecido como context rot." Encher uma janela de 1M tokens não te compra uma resposta com qualidade de 1M tokens.

Como corrigir o context rot?

Envie menos tokens, e melhores. Em apps e agentes, isso significa recuperar e reordenar em vez de empilhar, colocar os documentos longos antes da pergunta, limpar resultados de ferramentas obsoletos, compactar antes de a janela encher, manter regras e progresso fora da conversa e entregar a exploração a subagentes. Em ferramentas de chat e de código, significa um chat por tarefa, recomeçar depois de duas correções fracassadas, compactar cedo com uma instrução de foco e manter as regras persistentes num arquivo que o agente relê, como o CLAUDE.md.

Modelos mais novos como o Claude Opus 5.5 ou o GPT-6 resolvem o context rot?

Nenhum modelo é imune, mas a distância entre os modelos é grande. A OpenAI informa 96.3 por cento para o GPT-6 Astra no seu MRCR de 8 agulhas entre 512K e 1M tokens, enquanto o model card do Google mostra o Gemini 3.1 Pro com 26.3 por cento em 1M na versão do teste do próprio Google. Os conjuntos de dados são diferentes, mas a diferença é grande demais para ignorar. A documentação da Anthropic descreve o context rot como uma propriedade geral de entradas que crescem, e a documentação do Claude Code diz, sobre a janela de contexto, que o desempenho "se degrada conforme ela enche". Meça o modelo que você realmente usa, com entradas parecidas com as suas.

O RAG ainda é relevante em 2026?

Sim. A recuperação continua obrigatória para corpora que excedem qualquer janela, para dados que mudam de hora em hora, para controle de acesso por inquilino e para citação. O que está ultrapassado é o RAG clássico de top-5 como único padrão. O padrão atual é híbrido: recupere um conjunto limitado e depois raciocine sobre ele inteiro. Janelas de contexto maiores mudaram quanto você recupera, não se você recupera.

O contexto longo substitui o RAG?

No caso geral, não. O relatório Context Rot da Chroma mostrou o desempenho se degradando muito antes de a janela encher, e os fornecedores constroem como se concordassem: a compactação por limiar da Anthropic assume por padrão 150K em modelos de 1M tokens, a OpenAI reprecifica requisições acima de 272K tokens de entrada, e o Google cobra mais por prompts do Gemini 3.1 Pro acima de 200K. O contexto longo substitui, sim, o RAG para um único documento limitado que caiba dentro do seu orçamento seguro medido.

Qual deve ser o tamanho do meu conjunto recuperado antes de o context rot aparecer?

Teste o seu modelo específico, mas um ponto de partida razoável é de 20 a 40 por cento da janela documentada. Isso dá 40K a 80K para um modelo de 200K e 200K a 400K para um modelo de 1M, embora na OpenAI você vá querer ficar abaixo de 272K por motivos de cobrança, no Gemini 3.1 Pro abaixo de 200K e no Claude Haiku 5.5 abaixo de 100K. Monte uma avaliação pequena com perguntas de vários saltos, meça a precisão ao longo dos tamanhos de contexto e fique com o maior tamanho que ainda passa da sua barra.

O cache de prompt resolve o context rot?

Não. O cache resolve custo, não precisão. Leituras em cache agora custam entre um décimo e um quadragésimo do preço normal de entrada, dependendo do modelo, então consultas de contexto longo sobre conteúdo estável ficam bem mais baratas e a vantagem de custo do RAG diminui. O modelo continua lendo o mesmo contexto longo e se degradando do mesmo jeito, então você está pagando menos pela mesma resposta mais fraca. Na OpenAI, tokens em cache também dobram de preço acima de 272K.

Devo usar um reranker antes de mandar para o contexto longo?

Para a maioria dos sistemas híbridos em produção, sim. Um cross-encoder pontuando os seus 50 a 200 melhores chunks recuperados melhora muito o que chega ao estágio de raciocínio. Pular o rerank normalmente significa empilhar mais tokens para compensar a precisão mais fraca, o que te empurra tanto para a zona de context rot quanto para o penhasco de preço. É uma das mudanças de maior impacto que você pode fazer num pipeline híbrido.

Meu agente para cedo em tarefas longas. Isso é context rot?

Provavelmente, e agora isso tem nome. O artigo de 2026 Diagnosing and Mitigating Context Rot in Long-horizon Search chama isso de terminação prematura: sob contexto pesado, os modelos desistem ou devolvem uma resposta errada que eles mesmos marcam como incerta antes de esgotar a janela, a uma taxa que sobe com o comprimento do contexto. O gerenciamento de contexto (compactação, poda ou subagentes) ajuda principalmente por cortar essa taxa, de modo que o agente continue explorando. Instrumente as desistências antecipadas como métrica própria.

---

Considerações finais

Todo lançamento com uma janela maior carrega a mesma promessa implícita: pare de fazer engenharia, é só despejar. A Chroma colocou números concretos no motivo de essa promessa não ter se cumprido, o trabalho de 2026 acrescentou um segundo modo de falha que ninguém estava observando, e a matemática por baixo (diluição do softmax, extrapolação de posição, distribuição de treinamento) diz que ela também não vai se cumprir direito em 100M tokens.

O que resta é a resposta chata e produtiva. Construa recuperação. Ajuste. Adicione um reranker. Limpe o que o modelo não precisa mais e guarde fora da conversa o que ele nunca pode perder. Escolha um orçamento de contexto seguro medindo, em vez de confiar numa ficha técnica, e meça de novo quando o modelo ou o seu tokenizador mudar, o que, entre setembro e o início de outubro de 2026, aconteceu igualmente na Anthropic, na OpenAI e no Google. Envie o conjunto de tokens menor e mais relevante que contenha a resposta. Deixe o modelo raciocinar sobre isso. Cite as fontes.

A novidade de 2026 é que os fornecedores agora projetam como se concordassem com você. A linha da OpenAI em 272K, a do Google em 200K no Gemini 3.1 Pro, a do Haiku 5.5 em 100K e um gatilho padrão de compactação em 150K nos modelos Claude de um milhão de tokens são todas admissões de que a janela utilizável é uma fração da anunciada. A tarifa uniforme da Anthropic nos seus modelos maiores remove o penhasco de preço, mas não o custo em precisão, e menos tokens continuam custando menos com uma tarifa uniforme. Então a arquitetura disciplinada também é a barata, e essas duas raramente apontam para a mesma direção.

Se você quiser um mapa mais amplo de qual modelo apontar para qual tarefa, mantemos um na matriz de tarefas e modelos de IA. Decisões de arquitetura duram mais do que lançamentos de modelo. Acerte essas e a próxima atualização será uma melhoria de graça em vez de uma reescrita forçada.