Mnemo, couche mémoire locale : un rappel portable pour Ollama et vos apps LLM

Les recherches sur Mnemo viennent en général d’une douleur concrète, pas de la curiosité pour un énième outil LLM local. Ollama tourne peut-être déjà chez vous. Vous appelez peut-être déjà un modèle local via une API compatible OpenAI. Le moment gênant arrive ensuite : après la fin de la session, le modèle perd les décisions de projet, les préférences utilisateur, les contraintes d’API et la note de debug que vous lui aviez donnée hier. Vous pouvez recoller ce matériel dans le prompt, mais le prompt s’allonge, et l’information périmée commence à se battre avec l’information actuelle.

Mnemo se loge dans cet interstice. Il garde la mémoire à long terme sur votre propre machine, stocke entités et chunks via SQLite et des relations de graphe, puis renvoie le contexte récupéré à Ollama, OpenAI, Anthropic ou un autre backend compatible. Il ne donne pas au modèle une mémoire native, et ce n’est pas une base de connaissances universelle. Voyez-le comme un service mémoire local que vous pouvez remplacer, sauvegarder, inspecter et rollback.

Quelle couche de mémoire gère Mnemo

La plupart des workflows LLM locaux ont trois couches : le modèle génère, l’application coordonne le flux, et la couche mémoire ramène l’information utile à travers les sessions. Ollama couvre la première couche en exécutant les modèles en local. Le RAG répond généralement à « quels chunks de documents ressemblent à cette question ? ». Mnemo vise la couche inter-sessions plus fine.

Un assistant de code local est un bon exemple. Aujourd’hui vous lui dites : « Ce projet n’utilise pas LangChain pour l’instant ; garde la couche API sur FastAPI et SQLite. » Demain vous démarrez une nouvelle session et demandez comment ajouter du retrieval. Un assistant utile devrait retrouver cette décision au lieu de proposer un stack complètement différent.

Cela fait de Mnemo un meilleur choix une fois les bases en place, comme appeler l’API Ollama. Faites d’abord répondre le modèle de façon fiable. Décidez ensuite quelles informations méritent de devenir des mémoires. Inverser cet ordre transforme une démo fragile en machine à états difficile à déboguer.

Architecture : API Rust, SQLite et parcours de graphe

Le README de Mnemo découpe le dépôt en quatre crates Rust. mnemo-core possède l’extraction d’entités, les opérations de graphe, le retrieval et la couche base de données. mnemo-api expose une API REST Axum. mnemo-cli est le client en ligne de commande. mnemo-bench contient les suites de benchmark. Pour un outil local, cette structure compte, car elle montre que le projet est plus qu’un prompt qui résume d’anciennes conversations.

SQLite stocke l’état, les liens de graphe ajoutent des indices

Beaucoup d’outils de mémoire découpent chaque tour de conversation, créent des embeddings et récupèrent par similarité. Cela marche pour certains travaux, mais deux problèmes apparaissent vite. La même personne, le même projet ou la même décision peut apparaître dans plusieurs sessions. Deux faits peuvent entrer en conflit, et la similarité vectorielle ne décide pas lequel doit l’emporter.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget ➡️

Tester l'MVP →Pub

La description publique de Mnemo met plus de poids sur la déduplication d’entités et le retrieval graph-first. En pratique, il extrait les entités du texte, les fusionne avec les entités existantes et utilise des arêtes de relation pendant le retrieval. Si « API gateway », « auth middleware » et « FastAPI service » apparaissent dans des sessions différentes, le graphe peut les relier quand vous interrogez le système plus tard.

L’expansion de graphe a quand même besoin d’une laisse. Le README indique que les résultats étendus par graphe participent avec un score plus faible, donc les correspondances directes passent devant le contexte inféré. Un compromis utile : les liens de graphe apportent des indices, sans enterrer la preuve qui correspond directement à la requête.

Traiter les chiffres de benchmark comme des mesures de projet

