O que é context rot em uma frase?

É a degradação da qualidade da resposta de um LLM conforme o contexto de entrada cresce, mesmo quando o conteúdo relevante continua presente e mesmo dentro do limite anunciado da janela.

Se o modelo tem 1 milhão de tokens de janela, por que não usar tudo?

Porque a janela é o limite físico, não a região onde o desempenho se mantém. Nos testes com modelos de janela muito grande, um efeito claro costuma aparecer bem antes do limite, na faixa das centenas de milhares de tokens. Caber não é o mesmo que funcionar bem.

O benchmark needle in a haystack não provou que long context está resolvido?

Não. O NIAH mede recuperação quase literal de uma frase inserida em um texto longo, que é a tarefa mais fácil possível nesse formato. Tarefas reais exigem síntese, desambiguação e ignorar distratores — e é aí que a queda aparece.

Aumentar o contexto sempre piora?

Não. Contexto relevante melhora. O que piora é contexto irrelevante, duplicado, contraditório ou desorganizado. O objetivo não é minimizar tokens e sim maximizar a densidade de relevância.

Como sei que estou sofrendo de context rot?

Os sintomas típicos são: o modelo ignora uma instrução que estava no começo, mistura duas fontes parecidas, responde com uma versão antiga de um documento que aparece duas vezes, ou fica pior justamente depois que você adicionou mais material de apoio.

Conceito · Contexto · NLP · RAG

Context rot

Por que encher a janela de contexto piora a resposta — e o que fazer a respeito.

Nível: Intermediário
min de leitura: 12 min
Atualizado: 18 de ago. de 2026

É: A queda mensurável de qualidade de um LLM conforme o número de tokens de entrada cresce — mesmo em tarefas simples e mesmo dentro da janela anunciada.
Use quando: Use o conceito sempre que for decidir quanto contexto injetar: em RAG, em agentes de longa duração e em qualquer prompt que cresce com o tempo.
Evite quando: Não é desculpa para não dar contexto. Contexto insuficiente erra mais rápido e mais feio que contexto grande.

VereditoJanela de contexto é capacidade de armazenamento, não promessa de atenção — trate cada token como custo de qualidade, não só de fatura.

Existe uma intuição confortável sobre modelos de linguagem que quase todo mundo carrega no começo: se o modelo aceita um milhão de tokens, então enfiar mais material lá dentro só pode ajudar. Na pior das hipóteses, ele ignora o que não interessa.

Não é o que acontece. A partir de certo ponto, adicionar contexto piora a resposta — inclusive contexto que você considera útil. O nome que pegou para esse fenômeno é context rot.

Resposta direta: context rot é a queda mensurável da qualidade de um LLM conforme o número de tokens de entrada cresce, mesmo em tarefas simples e mesmo com a informação relevante presente. A janela de contexto define o que cabe, não a região em que o desempenho se mantém.

O que a pesquisa mostrou

O termo surgiu numa discussão pública em meados de 2025 e ganhou corpo com um relatório da Chroma Research, publicado em julho daquele ano, que testou 18 modelos de ponta em tarefas derivadas do clássico needle in a haystack.

O resultado incômodo: o desempenho cai conforme a entrada cresce, mesmo em tarefas triviais. A queda não é linear nem uniforme entre modelos — mas está presente em todos. Em modelos com janela de um milhão de tokens, um efeito claramente observável costuma aparecer bem antes do limite, na faixa das centenas de milhares.

Formato típico da curva

Acerto em uma tarefa fixa conforme o contexto cresce

8 mil tokens95%
32 mil tokens90%
128 mil tokens78%
400 mil tokens62%
900 mil tokens48%

Números ilustrativos do formato da curva relatada na literatura, não medição de um modelo específico. O valor de cada modelo varia; o formato se repete.

Por que o benchmark clássico enganou tanta gente

O needle in a haystack insere uma frase específica em um texto longo e pergunta por ela. Os modelos vão bem nisso — daí a impressão generalizada de que contexto longo estava resolvido.

O problema é que essa tarefa mede uma capacidade estreita: recuperação quase literal. A pesquisa mostrou que basta afastar a tarefa dessa condição ideal para a queda aparecer.

Por que o NIAH superestima a capacidade real

Fator	No benchmark	No seu sistema
Semelhança pergunta-resposta	Alta, quase literal	Baixa, a pergunta usa outras palavras
Distratores	Nenhum ou poucos	Vários trechos parecidos e plausíveis
Estrutura do material	Texto coeso	Fragmentos de fontes diferentes, colados
Número de fatos necessários	Um	Vários, que precisam ser combinados
Contradições	Nenhuma	Versões antigas e novas do mesmo documento

