Contexto longo não é grátis: engenheiro constrói camada de poda de prompts que reduz até 34% dos tokens

Em sistemas de IA que mantêm conversas longas, um problema silencioso corrói desempenho e custo: o acúmulo infinito de contexto. A cada turno, o prompt enviado ao modelo inclui todo o histórico da conversa, saídas antigas de ferramentas, resultados repetidos de RAG (geração aumentada por recuperação) e preferências do usuário mencionadas uma única vez — tudo empilhado indefinidamente.

Emmimal P Alexander, engenheiro e autor no Towards Data Science, enfrentou esse problema de frente e construiu uma camada determinística de poda de prompts que reduz o uso de tokens sem quebrar dependências entre mensagens. O projeto é open source, tem 35 testes automatizados e foi validado em 15 configurações diferentes de carga de trabalho.

O problema: prompts que só crescem

“No quinquagésimo turno de conversa, o payload que você está enviando inclui o prompt do sistema, o histórico completo do chat, quatro saídas de ferramentas (duas completamente obsoletas porque a ferramenta rodou duas vezes), seis trechos recuperados (três quase duplicados porque o usuário voltou a um tópico antigo), um resultado SQL de vinte turnos atrás e uma preferência do usuário mencionada uma única vez”, explica Alexander.

O problema não é que esses dados estejam errados — cada um fez sentido no momento em que foi injetado. O problema é que nada nunca é removido. O prompt se transforma em um log somente de acréscimo, e você está despejando tudo no modelo a cada turno, indefinidamente.

E não é só uma questão de custo. Estudos acadêmicos mostram que o desempenho de raciocínio dos LLMs se degrada conforme o comprimento do input cresce, mesmo quando o conteúdo adicional é irrelevante para a tarefa. Modelos também são piores em usar informações enterradas no meio de um contexto longo do que informações próximas às bordas — fenômeno conhecido como “lost in the middle”.

Por que truncamento simples não funciona

A reação instintiva é truncar: cortar as últimas N mensagens e descartar o resto. Uma linha de código resolve. Mas isso quebra silenciosamente as cadeias de conversa de formas que você só descobre quando explode com um usuário real.

Imagine: no turno 3, o usuário diz “prefiro CSV como formato de saída”. No turno 47, pede “exporte os resultados”. Se sua janela está limitada aos últimos 20 turnos, o turno 3 desaparece e o assistente perde a informação de que o CSV era obrigatório. Aquele dado não estava obsoleto — era uma dependência rígida. O truncamento posicional simples não consegue diferenciar contexto antigo descartável de contexto antigo que um turno posterior ainda precisa.

A solução: três passagens determinísticas

Alexander emprestou uma ideia dos sistemas operacionais: assim como um SO decide quais páginas permanecem na RAM e quais são removidas, sua camada de poda faz a mesma coisa para o prompt. O pipeline executa três passagens distintas:

Passagem 1 — Eliminação de Contexto Expirado: remove informações que têm prazo de validade explícito. Por exemplo, se um resultado de ferramenta é marcado como válido por apenas 3 turnos e já estamos no turno 15, ele é removido.

Passagem 2 — Eliminação de Contexto Duplicado: identifica e remove trechos redundantes. Se o sistema de RAG recuperou as mesmas informações duas vezes com pequenas variações, apenas uma cópia sobrevive.

Passagem 3 — Restauração de Dependências: esta é a passagem que torna as duas primeiras seguras na prática. Ela garante que nada de que uma mensagem posterior dependa seja removido acidentalmente. Por exemplo, se a preferência por CSV do turno 3 foi marcada para remoção como “contexto expirado”, mas o turno 47 explicitamente a referencia, a passagem 3 a restaura.

Uma propriedade importante do sistema é que ele atinge um ponto fixo estável após uma única passagem: podar um prompt já podado não produz mais alterações.

Resultados dos benchmarks

O sistema foi testado em três cargas de trabalho — chat simples, assistente RAG e agente com ferramentas pesadas — cada uma em cinco tamanhos de conversa, totalizando 15 configurações em duas máquinas diferentes.

A redução de tokens depende da carga de trabalho:

• Chat simples: 2% a 4% de redução — esperado, já que há pouco a podar em conversas lineares
• Assistente RAG: 27% a 32% de redução — ganho expressivo com eliminação de duplicatas de recuperação
• Agente com ferramentas: 33% a 34% de redução — maior economia, com remoção de saídas obsoletas de ferramentas

Crucialmente, mesmo com 2.000 turnos e 131.000 tokens, o pré-processamento ficou abaixo de 50 milissegundos. Em todos os testes, todos os fatos rotulados como obrigatórios foram preservados.

Duas armadilhas que mudaram o design

Durante o desenvolvimento, Alexander encontrou dois bugs que forçaram mudanças no design.

O primeiro corpus de benchmark usava um número fixo de duplicatas e chamadas de ferramenta obsoletas, o que fazia as porcentagens de redução encolherem artificialmente conforme as conversas cresciam — comportamento que não reflete o mundo real.

A lógica de restauração de dependências também passou completamente não testada no início, porque os dados sintéticos nunca criavam um caso em que uma mensagem obrigatória fosse realmente removida. Ambos os problemas foram corrigidos, e as correções alteraram significativamente os resultados.

Para onde isso vai

Alexander aponta três direções para extensão do sistema. A primeira é adicionar uma quarta passagem opcional usando um modelo pequeno para compressão semântica, operando sobre a saída já segura do pipeline determinístico — se o modelo falhar, o sistema simplesmente volta ao baseline determinístico.

A segunda é migrar de dados sintéticos para traces de produção reais, mantendo a mesma metodologia de benchmark para garantir comparabilidade. A terceira é substituir as marcações manuais REF/DEFINE por derivação automática a partir de dados estruturados, argumentos de chamadas de ferramenta ou configurações explícitas do usuário.

Alexander observa que sistemas de produção já tratam o inchaço de prompts como um problema de gerenciamento de memória na camada de infraestrutura, com técnicas como PagedAttention. “Você pode pensar neste projeto como operando uma camada acima disso, na fase de construção do prompt, antes que a requisição chegue à infraestrutura. As duas camadas não competem — um prompt menor e deduplicado fornece uma entrada melhor para um cache bem gerenciado.”

O código completo está disponível no GitHub, incluindo o pipeline de poda, o gerador de corpus sintético, o harness de benchmark e todos os 35 testes. O sistema não depende de chamadas a LLMs, embeddings ou bibliotecas externas — apenas a biblioteca padrão do Python.