Context rot: o que a pesquisa realmente diz — e os números que o nicho inventou em cima dela

Foto: Pavel Danilyuk via Pexels

A Chroma — a empresa do banco de dados vetorial de mesmo nome — publicou um estudo chamado Context Rot: How Increasing Input Tokens Impacts LLM Performance. Dezoito modelos testados. Um único distrator — um trecho que parece a resposta, mas não é — já basta para derrubar o desempenho. E os modelos vão melhor com o contexto embaralhado do que com texto coerente.

Agora o outro placar, o que interessa mais: dois números e um jargão são atribuídos a esse paper todos os dias, em português e em inglês, e nenhum dos três está nele.

Eu abri a fonte. Cinco vezes, com perguntas diferentes, porque não acreditei na primeira. Achei duas coisas erradas nas minhas próprias anotações. É disso que trata este artigo.

O que o paper realmente mediu

Context rot é o nome que a comunidade deu para a degradação do modelo conforme o contexto cresce. O estudo da Chroma é a tentativa de medir isso.

A premissa que ele derruba está logo na abertura, e é a premissa que você e eu carregamos sem perceber:

"Large Language Models (LLMs) are typically presumed to process context uniformly—that is, the model should handle the 10,000th token just as reliably as the 100th. However, in practice, this assumption does not hold."

O achado central, verbatim:

"We observe that model performance varies significantly as input length changes, even on simple tasks. (…) Our results reveal that models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows."

São 18 modelos de verdade, com nome: Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5 e Haiku 3.5; o3, GPT-4.1 (mais mini e nano), GPT-4o, GPT-4 Turbo e GPT-3.5 Turbo; Gemini 2.5 Pro, 2.5 Flash e 2.0 Flash; Qwen3-235B-A22B, 32B e 8B. Não é um modelo velho tendo um dia ruim. É todo mundo.

Repare no even on simple tasks. Não é raciocínio difícil quebrando sob carga. É tarefa boba degradando só porque a entrada cresceu.

E agora repare no que a frase mede: input length. Comprimento da entrada. Não "quanto da sua janela você já gastou".

Essa distinção parece chata e é o artigo inteiro.

A variável do estudo é o tamanho do que entra — não a fração de uma capacidade. E não existe no relatório nenhuma afirmação de que "a degradação começa antes da janela encher". Eu procurei essa formulação literalmente, string por string, porque eu mesmo já tinha escrito ela. Não está lá. O que está lá é mais simples e pior: conforme a entrada cresce, o desempenho fica cada vez menos confiável. Sem limiar. Sem "a partir de tal ponto você deve se preocupar".

A conclusão sobre janela, então, é minha, não do paper — e eu prefiro assim, porque assinada ela fica até mais forte. Se a confiabilidade cai em função do tamanho da entrada, aumentar a janela não trata nada: janela maior não faz a sua entrada encolher. Ela só te dá permissão para deixar a entrada crescer mais. É o remédio que agrava a doença, vendido a cada anúncio de "agora com 1 milhão de tokens".

O achado que ninguém explica: embaralhar o contexto melhora o resultado

Esta é a parte mais interessante do paper e a que menos aparece nos resumos — provavelmente porque é a mais difícil de transformar em dica prática.

O vocabulário primeiro, porque ele é preciso. Haystack é o palheiro: o texto longo em que se esconde a informação buscada. Needle é a agulha, o fato que o modelo tem que achar. Distractors são trechos que parecem a resposta, mas não são.

Sobre distratores, o paper é direto:

"Even a single distractor reduces performance relative to the baseline (needle only), and adding four distractors compounds this degradation further."

Um. Um único trecho parecido-mas-errado já cobra pedágio.

E aí vem a estranheza. O que acontece se você pegar o palheiro e destruir a coerência dele — embaralhar as frases até virar sopa?

"Although it seems counterintuitive, models perform worse when the haystack preserves a logical flow of ideas. Shuffling the haystack and removing local coherence consistently improves performance."

Consistently. Não em um modelo. Consistentemente.

