Mnemo als lokale Memory-Schicht: portables Gedächtnis für Ollama und eigene LLM-Apps

Suchen nach Mnemo kommen meist aus einem praktischen Schmerz, nicht aus Neugier auf noch ein lokales LLM-Tool. Vielleicht läuft Ollama bei Ihnen schon. Vielleicht rufen Sie ein lokales Modell schon über eine OpenAI-kompatible API auf. Der unangenehme Teil kommt danach: Nach dem Ende der Sitzung verliert das Modell Projektentscheidungen, Nutzerpräferenzen, API-Einschränkungen und die Debugging-Notiz von gestern. Sie können dieses Material immer wieder in den Prompt kopieren, aber der Prompt wird länger, und veraltete Informationen geraten in Konflikt mit aktuellen.

Mnemo sitzt in dieser Lücke. Es hält Langzeitgedächtnis auf Ihrer eigenen Maschine, speichert Entitäten und Chunks über SQLite und Graph-Beziehungen und gibt den abgerufenen Kontext dann an Ollama, OpenAI, Anthropic oder ein anderes kompatibles Backend zurück. Es gibt dem Modell kein natives Gedächtnis und ist keine universelle Wissensdatenbank. Behandeln Sie es als lokalen Memory-Service, den Sie ersetzen, sichern, prüfen und zurückrollen können.

Welche Gedächtnis-Schicht Mnemo abdeckt

Die meisten lokalen LLM-Workflows haben drei Schichten: Das Modell generiert, die Anwendung koordiniert den Ablauf, und die Memory-Schicht holt nützliche Informationen sitzungsübergreifend zurück. Ollama deckt die erste Schicht ab, indem es Modelle lokal ausführt. RAG beantwortet meist „Welche Dokument-Chunks ähneln dieser Frage?”. Mnemo zielt auf die kleinere sitzungsübergreifende Schicht.

Ein lokaler Coding-Assistent ist ein gutes Beispiel. Heute sagen Sie ihm: „Dieses Projekt nutzt vorerst kein LangChain; halte die API-Schicht auf FastAPI und SQLite.” Morgen starten Sie eine neue Sitzung und fragen, wie man Retrieval ergänzt. Ein nützlicher Assistent sollte diese Entscheidung wiederherstellen, statt einen völlig anderen Stack vorzuschlagen.

Damit passt Mnemo besser, nachdem die Grundlagen stehen, etwa das Aufrufen der Ollama-API. Bringen Sie das Modell zuerst zu zuverlässigen Antworten. Entscheiden Sie dann, welche Informationen es wert sind, Memory zu werden. Die umgekehrte Reihenfolge macht aus einer fragilen Demo eine schwer zu debuggende Zustandsmaschine.

Architektur: Rust-API, SQLite und Graph-Traversal

Die Mnemo-README teilt das Repository in vier Rust-Crates. mnemo-core besitzt Entity-Extraktion, Graph-Operationen, Retrieval und die Datenbankschicht. mnemo-api stellt eine Axum-REST-API bereit. mnemo-cli ist der Kommandozeilen-Client. mnemo-bench enthält die Benchmark-Suites. Für ein lokales Tool ist diese Struktur wichtig, denn sie zeigt, dass das Projekt mehr ist als ein Prompt, der alte Gespräche zusammenfasst.

SQLite speichert den Status, Graph-Links liefern Hinweise

Viele Memory-Tools chunken jede Gesprächsrunde, erzeugen Embeddings und rufen nach Ähnlichkeit ab. Das funktioniert für manche Aufgaben, aber zwei Probleme tauchen schnell auf. Dieselbe Person, dasselbe Projekt oder dieselbe Entscheidung kann in mehreren Sitzungen erscheinen. Zwei Fakten können in Konflikt stehen, und Vektorähnlichkeit entscheidet nicht, welcher gewinnen soll.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Mnemos öffentliche Beschreibung legt mehr Gewicht auf Entity-Deduplication und Graph-first-Retrieval. In der Praxis extrahiert es Entitäten aus Text, verschmilzt sie mit vorhandenen Entitäten und nutzt Beziehungs-Edges beim Retrieval. Tauchen „API gateway”, „auth middleware” und „FastAPI service” in verschiedenen Sitzungen auf, kann der Graph sie verbinden, wenn Sie später nach dem System fragen.

Graph-Expansion braucht dennoch eine Leine. Die README sagt, graph-expandierte Ergebnisse nehmen mit niedrigerer Bewertung teil, sodass direkte Treffer vor abgeleitetem Kontext ranken. Ein nützlicher Kompromiss: Graph-Links sollen Hinweise einbringen, nicht die Evidenz begraben, die direkt zur Anfrage passte.

Benchmark-Zahlen als Projektmessungen behandeln

