Document Chunking Architecture for RAG: 2026 Guide

Q: What is the best chunk size for RAG?

There is no universal best chunk size, but a strong default in 2026 is roughly 256 to 512 tokens with 10 to 20 percent overlap, then tuned per document type against a golden set. The size is a trade-off: larger chunks carry more surrounding context but dilute the embedding (the vector averages too many ideas, so it matches less precisely) and consume more of the context window per result, raising cost and latency. Smaller chunks embed more precisely and cite more cleanly but can lose the meaning that lived in neighbouring sentences. Dense technical or legal text usually wants smaller, semantically-coherent chunks; narrative or uniform content tolerates larger ones. The reliable approach is to treat chunk size as a tuned parameter, not a constant, and measure context recall and precision on a representative question set whenever you change it.

Q: What is the difference between fixed, recursive, and semantic chunking?

Fixed-size chunking cuts the text every N tokens regardless of meaning, which is fast and simple but routinely severs sentences, tables, and arguments mid-thought, producing chunks that embed poorly. Recursive chunking tries a hierarchy of separators — paragraph breaks first, then sentences, then words — so it respects natural boundaries while still hitting a target size, and it is the sane production baseline. Semantic chunking goes further: it embeds each sentence and starts a new chunk wherever the similarity between consecutive sentences drops sharply, so each chunk is a topically-coherent passage rather than a length-bounded window. Semantic chunking gives the best topical coherence but costs roughly double the ingestion compute because you embed the document twice, so it earns its cost on dense, topic-shifting content and is overkill for uniform text where recursive splitting already captures most of the benefit.

Q: What is contextual retrieval and is it worth the cost?

Contextual retrieval, introduced by Anthropic, prepends a short LLM-generated description of the surrounding document to each chunk before embedding it — for example adding "This is from the Q3 2026 earnings report, EMEA revenue section" to a chunk that otherwise just says "revenue grew 40%". This makes each chunk self-explanatory, so the retriever can match it even when the chunk relies on context defined elsewhere in the document. Anthropic reports it reduces retrieval failures by up to 49 percent when combined with BM25 keyword search, and up to 67 percent when paired with reranking. The cost is one cheap LLM call per chunk at ingestion time, which is made affordable by prompt caching the shared document so you do not re-send it for every chunk. It is worth the cost for high-stakes corpora where a wrong or missed retrieval is expensive, and usually not worth it for low-value, high-volume content.

Q: What is late chunking?

Late chunking, introduced by Jina AI, reverses the usual order of operations. Normally you split the document into chunks first and then embed each chunk independently, which means each chunk vector is computed in isolation with no knowledge of the rest of the document. Late chunking instead embeds the entire document through a long-context embedding model first, producing token-level embeddings that were all computed while the model could see the full document, and only then pools those token embeddings into one vector per chunk. Because each chunk vector was derived from a pass that saw the whole document, every chunk implicitly carries its context — a chunk referring to "the defendant" or "this metric" still embeds near the document content that defines those terms. It adds modest cost beyond a long-context embedding pass and substantially improves retrieval on documents dense with pronouns and back-references, without requiring an LLM call per chunk the way contextual retrieval does.

Q: How should I handle tables and code when chunking?

Tables, code blocks, and lists are atomic units and must not be split across chunk boundaries. A table cut in half loses its header row and becomes unparseable noise that embeds badly and can never be cited correctly; a function cut mid-body confuses both the embedding model and the answering model. The correct approach is document-aware chunking: parse the source into a structured tree first (detecting headings, tables, code fences, and lists), then keep each structured block intact as a single chunk even if it exceeds your target token size, while splitting only the surrounding prose normally. For very large tables, keep the header with each row group, and for figures and charts pair structural chunking with multimodal techniques so the visual content stays retrievable. Attaching the table or code block to its section heading via metadata further improves both retrieval and citation rendering.

Q: Why does chunk overlap matter and how much should I use?

Overlap means consecutive chunks share some text at their boundaries, and it exists to prevent facts that straddle a boundary from being lost. Without overlap, a sentence or fact that happens to sit at the exact cut point can be truncated in both adjacent chunks, so neither chunk embeds it cleanly and the retriever can never surface it intact. A typical overlap of 10 to 20 percent of the chunk size ensures boundary-spanning facts appear whole in at least one chunk. The trade-off is storage and compute: overlap increases the total number of tokens you embed and store, so 50 percent overlap doubles redundancy for little extra recall. The practical sweet spot is 10 to 20 percent for most prose, lower for already-structured content where boundaries fall naturally between coherent blocks, and you should verify the chosen value on your golden set rather than assuming a default.

Q: How do I evaluate whether a chunking change helped?

Evaluate chunking the same disciplined way you evaluate any retrieval change, because intuition about chunking is unreliable and a change that feels better often is not. Build a golden set of 50 to 200 question and answer pairs where you know which source passage contains the answer, then for each chunking strategy measure three things: context recall (was the correct chunk retrieved at all), context precision (what fraction of the retrieved text was actually relevant), and end-to-end answer faithfulness (did the final answer stay grounded in the retrieved chunks). Run this harness on every chunking change and gate the change on the metrics, not on spot checks. Watch for the common trap where a change improves recall but tanks precision, because flooding the context window with near-miss chunks frequently produces worse answers while also raising cost and latency. Tie chunking evaluation into the same continuous-evaluation process you use for embedding and model upgrades.

Q: Does long-context (1M-token) models make chunking obsolete?

No. Long-context models change the trade-off but do not remove the need for chunking in most production systems. Stuffing an entire corpus into a million-token window is expensive per request, slower, and suffers from the "lost in the middle" effect where models attend less reliably to information buried in the centre of a very long context, so accuracy can actually drop relative to focused retrieval. Chunking plus retrieval keeps each request small, cheap, and precise by sending only the most relevant passages, and it scales to corpora far larger than any context window. Long context is genuinely useful for whole-document reasoning over a single bounded document, or as a complement where you retrieve a shortlist of chunks and then let a long-context model read several full sections around them. The right architecture in 2026 is usually retrieval over well-chunked content, with long context applied selectively, rather than one replacing the other.