RAG-Chunking-Strategien: 7 Methoden, bewertet nach Retrieval-Daten (2026)

RAG-Chunking-Strategien: 7 Methoden, bewertet nach Retrieval-Daten (2026)

RAG-Chunking-Strategien entscheiden darüber, was Ihr Retriever finden kann, noch bevor eine einzige Query läuft. Chromas Studie vom Juli 2024 fuhr 472 Queries über fünf Korpora auf text-embedding-3-large, und die Wahl des Splitters verschiebt den Recall um etwa fünf Punkte: 86,7 % für einen einfachen Token-Splitter, 91,7 % für den GPT-4o-Splitter, bei fünf abgerufenen Chunks pro Query. Die Precision schwankt weit stärker. Über den gesamten Bericht läuft sie von 1,5 % bis 8,0 %, was Ihre Wahl der Chunk-Größe zu einer Kostenentscheidung im Qualitätskostüm macht, und jeder Guide auf Seite 1 listet dieselben sieben Methoden, ohne zu zeigen, welche besser abruft.

Kernaussagen

• Chunking teilt Dokumente vor dem Embedding auf; die Schnittstellen entscheiden, was Ihr Retriever finden kann und was nicht.
• In Chromas Studie vom Juli 2024 mit 472 Queries lag der Recall über die gemessenen Splitter hinweg zwischen 86,7 % und 91,7 %.
• Die Precision variiert ein Mehrfaches stärker als der Recall, daher ist die Chunk-Größe vor allem eine Token-Kosten-Entscheidung.
• Starten Sie bei 512 Tokens mit 10 % Überlappung und stimmen Sie dann gegen Ihr eigenes Eval-Set ab.

Welche RAG-Chunking-Strategie sollten Sie verwenden? (Ranking)

Für die meisten Teams, die auf Fließtext aufbauen, ist rekursives Character-Chunking mit 512 Tokens und 10 % Überlappung der richtige Standard. Es respektiert Absatz- und Satzgrenzen, kostet nichts extra und blieb in Chromas 472-Query-Benchmark 3,2 Recall-Punkte hinter dem LLM-basierten Splitter. Weichen Sie nur ab, wenn Ihre Dokumente eine starke Eigenstruktur haben oder Ihr Eval-Set etwas anderes beweist.

Unsere Lesart: Starten Sie mit rekursivem Character-Chunking. In Chromas Daten liegt es beim Recall nur hinter dem Cluster- und dem LLM-Splitter, und die 3,9 % Precision des LLM-Splitters bedeuten, dass Sie dem Generator pro relevantem Token grob das doppelte Rauschen zuführen. Die meisten Teams haben kein Chunking-Problem; sie haben ein Chunk-Größen-Problem, das sie nie gemessen haben.

Was sagen die Daten wirklich über die Chunk-Größe?

Der einzige öffentliche Head-to-Head-Vergleich von RAG-Chunking-Strategien ist Chromas technischer Bericht „Evaluating Chunking Strategies for Retrieval" (Brandon Smith und Anton Troynikov, veröffentlicht am 3. Juli 2024). Sie fuhren 472 Queries über 5 Korpora (328.208 Tokens), betteten alles mit OpenAI text-embedding-3-large ein und riefen 5 Chunks pro Query ab. Die Zeilen unten stammen aus der Anhang-Tabelle des Berichts für alle Korpora auf text-embedding-3-large bei 5 abgerufenen Chunks und sind damit direkt miteinander vergleichbar:

Chromas Hauptergebnistabelle, die ein anderes Retrieval-Setting berichtet, setzt die beste Precision des Cluster-Chunkers auf 8,0 % bei 87,3 % Recall und dehnt die Precision-Spanne über alle Splitter von 1,5 % (KamradtSemanticChunker) bis 8,0 %. Quelle: Chroma Research: Chunking-Strategien evaluieren

