arxiv: 2605.00318 · v1 · submitted 2026-05-01 · 💻 cs.CL · cs.IR

Recognition: unknown

Structure-Aware Chunking for Tabular Data in Retrieval-Augmented Generation

Pooja Guttal , Varun Magotra , Vasudeva Mahavishnu , Natasha Chanto , Sidharth Sivaprasad , Manas Gaur

Authors on Pith no claims yet

Pith reviewed 2026-05-09 20:06 UTC · model grok-4.3

classification 💻 cs.CL cs.IR

keywords tabular chunkingstructure-aware processingretrieval-augmented generationRAGdocument chunkingMAUD datasetrow-level segmentationkey-value blocks

0 comments

The pith

Preserving row boundaries when chunking tables for RAG cuts chunk counts by up to 56 percent and raises retrieval recall.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents a chunking method for tabular files that builds each row as a key-value block inside a hierarchical tree. Splits follow structural edges and merging stays overlap-free so fields that belong together stay in the same chunk. This produces fewer, denser chunks than text-oriented baselines and improves how well relevant table sections are retrieved. Readers should care because enterprise records are commonly stored in tables, and standard chunking breaks the very connections needed for accurate answers. If the method holds, RAG pipelines can process tabular data with lower overhead and higher precision.

Core claim

Constructing a Row Tree in which every row is stored as a key-value block, then executing token-constrained splits at structural boundaries and overlap-free greedy merging, yields dense non-overlapping chunks that keep intra-row semantic relationships intact, delivering up to 40 percent and 56 percent fewer chunks than recursive and key-value baselines while lifting hybrid MRR from 0.3576 to 0.5945 and BM25 Recall@1 from 0.366 to 0.754 on the MAUD dataset.

What carries the argument

The Row Tree representation of tabular data, with each row encoded as a key-value block, that guides token-constrained splitting and overlap-free greedy merging to align chunks with structural boundaries.

If this is right

Chunk counts fall by up to 40 percent versus recursive chunking and 56 percent versus key-value baselines.
Token utilization rises, lowering processing and indexing costs.
Retrieval MRR increases from 0.3576 to 0.5945 in hybrid settings.
Recall@1 increases from 0.366 to 0.754 in BM25-only retrieval.
Keeping intra-row field relationships intact improves RAG effectiveness on tabular documents.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same row-tree logic could be applied to JSON or XML records that contain repeated object structures.
Default RAG pipelines for mixed documents may benefit from an initial structure-detection step before generic text chunking.
Testing the method on tables with missing columns or varying widths would reveal how robust the key-value block encoding remains.
Fewer chunks could translate directly into reduced storage and lower latency for large-scale table collections.

Load-bearing premise

The observed gains arise primarily from preserving relationships inside each row rather than from incidental differences in chunk size or the particular merging rule, and that results on the MAUD dataset generalize to other enterprise tables.

What would settle it

Running the identical merging heuristic on the MAUD dataset but deliberately ignoring row boundaries and measuring no reduction in chunk count or retrieval scores would show that structure preservation is not the operative factor.

Figures

Figures reproduced from arXiv: 2605.00318 by Manas Gaur, Natasha Chanto, Pooja Guttal, Sidharth Sivaprasad, Varun Magotra, Vasudeva Mahavishnu.

**Figure 1.** Figure 1: Comparison of baseline recursive chunking versus the proposed structure-aware framework. The baseline method (top) operates on linearized text view at source ↗

read the original abstract

Tabular documents such as CSV and Excel files are widely used in enterprise data pipelines, yet existing chunking strategies for retrieval-augmented generation (RAG) are primarily designed for unstructured text and do not account for tabular structure. We propose a structure-aware tabular chunking (STC) framework that operates on row-level units by constructing a hierarchical Row Tree representation, where each row is encoded as a key-value block. STC performs token-constrained splitting aligned with structural boundaries and applies overlap-free greedy merging to produce dense, non-overlapping chunks. This design preserves semantic relationships between fields within a row while improving token utilization and reducing fragmentation. Across evaluations on the MAUD dataset, STC reduces chunk count by up to 40% and 56% compared to standard recursive and key-value based baselines, respectively, while improving token utilization and processing efficiency. In retrieval benchmarks, STC improves MRR from 0.3576 to 0.5945 in a hybrid setting and increases Recall@1 from 0.366 to 0.754 in BM25-only retrieval. These results demonstrate that preserving structure during chunking improves retrieval performance, highlighting the importance of structure-aware chunking for RAG over tabular data.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

STC gives practical gains for tabular RAG chunking but the role of structure preservation needs better isolation from chunk count and merging changes.

read the letter

