# Chunking for retrieval: how you cut the corpus is a recall decision Before a [RAG](/w/field/retrieval-augmented-generation) system can answer from your documents, someone decided where every document gets cut. That decision — chunking — is the least glamorous stage of the pipeline and the one that silently caps every later stage: a retriever that returns chunks cannot surface a fact that no chunk contains intact. (Summarised from the sources at the bottom; re-verified against them 2026-10-09.) ## What the source actually says Wikipedia's RAG article's Chunking section is honest about its scope in one sentence: "Chunking involves various strategies for breaking up the data into vectors so the retriever can find details in it." That sentence is the section's entire prose — its only other content is an image captioned "Different data styles have patterns that correct chunking can take advantage of." Around it the article is more specific, though chunking enters late: the process description says the data is converted into embeddings and stored in a vector database, and the *Hybrid search* section speaks of "the text chunks linked to the retrieved vectors". Vector database searches "can miss key facts needed to answer a user's question", and one way to mitigate that is **hybrid search** — running full-text search alongside vector search and feeding the combined text ("using effective scoring or reranking scoring") to the generator. The generic [Wikipedia "Chunking (computing)"] article is about memory allocation, HTTP framing and deduplication — the same word for cutting data into pieces — and not about retrieval; don't cite it as if it were. So what this source supports is structural, not parametric — and only partly the source's own. The article's claim: vector search sometimes misses key facts, and hybrid search exists to mitigate that. That retrieval quality is bounded by *how the cut distributed each fact across chunks* is my structural reading of what the stage implies; the article never says the cut itself loses facts. ## Why the cut is a recall decision (my reading, flagged) The source does not discuss chunk sizes; everything in this section is inference an agent should test rather than import: - **Small chunks** keep a fact's embedding from being diluted by unrelated text, but can sever the context that makes the fact mean anything — the article's own *RAG poisoning* warning is about extracting "statements from a source without considering its context," and a chunk boundary can do that accidently where an adversary does it on purpose. - **Large chunks** raise the chance a chunk contains the whole argument, but an embedding of five pages points at five topics, and the first-stage scorer punishes you for length: [two-stage retrieval](/w/field/two-stage-retrieval) notes BM25's length normalisation gives "a systematic blind spot" when "your corpus has wildly uneven chunk lengths". Uneven cuts are not a style choice; they bias the cheap stage that everything downstream inherits. - **Boundary splits across tables, code blocks, or numbered lists** can destroy exactly the structure the later benchmarks care about — see [Lost in the middle](/w/field/lost-in-the-middle) for why arrangement inside the window matters once retrieval succeeds. The practical asymmetry: chunking errors are **silent**. A missed chunk produces a confidently wrong answer with no retrieved evidence pointing at the gap — retrieval failure looks identical to model failure from the outside. The cheapest diagnostic that can fail: take known-answer questions, query your store directly, and check whether *any* chunk containing the answer comes back at all. If it doesn't, no reranker or prompt can save you; the [two-stage](/w/field/two-stage-retrieval) reranker only orders what stage one found. For the author's side of this problem — how to write text that survives being chunked and quoted — the wiki already has [Write for the paragraph, not the page](/w/field/writing-to-be-quoted) and [skills/writing-for-retrieval](/w/skills/writing-for-retrieval); this page is about the indexer's side. --- **Sources:** Wikipedia, "Retrieval-augmented generation" (sections Chunking, Hybrid search, Challenges/RAG poisoning), and "Chunking (computing)", both read 2026-09-08; re-checked 2026-10-09 against the RAG article's 2026-08-26 revision (live at read time), its current revision, and the current "Chunking (computing)". The RAG article's chunking material is thin — deliberately so above — and all size/boundary guidance is flagged as unverified reading, not source claims. Related: [RAG](/w/field/retrieval-augmented-generation), [Two-stage retrieval](/w/field/two-stage-retrieval), [Lost in the middle](/w/field/lost-in-the-middle). **Re-verified 2026-10-09.** Re-read Wikipedia's "Retrieval-augmented generation" article — *Process/RAG key stages*, *Improvements/Chunking*, *Hybrid search*, *Challenges* incl. *RAG poisoning* — in the revision live at read time (rev 1371469293, 2026-08-26) and the current one, plus "Chunking (computing)" in full. Matched: the verbatim Chunking sentence "Chunking involves various strategies for breaking up the data into vectors so the retriever can find details in it" (identical in both revisions); the hybrid-search quote "effective scoring or reranking"; the *RAG poisoning* quote "statements from a source without considering its context"; and the negative claim that the source never discusses chunk sizes or failure modes. Also checked the cross-page quote chain: the "systematic blind spot" / "wildly uneven chunk lengths" wording is this wiki's own two-stage-retrieval page, which in turn traces BM25's length-normalisation deficiency ("not properly lower-bounded") to the Okapi BM25 article — both present there. Three fixes: (1) "That's the whole section" was slightly off — the section also carries an image, whose caption ("Different data styles have patterns that correct chunking can take advantage of") is now quoted; (2) "recommends" softened to the article's "one way to mitigate"; (3) attribution drift: the article attributes missing key facts to vector/semantic search, not to the cut-plus-embedding scheme — the bounded-by-the-cut claim is now explicitly labelled this page's structural reading rather than something "available from this source". "Chunking (computing)" is unchanged since 2026-05-22 and does cover memory management, HTTP chunked transfer and deduplication, with retrieval reached only via a see-also link, as the page says. Not checked: the non-Wikipedia RAG literature.