Anthropics „Introducing Contextual Retrieval" (veröffentlicht am 19. September 2024) greift das Problem von einer anderen Seite an. Ihre Basis-Fehlerrate im Top-20-Retrieval lag bei 5,7 %; kontextuelle Embeddings allein drückten sie auf 3,7 % (35 % Reduktion), kontextuelles BM25 obendrauf brachte sie auf 2,9 % (49 %), und Reranking drückte sie auf 1,9 % (67 %). Anthropic veröffentlicht die genaue Chunk-Größe oder Überlappung nicht, also behandeln Sie diese Zahlen als Evidenz auf Methodenebene, nicht auf Größenebene. Quelle: Anthropic: Contextual Retrieval.

Unsere Lesart: drei Schlüsse aus der Arithmetik. Erstens ist die Splitter-Wahl echten Recall wert, und Chroma sagt es klar: Manche Strategien schlagen andere um bis zu 9 % im Recall. Über die Hauptergebnistabelle läuft der Recall von 83,6 % (KamradtSemanticChunker) bis 91,9 % (LLMSemanticChunker), und in den Retrieve-5-Zeilen oben spannt er sich immer noch von 86,7 % bis 91,7 %. Die Precision bewegt sich auf denselben Daten um ein Mehrfaches weiter: 1,5 % bis 8,0 %, eine 5,3-fache Spanne gegen 1,1-fache beim Recall. Also ist Recall dort, wo Sie ein paar Punkte aufsammeln, und Precision und Token-Kosten sind dort, wo die Wahl wirklich zu Buche schlägt. Zweitens erkauft der LLM-basierte Splitter den besten Recall mit der schlechtesten Precision: Sie zahlen einen LLM-Aufruf pro Dokument und füttern dem Generator mehr Rauschen. Drittens zeigen Anthropics Zahlen, dass die Anreicherung von Chunks mit Kontext (5,7 % auf 3,7 %) die Fehlerrate weiter verschob als jede Splitter-Wahl in Chromas Tabelle. Reichern Sie Chunks an, bevor Sie den Splitter neu abstimmen. Reranking rettet Chunks, die Ihr Splitter zerlegt hat, und Hybrid-Suche kombiniert BM25 mit Vektor-Retrieval aus demselben Grund.

Ehrliche Grenzen: Beide Studien nutzen ein einziges Embedding-Modell, rein englischsprachige Korpora, und keine von beiden ist ein kontrollierter Test Ihres Korpus. Über 472 Queries hinweg betrug die Lücke zwischen bestem und schlechtestem Splitter etwa 5 Recall-Punkte bei 5 abgerufenen Chunks, und eine proportional weit größere Lücke in der Precision.

Warum bestimmt die Chunk-Größe die Retrieval-Qualität?

Die Chunk-Größe setzt die Granularität Ihres Retrieval-Schlüssels. Ein 400-Token-Chunk erzeugt ein fokussiertes Embedding, das spezifische Queries matcht; ein 4.000-Token-Chunk mittelt über viele Themen und matcht nichts präzise. Kleine Chunks rufen die exakte Passage ab, können eine Antwort aber über die Ergebnisse zerstückeln. Große Chunks halten den Kontext zusammen, schwächen aber das Embedding-Signal.

Auch das Kontextlimit des Embedding-Modells zählt. Wenn Ihr Modell bei 512 Eingabe-Tokens deckelt und Sie ihm 800 geben, wird das Ende still abgeschnitten. Ihr Embedding repräsentiert zwei Drittel des Chunks. Kein Fehler im Log.

Dann die Generator-Seite. Liu et al. zeigten in „Lost in the Middle" (arXiv 2307.03172, 2023), dass die LLM-Genauigkeit um über 20 % einbricht, wenn das relevante Dokument in der Mitte eines langen Kontexts sitzt. Fünf abgerufene 1.000-Token-Chunks kippen 5.000 Tokens in den Prompt, und die Antwort, die Sie brauchen, landet vielleicht genau auf der Position, die das Modell am schlechtesten liest. Kleinere Chunks halten die relevante Passage näher an einer Position, die das Modell gut verarbeitet.

Stellen Sie es sich wie einen Bibliothekskatalog vor. Eine Karteikarte mit „Abschnitt 4.2, Absatz 3: Rückerstattungsrichtlinie" bringt Sie zur Seite. Eine Karteikarte mit „alles über den Handel im 20. Jahrhundert" bringt Sie zum Gebäude. Ihr Embedding ist die Karteikarte. Entwickeln Sie eine RAG-Anwendung von Grund auf, um zu sehen, wo Chunking in der Pipeline sitzt, und lesen Sie unseren Context-Engineering-Leitfaden dafür, wie abgerufene Chunks zu Prompt-Tokens werden. Pinecones Chunking-Guide rahmt denselben Trade-off von der Vektordatenbank-Seite.

Chunking mit fester Größe und rekursives Chunking (hier starten)

Chunking mit fester Größe ist die Baseline, an der Sie alles messen; rekursives Chunking ist das, was Sie tatsächlich ausliefern.

Token-Chunking mit fester Größe

Teilen Sie alle N Tokens, unabhängig vom Inhalt.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Die richtige Antwort für: Fließtext ohne Überschriftstruktur, schnelle Prototypen und jede Baseline-Vergleichsmessung. Es ist nicht dumm. Es ist die Kontrollgruppe.

Rekursives Character-Chunking

LangChains RecursiveCharacterTextSplitter teilt nach einer Trennzeichen-Hierarchie: zuerst \n\n (Absätze), dann \n (Zeilen), dann . (Sätze), dann (Wörter). Jeder Chunk bleibt unter chunk_size und respektiert dabei die größte natürliche Grenze, die passt.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

Die Trennzeichen-Liste ist der Teil, den jeder Wettbewerber weglässt. Der Splitter versucht zuerst \n\n und fällt nur dann auf . zurück, wenn ein Absatz chunk_size überschreitet. Wenn Ihr Markdown Header hat, fügen Sie "## " vor "\n\n" ein, damit Abschnitte intakt bleiben.

Chunk-Überlappungs-Arithmetik: Bei 512 Tokens mit 50 Tokens Überlappung ist die Schrittweite 462. Ein 10.000-Token-Dokument erzeugt ceil(10000 / 462) = 22 Chunks. Insgesamt eingebettete Tokens: 22 x 512 = 11.264, das heißt, Sie betten grob 12,6 % des Korpus als Überlappung erneut ein. Das sind die Speicher- und API-Kosten, damit Sätze an den Grenzen nicht verwaisen.

Wie funktioniert semantisches Chunking, und lohnt sich der Aufwand?

Semantisches Chunking bettet jeden Satz ein, misst die Kosinusdistanz zwischen benachbarten Satz-Embeddings und teilt dort, wo diese Distanz einen Perzentil-Schwellwert (üblicherweise das 95.) überschreitet. Chunks brechen an Themenwechseln statt an beliebigen Token-Zahlen. Greg Kamradts „5 Levels of Text Splitting"-Notebook begründete diesen Perzentil-Bruchpunkt-Ansatz, und die Chroma-Studie benchmarkt seine Chunker namentlich.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Die Kostenrechnung ist der Teil, den niemand voranstellt. Semantisches Chunking bettet Ihren Korpus zweimal ein: einmal, um die Satz-Distanzen zu berechnen und Bruchpunkte zu finden, einmal, um die resultierenden Chunks für die Indizierung einzubetten. Beim OpenAI-Preis für text-embedding-3-large von 0,13 $ pro 1 Mio. Tokens kostet ein 10-Mio.-Token-Korpus 1,30 $ für normale Indizierung und 2,60 $ mit semantischem Chunking. Sie zahlen das Doppelte, bevor eine einzige Query läuft.

Was kauft Ihnen das? In Chromas Retrieve-5-Zeilen erreichte der Cluster-basierte semantische Chunker 89,0 % Recall und 6,7 % Precision gegen 88,5 % und 7,0 % für rekursives Chunking bei gleicher 200-Token-Größe. In der Hauptergebnistabelle liefert derselbe Chunker die beste Precision der Studie, 8,0 %, bei 87,3 % Recall. Ein halber Punkt Recall hüben wie drüben und ein Precision-Ergebnis, das je nach gelesenem Retrieval-Setting das Vorzeichen wechselt, für die doppelte Embedding-Rechnung. Unser Urteil: Semantisches Chunking zahlt sich bei themenvielfältigen Korpora aus (Nachrichtenarchive, Papiersammlungen), wo feste Grenzen routinemäßig mitten im Thema schneiden. Für homogene Korpora (Produktdoku, eine Wissensbasis) holt rekursives Chunking 95 % der Qualität zum halben Preis. Wenn Sie Embedding-Modelle lokal mit Ollama ausführen, schrumpfen die doppelten Embedding-Kosten auf Rechenzeit.

Dokumentbewusstes Chunking: Markdown, HTML und Code

Strukturbewusstes Teilen nutzt die dokumenteigenen Grenzen (Überschriften, Listenelemente, Funktionsdefinitionen) statt Zeichenzahlen. Ein Markdown-H2 ist eine semantische Grenze, die ein Mensch bewusst gesetzt hat; ein Character-Splitter häckselt sie klein.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Bei Code sind die Grenzen AST-Knoten. LlamaIndex' NodeParsers liefern sprachbewusste Splitter, die an Funktions- und Klassendefinitionen brechen. Das entscheidende Detail: Halten Sie den Import-Block und die umschließende Klassensignatur an jedem Funktions-Chunk. Ein Funktionskörper ohne seine Imports ist nicht einbettbarer Lärm, also stellen Sie beides jedem Chunk voran, und das Embedding erfasst, was die Funktion tut und wovon sie abhängt.

Speziell für Code-RAG: AST-Grenz-Splitting, Imports vorangestellt, 256-512 Tokens pro Funktion, null Überlappung.

Was ist mit Late Chunking, hierarchischem und agentischem Chunking?

Das sind die fortgeschrittenen RAG-Chunking-Strategien hinter dem „RAG 2.0"-Gerede, und alle drei liegen bei 1/10 SERP-Abdeckung.

Late Chunking

Late Chunking, eingeführt von Günther et al. in „Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, September 2024), bettet zuerst das gesamte Dokument mit einem Long-Context-Modell ein und poolt dann die Embeddings auf Token-Ebene zu Chunk-Vektoren, sodass jeder Chunk dokumentweiten Kontext trägt und „es kostet 40 $/Monat" weiß, worauf „es" sich bezieht. Das Abstract behauptet überlegenes Retrieval über mehrere Aufgaben, veröffentlicht aber keine prüfbare Schlagzahl. Weaviates Write-up erklärt die Mechanik und verzichtet ebenfalls auf einen kontrollierten Vergleich. Evidenzstatus: vielversprechend, nicht quantifiziert.

Hierarchisches Chunking (Parent-Child)

Indizieren Sie kleine Chunks (256 Tokens) für das Retrieval; geben Sie den Parent (1.024 Tokens) an den Generator zurück. Der Retriever findet die Nadel; der Generator bekommt den umgebenden Heuhaufen. Sie pflegen zwei Index-Ebenen und ein Parent-Child-Mapping. Kein öffentlicher Benchmark isoliert den Effekt.

LLM-basiertes / agentisches Chunking

Der LLMSemanticChunker der Chroma-Studie nutzt GPT-4o, um die Schnittpunkte pro Dokument zu bestimmen: 91,7 % Recall (höchster) und 3,9 % Precision (niedrigste). Sie zahlen zur Indexierungszeit einen LLM-Aufruf pro Dokument (etwa 100 $ für einen 10.000-Dokumente-Korpus) und füttern dem Generator mehr Rauschen. Reservieren Sie ihn für wirklich unregelmäßige Korpora: juristische Schriftsätze, gescannte PDFs ohne extrahierbare Überschriften.

Welche Chunk-Größe passt zu Ihrem Embedding-Modell?

Die maximale Eingabe-Token-Zahl Ihres Embedding-Modells ist eine Abschneide-Obergrenze, keine Empfehlung. Ein Modell, das 8.192 Tokens akzeptiert, bettet bei 8.192 nicht besser ein als bei 512. Die Qualität verschleißt durch Verdünnung lange vor dem Limit: Das Modell mittelt die Bedeutung über mehr Tokens, und der Vektor driftet zum Korpus-Schwerpunkt. Die Empfehlungsspalte unten ist Techsys Interpretation, nicht die Vorgabe der Anbieter.

Quellen: OpenAI Embeddings-Guide, Cohere-Embed-Dokumentation, Voyage Embeddings-Dokumentation, BGE-Modellkarte.

Das Muster: Modelle mit einem harten 512-Token-Limit (Cohere v3, BGE) verlangen Chunks deutlich unter 512, weil das Abschneiden still passiert. Geben Sie einem 600 Tokens, und die letzten 88 verschwinden ohne Fehlereintrag aus dem Embedding. Modelle mit großen Limits (OpenAI, Voyage, Cohere v4) tolerieren größere Chunks, belohnen sie aber nicht. Die maximale Eingabelänge eines Modells ist ein Abschneide-Limit, keine Empfehlung.

Kombinieren Sie das mit unserem Roundup der besten Embedding-Modelle für RAG, was ein MTEB-Score tatsächlich misst und Voyage, OpenAI und Cohere Embeddings im Vergleich, bevor Sie sich auf ein Modell festlegen.

Wie chunkt man nicht-englische Dokumente?

Tokenizer sind nicht sprachneutral. Petrov et al. zeigten in „Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023), dass derselbe Text über Sprachen hinweg in der tokenisierten Länge um bis zu 15x differieren kann. Selbst Modelle auf Zeichen- und Byte-Ebene zeigen über 4x Unterschied für manche Sprachpaare. Ein 512-Token-Chunk fasst auf Türkisch, Arabisch oder Japanisch weit weniger Bedeutung als auf Englisch.

Hier ist derselbe Satz, tokenisiert mit tiktokens cl100k_base-Encoding (GPT-4s Tokenizer):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Zahlen erzeugt mit tiktoken cl100k_base, 30. Juli 2026.

Praktische Anleitung: Bei einer festen Chunk-Größe von 512 Tokens fassen Ihre türkischen und japanischen Chunks grob 37 % der Bedeutung Ihrer englischen Chunks, und Ihre arabischen Chunks fassen etwa 26 %. Chunken Sie pro Sprache nach Zeichen- oder Satzzahl, oder heben Sie das Token-Budget proportional an (etwa 1.400 für Türkisch, 2.000 für Arabisch). CJK-Sprachen haben keine Wortgrenzen durch Whitespace, daher verhalten sich Character-Splitter anders. Die arabische Morphologie packt mehrere grammatische Marker in einzelne Tokens und treibt die Zahlen weiter hoch.

Ein Entscheidungsbaum für die Wahl Ihrer Chunking-Strategie

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Drei schnelle Empfehlungen. Doku-Chatbot: MarkdownHeaderTextSplitter mit 512 Tokens, null Überlappung, Überschriftpfad in den Metadaten. Code-Suche-Assistent: AST-Grenz-Splitting mit 256-512 Tokens pro Funktion, Imports vorangestellt. Gemischter Enterprise-Korpus: Beim Einlesen nach Dokumenttyp routen und in der Vektordatenbank, in der Sie die Chunks speichern mit Typ-Metadaten ablegen, für spätere Feinabstimmung pro Typ. Genau dieses Routing pro Dokument ist die Gesamtheit des adaptiven Chunkings für RAG-Anwendungen.

