Kapitel 3 — Fortgeschrittene Chunking-Frameworks

Dritter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Wo naive Entscheidungen am stillsten alles Nachgelagerte beschädigen — und wo zwei junge Techniken das Mögliche an der Frontier verschoben haben.

Warum dieses Kapitel existiert

Sind die Dokumente geparst, ist die nächste Entscheidung zugleich die folgenreichste: wie zerlegt man sie in Stücke, klein genug zum Einbetten und groß genug, um für sich allein noch etwas zu bedeuten. Das ist Chunking. Ein Chunk, der eine Definition von ihrem Zusatz trennt, wird selbstbewusst abgerufen und falsch sein. Ein Chunk, der fünf unverbundene Themen bündelt, verdünnt jedes Embedding, das ihn berührt. Das Retrieval-System, das du darauf aufbaust, kann nur zurückholen, was der Chunking-Schritt erhalten hat, und die Versagensmuster sind hier leise — der Retriever liefert weiter Kandidaten, das Modell weiter flüssige Antworten, und nur der Nutzer merkt, dass die Antworten subtil falsch sind.

3.1 Das Chunking-Spektrum

Es hilft, die Strategien danach zu ordnen, wie viel sie über das Dokument wissen. Am einen Ende weiß Fixgrößen-Chunking nichts — Tokens zählen, schneiden. Schnell, deterministisch, akzeptabel für stilistisch gleichförmigen Kurztext (Chat-Protokolle, FAQ-Einträge, Kundenrezensionen). Auf strukturierten technischen Dokumenten ist es ein stilles Desaster. Rekursives Chunking wendet eine priorisierte Trennzeichenliste an — Absätze, dann Zeilenumbrüche, dann Sätze, dann Wörter — und schneidet am höchstpriorisierten Trenner, der unter die Zielgröße passt. Fast so günstig wie Fixgröße und substanziell besser. Das ist die richtige Voreinstellung für die meisten Teams.

Semantisches Chunking verschiebt die Entscheidung von Syntax zu Bedeutung: jeden Satz einbetten, die Sequenz durchgehen, Themenübergänge markieren, wo die Ähnlichkeit benachbarter Sätze unter eine Schwelle fällt. Es funktioniert gut auf langer Prosa, in der strukturelle Hinweise schwach sind (Analystenberichte, Interview-Transkripte), und schlecht auf strukturierten technischen Dokumenten, in denen dichte Querverweise und wiederholter Boilerplate die Satz-Embeddings verwirren. Strukturbewusstes Chunking behandelt das geparste Dokument als Baum und schneidet entlang davon — nach Abschnitt, nach Überschriftenebene, nach Code-Funktion. Gut gemacht ist es die treueste Form; ohne einen layoutbewussten Parser upstream produziert es nichts anderes als rekursives Chunking, weil die Struktur nie extrahiert wurde. Die vier sind Alternativen, kein gemeinsam einzusetzender Stack.

3.2 Der Overlap-Mythos und die Kontextklippe

Fast jedes Tutorial empfiehlt einen Chunk-Overlap von 15–20 %. Die Intuition stimmt, soweit sie reicht — Overlap verhindert Grenzverluste — aber die Kurve flacht schnell ab. Die ersten 10 % holen das meiste herein. Jenseits von etwa 25 % ist die Genauigkeit praktisch flach, während die Kosten auf drei Achsen steigen: Embedding-Rechnungen skalieren linear mit der Chunk-Anzahl, Indexgröße und Query-Latenz wachsen, und die Top-Ergebnisse des Retrievers werden zu Near-Duplikaten voneinander. Eine Nutzerquery trifft eine Passage in den Chunks A, B und C; das Kontextfenster füllt sich, ohne dass neue Information hinzukommt; der Reranker verbraucht sein Budget mit dem Umsortieren von Varianten desselben Inhalts. Ein Team, das nach 30–40 % Overlap greift, sollte das als Signal werten, dass das Chunking falsch ist, nicht dass der Overlap zu niedrig ist.

Verwandt, aber unterschieden ist die Kontextklippe: der scharfe Einbruch der Retrieval-Qualität, sobald ein Chunk die Ankertermini verliert, die ihn auffindbar machten. Ein Absatz, der mit "Die Novelle von 2023 zu Richtlinie 47-B verpflichtete alle Filialen, …" beginnt und die Verpflichtung in den folgenden Sätzen beschreibt. Schneide nach dem Auftakt, und der die Verpflichtung beschreibende Chunk nennt weder die Richtlinie noch die Novelle noch das Jahr. Er wird selbstbewusst für unverwandte Queries auftauchen und die kanonischen verfehlen. Retrieval ist Top-k — entweder der Chunk taucht auf oder nicht, ohne weiche Abstufung. Die Klippe ist das dominante Versagensmuster in technischen Korpora, in denen Pronomen und Kurzformen die Antezedenten durch einen Abschnitt tragen.

