การดึงข้อมูลแบบส่วนแม่-ส่วนลูกและจากเล็กไปใหญ่

RAG systems face a tension: small chunks are retrieved with high precision because each chunk is focused on one idea, but they lack the surrounding context the LLM needs to generate a complete answer. Large chunks provide rich context but reduce retrieval precision because they match many queries weakly instead of one query strongly. Parent-child chunking solves this dilemma.

In parent-child chunking, you create two layers of chunks from the same document. Child chunks are small (e.g., 1-3 sentences) and are embedded and indexed for retrieval. Parent chunks are larger sections (e.g., entire paragraphs or pages) that are stored separately. When a child is retrieved, you return its parent to the LLM instead.

The first step is to split the document into large parent chunks, then split each parent into smaller child chunks. Each child chunk keeps a reference — typically a parent_id metadata field — pointing back to its parent. This mapping allows you to look up the full parent passage given any retrieved child.

Only the child chunks are embedded and stored in the vector database. The parent chunks are stored in a separate key-value store (an in-memory dictionary, Redis, or a document database). This keeps the vector index dense and precise while the rich context lives outside it.

During retrieval, the user query is embedded and matched against child chunks. The top-k child chunks are found, and their parent_id references are resolved by looking up the parent store. The parent passages — not the children — are then injected into the LLM prompt. The LLM receives broad context; retrieval was precise.

LangChain provides the ParentDocumentRetriever class that implements this pattern out of the box. You provide a parent splitter, child splitter, a vectorstore for child embeddings, and a docstore for parent documents. It wires up the hierarchy and handles retrieval transparently.

Small-to-big retrieval is another name for the same concept: you retrieve small, precise chunks but then expand them to their surrounding context before sending to the LLM. Some implementations expand not to a fixed parent but to a window of adjacent sentences — giving the model the sentences before and after the matched chunk for contextual continuity.

Multiple child chunks from the same parent may all be retrieved for one query. Without deduplication, the same parent passage would appear multiple times in the prompt, wasting tokens. Always deduplicate by parent ID before assembling the context. The code example in the retrieve function above handles this with a seen_parent_ids set.

Parent-child retrieval works best when your documents have clear hierarchical structure: chapters with sections, articles with paragraphs, or wikis with subsections. It is particularly effective for long technical documentation where precise questions need localized answers but those answers only make sense within a broader section of context.

A typical configuration is: child chunks of 200-400 tokens (focused single ideas) and parent chunks of 1000-2000 tokens (complete sections). If child chunks are too small, they become individual sentences that lack meaning on their own. If parent chunks are too large, you start reintroducing the context dilution problem you were trying to avoid.

To summarize the chunking strategies so far: fixed-size is fast but breaks context; semantic chunking preserves topic coherence; parent-child optimizes both retrieval precision and LLM context richness. For most production RAG systems handling long documents, parent-child chunking delivers the best retrieval quality at manageable complexity.

Test your understanding of parent-child chunking from this lesson.

In this lesson you learned: child chunks provide precise retrieval while parent chunks provide rich context, LangChain's ParentDocumentRetriever implements this automatically, and deduplication by parent ID prevents context repetition. Next up we explore document-specific chunking strategies for code files and HTML documents.