Wie BibGenie Kontexte komprimiert

Lange Forschungsdialoge stoßen zwangsläufig an eine technische Grenze: Das Kontextfenster eines Modells ist endlich.

In Zotero wird diese Begrenzung besonders deutlich. Eine einzige Sitzung kann Literaturrecherchen, PDF-Lektüre, Zitatextraktion, Notizorganisation, Werkzeugaufrufe und wiederholte Korrekturen umfassen. Mit wachsendem Verlauf wird es immer teurer, die gesamte Unterhaltung erneut zu senden – bis sie schließlich nicht mehr in das Modell passt. Ältere Nachrichten einfach zu löschen, ist keine tragfähige Lösung: Gerade dort stehen oft Forschungsziel, zentrale Quellen, Vorgaben und Entscheidungen, von denen die spätere Arbeit abhängt.

BibGenies Context Compaction löst dieses Problem, indem früherer Kontext in einen strukturierten Forschungs-Checkpoint überführt wird. Der vollständige Verlauf bleibt erhalten, ebenso ein unveränderter Ausschnitt der jüngsten Nachrichten. Das Modell erhält damit einen kleineren, informationsdichten Arbeitskontext, ohne den bisherigen Fortschritt oder die nächsten Schritte aus dem Blick zu verlieren.

Dieser Beitrag erläutert die technische Umsetzung.

Warum eine Agent-Anfrage immer größer wird

Eine Chat-Oberfläche wirkt wie eine einfache Folge angehängter Nachrichten. Ein Modell erinnert sich jedoch nicht automatisch an die vorherige Anfrage. Jede Anfrage muss den nötigen Kontext erneut enthalten. Tool-Aufrufe, PDF-Auszüge und Zotero-Suchergebnisse vergrößern ihn, bis der Provider die nächste Anfrage wegen des Context Window ablehnt.

Dann gibt es zwei Möglichkeiten: eine neue Unterhaltung ohne Verlauf beginnen oder den vorhandenen Kontext in eine kleinere, weiterhin arbeitsfähige Darstellung umwandeln. Compact verwendet den zweiten Weg.

Kontextverwaltung bedeutet nicht, die ältesten Nachrichten zu löschen

Naheliegend wäre, nur die letzten N Nachrichten zu behalten oder beim Erreichen eines Grenzwerts von vorne zu löschen. Für einen Forschungsagenten sind beide Ansätze unzuverlässig.

Erstens besteht kein stabiles Verhältnis zwischen Nachrichtenanzahl und Tokenmenge. Ein kurzes „Weiter“ benötigt nur wenige Token, während ein PDF-Auszug oder Werkzeugergebnis Tausende enthalten kann. Eine Begrenzung nach Nachrichtenzahl sagt daher wenig über den tatsächlichen Modellkontext aus.

Zweitens ist alt nicht gleich unwichtig. Forschungsziel, Ein- und Ausschlusskriterien, festgelegte Literatur, Zitierstil und zentrale Entscheidungen stehen häufig am Anfang. Werden sie entfernt, kennt der Agent vielleicht noch den letzten Satz, aber nicht mehr den Zweck der gesamten Arbeit.

Drittens ist ein Agentendialog keine reine Textliste. Ein vollständiger Forschungsprozess kann zusätzlich enthalten:

• Werkzeugaufrufe und Ergebnisse;
• Zotero-Item-Keys, Anhänge und Positionsangaben;
• Korrekturen früherer Schlussfolgerungen;
• fehlgeschlagene Ansätze, die nicht wiederholt werden sollen;
• offene Aufgaben und noch zu prüfende Hypothesen;
• multimodale Inhalte wie Bilder.

Compact darf deshalb nicht lediglich abschneiden. Es muss Informationen kontrolliert neu ordnen: ersetzbare Prozessdetails verwerfen und zugleich den Zustand bewahren, der für die Fortsetzung erforderlich ist.

BibGenie definiert Compact daher so:

Der entscheidende Unterschied lautet: Komprimiert wird der Kontext für die nächste Modellanfrage, nicht der Verlauf des Nutzers.

Vom vollständigen Verlauf zu „Checkpoint + Recent Tail“

Angenommen, eine Sitzung umfasst drei Dialogrunden:

U1 → A1 → U2 → A2 → U3 → A3

Nach Compact löscht oder verändert BibGenie keinen dieser Knoten. Stattdessen wird am Ende der aktiven Sitzung ein interner Checkpoint C1 angehängt:

U1 → A1 → U2 → A2 → U3 → A3 → C1
                              ↑
                    dauerhaftes Sitzungsende

C1 enthält die Zusammenfassung des früheren Kontexts. firstKeptMessageId verweist auf die erste Nachricht, die weiterhin im Wortlaut erhalten bleiben soll. Liegt diese Grenze bei U3, erhält das Modell bei der nächsten Anfrage:

C1.summary → U3 → A3

Nach der nächsten Nutzerfrage lautet der Kontext:

C1.summary → U3 → A3 → U4

Damit entstehen zwei miteinander vereinbare Ansichten:

• Dauerhafter Verlauf: Datenbank und Oberfläche behalten die vollständige Kette U1 → A1 → … → C1 → U4.
• Modellprojektion: Das Modell erhält nur den neuesten Checkpoint, den jüngsten Originalausschnitt und neue Nachrichten nach dem Checkpoint.

Es geht also nicht nur darum, eine Zeichenfolge zu kürzen, sondern einen vollständig prüfbaren Verlauf von einem dichten Arbeitsgedächtnis für das Modell zu trennen.

Wann Compact ausgeführt wird

BibGenie bietet drei Einstiegspunkte. Alle verwenden dieselbe Modellauflösung, Kapazitätsschätzung und Schwellenlogik.

1. Manuell

Nach Abschluss einer Forschungsphase können Nutzer gezielt Compact auswählen, bevor sie mit dem nächsten Abschnitt beginnen.

Die manuelle Ausführung ist nicht an den automatischen Schwellenwert gebunden. Sie entspricht einer ausdrücklichen Anweisung, jetzt einen Checkpoint anzulegen:

• Vor dem ersten Checkpoint genügt eine kurze Sitzung mit mindestens zwei Dialogrunden: Die erste wird zusammengefasst, die zweite bleibt im Wortlaut erhalten.
• Existiert bereits ein Checkpoint und sind danach neue Nachrichten entstanden, kann ein aktualisierter Checkpoint die vorherige Zusammenfassung übernehmen, selbst wenn sich die Aufbewahrungsgrenze nicht verschieben muss. Verschiebt sie sich, fließt der neu ausgeschlossene Verlauf in die Zusammenfassung ein.
• Besteht die Sitzung nur aus einer nicht komprimierbaren Runde oder ist der letzte Checkpoint bereits das Ende des Branches, gilt der Vorgang als erfolgreicher No-op statt als wenig hilfreicher Fehler.

So lassen sich sinnvolle Forschungsmeilensteine markieren, ohne „nichts zu komprimieren“ als Fehlschlag darzustellen.

2. Automatische Prüfung nach einer abgeschlossenen Antwort

Nachdem die endgültige Assistant-Antwort erfolgreich gespeichert wurde, prüft BibGenie die aktuelle Kontextbelegung. Nähert sie sich der sicheren Grenze, startet Compact proaktiv.

Dadurch fällt die Zusammenfassung meist nicht erst beim nächsten Senden an, und die nächste Frage kann ohne zusätzliche Wartezeit beginnen.

Die Prüfung läuft nur in einem stabilen Sitzungszustand. Solange Werkzeugaufrufe, Ergebnisse oder Nutzerfreigaben ausstehen, wird Compact übersprungen. Ein unvollständiger Ablauf darf nicht in einem Checkpoint festgeschrieben werden.

3. Preflight vor dem Senden

Die Prüfung nach einer Antwort verbessert die Latenz; die abschließende Korrektheitsgrenze ist jedoch der Preflight vor dem Senden.

Bevor eine neue Nutzernachricht in den Zustand des AI SDK übernommen wird, fügt BibGenie sie vorübergehend zur Modellprojektion hinzu und schätzt die nächste Anfrage. So werden große eingefügte Textpassagen, Bilder oder der Wechsel zu einem Modell mit kleinerem Kontextfenster rechtzeitig erkannt.

Passt die Anfrage auch nach Compact nicht, sendet BibGenie keine vorhersehbar fehlschlagende Provider-Anfrage. Der Entwurf bleibt erhalten und kann gekürzt werden.

