When a RAG system gives a wrong answer, the model is usually blamed. In practice the failure often happens earlier: the right passage never reached the model, because it was split in the wrong place, scored badly or ranked too low.
In 2026 there is no shortage of advice about how to fix this. Semantic chunking, late chunking, contextual retrieval, proposition chunking, agentic search, million-token context windows. Most of it comes from vendors or tutorials. This year, though, several large independent studies tested these ideas head to head, at scale, with proper statistics.
This article pulls that evidence together. It covers:
- Why retrieval still matters when context windows are huge
- Every major chunking method, how it works, what it costs and what the 2024–2026 studies found
- Why the retriever (hybrid search, rerankers, embeddings) usually matters more than the chunker
- How to evaluate your own pipeline
- A practical recipe, plus three small experiments of my own that show the mechanisms on a toy scale
Every number below links to its source. Where a result comes from a vendor, I say so.
1. Long context did not make retrieval obsolete
The obvious question first: if a model can read 1 million tokens, why chunk anything?
Three lines of evidence say retrieval is still worth it.
Quality drops as input grows. Chroma's Context Rot study (July 2025) tested 18 models, including GPT-4.1, Claude 4 and Gemini 2.5. Performance degraded as input length increased, even on simple tasks, and distracting passages made it worse. On LongMemEval, focused prompts of about 300 tokens clearly beat full prompts of about 113K tokens for every model.
Effective context is much shorter than the advertised window. In NoLiMa (ICML 2025), 10 of 12 models that support 128K+ tokens fell below half of their short-context score at just 32K tokens when the question and the answer did not share keywords. GPT-4o dropped from 99.3% to 69.7%.
Long context costs far more. A June 2026 study, "The Token Tax", compared long-context prompting with RAG on 324 matched questions. Long context was more accurate (73.1% vs 65.4%), but it cost about 26 times more per query ($0.118 vs $0.0045) and used about 29 times more input tokens. Their recommendation is a sensible default: use RAG first and escalate to long context only for low-confidence questions.
So the realistic 2026 position is not "RAG or long context". It is "retrieve well, then decide how much context the model really needs". Retrieving well starts with the chunk.
2. What a chunk is for
A chunk has two jobs at the same time:
- Unit of retrieval: it is what gets scored against the question. Smaller chunks give sharper matches.
- Unit of context: it is what the model reads. Larger chunks keep the surrounding meaning.
Every chunking method is a different trade-off between these two jobs. A useful way to see the problem is Chroma's chunking evaluation (2024), which measured not only whether the relevant tokens were retrieved (recall) but also how many irrelevant tokens came with them (precision and IoU). With similar recall, strategies differed by about five times in wasted tokens. Recall alone hides that cost.
3. The chunking menu in 2026
3.1 Fixed-size and recursive splitting
How it works: cut every N tokens or characters, optionally with an overlap. Recursive splitters try paragraph breaks first, then sentences, then words, so they only cut mid-sentence as a last resort.
Evidence: the simplest method keeps winning.
- The largest study so far, Caspari et al., accepted at CIKM'26, compared 8 methods on corpora of up to 10 million documents with three modern embedders (Qwen3-Embedding-0.6B, EmbeddingGemma-300M, Snowflake Arctic). Their conclusion: expensive methods "rarely" beat simple ones consistently, and token-based chunking is a strong default at scale.
- Śmigielski et al. (May 2026) reported Accuracy@5 of 89.36 for recursive semantic chunking and 87.71 for plain fixed-size chunking. Fixed-size chunking took under a second; the proposition-based method took 15 hours.
- One warning from Shaukat et al. (March 2026): fixed character chunking was the worst of 36 strategies (nDCG@5 of 0.244). Token-aware and structure-aware splitting is fine; blindly cutting characters is not.
Use it when: you need a baseline, a large corpus or predictable cost. That is most projects.
3.2 Sentence and paragraph grouping
How it works: split into sentences or paragraphs, then pack whole units until a size limit is reached.
Evidence: in Shaukat et al.'s 1,080-configuration study (36 strategies × 6 domains × 5 embedders), paragraph group chunking ranked first (nDCG@5 ≈ 0.459, Hit@5 ≈ 59%). They also found that a stronger embedding model does not make up for bad segmentation. The gains from good chunking and from a good embedder add up.
Use it when: your documents have real paragraphs, for example articles, reports and documentation.
3.3 Semantic chunking
How it works: embed each sentence and start a new chunk where the similarity between neighbouring sentences drops.
Evidence: weaker than its popularity suggests.
- Qu, Bao and Tu (Vectara), NAACL 2025 Findings: "the computational costs associated with semantic chunking are not justified by consistent performance gains." On normal documents, fixed-size chunks won (HotpotQA F1@5: 90.59 vs 87.37 for breakpoint-based semantic chunking). Semantic chunking only won on artificially "stitched" documents, where unrelated texts had been glued together.
- Kreileder et al. (July 2026) found the same on academic theses: cluster-based semantic chunking did not beat fixed or recursive chunking.
Use it when: your documents really do mix unrelated topics without clear structure. Otherwise, test it against a recursive splitter before paying for it.
3.4 Late chunking
How it works: Jina's late chunking runs the whole document through a long-context embedding model first, then averages the token embeddings inside each chunk's boundaries. Each chunk vector therefore "knows" about the rest of the document.
Evidence: helpful on long documents in Jina's own tests (for example NFCorpus nDCG@10 from 23.46 to 29.98), but at scale it was weaker. In the CIKM'26 study, late chunking on a 1M-document corpus scored Recall@100 of 50.54 against 57.09 for plain token chunking, and it needs a lot of memory.
Use it when: you have long, coherent documents and a long-context embedder, and you have measured a gain on your own data.
3.5 Contextual retrieval and contextual embeddings
How it works: Anthropic's contextual retrieval (2024) asks an LLM to write 50–100 tokens explaining where each chunk sits in its document, and prepends that to the chunk before embedding and BM25 indexing.
Evidence:
- In Anthropic's tests, the top-20 retrieval failure rate fell by 35% with contextual embeddings, 49% when contextual BM25 was added, and 67% when a reranker was added as well (5.7% → 1.9%). With prompt caching, it costs about $1.02 per million document tokens.
- The 2026 independent evidence is more cautious. The CIKM'26 study found the cost was "rarely matched by retrieval gains", and contextual chunking processed only 0.26 documents per second at 100 generated tokens per second. On the other hand, in a financial benchmark (below), "contextual hybrid" was the best method without a reranker.
- A newer alternative skips the LLM call: voyage-context-3 (July 2025) embeds each chunk together with its document context in one model. Voyage reports large gains over Anthropic's method and over late chunking; these are vendor numbers.
Cheap version that works: the CIKM'26 authors found that simply prepending the document title ("enriched title") was the most reliable low-cost improvement. Docling's HybridChunker does the same with contextualize(), which prepends the title and section headings.
3.6 Proposition chunking
How it works: an LLM rewrites the text into short, self-contained factual statements, and each one becomes a chunk.
Evidence: the original Dense X Retrieval paper reported strong gains, but in the 2026 head-to-head by Śmigielski et al. it was the weakest and slowest method (Accuracy@5 69.10, about 15 hours of processing).
Use it when: you have a small, high-value knowledge base of short facts and can afford the LLM pass.
3.7 Hierarchical chunks (small-to-big, parent–child)
How it works: retrieve small chunks for precise matching, then hand the model their larger parent section. HiChunk (ACL 2026) builds a multi-level hierarchy and merges child chunks into parents within a token budget.
HiChunk's most useful point is about evaluation: most benchmarks have only about 1.7 evidence sentences per question, so they cannot tell chunkers apart. If your evaluation questions each need one sentence, every chunker looks the same.
3.8 Layout-aware chunking for PDFs
Real documents are not plain text. Tables, headings and page structure matter.
- In Unstructured's FinanceBench study, chunks based on document elements (titles, tables, lists) improved question-answering accuracy from 48.23% to 53.19% compared with 512-token chunks.
- NVIDIA's 2025 chunking study found that page-level chunks had the best average accuracy (0.648) and the lowest variance across five datasets. Factoid questions did best with 256–512 token chunks; analytical questions did best with 1,024 tokens or whole pages.
- Docling's HybridChunker can repeat table headers in each chunk and should use the same tokenizer as your embedding model.
3.9 Visual retrieval: skipping text extraction
For slide decks, scanned reports and pages full of charts, you can embed page images directly with ColPali-style models. On ViDoRe V3 (January 2026: about 26K pages, 3,099 human-verified queries in 6 languages including German), the best visual retriever scored 59.8 nDCG@10 against 51.0 for the best text-based retriever. A text reranker still added 13.2 points to the text pipeline, so reranking matters there too.
4. What the large studies agree on
| Study | Scale | Main finding |
|---|---|---|
| Chroma 2024 | 472 queries, 5 corpora | Strategies differ by up to 9% recall and ~5× in wasted tokens; 200-token recursive splitting was a strong choice |
| Vectara, NAACL 2025 | Several QA datasets | Semantic chunking's cost not justified on normal documents |
| NVIDIA 2025 | 5 datasets | Page-level chunks most accurate and most stable; chunk size should follow query type |
| Shaukat et al. 2026 | 1,080 configurations | Paragraph grouping best; character cutting worst; chunker and embedder gains add up |
| Śmigielski et al. 2026 | Cost vs quality | Recursive and fixed-size give the best balance; LLM-based methods slow and fragile |
| Caspari et al., CIKM'26 | Up to 10M documents | Complex chunking rarely wins; token chunking + title is the default |
The pattern is consistent: structure-aware, size-limited chunks plus a little cheap context (title, headings) get you most of the way. Expensive chunkers can win on specific datasets, but the gains shrink as the corpus grows and they cost a lot of compute.
5. A small experiment: watching chunking fail
In my lab repository, applied-llm-lab, I write each retrieval component from scratch with tests. Three experiments show the mechanisms behind the studies above on a toy scale. This is a tiny, five-question set, so it illustrates the mechanism; it is not a benchmark.
Experiment 1: three chunkers on the same text. At almost the same chunk size, fixed-size chunking cut 3 of 4 chunks mid-sentence. Sentence packing cut none.
def by_sentence(text: str, max_chars: int = 200) -> list[str]:
"""Pack whole sentences into chunks up to max_chars."""
sentences = [s.strip() for s in re.split(r"(?<=[.!?])\s+", text) if s.strip()]
chunks, current = [], ""
for s in sentences:
if current and len(current) + 1 + len(s) > max_chars:
chunks.append(current)
current = s
else:
current = f"{current} {s}".strip()
if current:
chunks.append(current)
return chunks
Experiment 2: BM25 from scratch. I implemented Okapi BM25 (k1 = 1.5, b = 0.75) and asked five questions, each with the exact fact the top chunk must contain in full.
def score(self, query: str, i: int) -> float:
norm = self.k1 * (1 - self.b + self.b * self.len[i] / self.avgdl)
return sum(self.idf[t] * f * (self.k1 + 1) / (f + norm)
for t in tokenize(query) if (f := self.tf[i].get(t, 0)))
Experiment 3: TF-IDF cosine search with NumPy, plus three paraphrased questions that ask for the same facts in different words.
| Chunking | BM25, original questions | Cosine, original questions | BM25, paraphrased | Cosine, paraphrased |
|---|---|---|---|---|
| Fixed size (120 chars) | 2 / 5 | 2 / 5 | 0 / 3 | 1 / 3 |
| Fixed size + 30 overlap | 4 / 5 | 4 / 5 | 0 / 3 | 0 / 3 |
| Sentence packing (160) | 5 / 5 | 5 / 5 | 0 / 3 | 0 / 3 |
Three lessons, each matching the large studies:
- Chunking decided more than the scoring formula. BM25 and cosine picked the same top chunk in 14 of 15 cases. Changing the chunker moved the score from 2/5 to 5/5. This is Shaukat et al.'s finding in miniature.
- Overlap is a patch. It recovered most of the gap but added a chunk to index. At scale, that means more storage and more embedding cost.
- Lexical methods cannot handle paraphrases. Both failed on every reworded question (the single "hit" was an accident: the chunker cut "con|text" and the leftover "text" matched the question). That gap is why the next section matters.
6. The retriever matters more than the chunker
6.1 Hybrid search plus a reranker
The clearest 2026 result comes from Akarsu et al. (April 2026), who benchmarked retrieval strategies on T2-RAGBench: 23,088 questions over 7,318 financial documents mixing text and tables.
| Method | Recall@5 | nDCG@10 |
|---|---|---|
| BM25 | 0.644 | 0.515 |
| Dense (text-embedding-3-large) | 0.587 | 0.466 |
| HyDE | 0.544 | 0.433 |
| Multi-query + RRF | 0.640 | 0.506 |
| Hybrid (BM25 + dense, RRF) | 0.695 | 0.551 |
| Contextual hybrid | 0.717 | 0.571 |
| Hybrid + reranker | 0.816 | 0.683 |
Three things stand out:
- BM25 beat a strong dense model. On financial text full of exact terms and numbers, keyword matching still wins.
- HyDE hurt. Generating a hypothetical answer and searching with it made retrieval worse.
- Hybrid plus reranking was best by a wide margin: Recall@5 rose by about 23 points over dense retrieval alone and about 17 points over BM25.
My third experiment explains why hybrid helps: lexical search catches exact terms, dense embeddings catch paraphrases, and each covers the other's blind spot. Reciprocal rank fusion (RRF) merges the two ranked lists without needing to calibrate their scores.
6.2 Why one vector per chunk has a ceiling
Google DeepMind's LIMIT paper (ICLR 2026) showed a theoretical limit: the embedding dimension bounds which sets of top-k documents a single-vector retriever can return for any query. Even state-of-the-art MTEB models scored under 20 Recall@100 on a deliberately simple dataset built around that limit. The practical conclusion is to add a stage that is not a single vector: sparse BM25, multi-vector late interaction, or a cross-encoder reranker.
6.3 Late interaction is back
ColBERT-style models keep one vector per token and compare query and document tokens individually. In March 2026, LightOn reported that its 149M-parameter Reason-ModernColBERT reached 87.59% accuracy on BrowseComp-Plus with GPT-5, against 80.00% for the previous best, while needing fewer search calls. It also beat an 8B dense embedder about 54 times its size. These are vendor numbers, but they fit the LIMIT theory.
6.4 Rerankers in 2026
A reranker reads the question and each candidate chunk together and scores how well they match. It is slower than vector search, so you use it on the top 50–150 candidates only. Anthropic recommends retrieving 150 and reranking down to 20.
The community reranker-eval ranking currently puts zerank-2, Cohere Rerank 4 Pro, zerank-1 and Voyage rerank-2.5 at the top, with Qwen3-Reranker-8B and BGE-reranker-v2-m3 as strong open-weight options. Cohere's Rerank 4 (December 2025) raised its context to 32K tokens, so it can score long chunks.
6.5 Embedding models, and a warning about leaderboards
Strong options in 2026 include the Qwen3-Embedding family (0.6B to 8B, 32K context), Voyage 4 (whose models share one embedding space, so you can switch models without re-indexing), jina-embeddings-v5 and the multimodal EmbeddingGemma 2 (October 2026).
For German documents, the community model most-embed-de (September 2026) reports first place on the German MTEB retrieval tasks; these are the author's own numbers. ViDoRe V3 found a 2–3 point penalty when queries and documents are in different languages, so test with real German queries if you serve German users.
The warning: Chroma found that MTEB rankings did not transfer to a real-world dataset. A model that ranked higher on MTEB scored lower on their production data (Recall@10 of 0.532 vs 0.602). Always test the top two or three candidates on your own questions.
7. Agentic retrieval: where it fits
Agents now search iteratively: they run a query, read results, refine the query and search again. Anthropic's context engineering guidance describes "just-in-time" retrieval through tools, combined with some context loaded up front.
Two findings keep this grounded:
- The retriever still sets the ceiling. On BrowseComp-Plus, the same agent (GPT-5) scored 55.9% with BM25 and 70.1% with Qwen3-Embedding-8B, and needed fewer searches with the better retriever.
- Query rewriting is not free accuracy. In the T2-RAGBench study, HyDE reduced recall and multi-query fusion only matched plain BM25.
An agent multiplies the quality of its search tool. It does not replace it.
8. How to evaluate your own pipeline
Metrics:
- Hit rate@k / Recall@k: did the needed chunk appear in the top k?
- MRR: how high was the first correct chunk?
- nDCG@k: rewards correct chunks near the top, with graded relevance.
- Token precision / IoU: how much irrelevant text came along (from the Chroma method). Useful when context cost matters.
Build a test set from your own documents. Chroma's generative benchmarking generates realistic questions from your corpus and filters them; after five iterations their LLM judge agreed with humans 75.2% of the time, up from 46%. Even 50–100 good questions beat any public leaderboard for your use case.
Make questions that need real evidence. Following HiChunk's point, include questions whose answers span several sentences or a table, or every chunker will look the same.
Be careful with LLM-judged scores. RAGAS v0.4 (December 2025) changed its API (@experiment() replaces evaluate()), and the 2026 thesis study found its faithfulness score unreliable. Use retrieval metrics with a fixed answer key wherever you can.
9. A practical recipe for late 2026
- Start simple. Recursive or paragraph-aware chunks of about 256–512 tokens, small overlap, same tokenizer as the embedder.
- Add cheap context. Prepend the document title and section headings to each chunk.
- Respect structure. For PDFs, use a layout-aware parser (for example Docling) and keep tables whole with their headers. Consider page-level chunks for reports.
- Use hybrid retrieval. BM25 + dense embeddings, merged with RRF.
- Rerank. Retrieve 50–150 candidates and rerank to the top 5–20.
- Evaluate on your own questions with Recall@k, MRR and nDCG before changing anything expensive.
- Only then try advanced chunking (contextual, late, semantic, propositions), and keep it only if it beats step 6 on your data at a cost you accept.
- Use long context selectively, for questions where retrieval confidence is low.
10. What I'm testing next
Next in the lab: hit rate and MRR on a larger question set, learned embeddings against TF-IDF on the paraphrased questions, hybrid search with RRF, and a cross-encoder reranker on top. I'll publish the numbers as they come in, including the ones that don't go my way.
Code and tests: github.com/Hussnainoffical/applied-llm-lab
I'm Muhammad Hussnain Jamil, an applied LLM and AI automation engineer and co-author of published research on multi-agent LLM systems. I'm learning German (A2) and open to AI roles in Germany. Portfolio
Sources
- Caspari et al., "When Is Complex Chunking Worth It?", CIKM'26: https://arxiv.org/pdf/2608.16586
- Śmigielski et al., 2026: https://arxiv.org/html/2606.00881v1
- Shaukat et al., 2026: https://arxiv.org/html/2603.06976
- Qu, Bao and Tu (Vectara), NAACL 2025 Findings: https://arxiv.org/html/2410.13070v1
- Kreileder et al., 2026: https://arxiv.org/abs/2607.01852
- Chroma, Evaluating Chunking: https://www.trychroma.com/research/evaluating-chunking
- NVIDIA, Finding the Best Chunking Strategy: https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/
- Anthropic, Contextual Retrieval: https://www.anthropic.com/news/contextual-retrieval
- Jina, Late Chunking: https://jina.ai/news/late-chunking-in-long-context-embedding-models/
- Voyage/MongoDB, voyage-context-3: https://www.mongodb.com/company/blog/product-release-announcements/voyage-context-3-focused-chunk-level-details-global-document-context
- Chen et al., Dense X Retrieval: https://arxiv.org/abs/2312.06648
- HiChunk, ACL 2026: https://arxiv.org/html/2509.11552v2
- Jimeno Yepes et al., element-based chunking (FinanceBench): https://arxiv.org/html/2402.05131v3
- Docling HybridChunker: https://docling-project.github.io/docling/_generated/examples/hybrid_chunking/
- ViDoRe V3: https://arxiv.org/html/2601.08620v1
- Akarsu et al., From BM25 to Corrective RAG (T2-RAGBench): https://arxiv.org/html/2604.01733v1
- LIMIT, Google DeepMind: https://arxiv.org/html/2508.21038v1
- LightOn, Reason-ModernColBERT: https://lighton.ai/lighton-blogs/the-bloated-retriever-era-is-over
- Agentset reranker-eval: https://github.com/agentset-ai/reranker-eval
- Qwen3-Embedding: https://huggingface.co/Qwen/Qwen3-Embedding-4B
- Voyage 4: https://blog.voyageai.com/2026/01/15/new-models-and-expanded-availability/
- most-embed-de: https://huggingface.co/blog/malteos/most-embed-de-german-embedding-model
- Chroma, Context Rot: https://trychroma.com/research/context-rot
- NoLiMa: https://huggingface.co/papers/2502.05167
- The Token Tax: https://arxiv.org/html/2606.20898v1
- Anthropic, Effective Context Engineering: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- BrowseComp-Plus: https://arxiv.org/abs/2508.06600
- Chroma, Generative Benchmarking: https://trychroma.com/research/generative-benchmarking
- RAGAS v0.4 migration guide: https://docs.ragas.io/en/latest/howtos/migrations/migrate_from_v03_to_v04/
Top comments (0)