Compressão de contexto é a redução do texto enviado a um modelo de linguagem, preservando as informações necessárias para a tarefa. Pruning significa selecionar e remover partes menos úteis, como mensagens repetidas, documentos irrelevantes ou saídas antigas de ferramentas. O objetivo prático é usar um orçamento menor de tokens sem perder decisões, restrições e evidências.
Isso não reduz automaticamente o número de chamadas à API. Um resumo gerado por outro modelo pode acrescentar uma chamada. A economia aparece quando o processamento total de uma tarefa cai, quando se evitam consultas redundantes ou quando a aplicação deixa de fragmentar trabalho que caberia em uma única requisição. Meça o fluxo completo antes de escolher a técnica.
Resumo rápido
- Comece removendo repetição e retornos excessivos de ferramentas.
- Proteja instruções, identificadores, números, negações e pendências.
- Conte tokens com o tokenizador adequado ao modelo de destino.
- Inclua o custo do compressor e das tentativas de recuperação.
- Compare qualidade, latência e chamadas por tarefa concluída.
O que muda entre poda, resumo e recuperação
Uma aplicação costuma acumular mensagens, registros de banco, resultados de busca e instruções. Nem todos esses elementos precisam estar presentes em todas as etapas. A primeira decisão é identificar o papel de cada bloco. Uma restrição de autorização vale durante toda a operação; a lista completa de produtos consultada anteriormente talvez já não ajude a responder sobre um único pedido.
Na poda por regras, o sistema remove blocos selecionados segundo critérios explícitos. No resumo, uma representação mais curta substitui conteúdo extenso. Na recuperação, o material fica armazenado fora do prompt e apenas trechos relevantes são carregados quando necessários. São mecanismos complementares, mas têm riscos diferentes e precisam de avaliações separadas.
| Técnica | Aplicação inicial | Risco a observar |
|---|---|---|
| Poda por regras | Remover cabeçalhos e resultados duplicados | Descartar uma exceção junto com o bloco |
| Resumo estruturado | Condensar conversa longa | Transformar hipótese em fato |
| Seleção de trechos | Enviar somente evidências relevantes | Perder contexto entre documentos |
| Compressão por modelo | Selecionar conteúdo dentro do texto | Adicionar custo e alterar relações |
| Referências externas | Guardar documentos fora do histórico | Exigir consultas adicionais |
A discussão da Anthropic sobre engenharia de contexto apresenta compactação e notas estruturadas como estratégias para tarefas longas. A recomendação operacional deste guia é preservar também a origem das informações: qualquer versão resumida deve permitir localizar o registro completo que a gerou.
Para a base conceitual, consulte o guia de janela de contexto. Aqui, o foco é a implementação de um processo de redução com critérios verificáveis, e não a escolha de uma janela maior.
Como definir um orçamento que respeite a tarefa
Separe o orçamento de entrada em instruções fixas, estado atual, evidências recuperadas e histórico recente. Reserve espaço para a saída esperada e para a estrutura de mensagens exigida pela integração. Não trate o limite informado pelo provedor como uma meta de consumo. A aplicação deve funcionar com o menor conjunto que mantenha sua qualidade medida.
Conte o texto depois de montar o prompt final. Caracteres, palavras e tokens não são equivalentes. A documentação de tokenizadores do Transformers descreve a conversão de texto em identificadores e o tratamento de tokens especiais. A contagem precisa usar a configuração compatível com o modelo; um estimador genérico serve apenas como aproximação inicial.
Crie três classes de conteúdo. O conteúdo protegido inclui regras de segurança, objetivo vigente e fatos que determinam a resposta. O conteúdo condensável inclui explicações anteriores e atividades concluídas. O conteúdo descartável inclui duplicatas exatas, registros de depuração e resultados substituídos por versões mais recentes. Faça essa classificação antes de escolher uma biblioteca.
Também registre dependências. Uma resposta de ferramenta pode ser referenciada por uma mensagem posterior. Se ela for removida, substitua a referência por um estado válido e compatível com o protocolo utilizado. Não deixe identificadores órfãos nem apague apenas metade de um par de chamada e retorno. Integridade de formato e integridade semântica são verificações diferentes.
Uma sequência prática para implementar a compressão
Comece por transformações determinísticas: normalize espaços redundantes, elimine linhas repetidas e selecione campos necessários nos resultados das ferramentas. Uma consulta de pedido não precisa devolver o catálogo inteiro. Essa mudança ocorre antes do modelo e facilita explicar por que uma informação entrou ou saiu do prompt.
Depois, filtre documentos por relevância e diversidade. Dois trechos muito parecidos podem ocupar espaço sem acrescentar informação, enquanto uma cláusula curta contém a exceção que resolve a pergunta. Preserve metadados como fonte, seção, data de atualização e escopo. O filtro deve considerar a pergunta atual, sem modificar o acervo original.
Na etapa seguinte, use um estado estruturado para a conversa. Campos úteis são objetivo, decisões confirmadas, pendências, restrições, referências e ações já executadas. Exija que incertezas permaneçam incertezas. Se o cliente disse que talvez queira cancelar, o resumo não deve registrar um cancelamento solicitado. Esse tipo de alteração muda o comportamento operacional mesmo quando o resumo parece fluente.
Somente depois avalie seleção por modelo. O projeto LLMLingua, da Microsoft, disponibiliza ferramentas de compressão de prompts. O artigo original do LLMLingua descreve sua abordagem de pesquisa. Resultados experimentais dessas fontes não devem virar uma promessa de economia para textos brasileiros ou fluxos de produção sem testes locais.
Uma arquitetura inicial pode seguir a sequência: validar entrada, selecionar campos, recuperar evidências, construir estado, contar tokens e executar. Se ultrapassar o orçamento, aplique a próxima transformação permitida e conte novamente. Se ainda não couber, retorne uma necessidade de esclarecimento ou divida a tarefa explicitamente. Nunca corte o final silenciosamente.
Como medir economia sem esconder novas chamadas
Compare o custo por tarefa concluída corretamente. Inclua entrada e saída do modelo principal, processamento do compressor, armazenamento associado e novas tentativas. Quando houver um componente local, considere tempo de execução e infraestrutura. Uma chamada remota a menos pode exigir trabalho local que precisa entrar na conta.
Use uma linha de base sem compressão e registre, para cada caso, tokens enviados, tokens recebidos, chamadas totais, duração e resultado da avaliação. Depois execute as mesmas entradas com a política proposta. Mantenha versões do prompt, do modelo e das regras para que uma melhoria de configuração não seja confundida com melhoria da compressão.
Uma conta ilustrativa ajuda: suponha que uma tarefa use três chamadas de consulta. Reduzir o tamanho de cada entrada mantém três chamadas. Acrescentar um resumo intermediário pode elevar esse número para quatro. Só haverá menos requisições se o novo desenho eliminar uma etapa ou evitar uma repetição. Esses números descrevem arquiteturas hipotéticas, não resultados de benchmark.
Defina o que significa erro grave. Trocar um nome de produto pode ser reparável; alterar uma autorização ou um valor aprovado pode invalidar todo o fluxo. Avalie separadamente preservação de fatos, cumprimento de instruções e necessidade de reabrir documentos. O artigo sobre observabilidade de chamadas de modelos ajuda a organizar os registros dessa comparação.
Para entender o uso das estratégias no ecossistema citado, consulte também a página de integrações do Claude. Recursos específicos da plataforma precisam ser confirmados na documentação da integração antes de entrarem no desenho técnico.
Exemplo: atendimento de uma distribuidora em Campinas
Considere uma distribuidora de materiais elétricos em Campinas, em um cenário ilustrativo. Seu assistente acompanha pedidos de instaladores. O histórico inclui pesquisas no catálogo, mensagens sobre substituição de peças e retornos do sistema comercial. O problema é que cada resposta reenvia toda a conversa, inclusive consultas que já não são relevantes.
A equipe define um estado com pedido atual, itens confirmados, alternativas recusadas, restrição de entrega e pendências. As alternativas recusadas são protegidas porque impedem sugestões repetidas. O catálogo completo permanece fora do histórico. Uma consulta retorna apenas os itens relacionados ao pedido e a origem de cada disponibilidade.
Antes da próxima resposta, o sistema remove resultados duplicados e resume etapas concluídas. Mantém literalmente o código dos produtos e as restrições de entrega. Quando há conflito entre mensagens, registra o conflito para confirmação. O resumo não pode escolher sozinho qual endereço vale nem concluir que uma substituição foi autorizada.
O piloto compara atendimentos históricos revisados por pessoas, incluindo mudança de endereço, item indisponível e pedido retomado depois de interrupção. A decisão de avançar depende da preservação desses fatos e da redução do custo total observado. Sem essa avaliação, a equipe tem apenas um prompt menor, não uma melhoria comprovada.
Erros comuns
Usar uma porcentagem fixa de corte. O tamanho aceitável depende da informação necessária. Um texto curto pode conter muitas restrições, enquanto um log extenso pode ser quase todo repetição. A regra deve proteger conteúdo crítico antes de perseguir uma taxa de redução.
Resumir resumos indefinidamente. Cada transformação pode perder detalhes. Mantenha checkpoints vinculados às fontes e reconstrua o estado a partir do material original quando surgirem inconsistências. Não dependa de uma cadeia de paráfrases para comprovar o que foi solicitado.
Confundir compressão com cache. Cache reutiliza trabalho ou conteúdo conforme o mecanismo adotado; compressão altera a representação enviada. Ambos podem coexistir, mas suas métricas precisam ficar separadas. Um cache eficiente não prova que a poda preserva qualidade.
Avaliar apenas conversas fáceis. Inclua correções, negações, siglas, referências cruzadas e mensagens ambíguas em português. Inclua também tentativas de inserir instruções no conteúdo recuperado. Um documento continua sendo dado de entrada depois de resumido; não ganha autoridade sobre as instruções do sistema.
Perguntas frequentes
Compressão sempre reduz a quantidade de chamadas?
Não. Ela reduz o conteúdo processado quando funciona conforme planejado. A quantidade de chamadas depende da arquitetura. Conte consultas, resumos, recuperações e repetições para verificar se o fluxo realmente ficou mais curto.
Posso apagar todas as mensagens antigas?
Apenas quando o estado necessário estiver preservado e a tarefa permitir. Decisões antigas podem continuar válidas. Antes de apagar, defina quais fatos precisam acompanhar a sessão e como recuperar evidências completas quando houver dúvida.
Preciso de outro modelo para começar?
Não. Seleção de campos, eliminação de duplicatas e filtros por metadados são bons primeiros passos. Um compressor baseado em modelo deve entrar quando trouxer benefício adicional medido em relação a essas alternativas mais simples.
Como escolher o limite de tokens?
Use o limite técnico como restrição e os testes como critério de qualidade. Reserve espaço para saída e mensagens de controle. Ajuste o orçamento por tipo de tarefa, em vez de aplicar um único valor a todos os fluxos.
Quando interromper o piloto?
Quando a redução eliminar fatos protegidos, elevar chamadas de recuperação ou produzir respostas incompatíveis com as fontes. Corrija a política, repita os casos afetados e só amplie o uso depois de observar estabilidade na avaliação.