Entscheidungen basieren auf Modellkapazität, nicht auf Nachrichtenzahl

Modelle unterscheiden sich bei Kontextfenster und maximaler Ausgabelänge. Deshalb verwendet BibGenie keinen globalen Schwellenwert.

Die Grundbeziehung lautet:

Sicheres Eingabelimit = Kontextfenster - reservierte Token

Die Reserve hält Platz für die nächste Antwort frei und wird aus dem Kontextfenster des aktiven Modells abgeleitet. Große Modelle können eine großzügigere Ausgabe vorsehen; bei kleinen Modellen wird die Reserve angepasst, statt eine ungeeignete globale Konstante zu übernehmen.

Auch das Budget des Recent Tail skaliert mit dem Modell. Compact glättet daher weder die gesamte jüngste Unterhaltung, nur um Token zu sparen, noch behält es einen Ausschnitt, der in ein kleineres Modell nicht passt.

Die Grenze liegt stets an einem vollständigen User Turn und schneidet keine Assistant-Antwort oder kein Werkzeugergebnis auseinander. Übersteigt ein einzelner Assistant-/Tool-Turn bereits das Budget, wird die nächstfolgende User-Grenze gewählt, statt den übergroßen Turn bei der Suche nach einer älteren Nachricht mitzuführen.

Reale Provider-Usage bevorzugen

Ein präziser Tokenizer für jeden Provider würde erhebliche Komplexität schaffen, während Provider Kontext und Abrechnung ohnehin nicht vollständig einheitlich berechnen. BibGenie verwendet deshalb reale Usage als Basis und schätzt nur den noch nicht erfassten Zuwachs:

1. Die letzte Assistant-Nachricht mit gültiger Usage nach dem neuesten Checkpoint ermitteln.
2. Die vom Provider gemeldeten Token als Ausgangswert verwenden.
3. Danach hinzugekommene Nachrichten schätzen, die in dieser Usage noch nicht enthalten sind.
4. Fehlt eine verlässliche Usage, die gesamte aktuelle Modellprojektion schätzen.

Geschätzt wird der voraussichtliche Kontext der nächsten Provider-Anfrage, nicht der kumulierte Tokenverbrauch des Nutzers. Abrechnungsbezogene totalUsage wird nicht mit Kontextbelegung gleichgesetzt.

Text wird konservativ anhand von Zeichen angenähert. Reasoning zählt mit, wenn ein Provider es erneut übermitteln kann. Bilder erhalten im Preflight feste Kontextkosten, damit multimodale Nachrichten nicht auf einen Dateinamen reduziert werden. Im Plugin stammen nutzerseitige file-Parts vor allem aus eingefügten Bildern und Zotero-Screenshots.

Die Schätzung behauptet keine Scheingenauigkeit. Sie beantwortet zuverlässig eine operative Frage: Liegt die nächste Anfrage noch im sicheren Bereich?

Die Zusammenfassung ist ein Agent-Zustand, kein Gesprächsrückblick

Eine gewöhnliche Gesprächszusammenfassung beschreibt, was geschehen ist. Ein Agent-Checkpoint muss darüber hinaus genug Zustand enthalten, um die Arbeit fortzusetzen.

BibGenie verlangt daher feste Abschnitte:

• Research Goal: aktuelles Forschungsziel;
• User Requirements and Constraints: Anforderungen, Präferenzen und Grenzen;
• Research Progress: abgeschlossene, laufende und blockierte Arbeit;
• Findings and Evidence: Erkenntnisse und zugehörige Belege;
• Key Zotero Resources: zentrale Einträge, Anhänge und Zotero-Keys;
• Decisions: bereits getroffene Entscheidungen;
• Next Steps: konkrete nächste Schritte;
• Critical Context: weitere unverzichtbare Informationen.

Der Prompt trennt außerdem Aussagen des Nutzers, durch Werkzeuge gelieferte Fakten und Modellschlussfolgerungen. So wird eine vorläufige Vermutung nach Compact nicht versehentlich zur gesicherten Tatsache.

Serialisierung für Forschungskontext

Vor der Zusammenfassung überführt BibGenie UIMessage-Daten in eine kompakte, forschungsorientierte Textdarstellung:

• normaler Text behält Inhalt und Rollenkennzeichnung;
• Reasoning gelangt nicht in den langfristigen Checkpoint;
• Werkzeugparameter bleiben erhalten, überlange Ergebnisse werden gekürzt;
• Fehler und verweigerte Operationen werden ausdrücklich markiert;
• Bilder und Anhänge behalten Dateiname und MIME-Typ;
• Zotero-Daten behalten die zur Fortsetzung erforderlichen Felder.

Je nach Zotero-Ressource bleiben andere Informationen erhalten:

• Literaturangaben: Item Key, Titel und Zitattext;
• PDF-Seiten: Anhangsname, aktuelle Seite und Gesamtseitenzahl;
• EPUB: Abschnittsindex, href und CFI;
• Annotationen: Annotation Key, Text, Kommentar, Seite und Parent Item Key;
• Collections und Tags: stabile Kennungen und Anzeigenamen.

Damit landen keine vollständigen, potenziell großen Quellobjekte in jeder Zusammenfassungsanfrage, während wichtige Zotero-Lokatoren für spätere Werkzeugaufrufe erhalten bleiben.

Wiederholtes Compact ohne Checkpoint-Stapel

Eine lange Sitzung kann mehrfach komprimiert werden. BibGenie projiziert nie alle früheren Checkpoints, sondern ausschließlich den neuesten.

Beim nächsten Compact kombiniert das System:

vorherige Zusammenfassung + neu hinzugekommene ältere Nachrichten

zu einer neuen Zusammenfassung:

Zusammenfassung 1 + neuer Verlauf → Zusammenfassung 2
Zusammenfassung 2 + neuer Verlauf → Zusammenfassung 3

Der Kontext wächst somit nicht linear mit der Zahl der Checkpoints.

Auch die Grenze ist monoton: Eine neue Aufbewahrungsgrenze kann nicht hinter die Grenze des vorherigen Checkpoints zurückfallen. Bereits zusammengefasster früher Verlauf wird nicht wieder in den Recent Tail entfaltet.

Manuelle und automatische Ausführung unterscheiden sich bewusst:

• Automatisches Compact läuft nur, wenn die Grenze vorrücken und tatsächlich Kontext freigeben kann.
• Manuelles Compact darf bei neuen Nachrichten nach einem Checkpoint dieselbe Grenze verwenden und die vorherige Zusammenfassung aktualisieren. Rückt die Grenze vor, wird der neu ausgeschlossene Verlauf ebenfalls aufgenommen.

So konzentriert sich die Automatik auf messbaren Kapazitätsgewinn, während Nutzer Forschungsphasen weiterhin bewusst markieren können.

Das Ausgabebudget der Zusammenfassung stammt aus der Reserve und wird durch die maximale Ausgabelänge des Modells begrenzt. Es ist eine Sicherheitsobergrenze für komplexe Aufgaben; der Prompt verlangt dennoch eine prägnante Darstellung.

Warum Compact den Sitzungsbaum verstehen muss

BibGenie-Sitzungen sind keine einfachen Arrays, sondern verzweigte Nachrichtenbäume.

Nutzer können Antworten erneut erzeugen, die letzte Nachricht bearbeiten oder von einer historischen Assistant-Antwort aus einen Fork erstellen. Frühe Knoten können von mehreren Sitzungen geteilt werden; jede Sitzung kennzeichnet ihren aktiven Branch über ein eigenes dauerhaftes Ende.

Compact darf deshalb weder alte Knoten überschreiben noch den Recent Tail hinter den Checkpoint kopieren. Andernfalls könnten:

• Änderungen eines Branches andere Branches beeinflussen;
• Parent-Beziehungen geteilter Knoten verändert werden;
• Retry einen nicht mehr gültigen Checkpoint übernehmen;
• dieselben aktuellen Nachrichten mehrfach gespeichert werden;
• UI-Verlauf und Modellkontext voneinander abweichen.

BibGenie verwendet einen append-only Checkpoint:

C1.parentId = A3 beschreibt, wann und wo der Checkpoint im Baum angehängt wurde. C1.firstKeptMessageId = U3 definiert, ab welcher Stelle die Modellprojektion wieder Originaltext enthält. Beide Angaben beschreiben verschiedene Dimensionen und können einander nicht ersetzen.

Ein Fork von A2 übernimmt C1 nicht. Ein Fork von einer stabilen Assistant-Nachricht nach C1 enthält den Checkpoint dagegen automatisch in seiner Vorfahrenkette. Kein geteilter Knoten muss kopiert oder verändert werden.

Der Checkpoint als nebenläufigkeitssicherer Zustands-Commit

Eine Zusammenfassung kann mehrere Sekunden dauern. Wird der Branch in dieser Zeit bearbeitet, erneut erzeugt oder anderweitig verändert, darf eine auf dem alten Verlauf basierende Zusammenfassung nicht gespeichert werden.

BibGenie behandelt Compact als versionsgebundenen Zustands-Commit. Zu Beginn werden zwei Werte festgehalten:

• leafId: aktuelles Ende des dauerhaften Branches;
• branchRevision: eine Branch-Version, die nur bei tatsächlicher Änderung dauerhafter Inhalte steigt.

Nach der Generierung vergleicht eine dedizierte Transaktion beide Werte, bestätigt einen stabilen Werkzeugablauf und prüft, ob die Aufbewahrungsgrenze weiterhin zum aktiven Branch gehört. Nur dann werden Checkpoint, neues Sitzungsende und erhöhte Revision atomar gespeichert. Jede Abweichung macht die Zusammenfassung veraltet und führt zur Ablehnung.

Ändert sich der Branch während der Generierung, lädt BibGenie den tatsächlichen Datenbankzustand neu, statt einen veralteten Checkpoint aufzuzwingen. Ein Abbruch vor Abschluss der Transaktion führt zum Rollback. Nach erfolgreichem Commit wird der Speicherzustand mit dem Checkpoint synchronisiert, sodass Datenbank und Oberfläche auf denselben Branch konvergieren.

Zusammenspiel mit Retry, Edit, Fork und weiteren Aktionen

Eine zuverlässige Compact-Funktion muss die bestehende Sitzungssemantik bewahren und nicht nur erfolgreich Text zusammenfassen.

Retry

Ein Checkpoint ist eine interne Nachricht. Retry zielt auf die letzte echte Assistant-Antwort. Liegt danach ein Checkpoint, wird er gemeinsam mit dem alten Tail ungültig; die neue Antwort durchläuft anschließend wieder die normalen Kapazitätsprüfungen.

Edit

Beim Bearbeiten der letzten echten User-Nachricht verlassen die folgende Assistant-Antwort und nachfolgende Checkpoints den aktiven Branch. Das erneute Senden durchläuft wieder den Preflight.

Fork

Fork kann nur stabile echte Assistant-Nachrichten auswählen, niemals interne Checkpoints. Ob der neue Branch einen Checkpoint erbt, ergibt sich ausschließlich aus der Vorfahrenkette des Zielknotens.

Schutz beschädigter Verläufe

Beim Laden prüft BibGenie auf fehlende Parents, Parent-Zyklen und ungültige dauerhafte Nachrichten. Ist die Topologie beschädigt, zeigt die Oberfläche nur den sicher lesbaren Abschnitt und setzt die Sitzung auf schreibgeschützt. Die ursprüngliche Datenbank wird beim Laden oder Komprimieren nie stillschweigend umgeschrieben.

Nutzererlebnis während Compact

Kontextkomprimierung ist Infrastruktur, sollte aber nicht wie ein unerklärliches Einfrieren wirken.

Bei manuellem oder automatischem Compact zeigt der Chat Compacting earlier context… und bietet einen Abbruch an. Das Eingabefeld bleibt bearbeitbar, sodass die nächste Frage vorbereitet werden kann.

Erst nach dem ausdrücklichen Absenden wird der Inhalt eingefroren und wartet gegebenenfalls auf den laufenden Vorgang. Nach erfolgreichem Abschluss sendet BibGenie automatisch weiter. Bei Fehler oder Abbruch wird nichts unbemerkt gesendet; der Entwurf bleibt erhalten.

Retry, Edit, Fork, Modellwechsel und ein weiteres Compact sind vorübergehend deaktiviert, da sie den zugrunde liegenden Branch verändern würden. Reines Bearbeiten der Eingabe verändert den dauerhaften Verlauf nicht und muss daher nicht vorzeitig blockiert werden.

