11.09.2023 AI Engineering 4 Minuten Lesezeit

Chunking-Strategien für Document QA

Chunking bestimmt, was ein Document-QA-System überhaupt finden kann. Wir vergleichen Fixed-Size- und rekursives Splitting, quantifizieren die Trade-offs von Chunk-Größe und Overlap gegen die Kontextfenster von 2023 und erklären, warum Metadaten Pflicht sind. Mit verifizierten Zahlen von Pinecone, OpenAI und dem Lost-in-the-Middle-Paper — und einem 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.

Das Chunking wird einmal festgelegt, früh, und meist durch Übernahme eines Bibliotheks-Defaults. Das ist ein Fehler. Der Chunk ist die Einheit des Retrievals: Was nie korrekt zerlegt wurde, kann nie korrekt gefunden werden. In unseren Kundenprojekten hat eine Änderung der Chunking-Strategie die Antwortqualität stärker bewegt als jeder 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 entkoppeln außerdem die Retrieval-Einheit von der Generierungseinheit. Speichern Sie kleine Chunks für präzises Matching, halten Sie eine Parent-Referenz in den Metadaten und geben Sie dem LLM den umgebenden Abschnitt. Dieses Small-to-Large-Muster schlägt rohes Top-k-Retrieval — zum Preis zusätzlicher 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 aber intelligenter. Semantisches Splitting über Embeddings, layoutbewusstes PDF-Parsing und evaluationsgetriebene Wahl der Chunk-Größe werden hartkodierte Defaults ablösen. Retrieval wird sich weiter von Chunk-Grenzen entkoppeln. Die Teams, die Chunking als messbare Engineering-Entscheidung behandeln — nicht als Default — werden die besseren QA-Systeme bauen.