Chunking-Strategien für RAG: Fixed, Semantic, Hierarchical und Late Chunking im Vergleich

Chunking-Strategien für RAG legen fest, wie ein Dokument vor dem Embedding in durchsuchbare Textabschnitte - sogenannte Chunks - zerlegt wird. Die Wahl der Strategie und der Chunk-Größe entscheidet maßgeblich über die Retrieval-Qualität: Sie bestimmt, ob ein Sprachmodell die richtige Passage findet und ob diese genug Kontext für eine korrekte, quellengestützte Antwort enthält. Chunking ist damit der unscheinbarste, aber wirkungsvollste Hebel im gesamten RAG-Stack.

• Default-Empfehlung: 200-800 Tokens pro Chunk, 10-20 % Overlap, davor immer Layout-aware Parsing.
• Häufigster Fehler: Naives Fixed-Size-Chunking zerschneidet Sätze, Tabellen und Listen - eine der Hauptursachen für Halluzinationen.
• Bester Allrounder 2026: Hierarchisches Parent-Child-Chunking, optional kombiniert mit Contextual Retrieval (Anthropic: bis -67 % Retrieval-Fehler).

Warum Chunking über Erfolg oder Misserfolg entscheidet

In einer RAG-Pipeline wird jedes Quelldokument zerlegt, jeder Chunk wird in einen Vektor (Embedding) übersetzt und in einer Vektordatenbank abgelegt. Zur Laufzeit sucht das System die zur Nutzerfrage ähnlichsten Chunks und gibt sie dem Sprachmodell in den Prompt. Das bedeutet: Was nicht sauber gechunkt wurde, kann gar nicht erst gefunden werden - und was gefunden, aber ohne Kontext geschnitten wurde, führt das Modell in die Irre.

Zwei Fehlerklassen dominieren in der Praxis. Erstens ignoriert naives Fixed-Size-Chunking Satz-, Tabellen- und Listengrenzen; das Resultat sind Halluzinationen und fehlende Tabelleninhalte. Zweitens das "Lost-in-the-chunks"-Problem: Ein Chunk enthält den Satz "Er erhöhte sich um 12 %" - ohne den umgebenden Kontext bleibt unklar, was sich erhöhte. Beide Probleme entstehen vor dem Embedding und lassen sich später durch kein noch so gutes Re-Ranking reparieren.

Die sechs Chunking-Strategien im Überblick

Fixed-size Chunking zerschneidet Text in feste Fenster, etwa 512 Tokens mit einem Overlap von 50 Tokens. Es ist schnell, deterministisch und kostengünstig - aber inhaltsblind. Geeignet für gleichförmige Texte wie Logs oder Transkripte.

Recursive Character / Sentence Splitting zerlegt hierarchisch entlang von Trennzeichen (Absätze, dann Sätze, dann Wörter) und respektiert dabei natürliche Grenzen. Das ist der generische Default vieler Frameworks (LangChain) und ein guter Ausgangspunkt für gemischte Korpora.

Sentence-window ist eine Variante davon: Embedded und durchsucht wird auf Satzebene, an das LLM wird aber ein Fenster aus den umgebenden Sätzen übergeben - ein leichtgewichtiger Vorläufer des Parent-Child-Prinzips.

Semantic Chunking misst die Cosine-Distanz zwischen aufeinanderfolgenden Sätzen und setzt den Schnitt dort, wo der inhaltliche Zusammenhang abreißt (Cosine-Drift). Das liefert bei inhaltlich heterogenen Dokumenten kohärente Chunks, ist in der Indexierung aber rechenintensiver, weil jeder Satz vorab embedded werden muss.

Hierarchical / Parent-Child Chunking entkoppelt Retrieval von Generierung: Kleine Child-Chunks dienen als präzises Suchziel, der zugehörige große Parent-Chunk wird dem Generator als Kontext mitgegeben. Diese Strategie ist für lange Reports und technische Manuals häufig die beste Wahl.

Late Chunking ist ein neuerer Ansatz, der die Reihenfolge umkehrt: Statt den Text vor dem Embedding zu schneiden, wird zuerst das gesamte (lange) Dokument durch ein Long-Context-Embedding-Modell verarbeitet, und erst die resultierenden Token-Embeddings werden anschließend zu Chunk-Vektoren gepoolt. Dadurch trägt jeder Chunk-Vektor den Kontext des Gesamtdokuments in sich. Der Ansatz verfolgt dasselbe Ziel wie Contextual Retrieval - das Lost-in-the-chunks-Problem zu lösen - benötigt aber keinen zusätzlichen LLM-Aufruf pro Chunk. Er ist jedoch vergleichsweise jung und weniger breit erprobt und setzt ein Long-Context-fähiges Embedding-Modell voraus; die jeweils unterstützte Kontextlänge und das Pooling-Verhalten sollten Sie vor produktivem Einsatz mit der aktuellen Anbieterdokumentation des gewählten Modells abgleichen.

Ergänzend lohnen zwei weitere Verfahren: Propositional Chunking zerlegt Text in atomare Einzelaussagen und eignet sich für sehr präzise Faktenextraktion, sowie Contextual Chunking (siehe unten), das jedem Chunk einen erklärenden Kontext-Header voranstellt.

Vergleichstabelle: Wann welche Strategie?

Tradeoffs: Chunk-Size und Overlap

