Compressão de contexto
A compressão de contexto reduz os tokens enviados ao modelo em cada chamada preservando a informação de que ele realmente precisa para agir. Use-a em agentes de longa duração e conversas extensas para cortar custo e latência e permanecer dentro da janela de contexto. As três alavancas são resumir o histórico, podar contexto irrelevante e comprimir prompts. O risco central é a perda: descartar o único detalhe que importava. Meça a informação retida, não apenas os tokens economizados.
Problema
Agentes de longa duração e conversas de múltiplos turnos acumulam contexto: cada resultado de ferramenta, mensagem anterior e documento recuperado é reenviado na chamada seguinte. A contagem de tokens cresce de forma quase linear com a interação, então o custo e a latência por chamada sobem, e por fim a janela transborda e o conteúdo mais antigo (às vezes o mais importante) é truncado em silêncio. As correções ingênuas —janelas maiores, truncamento mais agressivo— ou elevam o custo ou destroem a informação de que o modelo precisa para manter a coerência.
Quando usar
Aplica-se quando o contexto cresce sem limite em relação ao que cada passo precisa: assistentes conversacionais com históricos longos, agentes autônomos iterando sobre muitas chamadas de ferramentas, pipelines RAG que recuperam em excesso e jobs em lote em que o tamanho do prompt domina o custo. Encaixa-se quando grande parte do contexto acumulado é redundante ou obsoleto, quando você controla a montagem do prompt e quando pode tolerar algum erro de reconstrução. Encaixa-se mal quando cada token é essencial (tarefas jurídicas, de auditoria, de recuperação exata) ou quando as interações são curtas o bastante para a janela nunca ser pressionada.
Solução
Trate o contexto ativo como um orçamento que você gerencia ativamente, e não como um registro somente de anexação. Existem três alavancas complementares. O resumo substitui um trecho do histórico por uma sinopse mais curta —normalmente um resumo contínuo dos turnos antigos, atualizado periodicamente, enquanto os turnos recentes permanecem literais. A poda remove o contexto irrelevante para o passo atual: deduplica, descarta saída de ferramenta obsoleta e seleciona apenas os trechos recuperados que ultrapassam um limiar de relevância. A compressão de prompts (por exemplo LLMLingua) usa um modelo menor para apagar ou reformular tokens de baixa informação antes de enviar o prompt, trocando um pequeno custo de exatidão por grandes reduções de tokens. Combine essas alavancas em um pipeline com limites explícitos: mantenha uma janela recente literal, um resumo contínuo do histórico antigo e um espaço de recuperação preenchido sob demanda. Proteja uma região 'fixada' para fatos que nunca devem ser comprimidos —identificadores, restrições, o objetivo atual. E, fundamentalmente, instrumente o resultado: rode um conjunto de avaliação comparando respostas com e sem compressão para ver quando a qualidade se degrada, e ajuste a agressividade por carga de trabalho em vez de globalmente. A compressão é um dial de qualidade versus custo, não um ganho gratuito.
Componentes
Benefícios
- Enviar menos tokens reduz diretamente o custo de entrada em cada chamada, o que se acumula ao longo de loops de agente longos e tráfego de alto volume.
- Prompts menores significam menos a codificar e menor tempo até o primeiro token, melhorando a resposta em fluxos interativos e de agentes.
- Limitar o contexto ativo permite que conversas longas e agentes de muitos passos continuem sem transbordar a janela nem truncar em silêncio.
- Remover contexto redundante e obsoleto pode melhorar a qualidade ao reduzir a distração, ajudando o modelo a atender ao que importa agora.
Riscos
- Resumos e poda podem descartar o único detalhe que depois se mostra decisivo, produzindo respostas erradas com confiança.
- Resumos contínuos resumem resumos anteriores; pequenas omissões se acumulam ao longo de muitos ciclos até o fio desviar sem aviso.
- Rodar um resumidor ou compressor adiciona sua própria latência, custo e superfície de falha, que pode anular a economia em interações curtas.
- A expulsão agressiva pode remover em silêncio restrições ou instruções de que o modelo ainda depende, sem um sinal de erro evidente.
Quando não usar
- Quando cada token é essencial —jurídico, auditoria, conformidade ou extração precisa de dados— a compressão com perda é inaceitável.
- Se as conversas raramente pressionam a janela, a sobrecarga de compressão custa mais do que economiza e adiciona complexidade desnecessária.
- Sem um arcabouço de avaliação de retenção, não implante nada: você não consegue saber se a compressão está degradando as respostas em silêncio.
Tecnologias
Exemplos
- Um agente que itera sobre uma base de código grande mantém uma janela recente literal mais um resumo contínuo dos passos anteriores, fixando a especificação da tarefa e os caminhos de arquivo para não perder o objetivo.
- Um bot de suporte multissessão resume os turnos anteriores em um resumo de caso compacto, podando subproblemas resolvidos enquanto fixa as restrições da conta do cliente.
- Um pipeline de recuperação que traz muitos trechos aplica poda por relevância e compressão de prompts para enviar apenas as passagens de alto sinal, cortando tokens sem perder a resposta.
KPIs
- Tokens por chamada (entrada)
- O principal motor do custo. Acompanhe a distribuição antes e depois da compressão; um resultado saudável é uma redução clara sem aumento de erros a jusante.
- Retenção de informação / qualidade da tarefa
- Compare respostas com e sem compressão em um conjunto de avaliação. O bom é a qualidade se manter estável dentro da sua tolerância enquanto os tokens caem.
- Latência de ponta a ponta
- Líquida da sobrecarga de compressão. O bom é menor latência total; observe que as chamadas do resumidor ou compressor não apaguem a economia.
- Taxa de transbordo / truncamento de contexto
- Com que frequência as interações atingem o limite da janela. O bom é levar isso a zero sem recorrer a descartar conteúdo fixado.
Modos de falha observados
- Um resumo omite uma restrição mencionada no início; muitos turnos depois o agente a viola porque esse fato simplesmente desapareceu do contexto.
- Resumir repetidamente amplifica erros de paráfrase e omissões até o resumo acumulado não refletir mais o que de fato aconteceu.
- Um orçamento mal configurado comprime identificadores ou instruções que deveriam estar protegidos, quebrando a corretude em silêncio.
- Um limiar de relevância agressivo filtra contexto que importava para um caso limite, então a qualidade parece boa nos testes mas falha em produção.
Lições aprendidas
- A redução de tokens é trivial de maximizar e sem sentido por si só; a métrica real é se o modelo ainda responde corretamente.
- Proteja explicitamente identificadores, restrições e o objetivo atual para que nenhuma etapa de compressão possa expulsá-los.
- Comprima o histórico antigo, não o contexto ativo; as trocas mais recentes carregam o sinal mais relevante para as decisões.
- Ajuste a agressividade por carga de trabalho contra um conjunto de avaliação; o que é seguro para um bate-papo é imprudente para uma tarefa de auditoria.
FAQs
- Como isso difere da memória de longo prazo?
- A memória de longo prazo persiste fatos fora do prompt e os recupera sob demanda; a compressão de contexto encolhe o contexto ativo enviado em cada chamada. São complementares: a memória decide o que trazer de volta, a compressão decide com quão pouca extensão isso ocupa a janela.
- Resumir, podar ou comprimir — qual usar?
- Pode primeiro (gratuito, sem perda ao remover redundância real), resuma o histórico antigo quando ele cresce sem limite e adicione compressão de prompts apenas quando ainda precisar de mais folga e puder validar o custo de qualidade. A maioria dos sistemas combina as três.
- Como sei se a compressão está prejudicando a qualidade?
- Rode um conjunto de avaliação com compressão ligada e desligada e compare os resultados de tarefa, não apenas as contagens de tokens. Observe respostas erradas com confiança e restrições descartadas: essa é a assinatura de uma compressão com perda que foi longe demais.