Chunk (Textsegment)
Lange Dokumente passen nicht als Ganzes in ein Einbettungsmodell. Deshalb werden sie vor der Verarbeitung in kleinere Abschnitte zerlegt. Diese Abschnitte heißen Chunks.
Warum Dokumente aufgeteilt werden müssen
Einbettungsmodelle haben ein begrenztes Eingabefenster. BERT-basierte Modelle verarbeiten maximal 512 Tokens, andere Modelle bis zu 8.192 oder mehr. Ein typisches Geschäftsdokument überschreitet diese Grenze bei Weitem.
Dazu kommt ein zweites Problem: Je länger ein Text, desto allgemeiner wird sein Vektor. Ein Vektor, der 50 Seiten repräsentiert, verwässert die Bedeutung einzelner Abschnitte. Bei einer Suchanfrage wird dann das gesamte Dokument als "irgendwie relevant" eingestuft, statt den präzise passenden Abschnitt zu identifizieren.
Beispiel 1: Eine 80-seitige Produktdokumentation. Eine Suchanfrage lautet "Wie setze ich das Admin-Passwort zurück?". Die Antwort steht auf Seite 47. Wenn das Dokument als Ganzes vektorisiert wird, ist der Vektor zu allgemein, um diesen Abschnitt gezielt zu finden. Wird das Dokument in Chunks aufgeteilt, erhält der Abschnitt auf Seite 47 einen eigenen Vektor, der präzise zur Anfrage passt.
Beispiel 2: Ein Gesetzestext mit 200 Paragraphen. Die Anfrage "Kündigungsfrist bei befristeten Arbeitsverträgen" soll genau den relevanten Paragraphen finden, nicht das gesamte Gesetz als Treffer liefern.
Wie Chunking funktioniert
Der Prozess folgt einem festen Ablauf: Ein Dokument wird entgegengenommen, nach einer definierten Strategie in Abschnitte zerlegt, und jeder Abschnitt wird einzeln vektorisiert und gespeichert.
Beispiel: 500 Support-Artikel werden für ein RAG-System aufbereitet. Jeder Artikel wird in Chunks von 300 bis 500 Tokens zerlegt. Das ergibt rund 3.000 Chunks, die einzeln vektorisiert und in einer Vektordatenbank gespeichert werden. Bei einer Suchanfrage durchsucht das System nicht 500 Dokumente, sondern 3.000 präzise Textabschnitte.
Chunking-Strategien
Wie ein Dokument zerlegt wird, beeinflusst die Suchqualität direkt. Es gibt mehrere erprobte Strategien.
Feste Größe (Fixed-Size)
Der Text wird in Abschnitte gleicher Länge geteilt, gemessen in Tokens oder Zeichen. Einfach umzusetzen, aber Satzgrenzen werden ignoriert. Ein Chunk kann mitten im Satz enden.
Beispiel: Chunk-Größe 200 Tokens. Ein Absatz mit 350 Tokens wird in zwei Chunks geteilt: 200 + 150. Der erste Chunk endet mitten im Satz.
Satzbasiert
Chunks werden an Satzgrenzen geschnitten. Jeder Chunk enthält eine bestimmte Anzahl vollständiger Sätze. Sprachlich sauberer, aber die Größe variiert stärker.
Absatzbasiert
Das Dokument wird an Absatzgrenzen geteilt. Funktioniert gut bei strukturierten Texten (Handbücher, Gesetzestexte), weniger bei Fließtext ohne klare Absätze.
Semantisch
Ein Algorithmus erkennt thematische Brüche im Text und setzt die Chunk-Grenzen dort. Aufwendiger, liefert aber inhaltlich kohärentere Chunks.
Beispiel: Ein Fachartikel behandelt drei Themen: Datenaufbereitung, Modelltraining und Evaluation. Semantisches Chunking erkennt die Themenübergänge und erzeugt drei Chunks, die jeweils ein Thema vollständig abdecken.
Overlap: Überlappung zwischen Chunks
Wenn ein Chunk genau an einer Grenze endet, geht der Kontext am Übergang verloren. Die Lösung: Aufeinanderfolgende Chunks überlappen sich um eine definierte Anzahl von Tokens.
Beispiel: Chunk-Größe 400 Tokens, Overlap 50 Tokens. Chunk 1 enthält Token 1 bis 400. Chunk 2 enthält Token 351 bis 750. Die letzten 50 Tokens von Chunk 1 sind identisch mit den ersten 50 Tokens von Chunk 2. Damit bleibt der Kontext am Übergang erhalten.
Beispiel: Ohne Overlap: "Die Kündigungsfrist beträgt drei" | "Monate ab Zugang der Erklärung." Keiner der beiden Chunks enthält die vollständige Information. Mit Overlap: Beide Chunks enthalten den vollständigen Satz.
Chunk-Größe: der zentrale Kompromiss
Zu kleine Chunks verlieren Kontext. Zu große Chunks verwässern die Präzision. Die optimale Größe hängt vom Anwendungsfall ab.
- Kleine Chunks (100 bis 200 Tokens): Hohe Präzision bei Faktensuche. Aber: Einzelne Sätze ohne Kontext können mehrdeutig sein.
- Mittlere Chunks (300 bis 500 Tokens): Häufiger Standard. Guter Kompromiss zwischen Präzision und Kontext.
- Große Chunks (800 bis 1.500 Tokens): Mehr Kontext, aber weniger präzise bei spezifischen Fragen.
Beispiel: Ein FAQ-System mit kurzen, präzisen Fragen profitiert von kleinen Chunks (eine Frage-Antwort pro Chunk). Eine juristische Recherche, bei der Zusammenhänge zwischen Paragraphen relevant sind, braucht größere Chunks.
Grenzen und häufige Fehler
- Kontextverlust: Kein Chunk enthält das gesamte Dokument. Fragen, die ein Gesamtverständnis erfordern ("Worum geht es in diesem Dokument insgesamt?"), lassen sich mit Chunks allein nicht beantworten.
- Metadaten-Verlust: Nach dem Chunking fehlt oft die Information, aus welchem Dokument, Kapitel oder Abschnitt ein Chunk stammt. Diese Metadaten müssen explizit mitgespeichert werden.
- Tabellen und Listen: Strukturierte Inhalte wie Tabellen lassen sich nicht sinnvoll in der Mitte teilen. Hier braucht es spezielle Chunking-Logik.
Beispiel: Eine Tabelle mit Produktpreisen wird mitten in einer Zeile geteilt. Chunk 1 enthält den Produktnamen, Chunk 2 den Preis. Keine der beiden Informationen ist für sich allein nützlich.
Fachliche Einordnung: Chunking ist kein einmaliger Schritt, sondern ein Parameter, der die gesamte Retrieval-Qualität beeinflusst. In der Praxis wird die Chunk-Größe zusammen mit dem Einbettungsmodell und der Suchstrategie als System optimiert. Änderungen an der Chunk-Größe erfordern eine Neuindexierung aller Dokumente und eine erneute Evaluation der Suchqualität.