Chunking-Strategien 2026
Wissen
Chunking bestimmt, was dein RAG-System findet. Egal wie gut dein Embedding-Modell ist, egal wie schnell deine Vector Database -- wenn die Chunks schlecht geschnitten sind, liefert das System schlechte Ergebnisse. Chunking ist der stille Qualitätshebel jeder RAG-Pipeline.
Die drei zentralen Strategien 2026:
- Fixed-Size Chunking: Dokumente in Abschnitte fester Tokenlänge schneiden
- Semantic Chunking: An inhaltlichen Bruchstellen schneiden, basierend auf Embedding-Ähnlichkeit
- Parent-Child Chunking: Hierarchische Struktur mit groben Eltern-Chunks und feinen Kind-Chunks
Verstehen
Fixed-Size Chunking -- Der Klassiker (und seine Grenzen)
Fixed-Size Chunking teilt Dokumente in Abschnitte gleicher Länge -- zum Beispiel 512 Tokens pro Chunk. Einfach zu implementieren, deterministisch, gut verständlich.
Das Problem: Text kümmert sich nicht um Tokenzahlen. Ein Chunk kann mitten im Absatz enden, einen Gedanken zerschneiden oder Kontext vom vorherigen Absatz abschneiden.
Overlap als Pflaster: Um zerschnittene Zusammenhänge zu retten, fügt man Überlappungen ein -- typisch 10--20% der Chunk-Größe. Bei 512 Tokens also 50--100 Tokens Overlap.
| Chunk-Größe | Overlap | Vorteil | Nachteil |
|---|---|---|---|
| 256 Tokens | 25 | Hohe Granularität, präzise Treffer | Viel Kontext geht verloren |
| 512 Tokens | 50 | Guter Kompromiss | Standard-Setting, nicht optimiert |
| 1024 Tokens | 100 | Mehr Kontext pro Chunk | Verwässert Relevanz bei kurzen Fragen |
iFixed-Size ist nicht tot
Für homogene Dokumente mit gleichmäßiger Informationsdichte (z.B. Log-Dateien, tabellarische Daten) funktioniert Fixed-Size Chunking nach wie vor gut. Es ist veraltet als Universallösung, nicht als Werkzeug.
Semantic Chunking -- Schneiden, wo der Inhalt es verlangt
Semantic Chunking analysiert den Text und identifiziert inhaltliche Bruchstellen. Der Algorithmus:
- Teile den Text in Sätze auf
- Berechne das Embedding für jeden Satz
- Vergleiche aufeinanderfolgende Satz-Embeddings (Cosine Similarity)
- Wenn die Ähnlichkeit unter einen Schwellenwert fällt, setze einen Chunk-Break
- Fasse die Sätze zwischen den Breaks zu Chunks zusammen
Das Ergebnis: Chunks, die thematische Einheiten bilden. Ein Absatz über Rückgabebedingungen bleibt zusammen, statt nach 512 Tokens mitten im Satz abgeschnitten zu werden.
Trade-offs:
- Nicht-deterministische Chunk-Größen (manche Chunks sind 200 Tokens, andere 800)
- Abhängig von der Qualität des Embedding-Modells
- Schwellenwert muss pro Dokumenttyp getuned werden
- Höherer Rechenaufwand bei der Indexierung
Ein Unternehmen indexiert Verträge mit klar strukturierten Abschnitten (Paragraphen, Klauseln, Unterpunkte). Welche Chunking-Strategie maximiert die Retrieval-Qualität?
Parent-Child Chunking -- Das Beste aus zwei Welten
Parent-Child Chunking löst ein fundamentales Dilemma: Kleine Chunks sind präzise für die Suche, aber liefern zu wenig Kontext für die Generierung. Große Chunks liefern Kontext, aber verwässern die Relevanz bei der Suche.
Die Lösung: Zwei Ebenen
- Kind-Chunks (klein, 100--300 Tokens): Werden für die Vektorsuche verwendet. Hohe Präzision beim Matching.
- Eltern-Chunks (groß, 500--1500 Tokens): Werden dem LLM als Kontext übergeben. Enthalten den vollständigen Zusammenhang.
Der Ablauf:
- Query-Embedding wird gegen die Kind-Chunks gesucht
- Die relevantesten Kind-Chunks werden identifiziert
- Statt der Kind-Chunks werden die zugehörigen Eltern-Chunks an das LLM übergeben
- Das LLM hat genug Kontext, um eine fundierte Antwort zu generieren
Beispieltext
20 Wörter pro Chunk, 5 Wörter Overlap. Schneidet manchmal mitten im Satz.
Chunks
6
Durchschn. Wörter
19
Overlap
5 Wörter
Vergleiche die drei Strategien und beobachte, wie sich Chunk-Größe und Qualität unterscheiden.
Warum verwendet Parent-Child Chunking unterschiedliche Chunks für Retrieval und Generierung?
Anwenden
Chunking-Strategie auswählen
| Dokumenttyp | Empfohlene Strategie | Begründung |
|---|---|---|
| Fließtext (Artikel, Berichte) | Semantic Chunking | Inhaltliche Bruchstellen bilden natürliche Einheiten |
| Strukturierte Dokumente (Verträge, Handbücher) | Strukturbasiert + Parent-Child | Vorhandene Gliederung nutzen, Hierarchie abbilden |
| Code-Dokumentation | Funktions-/Klassen-basiert | Logische Code-Einheiten als Chunks |
| Tabellarische Daten | Zeilen- oder Abschnittsbasiert | Zeilen als atomare Einheiten erhalten |
| Chat-Verläufe | Nachrichten-basiert mit Kontext-Window | Dialog-Turns als natürliche Einheiten |
Overlap-Strategien im Detail
Overlap ist keine Universallösung, aber oft nützlich:
- Token-Overlap: Feste Anzahl Tokens überlappen. Einfach, aber blind.
- Satz-Overlap: Ganze Sätze am Rand des vorherigen Chunks wiederholen. Erhält grammatische Vollständigkeit.
- Sliding Window: Chunks werden wie ein Fenster über den Text geschoben mit festem Schritt. Maximaler Overlap, aber auch maximale Redundanz in der DB.
Reflektieren
Überlege dir ein Szenario aus deiner Arbeitswelt: Welche Dokumente würdest du per RAG zugänglich machen? Welche Chunking-Strategie passt am besten -- und warum? Bedenke, dass die "richtige" Strategie immer vom Dokumenttyp und der Art der Fragen abhängt.