11.09.2023 AI Engineering4 Minuten Lesezeit

Chunking-Strategien für Document QA

Chunking legt fest, was ein Document-QA-System überhaupt finden kann. Wir vergleichen Fixed-Size- mit rekursivem Splitting, quantifizieren die Trade-offs von Chunk-Größe und Overlap unter den Kontextgrenzen von 2023 und zeigen, warum Metadaten unverzichtbar sind. Grundlage sind verifizierte Zahlen von Pinecone, OpenAI und aus dem Lost-in-the-Middle-Paper — ergänzt um einen Ausblick vom September 2023.

Die erste Entscheidung in jeder Document-QA-Pipeline

Document Question Answering folgt 2023 einem Standardmuster: Dokumente in Chunks zerlegen, jeden Chunk einbetten, die Vektoren speichern, zur Anfrage die Top-k-Chunks abrufen und ein Sprachmodell daraus eine Antwort erzeugen lassen. Retrieval-Augmented Generation (RAG) ist der etablierte Name für diese Pipeline. Jeder Schritt bekommt Aufmerksamkeit — außer dem ersten.

Die Chunking-Strategie fällt früh im Projekt und wird danach selten überprüft — oft übernimmt das Team schlicht den Default einer Bibliothek. Das ist riskant, denn der Chunk ist die Einheit des Retrievals: Was falsch segmentiert wurde, lässt sich später nicht zuverlässig finden. In unseren Kundenprojekten hat eine bessere Chunking-Strategie die Antwortqualität stärker verändert als der Wechsel des Embedding-Modells oder des LLM.

Dokumente werden gechunkt, eingebettet und indexiert — Vektoren plus Volltext. 1/4

Warum Chunking die Retrieval-Qualität dominiert

Ein Embedding komprimiert einen Chunk in einen einzigen Vektor — 1.536 Dimensionen bei OpenAIs text-embedding-ada-002, veröffentlicht im Dezember 2022. Der Vektor repräsentiert die mittlere Bedeutung des Chunks. Ein Chunk, der drei Themen mischt, erzeugt einen Vektor, der keines davon gut abbildet. Ein Chunk, der mitten im Satz endet, bettet ein Fragment ein.

Der Retriever kann nur ranken, was der Chunker produziert hat. Liegt eine Antwort über einer Chunk-Grenze, bringt keine Ähnlichkeitsmetrik sie vollständig zurück. Dazu kommen harte Limits: ada-002 akzeptiert maximal 8.191 Tokens pro Eingabe. Chunking-Fehler sind still — die Pipeline liefert plausiblen, aber unvollständigen Kontext, und das LLM füllt die Lücken mit flüssigem Rätselraten.

Splitting mit fester Größe

Fixed-Size-Splitting schneidet Text in Fenster von N Zeichen oder Tokens, optional mit Überlappung. Es ist deterministisch, schnell, benötigt kein Parsing und funktioniert auf jedem Input. LangChains Basis-TextSplitter nutzt als Default 4.000 Zeichen pro Chunk mit 200 Zeichen Overlap; LlamaIndex setzt derzeit 1.024 Tokens mit einem Overlap von 20.

Die Schwäche ist offensichtlich: Feste Fenster ignorieren Struktur. Sie schneiden durch Sätze, trennen Tabellen von ihren Kopfzeilen und Überschriften von den zugehörigen Absätzen. Für homogene Fließtexte ist Fixed-Size-Splitting eine brauchbare Baseline. Für Verträge, Handbücher oder alles, worin das Layout Bedeutung trägt, ist es eine schlechte Wahl.

Rekursives Splitting respektiert die Dokumentstruktur

Rekursives Splitting probiert eine Hierarchie von Trennzeichen und weicht erst auf die nächste Ebene aus, wenn ein Chunk noch zu groß ist. LangChains RecursiveCharacterTextSplitter verwendet als Default ["\n\n", "\n", " ", ""]: erst Absätze, dann Zeilen, dann Wörter. Das Ergebnis sind Chunks, die an natürlichen Grenzen enden, wann immer das Größenbudget es erlaubt.

Das ist eine Heuristik, keine Semantik. Der Splitter weiß nicht, dass zwei Absätze zum selben Argument gehören. Weil Absatzgrenzen aber stark mit Themenwechseln korrelieren, ist rekursives Splitting der empfohlene Default für generischen Text. Für Markdown, HTML und Quellcode liefern formatspezifische Trennzeichenlisten messbar bessere Ergebnisse.

