RAG-chunking-strategier: 7 metoder rankade efter retrieval-data (2026)

RAG-chunking-strategier: 7 metoder rankade efter retrieval-data (2026)

RAG-chunking-strategier avgör vad din retriever kan hitta innan en enda sökfråga ens körs. Chromas studie från juli 2024 körde 472 sökningar mot fem korpusar med text-embedding-3-large, och vilken splitter du väljer flyttar recall med ungefär fem procentenheter: 86,7 % för en enkel token-splitter, 91,7 % för GPT-4o-versionen, med fem chunks hämtade per sökning. Precisionen svänger mycket mer. I hela rapporten löper den från 1,5 % till 8,0 %, vilket gör din chunkstorlek till ett kostnadsbeslut i kvalitetsförklädnad, och varje guide på sida ett listar samma sju metoder utan att visa vilken som hämtar bäst.

Det viktigaste i korthet

• Chunkning delar upp dokument före embedding; delningspunkterna avgör vad din retriever kan och inte kan hitta.
• I Chromas studie från juli 2024 med 472 sökningar låg recall på 86,7–91,7 % mellan de uppmätta splittrarna.
• Precisionen varierar flera gånger mer än recall, så chunkstorlek är främst ett beslut om tokenkostnad.
• Börja på 512 tokens med 10 % överlapp och finjustera sedan mot din egen eval-mängd.

Vilken RAG-chunking-strategi ska du välja? (Rankad)

För de flesta team som bygger på löpande prosatext är rekursiv tecken-chunkning på 512 tokens med 10 % överlapp rätt standardval. Den respekterar stycke- och meningsgränser, kostar inget extra och hamnade i Chromas benchmark med 472 sökningar 3,2 procentenheter efter den LLM-baserade splittern i recall. Byt bara när dina dokument har stark struktur eller när din eval-mängd bevisar motsatsen.

Vår slutsats: börja med rekursiv tecken. I Chromas data slår den bara kluster- och LLM-splittrarna i recall, och LLM-splitterns precision på 3,9 % innebär att du matar generatorn med ungefär dubbelt så mycket brus per relevant token. De flesta team har inte ett chunkning-problem; de har ett chunkstorleks-problem som de aldrig har mätt.

Vad säger datan egentligen om chunkstorlek?

Den enda offentliga head-to-head-jämförelsen av RAG-chunking-strategier är Chromas tekniska rapport "Evaluating Chunking Strategies for Retrieval" (Brandon Smith och Anton Troynikov, publicerad 3 juli 2024). De körde 472 sökningar mot 5 korpusar (328 208 tokens), embeddade allt med OpenAI text-embedding-3-large och hämtade 5 chunks per sökning. Raderna nedan kommer från rapportens bilagetabell för alla korpusar med text-embedding-3-large vid 5 hämtade chunks, så de är direkt jämförbara med varandra:

Chromas huvudresultattabell, som rapporterar en annan retrieval-inställning, sätter kluster-chunkerns bästa precision till 8,0 % med 87,3 % recall, och sträcker precisionsspannet över alla dess splittrar från 1,5 % (KamradtSemanticChunker) till 8,0 %. Källa: Chroma Research, Evaluating Chunking Strategies

Anthropics "Introducing Contextual Retrieval" (publicerad 19 september 2024) angriper problemet från ett annat håll. Deras baseline för misslyckad top-20-retrieval var 5,7 %; enbart kontextuella embeddings sänkte den till 3,7 % (35 % minskning), kontextuell BM25 ovanpå det tog den till 2,9 % (49 %), och reranking pressade den till 1,9 % (67 %). Anthropic publicerar inte den exakta chunkstorlek eller det överlapp som användes, så behandla detta som bevis på metodnivå, inte storleksnivå. Källa: Anthropic, Contextual Retrieval.

Vår slutsats: tre slutsatser från aritmetiken. För det första är valet av splitter värt riktig recall, och Chroma säger det rakt ut: vissa strategier slår andra med upp till 9 % i recall. I huvudresultattabellen löper recall från 83,6 % (KamradtSemanticChunker) till 91,9 % (LLMSemanticChunker), och inom retrieve-5-raderna ovan spänner den fortfarande över 86,7–91,7 %. Precisionen rör sig flera gånger längre på samma data: 1,5–8,0 %, en spridning på 5,3x mot recalls 1,1x. Så recall är där du plockar några procentenheter, medan precision och tokenkostnad är där valet faktiskt biter. För det andra köper den LLM-baserade splittern topp-recall till sämst precision: du betalar ett LLM-anrop per dokument och matar generatorn med mer brus. För det tredje visar Anthropics siffror att berika chunks med kontext (5,7 till 3,7 %) flyttade felfrekvensen längre än något val av splitter i Chromas tabell gjorde. Berika chunks innan du finjusterar splittern. Reranking räddar chunks som din splitter styckade, och hybridsökning kombinerar BM25 med vektor-retrieval av samma anledning.

Ärliga begränsningar: båda studierna använder en enda embeddingmodell, engelskspråkiga korpusar, och ingen av dem är ett kontrollerat test av ditt korpus. Över 472 sökningar var gapet mellan bästa och sämsta splitter ungefär 5 procentenheter i recall vid 5 hämtade chunks, och ett proportionellt mycket större gap i precision.

Varför avgör chunkstorleken retrieval-kvaliteten?

Chunkstorleken sätter granulariteten på din retrieval-nyckel. En 400-token chunk ger en fokuserad embedding som matchar specifika sökfrågor; en 4 000-token chunk genomsnittar över många ämnen och matchar ingenting exakt. Små chunks hämtar den exakta passagen men kan fragmentera ett svar över flera resultat. Stora chunks håller ihop kontexten men försvagar embedding-signalen.

Embedding-modellens kontexttak spelar också roll. Om din modell har ett tak på 512 input-tokens och du matar den med 800 kapas slutet tyst. Din embedding representerar två tredjedelar av chunken. Inget fel loggas.

Sedan generatorsidan. Liu et al. visade i "Lost in the Middle" (arXiv 2307.03172, 2023) att LLM-precisionen sjunker över 20 % när det relevanta dokumentet ligger mitt i en lång kontext. Att hämta fem 1 000-token chunks dumpar 5 000 tokens i prompten, och svaret du behöver kan hamna på positionen som modellen läser sämst. Mindre chunks håller den relevanta passagen närmare en position som modellen hanterar bra.

Tänk dig ett biblioteksregister. Ett kort som säger "avsnitt 4.2, stycke 3: återbetalningspolicy" ger dig sidan. Ett kort som säger "allt om handel under 1900-talet" ger dig byggnaden. Din embedding är kortet. Bygg en RAG-applikation från början till slut för att se var chunkning hamnar i pipelinen, och läs vår guide om kontextengineering för hur hämtade chunks blir prompt-tokens. Pinecones chunkning-guide ramar in samma avvägning från vektordatabassidan.

Fast storlek och rekursiv chunkning (börja här)

Fast storlek är baslinjen du mäter allt annat mot; rekursiv är det du faktiskt skeppar.

Fast token-chunkning

Dela var N:e token oavsett innehåll.

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

Rätt svar för: löpande prosa utan rubrikstruktur, snabba prototyper och alla baslinje-jämförelser. Den är inte dum. Den är kontrollgruppen.

Rekursiv tecken-chunkning

LangChains RecursiveCharacterTextSplitter delar på en separatorhierarki: först \n\n (stycken), sedan \n (rader), sedan . (meningar), sedan (ord). Varje chunk håller sig under chunk_size samtidigt som den respekterar den största naturliga gräns som ryms.

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)

Separatorlistan är delen som alla konkurrenter utelämnar. Splittern provar \n\n först och faller tillbaka till . bara när ett stycke överskrider chunk_size. Om din Markdown har rubriker, lägg till "## " före "\n\n" så att avsnitten hålls intakta.

Chunk-överlappets aritmetik: vid 512 tokens med 50-token överlapp är steget 462. Ett dokument på 10 000 tokens ger ceil(10000 / 462) = 22 chunks. Totalt embeddade tokens: 22 x 512 = 11 264, vilket innebär att du om-embeddar ungefär 12,6 % av korpuset som överlapp. Det är lagrings- och API-kostnaden för att hindra gränsmeningar från att bli föräldralösa.

Hur fungerar semantisk chunkning, och är det värt kostnaden?

Semantisk chunkning embeddar varje mening, mäter cosinusavståndet mellan intilliggande menings-embeddings och delar där avståndet överskrider en percentiltröskel (vanligtvis den 95:e). Chunks bryts vid ämnesskiften i stället för godtyckliga tokenantal. Greg Kamradts notebook "5 Levels of Text Splitting" skapade denna percentil-brytpunktsmetod, och Chroma-studien benchmarkar hans chunkers vid namn.

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)

Kostnadsmatematiken är delen som ingen lägger fram. Semantisk chunkning embeddar ditt korpus två gånger: en gång för att beräkna meningsavstånd och hitta brytpunkter, en gång för att embedda de resulterande chunksen för indexering. Till OpenAI:s text-embedding-3-large-pris på 0,13 USD per miljon tokens kostar ett korpus på 10 miljoner tokens 1,30 USD att indexera normalt och 2,60 USD med semantisk chunkning. Du betalar dubbelt innan en enda sökfråga körs.

Vad köper det? I Chromas retrieve-5-rader nådde den klusterbaserade semantiska chunkern 89,0 % recall och 6,7 % precision mot 88,5 % och 7,0 % för rekursiv vid samma 200-token storlek. I huvudresultattabellen noterar samma chunker studiens bästa precision, 8,0 %, vid 87,3 % recall. En halv procentenhet hit eller dit i recall, och ett precision-resultat som byter tecken beroende på vilken retrieval-inställning du läser, för dubbla embedding-notan. Vår dom: semantisk chunkning lönar sig på ämnesmässigt breda korpusar (nyhetsarkiv, artikelsamlingar) där fasta gränser rutinmässigt delar mitt i ett ämne. För homogena korpusar (produktdokumentation, en kunskapsbas) ger rekursiv dig 95 % av kvaliteten till halva kostnaden. Om du kör embeddingmodeller lokalt med Ollama sjunker dubbel-embedding-kostnaden till beräkningstid.

Dokumentmedveten chunkning: Markdown, HTML och kod

Strukturmedveten delning använder dokumentets egna gränser (rubriker, listpunkter, funktionsdefinitioner) i stället för teckenantal. En Markdown H2:a är en semantisk gräns som en människa placerade medvetet; en teckensplitter strimlar 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": "..."}

För kod är gränserna AST-noder. LlamaIndex NodeParsers levererar språkmedvetna splittrar som bryter vid funktions- och klassdefinitioner. Den viktiga detaljen: håll import-blocket och den omslutande klasssignaturen fästa vid varje funktions-chunk. En funktion utan sina importer är oembeddbart brus, så ställ båda framför varje chunk så fångar embeddingen vad funktionen gör och vad den beror på.

För kod-RAG specifikt: AST-gränsdelning, importer först, 256–512 tokens per funktion, noll överlapp.

Vad med sen, hierarkisk och agentisk chunkning?

Det här är de avancerade RAG-chunking-strategierna bakom "RAG 2.0"-snacket, och alla tre ligger på 1/10 SERP-täckning.

Sen chunkning

Sen chunkning, introducerad av Günther et al. i "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, september 2024), embeddar först hela dokumentet med en långkontextmodell och poolar sedan token-nivå-embeddings till chunk-vektorer, så att varje chunk bär dokument-omspännande kontext och "den kostar 40 USD/månad" vet vad "den" syftar på. Abstractet hävdar överlägsen retrieval över olika uppgifter men publicerar inga rubriksiffror vi kunde verifiera. Weaviates genomgång förklarar mekaniken och stannar också före en kontrollerad jämförelse. Bevisläge: lovande, okvantifierad.

Hierarkisk (förälder-barn) chunkning

Indexera små chunks (256 tokens) för retrieval; returnera föräldern (1 024 tokens) till generatorn. Retrievern hittar nålen; generatorn får den omgivande höstacken. Du underhåller två indexnivåer och en förälder-barn-mappning. Ingen offentlig benchmark isolerar effekten.

LLM-baserad / agentisk chunkning

Chroma-studiens LLMSemanticChunker använder GPT-4o för att avgöra delningspunkter per dokument: 91,7 % recall (högst) och 3,9 % precision (lägst). Du betalar ett LLM-anrop per dokument vid indexering (ungefär 100 USD för ett korpus på 10 000 dokument) och matar generatorn med mer brus. Reservera den för genuint oregelbundna korpusar: juridiska inlagor, skannade PDF:er utan extraherbara rubriker.

Vilken chunkstorlek passar din embeddingmodell?

Din embeddingmodells max input-tokens är ett kapningstak, inte en rekommendation. En modell som tar emot 8 192 tokens embeddar inte bättre vid 8 192 än vid 512. Kvaliteten försämras av utspädning långt före taket: modellen genomsnittar betydelse över fler tokens och vektorn driver mot korpusets centroid. Rekommendationskolumnen nedan är Techsys tolkning, inte leverantörernas vägledning.

Källor: OpenAI embeddings guide, Cohere embed docs, Voyage embeddings docs, BGE model card.

Mönstret: modeller med ett hårt 512-token-tak (Cohere v3, BGE) kräver chunks en bra bit under 512, eftersom kapningen är tyst. Mata en med 600 så försvinner de sista 88 ur embeddingen utan att något fel loggas. Modeller med stora tak (OpenAI, Voyage, Cohere v4) tolererar större chunks men belönar dem inte. En modells max input-längd är en kapningsgräns, inte en rekommendation.

Para ihop detta med vår rundning av de bästa embeddingmodellerna för RAG, vad ett MTEB-score faktiskt mäter och Voyage, OpenAI och Cohere embeddings sida vid sida innan du bestämmer dig för en modell.

Hur chunkar du dokument på andra språk än engelska?

Tokenizers är inte språkneutrala. Petrov et al. visade i "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) att samma text översatt mellan språk kan skilja sig i tokeniserad längd med upp till 15x. Till och med tecken- och byte-nivå-modeller visar över 4x skillnad för vissa språkpar. En 512-token chunk rymmer mycket mindre betydelse på turkiska, arabiska eller japanska än på engelska.

Här är samma mening tokeniserad med tiktokens cl100k_base-encoding (GPT-4:s 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

Siffrorna genererade med tiktoken cl100k_base, 30 juli 2026.

Praktisk vägledning: vid en fast chunkstorlek på 512 tokens rymmer dina turkiska och japanska chunks ungefär 37 % av betydelsen som dina engelska chunks gör, och dina arabiska chunks ungefär 26 %. Chunka efter teckenantal eller meningsantal per språk, eller höj tokenbudgeten proportionellt (ungefär 1 400 för turkiska, 2 000 för arabiska). CJK-språk har inga ordgränser med blanksteg, så teckensplittrar beter sig annorlunda. Arabisk morfologi packar flera grammatiska markörer i enstaka tokens, vilket blåser upp siffrorna ytterligare.

Ett beslutsträd för att välja 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 snabba recept. Dokument-chattbot: MarkdownHeaderTextSplitter på 512 tokens, noll överlapp, rubriksökväg i metadatan. Kodsökningsassistent: AST-gränsdelning på 256–512 tokens per funktion, importer först. Blandat företagskorpus: routa efter dokumenttyp vid intag och lagra i den vektordatabas du förvarar chunks i med typ-metadata för typspecifik finjustering senare. Den per-dokument-routningen är hela adaptiv chunkning för RAG-applikationer.

Verktyg: LangChain vs LlamaIndex vs Chonkie

Vi säljer inget av dessa; de tre högst rankade sidorna för detta sökord är leverantörsbloggar med produkt-CTA:er.

Källor: LangChain docs, LlamaIndex NodeParsers, Chonkie docs.

Alla tre implementerar samma kärnalgoritmer, så välj utifrån vad din pipeline redan använder. För hela RAG-verktygsstacken utöver splittrar och Qdrant, Chroma och pgvector jämförda för lagring, se våra klusterguider.

Hur Techsy arbetar med chunkning

På RAG-byggen hos kunder börjar Techsy-teamet på 512 tokens med 10 % överlapp och rör inte splittern förrän vi har byggt en eval-mängd på 20–50 frågor från kundens riktiga supportärenden. Eval-mängden kommer först; sedan ändrar vi en variabel i taget: storlek, överlapp, strategi. Inget byte av splitter utan före-och-efter-siffror på samma frågor. Boka en gratis konsultation för ett extra par ögon på din retrieval-pipeline.

Vanliga frågor

Vad är chunkning i RAG?

Chunkning är förbehandlingssteget som delar upp dokument i mindre segment före embedding, så att retrievern kan matcha sökfrågor mot fokuserade passager i stället för hela filer. Delningspunkterna avgör vad ditt system kan och inte kan hitta vid söktillfället.

Vilken är den bästa chunking-strategin för RAG?

För de flesta produktionssystem på allmänna dokument är rekursiv tecken-chunkning på 512 tokens med 10 % överlapp det starkaste standardvalet. I Chromas studie med 472 sökningar (juli 2024) nådde den 88,5 % recall, inom 3,2 procentenheter från den dyraste LLM-baserade metoden, till noll extra kostnad.

Vilken är den optimala chunkstorleken för RAG?

Börja på 512 tokens. Gå ner till 256 om din embeddingmodell har ett tak på 512 input-tokens (Cohere v3, BGE) eller om dina sökfrågor förväntar sig enmeningssvar. Gå upp till 1 024 bara om din eval-mängd visar att flerstyckesvar fragmenteras. Mät alltid mot dina egna frågor.

Hur mycket chunk-överlapp ska jag använda?

10–20 % av chunkstorleken (50–100 tokens vid 512). Överlapp hindrar gränsmeningar från att bli föräldralösa: ett faktum som delas mellan två chunks framstår komplett i åtminstone den ena. Över 20 % om-embeddar du för mycket av korpuset för avtagande nytta. De flesta team landar på 10 % och ser aldrig över det igen.

Är semantisk chunkning bättre än chunkning med fast storlek?

Marginellt, och till dubbla embedding-kostnaden. Chromas benchmark från juli 2024 visade den klusterbaserade semantiska chunkern på 89,0 % recall och 6,7 % precision mot 88,5 % recall och 7,0 % precision för rekursiv vid samma tokenstorlek, med dess bästa precision-resultat på 8,0 % från en annan retrieval-inställning. Värt det för ämnesmässigt breda korpusar; svårt att motivera för homogena dokumentmängder.

Beror chunkstorleken på embeddingmodellen?

Ja. Modeller med ett 512-token tak på input (BGE, Cohere v3) kräver chunks en bra bit under 512 eftersom kapningen är tyst. Modeller med tak på 8 192+ tolererar större chunks men belönar dem inte; embedding-kvaliteten försämras av utspädning före taket. Se parningstabellen ovan för startpunkter per modell.

Hur chunkar jag kod för ett RAG-system?

Dela vid AST-gränser (funktions- och klassdefinitioner) i stället för tokenantal. Håll varje chunk på 256–512 tokens per funktion, ställ filens import-block och den omslutande klasssignaturen först, och använd noll överlapp eftersom funktioner är självständiga enheter. LlamaIndex CodeSplitter och LangChains språkmedvetna splittrar hanterar båda detta.

Vad är sen chunkning?

Sen chunkning embeddar först hela dokumentet med en långkontextmodell och poolar sedan token-nivå-embeddings till chunk-vektorer. Varje chunk-embedding bär dokument-omspännande kontext, vilket löser "vad syftar 'den' på?"-problemet. Introducerad av Günther et al. (arXiv 2409.04701, september 2024). Ingen offentlig head-to-head-benchmark kvantifierar vinsten ännu.

Hur chunkar jag dokument på andra språk än engelska?

Tokenantal är inte språkneutralt. Samma mening tog 2,7x fler tokens på turkiska och japanska än på engelska, och 3,9x på arabiska (tiktoken cl100k_base). En fast 512-token-budget ger tyst icke-engelska chunks mindre betydelse. Chunka efter tecken- eller meningsantal per språk, eller höj budgeten proportionellt.

Hur vet jag om min chunkning faktiskt fungerar?

Bygg en eval-mängd på 20–50 frågor från riktiga användarfrågor innan du rör splittern. Mät hit@5 och MRR mot dina nuvarande chunks. Ändra en variabel (storlek, överlapp, strategi), kör om, jämför. Utan en eval-mängd finjusterar du på känsla. Tjugo frågor räcker för att komma igång.

Sammanfattning

• Börja med rekursiv tecken-chunkning på 512 tokens, 10 % överlapp. Rätt standardval för löpande prosa.
• Över de fyra splitter-familjer som någon har mätt flyttar Chromas 472 sökningar recall ungefär 5 procentenheter och precision flera gånger mer. Finjustera för precision och kostnad först.
• Matcha chunkstorleken mot din embeddingmodells input-tak. En modell med 512-token-tak kräver chunks under 512.
• Berika chunks med kontext (Anthropics fall i felfrekvens från 5,7 till 3,7 %) innan du finjusterar splittern.
• Bygg eval-mängden först. Varje splitter-beslut utan före-och-efter-siffror är en gissning.

För hela pipelinen kring ditt chunkning-val, se bygg en RAG-applikation från början till slut. Väger du fortfarande mellan retrieval och finjustering? RAG eller finjustering reder ut när vardera vinner.