Quanto mais trabalho com LLMs, mais me encontro na batalha eterna entre contexto suficiente, contexto excessivo, desperdício de tokens e guerra de compactação. Ao observar sistemas de memória agêntica, vejo que existem armas poderosas para ajudar nisso.
A descoberta que continua surgindo nos 19 sistemas que analisei é que janelas maiores intensificam o problema de orçamento, em vez de resolvê-lo. Uma janela de 200 mil tokens não dá atenção igual a todos os 200 mil tokens. O desempenho degrada muito antes de a janela encher. A degradação não é uniforme: o material no meio de um contexto longo recebe consistentemente menos atenção do que o material nas bordas. E a tarefa real do agente ocupa uma fatia fixa da janela, independentemente do tamanho dela, o que significa que todo o resto é custo competindo pelo mesmo orçamento de atenção.
Os sistemas que lidam bem com isso convergiram para seis mecanismos. Nenhum deles é exótico. Vários são vergonhosamente simples. Mas os que os ignoram pagam o preço.
Os seis mecanismos
Passagens de compactação
O mecanismo mais visível. Você pega uma conversa longa ou um segmento de memória grande, resume e substitui o original pelo resumo. O MemoryOS faz isso no nível do segmento: seu sumarizador de segmentos é acionado quando um segmento de conversa ultrapassa um limite, colapsando-o em uma representação compacta antes que ele possa ocupar o contexto de trabalho. As wikis do padrão Karpathy (purpose.md, overview.md) fazem uma versão disso no nível do conhecimento: a wiki é a forma compactada de tudo que o agente aprendeu sobre um tópico, mantida entre sessões.
A compensação é a perda de informação. A compactação é uma operação com perda por definição. O resumo captura o que o sumarizador julgou relevante no momento da compactação. Se o agente precisar depois de um detalhe que não foi julgado relevante, ele desaparece. Isso não é motivo para evitar a compactação, mas é motivo para não tratá-la como o único mecanismo.
Há um segundo custo fácil de ignorar. A compactação não é gratuita em tempo de execução. O MemoryOS pode pagar 20 ou mais chamadas de LLM em uma única interação para manter seus resumos de segmento. Para sistemas com alta frequência de interação, isso é um custo operacional real.
Truncamento de pré-visualização de resultados
Em vez de retornar o conteúdo completo da memória em cada recuperação, retorne uma pré-visualização curta e deixe o agente decidir se busca o registro completo. O supermemory expõe controles de tamanho de trecho que permitem aos chamadores ajustar quanto texto retorna por resultado. O mem9 vai além: decora as falas de origem com três variáveis de ambiente (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) que dão aos operadores controle preciso sobre quantas falas de origem aparecem e com qual pontuação mínima de relevância.
A compensação é uma chamada de ferramenta extra. Se o agente precisar do conteúdo completo, ele tem que pedir explicitamente. Para a maioria dos padrões de recuperação, essa é a compensação correta: o agente recebe sinal suficiente para decidir se o registro é relevante antes de pagar o custo de tokens para lê-lo por inteiro.
Recuperação em duas etapas
Uma variante específica e importante do truncamento de pré-visualização. A busca retorna identificadores e pré-visualizações curtas. Uma chamada separada de GetByID busca o registro completo quando necessário. A interface MemoryRepo do mem9 é construída em torno desse padrão: busca e recuperação são operações distintas, com pegadas de token distintas.
Os números deixam o caso claro. Dez correspondências com 1.500 tokens cada são 15.000 tokens injetados no contexto, quer o agente as use ou não. A recuperação em duas etapas retorna 10 identificadores e pré-visualizações curtas com aproximadamente 450 tokens no total e, em seguida, busca apenas os registros que o agente realmente precisa. Em 20 etapas de recuperação em uma sessão, essa diferença se acumula para cerca de 200.000 tokens economizados.
Essa é a disciplina mais barata que você pode adotar. Não requer nenhuma mudança arquitetural no armazenamento de memória, nenhuma chamada adicional de LLM e nenhuma perda de informação. É uma decisão de interface de recuperação.
Decompor-depois-recuperar
Em vez de enviar a consulta completa do usuário para a camada de recuperação, decomponha-a em subconsultas primeiro. O planejador de recuperação consciente de intenção do SimpleMem divide consultas recebidas em intenções de recuperação atômicas antes de acessar o armazenamento de memória. O GitNexus faz algo semelhante com sua decomposição de ferramenta de consulta: consultas complexas são divididas em subconsultas direcionadas, cada uma recuperando uma fatia focada do grafo de memória.
O benefício é a precisão. Uma consulta decomposta recupera menos material irrelevante, o que significa menos ruído no contexto. A compensação é a latência: a decomposição adiciona uma etapa de planejamento antes da recuperação começar. Para agentes interativos, isso importa. Para agentes em lote ou em segundo plano, geralmente não.
Armazenamento em camadas como filtro de orçamento
Se você já construiu uma arquitetura de memória em camadas (o assunto do artigo da semana passada), obtém a filtragem de orçamento como efeito colateral. O modelo de três camadas do supermemory significa que o material ativo e frequentemente acessado vive em uma camada que retorna resultados compactos e de alto sinal. O material frio está em uma camada que não é consultada por padrão. A camada de observação do Hindsight funciona da mesma forma: observações brutas não são injetadas diretamente no contexto; elas são promovidas para camadas superiores antes de se tornarem candidatas à recuperação.
A compensação é a completude da recuperação. Material que não foi promovido pode ser relevante, mas não aparecerá em uma passagem de recuperação padrão. Esta é a mesma compensação da compactação, mas o modo de falha é diferente: em vez de perder informações por meio da sumarização, você as perde por meio do rebaixamento.
Respostas de ferramentas autoguiadas
O mecanismo menos discutido e um dos mais interessantes. Em vez de deixar o agente decidir o que fazer após uma chamada de ferramenta, a própria resposta da ferramenta inclui uma dica sobre o que fazer em seguida. O GitNexus anexa um bloco ---
**Próximo:** às respostas das ferramentas, sugerindo ações de acompanhamento. O mem9 decora as falas de origem com metadados estruturados que guiam a próxima etapa de recuperação do agente.
O efeito é que o agente gasta menos tokens planejando entre chamadas de ferramenta. A resposta da ferramenta carrega estrutura suficiente para tornar o próximo passo óbvio. A compensação é o esforço de engenharia de prompt: escrever boas respostas autoguiadas requer saber de antemão o que o agente provavelmente precisará em seguida, o que nem sempre é possível.
O caso limite do Tolaria
Vale a pena analisar o Tolaria separadamente porque ele representa o ponto final lógico da disciplina de orçamento levada ao extremo. O ADR-0009 documenta a decisão de remover completamente as incorporações do sistema. O Tolaria usa busca apenas por substring. Nenhum índice vetorial, nenhuma recuperação semântica, nenhuma chamada de incorporação.
O raciocínio é direto: o token mais barato é aquele que você nunca recupera em primeiro lugar. A recuperação baseada em incorporação retorna resultados semanticamente semelhantes, o que significa que retorna resultados que o agente não pediu explicitamente. Alguns desses resultados são úteis. Muitos não são. Todos custam tokens.
A posição do Tolaria é que o custo de resultados irrelevantes, mas semelhantes, acumulado ao longo de uma sessão, supera o benefício da recuperação semântica para seu caso de uso. Se essa compensação é válida para o seu sistema depende do propósito dele. Para sistemas onde as consultas são precisas e estruturadas (navegação de código, consulta de documentos por identificador), a posição do Tolaria é defensável. Para sistemas onde as consultas são vagas e exploratórias, remover as incorporações quebra a recuperação de maneiras difíceis de reverter.
O valor do caso Tolaria não é que você deva copiá-lo. É que ele torna o custo da recuperação semântica visível de uma forma que a maioria dos sistemas não faz.
O caso contra sistemas apenas de compactação
Vários dos 19 sistemas dependem da compactação como seu mecanismo principal ou único de orçamento. Vale a pena nomear os modos de falha.
O primeiro é que a sumarização perde detalhes que não foram julgados relevantes no momento da compactação, mas se tornam relevantes depois. Isso não é hipotético: é o modo de falha padrão de qualquer esquema de compressão com perda aplicado a informações cuja relevância futura é desconhecida.
O segundo é que a compactação é um custo no caminho crítico. O MemoryOS pagar 20 ou mais chamadas de LLM por interação não é incomum para sistemas pesados em compactação. Em escala, esse custo não é desprezível.
O terceiro, e mais sutil, é que a compactação sem uma saída de emergência é um esquecimento lento. Se a única maneira de reduzir o tamanho do contexto é sumarizar, e as sumarizações são com perda, então o sistema está continuamente descartando informações sem maneira de recuperá-las. A recuperação em duas etapas, o armazenamento em camadas e o truncamento de pré-visualização de resultados preservam o registro original. A compactação não.
Nada disso significa que a compactação está errada. Significa que apenas a compactação não é suficiente.
Ponderação por recência e a fila persistente
Dois mecanismos que não se encaixam perfeitamente nas seis categorias acima merecem destaque.
O graymatter usa fusão RRF com recência com metade do peso. Isso não é um mecanismo de orçamento no sentido estrito, mas funciona como um: ao reduzir o peso de material mais antigo nas classificações de recuperação, diminui a probabilidade de que registros obsoletos e de baixo sinal ocupem o espaço de registros recentes e de alto sinal. O efeito é uma estratificação suave através de pesos de classificação, em vez de promoção explícita de camadas.
A máquina de estado da fila de ingestão de 540 linhas do llm-wiki adota uma abordagem diferente. A fila serializa operações de ingestão e aplica um classificador de relevância de quatro sinais antes que qualquer coisa entre no armazenamento de memória. O controle de orçamento acontece no momento da escrita, não no momento da leitura. Material que não ultrapassa o limite de relevância não é armazenado, o que significa que não pode ser recuperado e não pode consumir contexto. Isso é controle de orçamento indireto, mas é durável: as economias se acumulam em todas as sessões futuras.
O que os sistemas bem projetados têm em comum
Observando os 19 sistemas, aqueles que lidam bem com orçamentos de contexto compartilham algumas propriedades.
Eles tratam a recuperação como uma operação de duas etapas, em vez de uma injeção de uma etapa. Eles retornam pré-visualizações antes dos registros completos. Eles preservam registros originais em vez de substituí-los por resumos. Eles dão aos operadores controle sobre o volume de recuperação por meio de parâmetros explícitos, em vez de padrões codificados. E pensam no orçamento tanto no momento da escrita quanto no momento da leitura.
Os que lidam mal tendem a depender de um único mecanismo, geralmente a compactação, e tratam a janela de contexto como um buffer a ser preenchido, em vez de um recurso a ser gerenciado.
A posição final da pesquisa é simples. Janelas maiores exigem mais disciplina, não menos. Não porque preenchê-las seja errado em princípio, mas porque preenchê-las com o material errado custa mais do que deixar o espaço vazio.
Para meu próximo artigo, planejo mudar de memória-como-injeção para memória-como-ferramentas, abordando como os 19 sistemas lidam com o limite entre o que é empurrado automaticamente para o contexto e o que o agente precisa pedir explicitamente.*
Como sempre, se você achou isso interessante, útil ou apenas quer ajudar a espalhar o conhecimento:
Por favor, Compartilhe
