InterviewsVector
Arc 7
Failure labIntermediate95 min estimateOriginal publication

Chunking Is a Recall Policy

Segmentation decides what evidence can be represented as one retrievable unit before a ranking model sees the query.

Authorship
InterviewsVector
Published / updated
2026-09-20 / 2026-09-20
Review status
Artifact tests passing · primary sources recorded

Original InterviewsVector teaching. Executable illustrative contracts are covered by focused tests and primary sources are recorded. No named human review, benchmark result, or production certification is claimed.

The decision in one pass

Chunking is a retrieval policy because it defines the candidate units that can be indexed and returned. A boundary can split the minimal evidence needed for an answer; a large chunk can preserve evidence while diluting its representation, wasting context, and crowding out other sources. Choose a policy from document structure, tokenizer behavior, answer-span and multi-hop distributions, embedding context, retrieval top-k, reranking, and generator budget. Measure span representability separately from retrieval success: first ask whether any chunk contains the required evidence, then whether a qualifying chunk was returned. Version boundaries, overlap, tokenizer, headings, source revisions, and embedding contract, and migrate indexes rather than silently rechunking them.

Why this matters

Teams often tune retrievers against candidates created by an unexamined fixed window. If an answer crosses every boundary, no ANN parameter can retrieve a self-contained unit. Conversely, increasing chunks and overlap may inflate storage, duplicate results, and consume the generation context with irrelevant tokens. Making the policy explicit keeps those failures attributable.

You will be able to

  • Model chunks as half-open source token spans bound to document and tokenizer revisions.
  • Separate source coverage, answer-span representability, retrieval coverage, and context waste.
  • Compare fixed, sentence, structure-aware, overlapping, and contextualized strategies without declaring a universal winner.
  • Bind headings, boundaries, content digests, source revisions, and downstream representation contracts.
  • Roll out a rechunking policy as a reversible index migration.

Your Vector Loop for this lab

  1. 01

    Model

    Map source structure, tokenizer offsets, answer evidence, retrieval top-k, and final context constraints.

  2. 02

    Derive

    Derive source coverage, span representability, retrieved coverage, overlap, and minimal context-waste measures.

  3. 03

    Build

    Create immutable chunk spans and query evidence bound to source, policy, embedding, and content identities.

  4. 04

    Stress

    Move answers across boundaries, vary structure, duplicate overlap, corrupt offsets, miss revisions, and retrieve wrong chunks.

  5. 05

    Operate

    Observe boundary misses, duplicated results, context utilization, storage growth, and downstream grounded outcomes by cohort.

  6. 06

    Defend

    Explain which policy evidence applies to this corpus and why fixture coverage is not semantic or production certification.

Segmentation defines the candidate universe

A retriever cannot return an evidence unit that was never represented. Fixed token windows make cost predictable but can cut headings from their bodies, tables from labels, or an exception from its governing rule. Sentence and structure-aware segmentation preserve different boundaries but depend on parser quality. Overlap gives spans near one boundary a second chance while duplicating storage and candidate content.

PolicyPotential advantageFailure to measure
fixed windowbounded size and deterministic backfillsemantic units and answer spans cross boundaries
sentence windowavoids mid-sentence cutslists, tables, code, and long sentences break assumptions
structure-awareretains headings and authored hierarchymalformed or inconsistent structure changes units
overlapraises boundary-span representabilityduplicate retrieval, index growth, and context waste
contextualized or late chunkingchunk representation can retain broader document contextmodel window, pooling, and evaluation contract differ

Measure whether the answer can fit before blaming ranking

SpanCoverage = |{q : ∃c, start(c)≤start(aq) ∧ end(c)≥end(aq)}| / |Q|

A case is representable when at least one same-revision chunk fully contains its required answer span. This simplified single-span measure does not model semantic sufficiency or multi-document reasoning.

RetrievalCoverage@k = |{q : ∃c∈TopK(q), c contains aq}| / |Q|

Retrieval coverage is conditioned on the candidate policy. If span coverage is low, ranking improvements cannot close the whole gap.