Pare um segundo nisso. Um texto bem escrito, com fluxo lógico, é pior para o modelo do que o mesmo texto picotado e jogado no liquidificador. Toda a sua intuição de "vou documentar isso direitinho pra IA entender melhor" acabou de levar uma paulada.

Aqui eu preciso parar e ser explícito: os autores não explicam esse resultado. Eles dizem que a estrutura do input "could influence how the attention mechanism is applied" e apontam interpretabilidade mecanicista como trabalho futuro. Ou seja: mediram, confirmaram nos 18, e deixaram a causa em aberto.

O que vem agora é leitura minha, e você deve tratar como especulação — não como conclusão do paper. Se um texto coerente atrapalha e a sopa ajuda, o que a coerência oferece a mais? Distratores melhores. Um documento bem escrito sobre um assunto é, por construção, uma coleção densa de trechos plausivelmente relevantes. Ele não é ruído: é concorrência qualificada. Embaralhado, o texto vira ruído óbvio — e ruído óbvio é fácil de descartar.

Se essa leitura estiver certa, ela reenquadra a coisa toda: o modelo não está lendo seu contexto e entendendo. Ele está disputando relevância entre pedaços. E você, escrevendo bem, está fabricando adversários mais fortes para a sua própria informação.

Guarde essa frase, porque o resto do artigo depende dela: o problema não é volume, é competição.

Os números que não estão no paper

Agora a parte de serviço público.

Procure "context rot" em português e você vai colidir com dois números, sempre os mesmos, sempre com a Chroma como fonte:

• "Queda de 30%+" de acurácia.
• "Orçamento seguro de 150K–400K tokens."

Eu abri o relatório procurando os dois, especificamente, com perguntas desenhadas para encontrá-los. Depois procurei as strings cruas: 30%, 150K, 400K. Não existem. Não aparecem em lugar nenhum da página. Não há percentual de queda declarado — há gráficos e comparações relativas. E não há recomendação de teto de tokens, nenhuma. O paper não te dá um número seguro porque ele não mediu um número seguro.

De onde vieram, então? De blogs de conteúdo — morphllm e glasp aparecem entre os primeiros — que citaram um estudo que não leram, e viraram fonte um do outro. Repetição em círculo. Cada cópia parecendo confirmação da anterior.

Enquanto pesquisava isto, eu vi o processo acontecer ao vivo. Rodei uma busca num buscador daqueles que hoje colocam um resumo escrito por IA acima dos links, perguntando exatamente se esses números existiam. O resumo gerado por IA — antes dos resultados, com cara de resposta pronta — afirmou, com todas as letras, que o orçamento de 150K–400K e a queda de ~30% são "well-supported findings from Chroma's research". A camada que deveria me ajudar a checar já tinha engolido a invenção e me servia ela de volta como fato consolidado, com a fonte primária listada logo ali embaixo, a um clique, contradizendo tudo.

É o context rot do ecossistema. Distratores plausíveis vencendo a fonte.

Eu não caí nesses dois. Caí em outros dois.

E antes que isso soe como superioridade: eu não sou o cara esperto da história.

Nas minhas anotações para escrever este artigo — as minhas, escritas por mim — estava listado, como vocabulário do paper, o termo "lost in the middle". Eu ia usar. Fazia todo sentido, casa perfeitamente com o assunto.

Fui conferir. A expressão não aparece no relatório da Chroma. Nem no corpo, nem nas referências. Conferi duas vezes porque não acreditei.

"Lost in the middle" é de outro paper: Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL, 2023 — o achado de que o desempenho é melhor quando a informação relevante está no começo ou no fim do input, e degrada no meio. Trabalho real, efeito real, fonte diferente. Os blogs fundiram os dois num troço só e penduraram tudo na Chroma. Minha nota tinha herdado a fusão sem eu perceber.

E teve a segunda, que é pior, porque essa eu não só acreditei — eu ensinei.

A mesma nota dizia que o achado da Chroma é que "a degradação começa antes da janela encher". Eu achava isso tão sólido que já tinha escrito essa frase num artigo anterior desta série, e usei ela para corrigir outra pessoa que, na minha cabeça, tinha entendido errado. Corrigir. Com a autoridade de quem leu o paper.

