MEMA und Continual Learning: drei Arten von KI-Memory

„Memory“ kann in einem KI-System drei verschiedene Mechanismen bezeichnen. Werden sie vermischt, klingt ein Kontextfenster plötzlich wie Lernen, ein LLM-Aufruf zur Extraktion wie Modelltraining und experimentelle neuronale Anpassung wie eine auditierbare Datenbank. Keine dieser Gleichsetzungen hält stand.

Für MEMA ist die nützliche Grenze konkret: Session-/Kontext-Memory, externe explizite Records und modellinternes Continual Learning unterscheiden sich bei Zustand, Evidenz und Löschbarkeit.

Grenze 1: Session- und Kontext-Memory

Session-Memory ist die Information, die einem Modell während eines Aufrufs zur Verfügung steht: der aktuelle Prompt, frühere Nachrichten, die noch hineinpassen, Tool-Ergebnisse und abgerufene Passagen, die in den Kontext eingefügt wurden. Das kann eine Interaktion kontinuierlich wirken lassen. Das Modell erwirbt dadurch jedoch keinen dauerhaften Fakt und keine dauerhafte Fähigkeit.

Fehlt die Information in einer späteren Anfrage, steht sie dem Modell womöglich nicht mehr zur Verfügung. Eine Anwendung kann den Kontext aus einem Gesprächsprotokoll oder externen Speicher neu aufbauen. Diese Persistenz gehört dann zur Anwendung. Andere Tokens als Input verändern noch keine gelernten Modellparameter.

Grenze 2: externe, explizite MEMA-Records

MEMA hält Memory ausserhalb des Modells als explizite Records mit Lifecycle-, Retrieval-, Provenienz-, Policy- und Audit-Oberflächen. Ausgewählte Records können in den Modellkontext gelangen, während der Quelldatensatz separat adressierbar und steuerbar bleibt. Damit werden Korrektur, Ablösung, Aufbewahrung und Löschen auf der Datenebene sichtbar.

Diese Sichtbarkeit hat eine Grenze: Ein Hash kann zeigen, ob Bytes von den zuvor gehashten Bytes abweichen. Er kann nicht zeigen, dass eine Behauptung wahr ist. Ein Freigabestatus dokumentiert einen Prozessentscheid; er macht aus einer Extraktion keine Ground Truth. Integrität ist keine Wahrheit. Evidenzqualität und Policy-Entscheide müssen weiterhin für sich bewertet werden.

Dabei ist der aktuelle Versionsstand entscheidend:

• Öffentlich prüfbar ist MEMA Package 2.22.13 bei Commit c37dbf7.
• Intern verifiziert ist v2.26.0 bei Commit d542fba. Dieser Stand ist nicht öffentlich verfügbar.
• Für keinen der beiden Stände behauptet die Website Produktionsreife.

Die Seite MEMA Evidenz- und Release-Status trennt öffentlichen Source, interne Implementierung, Experimente, Roadmap und Aussagen zur Produktionsreife.

Was /v2/observe tatsächlich macht

Im öffentlichen Stand ruft /v2/observe standardmässig einen LLM-Extraktor auf. Der automatische Pfad filtert die extrahierten Fakten und Entitäten und speichert die Ergebnisse danach mit Status „freigegeben“. Für andere untrusted Producers gibt es separate Draft- und Freigabe-Endpunkte.

Das ist eine Inferenz- und External-Record-Pipeline, kein Training von Modellgewichten. Der Extraktor erzeugt strukturierte Ausgaben; MEMA wendet Anwendungslogik an und schreibt Records ausserhalb des Modells. Die Gewichte des LLM werden durch diese Operation nicht aktualisiert. „Freigegeben“ beschreibt, wie der automatische Pfad ein gefiltertes Ergebnis speichert, nicht eine unabhängige Garantie seiner sachlichen Richtigkeit.

Grenze 3: modellinternes Continual Learning

Continual Learning verändert gelernten Zustand, wenn neue Daten eintreffen, und versucht dabei, nützliche frühere Fähigkeiten zu erhalten. Dieser Zustand kann in Modellparametern, optimiererähnlichem Memory oder adaptiven neuronalen Modulen liegen. Das unterscheidet sich vom Hinzufügen von Text zu einem Prompt und vom Schreiben eines menschenlesbaren externen Records.