MinimalWaste(q) = min_containing_chunk (tokens(c) - tokens(aq))

This local measure exposes how much surrounding material the smallest containing unit carries. Production context waste must also include duplicates, metadata, formatting, and multiple selected chunks.

Choose from evidence structure, not a magic token count

Build a query-to-evidence set with exact source offsets and inspect the distribution of evidence lengths, boundary types, languages, tables, lists, code, and cross-section dependencies. Evaluate policy candidates with the same embedding and retrieval settings first, then study interactions deliberately. A chunk size that works for short factoid passages may fail contracts, narratives, or multi-hop questions.

  1. 01Preserve source identityCarry document ID, revision, content digest, ordered token offsets, headings, and access metadata into every chunk.
  2. 02Generate candidate policiesMake size, overlap, boundary parser, parent-context treatment, and tokenizer revision explicit.
  3. 03Evaluate stagesMeasure representability, candidate retrieval, reranking, context packing, grounding, latency, storage, and cost separately.
  4. 04Inspect failuresRead boundary misses and wasted contexts by document family instead of selecting from one average score.

Check representability before diagnosing retrieval

Inspect the frozen evidence span before changing the retriever. The lab asks only whether each declared interval policy emits at least one chunk that contains the complete span. If none does, segmentation is already blocking that case. If one does, continue with separate retrieval, reranking, context, and generation evidence rather than treating geometric containment as end-to-end success.

Check answer-span coverage before tuning retrieval

Inspect frozen answer spans against fixed, overlapping, and structure-aware intervals, then predict which policies contain the complete span. The fixture isolates representability rather than retrieval or semantic quality.

Audit chunking as an answer-span coverage policy

Inspect token intervals and predict which policies place the complete answer span inside at least one chunk. These compact documents are original illustrative fixtures; they do not claim a universally best chunk size.

Synthetic document case
Document
[0, 100)
Answer span
[46, 58)

Half-open intervals include the start token and exclude the end. A policy passes this narrow check only when one chunk contains both answer boundaries.

Emitted chunk intervals

Chunk intervals emitted by each illustrative policy
PolicyChunk intervalsIndexed token occurrences
Fixed windows[0, 50) · [50, 100)100
Overlapping windows[0, 60) · [40, 100)120
Structure-aware[0, 64) · [64, 100)100

Span coverage does not establish semantic coherence, embedding quality, candidate recall, ranking, context utility, or cost. It isolates one failure boundary so those later stages stay attributable.

Which policies contain the complete answer in one chunk?

Select a prediction, then check it against the recorded evidence.

Audit source and answer spans

The fixture uses half-open token spans, enforces canonical source order and document-edge coverage, bounds overlap and chunk size, binds document/chunk/query content identities, and separates representability from retrieval coverage. Unrepresentable cases receive a full-document waste penalty so they cannot improve the average by disappearing. The offsets and digests remain caller-attested; the audit does not run a tokenizer or judge semantic sufficiency.

chunking_policy_audit.py
1def main():
2 result = audit(example_contract())
3 print("example=illustrative_only")
4 print(f"span_coverage={result.span_coverage:.3f}")
5 print(f"retrieval_coverage={result.retrieval_coverage:.3f}")
6 print(f"mean_minimal_waste_tokens={result.mean_minimal_waste_tokens:.3f}")
7 print("decision=" + result.decision)
8 print("claim=" + result.claim)

Expected output

example=illustrative_only
span_coverage=1.000
retrieval_coverage=1.000
mean_minimal_waste_tokens=3.000
decision=PASS_DECLARED_COVERAGE_GATES
claim=TOKEN_SPAN_FIXTURE_ONLY

Verify: python3 -m unittest discover courses/ai-engineering/reference-impl/chunking_policy

Rechunking changes identities and every downstream index

A new tokenizer, parser, maximum size, overlap, or heading policy creates new chunk identities. Build them beside the old generation, embed them under an explicit contract, populate a separate index, and compare the same query cases. Dual-write source changes and deletions during backfill. At cutover, switch chunk, vector, index, reranking, and context-assembly versions coherently; do not let new queries search only half of a migrated corpus.

