Nobody Measures the Decision That Caps Everything Else
Everyone argues about the embedding model. Everyone tunes the reranker. Almost nobody measures the decision that quietly sets the ceiling on both: how you chop the document into chunks before any of that happens.
Cut on a fixed character count and you will slice clean through the middle of the sentence that held the answer. The retriever finds a chunk that is "near" the answer, the model reads half a fact, and it confidently makes up the other half. The chunk boundary broke you, not the embedding.
Measuring the Only Thing That Matters
chunklab puts the common strategies side by side on a retrieval task where the answer spans are known exactly, and checks the only question that matters: did the retrieved chunk actually contain the whole answer, or just land near it.
• FixedSizeChunker: cuts every N characters. Fast, and it does not care what it slices through.
• OverlapChunker: the same idea with overlap between chunks, a cheap hedge against boundary casualties.
• RecursiveChunker: splits on paragraphs, then sentences, then a hard cut. Respects the document's own seams.
• SentenceChunker: never splits a sentence, so it never splits a one-sentence answer.
The Number
On a 10-question benchmark with a fixed retriever so chunking is the only variable, fixed-size cutting retrieves the whole answer 50% of the time. Overlap buys back a little at 60%. The structure-aware strategies, recursive and sentence, both hit 80%, a full 30 points free, sitting in a decision most pipelines make without ever measuring it.
9 tests pass in CI across Python 3.9, 3.11, and 3.13.