DataQubeDataQube
Blog

Kontext-Kompaktierung ohne Amnesie

Jede lange KI-Untersuchung wächst über das Kontextfenster hinaus - die ehrliche Frage ist, was dann passiert. Wie DataQube den Arbeitskontext des Modells vom append-only Protokoll trennt, Kompaktierung zu einem sichtbaren Event macht und kompaktierte Threads voll auditierbar hält.

E
Engineering
DataQube · 18. Juni 2026 · 6 Min. Lesezeit
Engineering

Jeder Agent, der echte analytische Arbeit leistet, trifft irgendwann auf dieselbe Wand: Die Untersuchung ist länger als das Kontextfenster. Eine Antwort an die Aufsicht, die sich über drei Wochen, vierzig Queries, ein Dutzend revidierter Annahmen und zwei Komitee-Umwege erstreckt, passt in keinen Modellkontext - heute nicht, und nächstes Jahr auch nicht, denn Untersuchungen wachsen in jeden Raum hinein, den man ihnen gibt.

Was Agent-Plattformen unterscheidet, ist nicht, ob sie diese Wand treffen. Sondern was sie dort tun - und die zwei Standardantworten der Branche sind beide leise unehrlich. Die erste ist stilles Abschneiden: die ältesten Züge verwerfen und hoffen, dass dort nichts Wichtiges lag - Amnesie, verabreicht, ohne es dem Patienten zu sagen. Die zweite ist die Unendlicher-Kontext-Pose: Marketing, das nahelegt, das Fensterproblem sei gelöst, während unter Last in Wahrheit Antwort eins passiert, nur leise. Wenn Ihre Arbeit reguliert ist, scheitern beide Antworten am selben Test: Können Sie präzise sagen, was der Agent nicht mehr berücksichtigte, als er diese Zahl produzierte?

DataQubes Antwort beginnt damit, einer einzigen Datenstruktur zwei Jobs zu verweigern.

Zwei Gedächtnisse mit verschiedenen Jobs

Die Verwirrung unter dem meisten Kontextfenster-Lamento besteht darin, "was das Modell sieht" und "was geschehen ist" für dasselbe zu halten. Es sind verschiedene Objekte mit verschiedenen Garantien:

Zwei Gedächtnisse, zwei Garantien
Arbeitskontext
was das Modell sieht — neu gebaut, damit es ins Fenster passt
Zusammenfassung der Züge 1–141
fixiert: Definitionen · Entscheidungen · offene Fragen
jüngste Züge, wörtlich
Das Protokoll
append-only — was tatsächlich geschah
Zug 1 … Zug 141 — jedes Event, erhalten
Kompaktierungs-Event #3 — was zusammengefasst wurde, wann
Zug 142 …
Kompaktierung baut die linke Seite neu. Nichts schreibt jemals die rechte um.

Das Protokoll - der Conversation-Log des Threads - ist append-only und vollständig: jeder Zug, jeder Tool-Aufruf mit Audit-Referenz, jedes Ergebnis, jede Entscheidung, für immer. Es ist das Objekt, auf dem der Audit-Trail lebt, und nichts am Kontextmanagement darf es berühren. Der Arbeitskontext ist eine Projektion, aus dem Protokoll gebaut für den nächsten Modellaufruf: jüngste Züge wörtlich, der Rest durch Zusammenfassungen und fixierte Essenzen vertreten. Er wird frei neu gebaut, verkleinert, umgeschrieben - weil er kein Beweisgewicht trägt. Das Protokoll beantwortet "Was ist geschehen?"; der Arbeitskontext beantwortet "Was braucht das Modell jetzt?". Sobald das getrennte Objekte sind, hört das Kontextfenster auf, ein Wahrheitsproblem zu sein, und wird ein Engineering-Budget.

Kompaktierung ist ein Event, kein Radiergummi

Nähert sich der Arbeitskontext eines Threads dem Fenster, kompaktiert DataQube ihn: Ältere Züge werden in eine strukturierte Zusammenfassung gefaltet, und der Kontext wird um sie herum neu gebaut. Der Teil, der für Vertrauen zählt, ist, wie sichtbar das geschieht.

Kompaktierung ist ein Event, an das Protokoll angehängt wie jedes andere. Es sagt, wann sie lief, welche Spanne des Gesprächs sie zusammengefasst hat und mit welcher Zusammenfassung das Modell fortan arbeitet. Im Thread selbst sehen Sie sie als Markierung zwischen den Nachrichten - jeder, der das Gespräch liest, sieht genau, wo das Arbeitsgedächtnis des Agenten konsolidiert wurde, so wie man sieht, wo ein Tool aufgerufen wurde. Nichts an der Kognition des Agenten ist neben dem Protokoll: Selbst die Momente, in denen er sein eigenes Gedächtnis reorganisiert hat, stehen darin.

Diese Sichtbarkeit klingt kosmetisch, bis man sie braucht. Wenn ein Reviewer fragt, warum die späteren Antworten des Agenten einen frühen Caveat nicht mehr referenzieren, ist die ehrliche Antwort auffindbar: Hier ist das Kompaktierungs-Event, hier die produzierte Zusammenfassung, und der Caveat hat es in sie geschafft oder nicht. Den Fehlermodus gibt es weiterhin - Zusammenfassen ist von Natur aus verlustbehaftet -, aber er ist inspizierbar. Das ist der Unterschied zwischen einem Bug, den man melden kann, und einem Gespenst, das man nicht fängt.

Was wörtlich überlebt und was komprimiert wird

Kompaktierung ist kein gleichmäßiges Verrühren. Manches ist fixiert und überlebt jede Kompaktierung wörtlich, weil sein exakter Wortlaut tragend ist: die geltenden validierten Definitionen, Entscheidungen des Nutzers, die Parameter der Aufgabe und offene Fragen, auf die der Agent noch eine Antwort schuldet. Komprimiert wird die Masse: lange Tool-Outputs, explorative Züge, die irgendwohin führten, Sackgassen, die es nicht taten.

Und komprimiert heißt nicht weg. Eine Zusammenfassungszeile wie "Kreditbuch über neun Segmentvarianten abgefragt; alle innerhalb der Toleranz abgestimmt außer Büro (siehe Zug 87)" trägt einen Zeiger zurück ins Protokoll. Braucht der Agent später die tatsächlichen Zahlen aus Zug 87, sind sie einen Zugriff entfernt - im Protokoll, wo sie nie aufgehört haben zu existieren. Der Arbeitskontext vergisst, wie der Schreibtisch einer guten Analystin vergisst: Der Ordner ging zurück in den Schrank, nicht in den Schredder.

Einen kompaktierten Thread auditieren

Hier ist die Eigenschaft, die dieses Design mit allem anderen auf diesem Blog kohärent macht: Evidenz lebt nie im Arbeitskontext. Jede Zahl, die der Agent produziert hat, trägt ihre Kette - Queries, Dokumente, Läufe, Prüfungen -, verankert im Protokoll, nicht in dem, was das Modell gerade im Fenster hatte. Kompaktierung kann Evidenz deshalb nicht verwaisen lassen. Ein fünfmal kompaktierter Thread auditiert sich exakt wie ein nie kompaktierter: Gehen Sie die Kette jedes Claims entlang, und jeder Verweis löst sich auf - denn das, worauf die Verweise zeigen, wurde nie kompaktiert.

Ein Reviewer einer langen Untersuchung bekommt daher beide Wahrheiten zugleich: die vollständige Historie (das Protokoll, unberührt) und einen ehrlichen Bericht darüber, womit der Agent in jeder Phase gearbeitet hat (die Folge der Kompaktierungs-Events und ihrer Zusammenfassungen). Nichts in diesem Satz verlangt, dem Zusammenfasser zu vertrauen - nur zu lesen, was er wann ins Protokoll geschrieben hat.

Ein Protokoll, das niemand umschreiben kann

Die Eigenschaft, die Sie aus alldem mitnehmen sollten: In DataQube lässt sich das Protokoll nicht bearbeiten - nicht vom Agenten, nicht von der Kompaktierung, nicht von uns. Manche Plattformen managen Kontext, indem sie das Gespräch selbst kompaktieren, alte Züge zusammenfassen und ersetzen; am Tag der Prüfung ist der gelesene Thread nicht mehr der Thread, der die Zahlen produziert hat - sondern eine Nacherzählung, geschrieben von derselben Klasse von Modell, deren Outputs die Prüfung kontrollieren soll, und Ihr primäres Beweisartefakt ist still zu einem abgeleiteten geworden.

Deshalb zahlen wir den Preis des append-only Protokolls mit wegwerfbaren Projektionen gern: Speicher ist billig, und eine Historie, die bearbeitet worden sein könnte, ist genau in dem Moment wertlos, in dem jemand sie braucht. Wenn Sie eine Agent-Plattform evaluieren, entscheidet eine einzige Frage dieses ganze Thema: Ist der Thread, den ich auditiere, der Thread, der gelaufen ist - oder eine Zusammenfassung davon?

Dasselbe Prinzip - ein Protokoll, viele Projektionen - zieht sich durch die ganze Plattform; die Produktseite zeigt es als Chat, Notebook und Deck. Und wenn Sie sehen wollen, wie ein kompaktierter Thread seine Belege behält, buchen Sie eine Demo und bringen Sie ein langes Gespräch mit.

Läuft in Ihrem Cluster - nichts verlässt Ihre Umgebung

Sehen Sie, wie Ihre Daten Fragen beantworten - ohne Ihre Infrastruktur zu verlassen

Dreißig Minuten mit einem Engineer: Live-Produkt, Bereitstellungsoptionen und Antworten auf die Fragen Ihres Sicherheitsteams von jemandem, der den Code geschrieben hat.