Monitor chunk count per source, token-length and overlap distributions, parse failures, uncovered source ranges, missing embeddings, near-duplicate top-k results, representability samples, retrieval coverage, final context utilization, and supported-answer outcomes. Expire and delete old chunks only after a separate retention-aware contraction decision.

Operate at three altitudes

Production lens

  • — Version tokenizer, parser, size, overlap, headings, source revision, embedding contract, and index together; reject incomplete generations.
  • — Monitor uncovered ranges, boundary-crossing answer cases, duplicated candidates, context utilization, storage growth, and downstream source support.
  • — Keep ACL and deletion propagation attached to source identities across both old and new chunk generations during migration.

Staff lens

  • — Require representative evidence-span cohorts across document families before standardizing a chunking policy platform-wide.
  • — Treat chunk identity as derived data lineage so source edits, legal deletion, and parser revisions have explicit fan-out and ownership.
  • — Optimize the whole retrieval-context system; a local recall gain can be defeated by duplicated top-k results or generator context waste.

Interview defense

A RAG system misses answers that visibly exist in the source documents. How do you decide whether chunking is responsible?

I bind ground-truth evidence to exact source and tokenizer offsets, then ask whether any indexed chunk fully contains the needed span. That span-coverage check separates segmentation from ranking. If representable, I test whether top-k returns a containing chunk under the same source, embedding, filter, and index revisions; then I examine reranking and context assembly. I compare fixed, structural, and overlap policies on representative document cohorts, tracking context waste, duplicates, storage, latency, and downstream support. A rechunk is a separate-index migration with dual writes, deletion reconciliation, canary reads, and rollback.

Expect the interviewer to press on

  • — Why can overlap hurt?
  • — How would you evaluate multi-hop evidence?
  • — What must stay synchronized during a rechunk migration?

Misconceptions to remove

“Smaller chunks always improve retrieval precision.”

They may lose context or split evidence; the outcome depends on task, encoder, corpus, ranking, and context assembly.

“Overlap only improves recall.”

It also increases embeddings, storage, duplicate candidates, and context waste, and can reduce result diversity.

“A retrieved chunk containing the answer proves good chunking.”

It is one case. Evaluate representability and retrieval across held-out distributions and distinguish semantic sufficiency from token containment.

Check your model

1. What does span coverage measure before retrieval?

Whether at least one same-revision candidate chunk fully contains the declared evidence span.

2. Why version tokenizer and source revision with offsets?

Token positions only identify content under the exact tokenization and document revision that produced them.

3. If span coverage is 70%, can ANN tuning reach 90% containing-chunk recall?

Not on the same candidate policy and cases; 30% have no containing candidate to retrieve.

Prove the mechanism

Annotate answer spans for three document families and compare fixed windows with a structure-aware policy. Report representability, retrieval coverage, minimal waste, duplicate top-k rate, and the dominant boundary failure for each family.

Add a production constraint

Design a rechunk migration that changes tokenizer and overlap simultaneously. Bind new identities, dual-write edits and deletions, backfill idempotently, validate context assembly, canary by document family, and define rollback plus contraction conditions.

Artifact: Chunking coverage audit

courses/ai-engineering/reference-impl/chunking_policy/chunking_policy_audit.py

Download reference implementation

Primary references and next links

References

  1. 1. Simple is Best: Experiments with Different Document Segmentation Strategies for Passage Retrieval

    Tiedemann and Mur. Primary study of passage segmentation strategies for question answering.

  2. 2. Dense Passage Retrieval for Open-Domain Question Answering

    Karpukhin et al.. Primary dense-retrieval work whose fixed passage setup is study-specific rather than a universal chunk size.

  3. 3. Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models

    Günther et al.. Primary contextualized chunk-embedding proposal; its results are method-specific, not a universal policy.

  4. 4. Document Segmentation Matters for Retrieval-Augmented Generation

    Wang et al.. Primary experimental work on segmentation and RAG retrieval/end-task outcomes.

Continue through the graph

Glossary: chunking · half-open span · span coverage · retrieval coverage · overlap · context waste · document segmentation · derived data