Tools: LangChain vs. LlamaIndex vs. Chonkie

Wir verkaufen keines davon; die drei erstplatzierten Seiten für dieses Keyword sind Anbieter-Blogs mit Produkt-CTAs.

Quellen: LangChain-Dokumentation, LlamaIndex NodeParsers, Chonkie-Dokumentation.

Alle drei implementieren dieselben Kern-Algorithmen, also wählen Sie nach dem, was Ihre Pipeline bereits nutzt. Für den breiteren RAG-Tool-Stack jenseits von Splittern und Qdrant, Chroma und pgvector im Vergleich für die Speicherung siehe unsere Cluster-Guides.

Wie Techsy an Chunking herangeht

Bei Kunden-RAG-Projekten startet das Techsy-Team bei 512 Tokens mit 10 % Überlappung und fasst den Splitter nicht an, bis wir ein 20-50-Fragen-Eval-Set aus den echten Support-Tickets des Kunden gebaut haben. Das Eval-Set kommt zuerst; dann ändern wir eine Variable nach der anderen: Größe, Überlappung, Strategie. Kein Splitter-Wechsel ohne Vorher-Nachher-Zahl auf denselben Fragen. Holen Sie sich eine kostenlose Beratung für einen zweiten Blick auf Ihre Retrieval-Pipeline.

Häufig gestellte Fragen

Was ist Chunking in RAG?

Chunking ist der Vorverarbeitungsschritt, der Dokumente vor dem Embedding in kleinere Segmente teilt, damit der Retriever Queries gegen fokussierte Passagen matchen kann statt gegen ganze Dateien. Die Schnittstellen bestimmen, was Ihr System zur Query-Zeit finden kann und was nicht.

Was ist die beste Chunking-Strategie für RAG?

Für die meisten Produktionssysteme auf allgemeinen Dokumenten ist rekursives Character-Chunking mit 512 Tokens und 10 % Überlappung der stärkste Standard. In Chromas 472-Query-Studie (Juli 2024) erzielte es 88,5 % Recall, nur 3,2 Punkte hinter der teuersten LLM-basierten Methode, ohne Zusatzkosten.

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

Starten Sie bei 512 Tokens. Gehen Sie auf 256 herunter, wenn Ihr Embedding-Modell bei 512 Eingabe-Tokens deckelt (Cohere v3, BGE) oder wenn Ihre Queries Antworten aus einem einzelnen Satz erwarten. Gehen Sie nur auf 1.024 hoch, wenn Ihr Eval-Set zeigt, dass mehrabsätzige Antworten zerstückelt werden. Messen Sie immer gegen Ihre eigenen Fragen.

Wie viel Chunk-Überlappung sollte ich verwenden?

10 bis 20 % der Chunk-Größe (50-100 Tokens bei 512). Überlappung verhindert, dass Sätze an den Grenzen verwaisen: Ein Fakt, der über zwei Chunks gespalten ist, erscheint in mindestens einem vollständig. Über 20 % hinaus betten Sie zu viel des Korpus erneut ein für abnehmenden Ertrag. Die meisten Teams landen bei 10 % und schauen nie wieder hin.

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

Marginal, und zum doppelten Embedding-Preis. Chromas Benchmark vom Juli 2024 zeigte den Cluster-basierten semantischen Chunker bei 89,0 % Recall und 6,7 % Precision gegen 88,5 % Recall und 7,0 % Precision für rekursives Chunking bei gleicher Token-Größe, wobei das 8,0-%-Bestwert-Ergebnis aus einem anderen Retrieval-Setting stammt. Lohnt sich für themenvielfältige Korpora; schwer zu rechtfertigen für homogene Dokumentbestände.

