TableReasoner: Schema-Centric TQA Framework

• The paper introduces a schema-centric, LLM-driven framework for table question answering by utilizing multi-step schema linking, iterative query refinement, and program execution.
• TableReasoner is designed to handle large, ambiguous tables by compressing them into focused schemas that reduce noise and overcome context-length limitations.
• Empirical results on SemEval-2025 Task 8 and DataBench show significant accuracy gains and scalability improvements over traditional table processing methods.

TableReasoner is a LLM-powered and programming-based framework for table question answering (TQA) designed for realistic tabular data characterized by large size, incomplete column semantics, and entity ambiguity. Rather than serializing an entire table as Markdown or CSV, it models a table through a schema that combines structural and semantic representations, applies multi-step schema linking to derive a focused table schema containing only query-relevant information, and then performs iterative reasoning with executable programs. The framework was introduced in “TableReasoner: Advancing Table Reasoning Framework with LLMs” and achieved first place in both subtasks of SemEval-2025 Task 8 (Xiong et al., 10 Jul 2025).

1. Scope, motivation, and problem formulation

TableReasoner addresses TQA in settings where plain prompting and direct code generation are unreliable. The motivating difficulties are explicitly tied to real-world tables: tables can be very large, column names may be abbreviated or semantically incomplete, entities in the question may be ambiguous relative to table values, and LLMs can hallucinate when given too much irrelevant table text. Existing approaches are described as struggling for complementary reasons. Methods that serialize the whole table in Markdown or CSV hit context-length limits on large tables; simple in-context prompting is brittle and loses accuracy as tables grow; and code-based methods, while stronger on computation, still often lack a principled account of which parts of the table matter and how question terms map to columns and values (Xiong et al., 10 Jul 2025).

Within the broader literature, these failure modes align with recurrent themes in LLM-based table reasoning. A survey of the area identifies instruction design, modular decomposition, tool use, and step-by-step reasoning as central methodological families, and highlights schema linking as a core challenge in aligning question entities with rows, columns, or cells (Zhang et al., 2024). Earlier prompting results also showed that LLMs can be competent few-shot table reasoners, but are sensitive to table size and truncation, with input often restricted to the first 22 rows, first 8 columns, and first 10 words per cell to keep prompts within about 2000 tokens (Chen, 2022). TableReasoner can be understood as a response to precisely these scaling and grounding constraints.

The framework treats table QA as a joint problem of schema understanding, question decomposition, symbolic execution, and iterative refinement. This suggests a shift away from “feed the whole table” workflows toward structured intermediate representations that reduce noise and constrain reasoning.

2. Schema-centric table modeling

The first stage of TableReasoner is table schema generation. The pipeline reads the spreadsheet in Python and converts it into a schema representation rather than raw table text. This schema combines structural signals and semantic signals. For each column it stores the data type, meta-statistics for numeric and categorical columns such as min, max, mean, median, or frequent categories, a small set of sampled cell values, and LLM-generated descriptions of the table and each column (Xiong et al., 10 Jul 2025).

A central claim of the framework is its scaling advantage. The paper states that the schema representation has token complexity roughly $O(N)$ with $N$ columns, rather than $O(M\times N)$ for a full table with $M$ rows. This makes the representation more suitable for very large tables and provides the foundation for later pruning and reasoning. In practical terms, the schema is intended to retain enough semantic content for question grounding while discarding most row-level redundancy.

This design is schema-centric rather than retrieval-centric. In that respect it differs from systems such as OpenTab, which operate in an open-domain setting where the relevant table is not given in advance and the system must first retrieve candidate tables with BM25, then generate and execute SQL, and finally map execution results to answers (Kong et al., 2024). TableReasoner instead assumes a given table and concentrates its effort on understanding, compressing, and disambiguating that table before reasoning.

The schema-centric choice also addresses a broader weakness of linearization-based methods. Related work argues that flat text representations lose structural relations and become vulnerable to prompt-length effects and “lost-in-the-middle” behavior (Wang et al., 13 Jan 2026). TableReasoner does not replace the table with a graph representation, but it does avoid verbatim serialization and thereby reduces both token load and irrelevant context.

3. Focused table schema and schema linking

A key concept in the framework is the “focused table schema,” defined as the pruned schema retained after schema linking. TableReasoner’s “parsing-linking-refinement” flow first parses the question into sequential sub-queries, then links each sub-query to relevant columns and entities, and finally removes irrelevant columns while preserving any entity-alignment information needed for later reasoning (Xiong et al., 10 Jul 2025).

