Document Chunking Strategy (Chunking-Strategie)
Eine Document Chunking Strategy (Chunking-Strategie) ist ein Regelwerk, wie Dokumente in sinnvolle Textabschnitte (Chunks) zerlegt werden – inklusive Chunk-Größe, Overlap (Überlappung), Struktur-Erhalt und Metadaten. Ziel ist, dass RAG (Retrieval-Augmented Generation) die richtigen Passagen zuverlässig findet, damit ein Large Language Model (LLM) präziser antwortet und weniger Halluzinationen (Hallucinations) produziert.
Was bedeutet „Chunking-Strategie“ konkret?
„Chunking“ heißt: Inhalte werden vor dem Indexieren in einer Vektordatenbank (Vector Database) in kleinere Einheiten geteilt, damit Embeddings und Vector Search (Vektorsuche) / Semantic Search relevante Stellen besser treffen. Die Strategie legt fest, wo geschnitten wird (z. B. an Überschriften), wie groß Chunks sind (z. B. 300–800 Tokens) und wie viel Kontext durch Overlap mitgegeben wird (z. B. 10–20%).
Wie funktioniert eine Document Chunking Strategy?
- 1) Dokument analysieren: Struktur erkennen (Titel, Abschnitte, Tabellen, Bulletpoints, FAQ, Codeblöcke). Bei PDFs ggf. vorher OCR (Optical Character Recognition).
- 2) Split-Regeln definieren: Erst „soft“ an natürlichen Grenzen (Überschrift, Absatz), dann „hard“ nach Token-Limit. Wichtig: Chunks sollten thematisch kohärent bleiben.
- 3) Chunk-Größe wählen: Zu klein = Kontext fehlt, zu groß = Retrieval wird unscharf und frisst Kontextfenster (Context Window). Häufige Startwerte: 400–700 Tokens für Fließtext, kleiner für FAQs oder Policies.
- 4) Overlap festlegen: Überlappung verhindert, dass wichtige Sätze „zwischen zwei Chunks“ verloren gehen. Typisch: 50–150 Tokens oder 10–20% der Chunk-Länge.
- 5) Metadaten & IDs: Quelle, Abschnittstitel, Seitenzahl, Datum, Doc-Version, Berechtigung (für Zugriffskontrolle). Das verbessert Filter, Zitierfähigkeit und Governance.
- 6) Indexieren & testen: Chunks einbetten (Embeddings) und Retrieval mit echten Fragen evaluieren (Trefferquote, Relevanz, Zitierqualität). Optional: Re-Ranking (Neu-Rangordnung).
Warum ist eine Chunking-Strategie wichtig für RAG?
In RAG-Systemen entscheidet die Chunking-Qualität oft stärker über die Antwortqualität als das Modell selbst. Gute Chunks erhöhen die Chance, dass semantische Suche die richtige Passage findet, reduzieren Redundanz und senken Tokenkosten. Schlechte Chunks führen zu „falschem Kontext“: Das Modell wirkt dann sicher, aber bezieht sich auf irrelevante Textteile – ein häufiger Auslöser für Halluzinationen (Hallucinations).
Beispiele aus der Praxis
- Handbuch / Wiki: Chunking nach Überschriften (H2/H3), 500–800 Tokens, 15% Overlap. Metadaten: Kapitel, Produktversion.
- FAQ-Seite: Pro Frage-Antwort ein Chunk (klein, 150–300 Tokens), kaum Overlap. Vorteil: sehr präzises Retrieval.
- Richtlinien / Compliance: Abschnitte inkl. Definitionen zusammenhalten, eher kleinere Chunks (300–500 Tokens), Overlap moderat. Metadaten für Gültigkeit/Datum sind entscheidend (z. B. für AI Governance).
- Tabellen / Preislisten: Tabellen als eigene Chunks, ggf. zusätzlich „row-wise“ Splits. Sonst gehen Relationen verloren.
Typische Fehler (und wie man sie vermeidet)
- Nur nach Zeichen/Lines splitten: zerstört Semantik. Besser: strukturbasiert + Token-Limit.
- Zu viel Overlap: erhöht Indexgröße und liefert redundante Treffer. Overlap nur so groß wie nötig.
- Keine Metadaten: erschwert Filter (z. B. „nur aktuelle Version“) und Quellenangaben.
- Einheits-Chunking für alle Dokumenttypen: FAQs, Policies, Code und Handbücher brauchen unterschiedliche Regeln.
Eine gute Document Chunking Strategy ist damit ein zentraler Baustein jedes RAG-Stacks – neben Retrieval (Information Retrieval), Vektordatenbank (Vector Database) und sauberer Evaluation.