Same Content, Different Representations: A Controlled Study for Table QA
Authors: Yue Zhang
Seiji Maekawa
Nikita Bhutani
Venue: ICLR 2026 Poster (2026)
Keywords: Table Question Answering
Semi-structured Table
Structured Table
Primary area: datasets and benchmarks

Abstract: Table Question Answering (Table QA) in real-world settings must operate over both structured databases and semi-structured tables containing textual fields. However, existing benchmarks are tied to fixed data formats and have not systematically examined how representation itself affects model performance.
We present the first controlled study that isolates the role of table representation by holding content constant while varying structure. Using a verbalization pipeline, we generate paired structured and semi-structured tables, enabling direct comparisons across modeling paradigms. To support detailed analysis, we introduce a diagnostic benchmark with splits along table size, join requirements, query complexity, and schema quality.
Our experiments reveal consistent trade-offs: SQL-based methods achieve high accuracy on structured inputs but degrade on semi-structured data, LLMs exhibit flexibility but reduced precision, and hybrid approaches strike a balance, particularly under noisy schemas. These effects intensify with larger tables and more complex queries.
Ultimately, no single method excels across all conditions, and we highlight the central role of representation in shaping Table QA performance. Our findings provide actionable insights for model selection and design, paving the way for more robust hybrid approaches suited for diverse real-world data formats.

Published as a conference paper at ICLR 2026
SAME CONTENT, DIFFERENT REPRESENTATIONS: A CONTROLLED STUDY FOR TABLE QA
Yue Zhang Seiji Mackawa²
Nikita Bhutani²
'Tee University of Texas at Dallas
Megaggon Labs
yxx23014@utcallaas edu
{sei sieajjiinikkttaaeeeggg...
ABSTRACT
Table Question Answering (Table QA) in real-world settings must operate over both structured databases and semi-structured tables containing textual fields. However, existing benchmarks are tied to fixed data formats and have not sys- tematically examined how representation itself affects model performance. We present the first controlled study that isolates the role of table representation by holding content constant while varying structure. Using verbalization pipeline, we generate paired structured and semi-structured tables, enabling direct com- parisons across modeling paradigms. To support detailed analysis, we introduce REPAIRTQA, a diagnostic benchmark with splits along table size, join require- ments, query complexity, and schema quality. Our experiments reveal consistent trade-offs: SQL-based methods achieve high accuracy on structured inputs but de- grade on structuruccddd data, LLMs exhibit flexibility but reduced precision, and hybrid approaches strike balance, particularly under noisy schemas. These ef- fects intensify with larger tables and more complex queries. Ultimately, no single method excels across all conditions, and we highlight the central role of represen- tation in shaping Table QA performance. Our findings provide actionable insights for model selection and design, paving the way for more robust hybrid approaches suited for diverse real- world data formats.
Code
INTRODUCTION
Tables are fundamental medium for storing and communicating information across domains such as finance (Chen al., 2021]. scientific communication (Ghosh al. 2024). biomedical records (Ghosh et al. 2024). and the web (Chakrabarti et al. (020).. Unlocking the knowledge con- tained these tables has motivated extensive research on Table Question Answering (Table QA), where models answer natural language queries grounded in tabular data (Pasupat & Liang 2015 Iyyer et al. 2017). In practice, tables appear in both structured formats with rigid schemas and exccutable SQL queries (Zhong et al., 2017] Li et al. 2023] Wu al.) (202aa). and semi-structured formats where columns are irregular and cells contain free text (Chen et al.) 2021 2020) Singh et al., 2025). Structured tables enable precision and symbolic reasoning, while semi-structured tables of- fer robustness to noise and incomplete metadata. Since both formats coexist in real-world settings, understanding their impact on Table QA methods is crucial.
Despite substantial progress, this key question remains unanswered: how do different modeling paradigms handle variation in table representation? Existing benchmarks focus query domain or complexity (Li et al.) 20233: Wu et al. 2025a Zhu et al., 2025), but fix the table format itself. As result, models are optimized for single representation. leaving their robustness to representation shift unclear. Current approaches fall into three main families: NL.2QQL. methods (Dong & Lapata 2016 Zhong et al., 2017 Liu et al., 2022). LLM --ased methods (Zhang et al., 2025c a), and hybrid methods (Zhang al.) 20244] Ye et al. 2023 Abhyankar et al. [2255] Khoja et al. 2025). NL2SQL methods scale and reason precisely but are brittle under noisy or irregular schemas. LLM-based
Work done during internship Megagon Labss.

---

