Chunking für RAG: Dokumente sinnvoll in Abschnitte teilen

Ein RAG-System ist nur so gut wie die Chunks, aus denen es zitiert. Ein Chunking-Fehler zeigt sich selten als offensichtlicher Absturz, sondern als schleichendes Problem: Die Suche liefert Treffer, die halbe Sätze oder abgeschnittene Tabellenzeilen enthalten, das Sprachmodell antwortet trotzdem selbstbewusst – nur eben mit lückenhaftem oder falsch zusammengesetztem Kontext. Wer ein internes Wissenssystem oder einen Kundensupport-Assistenten auf Basis eigener Dokumente baut, trifft die Chunking-Entscheidung meist früh im Projekt und lebt danach lange mit den Folgen.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die ein RAG-Projekt planen oder bereits ein bestehendes System mit unbefriedigender Antwortqualität betreiben. Er beantwortet die praktischen Kernfragen: Was ist Chunking genau, wie wählt man Größe und Überlappung, wie geht man mit Tabellen um, wann lohnt sich semantisches Chunking, und wie prüft man, ob die eigene Aufteilung überhaupt funktioniert.

Begriffe und Abgrenzung

Bevor es um Details geht, kurz die Einordnung: Chunk bezeichnet einen einzelnen, in sich abgeschlossenen Textabschnitt aus einem Referenzdokument. Chunking ist der Prozess, der ein Dokument in solche Abschnitte zerlegt. Chunk-Größe ist die Länge eines Chunks, meist gemessen in Tokens (den Recheneinheiten, die Sprachmodelle verarbeiten) oder in Zeichen. Overlap (Überlappung) bezeichnet den Textanteil, der am Ende eines Chunks wiederholt am Anfang des nächsten erscheint, um Kontext an der Schnittstelle nicht zu verlieren. Chunking ist ein Teilschritt der Datenaufbereitung innerhalb der RAG-Architektur – es findet statt, bevor Chunks über ein Embedding-Modell in Vektoren umgewandelt und in einer Vektordatenbank gespeichert werden.

Wichtig ist die Abgrenzung zum Fine-Tuning: Chunking verändert nicht, was das Sprachmodell “weiß” oder wie es trainiert wurde. Es entscheidet nur, welche Textausschnitte dem Modell bei einer konkreten Anfrage als zusätzlicher Kontext mitgegeben werden können.

Was ist Chunking?

Laut der Orientierungshilfe der deutschen Datenschutzaufsichtsbehörden zu RAG-Systemen umfasst die Datenaufbereitung vor dem Einsatz eines RAG-Systems “die Aufteilung der Referenzdokumente in kürzere Absätze (Chunks)”. Diese Chunks werden anschließend durch ein Embedding-Modell in Vektoren überführt, die zusammen mit den Chunks in der Vektordatenbank gespeichert werden. Der Grund für diesen Zwischenschritt ist technisch zwingend: Die Eingabe in ein Sprachmodell darf nicht beliebig lang sein, und auch Embedding-Modelle haben feste Obergrenzen – bei einem verbreiteten Embedding-Modell liegt diese laut Microsoft Learn beispielsweise bei 8.191 Tokens, was etwa 6.000 Wörtern entspricht. Ohne Chunking wären umfangreiche Dokumente wie Handbücher, Verträge oder Wissensdatenbank-Artikel schlicht nicht verarbeitbar.

Die DSK-Orientierungshilfe nennt zwei grundsätzliche Vorgehensweisen: Im einfachsten Fall werden “gleichgroße Abschnitte z. B. mit einer festen Zeichenanzahl” erzeugt – das kann semantische Zusammenhänge zerstören und die Qualität der Embeddings mindern. Beim Chunking mit einem (oft kleineren) generativen KI-Modell werden Dokumente dagegen anhand ihrer inhaltlichen Bedeutung aufgeteilt, was den Kontext innerhalb eines Chunks besser erhält – dieser Ansatz muss laut derselben Quelle datenschutzrechtlich wie der Einsatz eines eigenen Sprachmodells bewertet werden, weil er selbst ein KI-Modell einsetzt.

In der Praxis unterscheiden sich mehrere Varianten deutlich in Aufwand, Kontexttreue und Eignung. Die folgende Übersicht ordnet sie ein:

Variante	Wie sie schneidet	Stärke	Schwäche	Typischer Einsatz
Fixed-Size (Zeichen/Token)	Feste Zeichen- oder Tokenanzahl, unabhängig vom Inhalt	Einfach, schnell, vorhersehbar	Zerreißt Sätze und Sinnabschnitte an willkürlichen Stellen	Homogene, kurze Dokumente; erster Prototyp
Satz-/Absatzbasiert (recursive)	Schneidet bevorzugt an Satz-, Absatz- oder Überschriftsgrenzen, füllt bis zur Zielgröße auf	Bewahrt grammatikalische Einheiten, weiterhin einfach umzusetzen	Ungleiche Chunk-Längen, ignoriert thematische Brüche innerhalb eines Absatzes	Standard-Fließtext wie Richtlinien, FAQ, Anleitungen
Layout-/strukturbasiert	Nutzt Dokumentstruktur (Markdown-Überschriften, HTML, erkanntes Layout) als Schnittkante	Hält zusammengehörige Abschnitte und Tabellen zusammen	Braucht strukturierte oder gut geparste Ausgangsdokumente	Technische Dokumentation, Verträge mit klarer Gliederung
Semantisch (Embedding-basiert)	Erkennt Bedeutungsgrenzen über Ähnlichkeit aufeinanderfolgender Sätze	Beste Kontexttreue bei thematisch wechselnden Texten	Höherer Rechenaufwand, zusätzlicher Modellaufruf, komplexer zu betreiben	Große, heterogene Wissensbestände mit wechselnden Themen
LLM-basiert	Ein generatives Modell entscheidet aktiv über Schnittstellen nach Bedeutung	Höchste Kontexttreue, kann Zusammenfassungen pro Chunk ergänzen	Kosten pro Lauf, muss laut DSK datenschutzrechtlich wie ein eigenes KI-Modell bewertet werden	Komplexe, hochwertige Dokumente mit geringem Volumen

Eigene Einordnung Philogic Labs auf Basis der in den Quellen beschriebenen Verfahren.

Für die meisten KMU-Projekte ist die satz-/absatzbasierte Variante (“recursive character splitting”) der pragmatische Startpunkt: einfach genug für einen schnellen Piloten, aber deutlich kontextschonender als reines Fixed-Size-Chunking.

Wie wählt man Größe und Überlappung?

Es gibt keine universell richtige Chunk-Größe – das machen sowohl die DSK-Orientierungshilfe als auch die technische Dokumentation deutlich. Als konkreten Ausgangspunkt nennt Microsoft Learn für Azure AI Search eine Chunk-Größe von 512 Tokens (etwa 2.000 Zeichen) mit einem anfänglichen Overlap von 25 Prozent, also 128 Tokens; für die integrierte Chunking-Funktion wird als Standardparameter eine Seitenlänge von 2.000 Zeichen mit 500 Zeichen Overlap empfohlen. Allgemeiner fasst die Dokumentation es so: Ein fester Zeichenbereich, der für semantisch sinnvolle Absätze ausreicht, kombiniert mit einem Overlap von etwa 10 bis 15 Prozent des Inhalts, produziert in der Regel brauchbare Chunks als Eingabe für die Embedding-Erzeugung.

Diese Zahlen sind Richtwerte, keine Gesetze. Drei Faktoren bestimmen, wohin man von dort aus justiert:

• Dichte und Struktur der Dokumente. Braucht man zusammenhängende Passagen (etwa bei Vertragsklauseln), sind größere Chunks mit variabler, satzschonender Aufteilung im Vorteil. Kurze, in sich geschlossene FAQ-Einträge oder Produktdatenblätter vertragen kleinere Chunks besser.
• Art der erwarteten Fragen. Faktenfragen (“Wie lautet die Kündigungsfrist?”) funktionieren oft schon mit kleineren, präzisen Chunks. Fragen, die Zusammenhänge erklären sollen (“Warum gilt diese Frist in diesem Fall?”), brauchen mehr umgebenden Kontext und damit tendenziell größere Chunks.
• Grenzen des verwendeten Modells. Sowohl das Embedding-Modell als auch das später antwortende Sprachmodell haben Token-Obergrenzen. Wenn dieselbe Chunk-Größe für Zusammenfassung und Embedding gleichzeitig genutzt wird, muss sie zu beiden Modellen passen.

Die DSK-Orientierungshilfe ergänzt dazu einen für den deutschen Rechtsraum wichtigen Punkt: Vor dem eigentlichen Zuschnitt sollten störende Elemente wie Kopf- und Fußzeilen oder Seitennummern bereinigt und das Dokument in Fließtext überführt werden – “es sollte darauf geachtet werden, dass einzelne Chunks möglichst abschließende Sinnabschnitte enthalten”. Und, mit Blick auf personenbezogene Daten: Soweit sie für den Zweck nicht erforderlich sind, sind sie vor der Speicherung zu entfernen oder zu anonymisieren.

Meine Praxis-Faustregel: Ich starte bei neuen RAG-Projekten fast immer mit der satzbasierten Aufteilung bei 500 bis 800 Tokens und 10 bis 20 Prozent Overlap, teste das an 15 bis 20 echten Fragen aus dem jeweiligen Fachbereich und justiere danach in eine Richtung – kleiner, wenn zu viel irrelevanter Text mitkommt, größer, wenn Antworten erkennbar Kontext fehlt. Diese Zahl ist ein Startwert aus eigener Projekterfahrung, keine allgemeingültige Empfehlung; jedes Dokumentenset verhält sich anders.

Wie behandelt man Tabellen?

Tabellen sind der Klassiker unter den Chunking-Problemen, weil naives Zeichen- oder Satz-Chunking sie zerstört: Eine Zeile mit Zahlen landet in einem Chunk, die Spaltenüberschriften, die ihr erst Bedeutung geben, in einem anderen. Das Ergebnis ist ein Chunk, der für Menschen wie für ein Sprachmodell unverständlich ist – Zahlen ohne erkennbaren Bezug.

Aus der technischen Dokumentation zu Chunking-Techniken lassen sich drei praktikable Wege ableiten:

1. Layoutbewusste Vorverarbeitung. Werkzeuge, die Dokumentstruktur erkennen (Überschriften, Tabellengrenzen, Markdown- oder HTML-Struktur), können Tabellen als eigene, zusammenhängende Einheit behandeln statt sie im Fließtext-Zuschnitt mitzureißen.
2. Wiederholte Kopfzeilen pro Chunk. Wird eine große Tabelle doch in mehrere Chunks aufgeteilt, hilft es, die Spaltenüberschriften in jedem Teil-Chunk zu wiederholen – so bleibt jede Zeile für sich verständlich.
3. Umwandlung in Fließtext-Sätze. Für kleinere Tabellen kann es sinnvoller sein, jede Zeile in einen eigenständigen Satz umzuformulieren (“Produkt X kostet Y und hat Lieferzeit Z”), statt die Tabellenform beizubehalten. Das erhöht zwar den Vorverarbeitungsaufwand, verbessert aber die Trefferqualität bei faktenbasierten Fragen erheblich.

Welcher Weg passt, hängt vom Dokumenttyp ab: Bei Preislisten oder technischen Datenblättern mit vielen kleinen Tabellen lohnt sich oft die Umwandlung in Sätze; bei umfangreichen Finanz- oder Regelwerkstabellen ist die strukturerhaltende Vorverarbeitung mit wiederholten Kopfzeilen praktikabler. Ein pauschales “immer Fixed-Size-Chunking” ist bei Tabellen so gut wie nie die richtige Wahl.

Wann ist semantisches Chunking sinnvoll?

Semantisches Chunking – das Erkennen von Bedeutungsgrenzen statt fester Zeichenzahlen – klingt nach der offensichtlich besseren Lösung. In der Praxis ist der Nutzen kontextabhängig, und der zusätzliche Aufwand lohnt sich nicht immer.

Für semantisches Chunking spricht es, wenn:

• Dokumente thematisch heterogen sind, also innerhalb eines Absatzes oder einer Seite mehrere unterschiedliche Themen behandeln (typisch bei zusammengeführten Wikis, Protokollen oder langen Berichten).
• feste Zeichengrenzen in der Vergangenheit nachweislich Sinnabschnitte zerrissen haben – erkennbar an Chunks, die mitten im Gedankengang enden.
• genug Rechenbudget und Betriebsaufwand vorhanden sind, um den zusätzlichen Modellaufruf pro Dokument dauerhaft zu tragen, auch bei künftigen Dokument-Updates.

