Small chunks retrieve accurately, and large chunks give the model enough context to answer.
Parent document retrieval takes both by searching small and returning large.
Each small chunk records which larger passage it came from, and that parent is what is sent on.
It fixes the answer cut off mid-explanation problem without blurring the embeddings.
Deduplicate the parents, since several matching children often point at the same passage.
Chunk size is the first real decision in a RAG system and it pulls in two directions.
Small chunks make sharp embeddings, because a short passage is about one thing.
A query about a specific error code will match a two-sentence chunk far more cleanly than a full page.
But a small chunk is often not enough for the model to answer with.
It arrives without the setup before it or the conclusion after it, and the answer comes out truncated.
Large chunks have the opposite profile: plenty of context, and an embedding that averages many topics.
That average matches everything weakly and nothing strongly, which quietly degrades retrieval.
Parent document retrieval refuses the trade by using different units for search and for generation.
The corpus is split twice, into small children and into the larger parents that contain them.
Only the children are embedded and indexed, so search precision comes from them.
Each child stores the identifier of its parent rather than the parent's text.
After retrieval, the matching children are mapped to their parents and those are placed in the context.
Several children commonly point at the same parent, so deduplication before assembly matters.
The cost is context length, since parents are by design larger than what was matched.
A reranker over the retrieved parents pairs well with this, trimming the set before it reaches the model.
One question on this card. Every option explains itself once you pick, right or wrong.
19 concepts in this module, then a graded test with every answer explained.