O texto completo está traduzido abaixo, seguindo rigorosamente todas as regras e o glossário fornecidos.
Quanto mais tempo trabalho com LLMs, mais me encontro na eterna batalha entre contexto suficiente, contexto demais, desperdício de tokens e guerra de compactação. Olhando para sistemas de memória agentiva, podemos ver que existem algumas 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.000 tokens não dá atenção igual a todos os 200.000 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 indireto 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 aqueles 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 segmento é acionado quando um segmento de conversa ultrapassa um limite, colapsando-o em uma representação compacta antes que ele possa sufocar 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 desvantagem é a perda de informação. A compactação é uma operação com perdas por definição. O resumo captura o que o sumarizador julgou relevante no momento da compactação. Se o agente precisar posteriormente de um detalhe que não foi julgado relevante, ele se foi. Isso não é motivo para evitar a compactação, mas é motivo para não tratá-la como o único mecanismo.
Há um segundo custo que é fácil de perder. 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évia do resultado
Em vez de retornar o conteúdo completo da memória a cada recuperação, retorne uma prévia curta e deixe o agente decidir se deseja buscar o registro completo. O supermemory expõe controles de tamanho de trecho que permitem que os chamadores ajustem quanto texto retorna por resultado. O mem9 vai além: ele decora turnos de fonte 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 quantos turnos de fonte aparecem e com qual pontuação mínima de relevância.
A desvantagem é 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 troca certa: o agente recebe sinal suficiente para decidir se o registro é relevante antes de pagar o custo de token de lê-lo por completo.
Recuperação em duas etapas
Uma variante específica e importante do truncamento de prévia. A pesquisa retorna identificadores e prévias 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: pesquisa e busca são operações distintas com pegadas de token distintas.
Os números comprovam o caso claramente. Dez correspondências a 1.500 tokens cada são 15.000 tokens injetados no contexto, quer o agente os use ou não. A recuperação em duas etapas retorna 10 identificadores e prévias curtas com aproximadamente 450 tokens no total e, em seguida, busca apenas os registros que o agente realmente precisa. Em 20 etapas de recall em uma sessão, essa diferença se acumula para cerca de 200.000 tokens economizados.
Esta é a disciplina mais barata que você pode adotar. Não requer nenhuma mudança arquitetônica 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 e depois recuperar
Em vez de enviar a consulta completa do usuário para a camada de recuperação, decomponha-a primeiro em subconsultas. O planejador de recuperação consciente de intenção do SimpleMem divide as 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 desvantagem é a latência: a decomposição adiciona uma etapa de planejamento antes do início da recuperação. Para agentes interativos, isso importa. Para agentes em lote ou de 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), você obtém a filtragem de orçamento como um 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 desvantagem é a completude do recall. O material que não foi promovido pode ser relevante, mas não será exibido em uma passagem de recuperação padrão. Essa é a mesma desvantagem 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 a seguir. O GitNexus anexa um bloco ---
**Próximo:** às respostas da ferramenta, sugerindo ações de acompanhamento. O mem9 decora turnos de fonte com metadados estruturados que guiam o próximo passo de recuperação do agente.
O efeito é que o agente gasta menos tokens em planejamento entre chamadas de ferramenta. A resposta da ferramenta carrega estrutura suficiente para tornar o próximo passo óbvio. A desvantagem é o esforço de engenharia de prompt: escrever boas respostas autoguiadas requer saber antecipadamente 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 orçamentária levada ao extremo. O ADR-0009 documenta a decisão de remover completamente os embeddings do sistema. O Tolaria usa apenas pesquisa por substring. Sem índice vetorial, sem recuperação semântica, sem chamadas de embedding.
O raciocínio é direto: o token mais barato é aquele que você nunca recupera em primeiro lugar. A recuperação baseada em embedding 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 eles custam tokens.
A posição do Tolaria é que o custo de resultados irrelevantes, mas semelhantes, acumulado ao longo de uma sessão, excede o benefício do recall semântico para seu caso de uso. Se essa troca é válida para o seu sistema depende para que serve o seu sistema. Para sistemas onde as consultas são precisas e estruturadas (navegação de código, busca de documentos por identificador), a posição do Tolaria é defensável. Para sistemas onde as consultas são vagas e exploratórias, remover os embeddings quebra o recall de maneiras difíceis de recuperar.
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 de orçamento principal ou único. 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 mais tarde. Isso não é hipotético: é o modo de falha padrão de qualquer esquema de compressão com perdas aplicado a informações cuja relevância futura é desconhecida.
O segundo é que a compactação é um custo no caminho crítico. O MemoryOS pagando 20 ou mais chamadas de LLM por interação não é incomum para sistemas com uso intenso de 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 é resumir, e os resumos são com perdas, 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évia do resultado 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 sufoquem aqueles recentes e de alto sinal. O efeito é uma camada suave por meio de pesos de classificação, em vez de promoção explícita de camada.
A máquina de estado da fila de ingestão de 540 linhas do llm-wiki adota uma abordagem diferente. A fila serializa as operações de ingestão e aplica um classificador de relevância de quatro sinais antes que algo entre no armazenamento de memória. O controle de orçamento acontece no momento da escrita, em vez do momento da leitura. O 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. Este é um controle de orçamento indireto, mas é durável: as economias se acumulam em cada sessão futura.
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évias antes dos registros completos. Eles preservam os 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 eles pensam sobre o orçamento tanto no momento da escrita quanto no momento da leitura.
Aqueles que lidam mal com isso 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, pretendo mudar de memória como injeção para memória como ferramentas, cobrindo como os 19 sistemas lidam com o limite entre o que é empurrado para o contexto automaticamente e o que o agente tem que pedir explicitamente.*
Como sempre, se você achou isso interessante, útil ou apenas quer ajudar a espalhar o conhecimento:
Por favor, Compartilhe
