Wenn das Gedächtnis eines Agenten in kurze Codes gepresst wird: Einigen sich zwei KIs dann auf dieselbe falsche Antwort?

Das Paper

Ein Agent, der sich an frühere Gespräche erinnert, muss sie irgendwo ablegen und das richtige Stück schnell wiederfinden. FlyHash borgt sich etwas vom Geruchssinn der Fruchtfliege: Es verwandelt das Embedding jeder Erinnerung in einen kurzen, dünn besetzten Code, in dem nur wenige „aktive Bits“ eingeschaltet sind. Kurze Codes bedeuten ein kleines Gedächtnis.

Die Ergebnisse im Paper sind erfrischend nüchtern. Bei gleicher Codegröße ruft FlyHash die richtige Erinnerung etwa 2,5-mal so oft ab wie SimHash (0,27 gegen 0,11). Ist das Gedächtnis nicht knapp, schlägt ein gewöhnlicher HNSW-Index beide weiterhin, und die Autoren sagen das auch. Papers, die offen sagen, wo ihre Methode verliert, sind seltener, als sie sein sollten, und genau das hat uns bewogen, ihnen zu schreiben.

Der Code ist offen: github.com/mohanji/flyhash-agent-memory.

Wie das Gespräch verlief

Es begann in den Kommentaren unter dem Paper auf Hugging Face. Wir fragten, wie die Codes mit Fragen zurechtkommen, die umformuliert statt schablonenhaft gestellt sind. Mohan antwortete, die bisherigen Tests hätten schablonenhafte Formulierungen verwendet, und fragte, welchen Datensatz wir vorschlagen würden. Wir schlugen zwei vor, die aus langen, echten Dialogen über mehrere Sitzungen gebaut sind: LoCoMo und LongMemEval. Er entschied, mit LoCoMo zu beginnen und LongMemEval folgen zu lassen.

Dann stellten wir die Frage, die seine Arbeit mit unserer verbindet: Verlieren die kürzesten Codes bei Fragen zur Zeit („Wann ist sie umgezogen?“) mehr als bei einzelnen Fakten?

Warum das Gedächtnis für zwei sich gegenseitig prüfende KIs zählt

Wenn zwei Modelle verschiedener Firmen sich auf eine Antwort einigen, gilt das oft als gutes Zeichen. In einem Agenten lesen aber meist beide Modelle dieselbe abgerufene Erinnerung. Hat das Retrieval den Fakt verfehlt, sind sie nicht mehr unabhängig: Sie können sich selbstsicher auf dieselbe falsche Antwort einigen.

Um zu sehen, wie oft das vorkommt, haben wir einen kleinen offenen Check auf LoCoMo zusammengestellt, memory-agreement-check, und ihn einmal mit schlichtem Stichwort-Gedächtnis laufen lassen (BM25, die obersten 10 Dialogbeiträge). GPT und Claude antworteten getrennt, und Kimi bewertete sie blind.

Die Fehler der beiden Modelle waren stark korreliert (φ = 0,81). Das ist ein Retriever und ein Seed, es zeigt also einen Zusammenhang, keine Ursache. Aber es gibt FlyHash eine präzise Frage, die es beantworten kann.

Das Experiment, das wir gemeinsam durchführen

Mohan bot an, die Retrieval-Seite zu liefern; ab da übernehmen wir.

1. Mohan misst zuerst das Retrieval: Recall@k für jede LoCoMo-Kategorie (Single-Hop, Multi-Hop, zeitlich) bei mehreren FlyHash- und SimHash-Codegrößen, 16, 32, 64 und 128 aktive Bits, mit den obersten 10 Erinnerungen pro Frage, passend zum ersten Lauf.
2. Wir haben vorgeschlagen, auch die obersten 5 aufzunehmen: Weniger Erinnerungen heißt mehr Fehlgriffe, und das sollte zeigen, wie schnell der Anteil selbstsicher falscher, übereinstimmender Antworten wächst.
3. Er schickt die abgerufenen Kontexte als JSONL, eine Zeile pro Frage.
4. Wir lassen den Übereinstimmungs-Check auf jeder Datei laufen und schicken ihm die Ergebnisse.

Die Frage, die wir am Ende ablesen: Steigt mit kürzeren Codes der Anteil der Antworten, auf die sich beide KIs einigen und die falsch sind, und steigt er bei Fragen zur Zeit am schnellsten? Wenn ja, hat ein kleineres Gedächtnis versteckte Kosten, die eine Prüfung durch eine zweite KI nicht bemerkt. Wenn nicht, sieht FlyHash sogar besser aus, als das Paper sagt.

Der Code

Der Check nimmt die Ausgabe jedes beliebigen Retrievers. Eine Zeile pro Frage:

{"qid": "conv-26/0", "memories": [{"text": "[D1:3 | 1:56 pm on 8 May, 2023] Caroline: I went to a LGBTQ support group yesterday...", "dia_id": "D1:3", "score": 0.82}]}

Im Repository gibt es bereits ein Beispiel, das diese Kontexte mit den FlyHash- und SimHash-Klassen aus Mohans Code erzeugt:

git clone https://github.com/mohanji/flyhash-agent-memory
pip install numpy sentence-transformers
python examples/flyhash_contexts.py --flyhash-src flyhash-agent-memory/src \
  --method flyhash --active-bits 32 --out flyhash-k32.jsonl
python -m memcheck run --backend cli --contexts flyhash-k32.jsonl --memory-name flyhash-k32

Dieselben Fragen bei mehreren Codegrößen laufen zu lassen, oder gegen --method dense als Referenz, ergibt den Vergleich.

Was die ersten Zahlen sagen können und was nicht

• Sie stammen von einem Retriever (BM25), einem Modellpaar, einem Richter und einem Seed, bei 200 Fragen. Andere Retriever und Modelle können jede Zahl verschieben.
• Fragen, deren Belege BM25 verfehlt, unterscheiden sich von den übrigen (Multi-Hop- und Open-Domain-Fragen werden weit öfter verfehlt), deshalb wird der Vergleich auch innerhalb jeder Kategorie gemacht.
• Ein Kausaltest würde dieselben Fragen einmal mit und einmal ohne die Belegbeiträge beantworten. FlyHash bei mehreren Codegrößen ist ein natürlicher Schritt in diese Richtung: gleiche Fragen, gleiche Modelle, nur das Gedächtnis ändert sich.

Zeitverlauf

1. 4. November 2026FlyHash erscheint auf arXiv (2611.05791), von Mohan Bheemadolu und Chrisogonas O. Odhiambo.
2. 10. November 2026Das Paper erscheint bei Hugging Face Papers. In den Kommentaren fragen wir nach umformulierten Fragen; Mohan fragt, welchen Datensatz er nehmen soll; wir schlagen LoCoMo und LongMemEval vor, und er wählt zuerst LoCoMo.
3. 11. November 2026Wir fragen, ob kurze Codes bei Fragen zur Zeit mehr verlieren. Der offene Check läuft zum ersten Mal auf 200 LoCoMo-Fragen, mit einem Beispiel für FlyHash, und wir schicken Mohan die Zahlen.
4. 12. November 2026Mohan legt den Plan dar: Retrieval-Recall pro Kategorie bei 16, 32, 64 und 128 Bit mit k = 10, Kontexte als JSONL. Wir stimmen zu und ergänzen k = 5.