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?

The correct strategy is document-structure-aware chunking that detects table boundaries using PDF layout analysis and keeps a complete table as a single chunk regardless of page boundaries. The problem is a semantic boundary mismatch: page-based chunking does not align with the document structure, because the table's logical extent crosses page boundaries. Structure-aware chunking uses PDF layout signals such as bounding boxes, table detection, and section headers to identify the logical extent of a table and keeps it intact as one chunk. That preserves the column-header and data-row relationship within a single retrieval unit. Raising the number of retrieved chunks from 3 to 10 to include all pages of a multi-page table is wrong because it raises the probability of retrieving all relevant pages, but it also increases noise from unrelated chunks. It does not guarantee that the header page and the data pages are retrieved together, and it inflates context-window usage. Increasing chunk overlap from 0 to 50% of chunk size so the boundary between pages 3 and 4 is included in both chunks is wrong because 50% overlap on page-based chunks still splits tables by page. The overlap may include some data rows from the next page, but the relationship to column headers from the prior page remains encoded in a separate chunk and may not be retrieved together. Embedding a text description of the table structure as a prefix to the page 4 and page 5 chunks, summarizing column headers extracted from page 3, is wrong because synthesizing that 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.