RAG Table Chunking: Why Rows Need Headers, Units, and Scoped Notes

From a Single Row, Find Its Dependent Explanations

The article opens with a concrete failure case: a knowledge base contains an inspection pricing table. A user asks for the cost of an industrial pump. Retrieval returns the correct row — "Industrial Pump, 180, 260" — but the model must guess which number is the regular price, which is the urgent price, whether the unit is per unit or per service, and whether taxes or other fees apply. In the original table these answers are explicit: a two-level header ("Inspection Unit Price" → "Regular" / "Urgent"), a shared unit "Yuan/Unit/Trip" in the top-right corner, a general note below the table ("Price includes labor, excludes tax"), and a scoped note ("High-temperature pump only: consumables charged separately"). When the table is sliced into chunks, these explanatory elements may end up in different chunks or be dropped entirely.

The core principle: table chunking must preserve the relationship between a number and the conditions that explain it. Chunk size determines how much content fits; these relationships determine whether the content remains understandable.

Headers: Copy the Full Column Path, Not Just the Bottom Level

The synthetic example table spans pages 3–4, titled "Inspection Service Quotation." It has four rows (two instrument rows, two power-equipment rows) and two-level headers. The top level is "Inspection Unit Price"; the second level splits into "Regular" and "Urgent." Both columns share the unit "Yuan/Unit/Trip." When extracting only the industrial-pump row, the chunk must carry the full column path — "Inspection Unit Price / Regular" — not just "Regular," because "Regular" alone could refer to price or lead time. Merged cells in the original table that express hierarchy must be expanded into explicit column paths when entering a sub-chunk; the model cannot be expected to infer the upper-level name from a row of blanks.

Row Groups: Preserve Grouping Context Across Splits

Row direction has the same issue. The original table merges "Power Equipment" across two rows (industrial pump and high-temperature pump), leaving the high-temperature pump's group cell blank. That blank means "inherit the group from above," not "no group." The parsed logical table must retain this membership. When chunking, each sub-chunk must inherit its group label. Otherwise, if a split happens to start at the high-temperature pump row, the group label is lost. A "complete row group" is a set of rows that preserves the current business relationships. Instrument and power equipment can form separate chunks. If a group is still too long, it can be further split, but every sub-chunk must inherit its own group annotation. Cutting by complete rows is the baseline; retaining the context each row depends on is the goal.

Notes Must Follow and Know Their Scope

General notes ("Price includes labor, excludes tax") apply to all four rows and can enter both row-group chunks. The scoped note ("High-temperature pump only: consumables charged separately") applies only to the high-temperature pump and must travel with the chunk containing that row. Copying all footnotes into every chunk creates duplication and introduces ambiguity for rows that have no extra conditions. Moreover, when industrial pump and high-temperature pump happen to land in the same chunk, the chunk must carry the high-temperature pump note but must not imply that the note applies to every row in the chunk. Notes must retain their scope — e.g., the row identifier they belong to, and the original marker or region relationship. When generating readable text, the scope should be explicit: "High-temperature pump only: consumables charged separately" is safer than a lone "Consumables charged separately" at the chunk's end. Retrieving the industrial pump returns the general note; retrieving the high-temperature pump adds its specific note. Chunk containment of a note and row applicability of a note are two separate judgments.

Units also have scope. In this example both price columns share "Yuan/Unit/Trip"; in a table mixing prices and lead times, the price column and the day column cannot share a single unit field. Binding units to columns is more precise than letting "Yuan" appear once somewhere in the chunk.

These relationships are best kept in structured form before generating text for retrieval and reading. Original cells serve for verification; expanded column paths and groups serve for explanation; note scopes serve for condition restriction. If only a flattened string remains, it becomes hard to judge which row a note originally constrained.

Comparing Two Chunking Methods with the Same Numbers

To make the difference visible, the author ran an offline micro-experiment. Input: the hand-crafted logical table described above (four rows, two groups, two-level headers, one price unit, two notes with different scopes). Merged-cell ownership was pre-resolved; the experiment starts from that point and compares two splitting strategies. Both strategies split by instrument group and power-equipment group (two chunks each). Strategy A keeps only raw row content. Strategy B attaches table title, full header paths, units, group labels, applicable notes, plus parent-table ID and original page locations. Every original cell in both strategies matches exactly — no extra rows, no missing prices.

Evaluation fixes the target row and column position, equivalent to placing the same hit in front of the evaluator and checking what explanations it carries. This isolates the chunking problem from retrieval ranking. The query reader only reads existing fields; missing column names or units are left blank — no guessing.

