Preview parent-child chunking before you index
Hierarchical or small-to-big retrieval is one of the most effective RAG upgrades: you search over small child chunks for precise matches, but feed the larger parent chunk they came from into the model so it has enough surrounding context to answer well. This tool lets you preview that split — set a parent size and a child size, paste your document, and see exactly how the parents and nested children come out before you commit to an indexing pipeline.
How it works
The document is split in two passes. The first pass walks the text by sentence and paragraph boundaries, accumulating until it reaches roughly the parent size, producing the large context chunks. The second pass repeats the same boundary-aware accumulation inside each parent using the child size, producing the small chunks you would actually embed and search. Every child records which parent it belongs to, so the preview shows a clean nested tree with character counts at each level. Because the splitter respects sentence ends, chunks rarely break in the middle of a thought.
Why this pattern beats flat chunking
Standard flat chunking forces you to pick one chunk size. If you pick small chunks for precision, retrieved passages often lack the surrounding sentences needed to answer the question well. If you pick large chunks, similarity scores dilute because the chunk covers too many topics.
Parent-child chunking sidesteps this by decoupling the search unit from the context unit. The child (small) chunk scores well in a nearest-neighbour search because it is focused. The parent (large) chunk provides the context the model needs to give a complete answer.
For example, in a legal document where each section spans several paragraphs:
- Child chunk (200–400 characters): one clause or definition — precise enough to match “what is the indemnification period?”
- Parent chunk (1,200–2,000 characters): the full section containing that clause — rich enough for the model to understand surrounding obligations
The retriever finds the matching child, looks up its parent ID, and returns the parent as context.
Sizing guidance
| Document type | Suggested parent size | Suggested child size |
|---|---|---|
| Dense technical docs | 800–1,200 chars | 150–250 chars |
| Narrative prose or reports | 1,500–2,500 chars | 300–500 chars |
| Legal / policy text | 1,200–2,000 chars | 200–350 chars |
| FAQ content | 600–900 chars | 100–200 chars |
These are starting points. Use the preview to check that child chunks remain coherent sentences rather than mid-thought fragments.
Tips and notes
A common starting point is parents of roughly 1,000–2,000 characters with children of 200–400 characters, but the right values depend on your model’s context budget and how dense your source material is. If children come out larger than your target, your document has long unbroken sentences — shorten them or accept the overshoot. Watch the parent-to-child ratio: too many tiny children per parent inflates your index, while too few defeats the precision benefit. Tune here, then mirror the same sizes in your real LangChain, LlamaIndex or custom retriever configuration.