Die Chunk-Größe ist ein klassischer Zielkonflikt. Kleine Chunks (z. B. 256 Tokens) erzeugen schärfere Embeddings und präzisere Treffer für punktuelle Faktenfragen, riskieren aber Kontextverlust. Große Chunks (z. B. 800 Tokens und mehr) transportieren mehr Zusammenhang, verwässern aber das Embedding und erhöhen das Risiko, dass die relevante Information im "Lost-in-the-middle"-Effekt des LLM untergeht. Übergroße Top-k-Mengen an das Modell verschärfen das zusätzlich - die Empfehlung lautet daher, nach dem Retrieval per Re-Ranker auf top_k = 5-10 zu verdichten.

Der Overlap (überlappende Tokens zwischen benachbarten Chunks) verhindert, dass ein Gedanke genau an der Schnittkante zerrissen wird. 10-20 % der Chunk-Größe sind ein bewährter Richtwert. Mehr Overlap erhöht Redundanz, Speicherbedarf und Indexierungskosten, ohne die Qualität proportional zu steigern.

Ein für DACH-Korpora oft unterschätzter Faktor: Deutsche Komposita wie "Datenschutz-Folgenabschätzung" erzeugen je nach Tokenizer (BPE/SentencePiece) deutlich mehr Tokens als ihr englisches Äquivalent. Als Faustregel ist Deutsch je nach Modell rund 1,3-1,7x tokenintensiver. Das senkt die effektive inhaltliche Kapazität eines 512-Token-Chunks - eine in Tokens definierte Größe transportiert auf Deutsch also weniger Sachinhalt als auf Englisch.

Konkretes Beispiel mit Zahlen

Angenommen, Sie indexieren 10.000 technische PDF-Seiten (Verträge und Produkt-Manuals).

1. Parsing: Layout-aware mit einem Parser wie Docling oder Unstructured, damit Tabellen, Listen und Überschriften erhalten bleiben.
2. Chunking: Parent-Child. Parent-Chunks zu ca. 1.500 Tokens (ganze Abschnitte), Child-Chunks zu ca. 300 Tokens mit 15 % Overlap.
3. Embedding-Ziel: die Child-Chunks; an das LLM geht der jeweilige Parent.
4. Optional Contextual Header: Pro Chunk ein kurzer LLM-generierter Kontextsatz vor dem Embedding. Laut Anthropic (Stand 2024) sinkt die Top-20-Retrieval-Fehlerrate dadurch von 5,7 % auf 2,9 % (-49 %), in Kombination mit Re-Ranking auf 1,9 % (-67 %); Contextual Embeddings allein bringen -35 %. Die Indexierungskosten liegen bei etwa 1,02 US-Dollar pro 1 Mio. Dokument-Tokens mit Prompt-Caching (Anthropic-Pricing, Stand September 2024 - vor Einsatz aktualisieren).

Pseudocode für den hierarchischen Schnitt:

```
parents = split(document, size=1500, separators=["\n## ", "\n\n"])
for p in parents:
children = split(p, size=300, overlap=45) # 15 % von 300
for c in children:
c.context = llm("Worum geht es in diesem Abschnitt?", p) # optional
index.upsert(embed(c.context + c.text), parent_ref=p.id)
```

So testet man die richtige Strategie

Chunking-Entscheidungen werden nicht geraten, sondern gemessen. Das Vorgehen:

• Goldset bauen: 50-200 reale Nutzerfragen, jeweils mit der korrekten Quell-Passage annotiert. Ohne Goldset hilft LLM-as-Judge (RAGAS reference-free) oder ein synthetisch generiertes Testset.
• Varianten indexieren: Denselben Korpus mehrfach chunken - etwa Fixed-512, Recursive-300, Semantic, Parent-Child - bei sonst identischer Pipeline.
• Mit RAGAS messen: Die zentralen Metriken sind Context Precision und Context Recall (Treffer die richtigen Passagen?) sowie Faithfulness und Answer Relevancy (stützt sich die Antwort wirklich auf den Kontext?).
• A/B in Produktion: Die im Offline-Test führende Variante gegen die bestehende ausspielen und reale Signale (Klicks, Nutzer-Feedback) beobachten.

Wichtig: Ändert sich das Embedding-Modell, ist eine vollständige Re-Indexierung nötig - Embeddings verschiedener Modelle sind nicht vergleichbar. Versehen Sie Indizes daher mit einem Versionsstring.

Für Agenturen und B2B-Entscheider

Chunking ist kein Setup-Detail, das man einmal konfiguriert und vergisst, sondern die Stellschraube mit dem höchsten Hebel auf die Antwortqualität Ihres RAG-Systems - und damit auf das Vertrauen, das Kunden und Mitarbeitende ihm entgegenbringen. Wer hier mit naivem Fixed-Size-Chunking startet, zahlt später mit Halluzinationen, Support-Eskalationen und teuren Nachbesserungen. Als Agentur Blck Alpaca (Wien) konzipieren und evaluieren wir RAG-Pipelines für DACH-Unternehmen messbar entlang RAGAS-Metriken - inklusive deutschsprachiger Tokenisierung, EU-konformem Hosting und einer Chunking-Strategie, die zu Ihren Dokumenten und Fragen passt. Sprechen Sie uns an, bevor Sie produktiv gehen, statt danach zu reparieren.