Chunking

Warum werden Dokumente überhaupt in Chunks zerlegt?

Ein Handbuch mit 200 Seiten ist als einzelne Retrieval-Einheit meist zu grob. Eine Nutzerfrage betrifft häufig nur wenige Absätze. Würde das gesamte Dokument in einen Prompt gelegt, entstünden unnötiger Kontext, höhere Verarbeitungskosten und eine schwierigere Relevanzbewertung.

Chunking zerlegt Inhalte deshalb in kleinere Einheiten. Jeder Chunk kann separat indexiert, mit Metadaten versehen und bei einer Anfrage abgerufen werden. Die zentrale Frage lautet jedoch nicht „Wie viele Zeichen pro Chunk?“, sondern: Welche Einheit enthält genug Kontext, um fachlich verständlich zu bleiben, und ist gleichzeitig präzise genug, um gezielt gefunden zu werden?

Fachliche Grundlage: Retrieval-Granularität ist eine Designentscheidung

Chen et al. untersuchten 2024 in „Dense X Retrieval“, wie sich unterschiedliche Retrieval-Einheiten wie Dokumente, Passagen, Sätze und Propositionen auswirken. Die Studie zeigt, dass die Granularität die Retrieval-Leistung und nachgelagerte Aufgaben deutlich beeinflussen kann. Damit ist Chunking kein rein technisches Vorverarbeitungsthema, sondern Teil des Retrieval-Designs.

Hinzu kommt die Nutzung langen Kontexts durch Sprachmodelle. Liu et al. fanden in „Lost in the Middle“, dass relevante Informationen je nach Position im langen Kontext unterschiedlich zuverlässig genutzt werden können. Ein möglichst großes Kontextfenster ersetzt daher keine sinnvolle Auswahl und Strukturierung.

Welche Chunking-Strategien gibt es?

Feste Länge

Text wird nach einer festen Zahl von Zeichen oder Token getrennt. Das ist einfach und reproduzierbar, kann aber Sätze oder logische Abschnitte ungünstig zerschneiden.

Absatz- oder Überschriften-basiert

Dokumentstruktur wie Überschriften, Absätze oder Listen bildet die Grenze. Dadurch bleibt semantischer Kontext häufiger erhalten.

Überlappende Chunks

Benachbarte Chunks teilen einen Teil ihres Inhalts. Das reduziert das Risiko, dass wichtige Informationen genau an einer Grenze getrennt werden, erzeugt aber Redundanz im Index.

Semantisches Chunking

Grenzen werden anhand inhaltlicher Veränderungen oder sprachlicher Einheiten bestimmt. Das kann fachlich sinnvollere Einheiten erzeugen, ist aber komplexer und muss zur Dokumentstruktur passen.

Gibt es eine ideale Chunk-Größe?

Nein. Eine pauschale Empfehlung wie „immer 500 Token“ ignoriert Domäne, Dokumenttyp und Suchfrage. Ein juristischer Absatz, eine API-Dokumentation, eine Produktdatentabelle und ein FAQ benötigen unterschiedliche Einheiten.

Die richtige Größe sollte empirisch getestet werden. Dafür können reale Fragen gesammelt und geprüft werden: Ist der relevante Inhalt im Top-k-Retrieval? Enthält der Chunk genug Kontext für eine korrekte Interpretation? Werden zu viele irrelevante Abschnitte gefunden?

Chunking und Metadaten gehören zusammen

Beim Zerlegen eines Dokuments sollten Herkunft und Struktur nicht verloren gehen. Sinnvolle Metadaten sind beispielsweise:

• Dokument-ID und Version,
• Kapitel und Überschrift,
• Seiten- oder Abschnittsreferenz,
• Produkt, Mandant oder Gültigkeitsbereich,
• Erstellungs- beziehungsweise Änderungsdatum,
• Zugriffsrechte.

So kann ein einzelner Treffer in seinen ursprünglichen Kontext zurückgeführt und gegebenenfalls gefiltert werden.

Typische Fehler

• Zu große Chunks: relevante Information geht in viel Begleittext unter.
• Zu kleine Chunks: Aussagen verlieren Voraussetzungen, Referenzen oder Definitionen.
• Blindes Overlap: zu viel Redundanz führt zu fast identischen Treffern.
• Strukturverlust: Tabellen, Überschriften und Hierarchien werden beim Extrahieren zerstört.
• Keine Evaluation: Chunk-Größe wird aus einem Blogpost übernommen, ohne den eigenen Datenbestand zu testen.

Praxisbeispiel

Ein Wartungshandbuch beschreibt zuerst einen Fehlercode und auf der nächsten Seite die zugehörige Sicherheitswarnung. Ein rein seitenbasiertes Chunking könnte beides trennen. Eine strukturorientierte Strategie kann dagegen Fehlercode, Warnung und Handlungsempfehlung als gemeinsame fachliche Einheit behandeln.

Wie evaluiert man eine Chunking-Strategie?

Ein sinnvoller Test trennt Retrieval und Antwortgenerierung. Zunächst wird geprüft, ob für reale Fragen überhaupt der richtige Chunk unter den Top-Treffern liegt. Danach wird bewertet, ob dieser Chunk genug Kontext für eine fachlich korrekte Antwort enthält. So lässt sich erkennen, ob ein Fehler aus Chunking/Retrieval oder erst aus dem Sprachmodell entsteht.

Zusätzlich sollten verschiedene Dokumenttypen getrennt betrachtet werden. Ein pauschaler Splitter für Fließtext, Tabellen, Verträge und technische Handbücher ist selten optimal. Dokumentstruktur ist selbst ein wichtiges Signal und sollte beim Ingest möglichst erhalten bleiben.

Fazit

Chunking bestimmt, in welchen Einheiten ein Wissensbestand überhaupt auffindbar wird. Für RAG und Semantic Search ist es deshalb eine zentrale Qualitätsentscheidung. Gute Chunking-Strategien orientieren sich an Dokumentstruktur und Nutzerfragen und werden mit realen Retrieval-Tests validiert.