Eu não tinha lido o paper. Tinha lido um resumo do paper.

Quando fui atrás da frase literal para este artigo, ela não estava lá. O paper mede input length e diz que a confiabilidade cai conforme a entrada cresce. A moldura de "janela enchendo" não é dele — é do nicho, e eu tinha reembalado e devolvido como se fosse ciência. Já corrigi o artigo anterior: a conclusão sobre janela continua lá, mas agora assinada como inferência minha, que é o que ela sempre foi. Este parágrafo é o registro de que ele precisou ser corrigido.

Repare no mecanismo, porque é o ponto inteiro: não teve má-fé em lugar nenhum dessa cadeia. Ninguém mentiu. Cada elo repetiu, com confiança sincera, uma coisa plausível que recebeu de um elo anterior confiável. Foi assim que "30%" nasceu, foi assim que "lost in the middle" migrou de paper, e foi assim que eu — escrevendo um artigo sobre atribuição falsa — quase publiquei duas atribuições falsas.

A única coisa que impediu não foi eu ser cuidadoso. Foi eu ter aberto a fonte. É a diferença inteira, e ela custa cinco minutos.

Na mesma linha, um número que eu não vou usar. Numa thread do Hacker News sobre o assunto, um comentarista afirma que "LLMs flip positions when users push back ~70% of the time". Excelente frase. Sem paper, sem link, sem nada. É opinião de alguém na internet, e opinião de alguém na internet com número no meio continua sendo opinião de alguém na internet. Eu quis muito usar. Fui atrás. Não existe.

O que a mesma thread oferece de valor é relato qualitativo, e como relato eu uso: "Some bad idea gets embedded into the context that you just can't argue away". Todo mundo que roda agente em projeto de verdade reconhece a cena — a ideia errada que grudou, que você não consegue argumentar pra fora, e que só sai com reset. Isso é experiência compartilhada, não medição. Rotulado como tal.

Então quanto de contexto é demais?

Aqui vem a parte incômoda, e é onde este artigo vai te frustrar de propósito.

Se o paper não dá um número seguro, eu também não posso dar. Seria repetir o crime que acabei de denunciar, só que com a minha assinatura.

A resposta honesta para "quanto de contexto é demais?" é: depende, e ninguém mediu isso pro seu caso. Depende do modelo, da tarefa, de quão parecida a sua pergunta é com a informação que você procura, e de quantos distratores o seu próprio repositório fabrica. O paper mostra que os modelos não usam o contexto de forma uniforme — o que é precisamente o motivo de não existir uma constante mágica pra você anotar na config.

É por isso que o "orçamento seguro de 150K–400K" pegou tão bem, aliás. Ele é reconfortante. Dá um número pra colar no YAML e uma sensação de controle. A verdade não tem essa cortesia.

A ausência de resposta é a resposta. E ela empurra a solução pra outro lugar.

Por que a saída é arquitetural, e não numérica

Junte as pontas. A confiabilidade cai conforme a entrada cresce. Um único distrator já cobra caro. Texto coerente compete melhor pela atenção do que sopa.

Se o problema fosse espaço, a saída seria comprar janela. Como o problema é atenção disputada por coisa irrelevante, a única saída que ataca a causa é o irrelevante não estar lá. Não "estar lá compactado". Não "estar lá bem escrito". Não estar.

Isso não é dica de prompt. É decisão de arquitetura, e é a que eu tomei no meu repositório de trabalho — um monorepo onde convivem, lado a lado, todos os sistemas que eu opero com agente de código: o blog, os carrosséis, os e-mails, os anúncios. É exatamente o tipo de repo que fabrica distrator: qualquer coisa que a IA leia sobre um desses sistemas é ruído qualificado para os outros onze. A decisão foi fatiar. O sistema é dividido em 12 micro-projetos independentes, declarados em roteador/routes.json, cada um com sua própria memória e seus próprios agentes. Nenhum sabe da existência do outro. Na frente de tudo tem um roteador que responde uma única pergunta antes de qualquer tarefa começar: qual é o menor pedaço do sistema que essa IA precisa conhecer agora?

