Context Rot: Por Que Mais Contexto Nem Sempre Significa Resposta Melhor

Em junho eu escrevi sobre os quatro problemas que quebram agentes de IA em produção, e um deles era o que chamei de context rot: o agente que se perde no próprio contexto conforme ele cresce, ignora instruções que estavam lá desde o início e repete tool calls que já tinha executado. Descrevi o sintoma com razoável confiança, porque é fácil de reconhecer quando você já viu um agente de longa duração degradar. O que não fiz naquele post foi explicar o mecanismo com o rigor que ele merece. Citei o termo de passagem, como item quatro de uma lista de quatro, e segui para o próximo problema.

Fiquei devendo essa explicação, e a dívida incomodou o suficiente para eu voltar ao assunto agora. Não fui eu quem rodou o experimento que dá nome ao fenômeno — isso ficou com a equipe de pesquisa da Chroma, que em 2025 testou sistematicamente como 18 modelos de fronteira se comportam conforme a janela de contexto cresce. O que fiz foi ler essa pesquisa com atenção, cruzá-la com outras fontes que documentam o mesmo padrão de ângulos diferentes, e tentar traduzir isso em algo útil para quem projeta sistema de agente no dia a dia.

O timing não é coincidência. Esta semana escrevi sobre o Gemini 3.8 Flash e sua janela de 1 milhão de tokens, e a conversa ao redor do lançamento seguiu o roteiro de sempre: janela maior tratada como avanço automático, como se cada token adicional de capacidade se traduzisse linearmente em mais contexto útil. A pesquisa da Chroma sugere que essa equação está incompleta. Janela grande é condição necessária para caber mais informação. Não é condição suficiente para o modelo usar essa informação bem.

Este post é o mergulho que faltou em junho: o que a pesquisa da Chroma encontrou exatamente, por que a atenção do modelo se comporta de um jeito específico ao longo da janela, o que isso significa para quem está comemorando 1 milhão de tokens de contexto nesta semana, e quais padrões de mitigação já existem para quem precisa lidar com isso hoje.

---

Onde Esse Termo Apareceu Antes Neste Blog

Vale recapitular o contexto de junho, porque ele explica por que este post existe. Naquele momento eu tratava de quatro problemas que separam um agente de demo de um agente de produção: durabilidade de execução, sandboxing de código, observabilidade do loop de raciocínio e, por último, context rot. Descrevi o sintoma de um jeito que, em retrospecto, foi impressionista: "o agente simplesmente começa a tomar decisões piores à medida que o contexto envelhece e cresce". Verdadeiro, mas incompleto — faltava o mecanismo, faltava a curva, faltava o número.

Naquele post eu já citava um comportamento correlato: instruções em arquivos como CLAUDE.md ou AGENTS.md que crescem sem controle e acabam ignoradas quando o restante da janela está ocupado com histórico de execução. Atribuí isso ao mecanismo de atenção, sem detalhar qual formato essa degradação assume. É essa lacuna que a pesquisa da Chroma preenche com dado concreto.

Há uma razão prática para revisitar isso agora, além da dívida editorial: o campo mudou em três meses. Em junho, janela de 200 mil tokens já era considerada grande. Hoje, com o Gemini 3.8 Flash em 1 milhão de tokens, a conversa sobre limite técnico da janela ficou menos relevante do que a conversa sobre o que o modelo efetivamente consegue extrair de dentro dela. Context rot deixou de ser nota de rodapé para virar pergunta central de quem projeta prompt de agente longo.

---

O Que A Pesquisa Da Chroma Encontrou

O termo "context rot" foi formalizado pela pesquisa da Chroma em 2025, segundo descreve a Morph em análise sobre o tema. A pesquisa parte de uma constatação simples de enunciar e incômoda de aceitar: conforme se adicionam tokens à entrada de um LLM, a qualidade da resposta cai. Não é degradação ocasional em caso de borda. É padrão sistemático, medido em testes controlados com 18 modelos de fronteira — comportamento que atravessa praticamente todo o estado da arte disponível, não limitação isolada de um fornecedor.

O achado central é o número que dá peso ao termo: degradação de precisão de mais de 30% em posições no meio da janela de contexto, em todos os 18 modelos testados. Trinta por cento não é ruído estatístico — é queda grande o suficiente para mudar o resultado prático de uma tarefa, principalmente quando o agente precisa recuperar um dado específico enterrado no meio de um contexto longo, como um valor de configuração citado várias etapas atrás.

