Skip to content
Citable

Definition

Chunking

Also known as: Text splitting, passage segmentation

Chunking is the step in a retrieval pipeline that splits a page or document into smaller passages — typically a few hundred tokens each, cut at headings, paragraphs or a fixed window — so that each passage can be embedded, indexed and retrieved on its own. Because answer engines retrieve and cite chunks rather than whole pages, chunk boundaries decide what a model actually sees.

You do not control how an answer engine chunks your page, but you control how well the page survives it. Common strategies are fixed-size windows (a few hundred tokens, often with some overlap), recursive splitting on paragraph and then sentence boundaries, and structure-aware splitting on Markdown or HTML headings. Structure-aware splitters are the friendliest, and they are what a clean heading outline, semantic HTML and a Markdown version of the page make possible.

The failure mode is context loss. Anthropic's contextual retrieval write-up from September 2024 gives the canonical example: a chunk reading "The company's revenue grew by 3% over the previous quarter" is useless on its own, because it does not say which company or which quarter. Their fix — prepending a short generated note on where the chunk sits in the document — cut top-20 retrieval failures by 49% when combined with BM25. You can get much of the same effect at source by writing each section so that it names its own subject.

Writing for the chunker

  • One question per H2, phrased as the question
  • The first sentence of each section names the entity and states the answer
  • No "as mentioned above" or unresolved "it" at the start of a section
  • Tables and code blocks short enough to sit inside one chunk with their explanation

Frequently asked questions

How long should a section be so that it survives chunking?

Aim for sections that make sense on their own at a few hundred words and open with a self-contained answer. Chunkers differ, but nearly all respect headings and paragraph breaks, so a heading that states the question followed by a 40–70 word direct answer will usually land intact in one chunk.

Related terms

Guides that use this term

  • Content

    How to write answer-first content that LLMs can quote

    Answer-first content opens every page and every section with a self-contained answer of roughly 40–70 words, then explains, qualifies and expands. The first sentence names the main entity, each heading carries exactly one question, and no passage depends on a pronoun or a paragraph elsewhere. Written this way, a passage still makes sense after an answer engine splits the page into chunks and retrieves one of them in isolation.

    8 min read

  • Technical

    Serving Markdown to LLMs: content negotiation and .md endpoints

    Serving Markdown to LLMs means publishing a plain-text representation of each page next to the HTML one, so that AI crawlers and agents can read it without rendering JavaScript or spending tokens on markup. There are two delivery patterns: a .md suffix on the canonical URL, and content negotiation on the Accept: text/markdown request header, with Vary: Accept and a Link rel=canonical header pointing back to the HTML page.

    10 min read

  • Technical

    Modelling content for answer engines in a headless CMS!

    A headless CMS content model for answer engines makes every Answer Engine Optimization signal a constrained field, not an editorial habit: a required short answer with a maximum length, key takeaways, FAQ items, sources with URL validation, the author as a relation, and published and updated dates. JSON-LD, Markdown and llms.txt are then generated from those fields, so no representation can disagree with the page.

    9 min read