Memória de agente com menos tokens: o que o ALTK-Evolve muda em relação ao ACE

Quando um agente LLM falha numa tarefa multi-etapa realista (dividir uma conta, encontrar uma música, reconciliar um pedido entre vários apps), raramente é por falta de conhecimento. Ele pagina uma API errado, resolve a pessoa errada ou devolve um valor que ninguém pediu. O modelo conhece as APIs; o que ele não internalizou é como usá-las de forma confiável. E isso, segundo o time de IBM Research, é aprendível a partir do próprio histórico do agente.

O artigo publicado no blog da Hugging Face compara dois sistemas que fazem exatamente isso, sem atualizar pesos e sem rótulos humanos: o ACE (Agentic Context Engineering) e o ALTK-Evolve, da própria IBM. Ambos são uma forma de memória de agente: transformam trajetórias passadas em lições reutilizáveis e as reinjetam no momento da inferência. A diferença, e o que decide a conta de tokens, está em como essa memória é entregue ao modelo.

No que os dois concordam: não comprima

Os dois sistemas se recusam a comprimir os aprendizados num resumo enxuto. O ACE nomeia bem os dois modos de falha que quer evitar: brevity bias (a otimização colapsando para instruções curtas e genéricas) e context collapse (o modelo, ao reescrever todo o contexto a cada passo, resumindo os detalhes até sumirem). A resposta do ACE é manter um playbook rico e itemizado, com um contador de "útil/prejudicial" em cada item, deixando o modelo destilar a relevância na hora da leitura.

O ALTK-Evolve chega à mesma conclusão por outro caminho: cada diretriz distinta guarda um support count, quantos episódios independentes a produziram. Uma lição descoberta por cinco tarefas diferentes é um objeto distinto de uma que apareceu uma vez, e as duas merecem ser mantidas. Como resume o texto, os contadores por item do ACE e os support counts são "duas grafias da mesma ideia": contar, não colapsar.

Onde eles divergem: entrega como um botão, não uma constante

A divergência aparece em dois pontos, mas é o segundo que move os números:

• Construção da memória: o ACE cresce um único playbook por um loop Generator → Reflector → Curator, com updates incrementais e deduplicação por embedding. O ALTK-Evolve agrupa lições quase duplicadas e as funde dentro de um cluster de forma support-conserving: o sobrevivente herda a contagem somada. Ele também extrai diretrizes tipadas (estratégia, recuperação, otimização) com atribuição causal e rastreabilidade até a trajetória de origem.
• Entrega ao modelo: aqui está a diferença que pesa. O ACE injeta o playbook completo a cada passo, igual para qualquer modelo ou tarefa. O ALTK-Evolve trata a entrega como um dial: um núcleo fixo de diretrizes de alto suporte, estendido por tarefa com um punhado selecionado (via cosseno ou seleção guiada por LLM), ou o conjunto completo quando o modelo tem folga para usá-lo.

Por que importa: os números no AppWorld

Rodando ambos os sistemas em casa, sobre o mesmo agente ReAct base, no benchmark AppWorld (168 tarefas), o time reportou:

• DeepSeek-V3.2: ACE em 80.4 / 73.2 (TGC/SGC) com 634K tokens/tarefa; ALTK-Evolve em 89.3 / 80.4 com 263K. Melhor nas duas métricas a cerca de 40% do custo de inferência.
• gpt-oss-120b: ACE em 54.8 / 35.7 com 777K tokens/tarefa; ALTK-Evolve em 56.0 / 37.5 com 116K. Empate técnico em acurácia (a repetição do próprio time bateu 54.8, dentro do ruído do benchmark) a cerca de um sétimo do custo.

O breakdown por dificuldade conta duas histórias. No gpt-oss-120b, o playbook completo do ACE lidera Easy e Medium, mas nas tarefas Hard, onde o modelo precisa escolher a lição certa em vez de vasculhar todas, a recuperação curada vira o jogo, e é essa faixa que decide o agregado. No DeepSeek-V3.2 a história inverte: o modelo mais forte absorve bem o playbook completo e leva o Medium, mas o ALTK-Evolve vence Easy, Hard e Overall.

O trade-off honesto

Vale ler a ressalva do próprio artigo. A eficiência do ACE é sobre construir o contexto de forma barata; a do ALTK-Evolve está em outro eixo, o de servir esse contexto. Recuperar poucas diretrizes por tarefa, em vez de injetar o playbook inteiro a cada passo, é onde os tokens vão embora.

Vale também notar a metodologia: os números do ACE são execuções da própria IBM, não os do paper original (que usa DeepSeek-V3.1 como base). Os dois sistemas diferem apenas no template de prompt, o que faz as baselines sem memória divergirem (72.0 vs 79.8 TGC), e o time diz não apoiar a comparação nesse gap, apenas nas afirmações que um ajuste de prompt não alcança.

A lição prática para quem constrói agentes: antes de encher o contexto com tudo que o agente aprendeu, pergunte quanto o modelo em uso realmente consegue aproveitar. Em modelos mais fracos, contexto grande atrapalha em vez de ajudar. Quem quiser testar pode olhar a biblioteca ALTK-Evolve, que inclui o pipeline de extração, consolidação e recuperação usado no artigo.

Fonte: Hugging Face Blog