In the parsing stage, the LLM decomposes the original question into smaller executable sub-questions. In the linking stage, the model identifies relevant columns for each sub-query and also performs entity linking when the question mentions specific values. Entity linking is deliberately hybrid. The LLM first detects entities and suggests likely columns; Python then reads all entries from those columns and uses Longest Common Subsequence matching to retrieve candidate values whose overlap with the query entity exceeds 0.6; finally the LLM selects the exact aligned value from the recalled candidates. The example given in the paper is aligning “Mr Harari” in the question to “Yuval Noah Harari” in the table. The output is a focused schema containing only columns and values relevant to the question, thereby reducing noise, token usage, and ambiguity.

This stage is distinct from the later query refinement module. The paper emphasizes that schema linking handles “what table pieces are relevant,” whereas query refinement handles “what sequence of operations is needed to answer the question.” That distinction is methodologically important because it separates semantic grounding from operational planning.

A plausible implication is that the focused table schema functions as both a compression mechanism and an anti-hallucination device. This interpretation is consistent with the paper’s claim that removing schema linking degrades performance, and with the survey literature’s description of schema linking as a central bottleneck for LLM-based table reasoning (Zhang et al., 2024).

4. Query refinement, iterative thinking, and program-assisted execution

TableReasoner’s full pipeline comprises five sequential modules: table schema generation, schema linking, query refinement, program-assisted solution generation, and answer summary. Query refinement is a later decomposition step that further breaks the question into progressive sub-queries with associated relevant column names using Chain-of-Thought prompting. Because this operates over the already focused, denoised schema, the resulting sub-queries are described as more executable and better grounded. The appendix prompt instructs the model to infer intent, decompose the query step-by-step, and explicitly list the relevant columns for each sub-query while ensuring those column names actually exist in the schema (Xiong et al., 10 Jul 2025).

The reasoning workflow is wrapped in an iterative thinking architecture modeled as a ReAct-like “thought-action-observation” loop. In this formulation, “thought” corresponds to the decomposed sub-queries, “action” to generated code or program ideas, and “observation” to the result of executing the code. After each cycle, the system checks whether enough information has been gathered to answer the question; if not, it generates a follow-up query and repeats. The loop is bounded to a maximum of five reasoning rounds. The paper states that this iterative design is especially useful for complex TQA types such as list queries, which often require deduplication, multi-column correlation, and multiple retrieval or filtering steps.

Programming-based reasoning is central rather than auxiliary. After schema linking and query refinement, the framework prompts the LLM to produce a Program-of-Thoughts solution using the focused schema and refined queries. The generated Python code is executed in an isolated Python interpreter to produce verifiable results. Arithmetic, filtering, aggregation, and other table operations are thus delegated to code execution instead of free-form generation, which the paper argues greatly reduces numerical hallucination. The answer-summary module then formats the executed reasoning trace into the strict output format required by the benchmark.

The appendix further shows that the system uses dedicated prompts for the description stage, query refinement stage, iterative thinking stage, code generation stage, and final answer formatting, and explicitly recommends structured output, few-shot examples, and CoT-style prompting to stabilize behavior. This places TableReasoner within a larger class of tool-using and executor-based systems, but with tighter integration between schema grounding and program synthesis than one-pass code baselines.

5. Empirical results, benchmark standing, and ablations

TableReasoner was evaluated on SemEval-2025 Task 8 and on the associated DataBench benchmark, including both the full test set and DataBench Lite. The task covers real-world tabular data and multiple QA types, including boolean, category, number, list[category], and list[number]. The comparisons include two baseline paradigms: zero-shot in-context learning on Markdown tables and a direct code-based approach that generates Program-of-Thoughts solutions from a single LLM. The framework is also evaluated with multiple backbones, including Qwen2.5-7B, Qwen2.5-32B, Qwen2.5-72B, Qwen2.5-32B-Coder, Llama3.1-8B, Llama3.3-70B, TeleChat2-35B, Mistral-Large, and GPT-4o (Xiong et al., 10 Jul 2025).

The main reported result is that TableReasoner substantially outperforms both baselines and wins first place in both subtasks of SemEval-2025 Task 8. The paper reports absolute improvements of more than 40 percentage points over zero-shot in-context learning in many settings. With Qwen2.5-32B as the backbone, TableReasoner reaches 89.85 on DataBench and 89.66 on DataBench Lite without fine-tuning. A hybrid configuration using Mistral-Large for program generation and Qwen2.5-32B for the other modules reaches 90.61 and 90.04. With supervised fine-tuning and majority voting, performance rises to 93.87 and 91.76, which the authors describe as state of the art.

The analysis attributes these gains to framework design rather than scale alone. Even Qwen2.5-7B benefits significantly from the framework, and the system is described as more scalable and robust across table sizes, with minimal degradation on large tables, unlike zero-shot in-context learning, which declines sharply as tables get bigger.

The ablation evidence is particularly specific. Removing table schema generation and reverting to Markdown text causes the largest degradation, with accuracy dropping by 5.37 points on the test set and 1.92 on Lite. Removing schema linking or query refinement also hurts performance. The authors also show that fine-tuning improves results and that majority voting based on self-consistency improves them further. In the appendix, they note that vanilla prompting suffers from truncation, hallucination, and lack of explicit reasoning, which helps explain why the structured workflow is more reliable.