O detalhe mais contraintuitivo, e o que mais deveria mudar como arquitetos pensam sobre janela de contexto, é este: um modelo com janela de 200 mil tokens pode apresentar degradação significativa já em 50 mil tokens. O problema não aparece perto do limite técnico da janela — aparece bem antes, numa fração relativamente pequena da capacidade nominal. Isso quebra a intuição de tratar o limite anunciado pelo fornecedor como o ponto até onde "dá para confiar" no modelo. Na prática, a confiabilidade já está comprometida bem antes desse limite ser sequer chegado perto.

Essa distinção entre limite técnico e limite de uso confiável é o núcleo de tudo que vem a seguir. Um fornecedor pode anunciar 1 milhão de tokens de janela sem que isso implique nada sobre em que ponto dessa janela a precisão começa a cair. São duas métricas diferentes, medidas de formas diferentes, e a cobertura de lançamento de modelo quase sempre reporta só a primeira.

---

O Mecanismo "Lost In The Middle" E A Curva Em U

O nome técnico para o padrão que a Chroma documentou é "lost in the middle" — perdido no meio. A formulação é direta: modelos funcionam melhor quando a informação relevante está bem no início ou bem no fim da janela de contexto, e têm dificuldade quando ela fica enterrada no meio. O desempenho em tarefas de perguntas e respostas multi-documento e de recuperação chave-valor segue uma função em formato de U em relação à posição da informação dentro do contexto.

Vale detalhar o que essa curva significa na prática, com uma tabela simples relacionando posição da informação com a precisão observada:

Posição da informação na janela	Padrão de precisão observado
Início do contexto (primeiros ~10%)	Precisão mais alta
Meio do contexto (faixa central)	Degradação superior a 30%
Fim do contexto (últimos ~10%, próximo à pergunta)	Precisão mais alta

A forma de U vem exatamente disso: as duas pontas da janela — começo e fim — concentram a melhor precisão, e o vale no meio é onde a informação, mesmo presente e relevante, tem mais chance de ser mal utilizada ou simplesmente ignorada na hora de compor a resposta.

A causa técnica está em como a atenção é calculada. O peso de atenção é distribuído ao longo da janela, e essa distribuição não é uniforme: o modelo tende a prestar menos atenção a informação em posições do meio, e mais atenção às bordas. Isso causa diretamente o context rot, porque o LLM não consegue extrair de forma confiável informação do meio de contextos longos, mesmo quando ela está tecnicamente presente e relevante. O modelo não "esquece" no sentido literal — o dado está lá, ocupando os tokens que ocupa. O mecanismo de atenção aloca menos peso para essa região, e o resultado prático, do ponto de vista de quem usa o sistema, é indistinguível de esquecimento.

Um cenário hipotético ajuda a tornar isso concreto. Imagine um agente de suporte que recebe, no início da conversa, um documento de 40 páginas com o histórico de um cliente — contratos, tickets, configurações. Na página 22 existe uma cláusula específica: aquele cliente tem SLA diferenciado de 4 horas em vez do padrão de 24. Se essa cláusula estivesse na primeira ou na última página, a chance de recuperação correta seria alta. Estando no meio, cercada de outras 38 páginas de contexto denso, a chance de o agente simplesmente não aplicar a exceção cai de forma substancial — não porque o dado sumiu, mas porque a atenção do modelo naturalmente pesa menos aquela região.

Esse padrão também explica por que instruções colocadas no meio de um system prompt longo, misturadas com exemplos e contexto operacional, tendem a ser menos respeitadas do que instruções no início ou repetidas perto do fim, junto da tarefa imediata. Não é acaso — é o mesmo mecanismo de atenção distribuída operando sobre o prompt inteiro, incluindo a parte escrita manualmente pelo engenheiro.

---

Por Que Isso Importa Agora, Com O Gemini 3.8 Flash E Sua Janela De 1M Tokens

A conexão com a semana atual não é forçada. O Gemini 3.8 Flash chegou com 1 milhão de tokens de janela, e a cobertura de lançamento tratou esse número essencialmente como benefício direto: mais espaço, mais documento cabendo de uma vez, mais histórico preservado. Nada nessa cobertura discutiu em que ponto dentro desse 1 milhão de tokens a precisão começa a cair, porque esse não é o tipo de número que aparece em anúncio de lançamento. Fornecedor anuncia capacidade nominal. Ninguém anuncia curva de degradação.

Se o padrão documentado pela Chroma se generaliza — a pesquisa cobriu 18 modelos justamente para testar se o fenômeno é amplo ou isolado —, uma janela de 1 milhão de tokens não elimina o problema de lost in the middle. Ela desloca o problema para uma escala maior. Se degradação significativa já aparece em 50 mil tokens numa janela de 200 mil, não há garantia de que uma janela de 1 milhão empurre esse ponto de inflexão proporcionalmente para mais longe. O comportamento pode ser relativo ao tamanho total da janela, pode ser mais próximo de um valor absoluto de tokens, ou pode variar por arquitetura — pergunta em aberto que a pesquisa disponível não resolve para cada modelo novo lançado.

O que dá para afirmar com razoável segurança é que tamanho da janela e qualidade do uso dessa janela são variáveis diferentes, e tratar a primeira como proxy automático da segunda é o erro mais comum na forma como o mercado discute lançamento de modelo. Isso conecta com uma discussão que já tive neste blog sobre quando faz sentido usar RAG em vez de simplesmente aumentar a janela de contexto: a resposta nunca foi só sobre custo de token, é também sobre confiabilidade de recuperação. Uma janela de 1 milhão de tokens que degrada 30% no meio não é estritamente melhor, para efeito de recuperação de informação específica, do que uma janela menor combinada com estratégia de posicionamento deliberada.

Isso também tem implicação para a discussão de roteamento entre modelos que já tratei ao cobrir a arquitetura de custo de inferência entre SLM e LLM. Se o critério para mandar uma tarefa ao modelo com janela maior for só "esse caso tem muito contexto, precisa da janela grande", esse critério ignora que o modelo pode processar mal justamente a parte do contexto que fica no meio. Um roteador bem calibrado precisaria considerar não só o volume de tokens de entrada, mas onde dentro desse volume está a informação que a tarefa realmente precisa recuperar. Vale insistir que o problema não é exclusivo de documento longo: ele se manifesta com a mesma lógica em agentes que acumulam histórico de tool calls e resultados intermediários ao longo de uma sessão extensa, o cenário que descrevi em junho. Um agente que "esquece" uma decisão tomada vinte passos atrás não necessariamente tem problema de raciocínio — pode simplesmente ter essa decisão posicionada na região da janela onde a atenção é estruturalmente mais fraca.

---

Abordagens De Mitigação: RAG, MCP E Governança De Metadados

A boa notícia, na medida em que existe uma, é que já existem abordagens documentadas para mitigar context rot, e nenhuma depende de esperar o próximo modelo com janela ainda maior. A combinação de retrieval-augmented generation, protocolo MCP e governança ativa de metadados supera janelas de contexto maiores sem governança — a solução estrutural não é aumentar a janela indiscriminadamente, é ser mais seletivo sobre o que entra nela.

RAG ataca o problema pela raiz, reduzindo o volume total de contexto processado de uma vez. Em vez de despejar um documento de 40 páginas inteiro na janela na esperança de que o modelo encontre o trecho relevante, um pipeline de retrieval busca especificamente o trecho que importa para a pergunta atual e o injeta próximo do início ou do fim da janela — exatamente as regiões onde a curva em U mostra melhor precisão.

O MCP entra como camada complementar, não substituta. Em vez de o agente carregar todo o conhecimento potencialmente relevante no prompt inicial, o protocolo permite que ferramentas e fontes de dados sejam consultadas sob demanda, no momento exato em que a informação é necessária. Isso significa que o dado relevante entra na janela próximo do ponto em que será usado — perto do fim do contexto, logo antes da resposta ser gerada — em vez de ficar acumulado desde o início da sessão, envelhecendo e migrando para o meio da janela conforme a conversa avança.

A peça que costuma faltar nessa combinação é a governança ativa de metadados: decidir deliberadamente o que entra na janela, em que ordem, e quando algo deve ser removido ou resumido em vez de simplesmente acumulado. Isso é trabalho de engenharia, não de prompt engineering no sentido raso de "escrever melhor a instrução". Envolve decidir quais campos de um documento são realmente necessários para a tarefa atual, descartar o que não é, e posicionar ativamente o que sobra nas regiões da janela onde o modelo tem melhor desempenho. Um sistema que aplica essa governança de forma consistente tende a superar, em qualidade de resposta, um sistema que simplesmente aproveita uma janela maior e despeja tudo dentro dela sem critério.

