About The Chunking Problem

The Chunking Problem covers one stage of the retrieval pipeline: how a document becomes chunks.

That stage runs once, at index time, before anything is embedded — and it quietly determines the ceiling on everything downstream. A retriever cannot return a coherent passage if no coherent passage was ever created. A reranker cannot repair a table that was split from its header. Most of the retrieval failures people try to fix at query time were caused here.

What you’ll find

Chunk size as a precision/context trade-off. Fixed-size, sentence, paragraph, and structural splitting, and where each one fails. Overlap — what it buys, what it costs, when it’s the wrong tool. Parent/child and small-to-big strategies. The metadata that belongs on a chunk. And the document types that resist all of it: tables, code, transcripts, slide decks, PDFs that were scans.

Every strategy post shows the same source text cut more than one way, with the boundaries marked. A prose description of a chunking strategy is unfalsifiable; a visible split isn’t.

What you won’t find

A recommended chunk size. Not 512, not 1000, not any number. The right size depends on your documents, your queries, and your embedding model, and every article that hands out a figure is guessing on your behalf. What you’ll get instead is the trade-off explained and a procedure for measuring it.

Benchmarks. No invented recall percentages, no “structural chunking improves retrieval by X.” Mechanisms and failure modes, described honestly, with the corpus-dependence stated.

Product recommendations. Libraries get named when naming them is useful. None gets endorsed.

Scope

Ingestion only. Retrieval scoring, hybrid search and reranking are a different problem; so is fitting retrieved passages into a context window. This site stops at the point where chunks exist and are ready to be embedded.

Contact

No newsletter, no tracking, no comments. The RSS feed is at /rss.xml.