Chunking von Dokumenten für RAG: Wie teilen, damit Retrieval funktioniert

Ein Unternehmen mit 4000 PDF-Dokumenten, das diese mit der Standardeinstellung „je 500 Zeichen“ indiziert, erhält einen Assistenten, der den richtigen Absatz zitiert, aber nicht versteht, um welchen Vertrag es sich handelt. Die Retrieval-Präzision sinkt in dieser Variante um 30–50% im Vergleich zu einem kalibrierten Pipeline. Das Problem liegt nicht im Sprachmodell oder der Vektordatenbank, sondern in der Granularität der Fragmente.

Feste Größe (Fixed-Size Chunking) teilt das Dokument in Fragmente mit einer vorab festgelegten Anzahl von Token oder Zeichen, optional mit Verschiebung (Overlap). Dies ist der einfachste Ansatz, schnell zu implementieren und vorhersehbar in den Indexierungskosten. Er eignet sich, wenn Dokumente eine homogene Struktur haben, z. B. Systemprotokolle oder Produktbeschreibungen, die nach einer Vorlage verfasst sind. Hauptnachteil: Der Splitter erkennt keine Satzgrenzen und schneidet oft mitten im Gedanken ab.

Recursive Character Splitter (z. B. RecursiveCharacterTextSplitter in LangChain) versucht, semantische Grenzen zu wahren, indem er nacheinander nach \n\n, \n, . und erst am Ende nach einem Zeichen teilt. Für die meisten polnischen Geschäftsdokumente, d. h. Anleitungen, Regularien und Berichte in Prosa, ist dies die Standardwahl, die ein gutes Verhältnis von Qualität zu Aufwand bietet.

Semantisches Chunking gruppiert Sätze mit ähnlicher Bedeutung basierend auf der Kosinus-Ähnlichkeit aufeinanderfolgender Embeddings. Die Fragmentgröße ist variabel, was die Vorhersage der Tokenanzahl und der Inferenzkosten erschwert, aber die Retrieval-Präzision für lange, dichte Dokumente (z. B. mehrseitige Verträge) kann um 10–25% höher sein als bei Fixed-Size.

Es gibt keine universelle richtige Größe. Sie hängt von drei Faktoren ab: dem Embedding-Modell, der Art der Benutzerfragen und der durchschnittlichen Antwortlänge, die der Assistent liefern soll.

Praktische Richtwerte für polnische Geschäftsdokumente:

• Faktografische Fragen (Daten, Namen, Beträge): 256–512 Token, Overlap 50–80 Token.
• Fragen, die Kontext einer Prozedur erfordern: 512–1024 Token, Overlap 100–150 Token.
• Narrative Dokumente, Analysen, Berichte: 1024–2048 Token, Overlap 150–200 Token.

Overlap ist kein „Platzverschwendung“. Fragment A, das mitten in einem Absatz endet, und Fragment B, das 100 Token früher beginnt, garantieren zusammen, dass die semantische Suche die Antwort findet, selbst wenn die Frage genau auf die Teilungsgrenze trifft.

Embedding-Modelle haben eine Kontextgrenze: BGE-M3 unterstützt bis zu 8192 Token, aber das qualitative Optimum liegt im Bereich von 512–1024 Token pro Fragment. Oberhalb dieser Schwelle verteilt sich das semantische Signal über das gesamte Fenster, und die Retrieval-Präzision sinkt.

Tabellen und Code sind Strukturen, die ein Standard-Splitter nach Zeichen zerstört. Eine Tabelle, die zwischen zwei Fragmente gerissen wird, verliert die Spaltenüberschriften im ersten und die Daten im zweiten Fragment, sodass das Modell die Werte nicht mit ihrer Bedeutung verknüpfen kann.

Lösung: Erkennen Sie Tabellen und Code-Blöcke in der Phase der Dokumentenanalyse (z. B. mit pdfplumber, camelot oder Unstructured.io) und gehen Sie dann wie folgt vor:

• Tabellen: Wandeln Sie sie in ein Textformat (Markdown oder JSON row-by-row) um und speichern Sie sie als separates Chunk mit der Metadaten type: table. Wenn die Tabelle länger als 512 Token ist, teilen Sie sie in Blöcke von 5–10 Zeilen, wobei die Überschrift in jedem Block wiederholt wird.
• Code: Behalten Sie ihn als ein Chunk von maximal 1024 Token. Wenn der Code länger ist, teilen Sie ihn nach Funktionsblöcken (Zeilen, die mit def, function, class beginnen), nicht nach einer willkürlichen Anzahl von Zeichen.

