Memory Drift reparieren, wenn das Gedächtnis kippt

Irgendwann passiert es jedem der Memory ernsthaft nutzt. Du fragst die KI etwas und kriegst zwei Antworten in einer Session. Sie sagt im einen Satz "Du nutzt Postgres" und im nächsten "Du nutzt Supabase". Beides war mal wahr, jetzt verwirrt es nur. Das ist Memory Drift. Symptome sind subtil am Anfang, werden mit der Zeit aggressiver, und irgendwann ist das Gedächtnis so durchsetzt mit alten Stellungnahmen dass die KI mehr halluziniert als hilft.

Dieses Playbook ist der Werkzeugkasten für den Tag an dem Du merkst, das Memory ist kaputt. Wir gehen Schritt für Schritt durch Diagnose, Cleanup und Verifikation. Anders als die Memory-Hygiene-Routine (L4-09) ist das hier kein Wartungsritual sondern Notfall-Reparatur. Eine Stunde bis 90 Minuten, dann steht das Gedächtnis wieder.

1. Drift erkennen, drei Symptome

Bevor Du an Tools gehst, frag Dich ob die Symptome wirklich Memory sind und nicht Modell-Schwankung. Drei klare Signale.

Erstens, die KI zitiert Fakten die nicht mehr stimmen. Du hast vor sechs Monaten "Wir nutzen MySQL" gesagt, dann auf Postgres migriert, beides steht im Memory, sie wählt zufällig. Zweitens, sie gibt sich widersprüchliche Namen für dasselbe Ding. "Aklow Memory" und "StudioMeyer Memory" sind in Deinem Knowledge Graph zwei separate Entities obwohl es das gleiche Produkt ist. Drittens, sie macht Vorschläge die Du explizit verworfen hast. Lodash zum Beispiel, weil Du im Mai gesagt hast nimm vanilla, im Juli hast Du es vergessen und kurz lodash benutzt, jetzt ist beides als "User-Preference" gespeichert.

Wenn Du zwei dieser drei siehst, ist Drift da. Zeit für Diagnose.

2. Inventar ziehen, Schaden quantifizieren

Bevor Du irgendwas löschst, schau wie schlimm es wirklich ist. nex_contradictions(action: "stats") ist der Einstieg. Das gibt Dir die Zahl der gefundenen Widersprüche, sortiert nach Status.

Pi mal Daumen: unter 10 offenen Widersprüchen ist normaler Verschleiss, 10 bis 50 ist Wartungs-Backlog, über 50 ist akuter Drift. Wenn pending oder unresolved über 50 steht, weiter mit diesem Playbook. Wenn unter 10, Du brauchst nur die Routine aus L4-09.

Schreib die Zahl auf. Du brauchst sie am Ende für den Vorher-Nachher-Vergleich.

3. Widersprüche listen und gruppieren

nex_contradictions(action: "pending") zieht die offene Liste. Schau Dir die ersten 20 an, nicht alle.

Was Du suchst sind Cluster. Gleiche Entity, mehrere Versionen. "Datenbank-Wahl" wird mit hoher Wahrscheinlichkeit zehn Mal auftauchen, weil jede Migration eine neue Aussage gemacht hat. Wenn Du ein Cluster erkennst, hast Du das eigentliche Problem identifiziert. Einzeln betrachtet sehen die Widersprüche aus wie Zufall, im Cluster ist klar dass eine Entity über Monate verfilzt wurde.

Notier Dir die Top drei Cluster. Die kriegen gleich Sonderbehandlung, der Rest geht in Auto-Resolve.

4. Stale Observations identifizieren

Widersprüche sind eine Art Drift, alte unbenutzte Facts sind die andere. nex_consolidate(action: "cleanup_stale_obs", dryRun: true) zeigt Dir Observations mit Confidence unter 0.5 die älter als 30 Tage sind. Default-Filter, gut für den Einstieg.

Lies das Output sorgfältig. Wenn matched über 50 Prozent von scanned ist, der Server hat Dich vor dem realen Cleanup geblockt. Das ist gewollt, sonst löschst Du Dir versehentlich die halbe Datenbank weg.

Prüf in dem Fall ob der Filter zu breit war. Vielleicht ist maxAgeDays: 30 zu jung für Deinen Workflow, hoch auf 60 oder 90. Vielleicht ist maxConfidence: 0.5 zu locker, runter auf 0.3.

5. Dry-Run lesen, nicht überlesen

Das Dry-Run-Output zeigt Dir Beispiele der Treffer. Lies fünf bis zehn davon manuell. Frag Dich pro Treffer, ist das wirklich obsolet?

Wenn Du Treffer siehst die nicht weg sollen ("vom 15. Januar, MeetMyAgent Tech-Stack ist Next.js 16"), ist Dein Filter falsch und Du musst zurück zu Schritt 4. Wenn die Treffer aussehen wie Müll ("vom 3. Februar, Test-Eintrag, foo bar"), Filter ist gut und Du gehst zu Schritt 6.

Niemals Schritt 5 überspringen. Cleanup ohne Dry-Run-Review ist wie rm -rf ohne --preview.

6. Cleanup ausführen

Wenn das Dry-Run gut aussah, dasselbe Kommando mit dryRun: false. Der Server invalidiert die Observations soft (setzt valid_to), löscht nicht hart. Heisst, Du kannst notfalls per SQL zurückholen.

Falls Du beim Dry-Run einen Bulk-Block gesehen hast (matched über 50 Prozent scanned) und sicher bist es ist gewollt, füge force: true dazu. Mach das nur wenn Du verstehst warum die Schutz-Schwelle ausgeschlagen hat. Force ohne Verständnis führt regelmässig zu Memory-Wipes nach denen die KI plötzlich nichts mehr über Dich weiss.

Schreib auf wieviele Observations invalidiert wurden. Zweite Zahl für den Vorher-Nachher-Vergleich.

7. Duplikate mergen

Drift produziert oft Duplikate. "StudioMeyer Memory" und "studiomeyer-memory-server" sind technisch zwei Entities, faktisch eine. nex_deduplicate(action: "scan", autoMergeThreshold: 0.85) findet die hoch-konfidenten Duplikate und merged sie automatisch.

Default-Threshold ist 0.85, das fasst nur enge Matches. Für aggressivere Säuberung kannst Du auf 0.75 runter, dann werden mehr Paare auto-merged aber das Risiko von Falsch-Merges steigt. Persönliche Empfehlung, bleib bei 0.85 und merge die Restlichen manuell mit nex_entity_merge.

Merge-Operationen sind reversibel über nex_entity_history falls Du einen Fehler machst, aber nur in den ersten Sekunden bevor Caches greifen. Vorsicht.

8. Confidence-Decay laufen lassen

Drift kommt auch davon dass alte Aussagen das gleiche Vertrauen geniessen wie frische. Decay löst das. nex_decay(action: "run") reduziert Confidence auf Observations die lange nicht abgerufen wurden.

Gut zu wissen, Decay ist nicht destruktiv. Er ändert nur die Sortierung. Eine Observation mit gesunkener Confidence taucht später im Retrieval auf, wird aber nicht gelöscht. Bei wiederholtem Abruf steigt die Confidence wieder.

Für akuten Drift einmal ausführen, dann monatlich. Die monatliche Routine ist L4-09.

9. Always-On-Switch verifizieren

Nach dem Cleanup prüfst Du ob die KI das neue Memory tatsächlich liest. Sonst hast Du sauber gemacht und keiner merkt es.

Frische Session öffnen, Tool das Du nicht erwähnen willst. Eine projekt-spezifische Frage stellen, ohne Hinweis dass Du Memory hast. "Welche Datenbank nutze ich für Projekt X?" Wenn die Antwort konkret ist und stimmt, der Always-On-Switch läuft. Wenn die KI rumlaviert oder allgemeine Antworten gibt, ist der Switch deaktiviert.

Reparatur, nex_profile(action: "save") schreibt einen Snapshot ins Auto-Context, der wird in jeder neuen Session geladen. Danach gleiche Frage in neuer Session, sollte jetzt sitzen.

10. Pattern speichern, damit es nicht wiederkommt

Letzter Schritt, der wichtigste. Schreib auf was die Drift verursacht hat. Drei Sätze reichen.

Zum Beispiel: "Drift kam durch DB-Migration im März, alte MySQL-Aussagen blieben als Truth-Source neben neuen Postgres-Aussagen. Auflösung war Migration explizit als Decision speichern und alte invalidieren. Vorbeugung, bei jeder Architektur-Entscheidung den vorherigen Stand explizit als invalidiert markieren."

Speicher das als Learning mit Kategorie mistake und Tag memory-drift. Compound-Effekt, in einem Jahr hast Du fünf bis zehn solcher Entries und der nächste Drift wird frühzeitig erkannt.

Vergleich jetzt die Zahlen aus Schritt 2 (Widersprüche) und Schritt 6 (Stale Observations) mit den aktuellen Werten. Wenn Widersprüche unter 10 sind und Stale-Quote unter 5 Prozent, das Memory ist repariert. Wenn nicht, Loop zurück zu Schritt 3 mit feinerer Filter-Einstellung.

Was als nächstes

Drift wieder vermeiden ist L4-09, die wartungs-orientierte Memory-Hygiene-Lesson. Wenn Du das Memory über mehrere AI-Tools synchron halten willst, Playbook "memory-portabel-nutzen". Für die Frage warum Memory überhaupt sinnvoll ist und was passiert wenn man es nicht hat, L4-01 "warum-memory".