Persistência de estado, grafos temporais e busca híbrida para agentes LLM
LLMs processam cada request de forma completamente isolada. Quando o agente "Maria" discute política no round 15, no round 16 ela não tem nenhuma lembrança dessa conversa a menos que a informação seja explicitamente re-injetada no prompt. O context window do LLM funciona como "memória de trabalho" limitada (128K-200K tokens nos melhores modelos), mas uma simulação de 100 rounds com 50 agentes pode gerar milhões de tokens de histórico. O problema da memória é: como dar ao agente acesso a informações relevantes do passado sem exceder o context window e sem explodir custos de tokens?
Sem memória, agentes se contradizem, repetem posts idênticos, e não desenvolvem opiniões consistentes ao longo do tempo. A memória é o que transforma chamadas LLM desconexas em uma simulação social coerente com agentes que parecem "vivos".
Zep Cloud é uma plataforma SaaS de engenharia de contexto projetada especificamente para aplicações LLM. Seu componente central é o Graphiti, um engine de grafo temporal de conhecimento que armazena não apenas fatos ("AgentX é conservador") mas também quando esse fato foi estabelecido e como ele mudou ao longo do tempo. O Graphiti usa Neo4j como backend de grafo e combina com embeddings vetoriais para busca semântica. Zep possui certificação SOC 2 Type II, garantindo compliance para uso enterprise com dados sensíveis. A API oferece endpoints para add_memory, search_memory, e get_entity_timeline.
O Zep é a solução de memória padrão do OASIS original. Entender o Graphiti permite otimizar queries de memória, reduzir latência e custos, e avaliar se o trade-off cloud vs local faz sentido para seu caso de uso.
KuzuDB é um banco de dados de grafo embutido (embedded) que funciona como uma biblioteca, sem necessidade de servidor separado. Similar ao SQLite para dados relacionais, o KuzuDB armazena grafos em arquivos locais. O fork inematds substituiu toda a camada Zep Cloud por KuzuDB, implementando: armazenamento de memórias como nodes no grafo, relações temporais como edges com timestamps, e busca via Cypher queries combinadas com embeddings locais (sentence-transformers). A migração elimina 100% dos custos de cloud e funciona sem internet.
O KuzuDB é a solução de memória do MiroFish e de todos os forks derivados do inematds. Ele elimina custos recorrentes, permite operação offline, e dá controle total sobre os dados. Para pesquisa acadêmica e prototipagem, é a escolha ideal.
A busca híbrida combina dois paradigmas de information retrieval: busca semântica (que converte textos em vetores densos de 384-1536 dimensões e calcula cosine similarity, capturando significado e sinonímia) e BM25 (evolução do TF-IDF que ranqueia por frequência de termos com normalização de comprimento, capturando matches exatos de keywords). O score combinado é: final_score = 0.7 × semantic_score + 0.3 × bm25_score. Esses pesos foram otimizados empiricamente para equilibrar recall semântico com precisão lexical em queries de memória de agentes.
A qualidade da busca de memória determina diretamente a qualidade das decisões do agente. Se a busca retorna memórias irrelevantes, o agente age de forma incoerente. A busca híbrida maximiza a chance de recuperar memórias verdadeiramente relevantes.
Inspirado na neurociência cognitiva, o sistema organiza memórias em três tipos: Memória Episódica armazena eventos específicos com contexto ("No round 23, vi um post do AgentX defendendo desmatamento e fiquei indignada"). Memória Semântica armazena fatos consolidados sem contexto específico ("AgentX é um apoiador do agronegócio"). Memória Temporal armazena a sequência e timing de eventos, permitindo raciocínio causal ("Minha opinião sobre AgentX mudou depois do round 23"). O sistema implementa consolidação: episódicas repetidas são promovidas a semânticas.
Cada tipo de memória serve uma função cognitiva diferente. Episódicas permitem referências específicas ("como daquela vez que..."), semânticas provêm contexto geral rápido, e temporais permitem raciocínio causal. A combinação produz agentes com comportamento mais natural e coerente.
Os benchmarks de performance do sistema de memória mostram: Zep Cloud atinge P95 < 200ms (95% das queries respondem em menos de 200ms) com 80.32% de precisão no benchmark LoCoMO (Long Context Memory Optimization), que mede capacidade de recuperar informações corretas em históricos longos. O KuzuDB local atinge P95 < 50ms (mais rápido por ser local, sem latência de rede) mas com precisão levemente menor (~75%) por usar embeddings locais menores. Em simulações com 1000 agentes e 100 rounds, o KuzuDB processa ~100K queries de memória em ~8 minutos, enquanto o Zep Cloud leva ~25 minutos mas com melhor qualidade de retrieval.
Performance de memória é o gargalo em simulações de escala. Cada agente consulta memória a cada round. Com 10.000 agentes e 50 rounds, são 500.000 queries de memória. A diferença entre 200ms e 50ms por query é a diferença entre 27 horas e 7 horas de simulação.