RAG-chunking-strategier: 7 metoder, rangert etter retrieval-data (2026)

RAG-chunking-strategier: 7 metoder, rangert etter retrieval-data (2026)

RAG-chunking-strategier avgjør hva retrieveren din kan finne før én eneste spørring kjøres. Chromas studie fra juli 2024 kjørte 472 spørringer mot fem korpus med text-embedding-3-large, og splitteren du velger flytter recall med rundt fem prosentpoeng: 86,7 % for en enkel token-splitter, 91,7 % for GPT-4o-splitteren, med fem chunks hentet per spørring. Precision svinger mye mer. I hele rapporten løper den fra 1,5 % til 8,0 %, noe som gjør chunk-størrelsen til en kostnadsbeslutning forkledd som et kvalitetsvalg, og hver eneste guide på side én i Google lister de samme syv metodene uten å vise hvilken som faktisk henter best.

Nøkkelpoeng

• Chunking deler dokumenter før embedding; delingspunktene avgjør hva retrieveren kan og ikke kan finne.
• I Chromas studie fra juli 2024 med 472 spørringer lå recall på 86,7 % til 91,7 % på tvers av splitterne som ble målt.
• Precision varierer flere ganger mer enn recall, så chunk-størrelsen er først og fremst en token-kostnadsbeslutning.
• Start på 512 tokens med 10 % overlapp, og finjuster mot ditt eget eval-sett.

Hvilken RAG-chunking-strategi bør du velge? (Rangert)

For de fleste team som bygger på løpende prose, er rekursiv tegn-chunking på 512 tokens med 10 % overlapp riktig standardvalg. Den respekterer avsnitts- og setningsgrenser, koster ingenting ekstra og endte 3,2 prosentpoeng bak den LLM-baserte splitteren på recall i Chromas benchmark med 472 spørringer. Gå bort fra den bare når dokumentene dine har sterk struktur, eller når eval-settet ditt beviser noe annet.

Vår vurdering: start med rekursiv tegn-chunking. I Chromas data ligger den bare bak cluster- og LLM-splitterne på recall, og LLM-splitterens precision på 3,9 % betyr at du mater generatoren med omtrent dobbelt så mye støy per relevante token. De fleste team har ikke et chunking-problem; de har et chunk-størrelsesproblem de aldri har målt.

Hva sier dataene egentlig om chunk-størrelse?

Den eneste offentlige head-to-head-sammenligningen av RAG-chunking-strategier er Chromas tekniske rapport «Evaluating Chunking Strategies for Retrieval» (Brandon Smith og Anton Troynikov, publisert 3. juli 2024). De kjørte 472 spørringer mot 5 korpus (328 208 tokens), embeddet alt med OpenAI text-embedding-3-large og hentet 5 chunks per spørring. Radene under kommer fra rapportens vedleggstabell for alle korpus med text-embedding-3-large og 5 hentede chunks, så de er direkte sammenlignbare:

Chromas hovedresultattabell, som rapporterer en annen retrieval-innstilling, setter cluster-splitterens beste precision til 8,0 % med 87,3 % recall, og strekker precision-spennet på tvers av alle splitterne fra 1,5 % (KamradtSemanticChunker) til 8,0 %. Kilde: Chroma Research, Evaluating Chunking Strategies

Anthropics «Introducing Contextual Retrieval» (publisert 19. september 2024) angriper problemet fra en annen vinkel. Deres baseline feilrate for top-20-retrieval var 5,7 %; kontekstuelle embeddings alene senket den til 3,7 % (35 % reduksjon), kontekstuell BM25 på toppen tok den ned til 2,9 % (49 %), og reranking presset den til 1,9 % (67 %). Anthropic oppgir ikke nøyaktig chunk-størrelse eller overlapp, så behandle dette som bevis på metodenivå, ikke størrelsesnivå. Kilde: Anthropic, Contextual Retrieval.

Vår vurdering: tre konklusjoner fra aritmetikken. For det første er splittervalget verdt reell recall, og Chroma sier det rett ut: noen strategier slår andre med opptil 9 % i recall. I hovedresultattabellen løper recall fra 83,6 % (KamradtSemanticChunker) til 91,9 % (LLMSemanticChunker), og i retrieve-5-radene over spenner den fortsatt fra 86,7 % til 91,7 %. Precision beveger seg flere ganger mer på de samme dataene: 1,5 % til 8,0 %, et sprik på 5,3x mot recalls 1,1x. Så recall er der du plukker noen poeng, mens precision og token-kostnad er der valget faktisk biter. For det andre kjøper LLM-splitteren topp-recall med verst precision: du betaler et LLM-kall per dokument og mater generatoren med mer støy. For det tredje viser Anthropics tall at det å berike chunks med kontekst (5,7 % til 3,7 %) flyttet feilraten mer enn noe splittervalg i Chromas tabell gjorde. Berik chunks før du finjusterer splitteren. Reranking henter tilbake chunks som splitteren din ødela, og hybridsøk kombinerer BM25 med vektor-retrieval av samme grunn.

