A team splits long internal manuals into fixed-size chunks before embedding them for a retrieval index, and configures each chunk to overlap with the next by roughly 10-20% of its length rather than starting exactly where the previous chunk ended. What is the main reason for using this overlap between adjacent chunks?
- It reduces the total number of chunks that must be embedded and stored, which lowers the cost of building the index
- It prevents a sentence or idea that spans a chunk boundary from being split apart so that neither resulting chunk contains it in full, which could leave either chunk incoherent or missing context on its own
- It guarantees that every chunk containing the overlapping text will be retrieved for any query relevant to that document, since duplicated content is matched more often
- It lets the embedding model process shorter chunks than the maximum input length it is otherwise capable of handling
Why B? And why not the others?
Correct answer: B. It prevents a sentence or idea that spans a chunk boundary from being split apart so that neither resulting chunk contains it in full, which could leave either chunk incoherent or missing context on its own
Splitting a manual into non-overlapping chunks risks cutting a sentence, a step in a procedure, or a cause-and-effect explanation exactly at the boundary, leaving each side of that boundary incomplete on its own; giving adjacent chunks a modest overlap means the text spanning that seam appears in full inside at least one chunk, so retrieval is less likely to surface a fragment that is missing the context needed to make sense of it. The option about reducing the number of chunks is backwards: adding overlap increases the total number of chunks and the embedding cost, since the overlapping text is embedded more than once, rather than reducing it. The option promising guaranteed retrieval is wrong because appearing in an extra chunk does not guarantee a match; whether a chunk is retrieved still depends on how closely its embedding matches the query, not simply on how many times its text appears in the index. The option about processing shorter chunks confuses overlap with chunk size itself; the maximum length an embedding model can accept is a separate setting from how much adjacent chunks overlap.
Source: Pinecone, 'Chunking Strategies for LLM Applications,' https://www.pinecone.io/learn/chunking-strategies/; LangChain, 'Splitting recursively' text splitter documentation, https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter