rag-systems.deReifegrad-Check starten
Zurück zum Blog

03. August 2026 · 8 Min

Chunking-Strategien für deutsche Dokumente: RAG richtig teilen

Warum Standard-Chunking an deutschen Komposita und Schachtelsätzen scheitert: fünf Strategien im Vergleich, mit konkreten Startwerten und Messmethodik für RAG.

Warum Chunking über die Retrieval-Qualität entscheidet

In RAG-Projekten wird viel über Modelle diskutiert. Welches LLM, welches Embedding-Modell, welche Vektordatenbank, welches Framework. Nach unserer Erfahrung entstehen die meisten Qualitätsprobleme jedoch früher: beim Zerlegen der Dokumente in Chunks. Liefert der Retriever einen abgeschnittenen Satz oder eine Tabellenzeile ohne Kopfzeile, kann auch das beste Sprachmodell daraus keine belastbare Antwort bauen. Garbage in beim Retrieval schlägt jedes Modell-Upgrade.

Der Grund ist simpel. Das Embedding eines Chunks kann nur repräsentieren, was im Chunk steht. Endet ein Chunk mitten in einer Bedingung ("Die Gewährleistung entfällt, wenn"), landet der entscheidende Teil im nächsten Chunk, und keiner von beiden wird bei der passenden Frage zuverlässig gefunden. Wer die Chunking-Entscheidung dem Default eines Frameworks überlässt, hat diesen Fehler tausendfach im Index, bevor die erste Frage gestellt wurde.

Für englische Texte gibt es zu diesem Thema reichlich Material. Für deutsche Dokumente kaum, obwohl sie sich an mehreren Stellen deutlich anders verhalten. Genau darum geht es hier.

Was deutsche Dokumente besonders macht

Komposita sprengen das Token-Budget. Die Tokenizer der gängigen Embedding-Modelle sind überwiegend auf englischen Korpora trainiert. Ein Wort wie "Datenschutzfolgenabschätzung" zerfällt je nach Modell in fünf bis acht Tokens, das englische "data protection impact assessment" kommt mit weniger aus. Deutsche Texte brauchen dadurch je nach Tokenizer spürbar mehr Tokens für denselben Inhalt. Zwei Folgen: Ein Chunk mit 512 Tokens transportiert auf Deutsch weniger Information als auf Englisch, und seltene Fachkomposita werden in Subword-Fragmente zerlegt, die semantisch wenig tragen. Beides drückt die Embedding-Qualität.

Schachtelsätze und fixe Fenster vertragen sich nicht. Deutsche Fach- und Verwaltungssprache arbeitet mit langen, verschachtelten Sätzen. Ein Satz aus einem QM-Handbuch oder einer Verfahrensanweisung überschreitet schnell 60 Wörter. Ein fixes Token-Fenster schneidet solche Sätze regelmäßig in der Mitte durch, oft genau vor der Aussage, auf die es ankommt.

Juristisch geprägte Strukturen. Verträge, Richtlinien, Betriebsvereinbarungen und Gesetzestexte folgen einer strengen Gliederung aus Paragraphen und Absätzen. Verweise wie "Abs. 2 Satz 1" oder "§ 7 in Verbindung mit § 12" funktionieren nur, wenn der Chunk den Bezugsrahmen mitliefert. Ein Chunk, der mitten in § 7 Abs. 2 beginnt, ist für den Retriever fast wertlos: Die Frage des Nutzers nennt den Paragraphen, der Chunk-Text nicht.

DIN-Normen und technische Dokumentation. Nummerierte Abschnitte (4.2.1, 4.2.2), Anforderungslisten und Prüfkriterien sind Sinneinheiten. Wer sie quer schneidet, trennt die Anforderung von ihrer Nummer und macht sauberes Zitieren unmöglich.

Tabellen in PDFs. Preislisten, Wartungspläne, Prüfprotokolle, Stücklisten: Viele deutsche Geschäftsdokumente transportieren ihren Kern in Tabellen. Dazu unten mehr, denn hier scheitern die meisten Pipelines komplett.

Fünf Strategien im Vergleich

Fixe Fenster mit Overlap

Der Klassiker: alle 512 Tokens ein Schnitt, dazu 10 bis 20 Prozent Überlappung. Schnell gebaut, deterministisch, eine ordentliche Baseline. Ausreichend ist das für homogene Fließtexte ohne starke Binnenstruktur, etwa Wissensartikel oder FAQ-Sammlungen. Für Verträge oder Normen ist es die falsche Wahl, weil die Schnitte blind für Sinneinheiten sind.