Metadaten wie type: table und type: code ermöglichen späteres Filtern in hybriden Abfragen. Mehr dazu im Artikel Wie man Unternehmensdaten für KI vorbereitet.

Der Text des Fragments allein reicht nicht aus. Jedes Chunk sollte Metadaten tragen, die die Vektordatenbank vor dem Reranking filtern kann: Name der Quelldatei, Seitenzahl, Dokumententyp, Aktualisierungsdatum, Kunden- oder Projekt-ID (falls zutreffend).

Das Filtern nach Metadaten vor der Vektorsuche reduziert den Suchraum und entfernt veraltete oder irrelevante Dokumente aus den Ergebnissen. Für ein Unternehmen mit 4000 Dokumenten, die in Kategorien (Verträge, Anleitungen, FAQ) unterteilt sind, verkürzt dieser Schritt die Liste der Kandidaten um 60–80% vor dem eigentlichen semantischen Ranking.

Ein RAG-Pipeline mit Metadatenfiltern sieht wie folgt aus: Benutzerabfrage → Embedding der Abfrage → Filter (z. B. type: contract AND client_id: X) → Vektorsuche im Teilbestand → Reranking der Top-k → Antwortgenerierung. Der Effekt ist messbar: Die Antwortpräzision steigt, und die Anzahl der Halluzinationen sinkt, weil das Modell nur relevante Fragmente erhält.

Mehr zur Bewertung der Retrieval-Qualität im Artikel RAG: Bewertung der Antwortqualität.

Sie haben eigene Dokumente und fragen sich, wo Sie anfangen sollen? Der folgende Sandbox ermöglicht es Ihnen, die Reasoning-Strategie für Ihren Fall zu testen:

Für Verträge und Regularien liegt das Optimum im Bereich von 512–768 Token mit einem Overlap von 80–120 Token. Wichtiger als die Größe selbst ist der Teilungspunkt: Teilen Sie nach Abschnittsüberschriften (§ 1, § 2, „Allgemeine Bestimmungen“), nicht nach einer willkürlichen Anzahl von Zeichen. Eine Klausel, die vollständig in einem Chunk landet, wird präziser retrievalt als dieselbe Klausel, die auf zwei Fragmente aufgeteilt ist.

Nein. Ein Overlap von mehr als 20–25% der Chunk-Größe erhöht die Indexierungskosten und kann Redundanzen einführen, die das Ranking stören. Wenn zwei Fragmente mit 50% gemeinsamer Inhalte in die Top-5-Ergebnisse gelangen, erhält das Modell duplizierten Kontext statt unterschiedlicher Perspektiven. Ein Overlap von 10–15% der Chunk-Größe ist ein sicherer Ausgangspunkt für die meisten Dokumente.

Chunking beeinflusst beide Komponenten: Zu kurze Fragmente verlieren Schlüsselwörter für BM25, zu lange verwässern das Vektorsignal. Für die hybride Suche liegt das Optimum meist im Bereich von 512–1024 Token, wo beide Signale effektiv wirken. Führen Sie A/B-Tests an einem repräsentativen Fragenpool durch, bevor Sie die endgültige Größe festlegen.

Ja, eine vollständige Re-Indizierung ist nach einer Änderung der Strategie oder Chunk-Größe notwendig. Embeddings, die aus unterschiedlich aufgeteilten Fragmenten generiert werden, sind nicht mit den vorherigen vergleichbar. In der Praxis: Bereiten Sie eine neue Sammlung neben der alten vor, führen Sie Qualitätstests an einem Golden Set durch, und schalten Sie den Traffic erst nach Erreichen besserer Ergebnisse auf die neue Sammlung um. Mehr dazu im Artikel Aktualisierung von RAG-Wissen und Versionierung.

Verwenden Sie einen strukturellen Parser wie Unstructured.io oder pdfplumber, der die Elementtypen vor dem Splitter erkennt. Fortlaufenden Text verarbeiten Sie mit einem Recursive Splitter, Tabellen konvertieren Sie in Markdown row-by-row mit wiederholter Überschrift, Bilder (Diagramme, Schemata) beschreiben Sie mit einem Vision-Modell und fügen die Beschreibung als separates Chunk mit der Metadaten type: image_caption hinzu. Diese Segmentierung ermöglicht es, die semantische Struktur des Dokuments zu erhalten, ohne Informationen in einer der Ebenen zu verlieren.