LTEM: LLM-Friendly Table-Enhanced Markdown for Table Understanding and Generation

AI summary

Overview

Research area: Natural Language Processing — specifically how tables are serialized (written out as text) for Large Language Models, covering both table question answering and table generation.

Technical level: Intermediate. Readers should be comfortable with standard table markups (Markdown, CSV, HTML, LaTeX) and basic LLM evaluation metrics, but no specialized table-parsing background is required.

Scope: The paper introduces a taxonomy of table structural complexity, a synthetic benchmark built on that taxonomy, and a new Markdown-derived table format (LTEM), then compares six serialization formats across five LLMs on table understanding and three LLMs on table generation, with token-efficiency analysis.

What This Paper Is About

Real documents contain tables with merged cells, multi-level headers, and stacked sections, but the formats LLMs handle most easily (Markdown, CSV) cannot express those structures at all, while the formats that can (HTML, LaTeX) cost more tokens and are harder to parse. The authors argue that prior work shows "format matters" without providing a tool for saying which structural information each format preserves, so they build a feature-based taxonomy, a controlled benchmark, and a minimal Markdown extension called LTEM that explicitly marks spans and header hierarchy.

Key Contributions

1. A structural complexity taxonomy. Six atomic features (F1 Grid Formation, F2 Header Designation, F3 Cell Merging, F4 Header Nesting, F5 Section Stacking, F6 Table Composition) and six cumulative complexity levels (L1–L6), where each level requires all features of the levels below it. The authors use this to classify the expressiveness of CSV, Markdown, MultiMarkdown, HTML, and LaTeX.

2. STB (Synthetic Table Benchmark). A controlled benchmark of 1,089 tables and 4,356 question–answer pairs (about 4 QA pairs per table), systematically distributed across complexity levels, with roughly 30% of tables at L3 — the first level requiring cell merging, and the boundary where Markdown and CSV become structurally incapable.