Ærlige begrensninger: begge studiene bruker én embedding-modell, engelskspråklige korpus, og ingen av dem er en kontrollert test av korpuset ditt. På tvers av 472 spørringer var gapet mellom beste og verste splitter omtrent 5 prosentpoeng i recall med 5 hentede chunks, og et proporsjonalt langt større gap i precision.

Hvorfor avgjør chunk-størrelsen retrieval-kvaliteten?

Chunk-størrelsen setter granulariteten på retrieval-nøkkelen din. En chunk på 400 tokens gir en fokusert embedding som treffer spesifikke spørringer; en chunk på 4 000 tokens gjennomsnittsberegner på tvers av mange temaer og treffer ingenting presist. Små chunks henter det nøyaktige avsnittet, men kan fragmentere et svar på tvers av resultater. Store chunks holder konteksten samlet, men svekker embedding-signalet.

Embedding-modellens konteksttak betyr også noe. Hvis modellen din stopper på 512 input-tokens og du mater den 800, blir halen kuttet av i stillhet. Embeddingen din representerer to tredjedeler av chunken. Ingen feil logges.

Så generatorsiden. Liu et al. viste i «Lost in the Middle» (arXiv 2307.03172, 2023) at LLM-nøyaktigheten faller over 20 % når det relevante dokumentet ligger midt i en lang kontekst. Henter du fem chunks på 1 000 tokens, dumper du 5 000 tokens inn i prompten, og svaret du trenger kan havne i posisjonen modellen leser dårligst. Mindre chunks holder det relevante avsnittet nærmere en posisjon modellen håndterer godt.

Tenk på det som et bibliotekregister. Et kort som sier «seksjon 4.2, avsnitt 3: refusjonspolicy» gir deg siden. Et kort som sier «alt om handel i det 20. århundre» gir deg bygningen. Embeddingen din er kortet. Bygg en RAG-applikasjon fra start til slutt for å se hvor chunking sitter i pipelineen, og les guiden vår om kontekst-engineering for hvordan hentede chunks blir til prompt-tokens. Pinecones chunking-guide rammer inn den samme avveiningen fra vektordatabasesiden.

Fast og rekursiv chunking (start her)

Fast størrelse er baselinen du måler alt annet mot; rekursiv chunking er det du faktisk skiper.

Fast token-chunking

Deler hver N tokens uansett innhold.

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

Riktig svar for: løpende prose uten overskriftsstruktur, raske prototyper og alle baseline-sammenligninger. Den er ikke dum. Den er kontrollgruppen.

Rekursiv tegn-chunking

LangChains RecursiveCharacterTextSplitter deler på et separatorhierarki: først \n\n (avsnitt), så \n (linjer), så . (setninger), så (ord). Hver chunk holder seg under chunk_size mens den respekterer den største naturlige grensen som får plass.

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 delen alle konkurrenter utelater. Splitteren prøver \n\n først og faller tilbake til . bare når et avsnitt overskrider chunk_size. Hvis Markdown-en din har overskrifter, legg til "## " før "\n\n" så seksjonene holder seg intakte.

Chunk-overlapp-aritmetikken: med 512 tokens og 50 tokens overlapp er steget 462. Et dokument på 10 000 tokens gir ceil(10000 / 462) = 22 chunks. Totalt antall embeddede tokens: 22 x 512 = 11 264, altså re-embedder du omtrent 12,6 % av korpuset som overlapp. Det er lagrings- og API-kostnaden ved å hindre at grensesetninger blir foreldreløse.

Hvordan fungerer semantisk chunking, og er det verdt kostnaden?

Semantisk chunking embedder hver setning, måler cosinus-avstanden mellom nabosetningers embeddings og deler der avstanden overskrider en persentilterskel (vanligvis 95.). Chunks brytes ved temasifter i stedet for vilkårlige tokenantall. Greg Kamradts «5 Levels of Text Splitting»-notebook startet denne persentil-bruddpunkt-tilnærmingen, og Chroma-studien benchmarker splitterne hans 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)