Die README-Benchmark-Tabelle ist konkret: Apple M2, SQLite WAL, In-Memory-petgraph und eine Debug-Build-Retrieval-Pipeline um 4,2 ms, mit dem Hinweis, dass Release-Builds schneller sind. Das zeigt, dass der lokale Pfad gemessen wurde. Es beweist nicht, dass Ihr Setup sich genauso verhält. Ihr Ergebnis hängt von Datenvolumen, Extraktionsaufrufen, Festplattengeschwindigkeit, Modell-Backend und Retrieval-Policy ab.

Ich würde vor der Latenz drei Dinge beobachten: ob geschriebene Memories abspielbar sind, ob abgerufene Ergebnisse ihre Quelle erklären und ob falsche Memories gelöscht oder korrigiert werden können. Langsamer Code lässt sich oft optimieren. Eine falsche Memory ohne Quelle ist viel schwerer zu vertrauen.

Den kleinsten Docker-+-Ollama-Pfad fahren

Binden Sie Mnemo am ersten Tag nicht an Ihr Hauptprojekt. Nutzen Sie einen temporären Ordner, folgen Sie der Docker-+-Ollama-Route in der Upstream-README und entscheiden Sie später, ob es in Ihre Anwendung gehört.

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

# Beim ersten Mal das README-Beispielmodell ziehen
docker exec mnemo-ollama ollama pull llama3

# Den API-Service prüfen
curl http://localhost:8080/health

Wenn Sie den Ollama-Einsteiger-Leitfaden schon durchgearbeitet haben, kommt Ihnen dieser Ablauf bekannt vor. Der Unterschied: Mnemo startet neben dem Ollama-Container eine Memory-API. Später spricht Ihre App mit dem Memory-Service, statt jede vergangene Entscheidung in den Modellkontext zu stopfen.

Mit dem Python-SDK einen Smoke-Test machen

Die README gibt auch einen winzigen Python-SDK-Pfad. Er testet eine Sache: eine Memory schreiben, dann mit natürlicher Sprache fragen und sehen, ob sie zurückkommt.

from mnemo import MnemoClient

client = MnemoClient()

client.ingest("Ich baue eine Rust-Vektordatenbank namens vecdb")
print(client.get_context("An welchem Datenbankprojekt arbeite ich gerade?"))

Beurteilen Sie dabei nicht nur die finale Modellantwort. Prüfen Sie Service-Logs, Datenbankdateien, die Struktur der API-Antwort und ob die Memory einen Neustart übersteht. Die Mindestschwelle für Langzeitgedächtnis ist keine schöne Formulierung. Es ist dauerhafter, prüfbarer, wiederherstellbarer Status.

Der Binary-Pfad passt, wenn Ollama schon läuft

Läuft Ollama bereits auf Ihrer Maschine, beschreibt die README auch eine Binary-Route:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

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

Dieser Pfad passt zu einem bestehenden lokalen LLM-Setup. Behalten Sie Ihre eigenen Modelle, Ports und Ihr Monitoring und binden Sie Mnemo als separaten Service an. Wenn Sie später auf ein Cloud-Backend wechseln, konfigurieren Sie stattdessen eine OpenAI-kompatible Base-URL, einen API-Key, ein Modell und einen Provider.

Vor der Einführung die Passung prüfen

Die Mnemo-README gibt eine nützliche Grenze: Wenn Sie bereits ein Managed-Agent-Harness nutzen, das Gedächtnis gut handhabt, brauchen Sie Mnemo vielleicht nicht. Diese Warnung zählt. Mehr Memory-Schichten können mehr versteckten Status bedeuten.

Local-first hat einen klaren Vorteil: Die Daten bleiben auf Ihrer Maschine, die SQLite-Datei ist leicht zu sichern, und Sie müssen nicht jedes Projektgespräch an einen Cloud-Service senden. Sicherheitsarbeit bleibt nötig. Entscheiden Sie, wer die Datenbank lesen darf, wo Backups liegen, ob Logs API-Keys enthalten und wie falsche Memories entfernt werden.

Drei Leitplanken für die Memory-Schicht

Langzeitgedächtnis ist nur nützlich, solange es steuerbar bleibt. Bevor ich Mnemo an einen echten Agenten anbinde, würde ich drei Regeln ins Projekt selbst schreiben.

Jede Memory braucht eine Quelle

Eine Memory sollte nicht als einsamer Zusammenfassungssatz enden. Sie sollte auf ein Gespräch, eine Datei, einen Task oder ein API-Ergebnis verweisen. Sagt ein Agent „Dieses Projekt nutzt FastAPI”, sollten Sie nachvollziehen können, woher diese Behauptung stammt.

