La Memoria de Agente de Código Abierto de Elastic Alcanza 0.89 Recall@10 con Fugas Cero

Elastic abrió el código de Atlas, un sistema de memoria de agente construido en Elasticsearch que divide el estado a largo plazo del agente en tres índices—episódico, semántico y procedural—reflejando la taxonomía de la ciencia cognitiva. En una evaluación de QA de 168 preguntas, Atlas logró 0.89 Recall@10 con fugas de memoria entre inquilinos cero. La implementación de referencia se entrega como una demostración FastAPI + Vite/React bajo licencia MIT con un endpoint de servidor MCP, permitiendo que Claude Desktop, Cursor, o cualquier cliente compatible con MCP se conecte sin cambios de código.

El problema central: context stuffing. Volcar el historial de conversaciones previas en la ventana de contexto falla en tres puntos—costo de token, latencia añadida, y el efecto "lost in the middle" donde los modelos descartan hechos posicionados lejos de los bordes del prompt. Una ventana de 1M-token maneja una única pasada de inferencia, no persiste entre sesiones, no puede ser consultada por contenido o tiempo, y no tiene concepto de qué hechos siguen siendo verdaderos. Atlas llena ese vacío.

El diseño de tres índices sustenta la arquitectura. La memoria episódica captura turnos de usuario marcados con fecha brutos conforme llegan—alta tasa de escritura, principalmente transitorios. Un paso de consolidación de LLM destila eventos episódicos en memorias semánticas: afirmaciones estables cortas ("Sarah posee un Lumio Hub v2," "el hub fue reiniciado en marzo") almacenadas con punteros de vuelta a evidencia episódica y enlaces de supersesión que invalidan hechos anteriores contradictorios sin eliminación. La memoria procedural mantiene playbooks multi-paso, cada uno llevando success_count y failure_count incrementados en cada resultado confirmado por el usuario. Esos contadores sesgan la recuperación hacia playbooks con mejores historiales. Un único bucket unificado no puede modelar esto: episódico necesita escrituras constantes y decaimiento agresivo, semántico necesita deduplicación y supersesión, procedural necesita retroalimentación de resultados. Tres índices permiten que cada uno siga su propia tasa de escritura y reglas de envejecimiento sin acoplamiento.

La recuperación ejecuta un pipeline de dos fases. La consulta híbrida obtiene 80 candidatos por rama—BM25 para coincidencias de token literal (números de versión, códigos de error, nombres propios) y vectores densos Jina v5 para similitud semántica—luego fusiona ambas clasificaciones con Reciprocal Rank Fusion. El pool de candidatos fusionado alimenta un reranker de cross-encoder, que devuelve los 10 mejores resultados. Un mapeamiento copy_to único en la escritura de documento mantiene el almacenamiento plano: el mismo texto llega al índice invertido BM25 y genera automáticamente vectores Jina v5 a través del Elastic Inference Service, sin requerir clave de API de embedding externa. La decadencia de tiempo y los boosts de use-count viven en un script de function_score Painless envolviendo cada rama RRF—decadencia se aplica a episódico y semántico, boost de use-count solo a semántico.

Multi-tenancy usa seguridad a nivel de documento. Cada documento de memoria lleva un user_id; las consultas se limitan con un filtro DLS entonces el historial de un usuario es estructuralmente invisible para otro. El endpoint del servidor MCP es /api/atlas/mcp/{user_id}, exponiendo tres herramientas: recall_memory, write_memory, forget_memory. Los docs de implementación para Google Cloud Run requieren que el servicio se ejecute detrás de Identity-Aware Proxy—nunca públicos.

El contrapunto en Hacker News señaló a Elasticsearch como operacionalmente pesado en relación a SQLite o almacenes de vectores ligeros. El contra-argumento: ANN de fuerza bruta tiene un desempeño por debajo de un millón de vectores para latencia en tiempo real, y cualquier cosa que requiera scoring con scripts—las funciones de decaimiento y boost que Atlas depende—se degrada en motores más simples. El costo real es migrar cuando la base de datos alcanza su límite. La apuesta arquitectónica es que un almacén de memoria de agente con pistas de auditoría, scoring con scripts, multi-tenancy, y recuperación híbrida necesita un motor de búsqueda, no un almacén clave-valor con vector bolt-ons.

Atlas es una referencia ejecutable para equipos que superaron el context stuffing con alcance de sesión. Los números de benchmark 0.89 R@10 y multi-tenancy con fugas cero proporcionan una base concreta. Ejecutar Elasticsearch para cada implementación de agente es un costo operacional real, y la llamada de LLM de consolidación en cada escritura añade latencia. Para agentes manejando menos de decenas de miles de sesiones, un almacén más simple puede ser suficiente. Para scoring con scripts, supersesión segura para auditoría, y DLS por usuario a escala, esta arquitectura entrega.