Chunking: wie Retrieval-Systeme einen Text zerlegen

Der Begriff stammt aus Retrieval-Systemen, nicht aus Suchmaschinen. Wenn ein System mit einem konkreten Zitat antworten soll, nützt ihm das ganze Dokument nichts, denn es müsste tausende Wörter zurückgeben, um einen einzigen Satz zu belegen. Deshalb zerlegt es das Dokument, bevor es es speichert. Jedes entstehende Stück ist ein Chunk, und dieser Chunk ist die kleinste Einheit, die das System abrufen und an das Modell weitergeben kann.

Drei Dinge, die oft vermischt werden, gehören auseinander. Ein Absatz ist eine Entscheidung deiner Redaktion. Ein HTML-Abschnitt ist eine Entscheidung des Layouts. Ein Chunk ist eine Entscheidung des Systems, das dein Dokument aufnimmt, getroffen mit Parametern, die du weder setzt noch siehst. Dreizeilige Absätze zu veröffentlichen zwingt niemanden, diese Grenzen als Chunk-Grenze zu verwenden.

Die zweite Unterscheidung betrifft den Besitz, und sie ordnet alles Weitere. Wenn du eine interne Suche oder einen Assistenten auf deiner Dokumentation baust, gehört das Chunking dir: Du wählst Verfahren, Größe und Überlappung und verantwortest die Qualität des Ergebnisses. Lautet die Frage dagegen, wie man in einer ChatGPT-Antwort oder in der Google-Suche auftaucht, findet die Zerlegung in einer fremden, geschlossenen Pipeline statt. Der Unterschied ist nicht akademisch, denn er bestimmt, was du wirklich optimieren kannst und was du nur vermuten kannst.

Es gibt vier Verfahrensfamilien. Die erste schneidet nach fester Länge, gezählt in Token oder Zeichen, und ist die einfachste und die blindeste, weil die Grenze fällt, wo sie eben fällt. Die zweite ergänzt eine Überlappung: Sie wiederholt das Ende eines Abschnitts am Anfang des nächsten, damit ein zerschnittener Satz irgendwo noch vollständig auftaucht. Die dritte schneidet nach Struktur und nutzt Überschriften, Unterabschnitte oder Tabellenzeilen als natürliche Grenze. Die vierte schneidet nach semantischer Ähnlichkeit, misst also, wo das Thema wechselt, und trennt genau dort.

Die konkreten Werte hängen vom System ab. Die RAG-Engine von Vertex AI, von Google, startet mit 1.024 Token pro Abschnitt und 256 Token Überlappung, aber das ist der Standardwert eines Produkts und keine allgemeine Empfehlung. Die Dokumentation selbst beschreibt den Zielkonflikt, ohne ihn aufzulösen: Ein kleiner Abschnitt erzeugt präzisere Repräsentationen, ein großer erzeugt allgemeinere, die Details verlieren können.

Der typische Fehler tritt auf, wenn der Zusammenhang jenseits der Grenze liegen bleibt. Anthropic zeigt das an einem Abschnitt, der von einem Umsatzwachstum von 3 % gegenüber dem Vorquartal spricht, ohne Unternehmen und Zeitraum zu nennen. Allein abgerufen taugt dieses Stück zu nichts, weil es keines der Wörter enthält, nach denen jemand fragen würde. Der vorgeschlagene Ausweg war, jedem Abschnitt vor der Indexierung einen Satz voranzustellen, der ihn in seinem Dokument verortet. In der eigenen Auswertung sank die Fehlerquote beim Abruf dadurch von 5,7 % auf 3,7 %; kombiniert mit lexikalischer Suche auf 2,9 %, und mit einer zusätzlichen Neusortierung auf 1,9 %.

