MDKeyChunker: Single-Call LLM Enrichment with Rolling Keys and Key-Based Restructuring for High-Accuracy RAG

Der Paper stellt MDKeyChunker vor, einen dreistufigen RAG-Pipeline-Ansatz für Markdown-Dokumente, der durch strukturbewusstes Chunking, eine einzelne LLM-Aufruf-Enrichment-Phase mit rollierenden Schlüsseln und eine schlüsselbasierte Neustrukturierung die semantische Kohärenz verbessert und die Retrieval-Genauigkeit signifikant steigert.

Das Wesentliche

📚 Das Problem: Der zerhackte Roman

Stell dir vor, du hast einen dicken Roman (deine Dokumente), den du einem sehr klugen, aber etwas vergesslichen Bibliothekar (dem KI-Modell) geben willst, damit er dir Fragen dazu beantworten kann.

Die herkömmliche Methode (das, was die meisten RAG-Systeme tun) ist wie folgt:

1. Der stumpfe Messer-Schnitt: Der Bibliothekar nimmt den Roman und schneidet ihn einfach in gleich große Stücke von je 500 Wörtern, egal was auf den Seiten passiert.
   • Das Problem: Ein wichtiges Diagramm wird mitten durchgeschnitten. Ein Code-Beispiel wird vom Text getrennt, der ihn erklärt. Der Bibliothekar bekommt also nur halbe Informationen.
2. Die mühsame Suche: Für jedes dieser Stücke muss der Bibliothekar extra Zeit aufwenden, um zu notieren: "Was ist hier drin? Wer ist erwähnt? Was ist das Thema?" Das kostet viel Zeit und Geld, weil er für jedes Stück einzeln nachschlagen muss.
3. Die verstreuten Notizen: Da er jedes Stück isoliert betrachtet, vergisst er den Zusammenhang. Wenn im ersten Stück von "Bewerbungsfrist" die Rede ist und im fünften Stück von "Einreichungsfrist", denkt der Bibliothekar, das seien zwei verschiedene Dinge.

💡 Die Lösung: MDKeyChunker – Der intelligente Archivar

Das Paper stellt MDKeyChunker vor. Das ist wie ein neuer, hochspezialisierter Archivar, der den Roman nicht einfach zerschneidet, sondern ihn mit Respekt behandelt. Er arbeitet in drei Schritten:

Schritt 1: Der sensible Schnitt (Struktur-Erkennung)

Statt blind zu schneiden, schaut sich der Archivar die Struktur des Dokuments an (Überschriften, Tabellen, Code-Blöcke).

• Die Analogie: Stell dir vor, du hast ein Puzzle. Der alte Archivar würde das Puzzle einfach in gleich große Haufen werfen, wodurch die Kanten der Bilder zerbrochen wären. Der MDKeyChunker schneidet das Puzzle genau dort, wo die Bildränder sind.
• Das Ergebnis: Ein ganzer Code-Block oder eine ganze Tabelle bleibt immer in einem Stück. Nichts wird zerhackt.

Schritt 2: Der "Ein-Mal-All-in-One"-Check (Single-Call Enrichment)

Jetzt muss der Archivar für jedes Puzzle-Stück Notizen machen (Titel, Zusammenfassung, Schlagwörter, Fragen, die es beantwortet).

• Die alte Methode: Er würde erst den Titel schreiben, dann den Text aufgeben, dann die Namen suchen, dann die Fragen erfinden. Das sind viele separate Besuche beim "Gehirn" (der KI).
• Die MDKeyChunker-Methode: Er macht einen einzigen Besuch beim Gehirn. Er sagt: "Hier ist das Stück. Gib mir mir alles auf einmal: Titel, Zusammenfassung, Namen, Fragen und ein Schlüsselwort."
• Der Clou: Das spart enorm viel Zeit und Geld, weil nur ein einziger "Gedankenimpuls" nötig ist, um alle Informationen zu sammeln.

Schritt 3: Der Rolling-Key-Trick (Der fließende Kontext)

Das ist die magischste Erfindung. Der Archivar führt ein laufendes Wörterbuch (ein "Rolling Key Dictionary") mit sich.

• Die Analogie: Stell dir vor, du liest ein Buch und machst dir Notizen auf einem Zettel. Wenn du im ersten Kapitel von "Admissions" (Zulassung) liest, schreibst du "Zulassung" auf deinen Zettel.
  • Wenn du später im fünften Kapitel wieder über "Zulassung" liest, schaust du auf deinen Zettel und sagst: "Ah, das ist dasselbe Thema wie vorher!" Du benutzt also das gleiche Schlüsselwort.
  • Ohne diesen Trick würde der Archivar im fünften Kapitel vielleicht "Bewerbung" oder "Eintritt" schreiben und denken, es sei etwas Neues.
• Das Ergebnis: Der Archivar weiß, dass verschiedene Teile des Dokuments zum selben Thema gehören, auch wenn sie weit voneinander entfernt sind.

Schritt 4: Das Zusammenkleben (Key-Based Restructuring)

Am Ende nimmt der Archivar alle Puzzle-Stücke, die das gleiche Schlüsselwort tragen, und klebt sie zu einem größeren, sinnvollen Block zusammen.

• Die Analogie: Wenn du im Buch zwei verschiedene Abschnitte über "Zulassung" hast, die durch 30 Seiten anderer Themen getrennt sind, holt der Archivar diese beiden Teile, klebt sie zusammen und erstellt einen neuen, perfekten "Zulassungs-Block".
• Warum? Wenn du später fragst: "Wie funktioniert die Zulassung?", muss der Bibliothekar nicht mehr zwei verschiedene, verstreute Teile suchen. Er hat einen einzigen, kompletten Block, der alles erklärt.

🏆 Was bringt das? (Die Ergebnisse)

Das Paper hat das System getestet und gezeigt:

1. Keine kaputten Teile: Tabellen und Code wurden nie zerschnitten.
2. Bessere Antworten: Weil die Informationen logisch zusammengefasst wurden, findet das System die richtigen Antworten viel schneller und genauer.
3. Günstiger & Schneller: Weil nur ein KI-Aufruf pro Stück nötig ist (statt vieler), ist es viel kosteneffizienter als andere Methoden.

Zusammenfassung in einem Satz

MDKeyChunker ist wie ein intelligenter Bibliothekar, der Bücher nicht willkürlich zerschneidet, sondern sie in logische Themenblöcke sortiert, dabei einen "Gedächtniszettel" führt, um Zusammenhänge zu erkennen, und alles in einem einzigen, effizienten Schritt für die KI auf

Technische Zusammenfassung

1. Problemstellung

Retrieval-Augmented Generation (RAG)-Pipelines leiden derzeit unter drei systematischen Schwachstellen, die durch herkömmliche Ansätze verursacht werden:

1. Fragmentierung durch feste Chunk-Größen: Das Aufteilen von Dokumenten in feste Token-Längen (z. B. 256–512 Token) ignoriert die semantische Struktur. Dies führt dazu, dass zusammengehörige Inhalte (wie Tabellen und ihre Beschriftungen oder Code-Blöcke mit Erklärungen) über Chunk-Grenzen hinweg zerschnitten werden, was die semantische Kohärenz und die Retrieval-Qualität beeinträchtigt.
2. Hohe Kosten der Metadaten-Extraktion: Um die Retrieval-Genauigkeit zu verbessern, werden oft Metadaten (Zusammenfassungen, Schlüsselwörter, Entitäten, Fragen) extrahiert. Herkömmliche Pipelines führen hierfür separate LLM-Aufrufe pro Feld durch. Bei $n$ Chunks und $m$ Extraktionsschritten skaliert dies als $O(n \cdot m)$, was hohe Latenz und Kosten verursacht.
3. Kontextuelle Isolation: Chunks werden oft unabhängig voneinander verarbeitet. Ohne Kontextweiterleitung entstehen Synonym-Probleme (z. B. „Bewerbungsfrist" vs. „Zulassungszeitraum" für dasselbe Thema), da keine übergreifende semantische Verknüpfung besteht.

2. Methodik: Der MDKeyChunker-Ansatz

