CrawlClick

Chunking

Splitting a document into smaller passages so a retrieval system can fetch and quote the relevant part rather than the whole page.

Also called: text chunking, passage splitting

Chunking splits a document into passages. Retrieval systems work on chunks, not pages, so how a page divides determines what an engine can actually quote from it.

Where do chunk boundaries usually fall?

Commonly at headings and paragraph breaks. A page with clear headings every few paragraphs divides cleanly. A wall of unbroken text divides arbitrarily, and the resulting fragments often begin mid-argument.

How long should a passage be?

Long enough to state something complete, short enough to be retrieved on its own. Sentences in roughly the ten to thirty word range tend to survive chunking with their meaning intact.

What is the practical consequence of poor chunking?

Your page may be retrieved and still fail to be used, because the fragment the system pulled does not say anything usable on its own. The content was fine; the packaging was not.

How big is a chunk, and who decides?

The retrieval system decides, not you. Implementations work to a token budget rather than a word count, usually with an overlap between neighbouring chunks so that a sentence straddling a boundary survives in both. None of the answer engines publish the values they use, and there is no header or directive that lets a publisher set them. What a publisher controls is narrower and more useful: whether a natural boundary exists close to where the splitter wants one.

Which parts of a page survive chunking intact?

Short paragraphs under a descriptive heading survive best, because the heading travels with the passage and supplies its subject. A simple table usually survives as rows of label-and-value pairs. A list survives when each item is a complete statement and falls apart when the items depend on a stem sentence three lines above them. Code blocks contribute very little, because there is rarely any prose in them for a model to lift.

What happens to a very long page?

It becomes many candidates rather than one strong one. A four-thousand-word article is split into a dozen or more passages, and retrieval scores each of them separately against the question; only the best match is pulled. Length is therefore neither an advantage nor a penalty in itself. What decides the outcome is whether any single passage answers the question completely.

How is this different from how a search engine reads a page?

Classical ranking scores a document and returns a link to it, so a reader who lands mid-argument can scroll. Retrieval scores a passage and returns the passage, so nothing above or below it exists. That single difference is why pages that ranked well for years can be invisible in answers: the document was good and no individual fragment of it was.

What else should I read?