Google Researchs Einführung in Nested Learning beschreibt ein Modell als verschachtelte oder parallele Optimierungsprobleme mit je eigenem Context Flow und eigener Update-Frequenz. Das zugehörige arXiv-v1-Paper und die Publikation der NeurIPS 2025 beschreiben die Arbeit. Das NeurIPS-Abstract führt drei Kernbeiträge auf: Deep Optimizers, ein selbstmodifizierendes Sequenzmodell und ein Continuum Memory System. HOPE ist die Architektur, die das selbstmodifizierende Sequenzmodell mit dem Continuum Memory System kombiniert; Deep Optimizers sind ein separater Beitrag und kein Bestandteil dieser Kombination.

Die Autoren berichten vielversprechende Resultate bei Sprachmodellierung, Continual Learning, Knowledge Incorporation und Long-Context-Aufgaben. Google bezeichnet HOPE als Proof-of-Concept-Architektur. Das ist Forschungsevidenz für die vorgeschlagene Architektur, kein Beleg dafür, dass HOPE eine Produktionskomponente von MEMA ist.

Die vorgeschlagene MEMA–HOPE-Grenze

Eine kontrollierte MEMA–HOPE-Integration ist geplante Architektur, keine ausgelieferte Funktion. Weder der öffentliche Stand 2.22.13/c37dbf7 noch der intern verifizierte Stand v2.26.0/d542fba enthält eine HOPE-Runtime.

Der Vorschlag hält MEMA als explizites System of Record und setzt ein künftiges HOPE-Modul hinter eine enge Schnittstelle:

1. Optional und standardmässig deaktiviert. Ein neuronales Continual-Learning-Modul zu aktivieren, braucht einen expliziten Deployment-Entscheid.
2. Zunächst im Shadow Mode. Das Modul darf Evaluationsausgaben erzeugen, beeinflusst aber während der Prüfung der Grenze weder gespeicherte Records noch Retrieval-Ergebnisse.
3. Untrusted und begrenzt. HOPE darf Record-Kandidaten oder begrenzte Ranking-Signale vorschlagen. Der Einfluss eines Scores ist gedeckelt und seine Provenienz wird erfasst; er ist kein Autorisierungsentscheid.
4. Keine Umgehung der Kontrollen. HOPE-Ausgaben dürfen Policy, Evidenzanforderungen, Freigabe, Löschbehandlung oder Audit nicht umgehen. Die Übernahme in einen autoritativen Record bleibt eine explizite MEMA-Operation.
5. Verwerfbarer abgeleiteter Zustand. Modellinterner Zustand wird nicht menschenlesbar oder einzeln löschbar, nur weil MEMA ihn umgibt. Eine künftige Integration braucht Regeln zum Zurücksetzen, Verwerfen oder Neuaufbauen abgeleiteten neuronalen Zustands und darf dort keine Löschung auf Record-Ebene behaupten.

Diese Einschränkungen gehören zum Architekturvorschlag. Implementierung und Betriebsnachweise dafür existieren in den genannten MEMA-Ständen nicht, und Produktionsreife wird nicht behauptet.

Ein praktischer Test für jede „Memory“-Aussage

Vor dem Vergleich von Systemen helfen vier Fragen:

• Wo liegt der Zustand: im aktiven Kontext, in einem externen Record oder im gelernten internen Zustand?
• Führt die Operation Inferenz aus, schreibt sie Daten oder aktualisiert sie Parameter?
• Kann ein Mensch den autoritativen Record prüfen, korrigieren, ablösen und löschen?
• Welche Version und welche Evidenz stützen die Aussage?

Diese Fragen verhindern, dass nützliche Ideen überverkauft werden. Kontext kann eine Session stützen. MEMA kann explizite Records steuern. Continual-Learning-Forschung kann adaptiven internen Zustand untersuchen. Eine künftige Integration kann diese Mechanismen verbinden, muss aber die Grenze zwischen Modellsignal und auditierbarem Entscheid erhalten.