Published as a conference paper at ICLR 2026
Structured
Semi-structured
Student
Subject
Score
Ramarks
Student
Sugject
Soore
Standing
This performence,
excelient
Alice
Math
Ficeelent
Chorle
History
78
The shudent needs improvement
Chorle
History
7B
Needs Improvement
only get
Diono
Math
A+
Outttonding
Diona
Math
95
Achieiing on stands out with ouistanding results.
Representation-speeffe mothods
NL29OL
Student
Subject
Score
Remarks
Alcce
Math
92
This student eor ned an escellent academic performence.
M-looed
Varying represantations
Choriic scored a with Cinn History.. Hi nceds improvement
Hybri
Diona in nuhhnddinng student. She earned As scoring 95 Motti
b)
Figure 1:
Structured vs. semi-structured formats of the same table pose challenges for Table QA methods that assume a fixed data format.
methods can handle semi-structured inputs containing free text but struggle on complex queries and long tables. Hybrid methods combine symbolic execution with neural reasoning to balance flexibility and precision. Without controlled evaluation of representation effects, practitioners lack guidance method selection, and researchers risk overfitting to narrow benchmark conditions.
To address this gap, we present the first controlled study of table representation Table QA. Our framework generates paired structured and semi-structured tables using verbalization pipeline, holding content constant while varying representation (Figure D enables systematic comparisons across modeling families, task conditions, and evaluation dimensions. Our contributions include:
Controlled comparison of representations: we introduce verbalization pipeline to convert structured tables into semi-structured forms, isolating the effects of representation while preserving semantics.
Fine- grne-grained diagnostic benchmark: decompose task difficulty into four dimensions in- cluding table size, table joins, query complexity, and schema quality. This enables targeted analysis of method strengths and weaknesses.
Comprehensive evaluation: we assess NL2SQL, LLM-based, and hybrid methods on BIRD (Li al. (023), MMQA (Wu et al. 2025a), and TableEval (Zhu et al. (0225) datasets, revealing trade-offs that inform both model design and practical deployment.
Our experiments show that representation structured inputs but drops 30-45% on semi-structured ones. LLMs are more stable (only 3.5% de- cline) but struggle with long or compositional queries. Hybrids fall by under 5% and are generally robust across conditions. These trade-offs intensify with larger tables, complex queries, and noisy schemas. Long tables reduce accuracy for all methods, though NL.2QL remains strong on long structured tables (62.9% accuracy). In contrast, hybrids outperform LLMs on long semi-structured tables, demonstrating better scalability. Multi-table reasoning and query complexity remain chal- lenging across all methods. Schema quality proves especially influential: noisy schemas severely hurt NL2SQL, while verbalization often improves LLMs and hybrids by embedding schema cues in natural language.
major driver of performance. NL2SQL excels on
Ultimately, no single paradigm excels across all conditions. Our findings establish representation as central factor in Table QA, provide actionable insights for method selection, and motivate future hybrid systems to operate robustly across diverse real-world table formats. We will release our framework and benchmark to support ongoing research.
2 EXPLORING POTENTIAL FACTORS OF REASONING
Table QA is challenging not only due to the diversity natural language queries but also due to how information is represented. A model's performance depends jointly on table representation (structured vs. semi-structured) and additional factors such as table size, schema quality, and query complexity. These challenges salient in real-world settings, where tables often large, noisy, and irregularly organized. We first contrast structured and semi-structured representations, then in- troduce four core dimensions that govern reasoning difficulty and ground diagnostic evaluation.
2

---

Published as a conference paper at ICLR 2026
2.1 TABLE REPRESENTATIONS STRUCTURED VS. DEMI-STRUCTURED
Structured tables. Structured tables adhere fixed schemas. Each column encodes predefined attribute and each row conforms to the schema. This consistency enables efficient storage, precise querying, and symbolic approaches such NI.2QQI. (Ramakrishnan & Gehrke 2003). However, most NL2SQL datasets assume idealized schemas, overlooking real-world issues such as missing attributes or misaligned semantics. For instance, a query about the "standing of Alice' becomes invalid if that information is embedded in free text rather than in a dedicated column (Figure
Semi-structured tables. remi-structured tables relax these constraints. Columns may be merged or repurposed (e.g., combining grade and standing), rows may summarize entities, and cells may contain long-form text, lists, or multimodal content. Web tables (Wang et al. 2024) and spread- sheets (Ma et al., 2024) exemplify this format. While they capture rich real- information, their irregular structure complicates parsing, schema alignment, and reasoning.
2.2 CORE DIMENSIONS OF REASONING DIFFICULTY
Prior studies have shown that representational aspects such as table length (Chen et al. (024). multi- table reasoning [Wu al. 2025aj. and query complexity (Zhu et al. (025) substantially affect performance. Yet, these insights remain fragmented across benchmarks, and no framework has systematically examined their interaction with representation. We close this gap by analyzing four core dimensions: table size, table joins, query complexity, and schema quality. By varying these conditions under both structured and semi-structured representations, we disentangle their individual contributions and analyze robustness.
Table size. Large tables strain token windows and increase attention cost quadratically, leading to truncation, sparse supervision, and difficulty locating relevant rows Liu al. (2023); Hsieh et al. (024). LLMs also approximate numbers and struggle with exact comparisons across many values, causing errors in factual and financial QA [hen al. (2019); Zhu al.) (2021). In this work, categorize short tables as under 100 rows and long tables as over 100 rows. We focus on tables that still fit into the context windows of current LLMs. Extending the framework ultra-Iong tables with hundreds or thousands of rows, which likely require chunking or retrieval, is an interesting direction for future work.
Table joins. Joins require aligning schemas and linking rows across multiple tables. This intro- duces challenges of ambiguous keys, irrelevant columns/rows and compositional reasoning. Semi- structured representations exacerbate these issues since explicit keys are often absent. We vary the number of tables per query and the presence of explicit key constraints probe join difficulty.
Query complexity. Queries range from simple lookups to multi-step reasoning involving aggrega- tion, filtering, comparisons, and arithmetic. Existing datasets often target narrow slices (e.g., SQL. lookups (Zhong et al. 2017), logical forms over web tables (Pasupat & Liang 2015), or discrete reasoning (Zhu et al., 2021)). remains unclear how methods scale from lookups to multi-step reasoning, particularly across table representations.
Schema quality. Schema encodes column names, data types, keys, and relationships. While curated databases maintain consistent schemas, real-world tables often have missing headers, inconsistent formatting, and absent metadata. Such noise can severely affect symbolic methods.
Together, these factors define the major dimensions of Table QA difficulty. By systematically vary- ing them under both structured and semi-structuree settings, we disentangle their individual contri- butions and assess model robustness.
REPAIRTQA: FINE-GRAINED DIAGNOSTIC BENCHMARK
To systematically study the impact of table representations and disentangle the effects of the four factors outlined Section 2 we construct REPAIRTQA, a fine-graing mne-grained diagnostic benchmark. Our design follows two guiding principles: (1) Representation pairing. Comparing structured and semi-structured Table QA requires identical semantics; otherwise, differences may reflect content mismatches. We achieve this by transforming structured tables into semi-structured ones via
3

---

Published as a conference paper at ICLR 2026
Sttdtntt Subject
Standing
Column
Shudent
Subject Score
Remories
Alice
Noth
92
Exccllent
Grade Standing
(Standing) academis performance (Srede).
This student (Shoce)
Alice
Math
92
excelien ent acaderic performence
stutent somed
Bob
Science 85
Good
Grede
this student performing (5honding)
Science
65
grade
performing
Chorlie
History 78
Needs
Grodk Standing
indicating standing (Stoncleg)
Chorite
History
78
nnstooinng stonding outstonding results.
student recerved
Diana
Math
Outstandny
Grade Standing
Achiesing d(n) (Srode)) out with (Stunding) resuhs.
Diana
Math
95
1. Column Selection
Template Construction
3. Seriolization
Figure 2: Verbalization pipeline for transforming structured tables into semi-structured representa-
tions while preserving semanties.
trolled verbalization strategy, (2) Factor isolation. We partition existing benchmarks into controlled subsets that vary along the core factors. This allows us to assess each factor's impact independently.
3.1 VERBALIZATION PIPELINE
Given QA pair over a structured table, our verbalization pipeline produces a semi-structured variant of the same table. Each question is thus paired with two versions of its table: structured and semi- structured. The pipeline consists of three steps, illustrated in Figure
1. Column selection. We first determine which columns to verbalize into free text. GPT-4o identi- fies suitable candidate columns, from which sample random combinations to introduce diver- sity across instances. We experimented with three alternative selection strategies (Appendix [B) and found comparable performance trends. We, hence, adopt the random strategy the default.
2. Template construction. For the selected columns, we generate natural language templates con- ditioned on the table schema, into which column values are inserted to form descriptive sentences. To reduce annotation cost, GPT-40 produces candidate templates, which are lightly corrected for errors. For each column combination, we create five diverse templates to increase variation.
3. Serialization. Finally, templates are instantiated with table values, merging verbalized content into a single free-text column while removing the original structured columns. The resulting semi-structured table mirrors the semantics of the original but encodes them in text-heavy, less rigid format. Both versions are retained for side-by-side evaluation.
3.2 DIAGNOSTIC SPLITS
To isolate the effects of representational and structural factors, partition benchmarks into trolled subsets rather than treating them as monolithic. Each split targets one of four dimensions: table size, number of tables, query complexity, and schema quality. This design allows us identify settings where different paradigms succeed or fail and provides fine-grained view of robustness captured by benchmark-level scores.
We construct diagnostic splits from three complementary benchmarks: 1) BIRD et al. 2023)
a large-scale, curated dataset with clean schemas and reliable evaluation protocols, representing the best-case setting for structured Table QA. 2) MMQA (Wu et al. (2025):: a benchmark explicitly de- signed for multi-table reasoning, where questions require retrieving and integrating evidence across multiple relational tables. 3) TableEval (Zhu et al., 2025): : collection of real-world web tables with noisy schemas, incomplete metadata, and inconsistent formatting, reflecting practical deploy- ment challenges. Together, these datasets span clean to noisy conditions and single- to multi-table reasoning, providing broad testbed for our diagnostic evaluation. Table summarizes the resulting fine-graines diagnostic splits.
4 EXPERIMENTAL SETUP
We now describe our evaluation protocol for isolating representation effects, including research questions, baselines, and metrics.
4

---

Published as a conference paper at ICLR 2026
Table 1: Diagnostic splits for factors: table length, no, of tables, query complexity, schema quality,
Subset ID
Data Source
Table Joins
Length
Query Complexity
Schema
#Samples
short
lookup
S2
TahleEval
short
lookup
incomplete
169
S3
BIRD
X
short
compositional reasoning
clean
435
BIRD
long X
lookup
S5
BIRD
long
compositional reasoning
clean
258
MI
MMQA
short
compositional reasoning
cleun
427
MMQA
long
compositional reasoning
166
4.1 RESEARCH QUESTIONS
We organize our comparison actoss method families around five key questions: RQ1. How does performance vary across paradigms when comparing structured and semi-structured inputs with identical content? RQ2. How do methods scale from short (<100 rows) to long (2 100 rows) tables? RQ3. How do multi-table alignment and join operations affect performance? RQ4. How does performance change from simple lookups to multi-step compositional queries (filters, aggregations, joins, comparisons)? RQ5. How robust are methods under noisy or incomplete schemas?
4.2 BASELINES AND SETUPS
We evaluate three method families by selecting representative methods from each family.
(Hurst et al. 2024), Gemini-2.5-flast Anil et al. 2023). and Qwen 3 YYang et al. 2025) as baselines for directly predicting the answer without any SQL exe- cution. The detailed prompts shown in Appendix
LLMs. We use GPT-4d
NL2SQL methods. We include two approaches that generate SQL queries. a) LLM-NL2SQL
baseline: two-stage pipeline where LLM generates SQL from the question and schema, executed via SQLite. We provide schema information (tables, columns, keys) and small set of example values per column via value previews. The detailed prompts are shown Appendix b) XiYan (Gao et al. 2024): recent framework that improves SQL generation via multi-generator ensemble design.
includes modules for schema linking via column/value retrieval, candidate generation with diverse LLMed generators, and candidate selection/ranking before execution. We use GPT-4o as backbone across generators and rankers for fair comparison.
Hybrid methods. We consider two hybrid approaches that combine SQL-based retrieval with LLM reasoning. a) H-STAR (Abhyankar et al. 2025): hybrid method that first performs table extraction (relevant columns/rows via SQL and _LM filtering). then routes numeric/aggregation tasks to SQL and relational/descriptive reasoning to the LLM. This allows H-STAR to combine precise symbolic computation with flexible natural-language inference. b) Weaver (Khoja al., 2025): executes stepwise workflow assigning operations to SQL or LLM, feeding intermediate tables back into the plan for integrated reasoning. This tight integration allows it combine the precision of SQL with the flexibility of LLMs. improving robustness on complex queries that require both symbolic computation and semantic interpretation.
4.3 EVALUATION
Previous work (Deng al. 2022 Wu al. 2025a| Zhu et al. 202I) has largely relied on traditional metrics such Exact Match (EM) and Partial Match (PM). However, these metrics suffer from well-known limitations: they depend on strict string-leve comparison with the gold answer. Con- sequently, they penalize semantically correct predictions due paraphrasing, formatting, minor rounding differences. To address these limitations, we adopt LLMS as judges, a strategy shown to correlate strongly with human evaluation in variety of reasoning tasks (Maekawa al. 2025). Concretely, GPT-4o is given both the gold answer and the model's 's prediction and prompted to deter- mine semantic correctness. This evaluator tolerates surface variation while enforcing strict semantic equivalence. To assess the reliability of our LLM--bsed evaluator, we randomly sampled 100 eval-
'gpt-40-oo- 2:0-4440222-11-222
2 'gemi ni-2.5--1
"gwen3
222077
5

---