Vale reconhecer o limite honesto dessa recomendação: nenhuma das três abordagens elimina o fenômeno documentado pela Chroma. RAG, MCP e governança de metadados reduzem a exposição ao problema, deslocando informação crítica para as regiões de melhor desempenho da janela e diminuindo o volume de conteúdo concorrendo por atenção. Isso não é o mesmo que resolver o mecanismo de atenção distribuída na raiz — é uma característica estrutural dos modelos testados, não um bug de implementação que uma camada de engenharia por cima consiga corrigir por completo.

---

O Que Muda Na Prática De Quem Projeta Prompt De Agente Longo

Para quem desenha prompt de agente ou pipeline de contexto no dia a dia, dá para traduzir isso em mudanças de prática concretas, sem prometer solução definitiva onde não existe uma.

A primeira é parar de tratar o limite de janela anunciado pelo fornecedor como sinônimo de limite de uso confiável. Se degradação significativa pode aparecer numa fração pequena da capacidade nominal, o planejamento de quanto contexto empurrar para um modelo precisa ser calibrado empiricamente contra a tarefa real, não assumido a partir da ficha técnica do lançamento. É o mesmo tipo de disciplina que já defendi ao tratar de preço promocional de modelo que muda de patamar numa data conhecida: número de marketing e número operacional são coisas diferentes, e tratar um como o outro é onde o problema de produção nasce.

A segunda é posicionar deliberadamente a informação mais crítica do prompt nas extremidades da janela — início e fim — e evitar depender de que o modelo recupere corretamente algo enterrado no meio de um bloco denso de contexto acumulado. Isso vale tanto para instrução de sistema quanto para dado recuperado via ferramenta: se algo é indispensável, o lugar mais seguro não é o meio de um histórico de execução de vinte passos, é o mais próximo possível do ponto em que a resposta será gerada, ou repetido explicitamente perto do fim mesmo que já tenha aparecido antes.

A terceira é instrumentar para detectar o problema antes que ele apareça como erro visível ao usuário final.

Context rot, como já registrei em junho, não gera exceção nem timeout — aparece como decisão silenciosamente pior. Isso exige o mesmo tipo de observabilidade granular que já defendi para agentes de produção de forma geral: comparar o comportamento do agente em sessões curtas versus sessões longas na mesma tarefa é uma forma prática de detectar se a degradação documentada pela pesquisa está de fato acontecendo no seu sistema específico, em vez de assumir que ela não se aplica porque o modelo usado é mais recente ou tem janela maior que os testados pela Chroma.

---

Conclusão

Volto à dívida que abri este post reconhecendo: em junho, citar context rot como item quatro de uma lista foi insuficiente, e a insuficiência não era só de espaço — era de profundidade de leitura que eu ainda não tinha feito naquele momento. A pesquisa da Chroma dá ao termo um contorno mensurável que a descrição impressionista de junho não tinha, e isso muda a forma como eu recomendaria alguém tratar o problema: não como sintoma vago de "agente longo fica confuso", mas como comportamento documentado, com curva conhecida e causa técnica identificável no mecanismo de atenção.

O que essa pesquisa não me dá é uma resposta fechada sobre até que ponto o problema muda de forma conforme os modelos evoluem. Não sei se o Gemini 3.8 Flash, especificamente, degrada na mesma proporção que os 18 modelos testados pela Chroma, porque essa medição não está entre as fontes que consultei para este post, e não vou fingir que ela existe. O que sei é que a lógica que sustenta o fenômeno — atenção distribuída de forma não uniforme ao longo da janela — não é peculiaridade de uma geração de modelo específica, é característica estrutural que atravessou todos os modelos testados até agora, e não há sinal público de que isso tenha sido resolvido na raiz por nenhum fornecedor.

Fica uma reflexão mais modesta para quem está decidindo hoje quanto contexto empurrar para dentro de um prompt de agente: o número de tokens que cabe na janela é a pergunta mais fácil de responder, porque está na ficha técnica do modelo. A pergunta mais difícil, e mais relevante, é em que posição dentro dessa janela a informação que realmente importa vai parar — e essa pergunta não tem resposta na ficha técnica de nenhum fornecedor. Ela só se responde testando, de forma empírica, contra a carga real do seu próprio sistema.

Fontes:

• Morph — Context Rot
• Redis — Context Rot: How Increasing Input Tokens Impacts LLM Performance
• Atlan — LLM Context Window Limitations
• Chroma — Context Rot: How Increasing Input Tokens Impacts LLM Performance (relatório original)