Mnemo avec Ollama : mémoire locale et déploiement

Votre modèle Ollama sait déjà répondre aux questions, mais chaque conversation repart de zéro. La décision de projet évoquée hier, la préférence définie aujourd’hui, la contrainte dont vous aurez besoin demain : tout disparaît.

C’est le manque de mémoire des LLM locaux. Ollama fournit un service de modèle capable de répondre. Mais ce qu’il répond, et ce qu’il garde de vos contraintes passées, dépend encore de ce que vous répétez manuellement à chaque prompt.

Mnemo ne cherche pas à refaire un RAG. Il utilise un graphe de connaissances et l’extraction d’entités pour gérer la mémoire longue durée, afin que votre LLM local se souvienne des décisions de projet et des relations entre entités au lieu de redemander : « à quoi sert cette API ? »

1. Ce qu’est Mnemo : positionnement et capacités clés

1.1 Lire le positionnement

Dans l’expression « local-first AI memory layer », deux mots comptent :

• local-first : les données restent chez vous, ne partent pas dans le cloud, sont migrables et ne dépendent pas de la survie d’un SaaS
• memory layer : ce n’est ni un nouveau RAG, ni un nouveau framework d’agent. Il se concentre sur la mémoire : extraction d’entités, construction de graphe et recherche sémantique

Prenons un exemple : vous demandez « quelle est l’URL de base de l’API de ce projet ? ». Une recherche vectorielle pure peut renvoyer plusieurs fragments de documentation liés à « API », sans savoir de quel projet vous parlez. Une recherche par graphe peut suivre la chaîne « projet -> API -> baseUrl » et renvoyer la valeur de configuration définie plus tôt.

Tout repose sur une extraction d’entités correcte. Si le LLM découpe à tort « URL de base de l’API » en deux entités, « API » et « URL de base », le graphe se fragmente et le rappel casse. C’est la racine de l’accumulation de bruit.

Une fois ce positionnement clair, les capacités principales sont plus faciles à lire.

1.2 Matrice des capacités clés

Le README de Mnemo met en avant quatre capacités :

1. persistent knowledge graph (graphe de connaissances persistant)

   • Les entités et les relations sont stockées dans SQLite, pas dans des vecteurs jetables
   • La structure du graphe peut être interrogée, exportée et migrée

2. entity extraction (extraction d’entités)

   • Identifie automatiquement dans les conversations des personnes, noms de projets, noms d’API ou décisions
   • Ce n’est pas une recherche vectorielle pure. La question « à quoi sert cette API ? » devient une structure entité-relation interrogeable
   • La qualité dépend de la compréhension du LLM. Un LLM local comme llama3 peut mal identifier des entités dans une conversation complexe. Le bruit s’accumule. Le README ne propose pas de nettoyage automatique complet : vous devez contrôler régulièrement la qualité du graphe

3. semantic retrieval (retrieval sémantique)

   • Combine recherche plein texte dans les fragments, recherche de noms d’entités, expansion du graphe, filtre de relations et classement pondéré
   • Les résultats issus de l’expansion sont déclassés afin que les correspondances directes passent avant les relations déduites et limitent le contexte

4. graph-first vs pure vector search

La recherche vectorielle pure demande : « qu’est-ce qui ressemble à ceci ? » La recherche par graphe demande : « qu’est-ce qui est relié ? » La première peut renvoyer du bruit similaire mais non pertinent. La seconde suit les chaînes de relations entre entités.

La comparaison rend la différence plus nette :

1.3 Stack technique et licence

Stack technique :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Rust, avec quatre crates détaillées dans la section suivante
• SQLite pour le stockage local en mode WAL
• petgraph pour le graphe en mémoire
• API OpenAI, Ollama ou Anthropic comme backend LLM

Licence : MIT License. Vous pouvez l’utiliser, le modifier et le redistribuer.

Rappels de risque :

• Projet encore jeune, d’après le README GitHub du 2026-06-05
• Les API et l’architecture peuvent changer
• Pas de validation de production à grande échelle documentée
• Les chiffres de performance du README sont des mesures internes, pas une preuve indépendante

2. Architecture : quatre crates Rust

Mnemo est écrit en Rust et découpé en quatre crates aux responsabilités claires :

mnemo-core : logique centrale

• Extraction d’entités, construction du graphe et logique de rappel
• Ne dépend pas d’un backend LLM précis ; il définit les interfaces

mnemo-api : serveur

• Fournit l’API HTTP, par défaut sur le port 8080
• Reçoit les conversations, appelle core et renvoie les résultats
• Health check : curl http://localhost:8080/health

mnemo-cli : outil en ligne de commande

• Débogage, gestion et requêtes
• Appelle l’API Mnemo en HTTP pour l’ingestion, le rappel, l’inspection des entités et l’effacement complet

mnemo-bench : tests de performance

• Les 122 Rust tests, 21 Python tests et 12 benchmarks mentionnés dans le README y sont liés
• Source des mesures déclarées par le projet

Ce découpage a des avantages :

• core se teste seul, sans dépendre de l’API
• cli facilite le débogage local sans lancer le service
• bench reste isolé et n’affecte pas le code de production

Ses inconvénients :

• Il faut une toolchain Rust complète pour compiler, sauf avec Docker
• Si les API entre crates changent, plusieurs endroits doivent souvent être ajustés ensemble

3. Installation et déploiement : trois chemins

Mnemo propose trois chemins de déploiement, du plus simple au plus manuel :

3.1 Docker + Ollama : le démarrage le plus rapide

Prérequis : Docker et Ollama sont installés.

# 1. cloner le projet
git clone https://github.com/zaydmulani09/mnemo.git
cd mnemo

# 2. démarrer Docker
docker compose up -d

# 3. télécharger le modèle dans Docker
docker exec mnemo-ollama ollama pull llama3

# 4. health check
curl http://localhost:8080/health

Attention : les commandes peuvent changer. Le README GitHub fait foi.

Explication : Docker compose démarre deux conteneurs : mnemo-api, le serveur, et mnemo-ollama, le service Ollama. Le second est optionnel. Si Ollama tourne déjà localement, vous pouvez n’utiliser que le conteneur mnemo-api et connecter l’Ollama local avec MNEMO_LLM_BASE_URL=http://host.docker.internal:11434/v1.

Vérifier la connexion LLM : si le health check renvoie {"status":"ok"}, l’API est démarrée, mais la connexion LLM n’est pas encore prouvée. Envoyez une requête de test avec curl :

curl -X POST http://localhost:8080/ingest \
  -H "Content-Type: application/json" \
  -d '{"content":"Le projet Atlas utilise https://api.example.test comme URL de base","source":"chat","session_id":"mnemo-trial"}'

Après l’écriture, appelez /retrieve pour vérifier le rappel :

curl -X POST http://localhost:8080/retrieve \
  -H "Content-Type: application/json" \
  -d '{"text":"Quelle est l URL de base de l API Atlas ?","session_id":"mnemo-trial"}'

Si la réponse contient des entités, des fragments de mémoire ou un context_prompt, extraction et rappel fonctionnent.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Avantages :

• Pas besoin de toolchain Rust
• Docker gère les dépendances automatiquement
• Ollama et Mnemo sont dans le même réseau compose, donc la configuration réseau est simple

Inconvénients :

• Docker consomme des ressources
• Le débogage est moins pratique, car il faut entrer dans les conteneurs pour inspecter SQLite
• Les logs sont répartis entre deux conteneurs

3.2 Binary : compilation locale

Prérequis : toolchain Rust installée, avec cargo et rustc, et Ollama installé.

# 1. cloner le projet
git clone https://github.com/zaydmulani09/mnemo.git
cd mnemo

# 2. compiler la crate API
cargo install --path crates/mnemo-api

# 3. configurer l'adresse Ollama
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1

# 4. démarrer le service
mnemo-api

Attention : les commandes peuvent changer. Le README GitHub fait foi ; ce chemin nécessite une toolchain Rust.

Explication : le temps de compilation dépend de la machine et du cache Cargo. Après compilation, mnemo-api utilise par défaut mnemo.db dans le répertoire courant. Modifiez le chemin avec MNEMO_DB_PATH ou la configuration TOML.

Vérifier la connexion Ollama : avant le démarrage, confirmez qu’Ollama écoute sur localhost:11434 et que le modèle a été téléchargé avec ollama pull llama3. Après le démarrage, testez avec curl :

curl -X POST http://localhost:8080/ingest \
  -H "Content-Type: application/json" \
  -d '{"content":"Tester l extraction d entités Mnemo","source":"cli-check"}'

Avantages :

• Ne dépend pas de Docker
• Plus simple à déboguer, car c’est un processus local et les logs restent dans le même terminal
• mnemo-cli peut manipuler directement SQLite local
• Le port et le chemin de base peuvent être ajustés avec des variables d’environnement

Inconvénients :

• Toolchain Rust complète nécessaire
• Première compilation longue
• Les dépendances peuvent bloquer, par exemple si cargo.lock est obsolète

3.3 OpenAI-compatible : LLM cloud

Prérequis : vous avez une clé API OpenAI, Anthropic ou autre backend compatible OpenAI.

Liste des variables d’environnement, vérifiée avec le README GitHub de 2026-06 :

export MNEMO_LLM_BASE_URL=https://api.openai.com/v1
export MNEMO_LLM_API_KEY=sk-...
export MNEMO_LLM_MODEL=gpt-4o-mini
export MNEMO_LLM_PROVIDER=openai

Puis démarrez :

mnemo-api

Attention : les noms de variables peuvent changer. Le README GitHub fait foi.

Cas adaptés :

• Votre machine locale n’a pas assez de calcul et vous utilisez un LLM cloud
• Vous avez déjà du quota OpenAI API
• Vous acceptez que le contenu des conversations soit envoyé au cloud. Avec un LLM cloud, local-first ne protège que le stockage local, pas le trafic d’inférence

Choisissez l’un des trois chemins selon votre contexte. La question suivante est la performance.

4. Performance : mesures déclarées dans le README

Le README de Mnemo liste des mesures de performance, vérifiées de nouveau le 17 juillet 2026 :

Conditions de test :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• Apple M2, debug build
• SQLite en mode WAL
• petgraph en mémoire

Chiffres de performance :

• Pipeline complet de retrieval : environ 4,2 ms
• Le release build serait 3 à 5 fois plus rapide, soit environ 0,8 à 1,4 ms

Attention : il s’agit d’une mesure du README, pas d’une preuve indépendante. La performance varie selon matériel, volume de données et backend LLM.

Comment lire ces chiffres :

• 4,2 ms mesure le retrieval, pas l’inférence LLM. L’inférence LLM reste le goulot d’étranglement
• SQLite WAL combiné à un graphe en mémoire peut rendre le rappel rapide
• Ce n’est qu’une mesure du rappel, pas de la vitesse de conversation

L’expérience réelle dépend de :

• temps d’inférence LLM, bien plus lent que le rappel
• longueur des conversations, car l’extraction d’entités appelle aussi le LLM
• volume de données, car un graphe plus grand ralentit la recherche

Conseil : exécutez mnemo-bench sur la machine cible. Les chiffres du README sont une référence, pas une promesse.

5. Caractéristiques local-first et limites

5.1 Avantages du local-first

Le cœur du local-first est simple : les données restent sur votre machine.

Avantages concrets :

1. Protection de la vie privée

   • Conversations, entités et relations restent dans SQLite local
   • Rien n’est envoyé à un SaaS tiers, tant que vous utilisez un LLM local