Os quatro fatores que a pesquisa isolou aparecem juntos no mundo real. Quanto menos a pergunta se parece literalmente com a resposta, mais forte a degradação com o aumento do contexto. Distratores plausíveis pioram. Material desestruturado piora.

Como isso se manifesta no dia a dia

Context rot raramente aparece como uma falha óbvia. Ele aparece como qualidade que escorre.

A progressão que quase todo projeto vive

01
Funciona muito bem
prompt enxuto, poucos documentos, respostas certeiras
02
Adicionamos mais fontes
a cobertura melhora, a precisão começa a oscilar
03
Aumentamos o top-k do retrieval
para não perder nada, trazemos mais trechos
04
A qualidade cai
e a suspeita recai sobre o modelo
05
Trocamos de modelo
e o problema continua, porque nunca foi o modelo

Os sintomas mais reconhecíveis:

o modelo ignora uma instrução que estava no início do prompt;
ele responde com base em uma versão desatualizada de um documento que aparece duas vezes na entrada;
ele mistura dois casos parecidos, atribuindo detalhe de um ao outro;
a resposta piorou logo depois que você adicionou mais material de apoio.

O último é o mais diagnóstico. Se adicionar informação piorou o resultado, o problema não é falta de informação.

As cinco técnicas que resolvem

A engenharia de contexto contra context rot é sempre a mesma ideia com nomes diferentes: aumentar a densidade de relevância, ou seja, a proporção do contexto que realmente serve para a pergunta.

1. Recuperar melhor em vez de recuperar mais

Aumentar o top-k é a solução que parece resolver e cobra depois. Vinte trechos com cinco relevantes rendem menos que cinco trechos relevantes. Reordenação por relevância — o reranking — costuma render mais que qualquer aumento de quantidade.

2. Comprimir antes de injetar

Documento inteiro raramente é a unidade certa. Resumir cada fonte antes de colocá-la no prompt troca mil tokens de texto bruto por cem tokens de conteúdo útil.

3. Isolar contexto em subagentes

Quando uma subtarefa exige ler muito material para produzir uma conclusão curta, delegue. O subagente lê os quarenta arquivos; só a conclusão volta para a conversa principal. É a técnica que faz subagentes em ferramentas de codificação valerem a pena, e o ganho é de higiene, não de velocidade.

Contexto principal

Mantém só o essencial

objetivo, decisões e conclusões

Leitor de docs

lê 40 páginas
devolve 5 linhas

Explorador de código

varre o repo
devolve 3 caminhos

Analista de dados

processa a tabela
devolve o número

O material bruto morre no subagente. Só a conclusão sobe.

4. Carregar sob demanda

Em vez de colocar todo o conhecimento no prompt desde o início, coloque só o índice — e deixe o modelo pedir o detalhe quando precisar. É exatamente o princípio de divulgação progressiva que sustenta as Agent Skills.

5. Reiniciar em vez de esticar

Conversa longa acumula decisões revogadas, caminhos abandonados e material que já não vale. Terminar a tarefa e começar uma sessão nova é a técnica mais barata da lista, e a mais ignorada.

Resumo operacional

Faça

Medir qualidade com contexto pequeno antes de crescer
Reordenar por relevância antes de aumentar quantidade
Resumir fontes longas antes de injetar
Delegar leitura pesada a subagentes
Encerrar a sessão quando a tarefa acaba

Evite

Aumentar o top-k para não perder nada
Colar documentos inteiros porque cabem
Manter versões antiga e nova do mesmo documento na entrada
Confiar que o modelo ignora o irrelevante
Culpar o modelo antes de auditar o contexto

Como medir no seu caso

Não dá para gerenciar o que não se mede, e a medida aqui é simples de montar.

Um teste que cabe em uma tarde

01
Monte 30 perguntas com resposta conhecida
do seu domínio real, não sintéticas
02
Rode com contexto mínimo
só o trecho que responde. Esse é o seu teto.
03
Rode com o contexto atual de produção
a diferença para o teto é o seu prejuízo
04
Rode com o dobro de contexto
se piorar, você achou o ponto de virada
05
Corte até voltar ao teto
e mantenha essa configuração como padrão

O número que importa dessa medição é a distância entre o teto e a produção. Se ela for grande, o ganho disponível está em engenharia de contexto — e não em trocar de modelo.

Adicionar contexto novo melhorou o resultado da última vez?

Melhorou

Você ainda está na região saudável

Continue crescendo, mas meça a cada passo. O ponto de virada existe e chega sem avisar.

Piorou ou ficou igual

Você já passou do ponto

Pare de adicionar. Corte, reordene e resuma — é onde está todo o ganho disponível agora.

A frase que vale guardar: a janela de contexto é um limite de armazenamento, não uma promessa de atenção. Cada token que você adiciona compete com todos os outros pela atenção do modelo. Contexto é orçamento, e orçamento se administra.