Dagegen spricht es bei klar strukturierten Dokumenten mit erkennbaren Absätzen, Überschriften oder Tabellen (Richtlinien, FAQ, Produktdatenblätter) – hier liefert strukturbasiertes oder satzbasiertes Chunking meist vergleichbare Ergebnisse bei deutlich geringerem Aufwand. Auch bei kurzen Dokumenten, die ohnehin komplett in einen einzigen Chunk passen, erübrigt sich die Frage.

Die DSK-Orientierungshilfe weist zudem auf einen datenschutzrechtlich relevanten Aspekt hin: Chunking mit einem eigenen generativen Modell (“Chunking mit LLM”) ist selbst der Einsatz eines KI-Modells und muss entsprechend bewertet werden – etwa hinsichtlich der Frage, welche Daten dabei verarbeitet werden und wo das Modell betrieben wird. Wer sensible oder personenbezogene Referenzdokumente verarbeitet, sollte diesen zusätzlichen Verarbeitungsschritt bewusst in die Datenschutz-Prüfung einbeziehen, nicht nur die spätere Anfrage an das Hauptmodell.

Wie evaluiert man Chunking?

Chunking lässt sich nicht “auf Zuruf” beurteilen – ohne Testverfahren merkt man ein Problem oft erst, wenn Nutzende sich über schlechte Antworten beschweren. Zwei Ebenen der Prüfung ergänzen sich:

Retrieval-Ebene: Findet die Suche die richtigen Chunks? Dafür braucht es einen Satz von Testfragen mit bekannter, im Dokumentenbestand belegbarer Antwort – im Idealfall aus echten, früher gestellten Fragen des Fachbereichs. Für jede Testfrage wird geprüft, ob unter den obersten Suchtreffern der oder die tatsächlich relevanten Chunks auftauchen. Das ist keine akademische Übung: Schon 15 bis 20 sorgfältig ausgewählte Testfragen decken oft die gröbsten Chunking-Probleme auf.

Antwort-Ebene: Erzeugt das Sprachmodell aus den gefundenen Chunks eine korrekte Antwort? Auch wenn der Retriever die richtigen Chunks liefert, kann die Antwort noch danebenliegen – etwa wenn ein Chunk zwar die richtige Information enthält, sie aber ohne Kontext unverständlich abgeschnitten ist. Hier hilft eine manuelle Stichprobenprüfung: Enthält der jeweils genutzte Chunk einen abgeschlossenen Sinnabschnitt? Fehlt erkennbar Kontext an einer Chunk-Grenze? Wurde eine Tabelle sinnvoll wiedergegeben?

Beide Prüfungen sollte man wiederholen, wenn sich Chunk-Größe, Overlap oder die Chunking-Methode ändern, und erneut, wenn sich der Dokumentenbestand deutlich verändert – ein neues Dokumentformat oder ein neuer Fachbereich kann bestehende Parameter unbrauchbar machen. Eine feste Kennzahl wie “90 % Trefferquote” lässt sich hier seriös nicht pauschal nennen, weil sie stark von Frageart und Dokumentenqualität abhängt; entscheidend ist die relative Verbesserung gegenüber der vorherigen Konfiguration, gemessen an denselben Testfragen.

Umsetzung: Vorgehen in der Praxis

Ein pragmatischer Ablauf für ein KMU-Projekt, unabhängig vom konkreten technischen Stack:

1. Dokumentenbestand sichten. Welche Formate (PDF, Word, HTML, Tabellen), wie einheitlich strukturiert, wie viele personenbezogene oder sensible Inhalte enthalten sie?
2. Vorverarbeitung klären. Kopf-/Fußzeilen, Seitenzahlen und Formatierungsreste entfernen; Tabellen gesondert behandeln (siehe oben).
3. Startkonfiguration wählen. Satz-/absatzbasiertes Chunking mit einer Chunk-Größe im mittleren dreistelligen Tokenbereich und 10 bis 20 Prozent Overlap als Ausgangspunkt, orientiert an den oben genannten Richtwerten.
4. Testfragen sammeln. 15 bis 20 reale Fragen aus dem Fachbereich mit bekannter, belegbarer Antwort zusammenstellen – das ist der wichtigste Schritt und wird am häufigsten übersprungen.
5. Retrieval und Antwortqualität prüfen. Wie oben beschrieben, auf beiden Ebenen testen.
6. Iterieren. Größe, Overlap oder Methode gezielt anpassen und erneut gegen dieselben Testfragen prüfen – nicht mehrere Parameter gleichzeitig ändern, sonst lässt sich die Wirkung nicht zuordnen.
7. Betrieb einplanen. Chunking ist kein einmaliger Schritt. Neue oder geänderte Dokumente müssen erneut aufbereitet werden; wer das nicht einplant, arbeitet nach kurzer Zeit mit veralteten Chunks.