Four checkpoints: industrial pump regular price, industrial pump urgent price, high-temperature pump urgent price, and page-1 pressure-gauge regular price. Both strategies retrieve the correct numbers at the preset positions. The bare-row strategy lacks full column explanations, unit-to-note bindings; the context-enriched row groups retrieve all that information together.

The high-temperature pump item has two extra checks. Its left-group cell, originally blank, can be restored to "Power Equipment" via the known relationship. Reading the urgent price 320 returns both the general note and the high-temperature pump note. Reading the industrial pump 180 in the same chunk returns the general note but does not attach the consumables note. This shows that when hit position and numbers are identical, whether the chunk retains context directly changes what explanations it can provide. The experiment does not test OCR accuracy or real-query recall; the next step — integrating retrieval — must separately verify whether user questions can hit these row groups. Field-level checking cannot substitute for that work.

A Parent Table May Need Multiple Original Page Locations

The high-temperature pump's data row is on page 4; headers and unit are on page 3; the general note is on page 3; the consumables note is on page 4. If a chunk stores only one page number, whether it is 3 or 4, it only accounts for part of the source. Therefore, a sub-chunk must keep a common parent-table identity and also keep precise original-page anchors for each piece of content. The parent-table ID says which logical table it belongs to; row ID and chunk order say which part it is; page numbers and region coordinates say where the row, header, unit, and notes each came from.

In the experiment, the high-temperature pump row points to mid-page 4; headers and unit each point to upper page 3; the two notes point back to page 3 and page 4 respectively. Following these anchors lets one verify that 320 falls in the urgent column and that the consumables note indeed points to the high-temperature pump. A cross-page range can only say where the table is; precise anchors say where the evidence is.

This also bounds context recovery. After hitting the high-temperature pump, one can fetch missing headers via the parent table and fetch necessary conditions via note relationships. There is no need to stuff all nearby chunks back in. The next chunk might belong to a spare-parts table; physical proximity does not imply semantic unity. The parent-table relationship itself must have a trustworthy origin. When page parsing yields two table regions, one must first decide whether they form a continuation table before doing row-group splitting. If that judgment is wrong, the more complete the copied headers, the more the inherited error resembles a complete fact.

Same Column Count Isn't Enough for Cross-Page Merging

Page 5 contains a "Spare Parts Price" table. It also has four columns, but column names are Category, Spare Part, Purchase Price, Retail Price, and the unit becomes Yuan/Piece. A merge rule that only compares column count would attach it to the inspection quotation, letting spare-part prices inherit the inspection unit-price interpretation. The micro-experiment includes this counterexample. A column-count-only rule says merge; adding title, column semantics, and unit conflict checks keeps them separate. Only when two pages have explicit continuation pointers, continuing titles, and no conflicts are they linked according to the known relationships in the synthetic input. A page with only matching column count but unclear title, unit, and continuation status is kept as an unresolved region, not forced into the parent table. Real materials can also use column positions, page boundaries, continuation markers, etc., but these signals must be validated on one's own samples; no single signal can be written as a universal guarantee.

Preserving pre-merge page regions is especially useful. When rules are uncertain, the two segments can remain independent, recording candidate associations; later, with additional evidence or human review, the parent table can be rebuilt. If one first rewrites two pages into one table and discards the original regions, a false merge often only surfaces after wrong answers appear, forcing a guess at where the problem originated.

Full Context Also Has Duplication Costs

Attaching full headers to every row makes independent reading easier, but long tables create massive duplication. In this micro-experiment, two rows per group (two chunks) produce 214 total characters with context. Switching to one row per chunk (four chunks) grows the text to 336 characters; the context portion alone rises from 133 to 255 characters. These numbers are script-counted character lengths under a fixed text format, illustrating how duplication grows when splitting finer. Actual storage is also affected by text representation, group size, and model tokenization, so no universal chunk size can be derived from this. A better approach: first find natural row groups, then simultaneously check explanation completeness and duplication cost.

Enterprise RAG projects place table structure restoration in the parsing pipeline. When discussing such projects, one can trace responsibility along a single price row: parsing preserves row-column ownership; chunking carries the context needed for explanation; source relationships support tracing back to the original page for verification. Every layer has concrete inputs and verifiable outputs. Hence, when an interviewer asks "How do you chunk a large table?" the answer can land on a concrete test: take a row from page two and see if it can independently state which device, which price type, what unit, which conditions, and where each piece of evidence lives in the source. The final measure is not how small the table is cut, but whether the cut-out numbers still carry complete meaning — that proves the split preserved structure.