- Embora o limite de tokens de entrada (janela de contexto) dos LLMs mais recentes tenha se expandido para a casa dos milhões, mesmo com pontuações altas em benchmarks simples de busca (Needle in a Haystack, NIAH), há uma degradação clara de desempenho em entradas longas reais
- Os pesquisadores realizaram diversos experimentos com 18 modelos e confirmaram repetidamente queda de desempenho e padrões inconsistentes, mesmo controlando apenas o aumento do comprimento da entrada
- Fenômenos em que a velocidade de queda de desempenho se acelera ou muda de forma imprevisível se destacam conforme há queda na similaridade entre pergunta e resposta, adição de frases distratoras e mudanças na estrutura do texto-base
- Até mesmo a manutenção de contexto estrutural (fluxo lógico de parágrafos) chegou a impactar negativamente o desempenho, mostrando que a organização e a forma da entrada influenciam fortemente os LLMs
- Até tarefas muito fáceis, como simplesmente copiar texto repetido, revelaram a limitação de não produzir resultados consistentes à medida que o comprimento da entrada aumenta, reforçando a importância do desenho de contexto (context engineering) na aplicação prática
Contexto e objetivo da pesquisa
- Com a recente ampliação da janela de contexto dos LLMs para 1 milhão a 10 milhões de tokens, se espalhou a percepção de que o “desempenho está garantido” mesmo com entradas longas
- Gemini 1.5 Pro, GPT-4.1 e Llama 4 são exemplos representativos
- O benchmark mais conhecido, Needle in a Haystack (NIAH), se limita a uma busca simples de frases, e por isso não reflete adequadamente a degradação de desempenho em tarefas mais complexas com documentos longos, como resumo e perguntas e respostas
- Este estudo verifica de forma sistemática as mudanças de desempenho ajustando apenas o comprimento da entrada e mantendo a dificuldade da tarefa fixa
Principais experimentos e resultados
- Foram conduzidos 4 desenhos experimentais com 18 LLMs recentes (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen etc.):
- mudança na similaridade semântica entre pergunta e resposta (Needle-Question)
- adição de frases distratoras
- mudança no tema/estrutura do texto-base (haystack)
- cópia de palavras repetidas (com expansão simultânea do comprimento de entrada e saída)
- Em todos os experimentos, o desempenho cai de forma acentuada à medida que o comprimento da entrada aumenta, e a queda se torna ainda maior quando a similaridade semântica é baixa ou há muitos distratores
- Quanto menor a similaridade entre pergunta e resposta, maior o aumento da taxa de erro em entradas longas
- Mesmo com a adição de apenas uma frase distratora, a taxa de acerto cai imediatamente; com 4 ou mais, aumentam bastante, dependendo do modelo, os fenômenos de confusão e alucinação (hallucination)
- Exemplo: a família Claude tende fortemente a responder “não foi possível encontrar a resposta” em vez de errar; já a família GPT gera mais respostas erradas com alta confiança
- Também foi observado um fenômeno peculiar em que o desempenho se inverte conforme a estrutura do texto-base (fluxo lógico/ordem aleatória)
- No texto original (Original), que preserva o fluxo lógico, o desempenho do modelo piora
- No texto embaralhado (Shuffled), com frases misturadas aleatoriamente, o desempenho de busca melhora
- Mesmo no experimento de cópia de palavras repetidas, à medida que os tokens de entrada e saída aumentam, crescem padrões imprevisíveis como mais erros, recusa da tarefa e geração de palavras aleatórias
- Exemplo: após 2.500 a 5.000 palavras, determinados modelos passam a apresentar forte aumento de recusas de cópia, geração de texto aleatório e outros resultados anômalos
LongMemEval: avaliação prática de conversas longas
- No benchmark LongMemEval, que inclui registros de conversas reais, foi comparada a entrada focada (apenas trechos relacionados à resposta correta) com a entrada completa (incluindo contexto irrelevante para a resposta)
- Em todos os modelos, a entrada focada apresentou taxa de acerto muito superior, enquanto na entrada completa o próprio ato de encontrar o conteúdo relevante passou a funcionar como uma tarefa adicional, degradando bastante o desempenho
- Os modelos da família Claude mostraram tendência especialmente clara de evitar a resposta com “sem resposta correta” em situações ambíguas
Análises adicionais e implicações
- Foram analisadas em detalhe, com diversos gráficos, diferenças nos padrões internos de funcionamento entre modelos, como taxa de confusão por distrator, precisão da posição da resposta e posição de geração de palavras aleatórias
- No experimento de cópia de palavras repetidas, houve características dependentes de posição, como maior precisão quando a palavra correta aparece mais no início
- Como o impacto do desenho do contexto (organização da informação, gestão do fluxo lógico etc.) sobre o desempenho do modelo é muito grande, o estudo sugere que, em aplicações reais, não se pode esperar desempenho consistente apenas ampliando o contexto
Conclusão
- A capacidade dos LLMs de lidar com entradas longas não é garantida por pontuações de benchmark, e mesmo o simples aumento do comprimento da entrada já causa degradação de desempenho inconsistente
- Não basta apenas incluir a informação relevante; a organização, a estrutura, os distratores e a similaridade da informação têm impacto decisivo no desempenho
- Ao utilizar LLMs, é indispensável fazer gestão e desenho de contexto longo (context engineering)
2 comentários
Já faz um bom tempo que saiu a 2.5, então por que a 1.5?
Comentários do Hacker News
Eu também tive uma experiência parecida. Especialmente ao usar o Gemini Pro com referências de texto longas, consegui respostas muito melhores resumindo primeiro cada documento e fazendo perguntas sobre esses resumos, em vez de colocar vários documentos de uma vez na janela de contexto; depois, se necessário, eu fornecia os documentos completos em estilo RAG ou com um loop simples de agente. De forma semelhante, ao usar o Claude Code com Opus ou Sonnet, também percebi na prática que quanto mais compactação ocorria, pior ficava o resultado. Não tenho certeza se isso acontece porque a qualidade do resumo cai, ou porque a proporção de dados menos relevantes dentro da janela de contexto aumenta, mas quando eu limpava o contexto e mandava reler apenas os arquivos relevantes, o resultado ficava bem melhor, mesmo que eles já tivessem sido mencionados no resumo anterior
O Gemini já começa a perder consistência e capacidade de raciocínio antes mesmo de chegar ao limite do contexto do chat. Ainda assim, segundo este relatório, ele é o melhor modelo em vários aspectos. A conclusão é que engenharia de contexto ainda importa, e a abordagem com RAG continua válida
"Compactação" no fim não é só encurtar a transcrição em um resumo? Se for isso, é natural que o desempenho piore, porque há perda real de informação. Mas isso não seria por causa de context rot. O verdadeiro sinal de context rot aparece quando se aproxima do limiar de auto-compaction. Estou entendendo certo?
Um agente de código ideal provavelmente automatizaria esse processo. Ele reuniria o código necessário, respostas de MCP, mapa do repositório etc., resumiria isso de vez em quando e juntaria tudo em uma nova mensagem de chat, deixando só o que realmente importa. Eu já uso algo nesse estilo com a ferramenta aider, e em situações que exigem muito contexto, ela teve desempenho bem melhor do que fluxos agentivos ou automatizados. Só dá mais trabalho manual
Já experimentou o NotebookLM? Esse app fragmenta e resume os documentos em segundo plano e permite fazer perguntas em formato de chat sobre o documento inteiro via RAG
No Cursor, percebi que quanto mais tempo eu converso sobre uma nova funcionalidade ou mudança de código, pior vai ficando o resultado. Os melhores resultados vieram quando eu primeiro definia instruções e um plano claros e específicos, e arrastava diretamente os arquivos a serem modificados para o prompt de contexto
Seguir o fluxo "Explore → plan → code → test → commit" ajudou muito mais. Se necessário, dá para limpar o contexto em cada etapa para melhorar o efeito
Quando eu já reuni informação suficiente para uma tarefa específica, salvo o contexto naquele ponto. Se começo a notar queda de qualidade, resumo novamente o trabalho feito até ali e acrescento isso ao checkpoint anterior
Esse fenômeno é bem conhecido, mas existem poucos lugares onde ele foi documentado direito, então este texto é muito bem-vindo. Acho que o impacto prático é ainda maior do que aquilo que dá para medir facilmente com benchmarks. Os apps de LLM realmente úteis ficam no limite do que o modelo consegue fazer. Ou seja, eles importam quando é preciso acompanhar um contexto que exige vários "saltos" lógicos numa pergunta ou tarefa real. Acho que o problema de context rot piora de forma explosiva quanto mais saltos lógicos são necessários, porque a cada salto cresce o conjunto de coisas às quais o modelo precisa prestar atenção
Precisamos muito de uma forma fácil de cortar o contexto. Se eu pudesse gerenciar manualmente o modelo e a conversa inteira, acho que conseguiria extrair muito mais desempenho de uma sessão de programação com cerca de 200 mil tokens. Mas, na prática, mesmo usando uma boa instância, depois de uns 20 mil tokens o modelo começa a agir de forma estranha e a sessão fica totalmente degradada. Queria simplesmente poder cortar essa parte fora
Em LLMs locais, dá para editar o contexto como quiser, então se você alterar a própria resposta do LLM, o modelo depois pode achar que foi isso mesmo que ele disse originalmente. Isso ajuda a conduzi-lo na direção desejada. Já os modelos LLM-as-a-service não oferecem isso, porque facilitaria burlar censura
Tentei pedir: "Ei Claude, vou resetar o contexto agora, então me crie um prompt para que eu possa continuar trabalhando daqui para frente". Depois eu revisava e ajustava previamente o prompt sugerido pelo Claude antes de reenviá-lo
Se fosse possível fazer rollback facilmente para um checkpoint anterior, isso seria de longe o melhor recurso
Na maioria dos agentes de CLI, dá para fazer esse tipo de coisa com o comando
/compressQuando uso o Claude code, ele vai perdendo a capacidade de distinguir os próprios erros das minhas instruções. Quando começa a se confundir, a solução é abrir uma nova sessão. Quanto mais longa a sessão, mais ele entra no mesmo loop ou insiste em ignorar algo dizendo que os testes já estavam quebrados antes, quando na verdade quebraram nesta sessão. Pode até ser culpa de prompts ruins da minha parte, mas ultimamente o Claude parece ter perdido uns 30 pontos de QI sem ninguém perceber
Sinto exatamente a mesma coisa. Mesmo no plano Max, há momentos em que o desempenho está claramente bom e outros em que não está
Pensar "deve ser meu prompt e meu contexto o problema" parece uma forma de gaslighting internalizado que todos nós absorvemos
Isso é um tipo de problema de recuperação de informação, mas acho que a queda de desempenho causada pela variação no comprimento do contexto pode funcionar de forma diferente de respostas baseadas em recuperação simples. Por exemplo, em perguntas como “como faço para deixar este botão vermelho?” ou problemas como “a quais categorias pertencem as frases acima?”, o comportamento pode ser diferente. Um artigo que achei marcante no passado foi Many-Shot In-Context Learning. Nesse estudo, eles mostram um fenômeno em que o desempenho melhora bastante à medida que o contexto é preenchido com exemplos. No fim, é preciso testar diretamente em cada problema para entender como o LLM muda conforme o conteúdo e o tamanho do contexto. Não dá para assumir sempre que contexto mais longo significa desempenho pior
Artigo muito interessante e cheio de insight. Só vale lembrar, do ponto de vista de letramento midiático, que a Chroma é uma empresa de banco de dados vetorial
Recentemente escrevi vários romances longos com o Gemini 2.5 Flash, e embora eu perceba claramente o context rot, ele aparece bem mais tarde do que o artigo sugere. No meu caso, só depois de algo entre 50 mil e 100 mil tokens ele começava a ignorar o contexto inicial, como o idioma de saída. Talvez em tarefas complexas como escrita criativa o efeito seja mais difícil de medir ou menos nítido. De todo modo, se eu reinserir de vez em quando apenas o contexto que se perdeu, a qualidade continua utilizável
Também tive uma experiência parecida. Durante um projeto, eu estava desenvolvendo uma funcionalidade de busca em transcrições de vídeo, e os textos eram muito longos. Como modelos como o GPT 4.1 têm uma janela de contexto grande, achei que RAG não seria necessário, mas principalmente nos modelos menores apareciam comportamentos estranhos com frequência. Às vezes eles não respondiam direito à pergunta e simplesmente faziam um resumo do conteúdo inteiro
Relatório interessante. Fico curioso se existe algo como um tamanho de contexto recomendado por modelo. Queria saber se há alguma forma de descobrir até que ponto isso é adequado para o meu caso de uso