MDKeyChunker ist eine dreistufige Pipeline für Markdown-Dokumente, die diese Probleme durch eine strukturbewusste und kontextuelle Verarbeitung löst.

Stufe 1: Struktur-bewusstes Chunking (Markdown Structural Splitting)

Anstatt feste Längen zu verwenden, analysiert ein Parser die Markdown-Struktur und identifiziert atomare Blöcke: Header, Code-Blöcke, Tabellen, Listen und Zitate.

• Atomarität: Diese Elemente werden niemals zerschnitten.
• Gruppierung: Blöcke werden zu Chunks zusammengefasst, die eine Mindestgröße ($\tau_{min}$) und eine weiche Obergrenze ($\tau_{max}$) einhalten.
• Ergebnis: Chunks, die semantische Einheiten (z. B. eine ganze Tabelle oder einen Code-Block) vollständig enthalten.

Stufe 2: Single-Call LLM-Enrichment mit Rolling Keys

Dies ist das Kernstück der Innovation. Statt mehrere Aufrufe zu tätigen, wird ein einziger LLM-Aufruf pro Chunk verwendet, um sieben Metadaten-Felder gleichzeitig zu extrahieren:

1. Titel
2. Zusammenfassung (Summary)
3. Schlüsselwörter
4. Entitäten (Personen, Organisationen, etc.)
5. Hypothetische Fragen
6. Semantischer Schlüssel (Key): Ein spezifisches Subthema (2–5 Wörter).
7. Verwandte Schlüssel (Related Keys): Verweise auf vorherige Schlüssel.

Rolling Key Dictionary:
Ein entscheidendes Merkmal ist das „Rolling Key Dictionary". Bei der Verarbeitung eines Chunks $c_i$ erhält das LLM ein Dictionary $K$, das die Schlüssel aller vorherigen Chunks im Dokument enthält.

• Das LLM wird angewiesen, einen bestehenden Schlüssel aus $K$ wiederzuverwenden, wenn der aktuelle Chunk dasselbe Thema behandelt, anstatt neue Synonyme zu erfinden.
• Das Dictionary wird nach dem LRU-Prinzip (Least Recently Used) verwaltet (max. 40 Einträge), um den Token-Overhead konstant zu halten.
• Dies ermöglicht eine dokumentenweite semantische Konsistenz ohne manuelle Schwellenwert-Tuning-Formeln.

Stufe 3: Schlüssel-basierte Umstrukturierung (Key-Based Restructuring)

Nach der Anreicherung werden Chunks, die denselben semantischen Schlüssel teilen, neu gruppiert.

• Bin-Packing: Ein Algorithmus fasst Chunks mit identischen Schlüsseln zu größeren Einheiten zusammen, solange die maximale Merge-Größe ($\tau_{merge}$) nicht überschritten wird.
• Effekt: Verstreute Inhalte, die im Originaldokument durch andere Abschnitte getrennt waren (z. B. zwei Abschnitte über „Modelltypen" an unterschiedlichen Stellen), werden zu einem einzigen, kohärenten Retrieval-Chunk zusammengeführt.
• Orphan-Handling: Chunks ohne Schlüssel erhalten zusätzlichen Kontext (Header, Nachbarn-Zusammenfassungen), um ihre Einbettung zu verbessern.

3. Hauptbeiträge

1. Single-Call-Protokoll: Extraktion von sieben Metadaten-Feldern in einem einzigen LLM-Aufruf pro Chunk, was die Kosten und Latenz im Vergleich zu mehrstufigen Pipelines drastisch reduziert.
2. Rolling Key Propagation: Ein Mechanismus zur Aufrechterhaltung des dokumentenweiten Kontexts, der Synonym-Probleme löst und eine implizite Graph-Struktur ohne expliziten Knowledge Graphen erzeugt.
3. Key-Based Restructuring: Ein Algorithmus, der semantisch verwandte, aber räumlich getrennte Inhalte global zusammenführt, um die Retrieval-Effizienz zu steigern.
4. Open-Source-Implementierung: Eine vollständige Python-Implementierung mit 76 Unit