Mnemo, capa de memoria local: recuerdo portable para Ollama y apps LLM propias

Las búsquedas de Mnemo suelen venir de un dolor concreto, no de la curiosidad por otra herramienta LLM local. Quizá ya tienes Ollama corriendo. Quizá ya llamas a un modelo local por una API compatible con OpenAI. La parte incómoda llega después: cuando la sesión termina, el modelo pierde decisiones de proyecto, preferencias del usuario, restricciones de API y la nota de depuración que le diste ayer. Puedes seguir pegando ese material en el prompt, pero el prompt crece, y la información vieja empieza a pelear con la actual.

Mnemo se mete en ese hueco. Mantiene la memoria a largo plazo en tu propia máquina, guarda entidades y chunks vía SQLite y relaciones de grafo, y luego devuelve el contexto recuperado a Ollama, OpenAI, Anthropic u otro backend compatible. No le da al modelo memoria nativa, y no es una base de conocimiento universal. Trátalo como un servicio de memoria local que puedes reemplazar, respaldar, inspeccionar y revertir.

Qué capa de memoria maneja Mnemo

La mayoría de los flujos LLM locales tienen tres capas: el modelo genera, la aplicación coordina el flujo y la capa de memoria trae información útil entre sesiones. Ollama cubre la primera capa al ejecutar modelos en local. El RAG suele responder «¿qué chunks de documentos se parecen a esta pregunta?». Mnemo apunta a la capa entre sesiones más fina.

Un asistente de código local es buen ejemplo. Hoy le dices: «Este proyecto no usa LangChain por ahora; mantén la capa API en FastAPI y SQLite». Mañana inicias una sesión nueva y preguntas cómo agregar retrieval. Un asistente útil debería recuperar esa decisión en vez de proponer un stack completamente distinto.

Eso hace a Mnemo mejor opción una vez que tienes las bases, como llamar a la API de Ollama. Primero haz que el modelo responda de forma fiable. Luego decide qué información merece convertirse en memoria. Invertir ese orden convierte una demo frágil en una máquina de estados difícil de depurar.

Arquitectura: API Rust, SQLite y recorrido de grafo

El README de Mnemo divide el repositorio en cuatro crates Rust. mnemo-core posee la extracción de entidades, las operaciones de grafo, el retrieval y la capa de base de datos. mnemo-api expone una API REST Axum. mnemo-cli es el cliente de línea de comandos. mnemo-bench contiene las suites de benchmark. Para una herramienta local, esa estructura importa, porque muestra que el proyecto es más que un prompt que resume conversaciones viejas.

SQLite guarda el estado, los enlaces de grafo agregan pistas

Muchas herramientas de memoria chunkean cada turno de conversación, crean embeddings y recuperan por similitud. Eso sirve para algunos trabajos, pero dos problemas aparecen pronto. La misma persona, proyecto o decisión puede aparecer en varias sesiones. Dos hechos pueden entrar en conflicto, y la similitud vectorial no decide cuál debe ganar.

🔥 ¡No pierdas meses en productos sin demanda! Valida los puntos fuertes de tu SaaS con Adsterra y poco presupuesto ➡️

Probar ahora →Anuncio

La descripción pública de Mnemo pone más peso en la deduplicación de entidades y el retrieval graph-first. En la práctica, extrae entidades del texto, las fusiona con las existentes y usa aristas de relación durante el retrieval. Si «API gateway», «auth middleware» y «FastAPI service» aparecen en sesiones distintas, el grafo puede conectarlas cuando preguntes por el sistema más tarde.

La expansión de grafo igual necesita una correa. El README dice que los resultados expandidos por grafo participan con menor score, así que las coincidencias directas quedan por delante del contexto inferido. Un buen compromiso: los enlaces de grafo aportan pistas, sin enterrar la evidencia que coincidió directamente con la consulta.

Tratar los números de benchmark como mediciones de proyecto

La tabla de benchmark del README es específica: Apple M2, SQLite WAL, petgraph en memoria y un pipeline de retrieval en debug build de unos 4,2 ms, con la nota de que los release builds son más rápidos. Eso muestra que el camino local fue medido. No prueba que tu setup se comporte igual. Tu resultado depende del volumen de datos, las llamadas de extracción, la velocidad del disco, el backend de modelo y la política de retrieval.

Antes de la latencia, yo vigilaría tres cosas: si las memorias escritas se pueden reproducir, si los resultados recuperados explican su fuente, y si las memorias malas se pueden borrar o corregir. El código lento suele optimizarse. Una memoria errónea sin fuente es mucho más difícil de confiar.

Correr el camino mínimo Docker + Ollama

No conectes Mnemo a tu proyecto principal el primer día. Usa una carpeta temporal, sigue la ruta Docker + Ollama del README upstream, y decide después si pertenece a tu aplicación.

git clone https://github.com/zaydmulani09/mnemo
cd mnemo
docker compose up -d

# Bajar el modelo de ejemplo del README la primera vez
docker exec mnemo-ollama ollama pull llama3

# Verificar el servicio API
curl http://localhost:8080/health

Si ya recorriste la guía para principiantes de Ollama, este flujo te resultará familiar. La diferencia: Mnemo arranca una API de memoria junto al contenedor de Ollama. Después, tu app habla con el servicio de memoria en vez de meter cada decisión pasada en el contexto del modelo.

Usar el Python SDK para un smoke test

El README también da un camino mínimo de Python SDK. Prueba una sola cosa: escribir una memoria, luego preguntar en lenguaje natural y ver si vuelve.

from mnemo import MnemoClient

client = MnemoClient()

client.ingest("Estoy construyendo una base de datos vectorial en Rust llamada vecdb")
print(client.get_context("¿En qué proyecto de base de datos estoy trabajando?"))

Al ejecutarlo, no juzgues solo la respuesta final del modelo. Revisa los logs del servicio, los archivos de base de datos, la estructura de la respuesta API y si la memoria sobrevive a un reinicio. El umbral mínimo de la memoria a largo plazo no es una redacción pulida. Es un estado duradero, inspeccionable y recuperable.

El camino binario sirve cuando Ollama ya existe

Si Ollama ya corre en tu máquina, el README también describe una ruta binaria:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

cargo install --path crates/mnemo-api
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1
mnemo-api

Este camino encaja con un setup LLM local existente. Mantén tus propios modelos, puertos y monitoreo, y agrega Mnemo como servicio separado. Si después pasas a un backend en la nube, configura una base URL compatible con OpenAI, una clave API, un modelo y un provider.

Revisar el encaje antes de adoptarlo

El README de Mnemo da un límite útil: si ya usas un harness de agente gestionado que maneja bien la memoria, quizá no necesites Mnemo. Esa advertencia importa. Más capas de memoria pueden significar más estado oculto.

El local-first tiene un beneficio claro: los datos quedan en tu máquina, el archivo SQLite es fácil de respaldar, y no tienes que enviar cada conversación de proyecto a un servicio en la nube. El trabajo de seguridad sigue siendo necesario. Decide quién puede leer la base, dónde viven los backups, si los logs contienen claves API y cómo se quitan las memorias malas.

Tres barandillas para la capa de memoria

La memoria a largo plazo solo es útil mientras siga siendo gobernable. Antes de conectar Mnemo a un agente real, yo escribiría tres reglas en el propio proyecto.

Cada memoria necesita una fuente

Una memoria no debería terminar como una frase resumen solitaria. Debería apuntar a una conversación, archivo, tarea o resultado de API. Si un agente dice «Este proyecto usa FastAPI», deberías poder rastrear de dónde salió esa afirmación.

Esa es también la lección principal de la guía de memoria de agentes IA. La memoria a largo plazo no es un portapapeles más grande. Sin fuente, tiempo y validez, las conclusiones viejas se ponen ropa nueva.

El contexto recuperado necesita un presupuesto

Un servicio local rápido igual debería devolver un set pequeño de evidencia. Para muchas tareas, 5 a 15 memorias muy relevantes con pistas de fuente bastan. Si el modelo necesita más, deja que vuelva a consultar en vez de empujar docenas de notas posiblemente relacionadas al prompt.

Esto reduce el context rot. Los agentes suelen fallar con mucho material en la mano porque ese material está viejo, duplicado o es contradictorio. La capa de memoria debería filtrar antes de que el prompt crezca.

Las memorias malas necesitan un camino de retiro

La memoria más peligrosa es errónea, no faltante. Supón que el modelo guardó una vez «el schema de producción se puede cambiar directo», y luego el equipo exige una migration review. Si esa memoria vieja sigue activa, el agente acabará haciendo una sugerencia riesgosa.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Así que el piloto necesita acciones de retiro: borrar una memoria, marcarla expirada, re-extraer un proyecto o vaciar un espacio de usuario. Sin esos movimientos, la memoria a largo plazo se vuelve deuda.

Checklist de diagnóstico

Los problemas de una herramienta como Mnemo suelen vivir entre el servicio local, el backend de modelo y el retrieval. Revísalos en este orden:

• curl http://localhost:8080/health falla: revisa si los contenedores Docker corren y si el puerto ya está ocupado.
• Ollama no puede bajar el modelo: ejecuta ollama list dentro del contenedor y confirma que el modelo existe; usa un modelo más pequeño si la red va lenta.
• Las llamadas API se cuelgan: verifica que MNEMO_LLM_BASE_URL apunte a un endpoint compatible con OpenAI. Ollama escucha comúnmente en 11434.
• La respuesta ignora la memoria: confirma que ingest tuvo éxito, luego inspecciona el contexto de retrieval en vez de juzgar solo la respuesta final.
• La memoria desaparece tras reinicio: revisa si la ruta de datos SQLite está montada en un volumen persistente.
• Los resultados se vuelven confusos: reduce el contexto recuperado, deduplica entidades y expira decisiones de proyecto viejas.

Estas revisiones superan al toqueteo de prompt. Un prompt puede cambiar cómo habla el modelo. No puede arreglar un servicio que nunca arrancó o una ruta de base que desaparece con el contenedor.

Lectura sugerida y un piloto seguro

Si todavía no has ejecutado un modelo local, empieza por la guía para principiantes de Ollama. Cuando las llamadas al modelo sean estables, pasa a las llamadas a la API de Ollama y a los embeddings de Ollama. Mnemo encaja después de esas bases como piloto de memoria de agente.

Un piloto de 7 días puede quedarse pequeño:

1. Elige un proyecto, no toda tu máquina.
2. Escribe 30 a 50 memorias reales sobre el stack, las opciones descartadas, los errores comunes y las restricciones de API.
3. Haz las mismas 10 preguntas de repetición cada día y registra el retrieval correcto, faltante y erróneo.
4. Borra o expira las memorias malas, luego revisa si la siguiente respuesta cambia.
5. Reinicia el contenedor y la máquina, luego confirma que las memorias quedan.
6. Agrega backups de base, chequeos de permisos y escaneo de secretos.
7. Recién entonces decide si tu agente principal debe usarlo.

El objetivo útil de Mnemo es modesto: traer un set pequeño de contexto importante a la próxima tarea, dejando a los humanos capaces de inspeccionar, editar, respaldar y retirar ese contexto. Una vez que logras eso, un LLM local empieza a sentirse menos como una ventana de chat desechable y más como una herramienta sostenible.