Arquitecturas de memoria comparadas
SQLite + FTS5 local, grafo de conocimiento, embeddings vectoriales, híbrido. ¿Cuál encaja en cada tipo de agente?
He construido tres sistemas de memoria en el último año. Cada uno para una forma de agente distinta. Cada uno con compromisos distintos. Esto es lo que aprendí.
Sistema uno: embeddings vectoriales puros (pgvector + Supabase). Cada chunk de memoria recibía un embedding de OpenAI, la búsqueda por similitud devolvía el top-k. Parecía inteligente. Devolvía contexto irrelevante constantemente. El problema: la similitud vectorial es un match difuso por "vibe". Si el usuario pregunta "cuál fue el bug que arreglamos en el flujo de auth la semana pasada", el top-k devolverá temas generales de autenticación, no el bug concreto. La recuperación vectorial es genial para vecindades semánticas, terrible para recuerdo específico.
Sistema dos: full-text search (SQLite FTS5). Sin embeddings, solo ranking BM25 sobre las palabras de las memorias. Más rápido, sin llamadas a APIs, sin factura de embeddings. Para recuerdo específico aplastó a la búsqueda vectorial. Para consultas semánticas (no recuerdas la palabra exacta pero conoces el concepto) falló.
Sistema tres: híbrido. Primer paso FTS5 (rápido, específico, gratis), luego un grafo de conocimiento para recall por entidades (personas, proyectos, decisiones, aprendizajes como nodos con aristas). Embeddings vectoriales solo como tercer nivel cuando los dos primeros no devuelven nada relevante. El coste cayó un 90 %, la calidad de recall subió. Eso es lo que distribuye local-memory-mcp y lo que studiomeyer-memory usa en cloud.
El grafo de conocimiento es el héroe sin reconocer. El agente no necesita similitud vectorial para la mayoría de consultas. Necesita saber "esta entidad fue mencionada, estas son sus observaciones, estas son sus relaciones". Un grafo responde a eso en una consulta. La búsqueda vectorial lo responde de forma probabilística y exige al agente filtrar el ruido.
Cuándo usar vectores: tus datos son sobre todo prosa no estructurada, no hay entidades que extraer, las consultas son conceptuales. Cuándo no: puedes extraer entidades, tienes terminología específica, necesitas recall preciso.
Aviso honesto: la mejor corrida validada de LongMemEval para nuestra memoria híbrida está en 86 % sobre 50q estratificadas (GPT-4o como juez, Anthropic Sonnet 4.6 como generador de respuestas, Run S957b del 1 de mayo de 2026). Ese run corrió contra el servidor de memoria v3.16.10, antes del fix v3.16.11 de cross-project-search-leak del 2 de mayo de 2026, por lo que el 86 % puede estar inflado 1-3 puntos porcentuales; el rango realista tras un re-run limpio es 78-86 %. Comparación: Mem0 Managed Platform saltó al 93,4 % en abril de 2026 (Token-Efficient Memory Algorithm) pero colapsa al 48,6 % agregado / 16,3 % temporal en BEAM-10M production-scale. La página de benchmark en studiomeyer.io rastrea la metodología y los logs de ejecución.
Patrón que veo siempre: los builders eligen vectores primero porque el marketing dice vectores. Después tienen mal recall y le echan la culpa al modelo de embeddings. El modelo está bien. La arquitectura está mal. Prueba FTS5 primero. Añade un grafo si tienes entidades. Añade vectores al final.