O resto não é resumido. Não é priorizado. Ele simplesmente não entra no turno. Entrada que não entra não compete — e não apodrece.

Repare que isso é o oposto do instinto. O instinto é enriquecer o contexto: mais documentação, mais exemplos, mais CLAUDE.md. Cada adição é bem-intencionada, e cada uma é um distrator a mais competindo contra a informação que a tarefa de agora realmente exige.

E agora a trava de honestidade, porque sem ela eu viro o que critiquei: essa arquitetura nasceu no commit 4296eb4, de 14/07/2026 — a mesma data em que escrevo isto. Tenho dias de estrada. Não tenho benchmark, não tenho antes-e-depois numérico, não tenho percentual de melhora. Se eu te desse um, ele seria inventado, e você deveria fechar a aba e nunca mais voltar.

O que eu tenho é uma decisão e o raciocínio que a produziu, derivados de um paper que eu finalmente li inteiro. Isso é uma hipótese arquitetural, não um resultado. O experimento completo é daqui a alguns meses, e ele vale mesmo que a resposta seja "não funcionou".

Perguntas frequentes

Janela de 1 milhão de tokens não resolve o context rot? Não — e cuidado, porque a formulação popular dessa resposta ("degrada antes da janela encher") também não é do paper. O que a Chroma mediu foi o desempenho ficando cada vez menos confiável conforme a entrada cresce. Janela maior não encolhe sua entrada; ela só permite que ela cresça mais. Comprar janela ataca um problema de espaço, e o gargalo é competição por atenção.

Se embaralhar melhora, eu devo embaralhar minha documentação? Não. Esse é o achado sendo torturado até virar dica de LinkedIn. É resultado de laboratório com haystacks controlados, os autores não explicam a causa, e o texto do seu repositório precisa ser lido por humanos também. A lição transferível não é "escreva pior" — é "escrever bem não protege sua informação de ser enterrada, então pare de tratar volume de documentação como investimento gratuito".

Como sei se estou sofrendo de context rot ou só de prompt ruim? Sintoma característico: a mesma tarefa, com o mesmo prompt, funciona no começo da sessão e falha depois de um tempo de conversa. Se o prompt fosse ruim, teria falhado no turno 1. Se ele degrada com o acúmulo, o prompt não é a variável.

Por que confiar nos seus números se você mesmo errou duas vezes neste artigo? Não confie. Confira. O relatório está publicado na página de pesquisa da própria Chroma, em trychroma.com/research/context-rot, e o toolkit para replicar os experimentos é público no repositório chroma-core/context-rot, no GitHub — ele traz o NIAH estendido (needle in a haystack: achar uma agulha no palheiro), o LongMemEval (avaliação de memória em conversas longas) e o repeated words (repetir de volta uma lista de palavras). O "lost in the middle" original é Liu et al., publicado na TACL em 2023. A cena da ideia errada que gruda no contexto está numa thread do Hacker News, no item 48272984. Cada um leva cinco minutos pra checar. Foi exatamente assim que eu descobri que estava errado — e é literalmente a tese do artigo.

O placar, revisitado

Dezoito modelos. Um distrator já basta. Sopa vence prosa.

E dois números mais um jargão que não estão em lugar nenhum do paper, circulando há meses como se estivessem — dois deles dentro das minhas próprias anotações, um deles já escrito num artigo meu, até eu abrir a página.

Tem uma simetria aqui que eu não consigo desconversar. O paper mostra um modelo que, cercado de trechos plausíveis, se apega ao que parece relevante em vez do que é. E o nicho inteiro, cercado de blogs plausíveis, se apegou ao número que parece medido em vez do que foi. Eu inclusive. Nós falhamos do mesmo jeito, pelo mesmo motivo: ninguém foi na fonte. Todo mundo recuperou por similaridade.

Contexto longo não é memória. Nunca foi. É uma pilha de coisas competindo pela atenção do modelo, e a maior parte dessa pilha está lá porque alguém achou que "não custa deixar".

Custa. E a saída não é achar o teto mágico — é subtrair até sobrar o que a tarefa exige.

Vale para o contexto da sua sessão. Valia, também, para as minhas anotações.