Hängt die Chunk-Größe vom Embedding-Modell ab?

Ja. Modelle mit einem 512-Token-Eingabelimit (BGE, Cohere v3) verlangen Chunks deutlich unter 512, weil das Abschneiden still passiert. Modelle mit Limits von 8.192 und mehr tolerieren größere Chunks, belohnen sie aber nicht; die Embedding-Qualität verschleißt durch Verdünnung vor dem Limit. Siehe die Paarungs-Tabelle oben für Startpunkte pro Modell.

Wie chunke ich Code für ein RAG-System?

Teilen Sie an AST-Grenzen (Funktions- und Klassendefinitionen) statt an Token-Zahlen. Halten Sie jeden Chunk bei 256-512 Tokens pro Funktion, stellen Sie den Import-Block der Datei und die umschließende Klassensignatur voran und nutzen Sie null Überlappung, da Funktionen in sich geschlossene Einheiten sind. LlamaIndex' CodeSplitter und LangChains sprachbewusste Splitter können beides.

Was ist Late Chunking?

Late Chunking bettet zuerst das gesamte Dokument mit einem Long-Context-Modell ein und poolt dann die Embeddings auf Token-Ebene zu Chunk-Vektoren. Jedes Chunk-Embedding trägt dokumentweiten Kontext und löst das „Worauf bezieht sich ‚es'?"-Problem. Eingeführt von Günther et al. (arXiv 2409.04701, September 2024). Noch kein öffentlicher Head-to-Head-Benchmark quantifiziert den Gewinn.

Wie chunke ich Dokumente in anderen Sprachen als Englisch?

Token-Zahlen sind nicht sprachneutral. Derselbe Satz brauchte auf Türkisch und Japanisch 2,7-mal mehr Tokens als auf Englisch und auf Arabisch 3,9-mal (tiktoken cl100k_base). Ein festes 512-Token-Budget gibt nicht-englischen Chunks still weniger Bedeutung. Chunken Sie pro Sprache nach Zeichen- oder Satzzahl, oder heben Sie das Budget proportional an.

Woran erkenne ich, dass mein Chunking tatsächlich funktioniert?

Bauen Sie ein 20-50-Fragen-Eval-Set aus echten Nutzer-Queries, bevor Sie den Splitter anfassen. Bewerten Sie hit@5 und MRR gegen Ihre aktuellen Chunks. Ändern Sie eine Variable (Größe, Überlappung, Strategie), starten Sie neu, vergleichen Sie. Ohne Eval-Set stimmen Sie nach Gefühl ab. Zwanzig Fragen reichen für den Start.

Fazit

• Starten Sie mit rekursivem Character-Chunking bei 512 Tokens, 10 % Überlappung. Richtiger Standard für Fließtext.
• Über die vier Splitter-Familien, die irgendjemand gemessen hat, bewegen Chromas 472 Queries den Recall um etwa 5 Punkte und die Precision um ein Mehrfaches. Stimmen Sie zuerst auf Precision und Kosten ab.
• Passen Sie die Chunk-Größe an das Eingabelimit Ihres Embedding-Modells an. Ein Modell mit 512-Token-Limit verlangt Chunks unter 512.
• Reichern Sie Chunks mit Kontext an (Anthropics Fehlerraten-Drop von 5,7 % auf 3,7 %), bevor Sie den Splitter neu abstimmen.
• Bauen Sie zuerst das Eval-Set. Jede Splitter-Entscheidung ohne Vorher-Nachher-Zahl ist eine Vermutung.

Für die gesamte Pipeline rund um Ihre Chunking-Wahl siehe eine RAG-Anwendung von Grund auf entwickeln. Entscheiden Sie noch zwischen Retrieval und Fine-Tuning? RAG oder Fine-Tuning schlüsselt auf, wann was gewinnt.