For supervised fine-tuning, the reported configuration uses LoRA on Qwen2.5-32B-Instruct and Mistral-Large, trains for five epochs with learning rate $5\times10^{-6}$, LoRA rank 8, batch size 32, and temperature 0 at inference. Fine-tuning data are constructed by collecting reasoning paths from multiple strong LLMs over the train and dev sets, filtering incorrect paths, and selecting higher-quality trajectories according to rules favoring correct column-to-subquery alignment and richer code generation.

6. Relation to adjacent frameworks and methodological significance

TableReasoner belongs to a broader movement in which table reasoning is no longer treated as pure answer generation but as staged, tool-augmented, execution-grounded inference. The survey literature identifies modular decomposition, tool using, and step-by-step reasoning as especially active directions (Zhang et al., 2024). TableReasoner instantiates all three: it decomposes reasoning into modules, uses Python execution, and employs progressive sub-queries over a grounded table representation.

Several neighboring systems illuminate its design choices by contrast. TabSQLify decomposes the problem through text-to-SQL generation to extract a relevant sub-table before reasoning, with strong gains on large tables and prompt reduction from an average of 183 cells to 32 under row-plus-column filtering on WikiTQ (Nahid et al., 2024). OpenTab similarly uses executable SQL, but targets open-domain table reasoning where relevant tables must be retrieved from a corpus and supports a Retriever–Reasoner architecture with BM25, RowSelector, Coder, and Reader (Kong et al., 2024). PoTable advances a five-stage analyst-like workflow—Initialization, Row Selection, Data Type Cleaning, Reasoning, and Final Answering—implemented through plan-then-execute reasoning and real-time code regeneration (Mao et al., 2024). RoT emphasizes iterative row-wise traversal and reflection as a training-free alternative to Long CoT, reporting that non-reasoning models with RoT outperform reasoning LLMs with Long CoT by an average of 4.3% (Zhang et al., 21 May 2025).

Against this landscape, TableReasoner’s distinctive feature is the focused table schema. Rather than retrieving tables, traversing rows, or decomposing into staged analyst workflows alone, it concentrates on schema abstraction and schema pruning as the primary interface between table content and executable reasoning. This suggests that its principal contribution is not only tool use, but tool use after aggressive semantic compression and alignment.

A separate naming issue is also relevant. A later paper on “Reasoning by Commented Code for Table Question Answering” describes a framework “presented in this paper under the ‘reasoning by commented code’ framework” as TableReasoner, emphasizing multi-line executable Python with explicit comments and reporting 70.9% accuracy with Qwen2.5-Coder-7B-Instruct and 84.3% when combined with Table-R1 on WikiTableQuestions (Pyo et al., 31 Jan 2026). The term “TableReasoner” therefore appears in more than one context. In the SemEval-2025 framework, however, the name specifically denotes the schema-centric, iterative, five-module system introduced in 2025 (Xiong et al., 10 Jul 2025).

7. Limitations, practical trade-offs, and future directions

The main limitation acknowledged by the authors is inference cost. Because the reasoning workflow is iterative and may require several rounds, it can be time-consuming. The authors also note that prompt design remains important and was not exhaustively studied across all formatting choices (Xiong et al., 10 Jul 2025). These trade-offs are consistent with a general pattern in execution-grounded table reasoning: stronger reliability is often purchased with additional orchestration, more prompts, and more runtime.

The future direction suggested in the paper is adaptive action-flow strategies to balance latency and accuracy. This suggests a move from a fixed upper bound of five rounds toward more selective control of when to decompose further, when to execute, and when to stop.

Within the wider field, related work points to several adjacent trajectories: graph-structured evidence propagation for explicit reasoning paths and permutation robustness (Wang et al., 13 Jan 2026), cell-level attribution for faithful small-model reasoning (Gajjar et al., 30 Apr 2026), and agentic search with rollback and execution feedback for complex stateful table reasoning (Luo et al., 15 Feb 2026). TableReasoner does not claim these properties directly, but its schema-centric and execution-grounded design places it near the center of an emerging methodological consensus: robust table reasoning requires explicit intermediate structure, constrained evidence access, and verifiable computation rather than ungrounded free-form generation.

Overall, TableReasoner is best understood as a scalable framework for large-table TQA in which schema abstraction, focused schema linking, progressive query refinement, and executable reasoning are tightly coupled. Its empirical results on SemEval-2025 Task 8 and DataBench, together with its ablation evidence, make it a representative example of how LLM-based table reasoning has evolved from prompt engineering toward grounded, decomposed, and executable systems (Xiong et al., 10 Jul 2025).