Practice explaining chunking as retrieval engineering.
01Why does chunking matter in RAG?
Strong answer: retrieval searches chunks, not original documents. Chunk boundaries decide whether evidence can be found and understood.
Follow-up: explain a rule-and-exception boundary failure.
02What is fixed chunking?
Strong answer: splitting by target size, such as tokens or characters, with optional overlap.
Follow-up: when is it a reasonable baseline?
03What is recursive chunking?
Strong answer: trying natural separators first, such as headings and paragraphs, then falling back to smaller separators.
Follow-up: why does this help policy documents?
04What is overlap?
Strong answer: repeated text between neighboring chunks to preserve boundary context.
Follow-up: what is the cost of too much overlap?
05How do you choose chunk size?
Strong answer: tune by document type, question shape, retrieval metrics, context size, citation needs, and cost.
Follow-up: which metrics would you inspect?
06How should tables be chunked?
Strong answer: preserve headers, units, row ids, captions, source positions, and table relationships.
Follow-up: why is plain-text flattening risky?
07How do you evaluate chunking?
Strong answer: use golden queries, Recall@k, citation support, boundary break rate, duplicate overlap rate, and context utilization.
Follow-up: why is average chunk size not enough?
08What metadata should chunks carry?
Strong answer: source id, chunk id, heading path, section, page/row, version, access, chunker version, chunk size, and overlap.
Follow-up: how does metadata help debugging?