Chunking-Strategien für RAG: Fixed-Size, Satz, Semantisch oder Struktur-bewusst?

Chunking entscheidet oft stärker über die Qualität einer RAG-Antwort als das gewählte Sprachmodell. Wer Dokumente falsch zerschneidet, trennt Fragen von ihren Antworten, zerreißt Tabellen mitten im Satz oder überflutet das Modell mit irrelevantem Text. Dieser Artikel erklärt die vier gängigen Chunking-Strategien, wie Overlap funktioniert und welche Chunk-Größen in der Praxis für welche Dokumenttypen funktionieren.

Was Chunking ist und warum es über Antwortqualität entscheidet

Beim Aufbau einer RAG-Pipeline (Retrieval Augmented Generation) werden Dokumente zunächst in kleinere Textabschnitte, sogenannte Chunks, zerlegt. Jeder Chunk wird in einen Vektor umgewandelt (siehe Embeddings einfach erklärt) und in einer Vektordatenbank abgelegt. Stellt ein Nutzer eine Frage, sucht das System die passendsten Chunks und übergibt sie als Kontext an das Sprachmodell, das daraus eine belegte Antwort formuliert. Den gesamten Ablauf beschreiben wir ausführlich in Wie funktioniert RAG?.

Das Problem: Ein Chunk ist die kleinste Einheit, die das System überhaupt finden und zitieren kann. Ist er zu klein, fehlt Kontext und die Antwort wird vage oder falsch zugeordnet. Ist er zu groß, verwässert sich die Relevanz, der Vektor repräsentiert mehrere Themen gleichzeitig und das Modell bekommt unnötigen Ballast, der zu Halluzinationen führen kann (mehr dazu in KI-Halluzinationen vermeiden). Chunking ist damit keine technische Nebensache, sondern die Stellschraube mit dem größten Hebel auf die Antwortqualität.

Die vier gängigen Chunking-Strategien im Überblick

Fixed-Size Chunking

Die einfachste Methode teilt Text in Abschnitte fester Länge, etwa alle 500 Tokens oder 1.000 Zeichen, unabhängig vom Inhalt. Das ist schnell zu implementieren und funktioniert für homogenen Fließtext ordentlich. Der Nachteil: Die Grenze fällt oft mitten in einen Satz, eine Aufzählung oder eine Tabellenzeile. Ein Vertragsparagraf kann so auf zwei Chunks verteilt werden, von denen keiner die vollständige Klausel enthält.

Satzbasiertes Chunking

Hier wird nicht nach Zeichenanzahl, sondern an Satzgrenzen geschnitten. Mehrere Sätze werden zu einem Chunk gruppiert, bis eine Zielgröße erreicht ist. Das bewahrt grammatikalisch vollständige Einheiten und reduziert abgeschnittene Gedanken. Für Fließtext aus Berichten, Artikeln oder Handbüchern ist das meist ein guter Kompromiss zwischen Einfachheit und Qualität.

Semantisches Chunking

Semantisches Chunking geht einen Schritt weiter: Es berechnet die Ähnlichkeit zwischen aufeinanderfolgenden Sätzen oder Absätzen und schneidet dort, wo sich das Thema merklich verschiebt. Dadurch entstehen inhaltlich kohärente Blöcke unabhängig von einer festen Länge. Das liefert oft die präzisesten Treffer, ist aber rechenintensiver, weil jeder Chunk-Kandidat erst eingebettet werden muss, bevor die Grenze feststeht.

Struktur-bewusstes Chunking

Diese Strategie nutzt die vorhandene Struktur eines Dokuments: Überschriften, Absätze, Listen, Tabellen, Kapitel. Ein Markdown-Dokument wird entlang seiner Überschriftenebenen geteilt, ein PDF entlang von Abschnittstiteln oder Seitenlayout. Struktur-bewusstes Chunking liefert bei gut formatierten Dokumenten (technische Dokumentation, Gesetzestexte, Handbücher mit Nummerierung) die saubersten Ergebnisse, weil jeder Chunk einer logischen Einheit entspricht, die ein Mensch auch als solche erkennen würde.

Overlap: wie viel Überlappung zwischen Chunks sinnvoll ist

Egal welche Strategie Sie wählen: An jeder Chunk-Grenze geht potenziell Kontext verloren. Ein Satz, der eine Information einleitet, kann im einen Chunk stehen, während die eigentliche Aussage im nächsten folgt. Overlap löst das, indem die letzten Sätze oder ein fester Prozentsatz eines Chunks am Anfang des nächsten wiederholt werden.

• 10-20 % Overlap ist für die meisten Textarten ein solider Startwert.
• Bei sehr kurzen Chunks (unter 200 Tokens) lohnt sich oft ein größerer relativer Overlap, weil jeder einzelne Satz mehr Gewicht hat.
• Bei strukturierten Dokumenten mit klaren Abschnittsgrenzen (Verträge, Normen) kann der Overlap gering oder sogar null sein, weil die Struktur selbst den Kontext liefert.
• Zu viel Overlap bläht den Index auf, erhöht Speicherkosten und kann bei der Suche zu redundanten Treffern führen, die denselben Satz mehrfach zitieren.

Ein praktischer Test: Lesen Sie zehn zufällige Chunk-Paare an ihren Grenzen. Wenn ein Mensch den Satz an der Grenze ohne den vorherigen oder nächsten Chunk nicht verstehen würde, ist der Overlap zu niedrig oder die Chunk-Grenze schlecht gewählt.

Wie die Chunk-Größe die Antwortqualität konkret beeinflusst

Precision beschreibt hier, wie zielgenau ein einzelner Chunk zur Frage passt, Recall, wie wahrscheinlich die relevante Information überhaupt in den abgerufenen Chunks enthalten ist. Kleine Chunks maximieren Precision, weil jeder Vektor ein eng umrissenes Thema repräsentiert, bergen aber das Risiko, dass eine Antwort auf mehrere Chunks verteilt ist und keiner davon allein genug Kontext bietet. Große Chunks erhöhen die Chance, dass die Antwort irgendwo enthalten ist, verwässern aber die semantische Suche und erhöhen die Tokenkosten pro Anfrage, was sich auch auf die Kosten einer Vektordatenbank auswirkt.

Praktische Defaults nach Dokumenttyp

Ohne eigene Tests ist jede Zahl nur ein Startpunkt, aber folgende Richtwerte haben sich in der Praxis als brauchbare erste Einstellung bewährt:

• FAQ-Listen und kurze Supportartikel: 150-300 Tokens, je ein Chunk pro Frage-Antwort-Paar, kaum Overlap nötig.
• Technische Dokumentation und Handbücher: 300-500 Tokens, struktur-bewusst nach Überschriften geschnitten, 10-15 % Overlap.
• Verträge und Rechtstexte: struktur-bewusst nach Paragrafen oder Klauseln, unabhängig von der Länge, weil eine Klausel eine juristische Einheit ist, die nicht getrennt werden darf.
• Berichte, Studien, lange Fließtexte: 400-600 Tokens satzbasiert, 15-20 % Overlap.
• Gesprächsprotokolle und Chatverläufe: Chunking entlang kompletter Gesprächswendungen, nicht nach Zeichenanzahl.
• Code-Dokumentation: entlang von Funktionen, Klassen oder Abschnitten, nie mitten in einem Codeblock.

Chunking in der Praxis testen und iterieren

Die beste Chunk-Strategie lässt sich nicht am Schreibtisch festlegen, sondern nur mit echten Fragen gegen echte Dokumente. Ein pragmatisches Vorgehen:

1. Stellen Sie 15-20 realistische Fragen zusammen, die Nutzer tatsächlich stellen würden, inklusive Grenzfällen (Fragen, deren Antwort über zwei Abschnitte verteilt ist).
2. Prüfen Sie für jede Frage, ob die abgerufenen Chunks die Antwort vollständig enthalten, nur teilweise oder gar nicht.
3. Passen Sie Chunk-Größe oder Overlap gezielt für die Fälle an, bei denen die Antwort nur teilweise gefunden wurde.
4. Kontrollieren Sie stichprobenartig die zitierten Quellenpassagen, wie in KI-Antworten mit Quellenangaben prüfen beschrieben, statt sich allein auf den Gesamttext der Antwort zu verlassen.
5. Wiederholen Sie den Test nach jeder größeren Dokumentenaktualisierung, denn ein neues Layout kann die Struktur-Erkennung durcheinanderbringen.

Wer eigene Pipelines mit API oder MCP-Server betreibt, findet die technischen Details zu Abfragemodi (belegte Antworten oder reine Passagen) in den Entwicklerdokumenten. Für den Einstieg reicht es oft, eine Testbasis über eine neue Wissensbasis anlegen zu erstellen, ein paar Dokumente hochzuladen und die automatische Chunking-Pipeline direkt gegen eigene Fragen zu prüfen, bevor man Zeit in eine selbstgebaute Lösung investiert.

Häufige Fragen zum Chunking bei RAG