RAG Chunking-strategier: 7 metoder, rangeret efter retrievaldata (2026)

RAG Chunking-strategier: 7 metoder, rangeret efter retrievaldata (2026)

RAG chunking-strategier afgør, hvad din retriever kan finde, før en eneste query nogensinde kører. Chromas undersøgelse fra juli 2024 kørte 472 queries på tværs af fem korpusser med text-embedding-3-large, og den splitter du vælger, flytter recall med cirka fem point: 86,7 % for en almindelig token-splitter, 91,7 % for GPT-4o-splitteren, med fem chunks hentet per query. Precision svinger langt mere. I hele rapporten løber den fra 1,5 % til 8,0 %, hvilket gør dit valg af chunkstørrelse til en omkostningsbeslutning i kvalitetsforklædning, og hver eneste side-ét-guide lister de samme syv metoder uden at vise, hvilken der henter bedre.

Nøglepointer

• Chunking opdeler dokumenter før embedding; opdelingspunkterne afgør, hvad din retriever kan og ikke kan finde.
• I Chromas undersøgelse fra juli 2024 med 472 queries løb recall fra 86,7 % til 91,7 % på tværs af de målte splitttere.
• Precision varierer flere gange mere end recall, så chunkstørrelse er primært en token-omkostningsbeslutning.
• Start ved 512 tokens med 10 % overlap, og finjuster derefter mod dit eget eval-sæt.

Hvilken RAG Chunking-strategi skal du bruge? (Rangeret)

For de fleste teams, der bygger på flad prosa, er rekursiv karakter-chunking med 512 tokens og 10 % overlap det korrekte standardvalg. Den respekterer afsnits- og sætningsgrænser, koster intet ekstra, og i Chromas 472-query benchmark sluttede den 3,2 recall-point efter den LLM-baserede splitter. Afvig kun, når dine dokumenter har stærk struktur, eller dit eval-sæt beviser det modsatte.

Vores læsning: start med rekursiv karakter. Den halter kun efter klynge- og LLM-splitterne på recall i Chromas data, og LLM-splitterens 3,9 % precision betyder, at du fodrer generatoren med cirka dobbelt så meget støj per relevant token. De fleste teams har ikke et chunking-problem; de har et chunkstørrelsesproblem, de aldrig har målt.

Hvad siger dataene faktisk om chunkstørrelse?

Den eneste offentlige head-to-head-sammenligning af RAG chunking-strategier er Chromas tekniske rapport "Evaluating Chunking Strategies for Retrieval" (Brandon Smith og Anton Troynikov, offentliggjort 3. juli 2024). De kørte 472 queries på tværs af 5 korpusser (328.208 tokens), embeddede alt med OpenAI text-embedding-3-large og hentede 5 chunks per query. Rækkerne nedenfor stammer fra rapportens appendiks-tabel for alle korpusser med text-embedding-3-large ved 5 hentede chunks, så de er direkte sammenlignelige:

Chromas hovedresultattabel, som rapporterer en anden retrieval-indstilling, sætter klynge-chunkerens bedste precision til 8,0 % med 87,3 % recall og strækker precision-intervallet på tværs af alle dens splitttere fra 1,5 % (KamradtSemanticChunker) til 8,0 %. Kilde: Chroma Research, Evaluating Chunking Strategies

Anthropics "Introducing Contextual Retrieval" (offentliggjort 19. september 2024) angriber problemet fra en anden vinkel. Deres baseline top-20 retrieval-fejlrate var 5,7 %; kontekstuelle embeddings alene sænkede den til 3,7 % (35 % reduktion), kontekstuel BM25 oveni bragte den til 2,9 % (49 %), og reranking pressede den til 1,9 % (67 %). Anthropic offentliggør ikke den præcise chunkstørrelse eller det anvendte overlap, så behandl dem som metode-niveau-evidens, ikke størrelses-niveau. Kilde: Anthropic, Contextual Retrieval.

Vores læsning: tre konklusioner fra aritmetikken. For det første er splitervalget reel recall værd, og Chroma siger det klart: nogle strategier overgår andre med op til 9 % i recall. På tværs af hovedresultattabellen løber recall fra 83,6 % (KamradtSemanticChunker) til 91,9 % (LLMSemanticChunker), og i retrieve-5-rækkerne ovenfor spænder den stadig fra 86,7 % til 91,7 %. Precision bevæger sig flere gange længere på de samme data: 1,5 % til 8,0 %, en 5,3x spredning mod recalls 1,1x. Så recall er der, hvor du samler et par point, og precision og token-omkostninger er der, hvor valget virkelig bider. For det andet køber den LLM-baserede splitter top-recall til den værste precision: du betaler et LLM-kald per dokument og fodrer generatoren med mere støj. For det tredje viser Anthropics tal, at berigelse af chunks med kontekst (5,7 % til 3,7 %) flyttede fejlraten længere end noget splitervalg i Chromas tabel gjorde. Berig chunks, før du finjusterer splitteren. Reranking genvinder chunks, som din splitter ødelagde, og hybrid søgning kombinerer BM25 med vektor-retrieval af samme grund.

Ærlige begrænsninger: begge undersøgelser bruger en enkelt embedding-model, engelsksprogede korpusser, og ingen af dem er en kontrolleret test af dit korpus. På tværs af 472 queries var forskellen mellem den bedste og værste splitter cirka 5 recall-point ved 5 hentede chunks og en proportionalt langt større forskel i precision.

Hvorfor afgør chunkstørrelse retrievalkvaliteten?

Chunkstørrelse sætter granulariteten af din retrieval-nøgle. En 400-token chunk producerer en fokuseret embedding, der matcher specifikke queries; en 4.000-token chunk midler på tværs af mange emner og matcher intet præcist. Små chunks henter den præcise passage, men kan fragmentere et svar på tværs af resultater. Store chunks holder konteksten samlet, men svækker embedding-signalet.

Embedding-modellens kontekstloft betyder også noget. Hvis din model har et loft på 512 input-tokens, og du fodrer den med 800, bliver halen stille trunkeret. Din embedding repræsenterer to tredjedele af chunken. Ingen fejl logges.

Så generatørsiden. Liu et al. viste i "Lost in the Middle" (arXiv 2307.03172, 2023), at LLM-nøjagtighed falder over 20 %, når det relevante dokument sidder i midten af en lang kontekst. At hente fem 1.000-token chunks smider 5.000 tokens ind i prompten, og det svar du har brug for, kan lande på den position, modellen læser værst. Mindre chunks holder den relevante passage tættere på en position, modellen håndterer godt.

Tænk på det som et biblioteksindeks. Et kort der siger "Afsnit 4.2, afsnit 3: refusionspolitik" giver dig siden. Et kort der siger "alt om handel i det 20. århundrede" giver dig bygningen. Din embedding er kortet. Byg en RAG-applikation fra ende til anden for at se, hvor chunking sidder i pipelinen, og læs vores context engineering-guide for, hvordan hentede chunks bliver til prompt-tokens. Pinecones chunking-guide indrammer den samme afvejning fra vektordatabase-siden.

Fast størrelse og rekursiv chunking (start her)

Fast størrelse er den baseline, du måler alt andet mod; rekursiv er det, du faktisk sender i produktion.

Fast token-chunking

Opdel hvert N. token uanset indhold.

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

Det rigtige svar til: flad prosa uden overskriftsstruktur, hurtige prototyper og enhver baseline-sammenligning. Det er ikke dumt. Det er kontrolgruppen.

Rekursiv karakter-chunking

LangChains RecursiveCharacterTextSplitter opdeler efter et separatorhierarki: først \n\n (afsnit), derefter \n (linjer), så . (sætninger), så (ord). Hver chunk bliver under chunk_size, mens den respekterer den største naturlige grænse, der passer.

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)

Separatorlisten er den del, alle konkurrenter udelader. Splitteren prøver \n\n først og falder kun tilbage til . , når et afsnit overskrider chunk_size. Hvis din Markdown har overskrifter, så tilføj "## " før "\n\n", så sektionerne forbliver intakte.

Chunk-overlap-aritmetik: ved 512 tokens med 50-token overlap er trinet 462. Et 10.000-token dokument producerer ceil(10000 / 462) = 22 chunks. Samlet antal embeddede tokens: 22 x 512 = 11.264, hvilket betyder, at du gen-embedder cirka 12,6 % af korpusset som overlap. Det er lager- og API-omkostningen ved at forhindre grænsesætninger i at blive forældreløse.

Hvordan virker semantisk chunking, og er det prisen værd?

Semantisk chunking embedder hver sætning, måler cosinus-afstanden mellem nabosætnings-embeddings og opdeler, hvor afstanden overskrider en percentiltærskel (typisk den 95.). Chunks bryder ved emneskift i stedet for vilkårlige tokenantal. Greg Kamradts "5 Levels of Text Splitting" notebook skabte denne percentil-brudpunktstilgang, og Chroma-undersøgelsen benchmarker hans chunkere ved navn.

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)

Omkostningsmatematikken er den del, ingen lægger frem. Semantisk chunking embedder dit korpus to gange: én gang for at beregne sætningsafstande og finde brudpunkter, én gang for at embedde de resulterende chunks til indeksering. Til OpenAIs text-embedding-3-large-pris på $0,13 per 1M tokens koster et 10M-token korpus $1,30 at indeksere normalt og $2,60 med semantisk chunking. Du betaler dobbelt, før en eneste query kører.

Hvad køber det? I Chromas retrieve-5-rækker ramte den klyngebaserede semantiske chunker 89,0 % recall og 6,7 % precision mod 88,5 % og 7,0 % for rekursiv ved samme 200-token-størrelse. I hovedresultattabellen leverer den samme chunker undersøgelsens bedste precision, 8,0 %, ved 87,3 % recall. Et halvt recall-point den ene eller anden vej, og et precision-resultat, der skifter fortegn afhængigt af hvilken retrieval-indstilling du læser, for den dobbelte embedding-regning. Vores dom: semantisk chunking betaler sig for emnemæssigt varierede korpusser (nyhedsarkiver, artikelsamlinger), hvor faste grænser rutinemæssigt deler midt i et emne. For homogene korpusser (produktdokumentation, én vidensbase) giver rekursiv dig 95 % af kvaliteten til halvdelen af omkostningen. Hvis du kører embedding-modeller lokalt med Ollama, falder dobbelt-embedding-omkostningen til beregningstid.

Dokumentbevidst chunking: Markdown, HTML og kode

Strukturbevidst opdeling bruger dokumentets egne grænser (overskrifter, listepunkter, funktionsdefinitioner) i stedet for karakterantal. En Markdown H2 er en semantisk grænse, et menneske har placeret bevidst; en karakter-splitter finder den.

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": "..."}

For kode er grænserne AST-noder. LlamaIndex' NodeParsers leverer sprogsbevidste splitttere, der bryder ved funktions- og klassedefinitioner. Den kritiske detalje: hold importblokken og den omsluttende klassesignatur knyttet til hver funktions-chunk. En funktionskrop uden dens imports er uembedbar støj, så prepend begge til hver chunk, og embeddingen fanger, hvad funktionen gør, og hvad den afhænger af.

For kode-RAG specifikt: AST-grænseopdeling, imports prepended, 256-512 tokens per funktion, nul overlap.

Hvad med sen, hierarkisk og agentisk chunking?

Det er de avancerede RAG chunking-strategier bag "RAG 2.0"-snakken, og alle tre ligger på 1/10 SERP-dækning.

Sen chunking

Sen chunking, introduceret af Günther et al. i "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, september 2024), embedder det fulde dokument med en langkontekst-model først og puljer derefter token-niveau-embeddings til chunk-vektorer, så hver chunk bærer dokumentdækkende kontekst, og "det koster $40/måned" ved, hvad "det" henviser til. Abstractet hævder overlegen retrieval på tværs af opgaver, men offentliggør intet hovedtal, vi kunne verificere. Weaviates skriv forklarer mekanikken og stopper også kort før en kontrolleret sammenligning. Evidensstatus: lovende, ukvantificeret.

Hierarkisk (forælder-barn) chunking

Indeksér små chunks (256 tokens) til retrieval; returner forælderen (1.024 tokens) til generatoren. Retrieveren finder nålen; generatoren får den omgivende høstak. Du vedligeholder to indekseniveauer og en forælder-barn-kortlægning. Ingen offentlig benchmark isolerer effekten.

LLM-baseret / agentisk chunking

Chroma-undersøgelsens LLMSemanticChunker bruger GPT-4o til at beslutte opdelingspunkter per dokument: 91,7 % recall (højest) og 3,9 % precision (lavest). Du betaler et LLM-kald per dokument ved indekseringstidspunktet (cirka $100 for et 10.000-dokument korpus) og fodrer generatoren med mere støj. Reserver den til genuinely uregelmæssige korpusser: juridiske indlæg, scannede PDF'er uden udtrækkelige overskrifter.

Hvilken chunkstørrelse passer til din embedding-model?

Din embedding-modells maksimale input-tokens er et trunkeringsloft, ikke en anbefaling. En model der accepterer 8.192 tokens, embedder ikke bedre ved 8.192 end ved 512. Kvaliteten forringes med udvanding længe før loftet: modellen midler mening på tværs af flere tokens, og vektoren driver mod korpus-centroiden. Anbefalingskolonnen nedenfor er Techsys fortolkning, ikke leverandørernes vejledning.

Kilder: OpenAI embeddings guide, Cohere embed docs, Voyage embeddings docs, BGE model card.

Mønsteret: modeller med et hårdt 512-token-loft (Cohere v3, BGE) kræver chunks godt under 512, fordi trunkering er stille. Fodr én med 600 tokens, og de sidste 88 forsvinder fra embeddingen uden fejl logget. Modeller med store lofter (OpenAI, Voyage, Cohere v4) tolererer større chunks, men belønner dem ikke. En models maksimale inputlængde er en trunkeringsgrænse, ikke en anbefaling.

Kombiner dette med vores bedste embedding-modeller til RAG-oversigt, hvad en MTEB-score faktisk måler, og Voyage, OpenAI og Cohere embeddings side om side, før du binder dig til en model.

Hvordan chunker du ikke-engelske dokumenter?

Tokenizere er ikke sprogsneutrale. Petrov et al. viste i "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023), at den samme tekst oversat på tværs af sprog kan variere i tokeniseret længde med op til 15x. Selv karakter-niveau og byte-niveau modeller viser over 4x forskel for visse sprogpar. En 512-token chunk indeholder langt mindre mening på tyrkisk, arabisk eller japansk end på engelsk.

Her er den samme sætning tokeniseret med 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

Antal genereret med tiktoken cl100k_base, 30. juli 2026.

Praktisk vejledning: ved en fast 512-token chunkstørrelse indeholder dine tyrkiske og japanske chunks cirka 37 % af den mening, dine engelske chunks gør, og dine arabiske chunks indeholder cirka 26 %. Chunk efter karakterantal eller sætningsantal per sprog, eller hæve token-budgettet proportionalt (cirka 1.400 for tyrkisk, 2.000 for arabisk). CJK-sprog har ingen whitespace-ordgrænser, så karakter-splittere opfører sig anderledes. Arabisk morfologi pakker flere grammatiske markører i enkelte tokens, hvilket oppuster antallet yderligere.

Et beslutningstræ til at vælge din chunking-strategi

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

Tre hurtige recepter. Docs-chatbot: MarkdownHeaderTextSplitter ved 512 tokens, nul overlap, overskriftssti i metadata. Kodesøgningsassistent: AST-grænseopdeling ved 256-512 tokens per funktion, imports prepended. Blandet virksomhedskorpus: diriger efter dokumenttype ved ingestion og gem i den vektordatabase, du gemmer chunks i med type-metadata til per-type finjustering senere. Den per-dokument-dirigering er hele adaptiv chunking for RAG-applikationer.

Værktøjer: LangChain vs LlamaIndex vs Chonkie

Vi sælger ingen af disse; de tre øverste rangeringssider for dette søgeord er leverandørblogs med produkt-CTA'er.

Kilder: LangChain docs, LlamaIndex NodeParsers, Chonkie docs.

Alle tre implementerer de samme kernealgoritmer, så vælg baseret på, hvad din pipeline allerede bruger. For den bredere RAG-værktøjsstak ud over splitttere og Qdrant, Chroma og pgvector sammenlignet til lagring, se vores klyngeguider.

Hvordan Techsy griber chunking an

På klient-RAG-projekter starter Techsy-teamet ved 512 tokens med 10 % overlap og rører ikke splitteren, før vi har bygget et 20-50 spørgsmåls eval-sæt fra klientens reelle supportbilletter. Eval-sættet kommer først; derefter ændrer vi én variabel ad gangen: størrelse, overlap, strategi. Intet splitter-skift uden et før-og-efter-tal på de samme spørgsmål. Få en gratis konsultation for et ekstra par øjne på din retrieval-pipeline.

Ofte stillede spørgsmål

Hvad er chunking i RAG?

Chunking er det forbehandlingstrin, der opdeler dokumenter i mindre segmenter før embedding, så retrieveren kan matche queries mod fokuserede passager i stedet for hele filer. Opdelingspunkterne bestemmer, hvad dit system kan og ikke kan finde på query-tidspunktet.

Hvad er den bedste chunking-strategi til RAG?

For de fleste produktionssystemer på generelle dokumenter er rekursiv karakter-chunking med 512 tokens og 10 % overlap det stærkeste standardvalg. I Chromas 472-query undersøgelse (juli 2024) scorede den 88,5 % recall, inden for 3,2 point af den dyreste LLM-baserede metode, til nul ekstra omkostning.

Hvad er den optimale chunkstørrelse til RAG?

Start ved 512 tokens. Gå ned til 256, hvis din embedding-model har et loft på 512 input-tokens (Cohere v3, BGE), eller hvis dine queries forventer enkelt-sætnings-svar. Gå op til 1.024 kun, hvis dit eval-sæt viser, at flersætnings-svar bliver fragmenteret. Mål altid mod dine egne spørgsmål.

Hvor meget chunk-overlap skal jeg bruge?

10-20 % af chunkstørrelsen (50-100 tokens ved 512). Overlap forhindrer grænsesætninger i at blive forældreløse: en fakta delt på tværs af to chunks fremstår komplet i mindst én. Over 20 % gen-embedder du for meget af korpusset for aftagende udbytte. De fleste teams lander på 10 % og genbesøger det aldrig.

Er semantisk chunking bedre end fast-størrelse chunking?

Marginalt, og til den dobbelte embedding-omkostning. Chromas benchmark fra juli 2024 viste den klyngebaserede semantiske chunker på 89,0 % recall og 6,7 % precision mod 88,5 % recall og 7,0 % precision for rekursiv ved samme tokenstørrelse, med dens 8,0 % bedste-precision-resultat fra en anden retrieval-indstilling. Det værd for emnemæssigt varierede korpusser; svært at retfærdiggøre for homogene dokumentsæt.

Afhænger chunkstørrelse af embedding-modellen?

Ja. Modeller med et 512-token input-loft (BGE, Cohere v3) kræver chunks godt under 512, fordi trunkering er stille. Modeller med 8.192+ lofter tolererer større chunks, men belønner dem ikke; embedding-kvalitet forringes med udvanding før loftet. Se parringstabellen ovenfor for per-model startpunkter.

Hvordan chunker jeg kode til et RAG-system?

Opdel efter AST-grænser (funktions- og klassedefinitioner) i stedet for tokenantal. Hold hver chunk på 256-512 tokens per funktion, prepend filens importblok og den omsluttende klassesignatur, og brug nul overlap, da funktioner er selvstændige enheder. LlamaIndex' CodeSplitter og LangChains sprogsbevidste splitttere håndterer begge dette.

Hvad er sen chunking?

Sen chunking embedder det fulde dokument med en langkontekst-model først og puljer derefter token-niveau-embeddings til chunk-vektorer. Hver chunk-embedding bærer dokumentdækkende kontekst, hvilket løser "hvad henviser 'det' til?"-problemet. Introduceret af Günther et al. (arXiv 2409.04701, september 2024). Ingen offentlig head-to-head benchmark kvantificerer gevinsten endnu.

Hvordan chunker jeg dokumenter på andre sprog end engelsk?

Tokenantal er ikke sprogsneutrale. Den samme sætning tog 2,7x flere tokens på tyrkisk og japansk end på engelsk og 3,9x på arabisk (tiktoken cl100k_base). Et fast 512-token-budget giver stille ikke-engelske chunks mindre mening. Chunk efter karakter- eller sætningsantal per sprog, eller hæve budgettet proportionalt.

Hvordan ved jeg, om min chunking faktisk virker?

Byg et 20-50 spørgsmåls eval-sæt fra reelle bruger-queries, før du rører splitteren. Score hit@5 og MRR mod dine nuværende chunks. Ændr én variabel (størrelse, overlap, strategi), kør igen, sammenlign. Uden et eval-sæt finjusterer du på fornemmelsen. Tyve spørgsmål er nok til at starte.

Konklusion

• Start med rekursiv karakter-chunking ved 512 tokens, 10 % overlap. Korrekt standard for flad prosa.
• På tværs af de fire splitterfamilier, nogen har målt, flytter Chromas 472 queries recall cirka 5 point og precision flere gange mere. Finjuster for precision og omkostninger først.
• Match chunkstørrelse til din embedding-modells input-loft. En model med 512-token-loft kræver chunks under 512.
• Berig chunks med kontekst (Anthropics 5,7 % til 3,7 % fejlrate-fald) før du finjusterer splitteren.
• Byg eval-sættet først. Hver splitterbeslutning uden et før-og-efter-tal er et gæt.

For den fulde pipeline omkring dit chunking-valg, se byg en RAG-applikation fra ende til anden. Beslutter du stadig mellem retrieval og fine-tuning? RAG eller fine-tuning gennemgår, hvornår hver især vinder.