
Welche Chunking-Strategien funktionieren für RAG-Systeme wirklich?
Direkte Antwort
Es gibt keine universell richtige Chunk-Größe. Fixed-Size-Chunking mit Overlap ist der robuste Standardfall, semantisches Chunking entlang von Absätzen oder Überschriften funktioniert besser bei strukturierten Dokumenten, und rekursives Chunking mit mehreren Trennzeichen-Ebenen ist der pragmatischste Kompromiss für gemischte Dokumentbestände.
"Ein zu kleiner Chunk verliert Kontext, ein zu großer Chunk verwässert Relevanz — beide Fehler zeigen sich erst im Retrieval, nicht im Chunking selbst.
Ein produktives RAG-System scheitert selten am LLM, sondern häufig an der Chunking-Strategie, die vor jeder Suche über die Qualität der Ergebnisse entscheidet.
Warum die Chunk-Größe die Suchqualität bestimmt
Ein Embedding-Modell komprimiert einen Chunk in einen einzigen Vektor. Ist der Chunk zu lang, mischen sich mehrere Themen in einem Vektor, und die Suche wird ungenau, weil kein einzelnes Thema mehr klar repräsentiert ist.
Ist der Chunk zu kurz, etwa ein einzelner Satz, fehlt dem Modell später der Kontext, um die Aussage korrekt einzuordnen — eine Tabellenzeile ohne Tabellenüberschrift ist ein klassisches Beispiel dafür.
Drei Strategien im Vergleich
Fixed-Size-Chunking teilt Text in feste Zeichen- oder Token-Blöcke mit 10 bis 20 Prozent Overlap. Es ist einfach zu implementieren und funktioniert vorhersagbar, ignoriert aber Dokumentstruktur komplett.
Semantisches Chunking orientiert sich an Absätzen, Überschriften oder Similarity-Brüchen zwischen aufeinanderfolgenden Sätzen. Es liefert inhaltlich kohärentere Chunks, braucht aber mehr Vorverarbeitung und liefert bei schlecht strukturierten Quelldokumenten unvorhersagbare Chunk-Größen. Rekursives Chunking versucht zuerst entlang großer Trenner (Kapitel, Absätze) zu teilen und fällt erst bei Überschreiten der Zielgröße auf kleinere Trenner (Sätze, Wörter) zurück — das ist der in der Praxis am häufigsten produktiv eingesetzte Kompromiss.
Sonderfälle, die Standard-Chunking bricht
Tabellen, Code-Blöcke und verschachtelte Listen verlieren bei naivem Chunking ihre Struktur und damit ihre Bedeutung.
Für Tabellen hat sich bewährt, jede Zeile mit den zugehörigen Spaltenüberschriften zu duplizieren; für Code-Blöcke sollte die Chunk-Grenze nie innerhalb einer Funktion liegen. Wer das ignoriert, bekommt technisch korrekt aussehende, inhaltlich aber unbrauchbare Retrieval-Treffer.
Wann passt es — wann nicht?
Passt gut
- ✓Der Dokumentbestand ist überwiegend Fließtext ohne komplexe Struktur
- ✓Dokumente haben klare Überschriftenhierarchien (Handbücher, technische Doku)
- ✓Der Bestand ist gemischt aus Markdown, PDF und Tickets
Passt nicht
- ✗Der Bestand enthält überwiegend Tabellen oder strukturierte Daten
- ✗Es gibt nur wenige, kurze Dokumente, die komplett in den Kontext passen