Em Fevereiro deste ano, estava a construir um agente de IA para o blog — um assistente que lesse os artigos técnicos e respondesse a perguntas sobre eles. Na primeira sessão, funcionava lindamente. No dia seguinte, já não se lembrava de nenhum artigo. No terceiro dia, repeti a configuração toda do zero.
Se já usaste ChatGPT, Claude ou qualquer LLM, conheces o problema. Conversas longas degradam-se. O modelo começa a perder contexto. No limite, tens de recomeçar do zero. Para um chat ocasional, é tolerável. Para um agente que toma decisões, executa tarefas em background ou interage com bases de conhecimento, é um falhanço garantido.
Nos últimos meses, surgiram frameworks dedicadas a resolver isto — Zep, Mem0, ContextNest, entre outras. Para mim, a diferença está em perceber que não há uma solução única. São três problemas diferentes, e cada um precisa da sua abordagem.
Vale a pena perceber a diferença entre cada camada e porque é que tentar resolver tudo com uma única base de dados vetorial é a receita para o desastre.
O Problema de Base: Contexto Finito
Os LLMs têm uma janela de contexto, tipicamente entre 4 mil e 200 mil tokens, dependendo do modelo. Quando a conversa excede esse limite, o modelo começa a “esquecer” o que foi dito antes. Isto acontece mesmo com modelos mais recentes que usam janelas grandes: a atenção do modelo dilui-se, e a recuperação de informação precisa torna-se ruidosa.
Há três problemas concretos que a memória persistente resolve:
- Continuidade de sessão: um agente que interage contigo ao longo de dias ou semanas precisa de reter preferências, decisões anteriores e estado de tarefas.
- Personalização: saber quem és, o que já fizeste, quais as tuas escolhas recorrentes. Sem memória, cada interação é um primeiro encontro.
- Conhecimento corporativo atualizado: preços, versões de API, políticas internas mudam. O modelo treinado há seis meses não sabe disto.
Cada um destes problemas exige uma abordagem diferente. Tentar resolver tudo com uma única base de dados vetorial é a receita para o desastre.
As Três Camadas de Memória
O artigo original da PromptOwl descreve três camadas complementares. Na prática, um agente bem desenhado usa as três em simultâneo.
1. Memória de Sessão — Zep
A primeira camada é a mais imediata: o contexto da conversa atual. Foi por aqui que eu comecei: o Zep guarda o histórico de mensagens, resume-as e permite pesquisa semântica sobre o que foi dito antes.
Zep é open-source e funciona como um middleware entre o LLM e a aplicação. À medida que a conversa cresce, o Zep resume mensagens antigas e mantém um índice de pesquisa. Quando o agente precisa de recordar algo, pesquisa no Zep em vez de confiar apenas na janela de contexto.
Cenário prático: Um assistente de suporte técnico que fala com o mesmo utilizador durante uma semana. O Zep permite que ele se lembre de que “o problema do certificado SSL já foi diagnosticado na terça-feira” sem precisar de reter todo o histórico no prompt.
2. Memória de Personalização — Mem0
A segunda camada é sobre o utilizador. Não interessa o que foi dito na última conversa, mas sim quem é a pessoa, o que prefere, como reage.
O Mem0 cria um grafo semântico de perfis de utilizador. Cada interação relevante é extraída, classificada e armazenada como um facto sobre o utilizador. Com o tempo, o agente constrói um modelo comportamental.
A diferença para a camada de sessão? A memória de personalização é persistente entre conversas e independente do tópico. Saber que o utilizador prefere respostas concisas, que já experimentou três soluções diferentes para o mesmo problema ou que evitou sempre falar de custos: isto vive no Mem0, não no Zep.
Cenário prático: Um agente de produtividade pessoal que aprende os teus padrões. Se costumas agendar reuniões ao final da tarde, o Mem0 regista essa preferência. Da próxima vez que disseres “marca uma reunião com a equipa”, o agente propõe automaticamente horários pós-14h.
3. Conhecimento Governado — ContextNest
A terceira camada é a mais esquecida e a mais crítica em produção. Não basta ter informação: é preciso ter a certeza de que a informação está correta e atualizada.
O ContextNest resolve um problema específico: quando o conhecimento da organização muda (preços, versões, procedimentos), é preciso que o agente não use a versão antiga. As bases de dados vetoriais padrão recuperam documentos por similaridade semântica. Se o documento antigo e o novo são semanticamente próximos, o modelo recebe ambos e decide, muitas vezes mal.
O ContextNest usa versões controladas por Git, hash chains SHA-256 e commits explícitos com aprovação manual. Quando um documento é marcado como obsoleto com ctx forget, ele é fisicamente removido do caminho de recuperação. Sem probabilidades, sem ambiguidade.
Cenário prático: Um agente de vendas que consulta preços. A tabela de preços foi atualizada esta semana. Sem ContextNest, o agente podia recuperar a versão antiga e negociar abaixo do custo. Com ContextNest, a versão anterior está simplesmente fora do alcance, deterministicamente eliminada.
E o RAG? E o Fine-Tuning?
O RAG (Retrieval-Augmented Generation) é frequentemente apresentado como a solução para memória. E é, para uma parte do problema. RAG resolve a recuperação de conhecimento estático ou semi-estático. Mas não resolve:
- A personalização (RAG não sabe quem és)
- A continuidade de sessão (cada pesquisa RAG é independente)
- A governança determinística (RAG recupera por similaridade, não por autoridade)
O fine-tuning, por outro lado, é útil para absorver padrões de comportamento e estilos de resposta, mas não serve para factos dinâmicos. Um modelo fine-tuned com dados de Janeiro não sabe o que mudou em Fevereiro.
A conclusão prática? Fine-tuning para personalidade e estilo. RAG para conhecimento de referência. E uma pilha de memória em três camadas para o resto.
Como Implementar Isto na Prática
Se estás a construir um agente hoje, aqui fica um ponto de partida concreto:
- Zep para o estado da conversa — integra como middleware. Cada mensagem passa pelo Zep antes de ir para o LLM.
- Mem0 para perfis de utilizador. Extrai factos após cada interação significativa. Usa a API deles ou self-host se precisares de controlo.
- ContextNest para documentação corporativa. Mantém um repositório Git de Markdown com revisão manual. Integra no pipeline de RAG como fonte autoritária.
Não precisas de lançar tudo no dia um. No meu caso, comecei pela memória de sessão (Zep). Só depois é que adicionei personalização com Mem0. Cada camada resolve um problema diferente, e tentar fazer tudo ao mesmo tempo raramente acaba bem.
O que esta experiência me ensinou
Montei este sistema há três meses. Ao fim desse tempo, a conclusão prática é simples: não há uma bala de prata. Cada camada de memória resolve um problema diferente, e tentar forçar tudo no mesmo sítio só cria problemas. Se estás a começar, faz como eu — implementa a sessão primeiro e vê como corre. A personalização e o conhecimento governado vêm depois, quando o caso base já está sólido.
O mais frustrante no processo foi perceber que não há atalhos. Cada ferramenta resolve uma parte do problema, e tentar saltar passos só adia o problema. Prefiro saber disso agora do que descobrir em produção. Se tivesse começado pelas três camadas ao mesmo tempo, nunca teria percebido qual delas estava realmente a resolver o quê.
Atenção: As ferramentas mencionadas (Zep, Mem0, ContextNest) evoluem rapidamente. Verifica as versões atuais e a documentação oficial antes de implementares em produção. O problema que resolvem é real, mas a solução certa depende sempre do teu caso de uso.
Comentários (0)
Nenhum comentário ainda. Seja o primeiro!
Deixar comentário