Was ist die beste Chunk-Größe für RAG?

Es gibt keine universelle Antwort, aber ein guter Ausgangspunkt sind 400 bis 512 Tokens mit 10 bis 20 % Überlappung. Passen Sie die Größe dann an Ihren Abfragetyp an: 128 bis 256 Tokens für die präzise Faktensuche und 512 bis 1024 Tokens für analytische Abfragen oder Zusammenfassungen. Testen Sie lieber einige Größen mit Ihren eigenen Fragen, als einem einzigen Standardwert zu vertrauen.

Ist semantisches Chunking besser als Chunking mit fester Größe?

Nicht zuverlässig. Semantisches Chunking gruppiert Sätze nach Thema, was besser klingt, aber Benchmarks zeigen, dass seine Vorteile gegenüber rekursivem oder festem Chunking inkonsistent sind und den zusätzlichen Embedding-Rechenaufwand oft nicht rechtfertigen. Festes und rekursives Chunking bleiben starke, kostengünstige Baselines — beginnen Sie dort und wechseln Sie nur zum semantischen Chunking, wenn Ihre Auswertung einen echten Gewinn zeigt.

Was ist Late Chunking und wann sollte ich es einsetzen?

Late Chunking bettet zunächst das gesamte Dokument mit einem Long-Context-Embedding-Modell ein und fasst dann die Token-Embeddings zu Chunks zusammen — sodass der Vektor jedes Chunks Kontext aus dem gesamten Dokument trägt, nicht nur aus seinem eigenen Text. Verwenden Sie es für lange Dokumente mit weitreichenden Abhängigkeiten, bei denen ein Abschnitt nur mit vorherigem Kontext Sinn ergibt.

Verbessert kontextuelles Retrieval die Genauigkeit wirklich?

Ja, messbar. Anthropic berichtete, dass das Voranstellen einer LLM-generierten Kontextnotiz vor jeden Chunk die Top-20-Retrieval-Fehler um 35 % mit kontextuellen Embeddings, um 49 % kombiniert mit kontextuellem BM25 und um 67 % mit zusätzlichem Reranking reduzierte — bei etwa 1,02 $ pro Million Dokument-Tokens mit Prompt-Caching. Am meisten lohnt es sich für hochwertige Korpora, bei denen ein verpasster Abschnitt teuer ist.

Was ist Parent-Document-Retrieval (von klein nach groß)?

Es entkoppelt, wie Sie abgleichen, von dem, was Sie zurückgeben. Sie indexieren kleine Kind-Chunks für präzises Matching, aber wenn einer übereinstimmt, übergeben Sie dem Modell den größeren Eltern-Abschnitt, damit es den umgebenden Kontext hat. Das gibt Ihnen den Recall kleiner Chunks und die Kohärenz großer Chunks, ohne bei einem von beiden Abstriche zu machen.

Mit welcher Chunking-Strategie sollte ich beginnen?

Mit rekursivem Chunking bei etwa 500 Tokens und 15 % Überlappung. Es respektiert natürliche Grenzen, ist kostengünstig und eine starke Baseline für die meisten Inhalte. Ergänzen Sie strukturbasiertes Splitting für PDFs und Handbücher, Parent-Document-Retrieval, wenn Antworten mehr Kontext benötigen, und kontextuelles Retrieval nur dort, wo der Mehrwert die Extrakosten rechtfertigt.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Chunking-Strategien für RAG: Größen, Überlappung und was funktioniert

Chunking setzt die Qualitätsobergrenze für RAG, noch bevor das Retrieval überhaupt läuft. Dieser Leitfaden vergleicht die sechs Strategien, die die Praxis dominieren, liefert konkrete Zahlen zu Größe und Überlappung und erklärt, welche Strategie zu welchem Abfragetyp passt.

Warum Chunking die RAG-Qualität bestimmt

Der Chunk ist die Einheit, die Ihr Retriever tatsächlich abruft — Chunk-Grenzen setzen daher die Obergrenze für alles Nachgelagerte. Zu kleine Chunks führen dazu, dass jedem Embedding ausreichend Signal fehlt, um zuverlässig gefunden zu werden; zu große Chunks mitteln das Signal des relevanten Abschnitts heraus und verdünnen den Vektor so weit, dass er nicht mehr zur Abfrage passt. Schlechtes Chunking lässt sich durch keinen Reranker und kein größeres Modell retten — der richtige Abschnitt wurde schlicht nie abgerufen. Deshalb ist Chunking, nicht die Modellwahl, üblicherweise das Erste, was man optimieren sollte.

Die sechs Strategien, die die Praxis dominieren

Die aktuelle Praxis lässt sich in sechs Ansätze einteilen:

Feste Größe: gleich große Token- oder Zeichen-Spannen mit Überlappung. Am ältesten, günstigsten und reproduzierbarsten — und eine überraschend starke Baseline.
Rekursiv: Aufteilung nach einer Prioritätshierarchie von Trennzeichen (Absatz → Zeile → Satz), um unter einem Größenlimit zu bleiben und dabei natürliche Grenzen zu respektieren. Die empfohlene Standardoption.
Semantisch: Sätze werden nach Embedding-Ähnlichkeit gruppiert, sodass jeder Chunk genau ein Thema umfasst. Die Gewinne gegenüber dem rekursiven Ansatz sind inkonsistent und erfordern zusätzlichen Embedding-Rechenaufwand.
Strukturbasiert: Aufteilung anhand der Dokumentstruktur (Überschriften, Abschnitte, Seiten, Markdown). Am besten für PDFs, Handbücher und Finanzdokumente.
Late Chunking: Das gesamte Dokument wird zuerst mit einem Long-Context-Modell eingebettet, dann werden die Token-Embeddings zu Chunks zusammengefasst — sodass jeder Chunk globalen Kontext trägt.
Kontextuelles Retrieval: Jedem Chunk wird vor der Indexierung eine LLM-generierte Kontextnotiz vorangestellt.

Beginnen Sie mit dem rekursiven Ansatz; greifen Sie zu den anderen, wenn Ihre Dokumente oder Abfragetypen es erfordern.

Chunk-Größe und Überlappung: konkrete Zahlen

Es gibt keine universell optimale Größe, aber gute Ausgangspunkte. Starten Sie mit etwa 400–512 Tokens und 10–20 % Überlappung (ungefähr 50–100 Tokens bei einem 500-Token-Chunk). Passen Sie die Größe dann an den Abfragetyp an: Kleine Chunks (128–256 Tokens) eignen sich für die präzise Fakten- und Keyword-Suche, größere Chunks (512–1024 Tokens) für analytische Abfragen und Zusammenfassungen, bei denen der narrative Fluss zählt.

Überlappung verhindert, dass Bedeutung an einer Grenze abgeschnitten wird — zu wenig zerstückelt den Kontext, zu viel bläht den Index auf und erzeugt Duplikate beim Retrieval. NVIDIAs Benchmark ergab, dass rund 15 % Überlappung bei Finanzdokumenten optimal ist und dass seitenweises Chunking die höchste und konsistenteste Genauigkeit über gemischte Korpora hinweg erzielte — wobei Faktenabfragen bei 256–512 Tokens ihren Höchstwert erreichten und analytische Abfragen bei 1024+.

Fortgeschritten: kontextuelles Retrieval und Late Chunking

Zwei neuere Techniken gehen dasselbe Problem an — ein Chunk, der "Umsatz stieg um 15 %" besagt, ist nutzlos, wenn unklar ist, um welches Unternehmen oder Quartal es geht.

Anthropics kontextuelles Retrieval stellt jedem Chunk eine 50–100 Tokens umfassende, LLM-generierte Kontextnotiz voran — sowohl vor dem Embedding als auch vor der BM25-Indexierung. Gemessen an einer Baseline-Fehlerrate von 5,7 % im Top-20 reduzierten kontextuelle Embeddings die Fehler um 35 %, das Hinzufügen von kontextuellem BM25 um 49 % und das Hinzufügen von Reranking um 67 % — bei etwa 1,02 $ pro Million Dokument-Tokens mit Prompt-Caching.

Jinas Late Chunking kehrt die Pipeline um: Das gesamte Dokument wird mit einem Long-Context-Modell eingebettet (bis zu ~8192 Tokens), dann werden die kontextualisierten Token-Embeddings zu Chunks zusammengefasst — sodass jedes Chunk-Embedding bereits chunk-übergreifenden Kontext trägt. Verwenden Sie es für lange Dokumente mit weitreichenden Abhängigkeiten.

Parent-Document-Retrieval und Metadaten

Zwei Verfeinerungen zahlen sich fast überall aus. Das Parent-Document-Retrieval ("von klein nach groß") entkoppelt die Retrieval-Granularität von der Generierung: Indexieren Sie kleine Kind-Chunks (≈100–500 Tokens) für präzises Matching, geben Sie dem Modell aber den größeren Eltern-Abschnitt (≈500–2000 Tokens) zurück, damit es den umgebenden Kontext hat. Und die Anreicherung mit Metadaten — das Anhängen von Quelle, Abschnittsüberschrift, Seitenzahl und Zeitstempeln an jeden Chunk — verbessert das Filtern, ermöglicht Zitate und erhöht die Retrieval-Präzision unabhängig von der Chunk-Größe.

Auswahl und Feinabstimmung in osFoundry

