Não confie em janelas de contexto grandes

• A janela de contexto de um LLM pode ser dividida em uma zona inteligente, onde o modelo funciona com precisão, e uma zona embotada, onde a atenção cai e ele começa a esquecer instruções anteriores
• O ponto de divisão fica por volta de 100k tokens, e mesmo que o tamanho da janela de contexto anunciada seja grande, isso não significa o mesmo alcance real de trabalho
• Agentes de código podem consumir tokens rapidamente apenas com leitura de arquivos, depuração longa e execução de testes grandes, chegando aos 100k tokens com facilidade
• O RULER e o relatório de context rot da Chroma mostram que o contexto efetivo é apenas uma parte do número anunciado, e que o desempenho se degrada gradualmente à medida que a janela é preenchida
• Em vez de resumir automaticamente sessões longas, manter a informação fora da sessão com especificações e pequenos artefatos escritos manualmente ajuda o trabalho a permanecer na zona inteligente

---

Os limites reais da janela de contexto

• A janela de contexto de um LLM pode ser dividida em uma zona inteligente, onde o modelo é preciso, e uma zona embotada, onde a atenção diminui
  • Na zona embotada, o modelo começa a esquecer o que foi dito poucos minutos antes
  • O ponto de divisão fica por volta de 100k tokens
  • Mesmo que o tamanho da janela de contexto anunciada seja maior, esse ponto de divisão não desaparece
• Agentes de código consomem tokens rapidamente no modo de uso moderno
  • Bastam algumas leituras de arquivos, uma sessão longa de depuração e execuções amplas de testes para chegar a 100k tokens
  • Os fornecedores anunciam janelas de contexto de 200k, 1M e 2M, mas esses números não representam o conjunto de trabalho realmente utilizável
• Janelas de contexto grandes são, em grande parte, números de marketing
  • A arquitetura por trás delas funciona, mas encobre problemas que o mecanismo básico de atenção na prática não resolve
  • Os números exibidos no produto aumentam a cada release, mas a parte realmente utilizável não acompanha no mesmo ritmo
• O RULER e o relatório de context rot da Chroma mostram que o contexto efetivo é apenas uma parte do número anunciado
  • Quanto mais a janela de contexto é preenchida, mais o desempenho se degrada gradualmente

Uma forma de trabalhar mantendo as sessões curtas

• Agentes mais recentes começaram a incluir recursos de compressão automática para lidar com sessões longas
  • O Claude Code executa auto-compact quando a sessão fica longa, resumindo o histórico e recomeçando
  • Isso ajuda, mas só entra em ação depois de já ter passado tempo na zona embotada
  • O próprio resumo também é gerado por um modelo cujo desempenho já caiu
• Uma forma melhor de passagem de contexto é abrir uma nova sessão e entregar uma especificação escrita manualmente
  • Uma especificação escrita diretamente oferece um sinal mais forte do que um resumo automático
  • Isso porque a pessoa pode decidir por conta própria o que será importante dali em diante
  • Esse método corresponde à abordagem de breadcrumb, que deixa artefatos limpos para a próxima sessão ou para a próxima pessoa continuar o trabalho
• obra/superpowers e mattpocock/skills organizam o fluxo de trabalho de agentes em torno de pequenos artefatos nomeados
  • PRD, planos, skills e handoff de subagentes são exemplos desses artefatos
  • Cada artefato move informações para fora da sessão ao vivo para que a próxima sessão possa lê-las
  • Isso ajuda a manter a sessão de trabalho dentro da zona inteligente
• A janela de contexto deve ser tratada como um orçamento
  • Pressuponha que a parte realmente útil são apenas alguns chunks iniciais
  • Informações movidas da sessão ao vivo para um artefato escrito reduzem a quantidade de itens disputando a atenção do modelo

[baam12]

Quem dera fossem 100 mil; dá para ver que ele já sofre só com 40 ou 50 mil tokens.

[GN⁺]

Comentários no Hacker News

