Semantic Chunking
Semantic Chunking ist eine Technik zur Dokumentaufteilung, die Text an Bedeutungsgrenzen statt nach festen Zeichen- oder Token-Zahlen zerschneidet. Sie nutzt Embeddings, um zu erkennen, wann benachbarte Sätze das Thema wechseln, und setzt den Schnitt dort. So ist jeder entstehende Chunk in sich kohärent und als eine einzige Idee abrufbar.
Semantic Chunking ist eine Technik zur Dokumentaufteilung, die Text an Bedeutungsgrenzen statt nach festen Zeichen- oder Token-Zahlen zerschneidet. Sie nutzt Embeddings, um zu erkennen, wann benachbarte Sätze das Thema wechseln, und setzt den Schnitt dort. So ist jeder entstehende Chunk in sich kohärent und als eine einzige Idee abrufbar.
Warum es wichtig ist
Naives Chunking teilt alle N Tokens oder an Absatzgrenzen, unabhängig von der Bedeutung. Das zerschneidet regelmäßig ein einziges Argument mitten entzwei, platziert die Prämisse in einem Chunk und die Schlussfolgerung in einem anderen, sodass der Retriever Fragmente liefert, die keinen Sinn ergeben. Semantic Chunking behebt das, indem es Themenwechsel respektiert. Benchmark-Berichte von LlamaIndex und LangChain aus den Jahren 2024 bis 2025 zeigen, dass Semantic Chunking die Antwortqualität von RAG bei Open-Domain-QA gegenüber Aufteilungen mit fester Größe um 8 bis 20 % verbessert, mit den größten Zugewinnen bei langen technischen Dokumenten.
Wie es funktioniert
1. In Sätze aufteilen: Einen Satz-Tokenizer nutzen, um atomare Einheiten zu erhalten.
2. Jeden Satz einbetten: Ein kleines Embedding-Modell erzeugt einen Vektor pro Satz.
3. Benachbarte Ähnlichkeiten berechnen: Für jedes Satzpaar die Kosinusähnlichkeit zwischen den Embeddings messen.
4. Die Bruchstellen finden: Wenn die Ähnlichkeit unter einen Schwellenwert fällt (oder im untersten Perzentil liegt), als Themenwechsel markieren.
5. Sätze zwischen den Brüchen zu Chunks gruppieren: Jeder Chunk ist thematisch kohärent.
6. Optionale Größengrenzen: Winzige Chunks zusammenführen oder riesige aufteilen, damit der Abruf praktikabel bleibt.
Semantic vs Fixed-Size vs Recursive Chunking
| Strategie | Wie sie aufteilt | Kohärenz | Kosten | Wann verwenden |
|---|---|---|---|---|
| Fixed-Size | Alle N Tokens | Niedrig | Kostenlos | Prototyping, Logs |
| Recursive | Absatz -> Satz -> Wort | Mittel | Kostenlos | Allzweck-Standard |
| Semantic | Grenzen der Embedding-Ähnlichkeit | Hoch | Embedding-Kosten | Technische Dokumente, lange Artikel |
| Agentic | LLM entscheidet je Dokument | Am höchsten | Sehr hoch | Hoher Einsatz, geringes Volumen |
Semantic Chunking liegt zwischen dem billig-und-stumpfen und dem teuer-und-klugen Ende, ein guter Standard, sobald Sie der rekursiven Aufteilung entwachsen sind.
Stellschrauben
Ähnlichkeitsschwelle: Niedrige Schwelle -> mehr Chunks, engere thematische Kohärenz, schlechtere Kontextkontinuität. Hohe Schwelle -> weniger, längere Chunks. Beginnen Sie etwa beim 15. bis 25. Perzentil der benachbarten Ähnlichkeiten.
Embedding-Modell: Ein günstiges, kleines Embedding-Modell reicht meist aus, denn Sie messen relative Verschiebungen, nicht die absolute Bedeutung.
Minimale Chunk-Größe: Sehr kurze Chunks (ein Satz) werden schlecht abgerufen, weil ihnen der Kontext fehlt. Setzen Sie eine Untergrenze durch.
Maximale Chunk-Größe: Begrenzen Sie Chunks, sodass keiner das nachgelagerte Kontextfenster überschreitet.
Überlappung: Eine kleine Satzüberlappung (1 bis 2 Sätze) zwischen benachbarten Chunks rettet Grenzfälle, in denen die Grenze mehrdeutig ist.
Wann es nicht hilft
Kurze Dokumente: Wenn das gesamte Dokument in einen Chunk passt, ist jegliche Aufteilung Mehraufwand.
Stark repetitiver Text: Logs, Produktlisten und Tabellen haben wenig natürliche thematische Drift, Semantic Chunking entartet zu Fixed-Size.
Strukturierte Inhalte: Tabellen, Code und JSON sollten nach Struktur aufgeteilt werden, nicht nach Bedeutung.
Wenn der Abruf nicht der Engpass ist: Wenn Halluzination aus dem Prompt-Design oder dem Reranking stammt, hilft es nicht, das Chunking zu beheben.
Sources: