Chunking-Strategien im RAG: Textsegmentierung für bessere Vektorsuche

Beim Aufbau eines Retrieval-Augmented-Generation-Systems (RAG) ist das Chunking einer der kritischsten und zugleich am häufigsten unterschätzten Schritte. Unter Chunking versteht man das Aufteilen von langen Dokumenten (z. B. 50-seitigen PDFs oder Handbüchern) in kleinere, zusammenhängende Textabschnitte (die sogenannten Chunks), bevor diese mit Embeddings vektorisiert und in die Vektordatenbank geladen werden. Die gewählte Chunk-Grösse hängt direkt mit dem Token-Budget und dem Kontextfenster des Modells zusammen.

Warum ist Chunking notwendig?

Embedding-Modelle und Sprachmodelle stossen bei der Verarbeitung sehr langer Texte auf zwei Probleme:

1. Semantische Verwässerung (Semantic Dilution): Ein Embedding-Vektor repräsentiert die durchschnittliche Bedeutung eines Textes. Vektorisieren Sie ein ganzes Buch als einen einzigen Punkt im Raum, gehen alle spezifischen Details verloren. Das Modell findet das Buch bei Detailfragen nicht mehr.
2. Kontextfenster-Limits: Sprachmodelle können nur eine begrenzte Anzahl an Tokens gleichzeitig verarbeiten. Übergibt das Retrieval-System zu grosse Textabschnitte, wird das Limit des LLMs überschritten.
3. Kosten und Geschwindigkeit: Je grösser der übergebene Kontext ist, desto langsamer antwortet das Modell (Latenz) und desto höher sind die API-Kosten.

---

Die wichtigsten Chunking-Strategien

Die Wahl der richtigen Aufteilungsmethode hängt stark von der Struktur der Quelldokumente ab.

1. Fixed-Size Chunking (Statisches Chunking)

Dies ist die einfachste Methode. Der Text wird starr nach einer festgelegten Anzahl von Zeichen oder Tokens getrennt (z. B. alle 500 Zeichen).

• Vorteil: Sehr einfach zu implementieren.
• Nachteil: Es nimmt keine Rücksicht auf die Grammatik. Sätze oder logische Absätze werden mitten im Wort oder Gedanken zerschnitten, was die Qualität der Vektorsuche verschlechtert.

2. Sentence- & Paragraph-based Chunking

Hierbei dienen Satzzeichen (Punkte, Fragezeichen) oder Zeilenumbrüche (\n\n) als natürliche Trenner. Ein Chunk wird erst dann beendet, wenn das konfigurierte Token-Limit fast erreicht ist und ein Absatz oder Satz schliesst.

• Vorteil: Erhält die logische Struktur des Textes.

3. Sliding Window (Überlappendes Chunking)

Um den Kontextverlust an den Schnittstellen zu verhindern, wird ein Overlap (Überlappung) definiert.

• Beispiel: Ein Chunk hat eine Grösse von 500 Zeichen und einen Overlap von 100 Zeichen. Chunk 1 enthält die Zeichen 0 bis 500. Chunk 2 startet bei Zeichen 400 und reicht bis 900.
• Vorteil: Stellt sicher, dass Sätze, die am Rand eines Chunks liegen, im nächsten Chunk vollständig erfasst werden.

4. Semantisches Chunking (Semantic Chunking)

Ein moderner, intelligenter Ansatz. Der Text wird Satz für Satz eingelesen. Das System berechnet die Embeddings für benachbarte Sätze und misst deren semantischen Abstand. Steigt der Abstand zwischen Satz A und Satz B über einen bestimmten Schwellenwert (was auf einen Themenwechsel hindeutet), wird an dieser Stelle dynamisch ein neuer Chunk erzeugt.

• Vorteil: Erzeugt Chunks mit maximaler inhaltlicher Reinheit.

5. Dokumentenspezifisches Chunking (Markdown/HTML)

Nutzt die Strukturierungselemente des Dokuments (z. B. # H1, ## H2). Hierbei wird definiert, dass jede Überschrift einen neuen Chunk einleitet. Dies ist besonders effektiv für technische Dokumentationen oder FAQs.

Vom Dokument zum überlappenden Chunk

Das folgende Diagramm zeigt den Weg eines Dokuments durch die Ingestion-Pipeline – inklusive des Overlaps, der zusammenhängende Sätze über Chunk-Grenzen hinweg erhält:

graph LR
    Doc["Langes Dokument"] --> Split["Aufteilen an<br/>semantischen Grenzen"]
    Split --> C1["Chunk 1<br/>Zeichen 0–500"]
    Split --> C2["Chunk 2<br/>Zeichen 400–900<br/>(100 Overlap)"]
    Split --> C3["Chunk 3<br/>Zeichen 800–1300"]
    C1 --> Emb["Embedding → Vektor-DB"]
    C2 --> Emb
    C3 --> Emb

Chunk-Grösse: zu klein vs. zu gross

Die Chunk-Grösse ist der wichtigste Stellhebel für die Retrieval-Qualität. Sowohl zu kleine als auch zu grosse Chunks verschlechtern das Ergebnis:

Chunk-Grösse	Risiko	Auswirkung auf das Retrieval
Zu klein (< 100 Token)	Kontextverlust	Treffer ohne erklärenden Zusammenhang
Optimal (300–500 Token, 10–20 % Overlap)	–	Hohe Relevanz, vollständiger Kontext
Zu gross (> 1000 Token)	Verwässerung	Vektor mischt mehrere Themen, schlechtere Trefferschärfe

Faustregel: An semantischen Grenzen (Absätze, Überschriften) trennen und einen Overlap von 10–20 Prozent setzen, damit Sätze nicht hart abgeschnitten werden. Sauberes Chunking ist Teil der Ingestion-Phase und Voraussetzung für gute Vektorsuche.

[!TIP] Die optimale Chunk-Grösse entscheidet darüber, ob eine Firmen-KI präzise Antworten liefert oder an den Fakten vorbeiredet. Sehen Sie in der RAG-Demo auf allerate.dev, wie sauber segmentierte Dokumente die Antwortqualität beeinflussen.