Chunking für deutsche Dokumente: Strategien für RAG

Deutsche Fachdokumente zuverlässig durchsuchbar machen? WZ-IT baut RAG-Systeme auf eigener Infrastruktur, mit Aufbereitung, Chunking, Metadaten und Testfragen aus Ihrem Bestand. Der RAG Proof of Value prüft einen abgegrenzten Wissensbestand mit vereinbarten Referenzfragen und belegbaren Quellen. RAG Proof of Value ansehen · Interne KI-Assistenten

Ein RAG-System findet keine Dokumente, sondern Abschnitte. Wie diese Abschnitte geschnitten werden, entscheidet mit darüber, ob die Antwort die richtige Fundstelle enthält oder eine halbe Regelung ohne Bedingung. Die meisten Anleitungen empfehlen dafür eine feste Größe von einigen hundert Tokens und beziehen sich auf englische Beispieltexte. Deutsche Dokumente, vor allem aus Verwaltung, Recht und Technik, stellen andere Anforderungen: Komposita, Paragraphenstruktur, Abkürzungen, Tabellen und gescannte Altbestände. Dieser Artikel ordnet die Strategien ein und zeigt, worauf es bei deutschen Texten ankommt. Stand September 2026.

Inhaltsverzeichnis

• Was Chunking in einem RAG-System entscheidet
• Was deutsche Dokumente besonders macht
• Die Strategien im Überblick
• Parent-Child und Overlap
• Chunk-Größe und Eingabegrenzen der Embedding-Modelle
• Metadaten, die jeder Chunk tragen sollte
• Werkzeuge und ihre Voreinstellungen
• Chunking testen statt schätzen

Was Chunking in einem RAG-System entscheidet

Bei der Indexierung wird jedes Dokument extrahiert, in Chunks zerlegt, und jeder Chunk erhält ein Embedding. Bei einer Anfrage sucht das System die ähnlichsten Chunks und gibt sie dem Sprachmodell als Kontext. Wie RAG insgesamt aufgebaut ist, erklärt Was ist RAG?.

Daraus folgen zwei gegenläufige Anforderungen:

• Kleine Chunks treffen präziser. Ein Embedding fasst den Inhalt eines Chunks in einem Vektor zusammen; je mehr Themen darin stehen, desto unschärfer wird er.
• Große Chunks liefern mehr Zusammenhang. Ein Satz wie „Sie ist jährlich zu prüfen" ist ohne den vorherigen Absatz wertlos.

Chunking ist deshalb eine Entwurfsentscheidung mit direkter Wirkung auf Trefferqualität, Quellenangaben und Antwortlänge.

Was deutsche Dokumente besonders macht

Komposita und Tokenizer

Tokenizer zerlegen Text in Teilstücke aus einem festen Vokabular. Englische Wörter sind darin häufig als Ganzes enthalten, deutsche Komposita selten. Eine eigene Auszählung (September 2026) zeigt das am Wort „Grundstücksverkehrsgenehmigung":

Zwei Folgen für die Praxis: Deutscher Text verbraucht bei gleichem Inhalt mehr Tokens als englischer, das Tokenbudget eines Chunks reicht also für weniger Inhalt. Die Größenordnung dieses Effekts über Sprachen hinweg beschreiben Petrov et al. (NeurIPS 2023). Und das eigenständige Wort „Genehmigung" ist im BGE-M3-Vokabular ein einzelnes Token, im Kompositum dagegen auf „ge · nehm · igung" verteilt. Eine Suche nach „Genehmigung" trifft das Kompositum daher nicht zuverlässig über exakte Wortübereinstimmung. Für die Stichwortsuche lösen Zerlegungsfilter wie der Dictionary Decompounder in OpenSearch dieses Problem; wie Stichwort- und Vektorsuche kombiniert werden, beschreibt Hybrid Search und Reranking.

Lange Sätze und Abkürzungen

