Lotook
Um Dokumente für RAG effektiv in Chunks aufzuteilen, zerlegen Sie Dateien zunächst anhand ihrer vorhandenen Struktur, begrenzen zu große Abschnitte anschließend nach Token-Länge mit Überlappung auf Satzebene und versehen jede Passage mit Quellenmetadaten. Die Wahl zwischen Token-, semantischem und strukturbasiertem Chunking hängt davon ab, ob Ihr Korpus aus gleichförmiger Prosa, wechselnden Themen oder formatierten Tabellen und Überschriften besteht.
Warum bestimmt RAG-Chunking die Qualität des Retrievals?
Retrieval-Augmented Generation (RAG) zerlegt Quelldokumente in kleinere Passagen, bevor diese eingebettet und in einem Suchindex gespeichert werden. Bei einer Anfrage ruft das System die relevantesten Chunks ab und übergibt sie zusammen mit der Frage an ein Sprachmodell. Das Chunking bestimmt die Retrieval-Einheit, da ein vollständiges Dokument meist zu umfangreich ist, um gut zu einer konkreten Frage zu passen, und neben anderen Kandidaten zu viel Platz im Kontextfenster des Modells einnimmt.
Als Patrick Lewis und Kollegen das Framework in ihrem NeurIPS-Paper von 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks) vorstellten, teilte ihr Experiment jeden Wikipedia-Artikel in nicht überlappende Chunks von etwa 100 Wörtern auf und erzeugte so rund 21 Millionen Passagen. Diese Aufteilung in 100-Wörter-Chunks war eine experimentelle Einstellung für Wikipedia aus dem Jahr 2020 und kein Produktionsstandard für 2026. Modernes RAG in Produktion läuft im November 2026 üblicherweise als modulare Engineering-Pipeline (in Chunks aufteilen, einbetten, indexieren, abrufen und generieren) statt als ursprüngliche durchgängig differenzierbare DPR-und-BART-Konfiguration.
Was sind die drei wichtigsten RAG-Chunking-Methoden?
RAG-Chunking-Methoden lassen sich in drei Familien einteilen: tokenbasierte, semantische und strukturbasierte Aufteilung. Jede Familie bestimmt anhand von Länge, Bedeutung oder Dokumentauszeichnung, wo eine Passage beginnt und endet.
| Chunking-Methode | Signal für die Aufteilung | Am besten geeignet für | Hauptrisiko | Indexierungskosten |
|---|---|---|---|---|
| Token-Chunking (oder längenbasiertes Chunking) | Festes Token- oder Zeichenfenster mit gleitender Überlappung | Gleichförmige Prosa, reiner Text oder eine Längenbegrenzung nach strukturbasierter Aufteilung | Teilt Sätze, Tabellenzeilen, Codeblöcke oder Definitionen | Niedrig |
| Semantisches Chunking | Abfall der Embedding-Ähnlichkeit zwischen benachbarten Sätzen | Unformatierte Prosa mit Themenwechseln innerhalb des Dokuments ohne Überschriften | Langsamere, teurere Indexierung; ungleichmäßige Chunk-Größen | Hoch |
| Strukturbasiertes Chunking | Überschriften, Absätze, Listen, Tabellen, Codeblöcke oder Seiten | Markdown, HTML, API-Dokumentation, Vertragsklauseln und strukturierte Handbücher | Schwache Struktur in gescannten PDFs; einzelne Abschnitte können sehr groß sein | Niedrig bis mittel |
1. Token- und Zeichen-Chunking
Token-Chunking teilt Text in Fenster fester Länge, gemessen in Tokens oder Zeichen, häufig mit gleitender Überlappung. Die Messung in Tokens entspricht der Arbeitsweise von Modellen: Embedding-Modelle und LLMs haben strikte Token-Grenzen, APIs werden nach Tokens abgerechnet, und derselbe Absatz kann je nach Modellfamilie unterschiedlich tokenisiert werden. Die Zeichenzahl ist nur ein grober Näherungswert.
Teams beginnen meist mit einer Fenstergröße innerhalb des Limits ihres Embedding-Modells (Tutorials starten oft bei einigen hundert Tokens) und passen sie nach der Untersuchung fehlgeschlagener Abrufe an. Das Hauptrisiko eines festen Fensters besteht darin, dass es Syntax und Layout ignoriert, einen Satz, eine Tabellenzeile, einen Codeblock oder eine Definition durchschneidet und dabei den Satzteil mit der Antwort auf die Frage auslässt.
2. Semantisches Chunking
Semantisches Chunking teilt Text bei einem Bedeutungswechsel auf, etwa wenn die Embedding-Ähnlichkeit benachbarter Sätze sinkt oder eine Diskursgrenze auftritt, statt bei einer starren Token-Zahl. Eine vollständige Aussage in einem Chunk zu halten, erleichtert das Retrieval, wenn Themen innerhalb eines Dokuments ohne Überschriften wechseln.
Die Indexierung mit semantischem Chunking ist jedoch langsamer und teurer, weil schon die Aufteilung Embedding-Aufrufe erfordern kann. Ein störanfälliger Ähnlichkeitsschwellenwert kann Text zudem zu stark oder zu wenig in ungleich große Chunks aufteilen; Satzähnlichkeit ist bei Tabellen, Formularen oder Code nicht automatisch besser.
3. Strukturbasiertes Chunking
Strukturbasiertes Chunking nutzt die vorhandene Dokumentstruktur für die erste Aufteilung: Markdown- oder HTML-Überschriften, Absätze, Listen, Abschnitte, Seiten, abgegrenzte Codeblöcke oder Tabellengrenzen. Wie die AWS Prescriptive Guidance zu RAG festhält, bleibt logisch zusammengehöriger Kontext durch den Erhalt der Dokumentstruktur intakt. Ein Chunk, der an einer Überschrift zu Rückerstattungsrichtlinien beginnt und den gesamten Abschnitt enthält, lässt sich leichter abrufen und zitieren als ein mitten im Satz beginnendes Fenster.
Da viele PDFs und Scans keine klaren Überschriften haben (und eine einzelne Überschrift dennoch 20 Seiten umfassen kann), kombinieren Produktionspipelines üblicherweise Methoden:
- Zuerst hierarchisch nach Struktur aufteilen: Teilen Sie das Dokument nach Abschnitt oder Überschrift und danach nach Absatz oder Block auf; halten Sie Codeblöcke, Tabellen und Listen zusammen.
- Danach die Token-Länge begrenzen: Wenn ein Abschnitt zu groß bleibt, teilen Sie ihn mit einem Token-Fenster auf.
- Ersatzaufteilungen für unstrukturierten Text verwenden: Greifen Sie bei gescannten PDFs oder langen unstrukturierten Abschnitten auf Seitenaufteilungen, Token-Fenster oder semantische Grenzen zurück.
Wie konfigurieren Sie Chunk-Überlappung und RAG-Metadaten?
Chunk-Überlappung und Passagenmetadaten verhindern den Verlust von Satzteilen an Grenzen und verbinden abgerufene Textstellen mit ihren Quelldokumenten.
Chunk-Überlappung konfigurieren
Die Chunk-Überlappung wiederholt das Ende eines Chunks am Anfang des nächsten, damit ein Satz oder eine Definition an einer Grenze in mindestens einer abgerufenen Passage vollständig erscheint. Sie dient als einfache Absicherung, wenn feste Fenster oder Ersatzaufteilungen einen Gedanken durchschneiden.
Wählen Sie die Überlappung so, dass sie ein oder zwei typische Sätze Ihres Korpus abdeckt, aber klein genug bleibt, um nicht fast denselben Chunk doppelt zu speichern. Überlappung erhöht die Anzahl der Tokens, die eingebettet, gespeichert und abgerufen werden, vergrößert den Index und fügt den Ergebnissen nahezu doppelte Nachbarn hinzu. Wenn das Retrieval häufig nahezu identische Chunks liefert, reduzieren Sie die Überlappung oder Chunk-Größe oder ergänzen Sie eine Deduplizierung nach dem Abruf.
RAG-Metadaten hinzufügen
RAG-Metadaten bestehen aus strukturierten Feldern, die neben jedem Chunk gespeichert werden, darunter:
- Quelldokument-ID oder URL und Titel
- Abschnitts- oder Überschriftenpfad und Seitenzahl
- Erstellungs- oder Aktualisierungsdatum und Dokumenttyp (Richtlinie, Ticket, API-Referenz)
- Zugriffs- und Berechtigungskennzeichnungen, Sprache und eine stabile Chunk-ID
Teams können Metadaten aus dem Embedding heraushalten, wenn rohe IDs oder Zeitstempel die Ähnlichkeit verfälschen würden, oder ausgewählte Felder (etwa einen Abschnittstitel) dem eingebetteten Text voranstellen, wenn sie das Retrieval verbessern. Metadaten unterstützen drei Anforderungen im Produktionsbetrieb:
- Zitate: Ihre Benutzeroberfläche oder Ihr Modell kann eine Datei, Überschrift und Seitenzahl statt einer bloßen Passage zitieren.
- Berechtigungs- und Versionsfilter: Rufen Sie nur die neueste Version einer Richtlinie, ein bestimmtes Produkt oder Dokumente ab, die der Nutzer sehen darf. Berechtigungen gehören in Indexfilter und nicht nur in den Prompt, da private Dokumente in einem ungefilterten RAG-Index für jeden zugänglich sind, der das System abfragen kann.
- Fehlersuche und Aktualisierungen: Wenn sich ein Quelldokument ändert, teilen Sie es erneut in Chunks auf, betten es erneut ein und nehmen alte Chunk-IDs außer Betrieb, damit veraltete Fakten keine Sachfehler verursachen.
Woran erkennen Sie, dass Ihre Chunks zu groß oder zu klein sind?
Die Prüfung abgerufener Chunks anhand echter Nutzerfragen zeigt, ob Ihre Passagen zu groß oder fragmentiert sind.
Anzeichen für zu große Chunks
- Versteckte Antworten: Das Retrieval liefert einen langen Abschnitt, der den Suchbegriff erwähnt, aber die eigentliche Antwort verbirgt, sodass das Modell suchen muss oder sie übersieht.
- Überfüllte Prompts: Nur wenige Chunks passen in den Prompt, sodass ein mittelmäßiger Treffer bessere verdrängt.
- Höhere Kosten und Latenz: Viele irrelevante Tokens zu senden erhöht Ausgaben und Antwortzeit.
- Stärkere Ablenkung: Zusätzliches Rauschen verstärkt Context Rot: Das Modell hat den richtigen Fakt in einem großen Prompt, stützt sich aber auf Trainingswissen oder einen benachbarten falschen Satz.
Anzeichen für zu kleine Chunks
- Unvollständige Fragmente: Ein abgerufener Chunk ist ohne den vorigen Satz nicht verständlich (etwa ein Satz über eine Ausnahme für Enterprise-Tarife, der die Regel nicht nennt).
- Getrennte mehrteilige Antworten: Eine Definition und ihre Ausnahme, eine Funktion und ihre Parameter oder eine Richtlinie und ihr Gültigkeitsdatum landen in getrennten Chunks, und top-k liefert nur einen Teil.
- Nahezu identische Fragmente: Sie rufen viele sich wiederholende Textstellen ab und erhalten dennoch keinen vollständigen Gedanken; zugleich werden Zitate unübersichtlich, weil jeder Satz eine eigene Quelle ist.
Um Größen praktisch abzustimmen, prüfen Sie echte Fragen und die abgerufenen Chunks und fragen Sie sich, ob ein Mensch allein anhand dieser Passagen antworten könnte. Liegt der benötigte Satz in einem nicht abgerufenen benachbarten Chunk, passen Sie Überlappung, Strukturregeln oder Größe an. Liegt er im abgerufenen Chunk, umgeben von sachfremdem Text, teilen Sie kleiner auf oder rufen Sie weniger, präzisere Chunks ab.
Wie beeinflusst RAG-Chunking Context Rot?
RAG-Chunking wirkt direkt gegen Context Rot, den Rückgang von Schlussfolgerungsqualität, Befolgung von Anweisungen und Erinnerungsvermögen eines Modells, wenn ein Prompt länger oder unübersichtlicher wird, selbst weit unter dem angegebenen Kontextlimit.
RAG dient dazu, nicht den gesamten Korpus in den Prompt zu laden. Werden jedoch zu große Chunks abgerufen oder wird top-k sicherheitshalber erhöht und der Prompt mit vielen nur vage ähnlichen Chunks gefüllt, entsteht erneut ein langer, verrauschter Kontext. Mehr Kontext ist nicht automatisch genauer. Fokussierte Chunks verringern die Unübersichtlichkeit des Prompts, doch gutes Chunking allein kann weder ein schlechtes Embedding-Modell reparieren noch KI-Halluzinationen beseitigen, wenn ein Modell abgerufenen Text ignoriert.
FAQ
Sollte ich die Größe von RAG-Chunks in Tokens oder Zeichen messen?
Messen Sie die Größe von RAG-Chunks nach Möglichkeit in Tokens. Embedding- und Sprachmodelle setzen Kontextlimits in Tokens durch, und die API-Nutzung wird pro Token abgerechnet. Zeichenzahlen sind nur ein grober Näherungswert, da derselbe Absatz je nach Sprache, Codeblock und Modellfamilie in unterschiedlich viele Tokens zerlegt werden kann. Der Tokenizer Ihres Embedding-Modells verhindert unerwartetes Abschneiden bei der Indexierung.
Ist semantisches Chunking immer besser als Token-Chunking?
Semantisches Chunking ist nicht automatisch besser als Token- oder strukturbasiertes Chunking. Eine Aufteilung bei sinkender Satzähnlichkeit hält Aussagen in unstrukturierter Prosa zusammen, erfordert aber zusätzliche Embedding-Arbeit bei der Indexierung, erzeugt ungleich große Chunks und kann bei einem störanfälligen Schwellenwert zu stark oder zu wenig aufteilen. Bei formatierten Dokumenten ist die Aufteilung entlang von Überschriften, Tabellen und Codeblöcken schneller und folgt den vom Autor vorgesehenen Grenzen.
Wie sollte ich Tabellen und Codeblöcke für RAG aufteilen?
Tabellen, Rechnungen, Vertragsklauseln und Code benötigen strukturbasierte Regeln, die Blöcke zusammenhalten. Eine naive Zeichen- oder Token-Aufteilung durch eine Markdown-Tabelle oder einen Funktionskörper erzeugt unbrauchbare Chunks, die Werte von Spaltenüberschriften trennen oder die Syntax zerstören. Halten Sie Codeblöcke, Tabellen und Listen nach Möglichkeit zusammen und wenden Sie strukturbasierte Ersatzverfahren nur an, wenn ein einzelner Block die Modelllimits überschreitet.
Sollten Metadaten im Chunk-Embedding enthalten sein?
Ob Metadaten im eingebetteten Text stehen, ist eine vom Feld abhängige Designentscheidung. Ein dem Chunk-Text vorangestellter Dokumenttitel oder Überschriftenpfad verbessert das Retrieval oft, wenn Absätze für ihren Kontext auf die Überschrift angewiesen sind. Rohe Kennungen, Zeitstempel und Zugriffskennzeichnungen sollten in getrennten filterbaren Metadatenfeldern bleiben, damit sie die Embedding-Ähnlichkeit nicht verfälschen.
Was passiert, wenn sich ein Quelldokument ändert?
Wenn sich ein Quelldokument ändert, muss Ihre Ingestion-Pipeline das Dokument erneut in Chunks aufteilen und einbetten sowie die alten Chunk-IDs aus dem Index entfernen. Bleiben veraltete Chunks neben aktualisierten aktiv, liefert der Retriever überholte Richtlinien oder widersprüchliche Passagen und verwandelt ein Versäumnis bei der Indexpflege in einen Sachfehler in der endgültigen Antwort.
