Chunks
Wenn ein langes Dokument für eine Suche oder eine KI-Anwendung vorbereitet wird, zerlegt man es in kürzere Abschnitte. Jeder dieser Abschnitte heißt Chunk. Die Art der Zerlegung entscheidet darüber, ob später die richtigen Stellen gefunden werden.
Warum Dokumente in Abschnitte zerlegt werden
Ein Embedding-Modell wandelt Text in einen numerischen Vektor um. Dieser Vektor repräsentiert die Bedeutung des Textes in einem hochdimensionalen Raum. Je länger der Eingabetext, desto mehr Themen muss ein einzelner Vektor gleichzeitig abbilden. Ab einer bestimmten Länge verliert der Vektor an Trennschärfe: Er repräsentiert alles ein bisschen, aber nichts präzise.
Beispiel: Ein 50-seitiges Produkthandbuch enthält Kapitel zu Installation, Fehlerbehebung und Wartung. Ein einzelner Vektor für das gesamte Dokument würde bei der Suchanfrage "Fehlermeldung beim Start" keine hohe Ähnlichkeit erzielen, weil die Installationsanleitung und Wartungshinweise den Vektor in andere Richtungen ziehen.
Zusätzlich haben Embedding-Modelle eine technische Obergrenze für die Eingabelänge, gemessen in Tokens. Typische Modelle akzeptieren 512, 2.048 oder 8.192 Tokens. Text, der diese Grenze überschreitet, wird abgeschnitten. Chunks stellen sicher, dass jeder Abschnitt innerhalb dieses Limits bleibt.
Beispiel: Das Embedding-Modell text-embedding-3-small von OpenAI akzeptiert maximal 8.191 Tokens. Ein wissenschaftlicher Artikel mit 12.000 Tokens muss vor der Verarbeitung in mindestens zwei Abschnitte geteilt werden.
Die Rolle der Chunk-Größe
Die Chunk-Größe bestimmt, wie viel Kontext jeder einzelne Vektor enthält. Sie wird in Tokens gemessen und beeinflusst sowohl die Suchqualität als auch die Weiterverarbeitung durch ein Sprachmodell.
Kleine Chunks (100 bis 200 Tokens) sind thematisch eng fokussiert. Sie eignen sich für Suchanfragen, die eine konkrete Antwort aus einem bestimmten Absatz verlangen. Der Nachteil: Wenn eine Information über mehrere Sätze verteilt ist, fehlt dem Chunk der Zusammenhang.
Beispiel: Ein Chunk enthält den Satz "Die Dosierung beträgt 500 mg." Ohne den vorherigen Satz, der das Medikament benennt, ist die Information unbrauchbar.
Große Chunks (800 bis 2.000 Tokens) bewahren mehr Kontext. Sie eignen sich für Fragen, deren Antwort sich über mehrere Absätze erstreckt. Der Nachteil: Der Vektor verwischt thematisch, und bei RAG-Anwendungen wird mehr irrelevanter Text in den Prompt übernommen, was Token-Kosten erhöht und die Antwortqualität senken kann.
Beispiel: Ein Chunk aus einem Rechtstext umfasst einen ganzen Paragrafen mit 1.500 Tokens. Bei der Suche nach einer spezifischen Frist wird der gesamte Paragraf als Kontext geliefert. Das Sprachmodell muss die relevante Stelle selbst extrahieren.
In der Praxis haben sich Chunk-Größen zwischen 200 und 1.000 Tokens als Ausgangspunkt bewährt. Der optimale Wert hängt vom Texttyp, vom Embedding-Modell und vom Anwendungsfall ab. Systematisches Testen mit repräsentativen Suchanfragen liefert zuverlässigere Ergebnisse als Faustregeln.
Strategien für die Zerlegung
Es gibt mehrere Ansätze, um Text in Chunks zu zerlegen. Die Wahl der Chunking-Strategie hängt von der Textstruktur und den Anforderungen der Anwendung ab.
Feste Größe
Der Text wird nach einer festen Anzahl von Tokens oder Zeichen geteilt. Der Tokenizer des Embedding-Modells bestimmt die Zählung. Die Methode ist schnell und deterministisch, ignoriert aber die inhaltliche Struktur.
Beispiel: Ein Nachrichtenartikel wird alle 300 Tokens geschnitten. Ein Chunk endet mitten in einem Satz über eine Fusionsverhandlung. Der nächste Chunk beginnt mit "... abgeschlossen wurde", ohne dass klar ist, worum es geht.
Strukturbasierte Zerlegung
Der Text wird an natürlichen Grenzen geteilt: Absätze, Überschriften, Kapitel. HTML-Dokumente lassen sich an Heading-Tags (<h2>, <h3>) trennen, Markdown an Heading-Markern. Diese Methode erhält die thematische Kohärenz einzelner Chunks.
Beispiel: Eine technische Dokumentation gliedert sich in Abschnitte mit Überschriften. Jeder Abschnitt wird ein eigener Chunk. Bei der Suche nach "Konfiguration der Firewall" liefert der Chunk zum Abschnitt "Firewall-Einstellungen" ein präzises Ergebnis.
Semantische Zerlegung
Ein Modell bewertet die inhaltliche Ähnlichkeit aufeinanderfolgender Sätze. Sinkt die Ähnlichkeit unter einen Schwellenwert, wird an dieser Stelle getrennt. Der Vorteil: Chunks spiegeln thematische Einheiten wider. Der Nachteil: Die Methode benötigt einen zusätzlichen Embedding-Schritt und ist langsamer.
Beispiel: In einem Jahresbericht wechselt der Text von Umsatzzahlen zu Personalentwicklung. Die semantische Zerlegung erkennt den Themenwechsel und setzt dort die Grenze, obwohl kein Absatzumbruch vorhanden ist.
Überlappung zwischen Chunks
Bei den meisten Chunking-Verfahren gehen Informationen an den Schnittstellen verloren. Wenn ein Satz am Ende von Chunk A beginnt und in Chunk B endet, enthält keiner der beiden Vektoren den vollständigen Gedanken. Überlappende Chunks (Overlap) kopieren die letzten Tokens eines Chunks an den Anfang des nächsten.
Typische Overlap-Werte liegen bei 10 bis 20 Prozent der Chunk-Größe. Bei 500-Token-Chunks bedeutet das 50 bis 100 Tokens Überlappung. Zu viel Overlap erhöht die Anzahl der Chunks und damit den Speicherbedarf und die Suchzeit. Zu wenig Overlap riskiert Informationsverluste.
Beispiel: Chunk A endet mit "Die Wirksamkeit des Verfahrens hängt von". Chunk B beginnt mit "hängt von der Datenqualität ab." Mit 50 Tokens Overlap enthält Chunk B den vollständigen Satz und ist als Suchergebnis brauchbar.
Metadaten und Chunk-Anreicherung
Ein Chunk allein ist ein Textfragment ohne Herkunftsangabe. In produktiven Systemen wird jeder Chunk mit Metadaten gespeichert: Quelldokument, Seitenzahl, Kapitelüberschrift, Erstellungsdatum, Dokumenttyp. Diese Metadaten ermöglichen gezielte Filterung vor der Vektorsuche.
Beispiel: Eine juristische Wissensdatenbank speichert zu jedem Chunk das Gesetz, den Paragrafen und das Datum der letzten Änderung. Bei einer Suche lässt sich vorab filtern: "Nur Chunks aus dem BGB, geändert nach 2023."
Darüber hinaus setzen manche Systeme auf Chunk-Anreicherung: Vor dem Embedding wird der Chunk um Kontextinformationen ergänzt. Ein verbreiteter Ansatz fügt die Überschrift des übergeordneten Abschnitts an den Chunk-Text an. Dadurch erhält der Vektor zusätzliche thematische Information, ohne dass der Chunk selbst vergrößert wird.
Beispiel: Der Chunk enthält "Die Dosierung beträgt 500 mg täglich." Vor dem Embedding wird "Abschnitt: Medikament X, Kapitel: Dosierungsanleitung" vorangestellt. Der resultierende Vektor bildet sowohl den Inhalt als auch den Kontext ab.
Chunks im RAG-System
In einem RAG-System durchlaufen Chunks einen mehrstufigen Prozess. Zuerst werden die Dokumente in Chunks zerlegt und eingebettet. Bei einer Benutzeranfrage wird der Anfragetext ebenfalls eingebettet. Die Vektordatenbank liefert die k ähnlichsten Chunks, gemessen an der Cosine Similarity oder einer vergleichbaren Metrik. Diese Chunks werden als Kontext in den Prompt des Sprachmodells eingefügt.
Die Chunk-Größe beeinflusst hier mehrere Faktoren gleichzeitig: die Precision der Suchergebnisse, die Token-Kosten für den Prompt und die Fähigkeit des Sprachmodells, die relevante Information zu extrahieren.
Beispiel: Ein Kundensupport-System durchsucht 50.000 Chunks aus Produktdokumentationen. Die Anfrage "Wie setze ich das Passwort zurück?" liefert drei Chunks. Sind die Chunks zu groß (je 2.000 Tokens), enthält der Prompt 6.000 Tokens Kontext, wovon nur 200 Tokens die eigentliche Anleitung enthalten. Bei kleineren Chunks (400 Tokens) ist der Kontext kompakter und die Antwort präziser.
Fachliche Einordnung: Die Wahl der Chunk-Größe in RAG-Systemen ist ein Optimierungsproblem mit mehreren Zielgrößen. Kleinere Chunks verbessern tendenziell die Retrieval-Precision, erhöhen aber die Anzahl der nötigen Retrievals und das Risiko fehlenden Kontexts. Größere Chunks verbessern den Recall auf Dokumentebene, senken aber die Precision auf Absatzebene. Aktuelle Forschung untersucht hierarchische Ansätze, bei denen Chunks auf mehreren Granularitätsstufen gleichzeitig indexiert werden.
Grenzen und häufige Fehlerquellen
Die Zerlegung in Chunks ist eine Heuristik, keine exakte Methode. Mehrere Fehlerquellen treten in der Praxis regelmäßig auf.
Kontextverlust an den Schnittstellen bleibt auch mit Overlap ein Problem. Referenzen wie "dieser Ansatz", "das oben genannte Verfahren" oder Pronomen verlieren ihren Bezug, wenn der referenzierte Text in einem anderen Chunk liegt.
Beispiel: Ein Chunk beginnt mit "Dieses Verfahren reduziert die Fehlerrate um 30 Prozent." Ohne den vorherigen Chunk, der das Verfahren beschreibt, ist die Aussage nicht zuordenbar. Das Retrieval-System liefert einen Treffer, der für den Nutzer wertlos ist.
Tabellen, Listen und Code-Blöcke werden durch die meisten Chunking-Verfahren beschädigt. Eine Tabelle mit 20 Zeilen, die in der Mitte getrennt wird, erzeugt zwei Chunks, von denen keiner die vollständige Information enthält. Spezialisierte Parser, die solche Strukturen als Einheiten erkennen, vermeiden dieses Problem.
Beispiel: Eine CSV-Datei mit Produktdaten wird zeilenweise in Chunks geteilt. Ein Chunk enthält die Spaltenüberschriften, ein anderer die Datensätze. Ohne die Überschriften sind die Datensätze nicht interpretierbar.
Die Chunk-Größe ist kein universell optimierbarer Parameter. Was für FAQ-Dokumente funktioniert (kurze, in sich geschlossene Antworten), versagt bei wissenschaftlichen Texten mit langen Argumentationsketten. Ohne systematische Evaluation mit realen Suchanfragen bleibt die Wahl der Parameter spekulativ.
Fachliche Einordnung: Neuere Ansätze wie "late chunking" verarbeiten das gesamte Dokument zuerst durch das Transformer-Modell und teilen erst die resultierenden Token-Repräsentationen in Chunks auf. Dadurch fließt der Dokumentkontext in jeden Chunk-Vektor ein, ohne dass die Chunks selbst vergrößert werden. Das Verfahren erfordert allerdings, dass das Modell die gesamte Dokumentlänge verarbeiten kann, was bei sehr langen Texten an Speichergrenzen stößt.