Published as a conference paper at ICLR 2026
Table Comparison of model paradigms on structured vs, semi-structured tables (RQI). Weighted
averages across diagnostic splits highlight the strong impact of input representation. Bold denotes the best, italic the second-best result within each block.
Model
Structured Acc. (%)
Seml-structured Acc. (%)
Drop (%)
GPT-4o
45.37
41.93
3.44
Demini-2.5--faas
52.07
50.78
1.29
Qwen3-235B
38.20
36.70
1.50
LLM--NL2SLL
69.14
38.65
30.49
XiYan
69.55
24.08
45.47
H-STAR
49.48
47.14
2.34
Weaver
62.19
57.70
4.49
uation cases across all datasets and model families. Each case was independently annotated by human and compared to the LLM's judgment. We observed 96% agreement rate, demonstrating that the LLM-based evaluation is sufficiently stable for large-scale benchmarking. Unless stated otherwise, all results reported follow this evaluation protocol. We provide a Chi-Square significance analysis in Appendix E to rigorously evaluate performance differences across data splits.
5 RESULTS AND ANALYSIS
5.1 RQI: MODEL PERFORMANCE ACROSS PARADIGMS
We first examine how model performance varies across paradigms when comparing structured and semi-structured inputs with identical content, using weighted averages all diagnostic splits.
NL2SQL models achieve the highest accuracy on structured tables, while hybrid models per- form best on semi-structured tables. Table shows that input representation has substantial and consistent effect on performance, with semi-structured inputs posing greater challenges across the methods. On structured inputs, SQL-based methods outperform both hybrids and LLMs, reflecting their reliance on clean, explicit schemas. On semi-structuse inputs, this ranking reverses. Hybrid models achieve the highest absolute accuracy on semi-structured tables, while LLMs exhibit rela- tively modest performance drops. SQL methods suffer dramatic drops since irregular or implicit structures disrupt symbolic execution.
We also examine the robustness of these trends across model scales. For instance, Gemini-2.5-PH shows the same structured vs. semi-structured performance gap as GPT-4o and other baselines, indicating that sensitivity to representation persists even in state-of-the-art LLMs (full results in Appendix D).
LLMs are the most robust to representation changes, due to their training on free-text, though they do not attain peak accuracy in either setting. These trends highlight the central role of representation in shaping model performance.
5.2 RQ2: IMPACT OF TABLE SIZE
We next examine how table size affects model performance across paradigms. isolate the effect of table length, we compare short tables S1 and S3 against long tables S4 and S5 (see Table
NL2SQL pipelines scale best on structured data but collapse on semi-structured tables. Table indicates that table size has substantial effect accuracy across all families. Performance declines monotonically as tables grow. The rate of degradation, however, depends on the paradigm. NL.2QQI. methods perform best on short, structured tables and remain competitive longer structured ones, leveraging exccution engines that scale efficiently. However, semi-structured inputs expose their reliance on clean schemas. Accuracy drops sharply scale (e.g., Xi drops to 25.0%).
LLMs are highly sensitive to table length, whereas hybrids offer a balanced trade-off. LLMs perform reasonably short tables but degrade substantially on long tables. For example, GPT- 4o falls to 28.9% on structured and 27.1 1% on semi-structured data; with Gemini falling to <55%. Hybrid models, while less competitive short structured tables, maintain relative robustness across

---

Published as a conference paper at ICLR 2026
Structured- Short
Semi-Smechme Sheet
Structured
Semi Strutured Long
Acerrayy (5)
64.5
67.4
41.0
52.8
46.2
41.1
16.
J5A
18.9
13.4
15A
14.
11.6
GPT-46
Gemini-2.55-M
Qwen1-2158 2158
LLM-NL
X7130
I.STAR
Weaver
Figure 3: Short tables vs. long tables (RQ2). All models struggle on long tables. LLMs are most sensitive, NL2SQL excels on short structured tables, and hybrids remain relatively stable.
table sizes, particularly semi-structune data. For example, Weaver achieves 57.2% on short semi- structured tables and 35.4% on long ones, while H-STAR drops to < 13% on long tables regardless of representation.
We also examine the robustness of these trends across table width (Appendix We found that reasoning difficulty grows with table width: wide tables (>20 columns) consistently challenge all model families as it makes schema linking harder and context retrieval noisier.
5.3
RQ3: IMPACT OF TABLE JOINS
To assess the effect of multi-table reasoning, we compare single-table subsets (S1-S5) with multi- table subsets (M1-M2).
NL2SQL models benefit from executable joins on structured tables but lose this advantage when schema signals are weak. Table indicates that multi-table reasoning has significant im- pact on performance, with effects varying by paradigm. On structured multi-table inputs, NL2SQL models leverage joins integrate information across tables. For instance, .IL--NI2SQI. improves from 71.5% (single-table) to 82.3% (multi-table), outperforming GPT-4o by over 35 points. How- ever, this advantage disappears under semi-structured conditions, where implicit structure hinders grounding, resulting in sharp performance drops.
LLMs are largely insensitive to join structure. They show minimal differences between single- and multi-table inputs, reflecting limited ability to exploit relational dependencies. Gemini exhibits modest improvements on multi-table structured inputs, but gains are small relative SQL-based methods. Hybrid models maintain relatively stable performance structured multi-table inputs but currently offer limited support for multi-table reasoning under semi-structured conditions, con- straining their effectiveness in realistic deployments.
Sinicural Single
Semi-Sttnetned
Stmittreed Mintted-iMlttt
Semi Strootuned Multi
18.1
Aecurney (%)
71.5
48.
$3.4
11,01
SAL
39.3
GPT44
Gemini-1.5 S-faahh
Owa2--215
11LLL
AiVia
H-STAR
Weaver
Figure 4: Single- vs. multi-table (RQ3). NL2SQL benefits from structured joins but fails on semi- structured tables. LLMs largely insensitive joins, while hybrids lack multi-table support.

---

Published as a conference paper at ICLR 2026
5.4 RQ4: IMPACT OF QUERY COMPLEXITY
We assess how query complexity affects performance by comparing lookup (subsets SI, S4) and compositional (subsets S3, S5) queries. These subsets target single tables. To isolate impact of query complexity we exclude MI, M2 since they focus multi-table settings.
NL2SQL models excel on structured queries but collapse under semi-structured conditions. Figure [5 shows that NL2SQL models achieve high accuracy on structured compositional queries, confirming the advantage of executable SQL for complex reasoning. However, their performance drops sharply under remi-structured conditions, reflecting brittleness to representational noise.
LLMs perform well on lookup queries but struggle with multi-hop reasoning. They achieve 70% accuracy on simple lookups but degrade significantly on compositional queries, highlighting limitations in symbolic and multi-step reasoning without execution support.
Hybrid models occupy the middle ground. They experience moderate drops from lookup to com- positional queries, balancing flexibility and precision. In particular, Weaver sometimes outperforms structured inputs on semi-structured lookup queries, suggesting that natural- natural-language verbalizations can better align with LLM pretraining and improve reasoning.
Strctured Simple lookup Structured Composiiionl
Semi Scrottreed
Simple lookup Stuutured Compositiona
769
75.4
76.1
70L
67.4
47.5
41.8
14.4
42.1
18.
16.2
33.00
12.9
GPF-46
Gemini-2.--Bal Bash
Qwen3-2158
XIVan
1.STAR
Weaver
Figure 5: Lookup compositional queries (RQ4). Accuracy drops across all models multi-hop queries. NL22QQ excels on structured but fails on semi-structured inputs. LLMs and hybrids also degrade, though hybrids often benefit from semi-structured lookup queries.
5.5 RQ5: IMPACT OF SCHEMA QUALITY
We assess the effect of schema quality by comparing clean-schema tables (SI) with incomplete- schema tables (S2). We focus on lookup queries to isolate schema effects.
NL2SQL models are highly sensitive schema quality, while LLMss and hybrids are more robust. Figure 6 shows that NL2SQL performance drops under incomplete schemas, reflecting their dependence on well-defined metadata. In contrast, LLMs maintain relatively high accuracy on clean schemas and degrade only moderately on incomplete ones, leveraging surface patterns even in noisy tables. Hybrid models are more resilient to schema noise. H-STAR mitigates irregularities via row/column pruning and alternative table views. Weaver remains stable by automatically renaming columns during SQL execution, reducing schema mismatches.
5.6
CASE STUDY
We now present illustrative examples that capture the main failure modes when shifting from struc- tured to semi-structured representations. Figure 7 shows a representative case from the "supplier" table, where the query asks for the top ten suppliers by account balance. On the structured version, NL2SQL methods (LLM-NL2SQL and XiYan) execute correctly by leveraging explicit fields such as "s.suppkey" and "scacclbal". On the semi-structured version, however, these attributes are em- bedded into free-text descriptions. The same models either output incorrect results raise execution errors due to missing column references, illustrating the brittleness of NL2SQL pipelines under rep- resentational shifts. similar failure is observed for the hybrid method Weaver, which also relies
8

---

Published as a conference paper at ICLR 2026
Structured Clean
Semi Strri--tcttrr--- Clean Semi Stuctured incomplete
Structured Incomplete
90.5
91.5
87.4
6s
Aceraity (%)
76A
ML.
16.3
63.1
31.2
313
GPT-46
Gemini-1.55
Qwon1-2158
LLM--N
X71a0
H-STAR
Weaver
Figure 6: Clean-schema vs. incomplete-schema with lookup queries (RQ5). NL2SQL degrades under schema noise, while LLMs and hybrids remain robust.
Structured Table
cemni-structured Table
cutindogy
sentbal
desrdptiie
40004020 4264
536-321-5544
Talance
Find the supply key of the top ten suppliers with the most account balance, and list the supply key along account balance descending order account balance.
Question:
NL25QL methods:
NL25QL methods:
cornectlly ranks the top suppliers account balance using the explicit acctbal column.
fail on semi-structure tables since account balances are embedded free:
LLMs:
struggle with compositional reasoning without execution, introducing hallucinated outputs.
struggie with compositional reasoning without execution, introducing hallucinated outputs.
Hybrid Methods:
Hybrid Methods:
outcomes. Weaver producing correct results
break semi-struc inputs. missing
while H-STAR only outputs reasoning plans.
severol results H-STAR failing output onswers.
An illustrative case from the RQI experiments. check mark cross indicates that all models in the series answered correctly or incorrectly, respectively, while the warning symbol denotes mixed outcomes. Example also compares structured and semi-structured inputs.
Figure 7:
SQL execution and cannot recover when key attributes are verbalized into text. This example high- lights the challenges that semi-structured representations pose for models that depend on explicit schema linking and executable queries. We also provide additional case studies in Appendix Ghat highlight scenarios where different model families diverge in behavior.
DISCUSSION & FUTURE WORK
We summarize the optimal method selection strategy as a decision tree in Figure 8 On the struc- tured data, schema quality the key discriminator. On clean, descriptive schemas, NL2SQL systems perform best. However, when schemas are incomplete ambiguous, hybrid pipelines are prefer- able since their retrieval, normalization, and schema-query alignment steps compensate for missing metadata. On the semi-structured data, the first branch is table size. For long tables, NL2SQL becomes competitive once a stable schema mapping is established, whereas for short tables, query complexity dominates. Simple lookups favor LLMM-nly reasoning, while compositional multi- step queries benefit from hybrid pipelines.
A deeper theoretical understanding of representation sensitivity is important avenue for future work. Our focus here is on establishing a controlled benchmark and documenting empirical trends. Fully explaining the underlying mechanisms will require tools such architectural ablations, tar-

---

Published as a conference paper at ICLR 2026
Table Represeriation
Structured
Semi Semi-structuree
Schema Quality
Table Size
Clean
Incomplete
Short
Long
NL2SQL
Complexity
NL2SQL
Simple Lopkup
Compostional Reesoning
LUM
Hybrid
Figure 8: Practical decision tree for method selection. NL2SQL excels in structured, clean tables, while Hybrid methods offer superior robustness for semi-structured, noisy, or large-scale contexts. LLMs serve cost-effective baselines for simple lookups.
geted probing of intermediate representations, and instrumentation of model--nneema decision path- ways. Developing such analyses on top of our benchmark a promising next step.
7
RELATED WORK
Answering questions over tables requires models to reason over information that can appear in both structured database-style formats (Li et al. 2023 Lei et al. 2025) and semi-structured natural- unguage-like representations (Chen et al. [021 1 2020). Approaches to this problem can be broadly grouped into three paradigms, including translating questions into SQL queries (Wang al. 2025). directly reasoning over table representations with large language models (Wu et al.) [025bb Zhang jet al., 2025b), and hybrid methods (Khoja et al. 2025 Abbyynnar et al. 2025) that combine sym- bolic and neural reasoning. Existing benchmarks (Zhong al. 2017 Zhu et al. 2025 Wu al., 2025a) for table QA typically categorize data by query type or task category, but pay little atten- tion representation factors such as table size, table joins, schema quality together. Crucially, no prior work has isolated the effect of semi-structured representations under the same information conditions. Meanwhile, most analytical studies (Ashury-
al. 2025 Singha et al., 2023 Sui ct al. 2024) evaluate single family of methods in isolation, without systematically comparing how different paradigms respond representation shifts. Our work fills these gaps by conducting a con- trolled, came-information study of structured and with key reasoning factors across multiple method families.
inputs, analyzing their interaction
CONCLUSION
We performed a controlled, same-information comparison of structured and semi-structured table representations across LLM, NL2SQL, and hybrid paradigms using a fine-grained diagnostic dataset constructed via an information-preeee preserving verbalization pipeline. Our findings confirm that repre- sentation has an first-order effect. NL22QQL attains peak accuracy on structured inputs yet is brittle under semi-structures or noisy schemas. LLMs are comparatively robust across formats but trade off peak accuracy. Hybrids mediate this trade-off and often lead under semi-structured inputs. Task fac- tors consistently influence these trends. Long tables degrade all methods (most for LLMs), explicit joins benefit NL2SQL on structured data, multi-hop queries challenge all paradigms (especially inputs), and schema incompleteness severely impacts SQL-based sys-
NL2SQL on tems. Overall, our results highlight the need for representation-ave aware benchmarks and systems, and for matching method families data conditions in deployment.
10

---

Published as a conference paper at ICLR 2026
REFERENCES
Nikhil Abhyankar, Vivek Gupla, Dan Roth, and Chandan K. Reddy. H-STAR: Ilm-driven hybrid sql-text adaptive reasoning on tables. Luis Chiruzzo, Alan Ritter, and Lu Wang (eds.), Pro- ceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies, NAACL 2025 Volume 1: Long Papers, Albuquerque, New Mexico, USA, April 29 May 2025, pp. 8841-8863. Associa- tion for Computational Linguisties, 2025. doi: 10.
URL
https:://oi.. orgg 186.3/6633vvv ht5/://l/222..o/ naacl oog. 445
Rohan Anil, Sebastian Borgeaud, Yonghui Wu, Jean- -aatttBp Alayrac. Jiahui Yu, Radu Soricut, Jo- han Schalkwyk, Andrew M. Dai, Anja Hauth, Katie Millican, David Silver, Slav Petrov, Melvin Johnson, loannis Antonoglou, Julian Schrittwieser, Amelia Glaese, Jilin Chen, Emily Pitler, Tim- othy P. Lillicrap. Angeliki Lazaridou, Orhan Firat, James Molloy, Michael Isard, Paul Ronald Barham, Tom Hennigan, Benjamin Lee, Fabio Viola. Malcolm Reynolds, Yuanzhong Xu, Ryan Doherty, Eli Collins. Clemens Meyer, Eliza Rutherford, Erica Moreira, Kareem Ayoub, Megha Goel, George Tucker, Enrique Piqueras, Maxim Krikun, lain Barr, Nikolay Savinov, Ivo Dani- helka, Becca Roclofs, Anaïs White, Anders Andreassen, Tamara von Glehn, Lakshman Yagati, Mehran Kazemi, Lucas Gonzalez, Misha Khalman, Jakub Sygnowski, and al. Gemini: fam- ily of highly capable multimodal models. CoRR, wabp///33...18800 2023. doi: 10.48550/ARXIV.
1312.11805.
Shir Sahury--Thhan, Yifan Mai, Rajmohan C, Ariel Gera, Yotam Perlitz, Asaf Yehudai, Elron Bandel, Leshem Choshen, Eyal Shnarch, Percy Liang, and Michal Shmueli-Scheuer The mighty torr: A benchmark for table reasoning and robustness. CoRR, abw/2502. 2025. doi: 10.48550/ 2ttp:/iw..5...99911.1.
ARXIV.2502.19412 httpsss//a....ogg//10oooo
Kaushik Chakrabarti, Zhimin Chen, Siamak Shakeri, and Guihong Cao. Open domain question answering using web tables. CoRR, hbbs2200.002222 2020. URL bttts::/arxiv.or
abs/ /os// 03272]
Si-An Chen, Lesly Miculicich, Julian Eisenschlos, Zifeng Wang, Zilong Wang, Yanfei Chen, Yasuhisa Fujii, Hsuan-Tien Lin, Chen-Yu Lee, and Tomas Plister. Tablerag: Million-token table understanding with language models. In Amir Globersons, Lester Mackey, Danielle Belgrave, Angela Fan, Ulrich Paquet, Jakub M. Tomezak, and Cheng Zhang (eds.). Ad- vances in Neural Information Processing Systems 38: Annual Conference on Neural Infor- mation Processing Systems 2024, NeurlPS 2024, Vancouver, BC, Canada, December 10 15, 2024, 2024. http:/ wwwp:::wwssp....ppeeooeooep.pppe wttp:/ipcppppppe.eeeelee/////eee 8Bdd7aa5697 htt.:/aaceeeeee2222222722222eee. Cot.re---ettttatt-ooooeeeeeee..e Con.tettooooeoeeeeeeeoe
html
Wenhu Chen, Hongmin Wang, Jianshu Chen, Yunkai Zhang, Hong Wang. Shiyang Li, Xiyou Zhou, and William Yang Wang. Tabfact: A large-scale dataset for table-based fact verification. arXiv preprint arXiv:/909 12..002666 164, 2019.
Wenhu Chen, Hanwen Zha, Zhiyu Chen, Wenhan Xiong, Hong Wang, and William Yang Wang. Hybridqa: A dataset of multi-hop question answering over tabular and textual data. In Trevor Cohn, Yulan He, and Yang Liu (eds.), Findings of the Association for Computational Lin- guistics: EMNLP 2020, Online Event, 16-20 November 2020, volume EMNLP 2020 of Find- ings of ACL, pp. 1026-1036. Association for Computational Linguisties, 2020. doi: 10. 18653/V1/220.FIIIIINGS WWWNINIIINNG-EGNSSSSS /tl.httts::/:d..orgge /000////10066333//2220 Findings-emnipp 91
Zhiyu Chen, Wenhu Chen, Charese Smiley, Sameena Shah, Iana Borova, Dylan Langdon, Reema Moussa, Matt Beane, Ting-Hao Kenneth Huang, Bryan R. Routledge, and William Yang Wang. Finqa: A dataset of numerical reasoning over financial data. In Maric-Francine Moens, Xu- anjing Huang, Lucia Specia, and Scott Wen-tau Yih (eds.), Proceedings of the 2021 Confer- ence on Empirical Methods in Natural Language Processing, EMNLP 2021, Virtual Event / Punta Cana, Dominican Republic, 7-11 November, 2021, pp. 3697-3711. Association for Com- putational Linguistics, 2021. doi: emn pp- w...maainn....
URL https:
7/doi. wrg/ 10. Set.l11653/11//
11

---

Published as a conference paper at ICLR 2026
Xiang Deng, Huan Sun, Alyssa Lees, You Wu, and Cong Yu. TURL: table understanding through representation learning. SIGMOD Rec. 51(1):33 40, 2022. doi: 10.115/3542700.55477799
3542709
Li Dong and Mirella Lapata. Language logical form with neural attention. In Proceedings of the 54th Anmual Meeting of the Association for Computational Linguistics, ACL. 2016, August 7-12, 2016, Berlin, Germany, Volume 1: Long Papers. The Association for Computer Linguistics, 2016. doi: 10. 10.18653/V1/P16-1 1004. URL htthttt:: doi. org/10. 1ww53/v1/svee 10tp://///....1//////01000110000
Yingqi Gao. Yifu Liu, Xiaoxia Li, Xiaorong Shi, Yin Zhu, Yiming Wang, Shiqi Li, Wei Li, Yuntao Hong, Zhiling Luo, et al. A preview of xiyan-sql: A multi-generator ensemble framework for text-to-sql. arXiv preprint arXiv:241 1.08599, 2024.
Akash Ghosh, B. Venkata Sahith, Niloy Ganguly, Pawan Goyal, and Mayank Singh. How ro- bust are the tabular QA models for scientific tables? A study using customized dataset. CoRR, abs/2404 00401, 2024. doi: 10448550AARXI..444.0000 URL
48550 10.50//rXiv.o 20...440...000 00401
Cheng-Ping Hsieh, Simeng Sun, Samuel Kriman, Shantanu Acharya, Dima Rekesh, Fei Jia, Yang Zhang, and Boris Ginsburg. Ruler: What's the real context size of your long-context language models? arXiv preprint arXiv:2404.0666 2024.
Aaron Hurst, Adam Lerer, Adam Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Os- trow, Akila Welihinda, Alan Hayes, Alec Radford, Aleksander Madry, Alex Baker-Whitcome Alex Beutel, Alex Borzunov, Alex Carney, Alex Chow, Alex Kirillov, Alex Nichol, Alex Paino, Alex Renzin, Alex Tachard Passos, Alexander Kirillov, Alexi Christakis, Alexis Conneau, Ali Ka- mali, Allan Jabri, Allison Moyer, Allison Tam, Amadou Crookes, Amin Tootoonchian, Ananya Kumar, Andrea Vallone, Andrej Karpathy, Andrew Braunstein, Andrew Cann, Andrew Codis- poti, Andrew Galu, Andrew Kondrich, Andrew Tulloch, Andrey Mishchenko, Angela Baek, An- gela Jiang, Antoine Pelisse, Antonia Woodford, Anuj Gosalia, Arka Dhar, Ashley Pantuliano, Avi Nayak, Avital Oliver, Barret Zoph, Behrooz Ghorbani, Ben Leimberger, Ben Rossen, Ben Sokolowsky, Ben Wang. Benjamin Zweig, Beth Hoover, Blake Samic, Bob McGrew, Bobby Spero, Bogo Giertler, Bowen Cheng, Brad Lightcap, Brandon Walkin, Brendan Quinn, Brian Guarraci, Brian Hsu, Bright Kellogg. Brydon Eastman, Camillo Lugaresi. Carroll L. Wainwright, Cary Bassin, Cary Hudson, Casey Chu, Chad Nelson, Chak Li, Chan Jun Shern, Channing Con- ger, Charlotte Barette, Chelsea Voss, Chen Ding, Cheng Lu, Chong Zhang, Chris Beaumont, Chris Hallacy, Chris Koch, Christian Gibson, Christina Kim, Christine Choi, Christine McLeavey, Christopher Hesse, Claudia Fischer, Clemens Winter, Coley Czarnecki, Colin Jarvis, Colin Wei, Constantin Koumouzelis, and Dane Sherburn. Gpt-4o system card. CoRR, abs/2410.21176 2024. doi: 1044550/ARXIW22410.2220 URL ozt org 48550/ / 2410.
21276
Mohit Iyyer. Wen-tau Yih, and Ming- Wei Chang. Search-based neural structured learning for se- quential question answering. In Regina Barzilay and Min-Yer Kan (eds.). Proceedings of the 55th Annual Meeting of the Association for Computational Linguisticss ACL. 2017, Vancouver, Canada, July 30 August 4, Volume I: Long Papers, pp. 1821-1831. Association for Computational Lin- guistics, 2017. doi: 10.18663/V1//17-1166 URL
Pl -1667
Rohit Khoja, Devanshu Gupta, Yanjie Fu, Dan Roth, and Vivek Gupta. Weaver: Interweaving SQL and LLM for table reasoning, CoRR, abs/2505. 18961, 2025, doi: 10448550/ARXIV2255..18666 URL
http://10..5500ax1.vvooo 18961
Fangyu Lei, Jixuan Chen, Yuxiao Ye, Ruisheng Cao, Dongchan Shin, Hongjin Su, Zhaoqing Suo, Hongcheng Gao, Wenjing Hu, Pengcheng Yin. Victor Zhong, Caiming Xiong, Ruoxi Sun, Qian Liu, Sida Wang, and Tao Yu. Spider 2.0: Evaluating language models on real- world enterprise text-to-sql workflows. In The Thirteenth International Conference on Learn- ing Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net, 2025. URL https:://ppnnew//
net http://wwwee/touutttt/e/e wow.oorddddmmmmio ro 9cPs
12

---

Published as a conference paper at ICLR 2026
Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang. Binhua Li, Bowen Li. Bailin Wang, Bowen Qin. Ruiying Geng, Nan Huo, Xuanhe Zhou, Chenhao Ma, Guoliang Li, Kevin Chen- Chuan Chang, Fei Huang, Reynold Cheng, and Yongbin Li. Can LLM already serve A database interface? A big bench for large-scale database grounded text-to-sqls. In Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine (eds.), Advances in Neural Information Processing Systems 36: Annual Conference on Neural In- formation Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 www.s//papee/eaaeeeaeee fi /
16. 2023, 2023. URL http::/paaers..rrr nips wttpsscccc/ppaaee fttppppssseeepppeeeeeeeeeeeeeeee
and
Berchmarks html
Nelson F Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. Lost in the middle: How language models use long contexts. arXiv preprint
MrXiv:2307.03122 2023.
Qian Liu, Bei Chen, Jiaqi Guo, Morteza Ziyadi, Zeqi Lin, Weizhu Chen, and Jian-Guang Lou. TAPEX: table pre- pre-training via learning a neural SQL executor. The Tenth International Confer- ence on Learning Representations, ICLR 2022, Virtual Event, April 25-29, 2022. OpenReview.net, 2022. URL httLltttt/psppeeeeeeee
net wetp:oormmmc0000444500.0 http:///ppppaaoooooooccccoooocaa
Zeyao Ma. Bohan Zhang, Jing Zhang, Jifan Yu, Xiaokang Zhang, Xiaohan Zhang, Si- jia Luo, Xi Wang, and Jie Tang. Spreadsheetbench: Towards challenging real world spreadsheet manipulation. In Amir Globersons, Lester Mackey, Danielle Belgrave, An- gela Fan, Uirich Paquet, Jakub M. Tomezak, and Cheng Zhang (eds.). Advances in Neural Information Processing Systems 38: Annual Conference tion Processing Systems 2024, NeurlPS 2024, Vancouver, BC, Canada, December 10 15, 2024, 2024. URL http::/ nips ww/ppperppppp..c/ppppp http/pppr_flllsese willes/paper//e Rash/ac840dE22 /ttp:///..////3001/a.a...... Benchmarks Frack.htm.
Neural Informa-
Abstract Datasets Datasetss_ndd and
Seiji Maekawa, Hayate Iso, and Nikita Bhutani. Holistic reasoning with long-context LMs: A benchmark for database operations on massive textual data. In The Thirleenth International Con- net forrmm?
ference on Learning Representations, 2025. URL bettps://ppezzerv//
id=5LXcoDtNyq
Panupong Pasupat and Percy Liang- Compositional semantic parsing on semi-structured tables. In Proceedings of the 53rd Annual Meeting of the Association for Computational Linguistics and the 7th International Joint Conference on Natural Language Processing of the Asian Fed- eration of Natural Language Processing, ACL 2015, July 26-31, 2015, Beijing, China, Vol- ume I: Long Papers, pp. 1470-1480. The Association for Computer Linguistics, 2015. doi: 10.3115/V1/P15-1144 11422. 1142.
Raghu Ramakrishnan and Johannes Gehrke. Database management systems (3. ed.). McGraw-Hill, 2003. ISBN 978-0-07-115510--
Anshul Singh, Chris Biemann, and Jan Strich. Mtabvqa: Evaluating multi-tabulan reasoning of language models in visual space. CoRR, abs/2506. 1164, 2025. doi: 10.48550/RXXVV25066 11684. https::///// /ttps::/:///o httpt::::/ddo.oogog//e htt::///oooooog////// 48550/8555////0
2506 11684
Ananya Singha, José Cambronero, Sumit Gulwani, Vu Le, and Chris Parnin. Tabular represen- tation, noisy operators, and impacts on table structure understanding tasks in llms. CoRR, abs/23 0os/2310.10358 2023. doi: 10448500AARXIV.3100000 48550/arXiv. 2310. 2035.
URL httpt::///// //doi org/10.
Yuan Sui, Mengyu Zhou, Mingjie Zhou, Shi Han, and Dongmei Zhang. Table meets LLM: can large language models understand structured table data? A benchmark and empirical study. In Luz Angelica Caudillo-Mata, Silvio Lattanzi, Andrés Muñoz Medina, Leman Akoglu, Aristides Gionis, and Sergei Vassilvitskii ),ds.), Proceedings of the 17th ACM International Conference Web Search and Data Mining. WSDM 2024, Merida, Mexico, March 4-8. 2024, pp. 645 URL Attps: /tttps://dd..org111.111
654. ACM, 2024. doi: 00.1145/3616855.333377
361 6855. 3635752
13

---

Published as a conference paper at ICLR 2026
Maria Wang, Srinivas Sunkara, Gilles Baechler, Jason Lin, Yun Zhu, Fedir Zubach, Lei Shu, and Jindong Chen. Webquest: A benchmark for multimodal QA on web page sequences. CoRR, URL http:: /tttpp:://doo.oz/I1...
abs/2409.13711, 2024. doi: 10.4850/ARRXI.22400..777 48550/arXiv. 1377
Tianshu Wang, Xiaoyang Chen, Hongyu Lin, Xianpei Han, Le Sun, Hao Wang, and Zhenyu Zeng. Dbcopilot: Natural language querying over massive databases via schema routing, In Alkis Simit- sis, Bettina Kemme, Anna Queralt, Oscar Romero, and Petar Jovanovic (eds.), Proceedings 28th International Conference on Extending Database Technology. EDBT 2025, Barcelona, Spain, March 25-28, 2025, pp. 707-721. OpenProcediings.org 2025. doi: 10.48786/EDBT.2025551 URL https::///// /tt.///o..... http::::/ddoi.orggg 10. 0.40444. 48784788888888 edbt. 2025.57,
Jian Wu, Linyi Yang, Dongyuan Li, Yuliang Ji, Manabu Okumura, and Yue Zhang. MMQA: evalu- ating lims with multi-table multi-hop complex questions. In The Thirteenth International Confer- ence on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net, 2025a. URL UtLlhttp:://stt httt:p::///peeneeieeee net hwt::oorumnddddllllyllo.....o
Zhenhe Wu, Jian Yang, Jiaheng Liu, Xianjie Wu, Changzai Pan, Jie Zhang, Yu Zhao, Shuangy- ong Song. Yongxiang Li, and Zhoujun Li. Table-rl: Region-basee reinforcement learning for table understanding. CoRR, abs/2505. 12415, 2025b. doi: 10. 10445550/RRXV.2255...22 12415. URL https://doi. wrg.10...000.0 48550/ arwiv. 2505. 12415
An Yang, Anfeng Li. Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, Chujie Zheng. Dayiheng Liu, Fan Zhou, Fei Huang, Feng Hu, Hao Ge, Haoran Wei, Huan Lin, Jialong Tang. Jian Yang, Jianhong Tu, Jianwei Zhang, Jian Yang. Jiaxi Yang. Jingren Zhou, Junyang Lin, Kai Dang, Keqin Bao, Kexin Yang, Le Yu, Lianghao Deng. Mei Li, Mingfeng Xue, Mingze Li, Pei Zhang, Peng Wang. Qin Zhu, Rui Men, Ruize Gao, Shixuan Liu, Shuang Luo, Tianhao Li, Tianyi Tang, Wenbiao Yin, Xingzhang Ren, Xinyu Wang, Xinyu Zhang. Xuancheng Ren. Yang Fan, Yang Su, Yichang Zhang, Yinger Zhang, Yu Wan, Yuqiong Liu, Zekun Wang, Zeyu Cui, Zhenru Zhang, Zhipeng Zhou, and Zihan Qiu. Qwen3 technical report. CoRR, abs/2505.003388 2025. doi: 10448550/ARXX..2555.0955 093888 URL https://doi.co http://....0011.....550505////// 4Bw...4455///01..2222. 2505 09388
Yunhu Ye, Binyuan Hui, Min Yang, Binhua Li, Fei Huang, and Yonghin Li. Large language models are versatile decomposers: Decomposing evidence and questions for table-based rea- soning. In Hsin-Hsi Chen, Wei-Jou (Edward) Duh, Hen-Hsen Huang, Makoto P. Kato, Josiane Mothe, and Barbara Poblete (eds.), Proceedings of the 46th International ACM SIGIR Con- ference on Research and Development in Information Retrieval, SIGIR 2023, Taipei, Taiwan, July 23-27, 2023, pp. 184. ACM, 2023. doi: 10.1145/539618833511703 7/doi wrogorgg1100 10. 111115333661111 3591708
URL https:
Junwen Zhang, Pu Chen, and Yin Zhang. Tablemoe: Neuro-symbolic routing for structured expert reasoning in multimodal table understanding. CoRR, abs/2506.21393, 2025a. doi: 10.48550/ ARXIV.2506.21393. URL http://////0....r0000.0.005
Siyue Zhang, Anh Tuan Luu, and Chen Zhao. Syntqa: Synergistic table-based question an- swering via mixture of text-to-sql and E2E TQA. In Yaser Al-Onaizan, Mohit Bansal, and
Yun-Nung Chen (eds.), Findings of the Association for Computational Linguistics: EMNLP 2024, Miami, Florida, USA, November 12-16, 2024, pp. 2352-2364. Association for Compu- URL https:
tational Linguisties, 2024. doi: htw.g////.............e......... 131
//doi. 0tlpg//0.11653////
Xiaokang Zhang, Sijia Luo, Bohan Zhang, Zeyao Ma. Jing Zhang, Yang Li, Guanlin Li, Zi- jun Yao. Kangli Xu, Jinchang Zhou, Daniel Zhang-Li, Jifan Yu, Shu Zhao, Juanzi Li, and Jie Tang. Tablellm: Enabling tabular data manipulation by Ilms in real office usage scenarios. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (eds.), Findings of the Association for Computational Linguistics, ACI. 2025, Vienna, Austria, July 27 August 1, 2025, pp. 10315-10344. Association for Computational Linguistics, 2025b. URL hettps://aclanthet 2og.laanthhoooy.or//222222 findings aac.ingg-acl.3336
Xuanliang Zhang, Dingzirui Wang, Keyan Xu, Qingfu Zhu, and Wanxiang Che. Rot: Enhancing table reasoning with iterative wiw- traversals. CoRR, abs/2505. 15110 2025c. doi: 10.48550/ ARXIV.2505.151 U //do .ariiiorgggoo 01110..85555080 w50....www......................
2501.15110
14

---

Published as a conference paper at ICLR 2026
Victor Zhong, Caiming Xiong, and Richard Socher. Seq2sql: Generating structured queries from natural language using reinforcement learning. CoRR, abs/1709.00103, 2017. URL http://
arxiv. org/ abs 2ww.
709. 001033
Fengbin Zhu, Wenqiang Lei, Youcheng Huang, Chao Wang, Shuo Zhang, Jiancheng Lv, Fuli Feng, and Tat-Seng Chua. TAT-QA: A question answering benchmark on a hybrid of tabular and textual content in finance. In Chengqing Zong, Fei Xia. Wenjie Li, and Roberto Navigli (eds.). Proceedings of the 59th Annual Meeting of the Association for Computational Linguis- fies and the 11th International Joint Conference on Natural Language Processing, AC1/JC- NLP 2021, (Volume I: Long Papers), Virtual Event, August 1-6, 2021, pp. 3277-3287. Asso- ciation for Computational Linguistics, 2021. doi: (018663/1/2021AALLLLLO00 0ttp://///o..0r/101111553333 acc1://2222.cc11--111 Long-loog...0
URL
Junnan Zhu, Jingyi Wang, Bohan Yu, Xiaoyu Wu, Junbo Li, Lei Wang, and Nan Xu. Tableeval: A real-world benchmark for complex, multilingual, and multi-structured table question answering. CoRR, abs/2506 2025, doi: 10.48550/ARXIV.55666 03949, ntts::::://///// htttt::://doi.rrr.
10. N8.48550/ark20 art.v///axi...m www.ariwwv...........m 03949
15

---

Published as a conference paper at ICLR 2026
A PROMPTS
Prompt for Random Column Selection
Prompt:
You are given list column names from a database table, along with a sample value for each column. Your task consists of two steps:
Column Suitability Classification Label cach column either:
Step I:
"YES": if the column descriptive and numan-interpretable (c.g., name, title, category, price, quantity, location, status).
"NO": if it is a technical field or metadata column (e.g., id, uuid, product created_at, URL) that is unlikely appear in a natural-language description.
Step 2: Column Combination Generation
From the columns labeled "YES", generate small number of diverse and meaningful com- binations (ideally 2-5). Each combination should:
Contain only columns labeled "YES"
Include several columns (based on availability, usually should more than two)
Avoid repeating the same column in single combination
Be suitable for use in a natural-language sentence such as: "(product namm)) is sold by
{supplier name} } for (price)."
If only one or two YES columns exist, just generate I or 2 simple combinations. Avoid bad combinations like: "'ATT_CLASS" "ATT-CIASS") [" "'ATTCLAASS JD"] if was labeled "NO"
Input:
Database: db Table: table
Columns with sample values: cols
Example:
Columns [product_name, price, category, product created_at, stock_quantity sup- plier_names Example Output: ["product_name" "price", "category"I, I"product.name", "supplier "supplier.name") name"], ["product.name", "stock..uanntit", "price"]]
Your Output Format:
"jjoon { croolumn_llassffiation ("column_name) "YES", "columm_name_22. "NO" "combinations": [...]] }
Prompt for Random Column Selection (One Column)
Prompt: You are given list column names from a database table, along with a sample value for each column. Your task consists of two steps:
Column Suitability Classification Label each column either:
Step 1:
"YES": the column descriptive and human-interpretable (c.g., name, title, category, price, quantity, location, status).
"NO": if it is a technical field or metadata column (e.g., id, uuid, product.id, created_at, URL) that is unlikely appear in natural-language description.
Step 2: Column Combination Generation
From the columns labeled "YES". generate small number of diverse and meaningful com- binations (ideally 2-5). Each combination should:
Contain only columns labeled "YES"
Include only one column
Avoid repeating the same column in single combination
16

---

Published as a conference paper at ICLR 2026
Be suitable for use in a natural natural-language sentence such as: "(product name) is sold by {supplier name} for (price)."
If only one or two YES columns exist, just generate I or 2 simple combinations. Avoid bad combinations like: ["ATT-CLASS, "ATT (XTTCC [" ["ATT CLASS [D"] if it was labeled "NO"
Input:
Database: db Table: table
Columns with sample values: cols
Example:
Columns = [product.namer price, category, product created stock quocktquantity, sup-
plier name] Example Output: [""pooduct name", "price", "category"), ("product.name name", Suuppliername""" ["product_name" " "stock..uantity", "price"]
Your Output Format:
"'json "columm _classification".: { "columm_name_I1" name__ "YES", "column.name" name 2": "NO" }. "combinations": [...]
Prompt for Random Column Selection (Three Column)
Prompt: You given list of column names from database table, along with sample value for each column. Your task consists of two steps:
Step 1: Column Suitability Classification
Label each column as either:
"YES": if the column descriptive and human-interpretable (e.g., name, title, category, price, quantity, location, status).
"NO": if it is a technical field metadata column (c.g., id, uuid, product.id, created URL) that is unlikely to appear in a natural- natural-language description.
Step 2: Column Combination Generation
From the columns labeled "YES". generate small number of diverse and meaningful com- binations (ideally 2-5). Each combination should:
Contain only columns labeled "YES"
Include exactly three columns
Avoid repeating the same column in a single combination
Be suitable for use a natural-language sentence such as: "(product.name" is sold by (supplier_name) name for {price}."
If only one or two YES columns exist, just generate 1 or 2 simple combinations. Avoid bad combinations like: ["AST.CLASS", "ATT.CLASS" ["ATT-CLASS if it was labeled "NO"
Input:
Database: db Table: table
Columns with sample values: cols
Example:
Columns [product name, price, category, product id, created at, stock quantity, sup-
plier name] Example Output: ['product name". "price", "category"), ['product name", cuupliiername"") ["product_name" "stock_qqannii" "price"]]
Your Output Format:
"'son "columm classification": "column name 1": "YES", "column name 2": "NO" }. "combinations": [...] }
17

---

Published as a conference paper at ICLR 2026
Prompt for Random Column Selection (Six Column)
Prompt: You are given list column names from a database table, along with a sample value for each column. Your task consists of two steps:
Column Suitability Classification Label each column either:
Step I:
"YES": the column descriptive and human-interpretable (e.g., name, title, category, price, quantity, location, status).
"NO": if it is a technical field or metadata column (e.g., id, uuid, product created URL) that is unlikely appear in natural- -atural-anguuge description.
Step 2: Column Combination Generation
From the columns labeled "YES", generate small number of diverse and meaningful com- binations (ideally 2-5). Each combination should:
Contain only columns labeled "YES"
Include exactly six columns
Avoid repeating the same column in single combination
Be suitable for use in a natural-language sentence such as: "(product.name) is sold by (supplier_namee name) for {price)."
If only one or two YES columns exist, just generate 1 or 2 simple combinations. Avoid bad combinations like: ("ATT CLASS", "ATT CLASS") ["ATT CLASS ID"] if was labeled "NO"
Input:
Database: db Table: table Columns with sample values: cols
Example:
Columns [product.name, price, category, product created stock- sup-
plier name] Example Output: ['product name", "price", "category"), ['product "arodu "supplier name"], ["product_nance name", "stock quantiitt,,, "price"]
Your Output Format:
"'json "column classification": { ('column name 1": "YES", "column name 2": "NO" }, "combinations": [... }
Prompt for Template Generation
You are writing five distinct fluent English sentence templates that verbalize one row a database table.
Prompt:
Database: db Table: table
Required columns (each sentence must use every one exactly once as placeholders): sel cols Sample values for these columns (for context): example block
Guidelines 1. **Produce exactly 5 sentences. ** Each sentence must include every required column once and only once, wrapped as column name. 2. You may reorder the placeholders naturally; no extra columns should be added. 3. Keep each sentence concise, grammatically correct, and natural to a human reader. 4. The column values are descriptive and human- interpretable (names, dates. quantities, locations, etc.). Avoid metadata fields like IDs or flags. 5. Return a single valid JSON object in the exact format below no Markdown, no commentary:
"template2": "Sentence with {coll), {col2).... "template3": "Sentence 3 with [coll), (col2). "ttemplate4"; "Sen- tence with (coll), (col2).... ... "template5":: "Sentence with {coll). (col2)...."" Example for reference Columns [product.name price, category] Sample values prod- uct name: "iPhone 15", price: "899 USD", category: "Electronics" Expected output: "'json { "ttemplatel": "product name in the category category is priced at {price].". "template2":
"'json { ("template1": "Sentence with {coll), ). (col2),
18

---

Published as a conference paper at ICLR 2026
"The {category] } item {product name) costs {price}.", "template3": "Retailing for {price), the {product name} belongs to (category)." "template4": " "(product name)-a (category) product- a price tag of price.", "template5": "Price for the {category) product (preduct_name) is price.")
Prompt for LLM inference
Prompt:
You are an expert table question answering. You need extract answers based on the following information: [Tables]
(tables_md)
[Question] {question]
Please return your answer in JSON format only, with explanation, following this structure:
("Answer": "[your answer]")
Prompt for NL2SQL Baseline
Prompt:
You are a careful NI.2SQL. expert for SQLite, Rules: Return single SQL query that answers the question.
Use ONLY provided tables/columns.
Prefer explicit JOINs with ON.
Use SQLite syntax.
Output ONLY SQL inside one fenced block:
"'sql SELECT
SQLite schema & preview: {schema_md}
Question: {question]
Prompt for Evaluation
Prompt:
You are an expert in evaluating question answering results. [Ground-truth Answer] {ground _truth]
[Model Prediction] {prediction] Is the prediction semantically equivalent the ground-trutt answer?
Please respond with only one word: "CORRECT" or "INCORRECT".
B EFFECT OF COLUMN SELECTION SETTINGS
We test whether our conclusions are sensitive to how content is chosen for verbalization. On the S3 split, we keep the questions and gold answers fixed and vary only the selection setting. We consider four settings: query-related, where only the columns directly referenced in the question are ver- balized; non-qqueryrrllaeed where only the columns not referenced in the question verbalized; random, where GPT-4o is prompted to randomly select a subset of columns to verbalize; and full, where all columns in the table verbalized into free-text. For full strategy, directly verbalizing all rows would collapse the table into single unstructured text block. To avoid this, we randomly verbalize only an a% subset of rows, while keeping the remaining rows their original structured form. The verbalized rows are then dropped, and the resulting semi-structured table contains both the structured part and the generated free-text column. We report a 50 and 10 below.
For tables with fewer columns than the target verbalization count, we discard those cases; all results are computed on the intersection of examples available under every selection setting ensure strict comparability.
indicating low sensitivity to the specific choice. (2) Column verbalization exhibits clear downward trend as the number of verbalized columns increases, with the unconstrained/random setting producing the
Findings. (1) Across selection settings, GPT-4o accuracy spans
19

---

Published as a conference paper at ICLR 2026
Table Effect of verbalization strategy on the S3, We vary only the selection policy while keeping questions and gold answers fixed.
Settings
Acc (%)
Column verbalization
Random (1 column)
44.68
Random (3 columns)
43,97
Random (6 columns)
42.20
Random (unconstrained count)
42.20
Query-aware
Query-Related
46.45
Non Query-Related Related
43.26
verhalization
a 50% rows
43.97
10% rows
42.91
lowest score (42.20%). (3) Query-aware selection is the only variant that yields consistent gain: verbalizing only the query-relevant columns gives the best result (46.45%), while excluding them hurts (43.26%) (4) Full verbalization with 50% or 10% behaves similarly to random column verbalization and offers no additional advantage. Given the comparable accuracy across all settings, adopt random column selection as the default maximize coverage and comparability in the main experiments.
C EFFECT OF TABLE WIDTH
While our primary analysis differentiates tables by row count, the number of columns (table width) is another important complexity dimension, especially in domains like medical or financial research where high-dimensional data common. To explore this, we further divide the BIRD diagnostic splits (S1, S3, S4, S5) into three categories based on column count: Narrow (1-5 columns), Medium (6-20 columns), and Wide (>20 columns). Table [ summarizes the distribution instances across these categories. Table reports the performance across different paradigms. Broadly, observe an inverse correlation between table width and accuracy across most methods.
On structured tables, performance degrades consistently width increases. For instance, GPT-4o drops from 52.75% on narrow tables to 27.91% % on wide tables. SQL-based methods demonstrate superior resilience wide tables, likely because symbolic SQL queries effectively select rele- vant columns. On semi-structured tables, the challenge is amplified for LLMs. Models like GPT-4o and H-STAR suffer significant drops wide tables. Interestingly. NL2SQL maintains consistent performance, further validating that symbolic execution provides a stable fallback when the input representation becomes noisy high-dimensional.
Table 4: Distribution of table width buckets across BIRD-based diagnostic splits.
Width Bucket
Column Range
# Instances
Narrow
1
455
Medium
6 - 20
329
Wide
20
89
D ADDITIONAL RESULTS ON A LARGE INSTRUCTION-TUNER LLM: GEMINI-2.5-PRO
To validate the generalizability of our findings, we evaluated Gemini-2.5-PP using the same setup in Section 3.2 The results are summarized in Table 6 While Gemini-2.5-Pro demonstrates strong overall capabilities, achieving high accuracy on simpler structured queries (e.g., 92.63% on S1 Structured), it shows the same sensitivity representation GPT-4o and other baselines. We
20

---

Published as a conference paper at ICLR 2026
Table 5: Performance comparison across table width buckets. Bold indicates the best performance within each setting and bucket.
Structured Accuracy (%)
Semi-Structured Accuracy (%)
Model
Narrow
Medium
Wide
Narrow
Medium
Wide
GITT4oo
52.75
37.80
27.91
48.79
37.92
25.58
Gemini-2.5-fasl
51.87
43.47
31.66
54,29
41.34
31.46
Qwen3-235B
42.64
34.35
28.09
43,96
31,91
30.34
LLM-NN.2QQU
76.48
65.55
$7.30
48.79
43.90
47.19
XiYan
75.16
64.94
56.18
24.18
35.06
43.82
H-STAR
43.30
32.01
25.84
44.84
32.52
21.35
Weaver
54.41
44.07
38.20
57.71
51.06
33.71
found consistent accuracy drop when moving from structured semi-structured tables across all difficulty levels. For instance, on the most complex subset (S5), the accuracy significantly declines from 41.31% % (Structured) to 33.98% Semmi-Structured.
Table 6: Performance of Gemini-2.5-Ppp across all splits (S1-S5 and MI-M2). The model consis- tently shows performance degradation on semi-structured inputs.
Split
Structured Acc. (%)
Semi-Structured Acc. (%)
A (pp)
S1
92.63
88.42
-4.21
S2
81.07
73.37
-7.70
S3
76.59
73.86
-2.73
60.76
59.49
-1.27
41.31
33.98
-7.33
M1
82.44
78.45
-3.99
M2
35.54
29.52
-6.02
E STATISTICAL SIGNIFICANCE ANALYSIS
To rigorously evaluate the performance differences across various data splits, conduct Chi-Square tests for each comparison. We report significance levels at p < 0.05 (*), < 0.01 (**), and
p 0.001 (***).
E.1 TABLE LENGTH: SHORT vs. LONG
Table presents the performance comparison between short and long tables. All methods show statistically significant performance degradation when processing long tables (p < 0.001), indicat- ing that table length is universal challenge. Gemini-2.5-flan exhibits the largest drop (72%)7%) while LLM-NL2SQL and Yi demonstrate relatively better robustness with drops of 11.87% and 1 1. 106%, respectively.
Table Performance comparison by table length (Short vs. Long).
Model
Short (%)
Long (%)
Drop (%)
p-value
Sig.
GPT-4o
53.26
27.98
25.29
3.38e-21
#48
femini-2.5-flash
67.06
14.88
52.17
1.37e-83
#48
Qwen3-235B
46.72
24.24
22,48
2.32e-17
**
L.M--NI2SQL.
63.86
51.99
11.87
8.17e-06
#*8
Yi
54.06
43.00
11.06
4.75e-05
**
H-STAR
53,59
12.19
41.40
3,70e-55
#48
Weaver
60.09
36.16
23.94
8.35e-19
21

---

Published as a conference paper at ICLR 2026
E.2 NUMBER OF TABLES: SINGLE VS. MULTI
Table 8 shows the performance comparison between single-table and multi-table queries. Interest- ingly, not all methods are significantly affected by the number of tables. GPT-4o (p 0.789), Qwen3-235B (p 0.097), LLM-NL2SQL (p 0.306), and Yi (p = 0.736) show no sta- tistically significant difference, suggesting robustness table joins. In contrast, Gemini-2.5-flash and H-STAR perform significantly better on multi-table queries, while Weaver shows significant degradation.
Table 8: Performance comparison by number of tables (Single vs. Multi).
Model
Single (%)
Multi (%)
A (%)
p-value
Sig.
GPT-4o
43.45
42.66
0.79
7.89c-01
Gemini-2.5
46.81
59.03
-12.2
2.47e-06
***
Qwen3-235B
38.00
33,81
4.19
9.71e-02
LLM-NI22SLL
59.25
56.57
2.68
3.06e-01
Xi
49.77
50.76
-0.98
7.36e-01
H-STAR
37.75
57.34
-19.59
3.38e-
***
Weaver
52.89
33.39
19.50
4.97c-14
E.3 QUERY COMPLEXITY: LOOKUP vs. COMPOSITIONAL.
Tresenss the performance comparison between simple lookup queries and compositional rea- soning queries. Most methods show significant performance degradation compositional queries (p < 0.001), with Qwen3-235B exhibiting the largest drop (37.79%). Notably, Xi is the only method that shows statistically significant difference (p 0.060), and even performs slightly bet- ter on compositional queries, suggesting its reasoning capability. LLM-NL2SQL also demonstrates relatively strong compositional reasoning with only 9.75% drop.
Table 9: Performance comparison by query complexity (Lookup vs. Compositional),
Model
Lookup (%)
Comp. (%)
Drop (%)
p-value
Sig.
GPT-40
72.55
36.19
36.36
4.36e-33
#**
Gemini-2.5-flash
69.68
41.11
28.58
1.29e-20
Qwen3-235B
68.24
30.45
37.79
9.77c-37
***
LLM-NL2SQL
67.05
57.30
9.75
1.54c-03
Xi
45.09
50.94
-5.85
6.01e-02
H-STAR
54.34
33.33
21.01
1.60e-12
Weaver
73.98
45.02
28.96
3.10e-21
E.4 SCHEMA QUALITY: CLEAN VS. NOISY
Table I0 shows the performance comparison between clean and noisy (incomplete) schemas. All methods show statistically significant performance differences. LLM-NL2SQL shows the most se- degradation (54.62%) indicating high sensitivity schema quality. Interestingly, H-STAR is the only method that performs better on noisy schemas (p 0.035), suggesting potential robust- ness schema imperfections. Thanks table preprocessing. Weaver maintains relatively stable performance with only an 8.64% drop.
These results show that all the analysis supports our findings in the Section
F FINE-GRAINED RESULTS
Beyond the overall trends summarized Section 5 the fine-grained results in Table 11
we highlight several noteworthy findings from
22

---

Published as a conference paper at ICLR 2026
Table 10: Performance comparison by schema quality (Clean vs. Noisy).
Model
Clean (%)
Noisy (%)
Drop (%)
p-value
Sig.
GPT-40
90.00
67.45
22.55
9.75e-17
8*8
Gemini-2.5-flash
89.47
70.71
18.77
3.61e-12
Qwen3-235B
87.37
62.13
25.24
1.37e-17
#*
LLM-NL2SQL
74.74
20.12
54.62
2.74e-47
Yi
52.64
24.56
28.08
1.40e-11
8+8
H-STAR
77.90
84.91
-7.02
3.52e-02
Weaver
90.00
81.36
8.64
6.97e-04
8*8
NL2SQL models remain advantageous at scale. Even with semi-structured inputs, NL2SQL sometimes outperforms LLMs and hybrids on long tables (e.g.. LLM-NL2SQL 41.1% vs. Weaver 35.4% and GPT-4o 27.1% S4), showing that SQL execution can still offset representation mismatch when contexts are large.
NL2SQL excels with joins. On multi-table structured inputs, LLM-NL2SQL rises from 71.5% (single-table) 82.3%. exceeding GPT-4o by more than 35 points. This highlights that executable joins are unique strength of NL2SQL, whereas GPT-4o is largely insensi- tive to join structure.
Verbalization can improve simple lookup queries. For simple lookup queries with clean schemas, aligning headers and content with natural language boosts hybrid mod- els (e.g.. Weaver +3 points on S1), demonstrating that verbalization not only enables semi-structured evaluation but can also yield accuracy gains.
G ADDITIONAL CASE STUDIES
We present additional case studies to further illustrate the distinctive behaviors of different methods.
G.1 MODEL BEHAVIOR ON LONG TABLES
Figure 9 shows a long user profile table with hundreds of rows and a query "What is the id of the youngest user?". LLM-NL2SQL correctly answers the query on the structured version, which exposes the Age column and allows SQL execution to identify the minimum value (id = 7828). In contrast, I.MSs fail to reliably behave similarly. Weaver returns an arbitrary large id, while H-STAR concludes that the task is impossible because of numerous NaN values. This example illustrates that while NL2SQL with execution remains competitive on structured long tables, both LLMs and current hybrid methods are highly sensitive to table length and may produce spurious results when the input context becomes too large.
the full column and return arbitrary large ids. Hybrid methods
G.2 MODEL BEHAVIOR ON INCOMPLETE SCHEMAS
Figure 10 presents two representative examples illustrating the impact of incomplete schemas on model performance. In the first example (left, RoboTaxi fare table), the Rest Day cell for 17:00- 20:00 is left blank, although by business rules should inherit the weekday rate (7 RMB). In this case, LLMs succeed by leveraging contextual cues to infer the missing value, while NL2SQL and hybrid pipelines fail due to their inability to capture implicit inheritance. The second example (right, biomedical citation table) involves clinical reference for Alectinib that is embedded only within free-text description column. In this case, NL2SQL methods return empty outputs, and LLMs hallucinate incorrect citations. In contrast, both hybrid methods (H-STAR and Weaver) success- fully locate and extract the correct reference, demonstrating their ability to combine schema-guides retrieval with flexible reasoning over unstructured content. These examples illustrate that while NL2SQL pipelines are highly sensitive missing schema entries, LLMs sometimes compen- sate via contextual reasoning, and hybrid approaches offer a middle ground capable of handling certain forms of schema incompleteness when textual cues present.
23

---

Published as a conference paper at ICLR 2026
Structured Table
Semi-structured Table
Crosttendiate
Prodie Inuge Lirl
desrritionn
48757
100
Alysa
Jneelly
Seats
The 86000
Question: Please list the full names of all the male clients born after the year 1990.
Question: What is the the youngest user?
NL2SQL methods:
LLMs:
correctly identify the youngest user by executing SQL over the explicit Age column
exhibit repetitive hallucinations, duplicating names rather than covering the full gold set, failure made amplified by long expected outputs and large table inputs. This problem amplified under long semi-structured table inputs.
LLMs and Hybrid methods:
fail on long tables, returning arbitrary ids or onswen
Case study: NL2SQL correctly finds the youngest a long structured table, while LLMs and hybrids produce spurious results.
Figure 9:
Structured Table
Semi-structured Table
Weekdan -RCB
Red Duy TIME
Flrst Goneration
Stating
00:00 02
Componad Alacinii, greater
07.00 go
00:0-12-0 100-110-0
1020
00000 02
165
02.00 09.00
What is the starting fare for RoboTaxi in the Shanghai region during rest days from 17:00 to 20:00?
Question:
Question:
Which reference is cited for the clinical data Alectinib in the table?
NL2SQL methods:
NL2SQL methods:
fail incomplete schemas, they infer the inherited values (7 RMB) when cells are left blank.
returning empty outputs when references embedded only in free-text.
LLMs:
LLMs:
succeed by leveraging contextual cues inferring missing values through implicit contextual information (7
Foils due generating hallucinated citations with incorrect dates or valume numbers.
RMB).
Hybrid Methods:
Hybrid Methods:
Both H-STAR and Weaver extract the correct information from the description column
also fail they make the plan cornectly but cannot using
the implicit contextual information RMB).
Figure 10: Incomplete schema example. LLMs can infer missing values while NL22QL and hybrid methods fails (left). Hybrid methods can correctly extract the information while NLSQL and LLMs fail (right).
H USE OF LARGE LANGUAGE MODELS
made limited use of large language models Sondels-specifically ChatGPT and GitHub Copilot-for language polishing and routine coding assistance (autocompletion, refactoring, and boilerplate gen- eration). LLMs were not used to generate research ideas, experimental results, or claims. No non- public sensitive data was shared with these tools. All suggested text and code were independently reviewed, tested, and edited by the authors, who remain responsible for the content.
We
24

---

Published as conference paper at ICLR 2026
Table 11: Structured Cemi-Structured accuracy across all splits. A (pp) semi-structured minus
structured.
Split
Model
Structured Acc. (%)
Semi-Structurrdd Acc. (%)
A (pp)
S1
GPT-4o
89.47
90.53
+1.06
Gemini-2.5-PP
92.63
88.42
-4.21
Gemini-2.55-B
90,53
88.42
-2.11
Owen3-233BB
85.26
89.47
+4.21
LLM-NL2SQL
87.37
62.11
-25.26
XiYan
78.95
26.32
-52.3
H-STAR
75.79
80.00
+4.21
Weaver
88.42
91.58
+3.16
S2
GPT-4o
71.60
63.31
-8.29
Gemini-2.5-Proo
81.07
73.37
-7.70
Gemini-2.5-flash
73.96
67.46
-6.50
Qwen3-235B
57.40
-9.46
LLM-NL2SQL
24.26
15.98
-8.28
XiYan
30.18
18.94
-11.24
H-STAR
88.17
81.66
-6.51
Weaver
86.39
76.33
-10.06
GPT-4o
46.90
43.58
-3.32
Gemini-2.5-Pro
76.59
73.86
-2.73
Gemini-2.5-
61.24
63.07
+1.83
Qwen3-235B
37.62
38.07
+0.45
LLM-NL2SQL
74.77
48.18
-26.59
XiYan
73.79
34.94
-38.85
H-STAR
48.74
47.82
-0.92
Weaver
57.47
49.66
-7.81
S4
GPT-4o
53.85
48.72
-5.13
Gemini-2.5- Pro-Pro
60.76
59,49
-1.27
Gemini-2.5-flash
46.84
44,30
-2.54
Qwen3-235B
45.57
44.30
-1.27
I.LM-NI22QI.
64.10
51.28
-12.82
XiYan
55.13
16.67
-38.46
H-STAR
28.21
23.08
-5.13
Weaver
53.85
55.13
+1.28
$5
GPT-4o
21.32
20.54
-0.78
Gemini-2.5-Pro
41.31
33.98
-7.33
Gemini-2.5-fae
5.41
+0.40
Qwen3-235B
18.92
17.05
-1.87
LLM-NL2SQL
62.55
37.98
-24.77
XiYan
62.79
27.52
-35.27
H-STAR
8.11
8.14
+0.03
Weaver
31.78
29.46
-2.32
MI
GPT-4o
53.40
50.82
-2.8
Gemini-2.5-PP
82.44
78.45
-3999
Gemini-2,,5flast
75.88
71.19
-.69
Qwen3-235B
41.45
41.22
-0.23
LLM-NL2SQL
83.37
33.96
-49.41
XiYan
84.54
18.97
-65.57
M2
GPT-44o
19.88
16.87
-3.01
Gemini-2.5.
35.54
29.52
-6.02
Heminii-25-ffaal
21.69
21.69
0.00
(wwe33-2352
15.66
13.25
-2.11
LLM-NL2SQQ
71.69
30.72
-40.97
XiYan
76.51
19.88
-56.63
25


Reviews:
[{"review_id": "LAL2ZutRgk", "reviewer": "Reviewer_9Uki", "summary": "The authors perform a controlled study to examine how table representation affects model performance. The diagnostic benchmark they created has structured tables, but also has semi-structured variants, which are produced by selecting columns to change into free-text, reconstructing templates and serialize the updated table. They look into five key factors: structured vs semi-structured inputs, short vs long tables, multi-table alignment vs join operation tasks, simple lookups vs multi-step compositional queries and noisy schemas. The method families they test on are LLM-based, NL2SQL methods and hybrid methods. They generally find NL2SQL models to be better with structured tables and hybrid models to be more balanced with robustness across formats and peak accuracy.", "questions": "See W1.", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 4, "contribution": 3, "strengths": "S1. The paper explores various facets of the table representation, which are reasonable and comprehensive directions.\nS2. The paper is generally well structured and organized.", "weaknesses": "W1. Some of the claims don't seem to match the actual results. For instance, on lines 284-286, the claim is that \"LLMs degrade modestly\" and \"hybrids lead\" for RQ1. However, based on Table 2, the drop % for LLM methods is similar or even much lower than the Hybrid ones. It doesn't seem that hybrid models lead in that case.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "0Y81RN3XQu", "reviewer": "Reviewer_kAHU", "summary": "This paper presents a controlled study on how table representation, structured vs. semi-structured, affects model performance in Table Question Answering (Table QA). Using a verbalization pipeline that preserves table semantics, the authors compare NL2SQL, LLM-based, and hybrid approaches across varied settings of table complexity and query difficulty. Results show that structured inputs favor symbolic methods, semi-structured forms favor LLMs, and hybrid systems achieve the best balance, highlighting how representation choice fundamentally shapes reasoning accuracy and robustness.", "questions": "See the Weaknesses above.", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 2, "contribution": 2, "strengths": "- The study introduces a novel, well-controlled evaluation framework that isolates representation effects with strong methodological rigor. It provides comprehensive empirical evidence across datasets (BIRD, MMQA, TableEval), method families, and conditions, revealing consistent, interpretable trends. \n\n- The verbalization pipeline and diagnostic splits are technically elegant and reproducible, offering a valuable benchmark for future Table QA research. The analyses are thorough, uncovering key trade-offs and failure cases that inform model and benchmark design.", "weaknesses": "The paper is largely empirical, offering extensive measurements but limited analytical explanation for why representational shifts yield performance divergence: What internal representations or attention dynamics contribute to this behavior? While the benchmark is comprehensive, it focuses mainly on static accuracy; are there analyses on error propagation, confidence calibration, or reasoning trace fidelity under different table formats?\n\nThe verbalization pipeline relies on LLM paraphrasing—how consistent is this process across seeds, and how might linguistic variation bias outcomes? The study primarily evaluates medium-scale models and standard datasets; can the results generalize to larger instruction-tuned LLMs or real-world multi-table enterprise data?\n\nFinally, while comparisons are broad, statistical significance testing and variance reporting across multiple runs are limited. Could more rigorous uncertainty quantification strengthen empirical claims?", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "IRRaBJa9NX", "reviewer": "Reviewer_ZC3E", "summary": "This paper presents the first controlled experimental study on a key yet underexplored problem in Table QA: the impact of table representation on model performance. It provides a comparative analysis of NL2SQL, LLM, and hybrid methods across different representation formats. The research is rigorously designed and supported by extensive experiments.", "questions": "1.  **Additional Experiments on Schema Restoration**: Consider incorporating experiments that utilize methods like NameGuess[1] to restore damaged schemas, evaluating how such restoration impacts model performance.  \n2.  **Table Reconstruction Prior to Testing**: It may be beneficial to experiment with table reconstruction as a preprocessing step before applying the evaluation methods.  \n3.  **Mitigating LLM Judge Bias**: To address potential biases introduced by LLM-based evaluation, it is advisable to sample a subset of data for analysis—comparing LLM judgments with human scoring—to enhance the validity of the evaluation approach.\n\n[1] Zhang J, Shen Z, Srinivasan B, et al. NameGuess: Column name expansion for tabular data[J]. arXiv preprint arXiv:2310.13196, 2023.", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "1. **Substantial Innovativeness**: The impact of table representation formats on model performance is an important yet systematically understudied topic.  \n2. **Comprehensive Evaluation**: The assessment covers multiple approaches—including NL2SQL, LLMs, and hybrid methods—across various datasets and evaluation dimensions.", "weaknesses": "1.  **Limited Table Representations Explored**: Although this study systematically investigates the impact of table representation formats on model performance, the variety of representations examined remains limited. Other transformations—such as row/column permutation, transposition, and modality conversion (e.g., to visual representations)—could be considered.\n2.  **Room for Enhanced Table Diversity**: The current definition of short and long tables based solely on row count could be expanded. For instance, tables with very high column counts—common in fields like medical research—represent another important dimension of diversity.\n3.  **Over-Simplified Table Transformation Methods**: Even when considering only structured and semi-structured tables, the transformation methods applied (e.g., textual serialization and cell merging) remain relatively basic. More advanced structural transformations could be explored.\n4.  **Potential Data Insufficiency in Some Experiments**: The sample size in certain experiments (e.g., S4) may be insufficient for robust conclusions.\n5.  **Recommendation: From Analysis to Decision Support**: Beyond data analysis, we recommend developing a decision tree to guide practitioners in selecting the most suitable method for specific scenarios.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "ZX1OPnDJOe", "reviewer": "Reviewer_DE2a", "summary": "This paper presents the controlled study examining how table representation (structured vs. semi-structured formats) affects Table QA performance across different modeling paradigms. The paper introduces a pipeline that generates paired structured and semi-structured tables with identical content, enabling direct comparison of NL2SQL, LLM-based, and hybrid methods under controlled conditions. The study reveals consistent trade-offs.", "questions": "see weakness", "limitations": "", "rating": 4, "confidence": 2, "soundness": 2, "presentation": 2, "contribution": 2, "strengths": "1  The pipeline that generates semantically equivalent structured and semi-structured table pairs is reasonable.\n\n2  The four-dimensional diagnostic framework (table size, joins, query complexity, schema quality) provides good insights into how different factors interact with representation formats.\n\n3  The case studies and error analysis provide concrete examples", "weaknesses": "1 The verbalization process may not fully capture the complexity of naturally occurring semi-structured tables. Real-world tables often exhibit more irregular patterns and noise than the systematically generated semi-structured versions used in this study.\n\n2 The paper provides limited theoretical analysis of why different representations affect model performance. More fundamental insights into the cognitive or architectural reasons for these differences would strengthen the contribution.\n\n3 The paper could discuss the scale limitations in evaluation, for example, long tables with more than 100 rows.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)