Trade-offs bei Chunk-Größe und Overlap

Die Chunk-Größe ist ein Trade-off, keine Optimierung mit einer einzigen richtigen Antwort. Kleine Chunks betten präzise ein, verlieren aber den Umgebungskontext; große Chunks erhalten Kontext, verwässern jedoch den Vektor und füllen den Prompt schneller. Bei GPT-3.5-turbo mit 4.096 Tokens konkurrieren Instruktion, Frage und Antwort mit den abgerufenen Chunks um dasselbe Budget — praktisch bleiben rund 3.000 Tokens für Kontext.

Ein Overlap von 10 bis 20 Prozent mildert Verluste an Chunk-Grenzen; er beseitigt sie nicht und vergrößert Index und Embedding-Rechnung. Bei ada-002 kostet das seit Juni 2023 nur 0,0001 US-Dollar pro 1.000 Tokens — Indexgröße und Query-Latenz wachsen trotzdem. Pinecones Leitfaden vom April 2023 empfiehlt, Größen zwischen 128 und 1.024 Tokens gegen repräsentative Anfragen zu testen, statt Defaults zu vertrauen. Liu et al. ergänzen eine verwandte Warnung: Mehr als 20 abgerufene Dokumente verbesserten die Antwortgenauigkeit von GPT-3.5-Turbo nur um rund 1,5 Prozent. Mehr Kontext ist nicht automatisch besser.

Metadaten machen Chunks zu Belegen

Ein Chunk ohne Herkunft ist eine Sackgasse. Speichern Sie zu jedem Vektor mindestens: Quelldokument, Abschnittsüberschrift, Seite oder Position und Ingestion-Datum. Vektordatenbanken wie Pinecone, Weaviate und Qdrant unterstützen Metadaten-Filter zur Query-Zeit — aus 'alles durchsuchen' wird 'nur die Verträge von 2023 durchsuchen'.

Metadaten lösen zugleich die Retrieval-Einheit von der Generierungseinheit. Kleine Chunks ermöglichen präzises Matching; eine Parent-Referenz führt anschließend zum umgebenden Abschnitt, den das LLM für die Antwort erhält. Dieses Small-to-Large-Muster ist rohem Top-k-Retrieval überlegen, verlangt jedoch zusätzliche Buchführung.

Was Chunking nicht löst

Chunking kann kaputte Extraktion nicht reparieren. Wenn der PDF-Parser die Lesereihenfolge durcheinanderbringt oder Tabellenzellen verwirft, erbt jeder nachgelagerte Chunk den Schaden. Chunking behebt auch keinen Embedding-Mismatch: Ein generisches Modell rankt Fachjargon schlecht — unabhängig davon, wo die Segmentgrenzen liegen.

Vor allem beantwortet Chunk-basiertes Retrieval lokale Fragen. 'Wie lang ist die Kündigungsfrist in Abschnitt 8?' funktioniert. 'Fassen Sie diesen 300-Seiten-Bericht zusammen' funktioniert nicht — kein Top-k-Satz von Chunks enthält eine Gesamtsicht. Solche Aufgaben brauchen Map-Reduce-Summarization oder ähnliche Techniken, keinen besseren Splitter.

Ausblick vom September 2023

Kontextfenster wachsen schnell: Anthropics Claude 2 akzeptiert 100.000 Tokens, OpenAI bietet eine 16k-Variante von GPT-3.5-turbo und ein 32k-GPT-4. Die Versuchung liegt nahe, Chunking für obsolet zu erklären — das Dokument einfach komplett einfügen. Die Lost-in-the-Middle-Ergebnisse (Liu et al., Juli 2023) sprechen dagegen: Modelle nutzen Anfang und Ende langer Kontexte deutlich besser als die Mitte, und die QA-Genauigkeit von GPT-3.5-Turbo fiel unter die Closed-Book-Baseline von 56,1 Prozent, sobald die relevante Passage in der Mitte stand.

Unsere Erwartung für das kommende Jahr: Chunking bleibt, wird jedoch stärker datengetrieben. Semantisches Splitting über Embeddings, layoutbewusstes PDF-Parsing und eine evaluationsgestützte Wahl der Chunk-Größe werden hartkodierte Defaults zurückdrängen. Zugleich wird sich Retrieval weiter von starren Chunk-Grenzen lösen. Die besseren QA-Systeme werden Teams bauen, die Chunking als messbare Engineering-Entscheidung behandeln — nicht als einmal gesetzten Default.