Estruturar a memória por tipo reduz os tokens recuperados em cerca de 40%.

Por que um armazenamento de memória plano falha

A maioria dos tutoriais para iniciantes ensina um agente LLM a “lembrar” anexando cada nova informação a uma única lista e enviando essa lista de volta ao modelo a cada turno. O código tem literalmente três linhas e produz uma demonstração funcional. Na prática, a lista cresce sem controle. Dois sintomas aparecem:

  • O agente trata dados desatualizados como se ainda fossem verdadeiros, por exemplo, fornecendo um ETA que expirou horas atrás.
  • A janela de contexto se enche de informações irrelevantes que nunca influenciam a resposta, inflando os custos de API e retardando o tempo de resposta.

Um simples banco de dados vetorial ou um cache de chave-valor básico não consegue distinguir o cargo de um usuário de um status temporário de projeto. Quando o agente realiza uma busca semântica, o algoritmo de similaridade pode trazer à tona um ETA antigo simplesmente porque a consulta contém as mesmas palavras, mesmo que o dado não seja mais relevante.

Memória estruturada: quatro categorias, um propósito

A solução é parar de tratar a memória como um monólito e começar a classificar cada entrada em uma de quatro categorias:

  • Fatos do usuário – atributos estáveis, como o cargo de um usuário, idioma preferido ou nível de acesso de segurança. Eles raramente mudam e podem ser armazenados em cache durante toda a sessão.
  • Feedback – regras explícitas que o agente deve obedecer, por exemplo, “nunca revele senhas de banco de dados” ou “evite humor em consultas de conformidade”. Como elas regem o comportamento, devem pertencer ao system prompt em vez do pool de busca.
  • Estado do projeto – dados de rápida mudança, como ETAs atuais, progresso de tarefas ou tokens temporários. Esta categoria precisa de uma verificação de expiração; assim que um timestamp estiver fora de uma janela definida, a entrada deve ser removida.
  • Referências – ponteiros para serviços externos, IDs de documentos ou endpoints de API. Eles não são conteúdo para ser exibido, mas rotas para buscar dados atualizados quando necessário.

O Mem0 permite que os desenvolvedores anexem metadados arbitrários a cada registro de memória. Ao indexar pelo campo “kind”, uma consulta pode primeiro filtrar a categoria relevante antes que o LLM decida como usar o resultado.

Recuperação em duas etapas com Mem0

  1. Buscar memórias por tipo – Uma consulta de filtro curta solicita ao Mem0 “todo o feedback” ou “entradas de estado do projeto mais recentes que um intervalo curto”. O conjunto de resultados já vem filtrado para a categoria apropriada.
  2. Deixar o LLM decidir – Os trechos filtrados são inseridos no prompt junto com a pergunta atual do usuário. O modelo agora pode raciocinar sobre eles sem precisar filtrar fatos irrelevantes.

Uma ilustração concreta: em vez de esperar que uma correspondência semântica traga à tona a regra “não faça piadas com o banco de dados”, o desenvolvedor injeta essa regra diretamente no system prompt no início da sessão e a armazena em cache para toda a interação. Mesmo que a consulta do usuário não contenha nenhuma referência explícita a bancos de dados, o modelo já conhece a restrição.

Truques práticos para manter os custos baixos

  • Armazenar regras de feedback em cache – Armazene o conjunto de regras uma vez por sessão e reutilize-o em vez de pesquisar novamente a cada turno. Isso reduz o uso de tokens em cada rodada.
  • Pular buscas de estado do projeto quando irrelevantes – Se o usuário fizer uma pergunta puramente conceitual (“Qual é a diferença entre aprendizado supervisionado e por reforço?”), não há necessidade de buscar dados de ETA ou progresso de tarefas.

Ao aplicar esses dois hábitos, o uso de tokens pode ser reduzido em cerca de 40% em comparação com uma abordagem de memória plana ingênua. A economia se traduz diretamente em faturas de API mais baixas e um tempo de resposta mais rápido, especialmente para agentes que permanecem ativos por muitas trocas de mensagens.

Quem ganha, quem se preocupa

Vencedores – Equipes que constroem bots de suporte ao cliente, assistentes de fluxo de trabalho interno ou qualquer interface de LLM de múltiplos turnos. Eles obtêm respostas mais confiáveis, evitam erros embaraçosos causados por dados desatualizados e fazem seu orçamento render mais.

Resumo

Se você quer um agente LLM que se mantenha afiado em sessões longas, pare de entupir cada fato em uma única janela de contexto. Marque cada memória como fato do usuário, feedback, estado do projeto ou referência, aplique expirações onde necessário e deixe uma ferramenta como o Mem0 fazer o trabalho pesado. O resultado são respostas mais atualizadas, menos tokens desnecessários e um corte perceptível nos custos operacionais.