Für Nutzer ergibt sich ein klares Verhalten:

• lange Recherchen brechen nicht plötzlich wegen eines wachsenden Kontexts ab;
• ein neuer Chat mit erneuter Erklärung des Hintergrunds ist nicht erforderlich;
• beim Wechsel zu einem kleineren Modell wird die Kapazität vor dem Request neu bewertet;
• wichtige Literatur, Zotero-Keys, Ergebnisse und offene Aufgaben bleiben erhalten;
• die jüngsten Nachrichten bleiben im Wortlaut und bewahren lokale Bezüge;
• Checkpoints gehören auch nach einem Neustart zum richtigen Branch;
• der vollständige Verlauf vor Compact bleibt einsehbar.

Compact hat einen Preis: Prompt Caching beginnt neu

Ein kürzerer Kontext macht die erste Anfrage nach Compact nicht automatisch günstiger. Viele Modelldienste cachen unveränderte Anfragepräfixe. Compact ersetzt einen Teil dieses Präfixes durch eine Zusammenfassung, sodass die erste Anfrage neu berechnet werden muss; danach kann ein neuer Cache entstehen.

Das Ziel ist daher nicht der kürzestmögliche Prompt, sondern ein Gleichgewicht zwischen Kontextkapazität, erhaltener Arbeitsinformation, Cache-Wiederverwendung, Latenz und Kosten.

Entwurfsentscheidungen: Prüfbarkeit statt Scheingenauigkeit

BibGenie übernimmt bewährte Muster der Agentenkomprimierung und passt sie an Zotero, multimodale Eingaben und baumförmige Persistenz an. Bewusst vermieden werden:

• ein vermeintlich universeller, für alle Provider „exakter“ Tokenizer;
• physisches Löschen oder Umhängen früherer Nachrichten;
• Duplizieren des Recent Tail;
• automatisches Compact mit Wiederholung nach einem Provider-Overflow;
• Erzeugen oder Ändern von Checkpoints über die gewöhnliche Nachrichtenpersistenz;
• Gleichsetzen kumulierter Abrechnungstoken mit Kontextbelegung.

Dadurch lassen sich die entscheidenden Eigenschaften leichter prüfen: Zeitpunkt der Ausführung, zugrunde liegender Branch, Modellprojektion, Datenbank-Commit und Zustand nach einem Fehler.

Compact bleibt eine verlustbehaftete Komprimierung. Das Ziel ist nicht, jedes Token wortgetreu zu bewahren, sondern die Kontinuität einer Aufgabe innerhalb eines endlichen Kontextfensters. Der vollständige Verlauf sorgt für Nachvollziehbarkeit, der Checkpoint für den Arbeitszustand und der Recent Tail für lokale Details.

Vom Chatbot zum langfristigen Forschungspartner

Ein klassisches Chatsystem fragt vor allem: „Wie soll ich in dieser Runde antworten?“ Ein Forschungsagent muss zusätzlich beantworten: „Welchen Zustand muss ich in die nächste Runde mitnehmen?“

BibGenies Context Compaction ist mehr als ein Zusammenfassungsaufruf. Es verbindet Kapazitäts-Preflight, Serialisierung von Forschungskontext, strukturierte Checkpoints, Projektion baumförmiger Sitzungen, Versionsprüfung bei Nebenläufigkeit, transaktionale Persistenz und konsistentes Verhalten bei Retry, Edit und Fork.

Wenn Forschung Dutzende Runden, mehrere Publikationen und zahlreiche Werkzeugaufrufe umfasst, ist es weniger wichtig, jedes Token zu behalten, als zuverlässig zu wissen:

• welches Ergebnis der Nutzer erreichen möchte;
• welche Aussagen bereits durch Belege gestützt sind;
• welche Schlussfolgerungen noch Hypothesen darstellen;
• welche Arbeit abgeschlossen ist;
• was als Nächstes geschehen soll.

Genau das ermöglicht Compact in BibGenie: Ein endliches Kontextfenster trägt eine Agentensitzung, die langfristig fortschreiten, zuverlässig wiederaufgenommen und in ihrem Forschungszusammenhang bewahrt werden kann.