No post anterior descrevi como a inflação de contexto drena orçamento sem decisão consciente do time. A pergunta que ficou aberta é operacional: dado que o sistema envia tokens demais, quais são as técnicas concretas pra reduzir esse volume sem degradar a qualidade das respostas. Pra mim, a resposta não é uma técnica única, é um conjunto de mecanismos atuando em camadas diferentes do problema.
A primeira distinção que considero necessária é entre contexto estático e contexto dinâmico. O estático é tudo que não muda entre chamadas, do tipo system prompt, definição de ferramentas, exemplos few-shot. O dinâmico varia a cada interação, e inclui histórico conversacional, resultados de tool calls, chunks de RAG e estado intermediário de agentes. Prompt caching resolve o custo do estático com eficiência brutal, cache hits custam 10% do preço base e reduzem latência em até 85%, mas não faz nada pelo dinâmico, que é exatamente a porção que cresce sem controle à medida que a conversa ou o pipeline avança.
A técnica mais direta pra comprimir contexto dinâmico é a sumarização progressiva do histórico conversacional. Pra evitar reenviar todas as mensagens anteriores a cada chamada, o sistema periodicamente condensa os turnos mais antigos num resumo estruturado e mantém apenas os turnos recentes na íntegra. A implementação do Claude Code segue esse padrão: quando a conversa se aproxima do limite da context window, o modelo gera um resumo que preserva decisões arquiteturais e bugs não resolvidos enquanto descarta outputs de ferramentas redundantes, e reinicia com esse contexto comprimido mais os cinco arquivos acessados mais recentemente. O trade-off é real, até porque a sumarização perde nuances e pode introduzir drift semântico ao longo de muitas rodadas de compressão. A mitigação que considero efetiva é manter um buffer de mensagens recentes intactas, tipicamente os últimos três a cinco turnos, e comprimir apenas o que está além desse horizonte.
Uma variante menos custosa da sumarização é a limpeza de resultados de ferramentas. A Anthropic oferece isso como funcionalidade nativa pelo recurso de context editing, em que a estratégia de tool result clearing remove automaticamente os resultados brutos de tool calls antigas quando o contexto ultrapassa um threshold configurável. Um agente que leu dez arquivos nas últimas vinte interações carrega os dez outputs completos no contexto, mesmo que apenas o último seja relevante. Substituir esses resultados antigos por um placeholder ou por uma referência compacta ao que foi feito elimina milhares de tokens por chamada sem nenhuma chamada adicional ao modelo e sem risco de alucinação, até porque não há geração envolvida.
Em pipelines de múltiplos agentes, a arquitetura de sub-agentes oferece uma compactação estrutural. Cada sub-agente especializado recebe um escopo restrito, executa sua tarefa consumindo potencialmente dezenas de milhares de tokens entre tool calls e raciocínio intermediário, e retorna ao orquestrador apenas um resumo condensado do resultado, tipicamente entre 1.000 e 2.000 tokens. O orquestrador nunca vê o contexto completo que o sub-agente processou. Num sistema com três sub-agentes que consomem 20.000 tokens cada, o orquestrador recebe 4.500 tokens no lugar dos 60.000 que precisaria absorver sem essa separação, uma redução de 92% no contexto que ele precisa carregar.
Na camada de retrieval, na minha análise, a compactação mais efetiva consiste em recuperar menos chunks com maior precisão, antes que qualquer compressão posterior seja necessária. Mencionei no post anterior pipelines que injetavam dez chunks quando dois bastavam. A solução passa por três frentes complementares: ajuste do threshold de similaridade do retriever, reranking dos resultados antes da injeção e budget fixo de tokens pra RAG por chamada. Um reranker como o Cohere Rerank, serviço de reordenação semântica da Cohere, ou o próprio modelo em modo de avaliação consegue ordenar chunks por relevância efetiva ao query, permitindo que o sistema injete apenas os dois ou três com maior score, no lugar de um número arbitrário. O custo adicional do reranking é marginal comparado à economia de tokens no modelo principal.
Pra compressão no nível de tokens existe o LLMLingua, desenvolvido pela Microsoft Research, que faz poda guiada por sinais do modelo, removendo tokens que contribuem pouco pra semântica e preservando os que o modelo efetivamente precisa pra manter a capacidade de raciocínio. Os benchmarks publicados mostram até 20x de compressão com apenas 1,5% de perda de performance no GSM8K. O LongLLMLingua, voltado pra contextos longos, reporta ganhos de até 21,4% em acurácia no benchmark NaturalQuestions com 4x menos tokens, até porque a remoção de informação irrelevante alivia o problema de lost in the middle. Na minha avaliação a técnica é particularmente útil em cenários de long-context RAG em que o volume de texto recuperado é alto e a proporção de informação relevante é baixa.
O princípio que unifica essas técnicas, pra mim, está bem capturado na formulação que a Anthropic adota em sua documentação de context engineering: encontrar o menor conjunto de tokens de alto sinal que maximize a probabilidade do resultado desejado. Cada token no contexto ocupa computação no mecanismo de atenção e ainda compete com outros por relevância, além de custar dinheiro. Compactação intencional é tratar cada token como recurso escasso, mesmo quando a context window diz que cabe mais. A window de 200K tokens do Claude Sonnet 4 ou de 1M do GPT-4.1 funciona como margem de segurança pra cenários excepcionais. O sistema bem projetado opera na fração inferior dessa capacidade, reservando espaço pra picos sem que o custo médio reflita o tamanho máximo da janela.