Wer dieses Vorgehen intern nicht abbilden kann oder will, kann es im Rahmen einer KI-Beratung extern begleiten lassen, etwa als abgegrenzter Pilot mit klaren Erfolgskriterien. Grundlagenwissen zu RAG lässt sich auch im Rahmen von Schulungen im Team aufbauen, bevor eigenständig weiterentwickelt wird.

Risiken und Grenzen

Chunking behebt nicht jedes Problem eines RAG-Systems, und es bringt eigene Risiken mit:

• Falsche Erwartungen an “einmal richtig einstellen”. Chunking-Parameter, die für den heutigen Dokumentenbestand gut funktionieren, können bei neuen Dokumenttypen oder wachsendem Bestand wieder nachjustiert werden müssen.
• Verlust von Querverweisen. Zusammenhänge, die über mehrere Chunks oder Dokumente verteilt sind – etwa “siehe Abschnitt 4” –, findet die Vektorsuche allein nicht zuverlässig. Das ist eine strukturelle Grenze der RAG-Methode, keine reine Chunking-Frage.
• Datenschutzrelevanz nicht übersehen. Laut DSK-Orientierungshilfe müssen bereits bei der Aufteilung der Referenzdokumente Fragen wie Mandantentrennung und Zweckbindung mitgedacht werden, besonders wenn personenbezogene Daten enthalten sind – etwa durch Aufteilung der Dokumente nach Mandant oder Organisationseinheit vor dem eigentlichen Chunking. Diese Einordnung ersetzt keine Rechtsberatung; verbindliche Bewertungen gehören zu Datenschutzbeauftragten oder Rechtsberatung (Stand Juli 2026).
• LLM-basiertes Chunking hat eigene Risiken. Wer Chunking mit einem generativen Modell durchführt, führt damit eine zusätzliche KI-Verarbeitung ein, die eigenständig bewertet werden muss – nicht nur das spätere Antwortmodell.
• Kein Ersatz für schlechte Ausgangsdaten. Wenn Referenzdokumente veraltet, widersprüchlich oder unvollständig sind, verbessert kein Chunking-Verfahren die inhaltliche Richtigkeit der Antworten. Das bleibt eine Frage der Datenpflege, nicht der Aufbereitungstechnik.

Checkliste: Chunking für RAG

1. Der Dokumentenbestand ist gesichtet: Formate, Strukturgrad, Anteil an Tabellen und personenbezogenen Daten sind bekannt.
2. Kopf-/Fußzeilen, Seitenzahlen und Formatierungsreste werden vor dem Chunking entfernt.
3. Tabellen werden gesondert behandelt (Layout-Erhalt, wiederholte Kopfzeilen oder Umwandlung in Sätze) statt blind im Fließtext-Zuschnitt mitgerissen.
4. Eine satz-/absatzbasierte Startkonfiguration mit Overlap (Richtwert 10–25 Prozent) ist gewählt und begründet.
5. 15–20 reale Testfragen mit bekannter Antwort liegen vor, bevor produktiv geschaltet wird.
6. Retrieval-Trefferquote und Antwortqualität wurden gegen diese Testfragen geprüft, nicht nur “gefühlt” bewertet.
7. Semantisches oder LLM-basiertes Chunking wird nur eingesetzt, wenn der Mehraufwand durch nachweisbar bessere Ergebnisse gerechtfertigt ist.
8. Bei personenbezogenen Daten sind Zweckbindung, Mandantentrennung und Erforderlichkeit vor der Speicherung geklärt.
9. Ein Prozess für die Neuaufbereitung bei Dokumentänderungen ist definiert – Chunking ist kein einmaliger Schritt.
10. Es gibt eine benannte Zuständigkeit, die bei sinkender Antwortqualität die Chunking-Parameter erneut prüft.