Satzbasiert und rekursiv

Die Standardempfehlung für die meisten Korpora. Rekursive Splitter versuchen zuerst an Absätzen zu trennen, dann an Sätzen und erst im Notfall innerhalb eines Satzes. Der Haken im Deutschen liegt in der Satzgrenzen-Erkennung. Abkürzungen wie "z. B.", "Abs.", "Nr." oder "bzw." lassen naive Punkt-Splitter falsch trennen. Verwenden Sie eine Satzsegmentierung mit deutschem Sprachmodell (spaCy mit de_core_news_lg oder SoMaJo) statt einer Regex. Der Unterschied ist im Index direkt sichtbar.

Strukturbasiert

Überschriften, Paragraphen und Abschnittsnummern werden zu Chunk-Grenzen. Für Verträge, Handbücher und QM-Dokumente ist das die beste Wahl, weil die Dokumentstruktur die Sinneinheiten bereits definiert. § 7 Abs. 2 wird ein eigener Chunk, samt Überschrift des Paragraphen im Text oder in den Metadaten. Voraussetzung: Die Struktur muss aus der Quelle extrahierbar sein. Bei Word-Dateien und sauberem HTML ist das einfach, bei gescannten PDFs braucht es Layout-Analyse.

Semantisches Chunking

Hier bestimmen Embeddings die Grenzen: Benachbarte Sätze werden verglichen, bei einem Themenwechsel wird geschnitten. Das klingt elegant, kostet aber einen Embedding-Aufruf pro Satz für jedes Dokument im Korpus. Der Qualitätsgewinn gegenüber gutem rekursivem Splitting mit sauberer deutscher Satzerkennung fällt in der Praxis oft überschaubar aus. Lohnen kann sich der Aufwand bei unstrukturierten, thematisch springenden Texten wie Gesprächsprotokollen oder Support-Tickets. Bei gut gegliederten Fachdokumenten gewinnt fast immer die strukturbasierte Variante, zum Bruchteil der Kosten.

Parent-Child (small-to-big)

Kleine Chunks werden indexiert und gesucht, geliefert wird der größere Elternkontext. Das löst den Zielkonflikt zwischen Retrieval-Präzision (kleine Chunks matchen präziser) und Antwortqualität (das LLM braucht Zusammenhang). Bei juristischen Texten spielt der Ansatz seine Stärke aus: Gefunden wird der einzelne Absatz, ins Prompt wandert der komplette Paragraph mit Überschrift. Der Mehraufwand steckt in der Index-Struktur, die Eltern-Kind-Beziehungen speichern muss. Die meisten Vektordatenbanken unterstützen das über Metadaten-Referenzen, mehr dazu in unserem Vergleich zur Vector-DB-Auswahl im DACH-Mittelstand.

Startwerte, ausdrücklich als Startwerte

Die folgenden Parameter sind Ausgangspunkte für eigene Messungen, keine Wahrheiten:

  • Wissensartikel, FAQ, Fließtext: 300 bis 500 Tokens pro Chunk, 10 bis 20 Prozent Overlap, rekursives Splitting mit deutscher Satzerkennung.
  • Verträge und Richtlinien: strukturbasiert auf Absatz- oder Paragraphenebene. Die Chunks dürfen größer werden (500 bis 800 Tokens), Parent-Child-Retrieval lohnt die Prüfung.
  • Technische Dokumentation und Normen: strukturbasiert entlang der Abschnittsnummerierung, die Nummern gehören in Text und Metadaten.
  • Wegen des Token-Mehrbedarfs deutscher Texte: Budgets eher am unteren Rand ansetzen und die tatsächliche Tokenzahl pro Chunk mit dem eigenen Tokenizer messen statt schätzen.

Die wichtigste Regel dabei: Ohne eigenen Ground-Truth-Datensatz und Retrieval-Metriken wie hit@k ist jede dieser Zahlen Raten. Zwei Teams mit demselben Korpus können mit unterschiedlichen Parametern richtig liegen, weil ihre Nutzer unterschiedliche Fragen stellen.

Tabellen: der häufigste Totalausfall

Naive PDF-Extraktion liest Tabellen zeilenweise als Fließtext. Aus einer Preistabelle mit vier Spalten wird eine Wortkette, in der sich Artikelnummer, Preis, Staffelmenge und Rabattstufe nicht mehr zuordnen lassen. Der Chunk sieht harmlos aus, das Embedding ist Rauschen, und im schlimmsten Fall zitiert das LLM einen falschen Preis mit voller Überzeugung.

Bewährte Gegenmittel:

  • Tabellenerkennung bereits in der Extraktion, mit layoutbasierten Parsern statt reiner Textextraktion.
  • Kleine Tabellen als Ganzes in einen Chunk übernehmen und nach Markdown konvertieren. Markdown-Tabellen bleiben für Embedding-Modelle und LLMs lesbar.
  • Große Tabellen separat behandeln: Eine kurze textliche Beschreibung der Tabelle dient als durchsuchbarer Chunk, die vollständige Tabelle wird als Payload oder über einen Verweis nachgeladen.
  • Kopfzeilen bei geteilten Tabellen in jedem Teil-Chunk wiederholen, sonst verlieren Folgechunks ihre Spaltenbedeutung.

Metadaten am Chunk sind Pflichtprogramm

Jeder Chunk braucht mindestens: das Quelldokument mit Pfad oder ID, den Abschnitt oder Überschriftenpfad, ein Gültigkeits- oder Standdatum und die Zugriffsrechte des Ursprungsdokuments. Das ist kein Ordnungsfimmel, sondern Betriebsvoraussetzung.

Zwei Gründe. Erstens die DSGVO: Ein Löschersuchen lässt sich nur umsetzen, wenn Sie vom Chunk zum Quelldokument zurückkommen und alle abgeleiteten Einträge im Index finden. Zweitens Berechtigungen: Wenn der Vertrieb über den Chatbot Gehaltstabellen aus dem HR-Laufwerk findet, ist das ein Datenschutzvorfall. Rechte gehören deshalb als Filter direkt in die Retrieval-Abfrage. Erst im Prompt zu filtern kommt zu spät. Wie eine vollständig DSGVO-konforme Pipeline aussieht, haben wir im Blueprint für die DSGVO-konforme RAG-Pipeline beschrieben.

Messen statt diskutieren

Chunking-Entscheidungen fallen in vielen Projekten im Meeting. Besser ist ein Experiment:

  1. Ground-Truth-Datensatz bauen: 50 bis 150 echte Fragen aus dem Fachbereich, jede mit der Quellstelle, die die Antwort enthält.
  2. hit@k messen: Wie oft liegt die richtige Quellstelle unter den Top-k-Treffern? Diese eine Zahl macht Chunking-Varianten direkt vergleichbar.
  3. Groundedness prüfen: Stützt sich die generierte Antwort nachweisbar auf die gelieferten Chunks, oder überbrückt das Modell Lücken mit Halluzinationen?

Mit diesem Setup ist der Vergleich von drei Chunking-Varianten in wenigen Stunden erledigt, und die Entscheidung steht auf Zahlen. Warum viele Teams genau diesen Schritt auslassen und ihre Prototypen deshalb nie produktiv werden, haben wir in Warum RAG-Prototypen nie die Production erreichen aufgeschrieben. Den kompletten Weg vom PoC in den Betrieb zeigt unser Leitfaden RAG-System entwickeln: von PoC zu Production.

Fazit

Chunking ist bei deutschen Dokumenten weder Nebensache noch gelöstes Problem. Komposita verschieben Token-Budgets, Schachtelsätze bestrafen fixe Fenster, juristische und normative Strukturen verlangen strukturbasierte Teilung, und Tabellen brauchen einen eigenen Verarbeitungspfad. Wer mit rekursivem Splitting samt deutscher Satzerkennung startet und jede Parameteränderung gegen hit@k misst, hat die größten Fehlerquellen im Griff. Metadaten gehören dabei von Anfang an in jeden Chunk.

Wenn Sie wissen wollen, wo Ihre bestehende Pipeline steht: Unser RAG-Check schaut sich Chunking, Retrieval und Evaluation Ihres Systems konkret an. Sie erhalten eine Antwort innerhalb eines Werktags. Weitere Grundlagen und Vorlagen finden Sie im RAG-Playbook.

Reifegrad-Check

In 90 Sekunden zu deinem RAG-Reifegrad.