• É bem divertido aprender os fundamentos de IA, mas não concordo com a direção que as coisas estão tomando
  É difícil colocar em palavras o quão inquietantes parecem os comentários em threads como esta. Relatos bem-intencionados do tipo “para mim, com XYZ aconteceu isso” parecem conselhos de threads do Facebook sobre cuidados com pets ou culinária
  Grupos de impressão 3D no Facebook são ainda piores; quem imprime, mas também quer entender o que realmente está acontecendo, provavelmente sabe do que estou falando
  No mundo dos LLMs, especialmente no mundo dos LLMs em nuvem, parece que todo o rigor compartilhado desmoronou completamente, e no fim tudo se reduz a imitação quase mística. Ninguém fica mais certo ou mais errado do que ninguém
  A sensação é de algo como “você já limpou o contexto com detergente Dawn, deixou secar e depois passou uma camada de bastão de cola?”
  Não quero ser duro demais com as pessoas que estão tentando ajudar. Só que isso parece muito diferente de threads sobre outros temas. Normalmente, a sugestão de alguém é debatida ou refinada por outras pessoas, e às vezes alguém explica algo como o modo de seleção do histórico do bash e isso muda sua vida; já threads como esta acabam indo para um “não é estranho que, se você ameaçar, isso funcione?”

  • A natureza arbitrária e não determinística do fluxo de trabalho com LLMs realmente incomoda. Como alguém mais antigo de embarcados/sistemas, sempre priorizei determinismo e reprodutibilidade
    Ainda assim, agentes são impressionantes, e também é divertido virar um “arquiteto do processo de raciocínio”. Não vou voltar atrás. Mesmo que o desenvolvimento de IA parasse hoje, minha carreira já não seria a mesma de antes
  • Na indústria de tecnologia isso sempre existiu, muito antes dos LLMs aparecerem
    Já passei por reuniões demais em que decisões eram tomadas não com base em critérios objetivos e mensuráveis, mas porque “uma empresa um pouco mais famosa faz assim”. Mesmo quando havia evidências de que aquela empresa nem seguia essa abordagem de forma geral, isso tinha surpreendentemente pouco peso
  • Conselhos de TI sempre tiveram um pouco disso. Quanto mais complexos forem os sistemas e os resultados, mais difícil fica definir claramente o que é “melhor” e o que é “pior”
    Somando a isso o fato de que LLMs são fortemente não determinísticos, conselhos sobre LLMs acabam sendo praticamente como conselhos de jardinagem
    Até mesmo “benchmarks” na maioria dos casos são mais uma tentativa de cristalizar com algum sucesso a intuição de alguém
  • Me identifico muito com a frustração e concordo em grande parte. Sempre que tento formalizar um fluxo de trabalho baseado em LLM, acabo me frustrando de novo porque parece que ninguém realmente sabe por que certas coisas funcionam e outras não
    Então no fim volto para /plan e mando “anotar num documento Markdown para depois, antes de iterar na implementação”, esperando que no mês seguinte apareça algo mais rigoroso e com base racional melhor
    Não uso bastão de cola de jeito nenhum, porque não preciso. Mas Dawn parece de fato ser bem eficaz para fazer a build plate da Bambu voltar a ter boa aderência. Não fui atrás disso de propósito; eu já tinha em casa para lavar louça. Como IPA não funcionou, tentei Dawn, e isso fez as peças voltarem a aderir bem várias vezes. Ainda não cheguei a N=30
  • Talvez essa própria ideia de “rigor compartilhado” na nossa cabeça seja uma ilusão, e os LLMs e seu problema de contexto só estejam revelando isso
    Em décadas vivendo na indústria de tecnologia, não vi muito rigor. Ferramentas se acumulam, paradigmas nascem, morrem e reaparecem, e para qualquer régua que mede alguma coisa existe outra régua concorrente com unidades diferentes. Passando pela física de potência e sinal e pelo custo dominante dos wafers de silício, em comparação com algumas poucas disciplinas muito mais antigas, quase todos nós somos mais parecidos com remendadores com diferentes níveis de habilidade
    Limites de contexto têm sido relativamente fáceis de lidar. Basta definir uma especificação e limitar o escopo. Para um LLM produzir bons resultados, ele precisa de uma especificação clara e de orientação forte
    Mas isso também é só a sensibilidade prática improvisada de hoje. Talvez daqui a 90 dias até esse fardo desapareça, e um único prompt simples possa gerar um sistema operacional de classe mundial, uma linguagem de programação e até a base formal matemática para ambos