Das ist auch die Hauptlektion aus dem früheren Leitfaden zum KI-Agent-Gedächtnis. Langzeitgedächtnis ist keine größere Zwischenablage. Ohne Quelle, Zeit und Gültigkeit ziehen alte Schlussfolgerungen neue Kleider an.

Abgerufener Kontext braucht ein Budget

Ein schneller lokaler Service sollte trotzdem eine kleine Menge Evidenz zurückgeben. Für viele Aufgaben reichen 5 bis 15 hochrelevante Memories mit Quellenhinweisen. Braucht das Modell mehr, lassen Sie es erneut anfragen, statt Dutzende möglicherweise verwandter Notizen in den Prompt zu drücken.

Das hält Context-Rot niedrig. Agenten scheitern oft mit reichlich Material in der Hand, weil das Material veraltet, dupliziert oder widersprüchlich ist. Die Memory-Schicht sollte filtern, bevor der Prompt wächst.

Falsche Memories brauchen einen Rückzugspfad

Die gefährlichste Memory ist falsch, nicht fehlend. Angenommen, das Modell speicherte einmal „Produktions-Schema kann direkt geändert werden”, und das Team verlangt später ein Migration-Review. Bleibt diese alte Memory aktiv, macht der Agent irgendwann einen riskanten Vorschlag.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget ➡️

Jetzt testen →Anzeige

Der Pilot braucht also Rückzugsaktionen: eine Memory löschen, als abgelaufen markieren, ein Projekt neu extrahieren oder einen Nutzer-Space leeren. Ohne diese Schritte wird Langzeitgedächtnis zu Schulden.

Checkliste zur Fehlersuche

Probleme mit einem Tool wie Mnemo liegen meist zwischen lokalem Service, Modell-Backend und Retrieval. Prüfen Sie in dieser Reihenfolge:

• curl http://localhost:8080/health schlägt fehl: prüfen, ob die Docker-Container laufen und ob der Port bereits belegt ist.
• Ollama kann das Modell nicht ziehen: im Container ollama list ausführen und bestätigen, dass das Modell existiert; bei langsamem Netz ein kleineres Modell nehmen.
• API-Aufrufe hängen: prüfen, ob MNEMO_LLM_BASE_URL auf einen OpenAI-kompatiblen Endpoint zeigt. Ollama lauscht üblicherweise auf 11434.
• Die Antwort ignoriert die Memory: bestätigen, dass ingest erfolgreich war, dann den Retrieval-Kontext prüfen, statt nur die finale Antwort zu beurteilen.
• Memory verschwindet nach Neustart: prüfen, ob der SQLite-Datenpfad auf ein persistentes Volume gemountet ist.
• Ergebnisse werden unübersichtlich: abgerufenen Kontext reduzieren, Entitäten deduplizieren und veraltete Projektentscheidungen ablaufen lassen.

Diese Checks schlagen Prompt-Basteln. Ein Prompt kann ändern, wie das Modell spricht. Er kann keinen Service reparieren, der nie startete, oder einen Datenbankpfad, der mit dem Container verschwindet.

Empfohlene Lektüre und ein sicherer Pilot

Wenn Sie noch kein lokales Modell betrieben haben, beginnen Sie mit dem Ollama-Einsteiger-Leitfaden. Sind Modellaufrufe stabil, gehen Sie weiter zu Ollama-API-Aufrufen und Ollama-Embeddings. Mnemo passt nach diesen Grundlagen als Agent-Memory-Pilot.

Ein 7-Tage-Pilot kann klein bleiben:

1. Wählen Sie ein Projekt, nicht Ihre ganze Maschine.
2. Schreiben Sie 30 bis 50 echte Memories über Stack, verworfene Optionen, häufige Fehler und API-Einschränkungen.
3. Stellen Sie täglich dieselben 10 Wiederhol-Fragen und notieren Sie korrekten, fehlenden und falschen Recall.
4. Löschen Sie falsche Memories oder lassen Sie sie ablaufen, dann prüfen Sie, ob sich die nächste Antwort ändert.
5. Starten Sie Container und Maschine neu, dann bestätigen Sie, dass die Memories bleiben.
6. Ergänzen Sie Datenbank-Backups, Berechtigungsprüfungen und Secret-Scanning.
7. Entscheiden Sie erst dann, ob Ihr Haupt-Agent es nutzen soll.

Mnemos nützliches Ziel ist bescheiden: eine kleine Menge wichtigen Kontexts in die nächste Aufgabe zurückbringen, während Menschen diesen Kontext weiterhin prüfen, bearbeiten, sichern und zurückziehen können. Sobald das gelingt, fühlt sich ein lokales LLM weniger wie ein Wegwerf-Chatfenster an und mehr wie ein nachhaltiges Werkzeug.