Parent Document and Small-to-Big Retrieval Quiz

Answers and explanations appear as you take the quiz.

1. What core trade-off does small-to-big retrieval address?
   • Embedding models are too slow for large documents
   • Small chunks match precisely but lack context, while large chunks carry context but match poorly
   • Vector databases cannot store documents longer than one page
   • Language models can only read one chunk per request
2. In a small-to-big system, what is embedded and searched at query time?
   • Small child chunks
   • Whole parent documents only
   • Document titles only
   • The model's previous answers
3. If three retrieved child chunks all belong to the same parent section, what should the system do?
   • Send all three children and the parent
   • Discard the children because they overlap
   • Send the shared parent once
   • Send only the lowest-scoring child
4. How does LangChain's ParentDocumentRetriever store the two levels of text?
   • Both levels in a single vector index with no links
   • Parents in the vector store and children discarded
   • Children in a relational table, parents in the model's weights
   • Children in a vector store and parents in a separate document store
5. What does sentence-window retrieval return?
   • Only the single matched sentence
   • The matched sentence plus a fixed number of neighboring sentences
   • A random sample of sentences from the document
   • The document's title and summary
6. What does auto-merging retrieval do when enough leaf chunks from the same parent node are retrieved?
   • It deletes the parent node from the index
   • It asks the user which leaf to keep
   • It replaces the leaf chunks with their shared parent node
   • It re-embeds the leaves as one vector
7. In which situation does small-to-big retrieval help the least?
   • When the documents are already short
   • When documents are long manuals with sections
   • When meaning depends on surrounding definitions
   • When several matches come from one contract section
8. Why store a parent_id in each child chunk's metadata?
   • So the model can be fine-tuned on parent IDs
   • To make embeddings smaller
   • To hide parents from the user
   • So expanding a child to its parent is a cheap key-value lookup instead of another search