Kostnadsregnestykket er delen ingen legger frem først. Semantisk chunking embedder korpuset ditt to ganger: én gang for å beregne setningsavstander og finne bruddpunkter, én gang for å embedde de resulterende chunksene for indeksering. Med OpenAIs text-embedding-3-large-pris på $0,13 per 1M tokens koster et korpus på 10M tokens $1,30 å indeksere normalt og $2,60 med semantisk chunking. Du betaler dobbelt før én eneste spørring kjøres.

Hva kjøper det? I Chromas retrieve-5-rader traff den cluster-baserte semantiske chunkeren 89,0 % recall og 6,7 % precision mot 88,5 % og 7,0 % for rekursiv chunking på samme 200-token-størrelse. I hovedresultattabellen leverer den samme chunkeren studiens beste precision, 8,0 %, med 87,3 % recall. Et halvt prosentpoeng hit eller dit på recall, og et precision-resultat som skifter fortegn avhengig av hvilken retrieval-innstilling du leser, for dobbel embedding-regning. Vår dom: semantisk chunking lønner seg på korpus med stor tematisk variasjon (nyhetsarkiver, artikkelsamlinger) der faste grenser rutinemessig deler midt i et tema. For homogene korpus (produktdokumentasjon, én kunnskapsbase) gir rekursiv chunking deg 95 % av kvaliteten til halv kostnad. Hvis du kjører embedding-modeller lokalt med Ollama, krymper dobbel-embedding-kostnaden til ren regnetid.

Dokumentbevisst chunking: Markdown, HTML og kode

Strukturbevisst splitting bruker dokumentets egne grenser (overskrifter, listepunkter, funksjonsdefinisjoner) i stedet for tegnantall. En Markdown H2 er en semantisk grense et menneske plasserte bevisst; en tegn-splitter kverner den opp.

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 grensene AST-noder. LlamaIndex sine NodeParsers leverer språkbevisste splittere som bryter på funksjons- og klassedefinisjoner. Den viktige detaljen: hold importblokken og den omsluttende klassesignaturen festet til hver funksjons-chunk. En funksjonskropp uten imports er uembeddbar støy, så sett begge foran hver chunk, så fanger embeddingen hva funksjonen gjør og hva den avhenger av.

For kode-RAG spesifikt: AST-grensesplitting, imports foran, 256-512 tokens per funksjon, null overlapp.

Hva med sen, hierarkisk og agentisk chunking?

Dette er de avanserte RAG-chunking-strategiene bak «RAG 2.0»-praten, og alle tre ligger på 1/10 SERP-dekning.

Sen chunking

Sen chunking, introdusert av Günther et al. i «Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models» (arXiv 2409.04701, september 2024), embedder hele dokumentet med en langkontekstmodell først og puljer deretter token-nivå-embeddings til chunk-vektorer, slik at hver chunk bærer dokumentomfattende kontekst og «den koster $40/måned» vet hva «den» viser til. Sammendraget hevder overlegen retrieval på tvers av oppgaver, men publiserer ikke noe hovedtall vi kunne verifisere. Weaviates gjennomgang forklarer mekanikken og stopper også kort for en kontrollert sammenligning. Bevisstatus: lovende, ukvantifisert.

Hierarkisk (forelder-barn) chunking

Indekser små chunks (256 tokens) for retrieval; returner forelderen (1 024 tokens) til generatoren. Retrieveren finner nålen; generatoren får høystakken rundt. Du vedlikeholder to indeksenivåer og en forelder-barn-relasjon. Ingen offentlig benchmark isolerer effekten.

LLM-basert / agentisk chunking

Chroma-studiens LLMSemanticChunker bruker GPT-4o til å bestemme delingspunkter per dokument: 91,7 % recall (høyest) og 3,9 % precision (lavest). Du betaler et LLM-kall per dokument ved indeksering (rundt $100 for et korpus på 10 000 dokumenter) og mater generatoren med mer støy. Reserver den for genuint uregelmessige korpus: juridiske dokumenter, skannede PDF-er uten uttrekkbare overskrifter.

Hvilken chunk-størrelse passer embedding-modellen din?

Embedding-modellens maks input-tokens er et truncation-tak, ikke en anbefaling. En modell som godtar 8 192 tokens, embedder ikke bedre på 8 192 enn på 512. Kvaliteten forringes av utvanning lenge før taket: modellen gjennomsnittsberegner mening på tvers av flere tokens, og vektoren driver mot korpusets sentroid. Anbefalingskolonnen under er Techsys tolkning, ikke leverandørenes veiledning.

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

Mønsteret: modeller med et hardt 512-token-tak (Cohere v3, BGE) krever chunks godt under 512, fordi truncation er lydløs. Mat én 600 tokens, og de siste 88 forsvinner fra embeddingen uten at noen feil logges. Modeller med store tak (OpenAI, Voyage, Cohere v4) tåler større chunks, men belønner dem ikke. En modells maks inputlengde er en truncation-grense, ikke en anbefaling.

Koble dette med oversikten vår over de beste embedding-modellene for RAG, hva en MTEB-score faktisk måler og Voyage, OpenAI og Cohere-embeddings side om side før du bestemmer deg for en modell.

Hvordan chunker du ikke-engelske dokumenter?

Tokenizere er ikke språknøytrale. Petrov et al. viste i «Language Model Tokenizers Introduce Unfairness Between Languages» (arXiv 2305.15425, 2023) at samme tekst oversatt mellom språk kan skille seg i tokenisert lengde med opptil 15x. Selv tegn- og byte-nivå-modeller viser over 4x forskjell for noen språkpar. En chunk på 512 tokens rommer langt mindre mening på tyrkisk, arabisk eller japansk enn på engelsk.

Her er den samme setningen tokenisert 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

Tallene er generert med tiktoken cl100k_base, 30. juli 2026.

Praktisk veiledning: med en fast chunk-størrelse på 512 tokens rommer de tyrkiske og japanske chunksene dine omtrent 37 % av meningen de engelske chunksene dine rommer, og de arabiske chunksene dine omtrent 26 %. Chunk etter tegnantall eller setningsantall per språk, eller øk tokenbudsjettet proporsjonalt (rundt 1 400 for tyrkisk, 2 000 for arabisk). CJK-språk har ingen ordgrenser med mellomrom, så tegn-splittere oppfører seg annerledes. Arabisk morfologi pakker flere grammatiske markører i enkelt-tokens og blåser tallene ytterligere opp.

Et beslutningstre for å velge 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 raske resepter. Dokument-chatbot: MarkdownHeaderTextSplitter på 512 tokens, null overlapp, overskriftssti i metadata. Kodesøkeassistent: AST-grensesplitting på 256-512 tokens per funksjon, imports foran. Blandet virksomhetskorpus: rut etter dokumenttype ved inntak, og lagre i vektordatabasen du oppbevarer chunksene i med type-metadata for finjustering per type senere. Den per-dokument-rutingen er hele adaptiv chunking for RAG-applikasjoner.

Verktøy: LangChain vs LlamaIndex vs Chonkie

Vi selger ingen av disse; de tre øverste rangeringssidene for dette søkeordet er leverandørblogger med produkt-CTA-er.

Kilder: LangChain docs, LlamaIndex NodeParsers, Chonkie docs.

Alle tre implementerer de samme kjernealgoritmene, så velg basert på hva pipelineen din allerede bruker. For den bredere RAG-verktøystacken utover splittere og Qdrant, Chroma og pgvector sammenlignet for lagring, se de andre guidene våre i clusteret.

Hvordan Techsy jobber med chunking

På RAG-prosjekter for kunder starter Techsy-teamet på 512 tokens med 10 % overlapp og rører ikke splitteren før vi har bygget et eval-sett på 20-50 spørsmål fra kundens reelle support-saker. Eval-settet kommer først; så endrer vi én variabel om gangen: størrelse, overlapp, strategi. Ingen splitter-bytte uten før-og-etter-tall på de samme spørsmålene. Få en gratis konsultasjon for et ekstra par øyne på retrieval-pipelineen din.

Ofte stilte spørsmål

Hva er chunking i RAG?

Chunking er forbehandlingssteget som deler dokumenter i mindre segmenter før embedding, slik at retrieveren kan matche spørringer mot fokuserte avsnitt i stedet for hele filer. Delingspunktene bestemmer hva systemet ditt kan og ikke kan finne på spørringstidspunktet.

Hva er den beste chunking-strategien for RAG?

For de fleste produksjonssystemer på generelle dokumenter er rekursiv tegn-chunking på 512 tokens med 10 % overlapp det sterkeste standardvalget. I Chromas studie med 472 spørringer (juli 2024) scoret den 88,5 % recall, innenfor 3,2 prosentpoeng av den dyreste LLM-baserte metoden, uten ekstra kostnad.

Hva er den optimale chunk-størrelsen for RAG?

Start på 512 tokens. Gå ned til 256 hvis embedding-modellen din har et tak på 512 input-tokens (Cohere v3, BGE), eller hvis spørringene dine forventer enkeltsetningssvar. Gå opp til 1 024 bare hvis eval-settet ditt viser at svar over flere avsnitt fragmenteres. Mål alltid mot dine egne spørsmål.

Hvor mye chunk-overlapp bør jeg bruke?

10-20 % av chunk-størrelsen (50-100 tokens på 512). Overlapp hindrer at grensesetninger blir foreldreløse: et faktum delt mellom to chunks fremstår komplett i minst én. Over 20 % re-embedder du for mye av korpuset for avtagende gevinst. De fleste team lander på 10 % og ser seg aldri tilbake.

Er semantisk chunking bedre enn fast chunking?

Marginalt, og til dobbel embedding-kostnad. Chromas benchmark fra juli 2024 viste den cluster-baserte semantiske chunkeren på 89,0 % recall og 6,7 % precision mot 88,5 % recall og 7,0 % precision for rekursiv chunking på samme tokenstørrelse, med det beste precision-resultatet på 8,0 % fra en annen retrieval-innstilling. Verdt det for korpus med stor tematisk variasjon; vanskelig å forsvare for homogene dokumentsett.

Avhenger chunk-størrelsen av embedding-modellen?

Ja. Modeller med et 512-token-tak på input (BGE, Cohere v3) krever chunks godt under 512 fordi truncation er lydløs. Modeller med tak på 8 192+ tåler større chunks, men belønner dem ikke; embedding-kvaliteten forringes av utvanning før taket. Se koblingstabellen over for startpunkter per modell.

Hvordan chunker jeg kode for et RAG-system?

Del på AST-grenser (funksjons- og klassedefinisjoner) i stedet for tokenantall. Hold hver chunk på 256-512 tokens per funksjon, sett filens importblokk og den omsluttende klassesignaturen foran, og bruk null overlapp siden funksjoner er selvstendige enheter. LlamaIndex sin CodeSplitter og LangChains språkbevisste splittere håndterer begge dette.

Hva er sen chunking?

Sen chunking embedder hele dokumentet med en langkontekstmodell først og puljer deretter token-nivå-embeddings til chunk-vektorer. Hver chunk-embedding bærer dokumentomfattende kontekst, noe som løser «hva viser 'den' til?»-problemet. Introdusert av Günther et al. (arXiv 2409.04701, september 2024). Ingen offentlig head-to-head-benchmark kvantifiserer gevinsten ennå.

Hvordan chunker jeg dokumenter på andre språk enn engelsk?

Tokenantall er ikke språknøytrale. Den samme setningen brukte 2,7x flere tokens på tyrkisk og japansk enn på engelsk, og 3,9x på arabisk (tiktoken cl100k_base). Et fast budsjett på 512 tokens gir i stillhet ikke-engelske chunks mindre mening. Chunk etter tegn- eller setningsantall per språk, eller øk budsjettet proporsjonalt.

Hvordan vet jeg om chunkingen min faktisk fungerer?

Bygg et eval-sett på 20-50 spørsmål fra reelle brukerspørringer før du rører splitteren. Score hit@5 og MRR mot de nåværende chunksene dine. Endre én variabel (størrelse, overlapp, strategi), kjør på nytt, sammenlign. Uten et eval-sett finjusterer du på følelse. Tjue spørsmål er nok til å komme i gang.

Oppsummert

• Start med rekursiv tegn-chunking på 512 tokens, 10 % overlapp. Riktig standardvalg for løpende prose.
• På tvers av de fire splitterfamiliene noen har målt, flytter Chromas 472 spørringer recall omtrent 5 prosentpoeng og precision flere ganger mer. Finjuster for precision og kostnad først.
• Tilpass chunk-størrelsen til embedding-modellens input-tak. En modell med 512-token-tak krever chunks under 512.
• Berik chunks med kontekst (Anthropics fall i feilrate fra 5,7 % til 3,7 %) før du finjusterer splitteren.
• Bygg eval-settet først. Enhver splitterbeslutning uten før-og-etter-tall er gjetning.

For hele pipelineen rundt chunking-valget ditt, se bygg en RAG-applikasjon fra start til slutt. Står du fortsatt mellom retrieval og finjustering? RAG eller finjustering bryter ned når hver av dem vinner.