2. Contrôle des données

   • Le fichier SQLite peut être exporté, sauvegardé et migré
   • Vous ne dépendez pas de la survie d’un SaaS : vos données restent avec vous

3. Portabilité

   • Pour changer de machine, copiez le fichier SQLite
   • Pas besoin de « réentraîner » la mémoire

4. Débogage

   • SQLite est un format standard, consultable avec n’importe quel outil SQLite
   • La structure du graphe est visible, contrairement à des vecteurs opaques

5.2 Risques et limites

Le local-first a des avantages, mais aussi des risques :

1. Accumulation de bruit

   • L’extraction d’entités n’est pas parfaite et peut se tromper
   • Les entités mal reconnues influencent les rappels suivants
   • Un nettoyage régulier est nécessaire, mais Mnemo ne fournit pas de nettoyage automatique
   • Ce problème n’est pas propre à Mnemo : il existe dans tout système de mémoire automatique. La différence est que le graphe de Mnemo se voit. Vous pouvez voir les entités bruitées et les mauvaises relations. Dans un système vectoriel, le bruit se cache dans les vecteurs. C’est un avantage du graphe, mais aussi une charge de maintenance

2. Limites de suppression et de restauration

   • L’API actuelle supprime une entité, un fragment de mémoire ou tout le contenu avec un en-tête de confirmation
   • Elle ne fournit pas de transaction haut niveau pour annuler la dernière écriture ou une décision métier complète
   • Si une erreur s’est propagée à plusieurs entités et relations, source ou session doit délimiter les éléments à supprimer avant une restauration
   • Ajoutez source, session_id et un identifiant d’audit aux décisions importantes, puis vérifiez l’extraction avant de stocker des faits réels

3. État caché

   • Le graphe peut contenir des relations que vous ne remarquez pas
   • Le retrieval peut renvoyer des résultats sans que leur chemin soit évident

4. Frontières d’usage

   • Avec de gros volumes, SQLite + graphe en mémoire peuvent être sous pression
   • Un usage partagé entre agents exige une couche d’autorisation, d’isolation et d’exploitation que Mnemo ne fournit pas

5.3 Tableau : cas adaptés et cas à éviter

Verdict : si votre cas est « projet personnel, forte confidentialité, Ollama déjà présent, volume modéré », Mnemo vaut un essai. Si votre cas est « gros volume, collaboration d’équipe, mémoire globale partagée », mieux vaut attendre sa maturité ou choisir une autre solution.

Suggestions concrètes :

• Lancez d’abord le chemin Docker dans un environnement de test, puis observez la structure du graphe, la qualité d’extraction et le résultat du rappel
• Testez le risque de bruit avec des conversations de test. Dites volontairement des choses hors sujet et vérifiez si Mnemo les identifie à tort
• Préparez un plan de nettoyage. Familiarisez-vous avec la structure SQLite pour savoir supprimer manuellement une mauvaise entité
• Suivez les mises à jour du README. Le projet est jeune : API, architecture et commandes peuvent changer

6. Suite : navigation dans la série

Si vous n’avez pas encore lu les articles précédents de la série Ollama local LLM, suivez cet ordre :

1. Guide Ollama débutant : faire tourner un grand modèle de langage en local

   • Commencez ici si Ollama n’est pas encore installé

2. Appels API Ollama : de curl à l’interface compatible OpenAI SDK

   • Mnemo utilise une API compatible OpenAI, donc il faut comprendre l’API Ollama

3. Ollama Embedding en pratique : recherche vectorielle locale et RAG

   • Sert à comparer la recherche vectorielle pure avec la chaîne plein texte, entités et graphe de Mnemo

4. Mémoire d’AI Agent : mémoire longue durée et gouvernance des connaissances

   • Mnemo est un outil de couche mémoire ; cet article explique la gouvernance de la mémoire d’agent

Après ces quatre lectures, installez Mnemo et exécutez le chemin Docker en local. Le premier résultat utile est de voir à quoi ressemble vraiment le graphe de connaissances.