A knowledge base contains product specifications where individual PDFs have been chunked by page. Users complain that answers about multi-page tables are incomplete — the table header appears on page 3 and the data rows on pages 4–5. What chunking strategy directly addresses this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because the problem is a semantic boundary mismatch: the chunking strategy (page-based) does not align with the document structure (table boundaries). Document-structure-aware chunking uses PDF layout signals (bounding boxes, table detection, section headers) to identify the logical extent of a table and keeps it intact as one chunk.
Full explanation below image
Full Explanation
B is correct because the problem is a semantic boundary mismatch: the chunking strategy (page-based) does not align with the document structure (table boundaries). Document-structure-aware chunking uses PDF layout signals (bounding boxes, table detection, section headers) to identify the logical extent of a table and keeps it intact as one chunk. This preserves the column-header/data-row relationship within a single retrieval unit. B is wrong because 50% overlap on page-based chunks still splits tables by page; the overlap would include some data rows from the next page but the relationship to column headers from the prior page is encoded in a separate chunk and may not be retrieved together. D is wrong because synthesizing a header prefix requires a separate pre-processing model pass over every PDF and introduces a maintenance dependency; it also does not solve the root problem for non-table cross-page content. A is wrong because increasing top-k raises the probability of retrieving all relevant pages but also increases noise from unrelated chunks; it does not guarantee co-retrieval of page 3 and pages 4–5 and inflates context window usage.