RAG-Chunking-Strategien: fixed, semantic, document-aware

TL;DR

• Pattern-Wahl: Document-aware Chunking (H1/H2/H3-Boundaries) ist 2026 der defensive Default für rund 80 % der Mittelstands-RAG-Setups — semantic nur bei unstrukturierten Quellen, hierarchical nur bei langen Verträgen oder Bedienungsanleitungen.
• Cost-Performance: Semantic-Chunking ist 2–3× rechenintensiver bei der Indexierung, liefert aber nur 5–8 % bessere Retrieval-Hit-Rate gegenüber Document-aware — bei strukturierter Doku verpufft der Hebel.
• Wann-was: Norm-Texte, SOPs, Wiki → Document-aware. Verträge, Handbücher, Studien → Hierarchical. E-Mails, Transkripte, freie Notizen → Semantic. Fixed-size 2026 nur noch für PoC.

Warum Chunking 80 % der RAG-Performance bestimmt

Jeder RAG-Setup hat drei kritische Pfade: Chunking, Embedding, Retrieval. Embedding-Modelle sind 2026 Commodity, Retrieval-Algorithmen well-understood. Chunking dagegen wird systematisch unterschätzt.

Falsche Chunks erzeugen eine Kaskade: zerrissener Kontext → falsche Embeddings → falsche Retrieval-Hits → halluzinierte Antworten. Das LLM kann am Ende nicht reparieren, was am Anfang verloren ging. In unseren Audits ist Chunking bei 70 % der gescheiterten RAG-Piloten die Wurzelursache — nicht das Modell, nicht der Embedding-Provider, nicht der Vector-Store.

Ein RAG-System ist nur so gut wie der schlechteste Chunk. Wer 100 Chunks gut macht und 5 schlecht, hat in 5 % der Queries eine halluzinierte Antwort — und genau die landen beim Auditor.

Vier Patterns im Vergleich

Verglichen nach drei Achsen: Indexierungs-Cost, Retrieval-Performance auf strukturierten Quellen, geeigneter Use-Case.

Document-aware schlägt Semantic in strukturierten Quellen um +8–11 Prozentpunkte Hit-Rate — bei 40 % niedrigerer Indexierungs-Cost. Das ist der defensive Sweet-Spot.

Wann welches Pattern

• Fixed-Size — Quick-Win, 2026 nur als PoC. Schneidet alle 512 oder 1024 Tokens ohne Rücksicht auf semantische oder strukturelle Grenzen. Trivial zu implementieren, deterministisch, 1× Cost — zerreißt aber Sätze, Tabellen und Bullet-Listen. Sobald der Pilot in Produktion soll, wird gewechselt.
• Semantic — wenn keine Struktur da ist. Nutzt ein Embedding-Modell, um an Stellen mit hoher semantischer Distanz zwischen aufeinanderfolgenden Sätzen zu schneiden. Liefert kohärente Themen-Blöcke, kostet aber 2–3× bei der Indexierung. Sinnvoll bei Sales-E-Mails, Meeting-Transkripten, Slack-Threads, Foren — alles ohne klare Markup-Struktur.
• Document-aware — der defensive Default. Nutzt die Dokument-Struktur (H1/H2/H3, Listen, Tabellen) als Boundary-Hinweis. Jede H2-Section wird ein Chunk, jede H3 optional eigener Chunk. Quasi gratis (1,2× Cost), nutzt die menschliche Strukturierungsarbeit direkt. Funktioniert hervorragend bei Norm-Texten (DIN, ISO, IEC), SOPs, Confluence-Wikis und technischen Handbüchern. Rund 80 % der DACH-Wissensbasen kommen damit durch.
• Hierarchical — lange Dokumente mit langen Hierarchien. Baut Parent-Child-Beziehungen: ein großer Parent-Chunk (das Kapitel) wird für Retrieval indexiert, kleinere Child-Chunks für den präzisen Antwort-Kontext. Löst das Trade-off zwischen Retrieval-Breite und Antwort-Präzision, kostet 1,8×. Sinnvoll bei Verträgen über 50 Seiten, Bedienungsanleitungen, klinischen Studien, Audit-Reports.

Praxis: MedTech-RAG mit Document-aware

Ein Mittelstand-Mandat aus Q1 2026 — MedTech-Hersteller, 3.200 SOPs in Confluence, 180 Norm-Dokumente (IEC 62304, ISO 13485, MDR Anhang II). Initial-Setup mit Fixed-Size 512 Tokens; der Pilot scheiterte nach 4 Wochen, weil Regulatory Affairs bei Compliance-kritischen Queries halluzinierte Antworten bekam.

Ergebnis: +23 Prozentpunkte Hit-Rate und –14 Prozentpunkte Halluzinations-Rate bei nur +21 % Indexierungs-Zeit. Das Cost-Performance-Verhältnis ist konkurrenzlos.

Overlap, Metadaten, Versionierung

• Overlap — 10 bis 15 % ist Industrie-Standard. Chunk-Overlap reduziert das Risiko, dass eine Antwort genau an einer Chunk-Grenze liegt. Unter 10 %: zu viele zerrissene Antworten. Über 20 %: Index bläht auf, Retrieval-Latency steigt. Default 12 %; bei sehr strukturierter Doku reichen 8 %, bei unstrukturierten Quellen braucht es 18–20 %.
• Metadaten — der unterschätzte Hebel. Jeder Chunk sollte Dokument-Titel, Section-Pfad, Datum, Autor, Version und Source-URL tragen. Diese Metadaten landen im Embedding-Payload und können beim Retrieval als Filter genutzt werden (»nur Chunks aus SOPs der letzten 6 Monate«). In MedTech-/Regulatorik-Kontexten ist Versions-Metadata Pflicht — sonst landet der Auditor in einer veralteten SOP-Antwort.
• Versionierung — Re-Index bei Dokument-Änderung. Wird eine SOP versioniert (V3.1 → V3.2), müssen alte Chunks aus dem Vector-Store entfernt und neue indexiert werden. Wer das übersieht, hat Doppelt-Hits mit widersprüchlichem Inhalt — der häufigste Grund für »RAG funktioniert nicht mehr nach 6 Monaten«. Lösung: jeder Chunk trägt doc_id + version; bei Update wird per Filter alles mit der alten Version gelöscht und neu indexiert.

Was 2026 nicht mehr funktioniert

Drei Patterns, die 2024 noch akzeptabel waren und 2026 in einem Production-RAG-Setup nicht mehr durchgehen:

• Naive Fixed-Size ohne Overlap. 512-Token-Chunks mit 0 % Overlap bauen systematisch Halluzinationen ein — selbst als PoC nicht mehr akzeptabel.
• Chunking ohne Metadaten. Ein Chunk ohne source, version, date ist 2026 unauditierbar. Bei EU-AI-Act-Verwendung (Art. 50 Transparenz-Pflichten) wird das zum Compliance-Problem.
• One-Size-Fits-All über alle Quellen. Wer Confluence-SOPs, Vertrags-PDFs und Sales-E-Mails mit demselben Pattern indexiert, lässt 15–25 Prozentpunkte Hit-Rate liegen. Source-spezifisches Chunking ist der 2026-Standard.

Praxis-Schritt: Ein 30-Min-RAG-Audit klärt, ob Ihr aktuelles Chunking-Pattern zur Source-Struktur passt — und welche Hit-Rate-Reserve Sie liegen lassen. Erstgespräch anfragen → /anfrage

Stand Mai 2026. Chunking-Frameworks (LangChain, LlamaIndex, Haystack) ändern Defaults quartalsweise — diese Übersicht wird entsprechend aktualisiert.