Atlas de Memória Open-Source da Elastic Atinge 0.89 Recall@10 com Vazamentos Zero

Elastic abriu o código de Atlas, um sistema de memória de agente construído no Elasticsearch que divide o estado de longo prazo do agente em três índices—episódico, semântico e procedural—espelhando a taxonomia de ciência cognitiva. Em uma avaliação de QA de 168 perguntas, Atlas obteve 0.89 Recall@10 com vazamentos de memória entre inquilinos zero. A implementação de referência é entregue como uma demo FastAPI + Vite/React sob licença MIT com um endpoint de servidor MCP, permitindo que Claude Desktop, Cursor, ou qualquer cliente compatível com MCP se conecte sem mudanças de código.

O problema central: context stuffing. Despejar histórico de conversas anteriores na janela de contexto falha em três pontos—custo de token, latência adicionada, e o efeito "lost in the middle" onde modelos descartam fatos posicionados longe das bordas do prompt. Uma janela de 1M-token lida com uma única passagem de inferência, não persiste entre sessões, não pode ser consultada por conteúdo ou tempo, e não tem conceito de quais fatos permanecem verdadeiros. Atlas preenche essa lacuna.

O design de três índices carrega a arquitetura. Memória episódica captura turnos de usuário timestamped brutos conforme chegam—alta taxa de escrita, mostly transient. Uma etapa de consolidação de LLM destila eventos episódicos em memórias semânticas: asserções estáveis curtas ("Sarah possui um Lumio Hub v2," "hub foi resetado em março") armazenadas com ponteiros de volta para evidência episódica e links de supersessão que invalidam fatos anteriores contraditórios sem exclusão. Memória procedural mantém playbooks multi-etapas, cada um carregando success_count e failure_count incrementados em cada resultado confirmado pelo usuário. Esses contadores enviesam recuperação para playbooks com melhores históricos. Um único bucket unificado não consegue modelar isso: episódico precisa de escritas constantes e decaimento agressivo, semântico precisa de deduplicação e supersessão, procedural precisa de feedback de resultado. Três índices deixam cada um seguir sua própria taxa de escrita e regras de envelhecimento sem acoplamento.

Recuperação executa um pipeline de dois estágios. A consulta híbrida busca 80 candidatos por perna—BM25 para correspondências de token literal (números de versão, códigos de erro, nomes próprios) e vetores densos Jina v5 para similaridade semântica—em seguida, funde ambas as classificações com Reciprocal Rank Fusion. O pool de candidatos fusionado alimenta um reranker de cross-encoder, que retorna os 10 melhores resultados. Um mapeamento copy_to único na escrita de documento mantém o armazenamento plano: o mesmo texto chega no índice invertido BM25 e gera automaticamente vetores Jina v5 via Elastic Inference Service, sem exigir chave de API de embedding externa. Decaimento de tempo e boosts de use-count vivem em um script de function_score Painless envolvendo cada perna RRF—decaimento aplica a episódico e semântico, boost de use-count apenas a semântico.

Multi-tenancy usa segurança em nível de documento. Cada documento de memória carrega um user_id; consultas limitam com um filtro DLS então o histórico de um usuário é estruturalmente invisível para outro. O endpoint do servidor MCP é /api/atlas/mcp/{user_id}, expondo três ferramentas: recall_memory, write_memory, forget_memory. Docs de deployment para Google Cloud Run exigem que o serviço execute atrás de Identity-Aware Proxy—nunca públicos.

Reação no Hacker News sinalizou Elasticsearch como operacionalmente pesado em relação a SQLite ou armazenamentos de vetores leves. O contra-argumento: ANN por força bruta tem desempenho abaixo de um milhão de vetores para latência em tempo real, e qualquer coisa exigindo scoring scripted—as funções de decaimento e boost que Atlas depende—degradam em motores mais simples. O custo real é portar quando o banco de dados atinge seu limite. A aposta arquitetural é que um armazenamento de memória de agente com trilhas de auditoria, scoring scripted, multi-tenancy, e recuperação híbrida precisa de um mecanismo de busca, não de um armazenamento chave-valor com vector bolt-ons.

Atlas é uma referência executável para equipes que cresceram além de context stuffing com escopo de sessão. Os números de benchmark 0.89 R@10 e multi-tenancy com vazamento zero fornecem base concreta. Executar Elasticsearch para cada deployment de agente é um custo operacional real, e a chamada de LLM de consolidação em cada escrita adiciona latência. Para agentes lidando com menos de dezenas de milhares de sessões, um armazenamento mais simples pode ser suficiente. Para scoring scripted, supersessão segura para auditoria, e DLS por usuário em escala, essa arquitetura entrega.