Why boundaries matter
A short chunk may isolate a useful identifier while losing the explanation around it. A long chunk may preserve context but dilute the signal that retrieval needs. Structural chunking tries to respect headings and paragraphs, which only helps when the extracted document structure is meaningful.
Four bounded candidates
The full audit compares fixed strategies targeting roughly 400, 800 and 1200 tokens, plus structural chunks targeting roughly 700. Fixed strategies include overlap. Sizes are approximate estimates rather than provider-tokenizer counts. This bounded matrix is a practical experiment, not an exhaustive search over every splitter.
Use sources that can actually be judged
For real queries, point relevant_id at the intended document or a specific CSV row/JSON item. For synthetic questions, the engine anchors relevance to the source passage. Broad document-level labels are easier to satisfy and can hide a poorly selected passage, so use precise labels where your source format allows them.
Read the matrix, then the regressions
Compare Recall@5, MRR and nDCG across configurations and inspect individual failures. If small chunks improve exact queries but hurt longer procedural questions, the segment report makes that trade-off visible. Do not infer a universal winner from a tiny or unrepresentative corpus.
Plan re-indexing as part of the decision
Changing chunk boundaries requires rebuilding embeddings and the retrieval index. The full report estimates embedding spend and raw vector storage from the corpus and candidate dimensions. These estimates omit database overhead, metadata, generation, reranking and negotiated pricing; use them to size the change, then check your infrastructure bill.