Lossless-memory, memoria para IA que no resume nada y guarda cada línea

La mayoría de los sistemas de memoria para asistentes de IA hacen una de dos cosas: resumen la conversación en notas compactas o la vectorizan y recuperan trozos "similares". Lossless-memory rechaza las dos. Guarda cada turno completo, sin resumir, y pone una marca de tiempo en todo. El autor lo resume así: los resúmenes son un mapa, el log es el territorio.

El proyecto vive en GitHub como aru-labs/lossless-memory. Es local, basado en ficheros, y no necesita servidor ni nube: los registros van a ficheros JSONL por día y los índices a SQLite. Está pensado para una sola persona hablando con un solo asistente en una sola máquina.

Cómo está montado

Cada turno se convierte en un registro de siete campos fijos: marca de tiempo ISO-8601 en UTC, actor, rol (user, assistant, system), tipo, texto literal, identificador de modelo y sesión. Todo índice se puede borrar y reconstruir desde los logs, que son la fuente de verdad.

La parte interesante es lo que llaman la columna temporal. El índice exacto usa FTS5 de SQLite, tokenizado por bigramas para japonés e inglés, y guarda el timestamp en cada fila. El parser de consultas entiende expresiones de tiempo —relativas como "ayer" o "hace 3 días", de momento solo en japonés, y fechas absolutas en cualquier idioma— y las convierte en un rango antes de ordenar nada. Si hay una frase temporal, los resultados salen restringidos a ese rango y en orden cronológico. La búsqueda semántica con sqlite-vec queda como último recurso, y cuando se usa el sistema lo dice en la cabecera de la respuesta.

El efecto práctico: el asistente puede contestar "¿qué decidimos el martes por la noche?" con las líneas reales de ese martes, no con una paráfrasis de algo parecido de hace tres semanas.

El tercer pilar es el índice LLL, unas pocas líneas con marcas de tema que registran cuándo la conversación cambió de asunto. Se inyecta en el contexto del modelo en cada turno, tarda bastante menos de un segundo en generarse, y sirve para que el asistente retome el hilo después de que se le haya compactado la ventana de contexto. La regla que lo sostiene es que lo lee la IA pero lo escribe la persona: el modelo no edita su propia noción de qué importa.

Un daemon reindexa de forma incremental cada diez minutos por defecto. Detecta ficheros fuente reescritos y solo reindexa esos días.

Lo que dice su historial de uso

El autor publica medidas de su instancia en producción, no proyecciones. La reconstrucción del índice exacto pasó de 40 segundos a 1,24 segundos tras un rediseño. El índice vectorial sufrió contaminación por parte de una librería: llegó a 865.588 filas el 4 de septiembre, cuando el problema estaba en su peor momento, y quedó en 124.174 tras el arreglo. Antes de eso había 447.013 filas a finales de agosto.

El sistema lleva en uso diario desde julio para un único usuario, con logs crudos desde junio, y arrastra un linaje de diseño que se remonta a diciembre. El propio autor lo describe como pequeño y aburrido, y reconoce que no hay benchmarks publicados: lo que hay es una implementación que funciona y su registro de operación, con los fallos documentados aparte.

El arranque es un clon del repositorio, pip install -e ., copiar un fichero de configuración de ejemplo y seguir el quickstart, que en unos cinco minutos ingiere una conversación de muestra y lanza una consulta con rango temporal. Hay un test de ida y vuelta con pytest que cubre el mismo camino.

A quien le interese el terreno, conviene mirar dos cosas antes de adoptarlo. La primera es que las expresiones temporales relativas solo funcionan en japonés hoy por hoy; las fechas absolutas sí son universales. La segunda es que esto no compite con una base de datos vectorial: si el problema es recuperar conocimiento de un corpus grande, aquí no hay nada que rascar. Encaja en otro caso, el de alguien que quiere que su asistente recuerde literalmente lo que se dijo, y cuándo.