RAG Chunking: Strategien für Unternehmensdaten

Chunking legt fest, welche Informationseinheiten ein RAG-System überhaupt finden kann. Wenn eine relevante Aussage über ungünstige Chunk-Grenzen verteilt oder mit zu viel Fremdkontext vermischt wird, können bessere Embeddings, Reranker oder LLMs das Problem nur begrenzt kompensieren.

Deshalb ist Chunking keine kosmetische Vorverarbeitung. Es ist eine Retrieval- und Informationsarchitektur-Entscheidung.

Für das Gesamtbild siehe RAG-System entwickeln & richtig aufbauen. Für die Messung verschiedener Varianten siehe RAG Evaluation: Metriken, Golden Dataset & Regression Tests.

Die Kurzfassung

| Strategie | Gut für | Hauptrisiko | | --- | --- | --- | | Fixed-size | einfache Baseline, homogene Texte | trennt logische Einheiten | | Rekursiv | allgemeine Dokumente mit Absätzen | Struktur wird nur indirekt verstanden | | Struktur-basiert | Handbücher, Wikis, Richtlinien, Markdown | Parser muss Dokumentstruktur sauber erhalten | | Semantisch | thematisch wechselnde Fließtexte | mehr Rechenaufwand und Tuning | | Hierarchisch | lange Dokumente, Kapitel + Details | komplexere Retrieval-Logik | | Kontextualisiert | Chunks mit fehlendem Eigenkontext | zusätzliche Ingestion-Kosten |

Empfehlung: Für Enterprise-RAG zuerst dokumentstrukturbasiert denken, dann mit einem Golden Dataset prüfen, ob zusätzliche Komplexität messbar hilft.

Warum Chunking so viel Einfluss hat

Ein Retriever sucht nicht abstrakt „im Dokument“. Er sucht in den Einheiten, die beim Indexieren erzeugt wurden.

Wenn eine Richtlinie sagt:

Reisekosten über 1.000 Euro benötigen eine zusätzliche Freigabe.

und die Bedingung „über 1.000 Euro“ in einem anderen Chunk liegt als „zusätzliche Freigabe“, kann die spätere Suche nur unvollständige Evidenz liefern.

Umgekehrt kann ein riesiger Chunk mehrere Themen gleichzeitig enthalten. Das Embedding repräsentiert dann eine Mischung, und die relevante Passage verliert an Signal.

Die vier Ziele guten Chunkings

Ein brauchbares Chunking optimiert mehrere Ziele gleichzeitig:

1. Retrievability – relevante Passage muss auffindbar sein.
2. Semantic coherence – ein Chunk sollte in sich verständlich bleiben.
3. Evidence quality – der Chunk sollte als belastbare Quelle nutzbar sein.
4. Operational efficiency – Indexgröße, Latenz und Kosten müssen vertretbar bleiben.

Diese Ziele stehen teilweise im Konflikt. Genau deshalb gibt es keine universelle „richtige“ Chunk-Größe.

1. Fixed-size Chunking

Fixed-size Chunking teilt Text nach Zeichen- oder Token-Limits.

Vorteile

• einfach,
• reproduzierbar,
• schnell,
• gute technische Baseline.

Nachteile

• trennt Absätze, Listen oder Tabellen unnatürlich,
• ignoriert Dokumenthierarchie,
• kann Überschriften vom Inhalt trennen.

Für homogene Fließtexte kann es reichen. Für komplexe Unternehmensdokumente ist es häufig nur die Vergleichsbasis.

2. Rekursives Chunking

Rekursive Splitter versuchen zuerst an größeren natürlichen Grenzen zu trennen – etwa Absätzen – und greifen erst bei Bedarf auf kleinere Grenzen zurück.

Das ist pragmatisch und robuster als stumpfes Fixed-size Chunking.

Aber auch hier gilt: Ein Parser muss zuerst korrekt erkennen, was Absatz, Überschrift, Liste oder Tabelle ist. Schlechte Extraktion kann kein Splitter später vollständig reparieren.