Ein schneller Entscheidungsleitfaden: Rekursiv ist die sichere Standardoption; strukturbasiert oder seitenweise für strukturierte Dokumente; semantisch für thematisch dichte Prosa; Late Chunking für lange Dokumente mit einem Long-Context-Embedder; kontextuelles Retrieval für hochwertige Korpora, bei denen Kontextverlust teuer ist; Parent-Document, wenn Sie sowohl Präzision als auch Kontext benötigen.

osFoundry behandelt all dies als Konfiguration, nicht als Code. Auto-Chunking liefert einen sinnvollen rekursiven Standard, und die anpassbare RAG-Pipeline lässt Sie Größe, Überlappung und Strategie pro Wissensbasis einstellen — mit Reranking und Parent-Document-Retrieval als Schalter einzelner Pipeline-Stufen. Da die Stufen konfigurierbar sind, können Sie Chunking-Einstellungen per A/B-Test gegen Ihre eigene Abfrageverteilung — faktisch versus analytisch — prüfen und den Rest des Stacks unverändert lassen. Genau das ist der parametergesteuerte Optimierungsworkflow, den die Forschung empfiehlt.

Frequently asked questions

Was ist die beste Chunk-Größe für RAG?: Es gibt keine universelle Antwort, aber ein guter Ausgangspunkt sind 400 bis 512 Tokens mit 10 bis 20 % Überlappung. Passen Sie die Größe dann an Ihren Abfragetyp an: 128 bis 256 Tokens für die präzise Faktensuche und 512 bis 1024 Tokens für analytische Abfragen oder Zusammenfassungen. Testen Sie lieber einige Größen mit Ihren eigenen Fragen, als einem einzigen Standardwert zu vertrauen.
Wie viel Überlappung sollten Chunks haben?: Zehn bis zwanzig Prozent der Chunk-Größe — ungefähr 50 bis 100 Tokens bei einem 500-Token-Chunk. Überlappung verhindert, dass Bedeutung an einer Grenze abgeschnitten wird; zu wenig zerstückelt den Kontext an der Trennstelle, und zu viel bläht den Index auf und erzeugt nahezu doppelte Abrufe. NVIDIA fand heraus, dass etwa 15 % bei Finanzdokumenten optimal sind.
Ist semantisches Chunking besser als Chunking mit fester Größe?: Nicht zuverlässig. Semantisches Chunking gruppiert Sätze nach Thema, was besser klingt, aber Benchmarks zeigen, dass seine Vorteile gegenüber rekursivem oder festem Chunking inkonsistent sind und den zusätzlichen Embedding-Rechenaufwand oft nicht rechtfertigen. Festes und rekursives Chunking bleiben starke, kostengünstige Baselines — beginnen Sie dort und wechseln Sie nur zum semantischen Chunking, wenn Ihre Auswertung einen echten Gewinn zeigt.
Was ist Late Chunking und wann sollte ich es einsetzen?: Late Chunking bettet zunächst das gesamte Dokument mit einem Long-Context-Embedding-Modell ein und fasst dann die Token-Embeddings zu Chunks zusammen — sodass der Vektor jedes Chunks Kontext aus dem gesamten Dokument trägt, nicht nur aus seinem eigenen Text. Verwenden Sie es für lange Dokumente mit weitreichenden Abhängigkeiten, bei denen ein Abschnitt nur mit vorherigem Kontext Sinn ergibt.
Verbessert kontextuelles Retrieval die Genauigkeit wirklich?: Ja, messbar. Anthropic berichtete, dass das Voranstellen einer LLM-generierten Kontextnotiz vor jeden Chunk die Top-20-Retrieval-Fehler um 35 % mit kontextuellen Embeddings, um 49 % kombiniert mit kontextuellem BM25 und um 67 % mit zusätzlichem Reranking reduzierte — bei etwa 1,02 $ pro Million Dokument-Tokens mit Prompt-Caching. Am meisten lohnt es sich für hochwertige Korpora, bei denen ein verpasster Abschnitt teuer ist.
Was ist Parent-Document-Retrieval (von klein nach groß)?: Es entkoppelt, wie Sie abgleichen, von dem, was Sie zurückgeben. Sie indexieren kleine Kind-Chunks für präzises Matching, aber wenn einer übereinstimmt, übergeben Sie dem Modell den größeren Eltern-Abschnitt, damit es den umgebenden Kontext hat. Das gibt Ihnen den Recall kleiner Chunks und die Kohärenz großer Chunks, ohne bei einem von beiden Abstriche zu machen.
Mit welcher Chunking-Strategie sollte ich beginnen?: Mit rekursivem Chunking bei etwa 500 Tokens und 15 % Überlappung. Es respektiert natürliche Grenzen, ist kostengünstig und eine starke Baseline für die meisten Inhalte. Ergänzen Sie strukturbasiertes Splitting für PDFs und Handbücher, Parent-Document-Retrieval, wenn Antworten mehr Kontext benötigen, und kontextuelles Retrieval nur dort, wo der Mehrwert die Extrakosten rechtfertigt.