TECHNOLOGY

Chunk tables for RAG without losing column headers and units

In this article
THE QUICK TAKE

A table fragment needs its header path, units and source identity to make a retrieved value interpretable.

A retrievable table fragment needs enough structure to explain what each value means, not merely the characters from one row. Preserve column headers, units and source identity before embedding table evidence for RAG.

Start from a structured table

The Docling table-export example works with table objects rather than treating the page as one unstructured text stream. This guide assumes extraction has already produced a table worth inspecting. OCR accuracy and cell-span reconstruction remain separate upstream checks. A chunking policy cannot repair a value assigned to the wrong column by the parser, so keep the extracted table linked to the source page.

Preserve the semantic header path

The document model supports tables and provenance within a larger hierarchy. A value can inherit meaning from several header levels, a caption or a unit outside its immediate row. Decide which of those labels must accompany each retrievable fragment. Repeating only the nearest short header may lose the distinction between a measured value, a limit and a historical comparison in the same table.

Use a deliberately small fixture

Consider this illustrative inventory, which is not a hardware specification or measured dataset.

ItemCapacityUnit
Tank A12L
Tank B8L

A fragment containing only “Tank A, 12” is less interpretable than one retaining the capacity header and unit. Add a caption describing the table’s scope, then ask whether the chunk still distinguishes capacity from another quantity. The point is preserving the relationship, not choosing one universal textual layout.

Choose row and table boundaries deliberately

The chunking reference describes contextualized serialization of structural units. A compact table may remain one unit, while a large table can need smaller fragments. If rows are split, retain table identity and the relevant header path in each output. Keep a way to reconstruct neighboring rows when a question requires comparison. Do not duplicate an entire large table into every chunk merely to avoid making a boundary decision.

Verify answers against cells

Prepare questions that require a value with its unit, comparison between rows and a condition from a header or caption. Judge the retrieved fragment against the original cells before evaluating the generated answer. A fluent answer can still associate the correct number with the wrong item. Preserve both source table coordinates and serialized evidence, making extraction errors distinguishable from retrieval misses and answer-generation mistakes.

Retain an evidence-oriented export

Store document revision, table ID, row or cell span, header context and the exact text embedded. Keep the original structured object alongside any Markdown representation. After changing serialization, rerun the same fixture to see whether meaning survived. The accepted policy explains how a reader can recover the value’s scope from a retrieved fragment. It does not equate a successful Markdown export with correct table understanding or guaranteed downstream answers.

Related reading: A GPU OCR pipeline for a 1,000-page PDF workload; A local RAG server: placing components around the GPU.

← All articles