Die Entscheidung, die daran hängt, ist eine Budgetentscheidung. Wenn du dein eigenes Retrieval betreibst, sind Größe und Grenze der Abschnitte der billigste Hebel, den du auf die Antwortqualität hast, noch vor einem Modellwechsel. Es lohnt sich, ihn mit deinen Dokumenten und deinen echten Fragen zu messen, bevor du irgendetwas anderes anfasst.

Geht es dagegen darum, in Suchmaschinen und Assistenten zitiert zu werden, fällt die ehrliche Antwort unbequemer aus. Google dokumentiert ein System namens Passage Ranking, das einzelne Abschnitte einer Seite identifiziert, um deren Relevanz besser zu bewerten, und stellte es als Verbesserung für 7 % der Suchanfragen vor. Dokumentiert ist, was dieses System tut. Nicht dokumentiert ist, mit welchen Grenzen es arbeitet, und nirgends steht, dass die Länge deiner Absätze diese Grenzen beeinflusst.

Für den Ratschlag, der daraus abgeleitet wird, gibt es dagegen eine direkte Quelle, und sie sagt das Gegenteil des Ratschlags. Google schreibt in seinem Leitfaden zur Optimierung für generative Funktionen, es sei nicht nötig, Inhalte in winzige Stücke zu zerlegen, damit die KI sie versteht, und die eigenen Systeme kämen mit mehreren Themen auf einer Seite zurecht. Der Budgetposten, eine ganze Website in Mini-Absätze umzuschreiben, hat also keinen dokumentarischen Rückhalt. Was der Prüfung standhält, ist bescheidener und ohnehin gute Redaktion: dass jeder Abschnitt für sich verständlich ist.

• Kläre zuerst, wem das Chunking gehört. Gehört es dir, dann miss es mit deinen Daten. Gehört es einem Dritten, behandle es als Parameter, den du nicht steuerst, und misstraue jedem, der dir das Gegenteil verkauft.
• Sorge dafür, dass jeder Abschnitt allein trägt. Ausdrückliches Subjekt am Anfang, kein »das«, »das Vorige« oder »wie erwähnt« über eine Überschrift hinweg.
• Wiederhole den Eigennamen statt des Pronomens, wenn der Bezug in einem anderen Abschnitt steht. Das kostet ein Wort und rettet den Chunk.
• Schließe die Angabe mit ihrem Kontext im selben Block ab: die Zahl mit Einheit, Datum und Geltungsbereich, nicht auf zwei Abschnitte verteilt.
• Nutze Überschriften als echte Grenze und nicht als typografische Zierde, damit eine Zerlegung nach Struktur dort landet, wo du sie haben willst.
• Wenn du ein eigenes System betreibst, miss vor dem Kopieren. Ein Satz aus dreißig echten Fragen mit notierter richtiger Antwort ist mehr wert als jede in einem Artikel empfohlene Zahl.

• Die Website in zweizeilige Absätze umschreiben, um »zitiert zu werden«. Google sagt ausdrücklich, dass Inhalte nicht in winzige Stücke zerlegt werden müssen, also rechtfertigt sich dieser Aufwand nur, wenn er die Lesbarkeit verbessert.
• Eine Abschnittsgröße kopieren, ohne zu wissen, wer sie gemessen hat. Die kursierenden Zahlen stammen aus einzelnen Experimenten mit einem bestimmten Modell und einer bestimmten Aufgabe und lassen sich nicht einfach übertragen.
• Passage Ranking mit Chunking verwechseln. Ersteres ist ein von Google dokumentiertes Ranking-System, Letzteres ein Vorbereitungsschritt in Retrieval-Systemen. Sie treffen sich in der Intuition und nicht im Mechanismus.
• Die Überlappung auf null setzen und später feststellen, dass die wichtigen Definitionen genau auf der Naht zwischen zwei Abschnitten liegen.
• Tabellen, Listen und nummerierte Schritte mittendurch trennen. Eine halbe Tabelle ohne Kopfzeile ist Rauschen, das wie eine Angabe aussieht.