RAG Chunking Strategies: The 2026 Benchmark Guide
Quick answer: Recursive character splitting at 512 tokens with 50 to 100 tokens of overlap is the benchmark-validated default for most RAG applications. It scored 69% accuracy in the largest real-document test of 2026, requires zero model calls, and outperformed every more expensive alternative. The rest of this guide covers when to deviate from that default, and how.
You need a basic understanding of RAG pipelines and Python. Familiarity with LangChain or LlamaIndex helps but is not required. If you are new to the retrieval landscape, our advanced RAG methods overview covers where chunking fits in.
Why Chunking Strategy Matters More Than Your Embedding Model
Documents are too long for embedding models and context windows, so RAG systems split them into chunks, embed each chunk, and retrieve the most relevant ones at query time. Most teams tune their embedding model obsessively and ignore how the documents were split.
That is backwards. A Vectara study published at NAACL 2025 (arXiv:2410.13070) tested 25 chunking configurations with 48 embedding models and found that chunking configuration had as much or more influence on retrieval quality as the choice of embedding model. In Chroma's evaluation, the gap between the best and worst chunking strategy on the same corpus reached 9% in recall.
Two failure modes dominate. Chunks that are too small lose context. In the FloTorch 2026 benchmark, semantic chunking produced fragments averaging 43 tokens, and those fragments scored only 54% accuracy on end-to-end questions. Chunks that are too large dilute relevance. A January 2026 systematic analysis identified a "context cliff" around 2,500 tokens where response quality drops (Firecrawl).
The practical starting range is 256 to 512 tokens with 10 to 25% overlap. Microsoft Azure recommends 512 tokens with 25% overlap (128 tokens) as a starting point, using BERT tokens rather than character counts. Arize AI found chunk sizes of 300 to 500 with K=4 retrieval offer the best speed-quality tradeoff.
For teams weighing whether long-context LLMs can replace RAG, chunking remains essential even with 128K-token models. Focused retrieval consistently beats full-document stuffing on precision. When picking an LLM for RAG, model selection and chunking strategy interact. Tuning one without the other leaves performance on the table.
What Four Independent Benchmarks Found (2024 to 2026)
Before looking at the numbers: each study measured something different, which explains why the results sometimes look contradictory. they measured different things, which explains why the results sometimes look contradictory.
Vecta / FloTorch, February 2026 Corpus: 50 academic papers, 905,746 tokens, 10+ disciplines, 3 to 112 pages each Embedding: text-embedding-3-small | Vector DB: ChromaDB | Generator: gemini-2.5-flash-lite Measured: End-to-end answer accuracy (did the LLM produce the correct answer, not just retrieve a relevant chunk) Key design: Equal context budget per strategy. Each strategy got the same ~2,000 tokens of context in the prompt, regardless of individual chunk size. This eliminates the unfair advantage larger chunks would otherwise get.
NVIDIA, 2024 Corpus: 5 datasets including FinanceBench (financial documents) Measured: NV Answer Accuracy via RAGAS across document types and chunk sizes Key design: Tested chunk size ranges from 128 to 2,048 tokens across different query types (factoid vs. analytical).
Chroma Research Corpus: General text, multiple domains Measured: Token-level retrieval recall: how much of the relevant answer text the retriever actually surfaces Key design: Isolated retrieval quality only, independent of downstream generation.
Superlinked VectorHub Corpus: HotpotQA and QuAC (multi-hop and conversational QA benchmarks) Measured: MRR (Mean Reciprocal Rank) and Recall@10 Key design: Evaluated chunking strategy combined with retrieval model. Tested which chunker + retriever pairing performs best end-to-end.
Consolidated results
| Strategy | FloTorch 2026 (Answer Accuracy) | NVIDIA 2024 (Answer Accuracy) | Chroma (Retrieval Recall) | Superlinked (MRR) |
|---|---|---|---|---|
| Recursive 512 tokens | 69% | -- | -- | -- |
| Fixed-size 512 tokens | 67% | -- | -- | -- |
| Page-level | -- | 0.648 (best) | -- | -- |
| 1,024-token (financial docs) | -- | 57.9% | -- | -- |
| Sentence-level + ColBERT v2 | -- | -- | -- | 0.3123 (best) |
| Semantic (LLMSemanticChunker) | 54% | -- | 91.9% (best) | -- |
| Semantic (ClusterSemantic, 400t) | -- | -- | 91.3% | -- |
| Proposition-based / agentic | Among worst | -- | -- | -- |
Why semantic chunking scores 91.9% in one study and 54% in another
Chroma measured retrieval recall: how well chunks surface relevant text. FloTorch measured answer accuracy: whether the LLM produced the right answer.
Semantic chunking in FloTorch produced fragments averaging 43 tokens. Those tiny fragments retrieved cleanly but gave the LLM too little context to generate a correct answer. High retrieval recall, wrong answer. The two studies are not contradicting each other. They are measuring different failure points in the same pipeline.
This is why end-to-end accuracy benchmarks matter more than retrieval-only benchmarks when evaluating chunking for production RAG. A chunk that retrieves well but answers badly is still a bad chunk.
The Vectara NAACL 2025 peer-reviewed study (arXiv:2410.13070) adds a third data point: on realistic document sets, fixed-size chunking consistently outperformed semantic chunking across document retrieval, evidence retrieval, and answer generation tasks. The computational overhead of semantic methods was not justified by the results.
Bottom line from the data: Recursive character splitting is the safest default. Page-level chunking wins for paginated financial PDFs. Semantic chunking can win on retrieval recall but needs a minimum chunk size floor to be useful end-to-end.
Seven Chunking Strategies: How Each One Works
1. Fixed-Size Chunking
Split by character or token count at fixed intervals. Overlap between consecutive chunks prevents information loss at boundaries.
When it works: Homogeneous documents like logs, data exports, and baseline testing. Fast and completely predictable.
When it fails: Documents with meaningful structure. A table that crosses a chunk boundary is useless to retrieve. A paragraph split mid-sentence loses its conclusion.
Results: 67% in FloTorch benchmark, 2 percentage points behind recursive splitting.
Implementation: LangChain CharacterTextSplitter.
from langchain_text_splitters import CharacterTextSplitter
splitter = CharacterTextSplitter(
chunk_size=512,
chunk_overlap=50,
separator="\n"
)
chunks = splitter.split_text(text)
2. Recursive Character Splitting
Uses a hierarchy of separators. The algorithm tries paragraph breaks first (\n\n). If the result exceeds the target size, it falls back to single newlines, then spaces, then individual characters. This means the split always lands at the most natural boundary the chunk size allows.
When it works: Almost every general-purpose RAG application. Articles, research papers, documentation, support content.
When it fails: Short documents that are already self-contained. Splitting a 200-word FAQ answer into three 70-word fragments is objectively worse than not splitting at all.
Results: 69% accuracy in FloTorch benchmark across 50 academic papers totaling 905,746 tokens.
Implementation: LangChain RecursiveCharacterTextSplitter (v1.1.1, Feb 2026), Chonkie RecursiveChunker.
from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=50, # ~10% overlap
length_function=len,
separators=["\n\n", "\n", " ", ""]
)
chunks = splitter.split_text(text)
print(f"Chunks: {len(chunks)}, first chunk: {len(chunks[0])} chars")
Note: chunk_size here uses character count via len(). For token-based sizing, replace length_function with a tokenizer. The numbers in the FloTorch benchmark are token-based, so a 512-character chunk is smaller than a 512-token chunk on dense academic text.
3. Sentence-Level Chunking
Splits at natural sentence boundaries using NLP sentence detection (spaCy, NLTK punkt tokenizer), then groups consecutive sentences until a target chunk size is reached.
When it works: Well-structured prose. Technical articles and documentation with clean sentence structure. Pairs particularly well with advanced retrieval models.
When it fails: Analytical or multi-hop queries that require multi-paragraph context. A single sentence almost never contains enough information to answer "explain how X affects Y in the context of Z."
Results: ColBERT v2 + SentenceSplitter was the top-performing combination in Superlinked's evaluation, with a roughly 10% MRR advantage over the second-best method.
Implementation: LlamaIndex SentenceSplitter (default: 1024 tokens, 20 overlap).
from llama_index.core.node_parser import SentenceSplitter
from llama_index.core import Document
splitter = SentenceSplitter(
chunk_size=512,
chunk_overlap=50,
)
document = Document(text=text)
nodes = splitter.get_nodes_from_documents([document])
print(f"Chunks: {len(nodes)}")
4. Document-Aware / Structure-Aware Chunking
Uses the document's native structure as split points. Different formats need different parsers: Markdown splits on headers, HTML splits on <h1> through <h6> tags, code splits on function or class definitions, PDFs split on page boundaries.
When it works: PDFs and financial reports (page-level). Markdown documentation (header-based). Codebases (function-level). Any document where the author's structural choices carry semantic meaning.
When it fails: Documents where page breaks are arbitrary, such as text pasted into a PDF with auto-pagination. Page-level chunking on those documents creates chunks with no relationship to topic boundaries.
Results: Page-level chunking won NVIDIA's benchmark with 0.648 accuracy and the lowest variance across five datasets.
Implementation: LangChain MarkdownHeaderTextSplitter, HTMLHeaderTextSplitter, PythonCodeTextSplitter; Unstructured.io chunk_by_title, chunk_by_page.
from langchain_text_splitters import MarkdownHeaderTextSplitter
headers_to_split_on = [
("#", "h1"),
("##", "h2"),
("###", "h3"),
]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on)
chunks = splitter.split_text(markdown_text)
# Each chunk now carries its header as metadata
for chunk in chunks[:3]:
print(chunk.metadata, chunk.page_content[:100])
5. Semantic Chunking
Three-step process: split text into sentences, generate an embedding for each sentence, compute cosine similarity between consecutive sentence embeddings. Place chunk boundaries where similarity drops below a threshold, indicating a topic shift.
When it works: Multi-topic documents with clear topic transitions, where you have corpus-specific evidence that it outperforms simpler methods, and where embedding cost at ingestion is acceptable.
When it fails: Homogeneous or single-topic corpora. Constrained compute budgets. Any scenario where chunk size is not explicitly floored, since semantic chunking tends to produce very small fragments that hurt downstream answer quality.
Results: 91.9% retrieval recall in Chroma's test. 54% end-to-end accuracy in FloTorch (due to 43-token average fragment size). Vectara's NAACL 2025 peer-reviewed study found fixed-size consistently outperformed it on realistic datasets.
Implementation: LlamaIndex SemanticSplitterNodeParser, Chonkie SemanticChunker.
from chonkie import SemanticChunker
chunker = SemanticChunker(
embedding_model="sentence-transformers/all-MiniLM-L6-v2",
chunk_size=512,
similarity_threshold=0.5, # Lower = more splits
# Always set a minimum chunk size to avoid the fragment problem
min_chunk_size=200,
)
chunks = chunker.chunk(text)
print(f"Semantic chunks: {len(chunks)}")
for chunk in chunks[:3]:
print(f" {chunk.token_count} tokens: {chunk.text[:80]}...")
Setting min_chunk_size is not optional if you use this in production. The FloTorch benchmark's 54% failure came from chunks averaging 43 tokens. A floor of 200 to 400 tokens prevents that.
6. LLM-Based Chunking
Sends document content to an LLM with a prompt instructing it to identify semantically complete units of information. The LLM reads the document and returns boundaries based on meaning rather than character counts or sentence breaks.
When it works: High-value documents where ingestion quality justifies the cost. Legal contracts, technical specifications, and complex policy documents where boundaries require genuine understanding of content.
When it fails: Large corpora at scale. The cost per document is orders of magnitude higher than any other method. For a 10,000-document knowledge base, LLM-based chunking at current API rates is not economically viable unless the documents are short and high-value.
Trade-off summary: Highest semantic quality, highest cost, slowest ingestion. Treat it as a premium option for specific document types, not a general-purpose strategy.
from langchain.text_splitter import TextSplitter
from openai import OpenAI
client = OpenAI()
def llm_chunk(text: str) -> list[str]:
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{
"role": "user",
"content": f"""Split this text into semantically complete chunks.
Each chunk should contain one complete idea or topic.
Return only a JSON array of strings, no other text.
Text:
{text}"""
}]
)
import json
return json.loads(response.choices[0].message.content)
chunks = llm_chunk(short_document)
Use this selectively. A practical pattern is routing by document type: LLM-based for high-value contracts and policy documents, recursive for everything else.
7. Late Chunking
Late chunking flips the standard order. Instead of chunking first and then embedding, it embeds the full document first (preserving global context in the token representations), then splits the resulting embeddings into smaller chunks. Each chunk's embedding carries awareness of the surrounding document, including pronouns, cross-references, and headers that would be missing from early-chunked embeddings.
When it works: Documents with heavy cross-references, anaphora, or where chunks only make sense in context of surrounding sections. Technical manuals, legal documents, and academic papers with "as described in section 3" style references.
When it fails: Documents that exceed the embedding model's context window. Late chunking requires embedding the full document at once, which is impossible if the document is longer than the model supports.
Implementation: Requires a long-context embedding model. Chonkie LateChunker supports this with Jina Embeddings v3 and similar models.
from chonkie import LateChunker
from sentence_transformers import SentenceTransformer
# Use a long-context embedding model
model = SentenceTransformer("jinaai/jina-embeddings-v3", trust_remote_code=True)
chunker = LateChunker(
embedding_model=model,
chunk_size=512,
)
chunks = chunker.chunk(text)
# Each chunk.embedding reflects full-document context
Late chunking is a meaningful upgrade for documents with dense cross-references. For straightforward prose, the improvement over recursive splitting is marginal and the model requirements are higher.
Python Tutorial: Building a Complete RAG Pipeline with Configurable Chunking
This example shows all seven strategies wired into a single evaluation harness, so you can swap and measure.
# rag_chunking_eval.py
from langchain_text_splitters import (
RecursiveCharacterTextSplitter,
CharacterTextSplitter,
MarkdownHeaderTextSplitter,
)
from llama_index.core.node_parser import SentenceSplitter
from llama_index.core import Document
from chonkie import SemanticChunker, RecursiveChunker
import json
def get_chunker(strategy: str, chunk_size: int = 512, overlap: int = 50):
"""Return configured chunker for the given strategy."""
if strategy == "fixed":
return CharacterTextSplitter(
chunk_size=chunk_size,
chunk_overlap=overlap,
separator="\n"
)
elif strategy == "recursive":
return RecursiveCharacterTextSplitter(
chunk_size=chunk_size,
chunk_overlap=overlap,
length_function=len,
separators=["\n\n", "\n", " ", ""]
)
elif strategy == "sentence":
return SentenceSplitter(
chunk_size=chunk_size,
chunk_overlap=overlap,
)
elif strategy == "semantic":
return SemanticChunker(
embedding_model="sentence-transformers/all-MiniLM-L6-v2",
chunk_size=chunk_size,
min_chunk_size=200, # Prevent tiny fragments
similarity_threshold=0.5,
)
else:
raise ValueError(f"Unknown strategy: {strategy}")
def chunk_document(text: str, strategy: str, chunk_size: int = 512, overlap: int = 50):
chunker = get_chunker(strategy, chunk_size, overlap)
if strategy == "sentence":
doc = Document(text=text)
nodes = chunker.get_nodes_from_documents([doc])
return [n.text for n in nodes]
elif strategy == "semantic":
return [c.text for c in chunker.chunk(text)]
else:
return chunker.split_text(text)
# Quick comparison across strategies
with open("document.txt", "r") as f:
text = f.read()
strategies = ["fixed", "recursive", "sentence", "semantic"]
for strategy in strategies:
chunks = chunk_document(text, strategy)
sizes = [len(c.split()) for c in chunks]
print(f"{strategy:12} | chunks: {len(chunks):4} | "
f"avg size: {sum(sizes)/len(sizes):6.0f} words | "
f"min: {min(sizes):4} | max: {max(sizes):4}")
Run this on your actual documents before picking a strategy. The aggregate stats reveal problems like the tiny-fragment issue that caused semantic chunking to fail in the FloTorch benchmark.
Tuning Chunk Size and Overlap
Chunk size depends on query type. NVIDIA's benchmark found factoid queries work well at 256 to 512 tokens, while analytical and multi-hop queries benefit from 512 to 1,024 tokens.
Start overlap at 10 to 20% of chunk size. For 512 tokens, that is 50 to 100 tokens. Increase to 25% per Microsoft Azure's recommendation if retrieval recall is low. One January 2026 study using SPLADE retrieval found overlap provided no measurable benefit for sparse retrieval methods, so this is worth testing rather than assuming.
If building and tuning chunking pipelines is not where your team adds value, Prem Platform deploys RAG pipelines in your cloud account with configurable chunking and built-in document processing. Your data stays in your VPC, with no external API calls required. See the private RAG deployment guide for architecture details.
Real-World Results: Three Domains Where Chunking Choice Changes Outcomes
Customer Support and Knowledge Bases
Support KB articles are typically short and focused. A 300-word answer to "how do I reset my password" does not need to be split at all. Splitting it into three 100-word fragments guarantees that at least one fragment is missing context.
For short, focused support content, use no chunking or sentence-level splitting with a high minimum size. The Firecrawl analysis confirms chunking can actively hurt retrieval on short, focused documents.
For multi-document KB setups where articles vary widely in depth and length, header-based splitting on the article's section structure preserves intended answer boundaries better than character-count splitting.
Financial Documents
NVIDIA found 1,024-token chunks produced 57.9% accuracy on FinanceBench, outperforming smaller chunk sizes. Page-level chunking also performed well on paginated financial PDFs.
Financial documents benefit from larger chunks because tables and numerical context need to stay together. A balance sheet split mid-row becomes two chunks that each answer nothing. Page-level splitting respects the document's natural unit of information.
Academic Papers
The FloTorch benchmark tested 50 papers totaling 905,746 tokens, ranging from 3 to 112 pages each. Recursive splitting at 512 tokens won at 69%. Academic papers have well-defined section structure but dense content per paragraph, and recursive splitting captures that paragraph-level structure without the ingestion cost of semantic analysis.
When NOT to Use Each Strategy
| Strategy | Avoid When | Failure Mode | Use Instead |
|---|---|---|---|
| Fixed-size | Docs with tables, lists, or strong structural hierarchy | Cuts mid-table, splits related content across arbitrary boundaries | Recursive or document-aware |
| Recursive | Short, self-contained documents (FAQs, product descriptions) | Fragments answers that should stay whole | No chunking, or full-document as chunk |
| Sentence-level | Multi-hop or analytical queries needing paragraph context | Single sentences lack enough context for complex reasoning | Recursive at 512 to 1,024 tokens |
| Document-aware / page-level | PDFs with arbitrary page breaks (auto-paginated text exports) | Page boundaries carry no semantic meaning | Recursive |
| Semantic | Single-topic corpora or constrained ingestion budget | High cost per document with no guaranteed gain on homogeneous content | Recursive |
| LLM-based | Large corpora or latency-sensitive ingestion | Cost and latency are prohibitive at scale | Recursive with post-processing |
| Late chunking | Documents exceeding embedding model context window | Cannot embed full document; falls back to early chunking | Standard semantic or recursive |
Based on FloTorch 2026, NVIDIA 2024, Vectara NAACL 2025 (arXiv:2410.13070), and Superlinked VectorHub.
The most common mistake is defaulting to semantic chunking because it sounds more principled. Vectara's peer-reviewed finding is direct: on realistic datasets, the computational costs are not justified by consistent gains.
The second most common mistake is page-level chunking on documents without meaningful page structure. The third is skipping overlap entirely. Even 10% overlap recovers context that would otherwise be lost at chunk boundaries.
Decision Framework: Matching Strategy to Document Type
| Document Type | Recommended Strategy | Chunk Size | Overlap | Evidence |
|---|---|---|---|---|
| General text (articles, blogs) | Recursive | 512 tokens | 10 to 20% | FloTorch 2026: 69% accuracy |
| Academic papers | Recursive | 512 tokens | 10 to 20% | FloTorch 2026: 50 papers tested |
| Financial reports, earnings calls | Page-level or 1,024-token fixed | 1,024 tokens | 15% | NVIDIA 2024: 57.9% (financial), 0.648 (page-level) |
| Technical docs (Markdown/HTML) | Header-based + recursive within sections | 512 tokens per section | 10 to 20% | Microsoft Azure; LangChain MarkdownHeaderTextSplitter |
| Code repositories | Language-aware splitting | Function or class level | None | LangChain PythonCodeTextSplitter |
| Multi-topic messy documents | Semantic (with min size floor of 200 to 400 tokens) | 256 to 512 tokens | N/A | Chroma: 91.9% recall |
| Short, focused documents (FAQs, support) | No chunking or sentence-level | Full document | N/A | Firecrawl: chunking hurts on short docs |
| Dense cross-referenced documents | Late chunking | 512 tokens | N/A | Requires long-context embedding model |
| High-value, low-volume documents | LLM-based | Semantic units | N/A | Best semantic quality; cost prohibitive at scale |
All chunk sizes in tokens unless noted. Validate against your own corpus before production.
How to walk through the decision:
- Start with recursive character splitting at 512 tokens, 10 to 20% overlap. Measure retrieval quality on a representative query set from your actual users.
- If documents are paginated with meaningful page structure, try page-level chunking.
- If documents are Markdown or HTML, use header-based splitting first, then recursive within sections.
- If retrieval metrics are still low and documents have clear topic transitions, test semantic chunking with a minimum size floor of 200 to 400 tokens.
- If you have high-value documents with dense cross-references, test late chunking.
- If nothing works and volume is low, try LLM-based chunking on that specific document type.
The Vectara and FloTorch data both show that testing different configurations on your actual corpus matters more than picking a theoretically superior method.
Start with Recursive, Measure, Then Optimize
Recursive character splitting at 512 tokens with 50 to 100 tokens of overlap is where you should start. It won the largest real-document benchmark, requires no model calls, and runs in milliseconds.
Your action plan:
- Implement recursive character splitting at 512 tokens with 50 to 100 token overlap. This is your baseline.
- Run the comparison script above on your actual document set. Look at average chunk size, minimum chunk size, and size variance.
- Measure retrieval quality (precision@K, recall@K, or MRR) on queries drawn from your actual users.
- If metrics fall short, consult the decision matrix above and test the next candidate strategy for your document type.
Chunking is one of the highest-ROI optimizations in a RAG pipeline. You do not need expensive LLM-based or semantic chunking to get strong results. Match the strategy to your document type, measure, and iterate.
If you would rather not manage chunking configuration yourself, Prem Platform deploys production-ready RAG pipelines in your cloud account with configurable chunking and built-in document processing. Data stays in your VPC. For open-source models with extended context windows suited to RAG, Prem-1B (Apache 2.0, 8,192-token context) pairs well with any of the chunking strategies above. Get started here.
FAQ
What is the best chunk size for RAG?
256 to 512 tokens covers most use cases. Factoid queries work well at 256 to 512 tokens; analytical and multi-hop queries benefit from 512 to 1,024 tokens, per NVIDIA's benchmark. Start at 512 with 10 to 20% overlap, measure on your actual query set, and adjust from there.
Is semantic chunking better than recursive chunking?
Not consistently. Semantic chunking scored 91.9% recall in Chroma's evaluation but 54% end-to-end accuracy in FloTorch's test, 15 points behind recursive splitting. The gap comes from fragment size: the FloTorch semantic chunks averaged 43 tokens, which retrieved well in isolation but gave the LLM too little context to answer questions accurately. Vectara's NAACL 2025 peer-reviewed study found fixed-size chunking consistently outperformed semantic chunking on realistic document sets.
How much overlap should I use?
Start at 10 to 20% of your chunk size. For 512-token chunks, that is 50 to 100 tokens. Microsoft Azure recommends 25% (128 tokens) as a conservative starting point. If you are using sparse retrieval methods like SPLADE, test with zero overlap first; some evidence suggests overlap adds storage cost without improving sparse retrieval recall.
What is late chunking and when should I use it?
Late chunking embeds the full document before splitting, so each chunk's embedding carries context from the surrounding document. This helps with cross-references, pronouns, and section headers that would be stripped away in standard early chunking. Use it when documents have heavy cross-references and your embedding model supports the full document length. For straightforward prose, the gain over recursive splitting is usually marginal.
When should I not chunk at all?
Short, focused documents like FAQ entries, product descriptions, and individual support articles often perform better without chunking. Splitting a 200-word answer into fragments guarantees that at least one fragment is missing the conclusion. Use the full document as the chunk, or apply sentence-level splitting with a high minimum size.
Does chunking strategy affect which embedding model I should use?
Yes. The Vectara NAACL 2025 study tested 25 chunking configurations across 48 embedding models and found that gains from better chunking depend partly on the embedding model. Evaluate chunking strategy and embedding model together on your corpus rather than independently.