CHUNKING · AI-KONZEPT
Chunking-Strategien für RAG: Fixed-Size, Recursive, Semantic, Late-Chunking
Wie Sie Dokumente für RAG schneiden: Fixed-Size, Recursive, Semantic, Document-based und Late-Chunking im Vergleich plus Faustregeln für Verträge, Tabellen und mehrsprachige Texte.
Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05
Was ist Chunking?
Chunking ist das Zerteilen langer Dokumente in Stücke (Chunks), die in eine Vektor-Datenbank indexiert werden. Jeder Chunk wird einzeln als Embedding gespeichert, einzeln gefunden und einzeln in den Prompt eines Sprachmodells gesteckt. Die Wahl der Chunking-Strategie entscheidet zu 30 bis 50 Prozent über die Antwort-Qualität einer RAG-Pipeline, oft mehr als die Wahl des Embedding-Modells.
Im Mai 2026 sind fünf Strategien etabliert. Fixed-Size schneidet alle N Tokens, blind für Struktur. Recursive Character Splitting (LangChain-Standard) bricht zuerst nach Absatz, dann nach Satz, dann nach Wort, bis die Ziel-Grösse erreicht ist. Semantic Chunking berechnet Embedding-Ähnlichkeit aufeinanderfolgender Sätze und schneidet bei semantischen Bruechen. Document-based Chunking respektiert die Datei-Struktur: Markdown-Header, PDF-Bookmarks, HTML-Sections. Late-Chunking (Jina AI, 2024) embeddet zuerst das ganze Dokument im Kontext und schneidet erst danach, sodass jeder Chunk die Bedeutung des Gesamtkontextes trägt.
Die Wahl hängt vom Dokumenttyp ab: Verträge und Wegleitungen profitieren von Document-based, weil ihre Gliederung Bedeutung trägt. Lange Fliesstexte profitieren von Semantic Chunking. Tabellarische Daten brauchen oft gar kein Chunking, sondern einen eigenen Indexierungs-Pfad.
Warum es wichtig ist
Schlechtes Chunking zeigt sich nicht im Code, sondern in falschen Antworten. Wer einen 30-seitigen Mietvertrag in 500-Token-Blöcke schneidet, ohne Kapitel-Grenzen zu respektieren, riskiert, dass Paragraph 4.2 (Nebenkosten) und Paragraph 4.3 (Index-Klausel) im selben Chunk landen oder dass eine Tabelle mittendurch zerschnitten wird. Das Sprachmodell bekommt dann halbe Sätze und halluziniert den Rest.
Für Treuhand-, Anwalts- und Versicherungs-Kontexte ist die Folge nicht nur Komfort-Verlust. Eine falsch beantwortete Mandanten-Frage zur Kündigungsfrist eines Vertrages kann haften. Deshalb ist Chunking ein Compliance-Thema, nicht nur ein Engineering-Thema. Wer revisionsfähige RAG-Systeme nach Art. 957a OR oder unter Berufsgeheimnis (StGB Art. 321) betreibt, muss die Chunking-Strategie dokumentieren und auf Re-Indexierung bei Strategie-Wechsel achten.
Kostenseitig ist Chunking ebenfalls relevant. Zu kleine Chunks (unter 200 Tokens) bedeuten mehr Embedding-Calls und mehr Vektor-Datenbank-Storage, ohne dass die Qualität zunimmt. Zu grosse Chunks (über 2000 Tokens) verwässern das Embedding, weil zu viele Themen zusammengefasst werden, und sprengen oft das Kontext-Fenster bei Top-k-Retrieval.
Wie es funktioniert
Fixed-Size: Token- oder Zeichen-Counter zählt bis N und schneidet. Simpel, deterministisch, schnell. Im Mai 2026 nur noch für rein technische Logs oder als Notlösung empfohlen.
Recursive Character Splitting: Liste von Trennzeichen (\n\n, \n, ., , Leerzeichen) wird rekursiv versucht. Beim ersten Treffer, der die Ziel-Grösse einhält, wird geschnitten. LangChain RecursiveCharacterTextSplitter und LlamaIndex SentenceSplitter sind die De-facto-Standards. Faustregel: 500 bis 1000 Tokens Chunk-Grösse mit 10 bis 20 Prozent Overlap (50 bis 200 Tokens).
Semantic Chunking: Sätze werden einzeln embedded; die Ähnlichkeit zwischen aufeinanderfolgenden Sätzen wird gemessen. Fällt sie unter einen Schwellwert (z.B. Perzentil 95), wird geschnitten. Greg Kamradts 5-Levels-Notebook (2024) ist die Referenz-Implementation. Vorteil: thematische Grenzen werden respektiert. Nachteil: zusätzliche Embedding-Kosten beim Indexieren.
Document-based Chunking: Strukturmarker (Markdown-Header, PDF-Bookmarks, DOCX-Style-Heading, HTML-Tags) werden zuerst extrahiert, dann pro Abschnitt geschnitten. Tools: MarkdownHeaderTextSplitter (LangChain), Unstructured.io, MarkItDown (Microsoft, Mai 2026). Bei sauberen Quellen die qualitativ beste Strategie.
Late-Chunking: Das gesamte Dokument geht zuerst in ein Long-Context-Embedding-Modell (Jina-Embeddings-v3, max 8192 Tokens). Der Embedding-Vektor wird pro Token-Position ausgelesen, dann erst aggregiert pro Chunk. Vorteil: jeder Chunk-Vektor "weiss", was vorher und nachher im Dokument stand. Mai 2026 noch experimentell, aber bei juristischen Texten messbar besser (Retrieval-Recall +5 bis +12 Prozent).
Für PDFs mit Tabellen empfehlen wir einen hybriden Pfad: erst Layout-Erkennung (Marker, Unstructured Hi-Res), Tabellen separat als Markdown serialisieren, Fliesstext document-based chunken. Lange Verträge über 100 Seiten brauchen Multi-Granularität: ein Chunk pro Paragraph plus ein Summary-Chunk pro Kapitel. Mehrsprachige Dokumente (DE/FR/IT in einem PDF) dürfen nicht über Sprachgrenzen hinweg gechunkt werden, sonst kollabiert das Embedding.
Chunking-Workflow in 6 Schritten
- 01Dokumente klassifizieren: Wegleitung, Vertrag, Mail, Tabelle, Code. Pro Klasse separate Pipeline.
- 02Pro Klasse die passende Strategie: Recursive für Default, Document-based für Markup, Semantic für Fliesstext, Late-Chunking für Long-Context-Bedürfnisse.
- 03Chunk-Grösse und Overlap parametrisieren: Default 800 Tokens plus 100 Tokens Overlap, dann iterieren mit Eval-Set.
- 04Metadaten an jeden Chunk anhängen: Quelle, Seite, Mandant, Datum, Vertraulichkeits-Tier. Filter-fähig in Qdrant Payload.
- 05Eval-Set mit 30 bis 50 Frage-Antwort-Paaren bauen und Retrieval-Recall@5 messen. Strategie nur wechseln, wenn Recall steigt.
- 06Re-Indexing-Strategie definieren: bei Schema-Wechsel komplett, bei Einzeldokument-Update nur betroffene Chunks (idempotente Pipeline nötig).
Wann welche Strategie
Recursive Character Splitting mit 500 bis 1000 Tokens und 10 bis 20 Prozent Overlap ist der sichere Default für fast jeden Einstieg. Wenn Sie nicht wissen, was Sie tun, fangen Sie hier an.
Document-based Chunking lohnt sich, sobald die Quellen strukturierte Markup-Information tragen: Markdown-Wegleitungen, technische Dokumentationen mit Bookmarks, Verträge mit klarer Paragraphen-Nummerierung. Der Setup-Aufwand ist höher (Parser-Wahl), aber die Antwort-Qualität steigt deutlich.
Semantic Chunking spielt seine Stärken aus bei langem Fliesstext ohne klare Struktur: Sitzungsprotokolle, Interview-Transkripte, lange Mail-Threads. Hier fehlen Marker, und thematische Bruechen liefern den besten Schnitt.
Late-Chunking probieren Sie bei juristischen oder medizinischen Texten, in denen Begriffe nur im Kontext eindeutig sind ("der Beklagte" referenziert auf Paragraph 1, taucht aber erst in Paragraph 17 auf). Voraussetzung: ein Long-Context-Embedding-Modell und genug Rechenkapazität.
Fixed-Size nur für Loganalyse, Telemetrie oder andere strukturlose Daten.
Wann gar nicht chunken
Kleine Dokumentensammlungen unter 50 Seiten Gesamttext: hier passt alles in den Prompt eines modernen Long-Context-Modells (Claude Sonnet: 1M Tokens, Gemini 2.5 Pro: 2M Tokens). Chunking spart in dieser Konstellation nichts und macht die Pipeline fragiler.
Tabellen und strukturierte Daten: eine Bilanz-Tabelle gehört nicht ins Embedding, sondern in eine SQL-Tabelle oder als JSON-Document mit Filter-Feldern in Qdrant Payload. RAG über unstrukturiertes Embedding ist hier das falsche Werkzeug.
Code-Repositories: Funktions- und Class-Grenzen sind die richtigen Chunks, nicht Token-Counts. Tree-sitter-basierte Splitter (z.B. LangChain Language-aware) sind hier überlegen.
Bilder, Pläne, Skizzen: brauchen Vision-Embeddings (CLIP, Cohere Embed v3 multimodal) oder eine eigene OCR-Strecke, kein Text-Chunking.
Vor- und Nachteile
STÄRKEN
- Document-based: höchste Antwort-Qualität bei strukturierten Quellen
- Recursive: robuster Default, sehr schnell, gut dokumentiert
- Semantic: respektiert thematische Bruechen in Fliesstext
- Late-Chunking: behält globalen Kontext pro Chunk-Vektor
SCHWÄCHEN
- Document-based: parser-abhängig, scheitert bei schlecht strukturierten PDFs
- Recursive: ignoriert Bedeutung, schneidet manchmal mitten in Listen
- Semantic: doppelte Embedding-Kosten beim Indexieren
- Late-Chunking: experimentell, benötigt Long-Context-Embedding-Modell
Häufige Fragen
Welche Chunk-Grösse ist optimal?
Faustregel: 500 bis 1000 Tokens mit 10 bis 20 Prozent Overlap. Für Frage-Antwort-Systeme tendiert die Forschung (Anthropic Contextual Retrieval, 2024) zu eher kleineren Chunks (200 bis 400 Tokens) plus Kontext-Präfix. Für Summarization-Systeme eher grössere (1000 bis 1500). Messen Sie mit Recall@5 auf einem Eval-Set, raten Sie nicht.
Brauche ich Overlap zwischen Chunks?
Ja, aber massvoll. 10 bis 20 Prozent reichen, um abgeschnittene Sätze zu vermeiden. Mehr Overlap erhöht Storage und Inferenz-Kosten, ohne Retrieval-Recall nennenswert zu verbessern. Bei document-based Chunking kann Overlap entfallen, weil Strukturmarker scharfe Grenzen geben.
Wie chunke ich PDFs mit Tabellen?
Zwei Pfade parallel. Layout-Erkennung (Marker, Unstructured Hi-Res, Microsoft Table Transformer) extrahiert Tabellen als Markdown oder JSON. Diese gehen in eine separate Collection mit strukturierten Filter-Feldern. Fliesstext wird document-based gechunkt. Ein Cross-Reference-Feld in der Payload verknüpft Tabelle und Erklärungstext.
Late-Chunking lohnt sich wann?
Bei langen, kontextabhängigen Texten (Verträge, Gerichtsurteile, wissenschaftliche Paper) und wenn Sie ein Long-Context-Embedding-Modell wie Jina-Embeddings-v3 (8192 Tokens) bereits einsetzen. Bei kurzen oder thematisch klar getrennten Dokumenten ist der Gewinn vernachlässigbar.
Verwandte Themen
Quellen
PASSEND ZU IHREM STACK?