La table de benchmark du README est précise : Apple M2, SQLite WAL, petgraph en mémoire et un pipeline de retrieval en debug build autour de 4,2 ms, avec la note que les release builds sont plus rapides. Cela montre que le chemin local a été mesuré. Cela ne prouve pas que votre setup se comportera pareil. Votre résultat dépend du volume de données, des appels d’extraction, de la vitesse du disque, du backend de modèle et de la politique de retrieval.

Avant la latence, je surveillerais trois choses : si les mémoires écrites peuvent être rejouées, si les résultats récupérés expliquent leur source, et si les mauvaises mémoires peuvent être supprimées ou corrigées. Du code lent s’optimise souvent. Une mémoire fausse sans source est bien plus dure à croire.

Faire tourner le plus petit chemin Docker + Ollama

Ne branchez pas Mnemo à votre projet principal le premier jour. Utilisez un dossier temporaire, suivez la route Docker + Ollama du README upstream, et décidez plus tard si elle a sa place dans votre application.

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

# Tirer le modèle d'exemple du README la première fois
docker exec mnemo-ollama ollama pull llama3

# Vérifier le service API
curl http://localhost:8080/health

Si vous avez déjà parcouru le guide débutant Ollama, ce flux vous semblera familier. La différence : Mnemo démarre une API mémoire à côté du conteneur Ollama. Ensuite, votre app parle au service mémoire au lieu d’entasser chaque décision passée dans le contexte du modèle.

Utiliser le Python SDK pour un smoke test

Le README donne aussi un chemin Python SDK minimal. Il teste une seule chose : écrire une mémoire, puis poser une question en langage naturel et voir si elle revient.

from mnemo import MnemoClient

client = MnemoClient()

client.ingest("Je construis une base de données vectorielle en Rust nommée vecdb")
print(client.get_context("Sur quel projet de base de données je travaille ?"))

En l’exécutant, ne jugez pas seulement la réponse finale du modèle. Vérifiez les logs du service, les fichiers de base de données, la structure de la réponse API et si la mémoire survit à un redémarrage. Le seuil minimal de la mémoire à long terme n’est pas une jolie formulation. C’est un état durable, inspectable et récupérable.

Le chemin binaire convient quand Ollama existe déjà

Si Ollama tourne déjà sur votre machine, le README décrit aussi une route binaire :

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

Commencer →Pub

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

Ce chemin convient à un setup LLM local existant. Gardez vos propres modèles, ports et monitoring, et ajoutez Mnemo comme service séparé. Si vous passez plus tard à un backend cloud, configurez plutôt une base URL compatible OpenAI, une clé API, un modèle et un provider.

Vérifier la pertinence avant d’adopter

Le README de Mnemo donne une limite utile : si vous utilisez déjà un harness d’agent managé qui gère bien la mémoire, vous n’avez peut-être pas besoin de Mnemo. Cet avertissement compte. Plus de couches mémoire peut signifier plus d’état caché.

Le local-first a un avantage clair : les données restent sur votre machine, le fichier SQLite est facile à sauvegarder, et vous n’avez pas à envoyer chaque conversation de projet à un service cloud. Le travail de sécurité reste nécessaire. Décidez qui peut lire la base, où vivent les backups, si les logs contiennent des clés API et comment les mauvaises mémoires sont retirées.

Trois garde-fous pour la couche mémoire

La mémoire à long terme n’est utile que tant qu’elle reste gouvernable. Avant de brancher Mnemo à un vrai agent, j’écrirais trois règles dans le projet lui-même.

Chaque mémoire a besoin d’une source

Une mémoire ne devrait pas finir en phrase de résumé solitaire. Elle devrait pointer vers une conversation, un fichier, une tâche ou un résultat d’API. Si un agent dit « Ce projet utilise FastAPI », vous devriez pouvoir tracer d’où vient cette affirmation.

