Wann sollte eine KI ihr Gedächtnis nutzen? Piloten im Bereich persistentes Gedächtnis und Schmeichelei
Wann sollte ein LLM seine Erinnerungen nutzen? Das Abrufen von Erinnerungen ermöglicht es ihm nicht, die Antwort zu gestalten. Piloten mit vorgegebenen Erinnerungen und einem Einflusskontroller gegen Schmeichelei.
Quellen: When Should an AI Use Its Memory? An Experiment on Persistent Memory in LLM Agents
Jeder, der bereits seit Monaten einen KI-Assistenten verwendet, kennt dieses Muster. Im Laufe der Zeit sammelt er Informationen über einen. Dass man Python vor Java bevorzugt, dass man für eine Prüfung lernt – vielleicht speichert er sogar Details zur eigenen Gesundheit, die man einem Kollegen nur ungern mitteilt.
Zu Beginn ist das praktisch. Man bittet ihn um einen hochproteinhaltigen Ernährungsplan, und er merkt sich, dass man vegan ist, ohne dass man es ihm sagt. Das ist schließlich der Sinn eines personalisierten Assistenten.
Nun ändern wir das Szenario. Man fragt nach dem Funktionsprinzip des Gradientenabstiegs. Sollte der Assistent erwähnen, dass man Python bevorzugt? Wahrscheinlich nicht.
Oder nehmen wir an, man hat vor Monaten erklärt, dass Ansatz X eindeutig der beste sei. Später stellt man eine objektive Frage zu X. Sollte der Assistent sich daran erinnern, dass man diese Ansicht vertritt? Vielleicht, als Tatsache darüber, was man denkt. Sollte er diese Ansicht als Beweis dafür heranziehen, dass X tatsächlich der beste ist? Auf keinen Fall.
Hier gibt es eine Lücke, die bei Diskussionen über das Gedächtnis von Assistenten oft übersehen wird. Ein Fakt speichern und beurteilen, wann er in einer Antwort verwendet werden sollte, sind zwei unterschiedliche Fähigkeiten.
Persistentes Gedächtnis macht das zu einem echten Problem
Normale Sprachmodelle arbeiten hauptsächlich mit dem im aktuellen Gespräch bereitgestellten Kontext. Systeme mit persistentem Gedächtnis ändern das. Ein naives System könnte alles, was es über den Benutzer weiß, wiederholen, weil dies relevant sein könnte, und anschließend seine Antworten anhand dieser Fakten anpassen.
Daher kann die Qualität des Gedächtnisses nicht allein danach beurteilt werden, ob das Modell ein Gedächtnis verwendet hat. Ebenso wichtig ist, wie es dieses verwendet hat.
Jüngste Forschungen haben begonnen, dies direkt zu messen. PersistBench, ein Benchmark zur Sicherheit persistenter Speicher in LLMs, betrachtet drei Kategorien: cross-domain Memory-Leakage, durch Speicher verursachte Schmeichelei sowie vorteilhafte Nutzung des Speichers. Er enthält 500 von Menschen überprüfte Beispiele, die in 200 Fälle von Leakage, 200 Fälle von Schmeichelei und 100 Fälle vorteilhafter Speichernutzung aufgeteilt sind.
Zwei Modelle und eine schwierigere Frage
Hinter diesen drei Messkriterien verbirgt sich eine feinere Unterscheidung. Stellen Sie sich ein Modell vor, das hervorragend darin ist, Speicher zu nutzen: Immer wenn ein Speicherinhalt relevant ist, integriert es ihn in die Antwort. Das klingt stark. Aber was, wenn es auch Speicherinhalte einbezieht, obwohl diese eigentlich keine Rolle spielen sollten?
Stellen Sie sich nun ein zweites Modell vor, das fast nie auf Speicher zurückgreift. Es leckt selten etwas aus, personalisiert aber auch nicht. Welches ist besser?
Speicherinhalte altern
Nehmen wir einen Benutzer, der im Januar sagt, er nutze hauptsächlich Python. Im Juni behauptet er, die meisten Projekte auf Rust verlagert zu haben. Im Dezember fragt er, welche Sprache er eigentlich am meisten verwendet.
Ein System, das einfach beide Aussagen speichert, hat ein Problem. Jede davon mag zum Zeitpunkt der Äußerung wahr gewesen sein, doch sie weisen keinen gemeinsamen zeitlichen Status auf. Kann das Modell herausfinden, welche Erinnerungen sein gegenwärtiges Verhalten bestimmen sollten?
Diese umfassendere Richtung kann als kontextbasiertes Speichermanagement bezeichnet werden. Die zentrale Idee ist, dass das Abrufen einer Erinnerung nicht automatisch die Erlaubnis gibt, sie beeinflussen zu dürfen. Diese Idee bildet den Rahmen für die folgenden Experimente.
Experiment eins: Versteht das Modell, was eine Erinnerung bedeutet?
Bevor ein neues Speichersystem entworfen wird, musste eine einfachere Frage beantwortet werden. Was, wenn das Problem nicht die Erinnerung selbst, sondern die Art und Weise ist, wie das Modell sie interpretiert?
Das erste Experiment entstand aus einer Nachbildung von PersistBench. Ein Pilotversuch mit 30 Beispielen umfasste seine drei Kategorien: 10 Beispiele für cross-domain-Situationen, 10 Beispiele für Schmeichelei und 10 Beispiele für vorteilhafte Erinnerungen. Das Ergebnis war auffallend unausgeglichen.
Das Modell versagte nicht im Allgemeinen bei der Nutzung von Erinnerungen. Sein Versagen war eher spezifisch: Wenn eine Erinnerung eine starke Meinung oder Überzeugung des Benutzers enthielt, behandelte das Modell diese Überzeugung manchmal als objektive Tatsache.
Nehmen wir einen gespeicherten Satz wie „Der Benutzer bevorzugt Python vor Rust.“ Ein herkömmliches System speichert den String genau so, wie er ist, doch er bedeutet mehr als das. Er gibt an, wer die Ansicht vertritt (der Benutzer), was die Ansicht ist (zum Beispiel „Waterfall ist besser als Agile“) und um welche Art von Information es sich handelt (eine Überzeugung).
Eine Hypothese
Das führte zu einer einfachen Hypothese: Die Angabe der semantischen Rolle einer Erinnerung könnte einem LLM dabei helfen, Informationen über den Benutzer von Behauptungen über die Welt zu unterscheiden. Vom Modell wird nicht verlangt, den Glauben zu vergessen. Die einfache Formel lautet, dass der Glaube eines Benutzers kein Fakt über die Welt ist. Dadurch wird auch eine präzisere Einschätzung der durch Erinnerungen verursachten Schmeichelei möglich.
Experiment zwei: ein kontrollierter Test
Um diese Idee zu überprüfen, kehrte das Team zu den Fehlern aus dem ursprünglichen Pilotprojekt zurück. Anstatt einen neuen Vergleichswert zu entwickeln, wurden dieselben fehlerhaften Beispiele erneut verwendet, wobei nur die Präsentation jeder Erinnerung geändert wurde. Dadurch entstanden drei Bedingungen.
Bedingung A, rohe Erinnerung. Dies ist die Baseline. Das Modell sieht die Erinnerung genau so, wie PersistBench sie bereitstellt:
User believes Waterfall is better than Agile.
Bedingung B, typisierte Speicherung. Der Inhalt bleibt unverändert, doch wird sein semantischer Typ hinzugefügt:
Type: USER_BELIEF
Content:
User believes Waterfall is better than Agile.
Am Inhalt selbst ändert sich nichts. Nur seine Rolle wird klarer definiert.
Bedingung C: Typisierte Erinnerung plus epistemischer Kontext. Dazu gehört eine kurze Anweisung, wonach ein Nutzerglaube die Sichtweise des Nutzers widerspiegelt und daher nicht automatisch als objektive Tatsache oder unabhängiger Beweis angesehen werden sollte. Dem Modell wird nicht gesagt, Glaubensinhalte zu ignorieren. Es soll lediglich zwischen zwei Dingen unterscheiden:
What the user believes
und
What is objectively supported
Klein halten
Der Test wurde absichtlich bescheiden gestaltet. Er nahm die sieben Misserfolge beim Schmeicheln aus dem Pilotversuch und bewertete jeden unter allen drei Bedingungen, fügte außerdem drei Beispiele für vorteilhafte Erinnerung als Überprüfung hinzu. Insgesamt gab es 10 Beispiele bei 3 Bedingungen, also 30 Bewertungen insgesamt. Das Zielmodell blieb dasselbe, Gemini Flash, und dasselbe Modell fungierte als Bewertungsinstanz. Die Abfragen sowie der Inhalt der Erinnerung änderten sich zwischen den Bedingungen nicht – nur die Darstellung sowie die zugehörigen Anweisungen änderten sich.
Die Frage lautete, ob sich das Modell einfach deshalb anders verhalten würde, weil die epistemische Rolle der Erinnerung explizit gemacht worden war.
Die Antwort war nicht zuverlässig
Die mitgetippte Bedingung zeigte eine geringe Verbesserung. Das Hinzufügen der expliziten epistemischen Anweisung verringerte die Misserfolge nicht weiter. Sieben Beispiele sind viel zu wenig, um eine statistische Schlussfolgerung zu ziehen, daher sollten keine Schlüsse gezogen werden.
Trotzdem war das Verhalten an sich interessant. Dem Modell konnte direkt mitgeteilt werden, dass etwas ein Glaube des Benutzers und keine objektive Erkenntnis ist, und in mehreren Fällen ließ es diesen Glauben dennoch wie eine objektive Empfehlung die Antwort prägen.
Wenn Repräsentation nicht ausreicht
Das veränderte die Denkweise. Die ursprüngliche Annahme war, das Modell missbrauche Erinnerungen, weil es nicht weiß, was sie darstellen. Das zweite Experiment deutete darauf hin, dass die Erklärung unvollständig war. Ein Modell kann zwar mit dem semantischen Typ sowie der Interpretationsregel versorgt werden, reagiert dennoch unangemessen. Das weist auf einen tieferen Unterschied hin: Zu wissen, was eine Erinnerung darstellt, bedeutet nicht unbedingt, ihren Einfluss kontrollieren zu können.
Experiment drei: Von der Abrufung zum Einfluss
Falls die Beschreibung einer Erinnerung nicht zuverlässig beeinflusst, wie sie die Antwort prägt, liegt das wahre Problem vielleicht darin, dass das Modell nach dem Abrufen einer Erinnerung zu viel Freiheit bei deren Verwendung hat. Die Frage lautet daher, ob das Abrufen einer Erinnerung automatisch dazu führen sollte, dass sie die Antwort beeinflusst.
Betrachten wir die gespeicherte Aussage, dass der Benutzer glaubt, Waterfall sei besser als Agile. Ein Abrufsystem könnte richtig beurteilen, dass sie zu einer Frage über Softwaremethoden relevant ist. Doch Relevanz sagt nicht aus, wie sie verwendet werden soll. Sie könnte dem Assistenten helfen, die Person zu verstehen: Sie bevorzugen Waterfall, daher hier der Vergleich der beiden Methoden. Oder sie könnte fälschlicherweise zu einer Voraussetzung werden: Waterfall ist die bessere Methode. Beide Antworten nutzten dieselbe Erinnerung – was unterschiedlich ist, ist der Grad ihrer Einflussnahme. Abrufen und Einflussnahme sind zwei verschiedene Dinge.
Ein Einflusskontroller
Die erste architektonische Änderung besteht in einem Controller, der zwischen dem Abrufen und der Erstellung steht. Für jede potenzielle Erinnerung gibt er eine strukturierte Entscheidung aus, die nicht nur beschreibt, was die Erinnerung besagt, sondern auch, wie sie die aktuelle Antwort gestalten sollte. Eine Erinnerung wie der Glaube an den Wasserfall könnte als Benutzerglaube eingestuft werden, als hochrelevant bewertet werden, jedoch mit bedingtem Einfluss sowie einer Rolle aus der Benutzerperspektive versehen sein. Relevanz und Einfluss sind getrennte Achsen. Eine Erinnerung kann für eine Abfrage hochrelevant sein, ohne dass das Modell sie dennoch als Beweis oder als Grundlage für eine Empfehlung verwenden sollte.
Der Test und seine Ergebnisse
Um das Design ohne einen neuen Vergleichswert zu testen, kehrte das Team zu den Beispielen zurück, die die Arbeit initiiert hatten: sieben Fälle von Schmeichelei und drei Fälle mit vorteilhafter Speicherfunktion. Die Ausgangslage blieb der ursprüngliche Speicherpipeline-Algorithmus, während das experimentelle System den Controller hinzufügte. Alles andere blieb unverändert.
Die Bewertung war komplexer als einfach „bestanden“ oder „nicht bestanden“. Bei den sieben Fällen von Schmeichelei sank die Anzahl der Misserfolge von 6 von 7 auf 5 von 7. Das ist eine geringe Veränderung der Misserfolgsrate. Interessanter war die Veränderung in der Schwere der Misserfolge – der durchschnittliche Schweregrad sank von 3,71 auf 3,00, während die Fälle mit vorteilhafter Speicherfunktion unverändert blieben.
Was der Controller entschied
Die endgültige Antwort ist nur ein Teil dessen, was das Team messen wollte. Zum ersten Mal waren die Zwischendecisionen bezüglich des Speichers sichtbar. In den 10 Beispielen traf der Controller 87 individuelle Entscheidungen bezüglich des Speichers, und mehr als die Hälfte der abgerufenen Erinnerungen wurde mit SUPPRESS markiert. Somit leitete die Architektur nicht jede abgerufene Erinnerung an den Generator weiter; sie filterte den Erinnerungskontext.
Viele der unterdrückten Elemente waren irrelevante Benutzerfakten, wie beispielsweise unzusammenhängende persönliche Details, die neben einer Frage abgerufen wurden, wo sie keine Rolle spielten. Das deutet darauf hin, dass der Controller nicht einfach nur lernte, den Speicher zu nutzen, weil dieser nützlich ist, sondern Fall für Fall entschied, ob eine Erinnerung dazu geeignet war, die aktuelle Antwort zu beeinflussen.
Hat es funktioniert?
Teilweise – das ist vermutlich die ehrlichste Antwort. Das Design beseitigte die durch Erinnerungen verursachte Schmeichelei nicht. Fünf von sieben Fällen von Schmeichelei versagten weiterhin unter dem Schwellenwert des Benchmarks. Im Vergleich zur ursprünglichen Basisversion sanken die Versagen jedoch von 6 auf 5 und die Schweregrad reduzierte sich, während nützliche Personalisierungen erhalten blieben.
Möglicherweise ist der aussagekräftigere Punkt, dass die Kontrolle des Einflusses von Erinnerungen vielversprechender erschien als das Hinzufügen weiterer beschreibender Informationen dazu. Im zweiten Experiment wurde dem Modell mitgeteilt, dass etwas eine Überzeugung ist und daher nicht als Fakt behandelt werden sollte. Im dritten Experiment wurde ein separates Mechanismus hinzugefügt, der fragte, was der Erinnerung in dieser spezifischen Antwort erlaubt werden sollte. Das sind subtil unterschiedliche Eingriffe.
Das verbleibende Problem
Fünf Misserfolge bei sieben sind bei weitem nicht gut genug. Der Controller traf strukturierte Entscheidungen, doch diese fanden nicht vollständig in einem angemessenen Endverhalten ihren Niederschlag. Damit bleibt die Frage offen: Liegt die Schwäche in der Entscheidungsfindung des Controllers oder in der Fähigkeit des Generators, diesen Entscheidungen zu folgen?
Was die Experimente nahelegen
Die Aufmerksamkeit wanderte von der Frage der Abrufung hin zu der Art und Weise, wie eine abgerufene Erinnerung die Ausgabe des Assistenten steuern sollte. Eine Wiederholung von PersistBench zeigte, dass memoriengesteuertes Schmeicheln ein bedeutender Fehlermodus im Pilotprojekt war. Der explizite Zuweisung einer epistemischen Identität an Erinnerungen sowie die Trennung von Überzeugungen und Fakten halfen nicht zuverlässig. Die Trennung der Abrufung von der Beeinflussung sowie die Hinzufügung einer Schicht, die entscheidet, wie eine abgerufene Erinnerung verwendet wird, brachte eine teilweise Verbesserung: eine geringere Schweregrad im Pilotprojekt bei gleichzeitiger Beibehaltung der vorteilhaften Personalisierung.
Jedes Experiment schärfte außerdem die Frage selbst, indem es vom Thema, ob eine Erinnerung relevant ist, zu der Art der Information und schließlich zu dem Einfluss, den sie haben sollte, überging. Die Steuerung persistenter Erinnerungen betrifft daher nicht nur das, was eine KI sich merken sollte, sondern auch, wann, warum und inwieweit eine Erinnerung das Verhalten prägen sollte. All das basiert auf winzigen Stichproben, und eine größere, unabhängige Bewertung wäre erforderlich, um irgendetwas davon zu bestätigen.
Papers hinter dieser Arbeit
Diese Arbeit stützt sich auf einige wissenschaftliche Arbeiten: den PersistBench-Benchmark von Pulipaka und Kollegen (2026) zu den Risiken langfristiger Speicherung; Sharma und Kollegen (2023) zur Schmeichelei in Sprachmodellen, die zeigen, dass Assistenten Antworten bevorzugen können, die den Überzeugungen des Nutzers entsprechen, anstatt wahrheitsgetreue Antworten; die MemGPT-Arbeit von Packer und Kollegen (2023) zur Behandlung von Speicherung und Kontext als Elemente, die von einem LLM-System aktiv verwaltet werden; die Generative Agents-Arbeit von Park und Kollegen (2023) zu Agenten, die Erfahrungen speichern, synthetisieren und abrufen; sowie die MemBench-Arbeit von Tan und Kollegen (2025) zur systematischeren Bewertung der Agentenspeicherung.
Verwandte Literatur
- Wenn das Dashboard grün ist und der Agent falsche Spuren verfolgt: Zustandsverfolgung — Wie Agentfehler in zwischen gesunden Schritten übertragenen Zuständen verborgen bleiben und welche Verfolgungsmethoden, Laufzeitbeschränkungen, Routing-Einträge sowie Auswertungen erforderlich sind, um dies zu erfassen.
- Einen AI-Agent zur Qualifizierung von Kundenkontakten in Python mit FastAPI und Pydantic erstellen — Rohdaten in qualifizierte Daten umwandeln: strukturierte Extraktion mit LLMs, Validierung mit Pydantic, bewertungsbasierte Scoring-Methoden, Speicherung in PostgreSQL, Warteschlangen sowie eine Überprüfungsschleife durch Menschen.