Compressão de memória em agentes de IA apaga até um terço das regras da tarefa, e os benchmarks não percebem

Compressão de memória em agentes de IA apaga até um terço das regras

da tarefa, e os benchmarks não percebem

Quando um agente de IA trabalha em uma tarefa por horas — digamos, escrevendo código ou tentando reproduzir um artigo científico — ele eventualmente esgota toda a janela de contexto disponível: a conversa, as chamadas de ferramentas e os resultados delas. Para continuar, desenvolvedores de sistemas agênticos como Claude Code, Codex CLI, Cursor ou OpenCode usam uma técnica chamada "compressão de contexto" (compaction): pede-se ao modelo que resuma brevemente tudo o que foi feito, o histórico antigo é apagado e o trabalho continua a partir desse resumo. O problema é que um resumo, por definição, perde detalhes — e não está claro exatamente o que se perde e o quão crítico isso é.

Foi exatamente isso que os pesquisadores Sahar Abdelnabi e Maksym Andriushchenko, do Max Planck Institute for Intelligent Systems, decidiram verificar.

Para manter o experimento rigoroso, eles fixaram a mesma ferramenta de "arnês" para os agentes — o projeto de código aberto OpenCode — de modo que as diferenças nos resultados não pudessem ser explicadas por particularidades de diferentes plataformas de software. Dentro do OpenCode, implementaram cinco métodos diferentes de compressão de contexto e testaram quatro modelos de ponta — Claude Opus 4.6, GPT-5.

3-Codex, GPT-5.4 e Gemini 3.1 Pro Preview — em três tarefas práticas longas: PaperBench (reproduzir um artigo científico da ICML a partir da descrição, sem acesso ao código dos autores), ProgramBench (escrever do zero um utilitário de linha de comando, tendo apenas um executável de amostra e documentação) e PostTrainBench (treinar e ajustar uma pequena rede neural em uma única GPU em até 10 horas).

A janela de contexto decide tudo; o método de compressão, quase nada

A conclusão principal diz respeito aos dois modelos com janela de um milhão de tokens — Claude Opus 4.6 e GPT-5.4. O desempenho deles praticamente não mudou, comprimindo a memória a cada 160 mil tokens ou a cada 380 mil — a diferença ficou dentro da margem de erro estatística. Já o GPT-5.3-Codex, com uma janela de apenas 400 mil tokens, apresentou um resultado visivelmente pior no PaperBench quando a compressão era precoce e frequente: 0,38 ponto com limiar de 160 mil tokens contra 0,60 com limiares de 260 mil ou mais — quase a metade. Na tarefa de escrita de código (ProgramBench) essa diferença não apareceu, e no PostTrainBench os resultados variaram demais para permitir conclusões.

Os pesquisadores também verificaram separadamente se alguma estratégia de compressão "mais inteligente" ajudava em relação ao simples resumo com as próprias palavras do modelo. Testaram cinco variantes: um resumo comum; um resumo comum mais a limpeza de resultados antigos de chamadas de ferramentas; salvar o histórico completo em um arquivo separado no disco antes da compressão (para, teoricamente, poder voltar e reler tudo depois); remover do histórico os blocos de raciocínio do modelo antes de montar o resumo; e, por fim, fazer o resumo com um modelo mais barato — Claude Haiku 4.5 — em vez do modelo principal que executa a tarefa.

Nenhum dos métodos avançados superou o resumo comum em nenhum benchmark. Pior: as variantes mais agressivas — remover o raciocínio e transferir o resumo para um modelo menor — reduziram visivelmente o resultado de alguns modelos no PaperBench, em até 20 pontos, mas não afetaram em nada outros modelos. Isso significa que um método de compressão que funciona bem com um modelo não pode simplesmente ser transferido para outro.

Para onde vão as regras do jogo

A descoberta mais preocupante não tem a ver com desempenho, mas com segurança. Na tarefa ProgramBench, o agente recebe, no início, três regras rígidas: não copiar nem vincular o código-fonte do programa de referência, não acessar a internet (em particular, para não baixar o código original) e escrever uma implementação realmente original, e não um invólucro em torno de uma solução já pronta. Essas regras existem apenas no texto da primeira mensagem — e se o resumo da compressão não as repetir, o agente simplesmente as esquece, diferentemente do objetivo da tarefa e de seu próprio progresso, que podem ser relidos a partir de arquivos no disco.

Pois bem: já após a primeira compressão de contexto desaparece, em média, aproximadamente uma das três regras. Após a décima compressão, já faltam duas das três. Em sessões reais de usuários do conjunto de dados SWE-chat o quadro é parecido: na compressão perdem-se as instruções sobre como o agente deve trabalhar e o que não deve fazer — e isso ocorre cerca de 6 vezes mais do que a perda dos requisitos sobre o que precisa ser construído.

Por que os testes atuais não percebem isso

Os autores fazem uma ressalva importante: os próprios benchmarks normalmente usados para avaliar agentes são construídos de forma que as perdas da compressão são facilmente contornadas. O objetivo da tarefa é fixo, o usuário não muda nada ao longo do processo, e todo o progresso do agente é salvo em arquivos no disco que podem ser relidos em qualquer momento. Por isso, de tudo o que a compressão apaga, o que realmente se perde é apenas o que não está registrado em nenhum outro lugar — sobretudo as restrições e regras mencionadas uma única vez no início.

Em conversas reais com usuários, onde há muito mais instruções e esclarecimentos que não ficam guardados separadamente, o custo desse esquecimento é muito maior.

A conclusão prática para equipes que constroem sistemas agênticos: se a tarefa é longa e restrições rígidas importam (não tocar no banco de dados de produção, não acessar a rede, não excluir arquivos sem confirmação), não se pode contar com que um resumo comum vá preservá-las — é melhor registrar explicitamente essas regras separadamente do histórico geral e relê-las a cada compressão, ou então escolher um modelo com folga de contexto maior e comprimir com a menor frequência possível.