The punchline is that this paper gives a workable structure-aware chunker for tables that beats the usual text chunkers on MAUD, but we can't tell yet if the structure part is what matters or if it's just the chunk count drop and the no-overlap merge. It is new in combining the row tree with token-limited splits at boundaries and greedy overlap-free merging. That setup does a good job of keeping rows together as key-value pairs, which should help when queries need info from the same row. The reported drops in chunk numbers (40-56%) and the retrieval lifts (MRR up to 0.59, recall@1 to 0.75) are concrete and useful for anyone dealing with CSV or Excel in RAG pipelines. The soft spot is exactly the one in the stress test: no ablation that fixes chunk size and merge policy while turning off the structural awareness. Without that, the gains might just be from packing more densely or avoiding overlaps. The paper also skips error bars and significance tests, and MAUD is one dataset; we don't know how it holds on other table types like those with many columns or nested data. The baselines seem standard but their exact setups aren't detailed enough in the abstract to rule out implementation differences. This is aimed at practitioners tuning RAG for tabular enterprise data. It is worth sending to peer review because the core idea is simple, the experiments are on a real dataset, and the method can be checked and extended. A referee could ask for the missing controls and more datasets, but the work stands on its own as an engineering step forward.

Referee Report

3 major / 2 minor

Summary. The paper proposes Structure-Aware Tabular Chunking (STC) for RAG over tabular documents. It builds a hierarchical Row Tree with key-value blocks per row, performs token-constrained splitting at structural boundaries, and applies overlap-free greedy merging to produce dense chunks. On the MAUD dataset, STC is reported to cut chunk counts by up to 40% versus recursive baselines and 56% versus key-value baselines while raising hybrid MRR from 0.3576 to 0.5945 and BM25 Recall@1 from 0.366 to 0.754.

Significance. If the gains are shown to arise specifically from structure preservation rather than from incidental changes in chunk cardinality or merging heuristics, the work would supply a practical, immediately usable improvement for enterprise RAG pipelines that ingest CSV/Excel data. The concrete metric deltas on MAUD constitute a useful empirical anchor for future tabular-chunking research.

major comments (3)

[§4 and abstract] §4 (Experimental Results) and abstract: the reported lifts (MRR 0.3576→0.5945, Recall@1 0.366→0.754) are presented without error bars, statistical significance tests, or a full description of data splits and baseline implementations. This omission makes it impossible to judge whether the differences are robust or could be explained by implementation details.
[§3.2–3.3 and §4.2] §3.2–3.3 and §4.2: no ablation is provided that fixes chunk-size distribution and merge policy while removing only the row-boundary awareness (e.g., a row-agnostic token-packing baseline matched to the same length statistics). Without this control, the central claim that gains derive from “preserving intra-row semantic relationships” cannot be isolated from the simultaneous 40–56% reduction in chunk count.
[§4.3] §4.3: MAUD is the sole evaluation corpus; no cross-dataset validation on other tabular collections (e.g., financial statements, scientific tables, or synthetic row-structured data) is reported, leaving open whether the observed advantages generalize beyond the specific characteristics of MAUD.

minor comments (2)

[abstract] The abstract states “improving token utilization” but supplies no quantitative metric (e.g., average tokens per chunk or packing density) to support the claim.
[§3] Notation for the Row Tree construction and the greedy merge heuristic could be formalized with pseudocode or a small worked example to aid reproducibility.

Simulated Author's Rebuttal

3 responses · 1 unresolved

We thank the referee for the constructive feedback, which highlights important aspects for improving the clarity and rigor of our work. We address each major comment below and commit to revisions that strengthen the manuscript without misrepresenting our current results.

read point-by-point responses

Referee: [§4 and abstract] §4 (Experimental Results) and abstract: the reported lifts (MRR 0.3576→0.5945, Recall@1 0.366→0.754) are presented without error bars, statistical significance tests, or a full description of data splits and baseline implementations. This omission makes it impossible to judge whether the differences are robust or could be explained by implementation details.

Authors: We agree that error bars, statistical tests, and fuller experimental details are necessary to establish robustness. In the revised version we will add bootstrap-derived 95% confidence intervals for all metrics and report paired significance tests (Wilcoxon signed-rank) between STC and each baseline. Section 4.1 will be expanded with the precise 70/15/15 train/validation/test split on MAUD and with explicit parameter settings plus pseudocode for the recursive and key-value baselines to ensure full reproducibility. revision: yes
Referee: [§3.2–3.3 and §4.2] §3.2–3.3 and §4.2: no ablation is provided that fixes chunk-size distribution and merge policy while removing only the row-boundary awareness (e.g., a row-agnostic token-packing baseline matched to the same length statistics). Without this control, the central claim that gains derive from “preserving intra-row semantic relationships” cannot be isolated from the simultaneous 40–56% reduction in chunk count.

Authors: We acknowledge that the current comparisons do not fully isolate row-boundary awareness from changes in chunk cardinality. We will add a controlled ablation baseline that performs greedy token packing while deliberately ignoring row boundaries yet matches the exact chunk-length distribution and merge policy of STC. Results from this baseline will be reported in a new subsection of §4.2 to separate the contribution of structural alignment from mere reductions in chunk count. revision: yes
Referee: [§4.3] §4.3: MAUD is the sole evaluation corpus; no cross-dataset validation on other tabular collections (e.g., financial statements, scientific tables, or synthetic row-structured data) is reported, leaving open whether the observed advantages generalize beyond the specific characteristics of MAUD.

Authors: We recognize that evaluation on a single corpus limits claims of broad generalizability. MAUD was chosen for its complex, real-world legal tabular data that mirrors enterprise use cases. In the revision we will expand the discussion in §4.3 and the conclusion to characterize MAUD’s structural properties, explicitly state the single-dataset limitation, and outline concrete directions for future validation on financial statements, scientific tables, and synthetic row-structured data. revision: partial

standing simulated objections not resolved

Empirical results on additional tabular datasets beyond MAUD

Circularity Check

0 steps flagged

No circularity: empirical comparisons to external baselines

full rationale

The paper introduces a structure-aware chunking method (Row Tree, key-value blocks, boundary-aligned splitting, overlap-free merge) and reports direct empirical outcomes on the MAUD dataset: chunk-count reductions versus recursive and key-value baselines, plus standard retrieval metrics (MRR, Recall@1) versus the same baselines. No equations, fitted parameters, or derivations are presented whose outputs are equivalent to their inputs by construction. Retrieval metrics are externally defined and independent of the chunking procedure. The central claims rest on measured differences against non-self-referential baselines rather than on any self-citation chain or self-definitional loop.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The work is an algorithmic proposal validated empirically; it introduces no explicit free parameters, mathematical axioms, or new postulated entities beyond the standard assumption that tabular rows carry coherent semantic units.

pith-pipeline@v0.9.0 · 5539 in / 1181 out tokens · 60307 ms · 2026-05-09T20:06:06.815547+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

14 extracted references · 9 canonical work pages · 3 internal anchors

[2]

Longformer: The Long-Document Transformer

I. Beltagy, M. E. Peters, and A. Cohan, “Longformer: The long- document transformer,” https://arxiv.org/pdf/2004.05150, 2020, arXiv preprint

work page internal anchor Pith review arXiv 2004
[3]

Texttiling: Segmenting text into multi-paragraph subtopic passages,

M. A. Hearst, “Texttiling: Segmenting text into multi-paragraph subtopic passages,” https://aclanthology.org/J97-1003.pdf, 1997

1997
[4]

A systematic investigation of document chunking strategies and embed- ding sensitivity,

“A systematic investigation of document chunking strategies and embed- ding sensitivity,” https://arxiv.org/abs/2603.06976, 2026, arXiv preprint

work page arXiv 2026
[5]

Reconstructing context: Evaluating advanced chunking strategies for retrieval-augmented generation,

C. Merola and J. Singh, “Reconstructing context: Evaluating advanced chunking strategies for retrieval-augmented generation,” https://arxiv. org/abs/2504.19754, 2025

work page arXiv 2025
[6]

arXiv preprint arXiv:2506.15655 (2025)

Y . Zhang, X. Zhao, Z. Z. Wang, C. Yang, J. Wei, and T. Wu, “Cast: Enhancing code retrieval-augmented generation with structural chunking via abstract syntax tree,” https://arxiv.org/abs/2506.15655, 2025

work page arXiv 2025
[7]

Langchain,

H. Chase, “Langchain,” 2022. [Online]. Available: https://github.com/ langchain-ai/langchain

2022
[8]

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

P. Lewis, E. Perez, A. Piktus, F. Petroni, V . Karpukhin, N. Goyal, H. K¨uttler, M. Lewis, W.-t. Yih, T. Rockt¨aschel, S. Riedel, and D. Kiela, “Retrieval-augmented generation for knowledge-intensive nlp tasks,” https://arxiv.org/abs/2005.11401, 2020

work page internal anchor Pith review arXiv 2005
[9]

Lost in the Middle: How Language Models Use Long Contexts

N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the middle: How language models use long contexts,” https://arxiv.org/abs/2307.03172, 2023

work page internal anchor Pith review Pith/arXiv arXiv 2023
[10]

Text segmentation as a supervised learning task,

O. Koshorek, A. Cohen, N. Mor, M. Rotman, and J. Berant, “Text segmentation as a supervised learning task,” https://arxiv.org/abs/1803. 09337, 2018

2018
[11]

Tabert: Pretraining for joint understanding of textual and tabular data,

P. Yin, G. Neubig, W.-t. Yih, and S. Riedel, “Tabert: Pretraining for joint understanding of textual and tabular data,” https://arxiv.org/abs/ 2005.08314, 2020

work page arXiv 2005
[12]

Tapas: Weakly supervised table parsing via pre-training,

J. Herzig, P. K. Nowak, T. M ¨uller, F. Piccinno, and J. M. Eisenschlos, “Tapas: Weakly supervised table parsing via pre-training,” https://arxiv. org/abs/2004.02349, 2020

work page arXiv 2004
[13]

Turl: Table understanding through representation learning,

X. Deng, H. Sun, A. Lees, Y . Wu, and C. Yu, “Turl: Table understanding through representation learning,” https://arxiv.org/abs/2006.14806, 2020

work page arXiv 2006
[14]

Merger agreement understanding dataset (maud),

T. A. Project, “Merger agreement understanding dataset (maud),” https: //huggingface.co/datasets/theatticusproject/maud, 2021

2021
[15]

Sec edgar database,

U.S. Securities and Exchange Commission, “Sec edgar database,” https: //www.sec.gov/edgar.shtml, 2024

2024