3. Struktur-basiertes Chunking

Bei Unternehmensdaten ist die Dokumentstruktur oft bereits ein starkes Signal:

• Kapitel,
• Überschrift,
• Unterüberschrift,
• Liste,
• Tabellenzeile,
• FAQ-Eintrag,
• Ticket,
• Wiki-Section.

Statt einfach „alle 800 Tokens“ zu schneiden, kann ein Chunk beispielsweise aus Überschrift + Abschnitt + Parent-Kontext bestehen.

Das ist besonders sinnvoll für:

• SharePoint,
• Confluence,
• DMS-Dokumente,
• technische Handbücher,
• Policies,
• Produktdokumentation.

IBM beschreibt Chunking ebenfalls als Aufteilung in kleinere sinnvolle Segmente und weist darauf hin, dass Chunk-Größe und Overlap experimentell passend zum Use Case bestimmt werden müssen. Quelle: IBM – Chunking strategies for RAG.

4. Semantisches Chunking

Semantisches Chunking versucht Themenwechsel im Inhalt zu erkennen und dort Grenzen zu setzen.

Das kann bei langen Fließtexten sinnvoll sein, ist aber kein kostenloser Qualitätsgewinn.

Mögliche Nachteile:

• zusätzliche Embedding- oder Modellaufrufe,
• schwerer reproduzierbare Grenzen,
• mehr Parameter,
• längere Ingestion,
• nicht automatisch besser bei stark strukturierten Dokumenten.

Deshalb: erst gegen eine einfachere Baseline messen.

5. Hierarchisches Chunking

Lange Dokumente haben oft mehrere sinnvolle Ebenen:

Dokument → Kapitel → Abschnitt → Detail

Ein hierarchischer Ansatz kann zunächst einen passenden größeren Bereich identifizieren und danach kleinere Evidenz-Chunks auswählen.

Das hilft, wenn Nutzer sowohl breite als auch sehr spezifische Fragen stellen.

Beispiel:

• „Welche Regeln gelten für Dienstreisen?“ → Kapitel-Ebene,
• „Braucht eine Bahnfahrt über 500 Euro eine Freigabe?“ → Detail-Ebene.

6. Kontextualisiertes Chunking

Ein Chunk kann lokal korrekt, aber ohne Parent-Kontext schwer verständlich sein.

Beispiel:

„Der Grenzwert beträgt 25 Prozent.“

Ohne Dokumenttitel, Abschnitt oder Objekt ist dieser Satz nahezu wertlos.

Anthropic beschreibt mit „Contextual Retrieval“ einen Ansatz, bei dem jedem Chunk vor Embedding und lexical indexing zusätzlicher Dokumentkontext vorangestellt wird. Quelle: Anthropic – Contextual Retrieval.

Für Enterprise-RAG ist das konzeptionell interessant, muss aber gegen Kosten, Ingestion-Zeit und den konkreten Korpus getestet werden.

Entscheidungsmatrix nach Dokumenttyp

| Dokumenttyp | Sinnvolle Baseline | | --- | --- | | Wiki / Confluence / SharePoint | Überschrift + Section strukturbasiert | | technische Handbücher | Kapitel/Section + moderate Größenbegrenzung | | Richtlinien / Policies | Absatz/Clause + Parent-Heading | | Verträge | Klausel-/Abschnittsbasiert, Grenzen nicht blind schneiden | | Tabellen | strukturierte Zeilen/Objekte statt Rohtextblöcke | | Tickets | Ticket als Einheit oder Thread-Segmente mit Metadaten | | Produktkatalog | strukturierte Felder, nicht primär Fließtext-Chunking | | lange unstrukturierte PDFs | Parsing zuerst, dann rekursiv/semantisch testen |

Der wichtigste Punkt: Chunking muss zum Quelltyp passen.