3.3 Chunkgröße an Query-Typ koppeln

Über die Chunkgröße wird oft so debattiert, als gäbe es eine einzige richtige Antwort. Gibt es nicht, weil die richtige Antwort davon abhängt, welche Queries das System bekommen wird. Eine Faktenfrage — "wie hoch war der Selbstbehalt bei Police 47-B in 2024?" — will 150–300 Tokens, schmal genug, um präzise zu sein, weit genug, um zu disambiguieren. Eine Argumentationsfrage — "fasse die Änderungen zwischen den Versionen 2023 und 2024 zusammen und erkläre, wie sie die Verlängerung betreffen" — will 800–1.200 Tokens, um das Bindegewebe innerhalb eines Abschnitts zu erhalten. Die optimale Größe unterscheidet sich um den Faktor 4–8 zwischen beiden, und Produktionsverkehr ist meist gemischt.

Zwei produktive Antworten. Multi-Granularity-Indizierung speichert denselben Korpus in mehreren Chunkgrößen und routet Queries nach Intent-Klassifikation. Hierarchisches Retrieval indiziert kleine Chunks für Präzision, liefert aber deren Eltern-Abschnitte für Kontext zurück — ein Index, zur Query-Zeit konditioniert, in Produktion verbreiteter, weil es bei falscher Intent-Klassifikation weich abfällt. Das Parent-Document-Muster ist eine der ertragreichsten Techniken in der Produktions-Retrieval-Literatur.

3.4 Contextual Retrieval und Late Chunking

Die Frontier ist die Einsicht, dass Chunk und Embedding trennbare Anliegen sind. Zwei junge Techniken nutzen diese Trennung in entgegengesetzten Richtungen. Contextual Retrieval, von Anthropic 2024 popularisiert, schickt jeden Chunk samt vollständigem Dokument an ein günstiges LLM und bittet um eine ein- bis zweisätzige Beschreibung, wo der Chunk sitzt — "Dieser Chunk behandelt die Änderung der Selbstbehaltsberechnung, eingeführt mit der Novelle 2024 zu Richtlinie 47-B" — und stellt das dann dem Chunk-Text voran, bevor eingebettet wird. Der Chunk wird auffindbar für Queries, die der zugrundeliegende Text nie benannte. Berichtete Gewinne liegen bei rund 49 % Reduktion der Retrieval-Fehler in Anthropics Evaluation, mehr noch in Kombination mit hybrider Suche und Reranking. Der Trick, der es ökonomisch macht, ist Prompt Caching: das Dokument einmal senden, jeden Chunk gegen die gecachte Version verarbeiten.

Late Chunking, von Jina AI 2024 eingeführt, greift dasselbe Problem von der anderen Seite an. Das vollständige Dokument läuft in einem Durchgang durch ein Long-Context-Embedding-Modell und produziert tokenweise Embeddings, die bereits über das ganze Dokument kontextualisiert sind. Erst danach wird das Dokument zerlegt, und das Embedding jedes Chunks wird aus seinen jetzt kontextualisierten Tokens gepoolt. Keine zusätzlichen LLM-Aufrufe; die Embeddings erben den Dokumentkontext implizit. Die Bedingung ist, dass das Embedding-Modell das nativ unterstützt (jina-embeddings-v3/v4 und einige Forschungsmodelle tun das) und das Dokument ins Fenster des Modells passt. Für Dokumente, die passen, gleicht Late Chunking Contextual Retrieval zu einem Bruchteil der Indexierungs-Kosten. Für Dokumente, die nicht passen, ist Contextual Retrieval allgemeiner. Die zwei schließen einander nicht aus, und ernsthafte Produktionssysteme fahren oft beides mit einem Deduplikationsschritt obendrauf.

Was Kapitel 3 vorbereitet

Chunking verwandelt ein geparstes Dokument in eine Population abrufbarer Einheiten. Jede Einheit braucht einen Ort zum Wohnen — gespeichert, indiziert, mit niedriger Latenz abgefragt, bei Änderungen am Korpus aktualisiert. Dieser Ort ist die Vektordatenbank, und ihre Wahl ist eine andere Art Entscheidung als die Chunking-Entscheidung. Chunking ist ein Softwareproblem mit Softwarekosten. Die Datenbankwahl ist ein Softwareproblem mit infrastrukturellen, operativen und regulatorischen Folgen, und die falsche Wahl kann sechs Monate brauchen, bis sie zurückgenommen ist.

Als Nächstes — Kapitel 4: Die richtige Vektordatenbank wählen. Purpose-Built versus Extension-Architekturen, die Managed-Leader, das Open-Source-Feld und die drei Achsen — Residency, Betrieb, Gesamtkosten — die die echte Entscheidung meist treffen.