• Eles evitam o problema do tamanho do contexto impondo uma única restrição simples no loop do agente. No thread principal da conversa com o usuário, bloqueiam todas as chamadas de ferramenta. O trabalho que exige chamadas de ferramenta só acontece dentro de chamadas recursivas do agente, e apenas o resultado é devolvido ao chamador
  Mesmo em uma base de código com mais de 1 milhão de LOC, conseguiram manter a mesma conversa de alto nível o dia inteiro sem chegar a um limite de tokens significativo. Não é preciso nenhum truque de compressão ou resumo. Mesmo que a chamada recursiva queime 50 milhões de tokens, o thread raiz pode ficar abaixo de 100 mil tokens
  É preciso refazer o “bootstrap” toda vez que o agente desce de novo para Nárnia, mas isso é muito mais eficiente do que carregar sempre um contexto plano enorme tentando conter tudo
  Recursão é muito eficaz para controlar o uso de tokens, mas também tem limites. Nunca viram ganho ao passar de profundidade recursiva 1. Já viram o agente tentar algumas vezes, mas o desempenho real não apareceu. Parece que a recursão simbólica externa não é algo em que os modelos de ponta tenham sido treinados. Eles são ótimos em imitar recursão dentro do contexto, mas se o objetivo é reduzir o uso de tokens, isso vai na direção errada

  • Se você usa Claude Code, basta mandar que todo o trabalho seja feito dentro de workflows. Existe ferramenta para isso, é um recurso que saiu junto com o Opus 4.8, e parece lidar um pouco melhor com tarefas longas
    Nesse ponto, a conversa principal passa a ter só o papel de coordenar a tarefa
  • Faz sentido intuitivamente. Fiquei curioso sobre qual harness você usa para impor esse tipo de restrição e como configura isso
  • Parece que o Claude Code faz isso automaticamente em alguns casos. Deve haver alguma heurística do tipo “isso vai consumir muito contexto”, e então ele decide passar para um subagente
    Vejo isso com frequência em fluxos de resolução de problemas ou análise de dados: ele joga a coleta e a agregação de dados para um subagente e só traz de volta os resultados resumidos
    De forma parecida, às vezes faz o agente principal manter o contexto em um documento de design ou arquivo Markdown, atualizando-o enquanto avança. Aí fica possível limpar, reiniciar ou passar adiante a qualquer momento
  • Estou usando outra abordagem e ainda avaliando o quão bem ela funciona. Em vez de entrar em recursão, quando o contexto fica grande demais ou emperra, o agente passa por uma etapa de resumo/relato/reflexão, reinicia o thread, grava as descobertas principais em memória persistente e pode reescrever o prompt
    Em outras palavras, é mais próximo de uma recursão com otimização de chamada de cauda
    Em certo sentido, é uma generalização de uma abordagem guiada por especificação: além da especificação formal, um buffer herdado permanece na memória
  • O interessante é que reduzir contexto e uso de tokens beneficia o usuário, mas vai contra o interesse financeiro dos fornecedores de IA
    Mesmo sem ser especialista, esse “truque simples” parece capaz de corrigir o problema de contexto e dar um controle muito mais fino sobre o uso de tokens. Obrigado por compartilhar essa dica nos comentários do HN. Isso pode mudar a forma como pessoas por dentro do assunto usam agentes de IA daqui para frente. É difícil acompanhar