Mehr zur Quellanbindung: RAG-Datenquellen anbinden.

Tabellen sind ein Sonderfall

Tabellen werden beim PDF-Parsing oft zerstört.

Aus:

| Produkt | Mindestmenge | Rabatt | | --- | ---: | ---: | | A | 100 | 5 % | | B | 500 | 12 % |

kann extrahierter Text werden, der Werte und Spaltenbeziehungen verliert.

Dann ist das Problem nicht „Chunk-Größe“, sondern Dokumentverständnis und strukturierte Extraktion.

Bei geschäftskritischen Tabellen sollte geprüft werden, ob sie als strukturierte Daten indexiert oder separat abgefragt werden.

Overlap: nützlich, aber nicht gratis

Overlap kopiert einen Teil des vorherigen Chunks in den nächsten.

Das kann helfen, wenn relevante Zusammenhänge oft an Grenzen liegen.

Zu viel Overlap erzeugt aber:

• größere Indizes,
• mehr nahezu identische Treffer,
• redundanten Kontext,
• höhere Embedding-Kosten.

Overlap ist deshalb ein Parameter für Tests, kein Qualitätsregler, den man einfach maximiert.

Chunk-Metadaten sind Teil der Strategie

Ein Chunk sollte nicht nur Text enthalten.

Sinnvolle Metadaten können sein:

• Dokument-ID,
• Titel,
• Abschnittspfad,
• Quelle,
• Änderungsdatum,
• Sprache,
• Mandant,
• ACL / Berechtigungsinformationen,
• Dokumenttyp,
• Version.

Diese Felder helfen bei Filtern, Zitaten, Aktualisierung und Security Trimming.

Chunking und Hybrid Search zusammen denken

Chunking bestimmt die Kandidaten. Retrieval bestimmt, welche davon gefunden werden.

Bei exakten Codes oder seltenen Fachbegriffen kann Hybrid Search helfen, lexical und semantic retrieval zu kombinieren.

Aber Hybrid Search kann schlechte Chunk-Grenzen nicht vollständig beheben. Wenn die relevante Information nicht sinnvoll repräsentiert ist, bleibt auch ein besseres Ranking begrenzt.

So evaluieren Sie Chunking

Vergleichen Sie mehrere Varianten mit identischen Fragen.

Beispiel:

| Variante | Chunking | | --- | --- | | A | Fixed-size | | B | rekursiv | | C | struktur-basiert | | D | struktur-basiert + Parent-Kontext |

Messen Sie:

• Recall@k,
• Rang relevanter Chunks,
• Kontextvollständigkeit,
• Antwortqualität,
• Citation Accuracy,
• Indexgröße,
• Ingestion-Zeit,
• Latenz.

Die Details stehen in RAG Evaluation.

Anti-Patterns

„Wir nehmen einfach 500 Tokens“

Ohne Bezug zu Dokumentstruktur und Fragen ist das nur ein Startwert, keine Architekturentscheidung.

„Mehr Overlap verbessert die Qualität“

Mehr Duplikation kann Retrieval auch verschlechtern.

„Semantisches Chunking ist immer fortschrittlicher“

Komplexität ist nur dann sinnvoll, wenn sie messbar bessere Ergebnisse bringt.

„Das PDF wurde extrahiert, also ist der Inhalt sauber“

Gerade Tabellen, Header, Footer, Spalten und Listen können bereits vor dem Chunking beschädigt sein.

Nächster Schritt

Wenn Sie RAG für SharePoint, DMS, ERP, CRM, Datenbanken oder andere Unternehmensquellen aufbauen, sollte Chunking zusammen mit Parsing, Berechtigungen und Retrieval geplant werden – nicht isoliert.

Dafür ist RAG-Implementierung & KI-Integration der passende Einstieg.

Wenn ein bestehendes System schon läuft und unklar ist, welche Chunking-Variante tatsächlich besser ist, zuerst Baseline und Testset etablieren: KI Production Readiness.