Parent Document and Small-to-Big Retrieval

Fixed-size chunking forces a trade-off. Small chunks, say a few sentences, produce sharp embeddings: the vector represents one idea, so a query about that idea matches it closely. But a two-sentence chunk rarely contains enough context for the model to answer well; it may omit the definition three paragraphs earlier or the exception in the next sentence. Large chunks carry that context, but their embeddings blur several ideas together, so retrieval gets less precise and the relevant passage can be outscored by a chunk that is merely on-topic. Small-to-big retrieval splits the two jobs. The system indexes small child chunks for search, and each child keeps a pointer to a larger parent: a section, a page, or the whole document. At query time it finds the best children, then looks up and returns their parents. If several children share one parent, the parent is sent once, which also removes duplicates. LangChain's ParentDocumentRetriever implements this with a vector store for children and a separate document store for parents. LlamaIndex offers related patterns: sentence-window retrieval, which returns a matched sentence plus a fixed number of neighboring sentences, and auto-merging retrieval, which replaces many retrieved leaf chunks with their shared parent node when enough of them match. The approach tends to beat fixed-size chunking on structured documents such as manuals, contracts, policies and textbooks, where meaning depends on the surrounding section. It helps less when documents are already short, or when parents are so large that a few of them overflow the context window or bury the answer in irrelevant text. A common misconception is that this is just using bigger chunks. It is not: the retrieval unit and the generation unit are deliberately different sizes, so you keep precise matching without starving the model of context.