Deine Suche liefert den Satz „Der Link ist 30 Minuten lang gültig“ – aber im gefundenen Ausschnitt fehlt jeder Hinweis darauf, um welchen Link es überhaupt geht. Im Originaldokument stand zwei Sätze weiter oben die Überschrift „Passwort zurücksetzen“. Wie zerlegst du lange Dokumente so, dass jeder Treffer für sich allein verständlich bleibt?
Beim Chunking teilst du längere Dokumente vor dem Einbetten in kleinere, thematisch geschlossene Textabschnitte auf. Schneidest du zu grob, verschwimmen verschiedene Themen in einem einzigen Durchschnittsvektor; schneidest du blind nach Zeichenzahl, trennst du Überschriften, Voraussetzungen und Warnhinweise von der eigentlichen Anleitung. Statt nach einer magischen Standardgröße zu suchen, orientierst du die Schnittkanten an der Dokumentstruktur, gibst jedem Abschnitt seinen Überschriften-Kontext mit und misst die Länge direkt mit dem Tokenizer deines Modells.
Ein guter Chunk ist fokussiert genug für einen präzisen Vektortreffer und vollständig genug, um ohne den Rest des Dokuments keine falschen Schlüsse zuzulassen.
Was darf beim Schneiden niemals getrennt werden?
Jeder Chunk ist ein potenzielles Belegstück für den Leser oder ein nachgelagertes Sprachmodell. Fehlt im Textausschnitt die entscheidende Vorbedingung, entsteht selbst aus einem korrekten Dokument eine gefährliche Halbwahrheit:
- Aussage und Bedingung zusammenhalten: In unserem deutschen Support-Datensatz enthält die MFA-Anleitung den wichtigen Hinweis: „Ein neues Passwort ersetzt den zweiten Faktor nicht.“ Wird dieser Satz beim Chunking abgetrennt, leitet der verbleibende Rest den Nutzer in die Irre.
- Hierarchischen Kontext vererben: Ein Absatz, der nur mit „Gehe dazu in die Einstellungen…“ beginnt, ist ohne seine Kapitelüberschrift wertlos. Stelle dem Chunk beim Einbetten den Dokumenttitel und den aktuellen Überschriftenpfad (z. B.
Konto > Sicherheit > Zweiten Faktor verloren) voran. - Metadaten am Chunk verankern: Speichere neben dem eingebetteten Text immer die
document_id, die Abschnittsposition, die Produktversion (version) und den unveränderten Originaltext für die spätere Quellenanzeige.
Welche Chunking-Strategie passt zu welchem Inhalt?
| Strategie | Wie wird getrennt? | Wann ist das der beste Startpunkt? | Wo liegt die typische Schwäche? |
|---|---|---|---|
| Feste Länge (Fixed-Size) | Hart nach einer bestimmten Token- oder Wortanzahl | Schnelle Baseline für unstrukturierte Fließtexte ohne Formatierung | Zerreißt Sätze, Tabellen und zusammengehörige Bedingungen mitten im Gedanken |
| Strukturorientiert | Entlang von Markdown-Headings (##, ###), HTML-Tags oder Absätzen | Technische Dokumentation, Handbücher, Support-Artikel und Wikis | Sehr lange Unterkapitel überschreiten das Token-Limit und müssen weiter geteilt werden |
| Rekursiv | Erst nach großen Strukturblöcken (Kapitel), bei Überlänge schrittweise nach Absatz und Satz | Gemischte Dokumentbestände mit unterschiedlich langen Abschnitten | Die Qualität hängt stark von einer sauberen Hierarchie der Trennzeichen ab |
| Semantisch | Schneidet dort, wo die Embedding-Ähnlichkeit aufeinanderfolgender Sätze stark abfällt | Lange Transkripte oder Texte ohne verlässliche Zwischenüberschriften | Höherer Rechenaufwand beim Indexieren und zusätzliche Schwellenwert-Parameter |
In der Praxis ist eine kombiniert strukturorientiert-rekursive Strategie für technische Dokumentation fast immer der robusteste Ausgangspunkt: Du respektierst vorhandene Überschriften und teilst nur jene Abschnitte weiter auf, die für das Modell zu lang sind. Die Weaviate-Dokumentation zu Chunking zeigt anschaulich, wie sich diese Ansätze auf Retrieval-Präzision und Kontextumfang auswirken.
Jedes Embedding-Modell besitzt ein hartes Eingabelimit (z. B. 512 Tokens bei multilingual-e5-base). Da die (Zerlegung eines Textes in die internen Wort- und Teilwort-Einheiten eines Sprachmodells; deutsche Komposita und Code erzeugen oft deutlich mehr Tokens als englischer Fließtext gleicher Zeichenlänge.) je nach Modell variiert und vorangestellte Überschriften oder Query-Präfixe mitzählen, schneiden viele Modelle überlange Chunks ab Token 513 kommentarlos ab. Prüfe die Länge daher immer mit dem echten Tokenizer des Modells.
Wann hilft Überlappung (Overlap) – und wann schadet sie?
Mit einem (Überlappender Textbereich (z. B. 10–15 % der Tokens), der sowohl am Ende von Chunk A als auch am Anfang von Chunk B gespeichert wird, um harte Schnitte abzufedern.) verhinderst du, dass ein Gedanke genau an einer künstlichen Längengrenze verloren geht. Das ist vor allem dann sinnvoll, wenn du einen langen Fließtext ohne Zwischenüberschriften rekursiv aufteilen musst.
Überlappung ist jedoch kein Heilmittel für unsaubere Dokumentgrenzen:
- Keine Überlappung über Kapitelgrenzen hinweg: Wenn Kapitel A die „Kündigung des Tarifs“ und Kapitel B das „Endgültige Löschen des Kontos“ behandelt, darf ein Overlap beide Themen niemals in einen gemeinsamen Chunk mischen.
- Duplikate im Retrieval beachten: Stark überlappende Chunks ähneln sich auch im Vektorraum. Ohne Deduplizierung auf Dokumentebene belegen sonst drei fast identische Ausschnitte desselben Artikels deine Top-k-Ergebnisliste.
Vergleiche im Zweifel immer einen Lauf ohne Overlap gegen einen Lauf mit moderatem Overlap (z. B. 10–15 % innerhalb desselben Kapitels) auf deinen echten Suchfragen.
Tabellen, Codeblöcke und mehrstufiger Kontext
Klassisches Text-Splitting scheitert zuverlässig an zwei Stellen: Tabellen und Quellcode. Eine einzelne Tabellenzeile wie | Pro | 49 € | 100 GB | ist ohne die Kopfzeile der Tabelle unbrauchbar, und ein mitten in der if-Bedingung zerschnittener Codeblock hilft keinem Entwickler.
- Wiederhole bei aufgeteilten Tabellen in jedem Chunk die Spaltenüberschriften und relevante Einheiten.
- Halte Codeblöcke samt Funktionssignatur und unmittelbarer Erklärung zusammen.
- Nutze bei langen Texten Small-to-Big Retrieval: Suche präzise auf kleinen Absätzen, lade für die Antwort aber den übergeordneten Abschnitt (unter Beachtung derselben Zugriffsrechte) nach.
- Markdown-Tabellen oder JSON-Blöcke mitten in der Zeile nach 500 Zeichen hart abschneiden.
- Absätze ohne ihren Kapitel- und Dokumenttitel einbetten.
- Beim Nachladen größerer Nachbarabschnitte die Berechtigungs- oder Versionsgrenzen des Dokuments ignorieren.
Checkliste vor der Indexierung
- Jeder Chunk trägt seinen Dokumenttitel und Überschriftenpfad sichtbar im eingebetteten Text oder als strukturiertes Kontextfeld.
- Kein Chunk überschreitet inklusive Präfixen und Überschriften das maximale Token-Limit des verwendeten Embedding-Modells.
- Tabellen behalten ihre Kopfzeilen, Codeblöcke bleiben syntaktisch zusammenhängend und Warnhinweise kleben an ihrer Handlungsanweisung.
- Bei der Auswertung und Anzeige werden mehrere Chunks derselben Quelle sauber über ihre
document_idzusammengeführt.
Quellen und nächste Schritte
- Weaviate: Starter Guide – Chunking für RAG – Auswirkungen von Chunk-Größe und Struktur auf Suche und Generierung.
- Pinecone: Chunking Strategies for LLM Applications – Vergleich von Fixed-Size-, rekursivem und strukturorientiertem Splitting.
- intfloat/multilingual-e5-base (Hugging Face) – Praxisbeispiel für ein festes 512-Token-Kontextfenster.
Wie deine fertig geschnittenen Chunks über Vektoren durchsuchbar werden, erfährst du in Semantische Suche. Wie daraus schließlich ein sauber abgegrenzter Prompt-Kontext mit überprüfbaren Quellen wird, zeigt die Kachel RAG.