Deutsche Fach- und Rechtstexte enthalten lange Sätze mit Einschüben und viele Abkürzungen mit Punkt: Abs., Nr., gem., z. B., i. V. m. Satzsplitter, die einen Punkt als Satzende werten, schneiden an diesen Stellen. Der untrainierte PunktSentenceTokenizer aus NLTK, den der SentenceSplitter von LlamaIndex für Satzgrenzen verwendet, zerlegt den Beispielsatz „Die Frist nach § 4 Abs. 2 Satz 1 beträgt drei Monate." in „Die Frist nach § 4 Abs." und „2 Satz 1 beträgt drei Monate." (eigener Test, September 2026). Landet eine solche Grenze zwischen zwei Chunks, ist der Verweis in beiden unvollständig. Abhilfe schaffen ein deutschsprachiger Satzsplitter, eine Abkürzungsliste oder ein Verfahren, das an Absätzen und Überschriften trennt statt an Sätzen.

Gliederung: Paragraphen, Absätze, Nummern

Gesetze, Satzungen, Verwaltungsvorschriften und Verfahrensanweisungen sind hierarchisch gegliedert: Teil, Abschnitt, Paragraph, Absatz, Satz, Nummer. Ein Absatz wie „(2) Abweichend von Absatz 1 gilt ..." ist nur mit seinem Paragraphen verständlich. Zwei Regeln helfen:

• Grenzen an der Gliederung ausrichten. Ein Chunk beginnt an einem Paragraphen oder Absatz, nicht mitten darin.
• Den Gliederungspfad mitführen. Jeder Chunk erhält Dokumenttitel und Pfad (etwa „Satzung, § 4 Gebühren, Abs. 2") als Metadatum oder als vorangestellten Kontext. So bleibt ein Treffer zitierbar und für das Embedding eindeutig.

Tabellen

Gebührenordnungen, Datenblätter, Prüfpläne und Fristenübersichten enthalten ihre Kernaussagen in Tabellen. Zerlegt ein zeichenbasierter Splitter eine Tabelle, landen Zeilen ohne Spaltenköpfe in einem Chunk, und die Zahl „30" verliert ihre Bedeutung. Tabellen gehören deshalb als eigene Einheiten behandelt: vollständig, wenn sie klein genug sind, sonst zeilenweise mit wiederholter Kopfzeile.

Gescannte PDFs und Altbestände

Viele Bestände liegen als Scans vor. Die Texterkennung liefert dann Fehler, die das Chunking verstärkt: Silbentrennung am Zeilenende („Verwal-" / „tung"), Kopf- und Fußzeilen mitten im Fließtext, Spalten in falscher Lesereihenfolge. Vor dem Chunking gehören Trennungen zusammengeführt und Seitenelemente entfernt. Für historische Dokumente in Frakturschrift stellt Tesseract eigene Modelle bereit (deu_latf und das Schriftmodell Fraktur in tessdata_best). Wie Dokumente zuverlässig aufbereitet werden, beschreibt Dokumente mit KI verarbeiten.

Die Strategien im Überblick

Rekursiv ist der verbreitete Standard. Der RecursiveCharacterTextSplitter von LangChain versucht standardmäßig die Trennzeichen Leerzeile, Zeilenumbruch, Leerzeichen und zuletzt einzelne Zeichen.

Strukturbasiert ist für gegliederte deutsche Dokumente meist die bessere erste Wahl. Liegt der Text als Markdown vor, trennt der MarkdownHeaderTextSplitter an Überschriften und legt die Überschriftenhierarchie als Metadaten ab. Für PDFs und Office-Dokumente übernehmen Docling und Unstructured die Strukturerkennung (siehe unten). Paragraphenzeichen und Absatznummern lassen sich zusätzlich als eigene Trennmuster definieren.

Semantisch klingt nach der naheliegenden Verbesserung, ist es aber nicht zwingend. Qu, Tu und Bao (2024) kommen zu dem Ergebnis, dass die Rechenkosten des semantischen Chunkings nicht durch durchgängige Qualitätsgewinne gerechtfertigt sind. Semantisches Chunking lohnt eine Prüfung bei langen Texten ohne Überschriften, etwa Protokollen oder Gutachten mit Fließtext.

Late Chunking wurde von Günther et al. (Jina AI) beschrieben. Das Embedding-Modell verarbeitet zuerst den gesamten Text (oder den größten Teil, der in sein Kontextfenster passt) und erzeugt Vektoren für jedes Token. Erst danach wird die Tokenfolge an den Chunk-Grenzen geteilt und je Chunk gemittelt. Ein Satz wie „Sie ist jährlich zu prüfen" erhält so einen Vektor, der die vorher genannte Anlage mitträgt. Das Verfahren kommt ohne zusätzliches Training aus. Zwei Einschränkungen: Die Chunk-Grenzen müssen weiterhin festgelegt werden, und das Serving muss die Token-Vektoren vor dem Pooling liefern. Übliche Embedding-Endpunkte geben nur einen fertigen Vektor pro Eingabe zurück; im Eigenbetrieb braucht es dafür eigenen Code, wie ihn das Referenz-Repository von Jina zeigt.

Ein verwandter Ansatz ist Contextual Retrieval, bei dem ein Sprachmodell jedem Chunk vor der Indexierung einen kurzen Kontexttext voranstellt. Er ist unabhängig vom Embedding-Modell einsetzbar und in Contextual Retrieval beschrieben.

Parent-Child und Overlap

Parent-Child trennt, was gesucht wird, von dem, was das Sprachmodell erhält. Gesucht wird über kleine Chunks (etwa einzelne Absätze), an das Modell geht der übergeordnete Abschnitt (etwa der ganze Paragraph). LlamaIndex bildet das mit dem HierarchicalNodeParser ab, der in der Voreinstellung drei Ebenen mit 2.048, 512 und 128 Tokens erzeugt (LlamaIndex Node Parser). Für deutsche Rechts- und Verwaltungstexte passt das Muster gut zur Gliederung: Treffer auf Absatzebene, Antwort mit dem ganzen Paragraphen.

Overlap wiederholt das Ende eines Chunks am Anfang des nächsten. Er mildert Schnitte an ungünstigen Stellen, verdoppelt aber auch Inhalte im Index und in den Suchtreffern. Etwa 10 bis 20 Prozent sind eine übliche erste Testvariante bei fester oder rekursiver Länge. Bei strukturbasierten Grenzen ist Overlap oft verzichtbar, weil die Schnitte ohnehin an natürlichen Stellen liegen.

Chunk-Größe und Eingabegrenzen der Embedding-Modelle

Die obere Grenze setzt das Embedding-Modell: Was darüber hinausgeht, wird abgeschnitten, ohne dass eine Fehlermeldung erscheint. Die Grenzen unterscheiden sich stark (Stand September 2026, laut Modellkarten):

Drei Punkte für die Praxis:

• Mit dem richtigen Tokenizer messen. Die Chunk-Größe muss mit dem Tokenizer des Embedding-Modells geprüft werden. Ein Chunk mit 500 Tokens nach cl100k_base kann nach einem anderen Tokenizer deutlich mehr oder weniger Tokens haben.
• Kontext zählt mit. Wer Gliederungspfad, Dokumenttitel oder einen erzeugten Kontexttext voranstellt, verbraucht Tokenbudget. Bei multilingual-e5 kommt zusätzlich das Präfix passage: hinzu.
• Lange Eingabe ist kein Ziel. Dass ein Modell 8.192 Tokens verarbeitet, heißt nicht, dass Chunks dieser Größe gut gefunden werden. Einige hundert bis etwa 1.000 Tokens sind ein üblicher Startbereich, den Tests mit echten Fragen bestätigen oder verschieben.

Welche Embedding-Modelle für deutsche Texte in Frage kommen, vergleicht der Beitrag Embedding-Modelle für Deutsch.

Metadaten, die jeder Chunk tragen sollte

Ein Chunk ohne Herkunft ist für ein Unternehmenssystem unbrauchbar: Er lässt sich nicht zitieren, nicht filtern und nicht gezielt löschen. Diese Felder haben sich bewährt:

Vektordatenbanken wie Qdrant speichern solche Felder als Payload und filtern direkt in der Suche. Einen Vergleich der Optionen bietet Qdrant vs. pgvector.

Werkzeuge und ihre Voreinstellungen

Die Voreinstellungen der verbreiteten Bibliotheken unterscheiden sich in einem wichtigen Punkt: ob sie Zeichen oder Tokens zählen (Stand September 2026, laut Dokumentation und Quellcode):

Docling (MIT-Lizenz) wandelt PDF, Office und Bilder in ein strukturiertes Dokumentmodell mit Überschriften, Lesereihenfolge und Tabellenstruktur und bringt Texterkennung mit, unter anderem über EasyOCR, RapidOCR und Tesseract. Der HierarchicalChunker erzeugt einen Chunk je erkanntem Dokumentelement und hängt Überschriften und Bildunterschriften als Metadaten an. Der HybridChunker baut darauf auf: Er teilt zu große Chunks nach dem Tokenizer des Embedding-Modells und fasst zu kleine benachbarte Chunks zusammen. Bei Tabellen, die über mehrere Chunks gehen, wiederholt er standardmäßig die Kopfzeile.

Unstructured zerlegt Dokumente zunächst in Elemente (Titel, Absatz, Liste, Tabelle). Die Strategie by_title beginnt bei jeder erkannten Überschrift einen neuen Chunk, auch wenn der vorherige noch Platz hätte. Tabellen werden immer isoliert und nie mit anderen Elementen kombiniert; zu große Tabellen teilt Unstructured in mehrere TableChunk-Elemente.

LangChain und LlamaIndex bieten die Splitter, die in den meisten Beispielen zu sehen sind. Ihre Voreinstellungen sind auf englische Texte und allgemeine Anwendungsfälle ausgelegt. Für deutsche Bestände lohnt es, Trennmuster, Satzsplitter und Längenmessung ausdrücklich zu setzen, statt die Voreinstellung zu übernehmen.

Chunking testen statt schätzen

Welche Strategie für einen Bestand passt, zeigt sich nur im Test. Ein belastbares Vorgehen:

1. Stichprobe wählen. Repräsentative Dokumente aus jedem Dokumenttyp, auch Scans und Tabellen.
2. Extraktion prüfen. Vor jedem Chunking-Vergleich die extrahierten Texte ansehen. Fehler bei Lesereihenfolge oder Silbentrennung lassen sich durch Chunking nicht beheben.
3. Testfragen sammeln. Echte Fragen aus dem Fachbereich mit der erwarteten Fundstelle, darunter Fragen nach Kennungen, Tabellenwerten und Verweisen.
4. Varianten vergleichen. Zwei bis drei Strategien oder Größen mit demselben Embedding-Modell indexieren und messen, ob die erwartete Fundstelle unter den ersten Treffern ist.
5. Entscheidung dokumentieren. Strategie, Parameter, Tokenizer und Chunking-Version festhalten, damit spätere Änderungen vergleichbar bleiben.

Welche Metriken sich dafür eignen und wie ein Testset aufgebaut wird, beschreibt RAG-Qualität messen.

Was das für Ihr Projekt heißt

Die Wahl der Chunking-Strategie hängt stärker vom Bestand ab als vom Werkzeug. Gut gegliederte Dokumente mit sauberer Textschicht profitieren von strukturbasiertem Chunking mit Gliederungspfad und Parent-Child. Gescannte Altbestände brauchen zuerst eine verlässliche Extraktion. Semantisches Chunking und Late Chunking sind Ergänzungen, die sich erst lohnen, wenn Tests einen Bedarf zeigen.

Den Gesamtaufbau erklärt Was ist RAG?. Wie Stichwort- und Vektorsuche zusammenwirken, zeigt Hybrid Search und Reranking, und wie Chunks vor der Indexierung Kontext erhalten, Contextual Retrieval. Woher die Dokumente kommen und wie Änderungen synchronisiert werden, beschreibt RAG-Datenquellen: Nextcloud, SharePoint und DMS. Wie eine Behörde den gesamten Weg angeht, zeigt der Beitrag RAG-Wissensdatenbank in der öffentlichen Verwaltung. Betrieben werden solche Systeme lokal auf dem AI Cube oder auf einem Managed GPU-Server von WZ-IT.

Quellen

• Günther et al.: Late Chunking, Contextual Chunk Embeddings Using Long-Context Embedding Models
• Jina AI: Late Chunking in Long-Context Embedding Models
• Jina AI: Referenz-Implementierung Late Chunking
• Qu, Tu, Bao: Is Semantic Chunking Worth the Computational Cost?
• Petrov et al.: Language Model Tokenizers Introduce Unfairness Between Languages
• Docling: Chunking
• Unstructured: Chunking
• LangChain: RecursiveCharacterTextSplitter
• LangChain: MarkdownHeaderTextSplitter
• LlamaIndex: Node Parser Modules
• OpenSearch: Dictionary Decompounder
• Tesseract: tessdata_best