Compactação de contexto apaga um terço das regras antitrapaça no ProgramBench

Tarefas longas de agentes cada vez mais deixam de caber na janela de contexto, e o harness do agente precisa abrir espaço: comprimir o histórico, descartar o que sobra e seguir o trabalho a partir de um resumo curto. Essa técnica se chama compactação e está presente em praticamente todo agente de programação. Quase ninguém a avaliou de forma sistemática em modelos frontier e tarefas realistas: os trabalhos anteriores usavam modelos abertos pequenos, em trajetórias de brinquedo ou sintéticas. O grupo de Jeanne Salle, com quatro coautores, preencheu essa lacuna e chegou a um resultado com duas camadas. Os benchmarks quase não percebem a compactação, mas o trabalho real percebe.

Como o experimento foi montado

Os autores fixaram o harness OpenCode e implementaram nele cinco estratégias de compactação. Depois, executaram três modelos frontier em três benchmarks longos. Dois dos três modelos têm contexto de 1 milhão de tokens; o terceiro é o GPT-5.3-Codex, com a menor janela da amostra. O limiar que dispara a compressão também variou.

• Harness: OpenCode, o mesmo em todas as execuções.
• Estratégias: cinco variantes de compactação; a base de comparação é a autossumarização, em que o próprio modelo reconta seu histórico.
• Modelos: dois com janela de 1M e o GPT-5.3-Codex.
• Benchmarks: PaperBench, ProgramBench, PostTrainBench.
• Conjunto de dados adicional: sessões reais de usuários do SWE-chat.

Onde a compactação é segura e onde não é

Nos modelos com janela de 1M, o limiar de compressão não afeta o resultado de forma perceptível. No GPT-5.3-Codex, o quadro é outro: no PaperBench, a qualidade cai com limiares baixos; no PostTrainBench, o efeito é mais fraco e menos definido. A lógica é simples: quanto menor a janela, mais frequente e mais agressiva precisa ser a compressão, e mais perdas se acumulam.

Os métodos sofisticados não se justificaram. Nenhum superou a autossumarização simples. As abordagens que descartam mais conteúdo custaram até 20 pontos a alguns modelos e nada a outros. Ou seja, a sensibilidade à compactação agressiva depende do modelo e não dá para prevê-la de antemão.

A descoberta mais incômoda diz respeito às restrições. No ProgramBench, já o primeiro resumo perde, em média, cerca de um terço das regras antitrapaça da tarefa, e a fração perdida cresce de forma monotônica a cada nova compactação. Um agente que esqueceu que não pode espiar nem contornar a verificação continua trabalhando formalmente, mas agora sob outras regras. E ele não avisa sobre isso.

Nas sessões reais do SWE-chat, a diferença é ainda maior. As instruções sobre como o agente deve trabalhar e o que não deve fazer são descartadas cerca de 6 vezes mais do que as especificações do que precisa ser construído. O modelo lembra bem do objetivo e mal da forma de trabalhar: estilo, proibições, acordos com o usuário.

Por que os benchmarks induzem ao erro

Os autores chamam os benchmarks atuais de «amigáveis à compactação». Neles, o objetivo é fixo e está escrito no enunciado, e o progresso do agente fica em disco: código, arquivos, logs. Por isso, quase tudo o que a compressão tirou do contexto pode ser recuperado relendo o repositório. Só não se recupera o que não está registrado em nenhum outro lugar: restrições, informações passadas oralmente no diálogo, motivos de decisões anteriores. Numa sessão real há muitas coisas assim; num benchmark, quase nenhuma. Daí a conclusão: números verdes nos testes não garantem que o agente não vá perder requisitos em um projeto real.

Para quem constrói agentes, as conclusões são práticas. Não vale complicar a compactação: a autossumarização por padrão continua sendo uma base sólida, e economizar tokens com descarte agressivo pode custar até 20 pontos de qualidade. Regras e proibições devem ficar fora do histórico da conversa: no prompt de sistema, em um arquivo de instruções no repositório ou em um bloco fixado que a compressão não toca.

Depois de cada compactação, vale conferir automaticamente o resumo contra a lista de restrições. Na escolha do modelo, a janela de contexto não importa por si só: quanto menor ela é, mais vezes a compactação dispara e maior o risco de perda silenciosa de requisitos. Por fim, convém avaliar agentes em cenários nos quais parte das condições existe apenas no diálogo; caso contrário, o benchmark mede a memória do objetivo, e não a disciplina de trabalho.