Chunking-Strategien für RAG warum die Aufteilung über alles entscheidet.
Wer KI-Assistenten auf die eigenen Firmendokumente loslässt — Verträge, Handbücher, Wikis, technische Spezifikationen — stellt schnell fest, dass die Antwortqualität enorm schwankt. Mal trifft der Assistent ins Schwarze, mal zitiert er eine völlig falsche Stelle oder erfindet etwas dazu. Die übliche Reaktion ist, am Modell zu schrauben oder einen teureren Anbieter zu wählen. In der Praxis liegt der Hebel jedoch fast immer woanders: beim Chunking, also der Frage, wie ein Dokument vor der Indexierung in durchsuchbare Häppchen zerlegt wird. Ein gutes Modell auf schlecht geschnittenen Chunks liefert schlechte Antworten; ein durchschnittliches Modell auf sauber zerlegten Dokumenten liefert oft erstaunlich gute. Dieser Beitrag zeigt, welche Chunking-Strategien es gibt, wann welche passt, wie man Tabellen und Verträge behandelt — und welche Fehler im Betrieb teuer werden, ohne dass man sie sofort bemerkt.
Warum die Aufteilung über die RAG-Qualität entscheidet.
Retrieval-Augmented Generation (RAG) funktioniert nach einem einfachen Prinzip: Eine Nutzerfrage wird mit einer Dokumentensammlung abgeglichen, die relevantesten Textstücke werden herausgesucht und dem Sprachmodell als Kontext mitgegeben. Das Modell antwortet dann nur auf Basis dieser Stücke. Der entscheidende Punkt ist: Was nicht abgerufen wird, kann das Modell auch nicht nutzen. Liegt die Antwort in einem Chunk, der bei der Suche nicht oben landet, ist sie für das System unsichtbar.
Genau hier entsteht der Großteil schlechter RAG-Qualität. Wird ein Dokument zu grob zerlegt, enthält ein Chunk mehrere Themen — die Suche findet ihn schlechter, weil sein „Sinn“ verschwimmt. Wird zu fein zerlegt, reißt der Zusammenhang ab: Die Antwort steht in Chunk drei, aber der entscheidende Bezug in Chunk zwei, und beide landen nicht gemeinsam im Kontext.
In vielen Projekten verbessert allein eine durchdachte Chunking-Strategie die Trefferqualität spürbar, ohne dass am Modell etwas geändert wird. Das ist die gute Nachricht: Der wirksamste Hebel ist auch der günstigste.
Die grundlegenden Strategien im Überblick.
Es gibt nicht die eine richtige Methode, sondern eine Handvoll Ansätze mit unterschiedlichen Stärken. Ein nüchterner Vergleich hilft, die passende auszuwählen:
| Strategie | Prinzip | Stärke | Schwäche |
|---|---|---|---|
| Fixed-Size | Feste Zeichen-/Token-Zahl, oft mit Überlappung | einfach, robust, schnell | zerschneidet Sätze und Gedanken |
| Satz-/Absatz-basiert | schneidet an natürlichen Grenzen | erhält Sinneinheiten | sehr ungleiche Chunk-Größen |
| Semantisch | trennt, wo sich das Thema ändert | kohärente, fokussierte Chunks | rechenintensiver, Tuning nötig |
| Hierarchisch | mehrere Ebenen (Kapitel → Absatz) | Kontext bleibt erhalten | komplexere Pipeline |
| Struktur-basiert | folgt Überschriften, Listen, Tabellen | ideal für formatierte Docs | braucht sauberes Quellformat |
Für viele Einstiege ist eine struktur- oder absatzbasierte Aufteilung mit moderater Überlappung ein guter Kompromiss aus Aufwand und Qualität. Semantisches oder hierarchisches Chunking lohnt sich dort, wo die Dokumente lang, dicht und thematisch verschachtelt sind.
Chunk-Größe und Überlappung richtig wählen.
Die beiden wichtigsten Stellschrauben sind die Größe eines Chunks und die Überlappung zwischen benachbarten Chunks. Beide klingen banal, entscheiden aber stark über das Ergebnis.
Als realistische Bandbreite haben sich Chunk-Größen von etwa 200 bis 800 Token bewährt, je nach Dokumenttyp. Kurze, faktendichte Texte — FAQ, Stammdaten, Definitionen — vertragen kleinere Chunks. Erklärende oder argumentative Texte — Handbücher, Richtlinien, Gutachten — profitieren von größeren Einheiten, weil der Gedanke sonst zerfällt.
Die Überlappung sorgt dafür, dass ein Gedanke, der genau an einer Schnittstelle liegt, in beiden angrenzenden Chunks auftaucht. Üblich sind 10 bis 20 Prozent Überlappung. Zu viel Überlappung bläht den Index auf und erhöht die Kosten, ohne die Qualität nennenswert zu verbessern; zu wenig erzeugt die typischen abgerissenen Antworten.
Wichtig ist die ehrliche Einsicht: Es gibt keinen universell optimalen Wert. Die richtige Größe hängt vom Dokumentbestand und von den typischen Fragen ab. Wer das nicht an realen Beispielfragen testet, optimiert ins Blaue.
Tabellen, Verträge und Sonderfälle.
Standard-Chunking geht von fortlaufendem Fließtext aus — und scheitert genau dort, wo Firmendokumente am wertvollsten sind. Drei Fälle verdienen besondere Aufmerksamkeit.
Tabellen verlieren ihren Sinn, wenn ein naiver Splitter sie mitten in einer Zeile zerschneidet oder Spaltenüberschriften vom Inhalt trennt. Eine Preistabelle, deren Kopfzeile in einem anderen Chunk landet, liefert Zahlen ohne Bedeutung. Hier hilft es, Tabellen als Einheit zu behandeln und die Kopfzeile in jeden Tabellen-Chunk mitzunehmen.
Verträge leben von Bezügen: „im Sinne von §3“, „vorbehaltlich Absatz 2“. Wird ein Paragraph isoliert abgelegt, fehlt der Verweis. Hier lohnt es sich, die Paragraphennummer und die Vertragsstruktur als Metadaten an jeden Chunk zu hängen, damit Bezüge auffindbar bleiben.
Handbücher und Wikis mit klarer Überschriftenstruktur lassen sich entlang dieser Hierarchie schneiden. Wer die Kapitel- und Abschnittsüberschrift jedem Chunk voranstellt, gibt der Suche und dem Modell wertvollen Kontext, fast ohne Zusatzaufwand.
Metadaten als unterschätzter Hebel.
Ein Chunk ist mehr als nur sein Text. An jedem Chunk lassen sich Metadaten speichern — und diese sind oft der Unterschied zwischen einem brauchbaren und einem frustrierenden Assistenten.
Sinnvolle Metadaten sind unter anderem:
- Quelle und Dokumenttitel: damit die Antwort belegbar ist und der Nutzer zur Originalstelle springen kann.
- Abschnittsüberschriften: geben dem Modell Kontext, ohne den Chunk aufzublähen.
- Datum und Version: entscheidend, wenn es mehrere Fassungen eines Dokuments gibt — niemand will Antworten aus der veralteten Richtlinie.
- Zugriffsrechte: wer welche Dokumente sehen darf. Ohne diese Filterung droht, dass der Assistent vertrauliche Inhalte an Unberechtigte ausgibt.
Gerade die letzte Kategorie ist kein technisches Detail, sondern ein Governance-Thema. Ein RAG-System ohne Rechtefilter kann zur unbeabsichtigten Datenschleuder werden. Das gehört von Anfang an mitgedacht, nicht nachträglich aufgesetzt.
Wie man Chunking-Qualität tatsächlich misst.
Der häufigste Fehler ist, Chunking nach Bauchgefühl einzustellen und das Ergebnis nie systematisch zu prüfen. Ohne Messung dreht man an Parametern, ohne zu wissen, ob es besser wird.
Ein praktikabler Weg: Man legt einen Testsatz aus realen Fragen an — idealerweise solche, die später wirklich gestellt werden — und notiert zu jeder Frage, in welchem Dokument die Antwort steht. Dann prüft man, ob das System den richtigen Chunk unter den Top-Treffern hat. Diese Kennzahl (oft als „Recall@k“ bezeichnet, also: Ist die richtige Stelle unter den ersten k Treffern?) macht Verbesserungen sichtbar.
50 bis 100 gut gewählte Testfragen reichen oft, um Strategien sinnvoll zu vergleichen. Das ist überschaubarer Aufwand und verhindert, dass man monatelang an Stellschrauben dreht, ohne den Effekt zu kennen.
Ehrlich bleiben sollte man bei der Erwartung: Auch das beste Chunking liefert keine 100 Prozent. Es gibt Fragen, deren Antwort über viele Dokumente verstreut ist oder die schlicht nicht in den Unterlagen steht. Ein gutes System sagt dann „dazu finde ich nichts“ — statt etwas zu erfinden.
Typische Fehler, die im Betrieb teuer werden.
Einige Fehler zeigen sich nicht beim ersten Test, sondern erst im Dauerbetrieb — und kosten dann Vertrauen.
Veraltete Chunks bleiben im Index. Wird ein Dokument aktualisiert, die alte Version aber nicht aus dem Index entfernt, liefert das System Antworten aus überholten Quellen. Ein sauberer Re-Index-Prozess ist Pflicht, kein Nice-to-have.
Format-Verlust beim Einlesen. PDFs, gescannte Dokumente oder schlecht exportierte Dateien verlieren ihre Struktur. Aus einer Tabelle wird Zeichensalat, aus Überschriften Fließtext. Wer hier nicht in saubere Extraktion investiert, baut auf Sand.
Einheitliche Strategie für alle Dokumenttypen. Verträge, Tabellen und Fließtext über einen Kamm zu scheren, ist bequem, aber selten optimal. Oft lohnt sich, wenige Dokumentklassen zu unterscheiden und je Klasse passend zu zerlegen.
Keiner dieser Punkte ist exotisch — aber jeder einzelne kann ein ansonsten gutes System unbrauchbar machen. Die gute Nachricht: Alle sind beherrschbar, wenn man sie kennt und früh adressiert.
Einstieg, Aufwand und realistische Erwartung.
Ein sinnvoller Einstieg beginnt klein: ein klar abgegrenzter Dokumentbestand, eine einfache Chunking-Strategie, ein Testsatz aus echten Fragen. Erst wenn das misst- und nachvollziehbar funktioniert, lohnt es sich, in semantisches oder hierarchisches Chunking, Reranking und feinere Metadaten zu investieren.
Der Aufwand für eine erste funktionierende RAG-Pipeline im Mittelstand bewegt sich, je nach Datenlage und Anbindung, typischerweise im Bereich weniger Wochen. Der weitaus größere Aufwand steckt selten im Modell, sondern in der Datenaufbereitung: Dokumente sammeln, bereinigen, Rechte klären, Extraktion robust machen.
Die realistische Erwartung lautet: Ein gut gebautes RAG-System nimmt der Belegschaft das mühsame Durchsuchen großer Dokumentbestände ab und beantwortet einen Großteil der wiederkehrenden Fragen verlässlich. Es ersetzt aber keine Fachkraft bei komplexen, verstreuten oder wertenden Fragen — und sollte das auch nicht vortäuschen.
Sie wollen einen KI-Assistenten auf Ihre Firmendokumente setzen, der die richtigen Stellen findet statt zu raten? Unverbindlich anfragen — wir schauen gemeinsam auf Ihren Dokumentbestand, prüfen die passende Chunking- und Indexierungsstrategie und bauen einen messbaren Testsatz, bevor Aufwand entsteht.