Unit 02.00: One chunk is one thing worth citing

A chunk is the unit your system retrieves, ranks and cites. Choosing what goes in one is the most consequential decision in the whole pipeline, and it is usually made by whichever default the library ships with.

The test: could you cite this alone?

The useful definition of a chunk is not "500 characters" or "one paragraph." It is: *one thing a reader could be pointed at as evidence for a claim*. Under that definition, size is a consequence, not a setting.

The example below takes one policy document and represents it two ways: as a single chunk, and as one chunk per claim. Both are valid indexes. Only one produces a usable citation.

whole-document chunks: 1
per-claim chunks     : 3
  doc-1#0: Refund policy. Refunds are allowed within 7 days of purchase.
  doc-1#1: Enterprise policy. Enterprise plans use custom contracts.
  doc-1#2: Support policy. Support responds within one business day.

The whole-document chunk is citable in the narrow sense - it has an id - and useless as evidence, because following the citation lands the reader in three policies with no indication which one applied. The per-claim chunks each point at one line.

This is why chunking gets revisited after the first eval run. A retrieval score can look excellent while every citation is unfollowable, because retrieval quality and citation quality are separate measurements. Module 8 scores them separately for exactly this reason.

The mistake this prevents

The mistake is choosing chunk size by token budget. Token budget constrains how many chunks you can pass, not what belongs in one. Decide the semantic unit first - one policy statement, one procedure step, one definition - then check whether k of them fits your budget. If not, reduce k, not meaning.

Takeaway

A chunk should be the smallest passage that still makes its point without its neighbours. Test it by asking what a reader sees when they follow the citation: one line they can check, or a document they have to search.

Mark complete