C’est aussi la leçon principale du guide sur la mémoire des agents IA. La mémoire à long terme n’est pas un presse-papiers plus grand. Sans source, temps et validité, les vieilles conclusions enfilent des habits neufs.

Le contexte récupéré a besoin d’un budget

Un service local rapide devrait quand même renvoyer un petit jeu de preuves. Pour beaucoup de tâches, 5 à 15 mémoires très pertinentes avec des indices de source suffisent. Si le modèle a besoin de plus, laissez-le réinterroger au lieu de pousser des dizaines de notes possiblement liées dans le prompt.

Cela limite le context rot. Les agents échouent souvent avec beaucoup de matériel en main parce que ce matériel est périmé, dupliqué ou contradictoire. La couche mémoire devrait filtrer avant que le prompt ne grossisse.

Les mauvaises mémoires ont besoin d’un chemin de retrait

La mémoire la plus dangereuse est fausse, pas manquante. Supposons que le modèle ait un jour stocké « le schéma de production peut être modifié directement », et que l’équipe exige plus tard une migration review. Si cette vieille mémoire reste active, l’agent finira par faire une suggestion risquée.

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

Obtenir -15 % →Pub

Le pilote a donc besoin d’actions de retrait : supprimer une mémoire, la marquer expirée, ré-extraire un projet ou vider un espace utilisateur. Sans ces gestes, la mémoire à long terme devient une dette.

Checklist de dépannage

Les problèmes d’un outil comme Mnemo vivent en général entre le service local, le backend de modèle et le retrieval. Vérifiez dans cet ordre :

• curl http://localhost:8080/health échoue : vérifiez si les conteneurs Docker tournent et si le port est déjà occupé.
• Ollama ne peut pas tirer le modèle : exécutez ollama list dans le conteneur et confirmez que le modèle existe ; prenez un modèle plus petit si le réseau est lent.
• Les appels API se bloquent : vérifiez que MNEMO_LLM_BASE_URL pointe vers un endpoint compatible OpenAI. Ollama écoute couramment sur 11434.
• La réponse ignore la mémoire : confirmez que ingest a réussi, puis inspectez le contexte de retrieval au lieu de juger seulement la réponse finale.
• La mémoire disparaît après redémarrage : vérifiez si le chemin de données SQLite est monté sur un volume persistant.
• Les résultats deviennent confus : réduisez le contexte récupéré, dédupliquez les entités et faites expirer les décisions de projet périmées.

Ces vérifications valent mieux que le bricolage de prompt. Un prompt peut changer la façon dont le modèle parle. Il ne peut pas réparer un service qui n’a jamais démarré ou un chemin de base qui disparaît avec le conteneur.

Lecture conseillée et un pilote sûr

Si vous n’avez pas encore exécuté de modèle local, commencez par le guide débutant Ollama. Une fois les appels de modèle stables, passez aux appels de l’API Ollama et aux embeddings Ollama. Mnemo s’inscrit après ces bases comme pilote de mémoire d’agent.

Un pilote de 7 jours peut rester petit :

1. Choisissez un projet, pas toute votre machine.
2. Écrivez 30 à 50 vraies mémoires sur le stack, les options rejetées, les erreurs courantes et les contraintes d’API.
3. Posez les mêmes 10 questions de rejeu chaque jour et notez le retrieval correct, manquant et erroné.
4. Supprimez ou expirez les mauvaises mémoires, puis vérifiez si la réponse suivante change.
5. Redémarrez le conteneur et la machine, puis confirmez que les mémoires restent.
6. Ajoutez les backups de base, les vérifications de permissions et le scan de secrets.
7. Décidez seulement alors si votre agent principal doit l’utiliser.

L’objectif utile de Mnemo est modeste : ramener un petit jeu de contexte important dans la prochaine tâche, tout en laissant les humains capables d’inspecter, éditer, sauvegarder et retirer ce contexte. Une fois cela acquis, un LLM local ressemble moins à une fenêtre de chat jetable et plus à un outil durable.