• Desde que a Anthropic passou a oferecer uma janela de contexto de 1 milhão de tokens no plano de assinatura, não tive esse tipo de experiência com o Opus. Normalmente já passo de 500 mil tokens com frequência, e às vezes chego perto de 800 mil sem ver esse problema
  Vi isso um pouco acima de 900 mil tokens, já perto do limite real, mas não foi tão grave quanto o autor descreveu
  Para começo de conversa, em uma tarefa única ou em um conjunto de tarefas relacionadas o suficiente para manter o mesmo contexto, é raro preencher a janela de contexto desse jeito; normalmente fico entre 200 mil e 600 mil
  Isso não quer dizer que ninguém tenha essa experiência, mas acho estranho que para algumas pessoas isso aconteça com frequência suficiente para até receber um nome

  • Vejo esse tipo de relato com frequência, mas me parece absurdo porque já vi os modelos Opus cometerem erros básicos de lembrança com menos de 100 mil tokens várias vezes
    Pessoalmente, acho que a faixa em que o Opus é inteligente fica abaixo de 60 mil tokens. O Opus 4.7 e 4.8 são piores por causa de um tokenizador mais granular
  • O Opus 4.6 parecia chapado depois de passar de 200 mil, pulei o 4.7, o 4.8 foi bem até cerca de 350 mil, e o Fable foi excelente mesmo acima de 400 mil em testes limitados
    A qualidade parece estar em tendência de alta
  • Nem todo mundo usa o mesmo modelo e o mesmo harness, nem usa o modelo da mesma forma
    Modelos e versões de modelos usam arquiteturas de atenção diferentes entre si, e isso afeta o desempenho em contexto longo. A quantidade e o tipo de treino em contexto longo também certamente variam
    Agentes diferentes também montam o contexto de formas diferentes e implementam a compressão de contexto de maneira distinta
    A menos que seja o mesmo modelo, o mesmo agente/harness e tarefas muito parecidas, não há motivo para esperar experiências iguais com o comportamento do modelo em relação ao tamanho do contexto
  • Costumo passar de 300 mil com frequência e já trabalhei com 800 mil, mas o problema é claramente observável
    Dependendo do problema, uma janela de contexto grande pode funcionar, mas tenho a sensação de que é mais eficaz tender para contextos menores, abaixo de 300 mil
  • Concordo. A linha Claude vem melhorando nisso a cada lançamento
    O Opus 4.5 começava a falhar em chamadas de ferramenta ao se aproximar do limite de 200 mil, o Opus 4.6 ia até uns 300 mil antes de se confundir, o Opus 4.7 chegava a cerca de 400 mil, mas depois disso entrava na zona burra. No Opus 4.8, já tive sessões que passaram de 500 mil com folga
    Usei o Fable por pouco tempo, mas tive algumas sessões que foram até 800 mil~900 mil sem problemas

• As versões recentes do Opus ficam bem acima de 100 mil, mas normalmente tento manter abaixo de 200 mil
  Por isso acho que os chamados sistemas de memória em geral são um erro que deixa o modelo mais burro. O modelo não tem memória, só contexto, e quanto mais fatos irrelevantes você enfia no contexto, menos contexto sobra para o problema. Quanto menos interferência, melhor o resultado
  A forma de fazer o agente “lembrar” de algo é fazê-lo documentar o trabalho como um desenvolvedor humano faria ao construir um projeto amigável para outros desenvolvedores. Uma boa documentação de desenvolvimento com página de índice e um bom plano com checklist, salvos como arquivos Markdown concisos e com commit no repositório, são a memória ideal para o modelo e a documentação ideal para entender o que diabos o modelo andou fazendo. Isso também ajuda quando uma pessoa ou outro modelo faz code review, e não tem desvantagem

  • Pelo menos no meu caso, o Opus continua escrevendo coisas na memória o tempo todo, mas sempre esquece de consultar essa memória antes de repetir o mesmo erro
    Então “lembre-se de verificar a memória!” acaba sendo salvo de novo na memória. Definitivamente não é um sistema que funcione bem
  • Sistemas de “memória” são uma forma de os desenvolvedores sentirem que estão contribuindo com a IA

• Quase todos os comentários aqui apelam para experiência pessoal. Em contraste, o post original faz referência a dois estudos que comparam o desempenho em testes padronizados de vários modelos
  Não sei dizer o quão bons são esses testes, mas não podem ser piores do que evidência anedótica sobre algo tão nebuloso e subjetivo quanto o desempenho de LLMs

  • Para acrescentar mais evidência anedótica: em todos os testes que fiz, a família Llama foi péssima em seguir instruções. Não sei sobre os outros modelos do RULER
    Nos resultados do Chroma aparece o Sonnet 4, e na minha experiência o Sonnet 4 também foi péssimo. O mesmo prompt que funcionou perfeitamente no Sonnet 4.5 falhou de forma desastrosa no Sonnet 4
    Eu gostaria de ver um novo teste que incluísse tanto os modelos mais avançados quanto os de pesos abertos. Os modelos de ponta parecem sempre seguir melhor as instruções e se desviar menos do tema; seria bom ter dados que sustentem isso
  • Esses estudos são de 2024 e 2025. Não se aplicam aos modelos Claude atuais