3. LTEM (LLM-friendly Table-Enhanced Markdown). A formally specified, minimal extension of Markdown adding only seven syntax elements: four for spans (<<, ^^, {c:N}, {r:N}), one for in-cell line breaks, one for table identification (| # id |), and one for references (@). It is defined by a context-free grammar in EBNF with syntax validation rules V1–V12, and is designed to be parsable in a single pass.

4. An empirical trade-off analysis. Comparisons of six formats on table understanding, table generation, and token-normalized efficiency, across five LLMs for understanding and three for generation, with McNemar tests on paired predictions over three repeated runs.

Main Findings

• LTEM matches HTML on understanding accuracy (STB). Average nEM over five models and three runs is 0.813 for LTEM versus 0.812 for HTML, with MultiMarkdown at 0.810, Markdown at 0.810, CSV at 0.808, and LaTeX lowest at 0.777. TokenF1 is 0.844 for both LTEM and HTML.

• LTEM has the lowest total error rate on STB. Refusal 0.15%, Invalid 0.14%, Total Error 0.29%, versus CSV 0.31%, HTML 0.41%, MultiMarkdown 0.49%, Markdown 0.61%, and LaTeX 3.04%. LaTeX's total is dominated by an Invalid rate of 2.67%, attributed primarily to formatting and parsing failures.

• LTEM is more token-efficient than HTML and LaTeX at comparable accuracy. Average prompt tokens are 449 for LTEM, 612 for HTML, and 447 for LaTeX, with table tokens of 228, 392, and 227 respectively. The token-normalized score (nEM per prompt token × 1000) is 1.809 for LTEM, 1.326 for HTML, and 1.737 for LaTeX; the shortest formats score highest on this metric (CSV 2.183, MultiMarkdown 1.858, Markdown 1.852).

• LTEM beats LaTeX significantly for four of five models. McNemar tests (Fisher-combined, p < 0.01) show LTEM significantly outperforming LaTeX on STB for four of the five models; Gemini-2.5-Pro shows no significant difference. The paper notes that some models are particularly sensitive to LaTeX serialization (Qwen3-235B shows a large degradation) while LTEM stays stable.

• Accuracy drops at structural transitions. On STB, average nEM declines from L2 to L3 and further at L4 — the points where cell merging and multi-level headers appear. The authors frame this as the boundary LTEM is designed to disambiguate.

• Format rankings do not transfer to real-world tables. On HiTab, absolute accuracy falls and ordering shifts: average nEM is 0.295 for HTML, 0.292 for LaTeX, and 0.289 for LTEM, a 0.6 percentage-point spread.

• HTML wins table generation; LTEM is near MultiMarkdown. Reconstructing HiTab tables from natural-language descriptions only, HTML achieves ANLS 0.913 and a Good+ rate (ANLS ≥ 0.7) of 96.2%. LaTeX reaches 0.749 / 72.2%, MultiMarkdown 0.734 / 69.0%, LTEM 0.720 / 67.9%, CSV 0.618 / 50.0%, and Markdown 0.549 / 41.2%. Prompt tokens for generation are 1,429 for LTEM versus 1,149 for HTML, with LTEM's count including an extra syntax guide.

• Training exposure is a plausible confound. The authors acknowledge that pretraining corpora contain far more HTML and Markdown tables than LTEM content (they cite GitHub at 4.5% and StackExchange at 2% of the LLaMA corpus), and that HTML's generation lead — including 76% Excellent (ANLS ≥ 0.9) — may partly reflect this imbalance. A small LoRA pilot reported in Appendix H.5 shows 4B-scale models can adapt to LTEM with limited supervision.

Methodology in Plain English

The authors start by asking what a table serialization actually has to do. They break table structure into six independent yes/no capabilities — does it place cells on a grid, mark which cells are headers, merge cells, nest headers, stack sections with the same columns, and combine tables with different schemas — and check each format against them. That table of checkmarks shows a stark split: Markdown and CSV fail at cell merging, which means they cannot structurally represent any table at L3 or above; only LaTeX covers all six features.

They then design LTEM to fill the gap, following five principles: stay a superset of Markdown so LLMs can lean on what they already know, keep the source readable top-to-bottom, make structure explicit with markers rather than implicit rules, add as few new symbols as possible, and allow single-pass parsing. Merged cells are marked with << (merge left) or ^^ (merge up), or with compact attributes like {c:5} or {c:2,r:2}; any row above the separator line counts as a header row, which gives multi-level headers for free; nested tables inside cells are replaced by separate tables linked with | # id | and @ref, analogous to database normalization.

To test the formats fairly, they needed tables of controlled complexity, so they built STB: table structure (rows, columns, merging patterns) is set by rules, Claude Sonnet 4.5 and Opus 4.5 fill in realistic headers and values across five domains (Scientific, Financial, Product, Survey, Schedule), and GPT-5-mini writes the questions in four types (LOOKUP, COUNTING, COMPARISON, AGGREGATION). Because automatically generated QA can be wrong, they keep a sample only if two models from different families (Qwen3-VL-8B-Instruct and Phi-4-mini-instruct) both agree with the generated answer under the same normalization. They then evaluate on STB and on HiTab's test split, converting each HiTab table into all six formats.

For understanding, the main metric is normalized Exact Match, with token-level F1 and a numeric Exact Match variant, plus a breakdown of errors into Refusal and Invalid. For generation, exact reproduction is unrealistic, so they use ANLS (normalized string similarity) with Good+ and Excellent thresholds. For efficiency, they divide accuracy by prompt token count, subtracting out any fixed-length format guide so LTEM is not penalized for its instructions. Statistical claims rest on three repeated runs per model–format setting and McNemar tests on paired predictions.

Why This Matters

Impact on research. The paper reframes table serialization as a measurable variable rather than a preprocessing choice. The F1–F6 / L1–L6 taxonomy and STB give other researchers reusable instruments for asking which structural operation a format fails at, and the finding that format rankings flip between the synthetic STB and the real-world HiTab is a caution against generalizing format conclusions from a single benchmark.

Real-world applications:

• Document editing and report writing, where an LLM must emit tables with merged cells and grouped headers that a downstream renderer or human can read.
• Financial and statistical reporting, where section-stacked tables (e.g., separate blocks per model or per period) are common.
• Scientific paper processing, where complex tables must be handed to an LLM without the token overhead of HTML or LaTeX.
• Structured data extraction and summarization pipelines, where LaTeX's 2.67% invalid-response rate would mean frequent parse failures.

Industry relevance. The accuracy–token trade-off is a direct cost question: at comparable nEM, HTML uses 612 prompt tokens versus 449 for LTEM. The finding that format effects vary substantially by model implies that format choice must be validated on the specific deployment backbone, not chosen generically.

Future Directions

• Test formats on domain-matched validation sets. The authors state that because STB and HiTab rank formats differently, a format's superiority cannot be generalized from one benchmark, and formats should be re-evaluated on data matching the target distribution — including OCR-extracted, noisy financial, or log tables that HiTab does not cover.

• Reduce the pretraining-exposure gap. LTEM is introduced in this work, so models have seen far more HTML and Markdown tables. A larger-scale adaptation study (the paper reports only a small 4B-scale LoRA pilot) would test how much of LTEM's generation deficit relative to HTML is a training-data artifact.

• Separate model effects from format effects. Some model–format pairs show atypical behavior such as elevated invalid-response rates, so a systematic map of which models are fragile under which serialization — and why — remains open.

• Stress-test the results against prompting and decoding choices. The authors note that output length constraints, instruction wording, and post-processing rules can shift invalid/refusal rates for verbose formats like LaTeX, and that rankings may change under different settings.

Target Audience

Researchers and engineers working on LLM–table interaction, table question answering, or structured-output generation who need to choose or design a serialization format; benchmark builders interested in controlled, complexity-stratified datasets; and practitioners building document-processing or report-generation systems where token cost and output-parse reliability both matter. Readers looking for a state-of-the-art table reasoning model or a new QA dataset for leaderboard comparison will find this paper is about representation, not modeling.

Authors’ abstract

Tables in real-world documents, including scientific papers, financial reports, and statistical summaries, frequently use merged cells, multi-level headers, and sectioned layouts. Yet the lightweight formats LLMs handle best (Markdown, CSV) cannot express these structures, while expressive formats (HTML, LaTeX) impose excessive token cost and parsing complexity. To enable systematic analysis of this trade-off, we introduce a taxonomy decomposing table structure into six atomic features (F1-F6) and corresponding complexity levels (L1-L6), and construct STB (Synthetic Table Benchmark), a controlled benchmark with 1,089 tables systematically distributed across complexity levels. Using this framework, we propose LTEM (LLM-friendly Table-Enhanced Markdown), a formally specified, minimal extension of Markdown that explicitly encodes spans and hierarchical headers. Experiments across five state-of-the-art LLMs show that LTEM achieves accuracy comparable to HTML, offers a favorable accuracy-token trade-off relative to HTML and LaTeX, and produces substantially fewer invalid responses than LaTeX; for table generation, LTEM is comparable to MultiMarkdown though HTML is best. We release our taxonomy, benchmark, and format specification to support future research on LLM-table interaction.