Chunking

Chunking bezeichnet die Aufteilung längerer Texte in kleinere, in sich geschlossene Abschnitte (Chunks). Jeder Abschnitt wird einzeln in einen Suchindex (die durchsuchbare Ablage) geschrieben und bei einer Frage als eigenständige Einheit an ein Sprachmodell weitergegeben. Der Schritt gehört zur Vorverarbeitung (Ingest) einer Retrieval-Augmented-Generation-Architektur (RAG, ein Muster, das eine Suche vor die Antwort schaltet) und bestimmt mit, wie fein oder grob der Text ist, den das Modell später als Kontext liest.

Was ist Chunking?

Chunking ist der Vorbereitungsschritt zwischen dem Einlesen des Dokuments (Parsing) und dem Umwandeln in Vektoren (Embedding, eine Zahlenrepräsentation, über die eine Suche Ähnlichkeit misst). Ein Roh-Dokument (PDF, HTML, Markdown, Confluence-Export) wird zunächst in reinen Text überführt und anschließend in Abschnitte definierter Größe zerlegt. Jeder Abschnitt bekommt seinen eigenen Vektor, landet in einem Vektor- oder Hybrid-Index (einer Ablage, die sowohl Bedeutungs- als auch Stichwort-Suche erlaubt) und ist dort die kleinste Einheit, die eine Suche zurückgeben kann. Der Schritt wirkt trivial, entscheidet aber über die Qualität aller nachgelagerten Antworten: Ein Suchtreffer ist immer nur so präzise wie der Abschnitt, den er zurückliefert.

Der Begriff hat sich durchgesetzt, weil drei Grenzen zusammenkommen, die den Text-Fluss unterbrechen. Embedding-Modelle verarbeiten pro Vektor ein festes Input-Fenster von typisch 512 bis 8.192 Tokens. Die semantische Auflösung eines Vektors sinkt bei zu langen Texten, weil viele Themen im gleichen Vektor gemittelt werden. Das Kontextfenster des Sprachmodells ist begrenzt und pro Token bepreist. Ohne Aufteilung landet entweder zu wenig relevanter Text im Modell oder zu viel irrelevanter Ballast.

Die zwei zentralen Stellschrauben sind Chunk-Größe (typisch 200 bis 1.000 Tokens) und Overlap (typisch 10 bis 20 Prozent). Kleine Chunks liefern präzise Treffer, verlieren aber Kontext um die Kernaussage herum. Große Chunks halten den Kontext, machen die Suche aber unschärfer und den Prompt teurer. Der Overlap wiederholt einen Teil des vorherigen Chunks am Anfang des nächsten und rettet damit Bedeutung, die sonst genau an der Chunk-Grenze verloren ginge.

Es gibt fünf gängige Strategien mit unterschiedlichem Aufwand und Ergebnis:

• Fixed-size: feste Token- oder Zeichen-Grenze, mit Overlap. Einfach, schnell, ignoriert Dokumentstruktur.
• Recursive: hierarchische Trenner (Absatz → Satz → Wort) mit Fallback, wenn die Zielgröße überschritten wird. Standard in [LangChain](https://python.langchain.com/docs/how_to/recursive_text_splitter/) und [LlamaIndex](https://docs.llamaindex.ai/en/stable/module_guides/loading/node_parsers/modules/).
• Semantic: Grenzen an Bedeutungswechseln, gemessen über die Embedding-Distanz zwischen Sätzen. Teurer, präziser bei heterogenen Texten.
• Document-aware: nutzt Markdown-Header, HTML-Tags, PDF-Layout oder Code-Blöcke als natürliche Grenzen und respektiert die Struktur des Ausgangsdokuments.
• Late Chunking und Contextual Retrieval: neuere Verfahren, die Kontext vor dem Chunking einbetten (Jina AI 2024) oder jedem Chunk einen vom Sprachmodell generierten Kontext-Präfix voranstellen ([Anthropic 2024](https://www.anthropic.com/news/contextual-retrieval)), um Bedeutung über die Chunk-Grenze hinweg zu retten.

Abgrenzung zu Tokenization, Embedding und Retrieval-Strategien

Der Begriff wird in der Praxis oft mit angrenzenden Schritten der Sprachmodell-Verarbeitung vermischt.

Der wichtigste Unterschied besteht zu Tokenization. Beide zerlegen Text, aber auf verschiedenen Ebenen. Chunking arbeitet auf lesbaren Text-Blöcken (Absätze, Sätze, Abschnitte) und erzeugt die Einheiten, die in einem Index gespeichert werden. Tokenization arbeitet auf Sub-Word-Ebene und erzeugt die numerischen Einheiten, die ein Modell intern verarbeitet. Ein Chunk enthält typisch mehrere Hundert Tokens; ein einzelnes Token ist meist kleiner als ein Wort. Chunking passiert einmalig zur Ingest-Zeit, Tokenization bei jedem Modell-Aufruf.

Zu Embedding und Retrieval-Strategien ist die Abgrenzung eine Frage der Pipeline-Position. Chunking erzeugt die Text-Einheiten, das Embedding wandelt sie in Vektoren, und die Retrieval-Strategien holen sie zur Query-Zeit wieder ab. Die drei Schritte laufen nacheinander, sind aber unabhängig optimierbar: ein anderes Chunking verlangt kein neues Embedding-Modell, und ein Reranker verändert das Chunking nicht.

Beispiel: Ingest-Pipeline für einen Wissensassistenten

Ein interner Wissensassistent soll Fragen zu technischen Handbüchern beantworten, die als 2.000 bis 5.000 PDF-Seiten pro Anlage vorliegen. Die Ingest-Pipeline läuft in vier Schritten. Ein Parser (etwa Unstructured oder Docling) überführt das PDF in strukturierte Blöcke mit Header-, Absatz- und Tabellen-Information. Ein Recursive Chunker teilt diesen Text mit einer Zielgröße von 800 Tokens und 100 Tokens Overlap; als bevorzugte Splitpunkte gelten Kapitel-Header und Absatz-Grenzen. Ein Embedding-Modell (zum Beispiel bge-large-en-v1.5 oder text-embedding-3-large) erzeugt für jeden der rund 15.000 Chunks einen Vektor. Der Vektor-Index (Databricks Mosaic AI Vector Search, pgvector oder Pinecone) speichert Vektor, Chunk-Text und Herkunfts-Metadaten.

Zur Query-Zeit liefert die Suche die sechs bis acht besten Chunks pro Frage an das Sprachmodell, das daraus eine Antwort formuliert. Die Qualität hängt hier an der Chunk-Größe: Mit 256-Token-Chunks würden Wartungsanleitungen mitten in einem Handlungsschritt abreißen, mit 5.000-Token-Chunks würde jede Frage grobe Kapitel treffen und keine präzise Anweisung. Der Chunker ist der stille Regelbau der Retrieval-Qualität und der Punkt, an dem sich später viele Debug-Sitzungen sammeln, wenn eine Antwort unvollständig oder unzusammenhängend wird.