• Tenho tido bastante sucesso agindo como gerente de produto da IA e exigindo com firmeza que ela escreva um PRD curto para cada funcionalidade que vai criar
  Isso permite consultar depois o que foi feito ao longo do tempo e faz cada funcionalidade derivar menos. Mantenho uma conversa separada para cada funcionalidade
  Para mim, é um meio-termo adequado: evita descarrilar, mas ainda permite consultar decisões passadas quando necessário. O que não gosto na abordagem do Pocock é que ela escreve menos PRDs e tenta alinhar primeiro com uma discussão aprofundada, o que desperdiça demais a melhor parte da janela nesse vai-e-volta inicial

  • Fico curioso se isso é feito de forma ad hoc ou se você usa uma abordagem mais estruturada, como o openspec
    Eu também tendo a planejar primeiro, mas isso acaba ficando como uma lista de tarefas dentro da sessão e depois é difícil de consultar

• Investigar o que acontece dentro do agente provavelmente não vai continuar sendo parte do desenvolvimento de software por muito tempo
  Pessoalmente, eu já trato LLMs e agentes como uma caixa-preta. Dou cada pedido de funcionalidade a vários LLMs e comparo os resultados. Não escrevo “sessões” manualmente. Eu só olho o resultado. Se não gosto, faço git reset --hard, mudo o prompt e recomeço o pedido da funcionalidade
  Mantenho logs para ter uma noção contínua de qual agente faz melhor o trabalho e calculo a pontuação ELO do agente que melhor atende às minhas necessidades. O que importa para mim é essa pontuação; como o agente a alcançou não me importa tanto

  • Considerando o custo real de inferência, isso é realmente um jeito absurdamente desperdiçador de trabalhar, e não é algo de que se deva se orgulhar
  • Fico curioso sobre que tipos de projeto ou trabalho de código você delega
    Imagino que possa funcionar para tipos de trabalho de frontend que não exigem muita segurança ou outras formas de verificação
    Mas não parece adequado para setores regulados ou tarefas em que é preciso extremo cuidado
  • Qual modelo está na frente no momento?

• Sim, gestão de contexto é o ponto central
  Eu construo meu próprio framework e gasto muito tempo depurando esse problema, e mais do que o tamanho absoluto do contexto, o problema é a probabilidade de haver lixo ou instruções enviesadas dentro da janela, encobrindo o que o usuário considera importante
  Isso aparece como o LLM insistindo em repetir coisas que já falharam na abordagem imediatamente anterior. Se algo aparece com frequência dentro da janela de contexto, ele ganha peso, mesmo que esteja errado
  Também existem muitos truques, como não encher o LLM de ferramentas e, em vez disso, dar a ele uma ferramenta para procurar ferramentas
  Mas a solução maior está no processo. Usar algo como superpowers para forçar o LLM a seguir etapas e controlar qual contexto será levado adiante

• Criei uma extensão pessoal bem pequena para o Pi para adicionar o comando /last. Ela apaga a sessão inteira e deixa só a última mensagem de saída do agente
  Isso permite uma “compressão” manual. Basicamente, eu digo ao agente “resuma o plano discutido com referências aos arquivos que precisam ser editados”, depois chamo /last e então mando implementar
  [1] https://pi.dev/

• Não gosto de agrupar tudo isso sob o rótulo de “modelos”. Cada modelo tem uma arquitetura de atenção diferente, então pode haver diferenças grandes no comportamento com contexto longo
  É verdade que contexto longo é um problema e que a maioria dos modelos sofre degradação de qualidade, mas eu não generalizaria diretamente o comportamento de modelos antigos para modelos novos