TabScope: Question-Adaptive Scope Selection for Table Question Answering

# TabScope: Question-Adaptive Scope Selection for Table Question Answering
Source: [https://arxiv.org/html/2609.03395](https://arxiv.org/html/2609.03395)
Yuxiang Wang,Junhao Gan,Jianzhong QiAffiliation:The University of MelbourneEmail:[yuxiang\.wang8@student\.unimelb\.edu\.au](mailto:)Affiliation:\{junhao\.gan, jianzhong\.qi\}@unimelb\.edu\.au

###### Abstract

Large Language Models \(LLMs\) have shown strong performance on table question answering, yet their accuracy often degrades as table size increases\. We find that this degradation is not uniform across question types\. Localization\-sensitive questions are particularly affected by irrelevant table content, while questions requiring broader evidence may still benefit from full\-table reasoning\. Based on this observation, we propose a question\-adaptive framework that dynamically selects between localized and full\-table reasoning\. The framework constructs question\-specific sub\-tables through operation\-aware table decomposition and uses the predicted question type to determine the appropriate reasoning mode\. We further introduce silver reference sub\-tables for evaluating evidence selection and constructSLQA, a benchmark based on real\-world long tables\. Experiments on WikiTQ andSLQAshow that localization is particularly effective for lookup and local reasoning questions, while adaptive selection between localized and full\-table reasoning achieves the best overall performance\. These results highlight that long\-table QA requires deciding not only how to localize, but also when to localize\. Our code and datasets will be made available upon publication of the paper\.

## 1Introduction

Large Language Models \(LLMs\) have demonstrated strong reasoning capabilities for table question answering \(TableQA\), particularly when combined with chain\-of\-thought \(CoT\) prompting\([Wei et al\., 2022](https://arxiv.org/html/2609.03395#bib.bib1);[Chen, 2023](https://arxiv.org/html/2609.03395#bib.bib2)\)\. However, their performance remains sensitive to table size\. As tables grow longer, LLMs struggle to identify the small set of rows and columns needed to support the answer from noisy inputs, leading to lower answer accuracy\([Ye et al\., 2023](https://arxiv.org/html/2609.03395#bib.bib3);[Liu et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib4)\)\.

Our analysis shows that this degradation varies across question types\. Localization is particularly effective when the answer depends on a small, restricted table region\. In contrast, questions requiring broad comparison sets, complete aggregation domains, or information distributed across many rows may benefit from retaining the full table\. Decomposition may otherwise remove necessary context or introduce retrieval errors\. Figure[1](https://arxiv.org/html/2609.03395#S1.F1)summarizes these observations\. Full\-table reasoning performs worse on large tables, while the benefit of localization varies with both the question and table size\. This leads to the central question of our work:*when should a TableQA model localize the table, and when should it reason over the full context?*

Figure 1:Motivation for question\-adaptive table scope selection using GPT\-5\-mini as base model\. \(a\) Full\-table QA performs worse on large tables\. \(b\) Localization helps questions requiring compact regions, whereas questions involving many rows or entities favor full\-table reasoning\. Small/medium and large tables correspond toWikiTQandSLQA, respectively\.We regard TableQA as a question\-adaptive reasoning problem rather than a fixed decomposition pipeline, especially for long tables\. We proposeTabScope, which first determines whether a question is better served by the full table or a compact sub\-table\. When localization is expected to be beneficial,TabScopeuses an operation\-aware decomposer with refinement to select the relevant rows and columns before reasoning\. Otherwise, the model reasons directly over the full table\. This design uses compact table regions when helpful while preserving broader context when necessary\.

Existing TableQA benchmarks present two additional limitations for studying evidence localization\. First, datasets such as WikiTableQuestions\([Pasupat and Liang, 2015](https://arxiv.org/html/2609.03395#bib.bib5)\)provide only tables, questions, and final answers, without explicit annotations of the supporting sub\-tables\. This makes it difficult to evaluate the quality of intermediate evidence selection\. Second, most existing benchmarks[Pasupat and Liang \(2015\)](https://arxiv.org/html/2609.03395#bib.bib5);[Chen et al\. \(2020\)](https://arxiv.org/html/2609.03395#bib.bib6);[Wu et al\. \(2025\)](https://arxiv.org/html/2609.03395#bib.bib14)contain relatively small tables and provide limited coverage of long\-table settings\. We address the first limitation by constructing silver reference sub\-tables for evaluating decomposition quality\. For the second, we develop an automatic pipeline for generating question–answer pairs from real\-world tables and use it to constructSLQA, a benchmark for long\-table question answering\.

Our main contributions are as follows:

- •We construct silver reference sub\-tables for directly evaluating decomposition quality and propose an operation\-aware decomposition method that improves evidence selection\.
- •We analyze when to localize and introduce a question\-adaptive framework selects between localized and full\-table reasoning\.
- •We develop an automatic pipeline for generating validated question–answer pairs from real\-world tables and use it to buildSLQA, a benchmark for long\-table question answering\.

## 2Related Work

Recent LLM\-based TableQA methods increasingly address the difficulty of reasoning over large tables by reducing, retrieving, or transforming relevant rows and columns before answer generation\. We first review two main lines of localization\-oriented methods:*semantic evidence selection*and*operation\-aware table reduction*\. We then review existing TableQA benchmarks and evidence annotations, which provide the context for our silver sub\-table construction and long\-table benchmark\.

##### Evidence localization and retrieval\.

One line of work selects a smaller sub\-table containing relevant evidence before reasoning\. DATER\([Ye et al\., 2023](https://arxiv.org/html/2609.03395#bib.bib3)\)uses LLMs to decompose both table and questions, selecting relevant rows and columns for downstream reasoning\. H\-STAR\([Abhyankar et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib7)\)similarly extracts relevant table regions within a hybrid symbolic–textual framework\. Others use retrieval\-augmented methods for table reasoning\. TableRAG\([Chen et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib20)\)retrieves relevant schema and cell information for large\-scale table understanding, T\-RAG\([Pan et al\., 2022](https://arxiv.org/html/2609.03395#bib.bib8)\)combines dense table retrieval with generation for open\-domain TableQA, and GTR\([Zou et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib9)\)performs graph\-based hierarchical retrieval for cross\-table question answering\. While these methods mainly improve how relevant evidence is retrieved or selected, our approach makes evidence selection operation\-aware and treats localization as a question\-dependent decision\.

##### Program\-guided table decomposition\.

Another direction obtains intermediate tables through explicit operations or executable programs\. Chain\-of\-Table\([Wang et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib10)\)iteratively transforms the table during reasoning and treats intermediate tables as evolving reasoning states\. Table\-Critic\([Yu et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib22)\)iteratively critiques and refines the intermediate table before answer generation\. ReAcTable\([Zhang et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib11)\)combines LLM reasoning with tools such as SQL and Python executors to manipulate tabular data step by step\. TabSQLify\([Nahid and Rafiei, 2024](https://arxiv.org/html/2609.03395#bib.bib12)\)constructs question\-relevant sub\-tables through SQL queries, while Plan\-of\-SQLs\([Nguyen et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib13)\)executes a sequence of SQL steps to provide interpretable intermediate reasoning traces\. In contrast,TabScopedoes not require a full operation chain or executable program, and applies decomposition only when localized reasoning is helpful\.

![Refer to caption](https://arxiv.org/html/2609.03395v1/overview.png)Figure 2:Overview ofTabScope\. The framework selects localized or full\-table reasoning for each question\. The localized path constructs a refined sub\-table, whereas the full\-table path bypasses decomposition\.
##### Evidence supervision and long\-table evaluation\.

Most TableQA benchmarks, such as WikiTableQuestions, provide tables, questions, and final answers, but no explicit annotations of the supporting rows and columns\([Pasupat and Liang, 2015](https://arxiv.org/html/2609.03395#bib.bib5)\)\. This limits direct evaluation of intermediate sub\-tables\. In addition, many commonly used benchmarks contain relatively small tables, typically under 4K table tokens, making them less suited for evaluating long\-table reasoning\([Chen et al\., 2020](https://arxiv.org/html/2609.03395#bib.bib6);[Wu et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib14);[Cheng et al\., 2022](https://arxiv.org/html/2609.03395#bib.bib15)\)\. We address these gaps by constructing silver reference sub\-tables for evaluating decomposition quality and by introducingSLQA, a benchmark built from real\-world long tables\.

## 3Methodology

### 3\.1Problem Formulation

Given a tableTT, a questionqq, and a reference answeraa, the goal of TableQA is to predict an answera^\\hat\{a\}that matchesaa\. We represent the table asT=\(H,R\)T=\(H,R\), whereH=h1,…,hmH=\{h\_\{1\},\\ldots,h\_\{m\}\}denotes the column headers andR=r1,…,rnR=\{r\_\{1\},\\ldots,r\_\{n\}\}denotes the table rows\. For each question, a model can either reason over the full tableTTor reduce it to a question\-specific sub\-tableT′T^\{\\prime\}\. We define the sub\-table asT′=T⁡\[R′,C′\]T^\{\\prime\}=T\[R^\{\\prime\},C^\{\\prime\}\], whereR′⊆RR^\{\\prime\}\\subseteq RandC′⊆HC^\{\\prime\}\\subseteq Hare the selected rows and columns\. Our goal is not to always minimize the table, but to select the appropriate table scope for each question\.

### 3\.2Overview ofTabScope

We proposeTabScope, a question\-adaptive framework that selects the appropriate table scope before answer generation\. As illustrated in Figure[2](https://arxiv.org/html/2609.03395#S2.F2),TabScopeconsists of three components\. \(i\) An LLM\-based scope selector predicts the question type and uses a fixed policy to choose localized or full\-table reasoning\. \(ii\) When localization is selected, an operation\-aware decomposer retrieves the required rows and columns and refines them into a question\-specific sub\-table\. \(iii\) The answer model generates the answer from the selected input, either the refined sub\-table or the original full table\.

### 3\.3Question\-Adaptive Scope Selection

TabScopeis designed to determine whether localization should be applied to each question\. The scope selector consists of an LLM\-based question\-type classifierCθC\_\{\\theta\}and a fixed type\-to\-scope policyπ\\pi\. Given a questionqqand tableTT, the classifier predicts a predefined question typeτ^\\hat\{\\tau\}\. The policy then selects the reasoning mode according to the predicted type and table\-size regime:

τ^\\displaystyle\\hat\{\\tau\}=Cθ​\(q,T\),\\displaystyle=C\_\{\\theta\}\(q,T\),\(1\)z\\displaystyle z=π⁡\(τ^,s⁡\(T\)\),\\displaystyle=\\pi\\bigl\(\\hat\{\\tau\},s\(T\)\\bigr\),z\\displaystyle z∈\{local,full\}\.\\displaystyle\\in\\\{\\mathrm\{local\},\\mathrm\{full\}\\\}\.
Here,s⁡\(T\)s\(T\)denotes the table\-size regime\. Ifz=localz=\\mathrm\{local\},TabScopeconstructs a question\-specific sub\-table before answer generation\. Otherwise, it bypasses decomposition and reasons directly over the original table\.

We deriveπ\\pithrough an offline analysis on the validation set\. For each question type, we compare localized reasoning with full\-table reasoning and assign the better\-performing mode\. We additionally account for table size when the preferred mode changes on large tables\. At inference time, the LLM predicts onlyτ^\\hat\{\\tau\}, while the fixed policy determines the final scope\. The classification prompt is provided in Appendix[C\.4](https://arxiv.org/html/2609.03395#A3.SS4), and the type\-wise analysis used to defineπ\\piis reported in Appendix[B](https://arxiv.org/html/2609.03395#A2)\.

### 3\.4Operation\-Aware Table Decomposition

When the scope selector chooses localized reasoning,TabScopeconstructs a question\-specific sub\-table through operation\-aware decomposition\. The goal is to retrieve the rows and columns needed for the question’s reasoning process, rather than relying only on lexical overlap between the question and table content\. The decomposer has three steps: operation\-aware retrieval, evidence aggregation, and sub\-table refinement\. All the prompts used are shown in Appendix[C](https://arxiv.org/html/2609.03395#A3)\.

##### Operation\-aware retrieval\.

The decomposer first identifies the operation required by the question, such as lookup, filtering, comparison, or counting\. This operation determines both the rows and columns to retrieve\. For example, for the question“How many Australian teams scored above 10?”, the decomposer should retrieve rows whose country is Australia and whose score is greater than 10, together with columns such as country, score, and team identifier\. Although the final answer is only a count, the sub\-table must preserve the evidence needed to verify the filtering operation\. This shows why decomposition should be guided by the operation rather than lexical overlap alone\.

##### Evidence aggregation\.

A single LLM retrieval may be unstable because generation can vary across samples\. It may miss necessary evidence or include weakly related rows and columns\. To make retrieval more robust, we sampleKKretrieval outputs for the same question, whereK=4K=4by default\.

We aggregate row retrievals and column retrievals separately\. Each retrieval output is treated as a candidatecc, which contains either a selected row set or a selected column set\. Each candidate is assigned a reliability scores⁡\(c\)s\(c\)\. When generation confidence is available for the LLM,s⁡\(c\)s\(c\)is computed from the average token log probability of the candidate\. Otherwise, we sets⁡\(c\)=0s\(c\)=0, reducingw⁡\(g\)w\(g\)to frequency\-based voting\. Candidates that select the same normalized row set or column set are merged into a candidate groupgg\.

For each group, we compute a support weight:

w⁡\(g\)=∑c∈gexp⁡\(s⁡\(c\)\)\.w\(g\)=\\sum\_\{c\\in g\}\\exp\(s\(c\)\)\.\(2\)Here,w⁡\(g\)w\(g\)measures how strongly the retrieval samples support groupgg\. The termexp⁡\(s⁡\(c\)\)\\exp\(s\(c\)\)converts the candidate score into a positive voting weight, so a group receives higher support when the same evidence set appears multiple times or when its candidates have higher reliability scores\.

After aggregation, each distinct row set returned by the retrieval samples forms a row group, and each distinct column set forms a column group\. Groups returned more frequently or with higher confidence receive larger weights\. For example, if three out of four samples retrieve the same rows, a candidate sub\-table containing these rows should receive stronger support\.

To construct candidate sub\-tables, we first rank the row groups and column groups by their support weights\. We progressively union the top\-ranked groups to form candidate row setsR′R^\{\\prime\}and candidate column setsC′C^\{\\prime\}, removing duplicate candidates\. We then enumerate the resulting row–column combinations and score each candidate sub\-tableT⁡\[R′,C′\]T\[R^\{\\prime\},C^\{\\prime\}\]using the support and compactness criteria defined below\. For a candidate row setR′R^\{\\prime\}, we compute:

RowScore⁡\(R′\)=∑g∈Gr;g⊆R′w⁡\(g\)∑g∈Grw⁡\(g\)\.\\mathrm\{RowScore\}\(R^\{\\prime\}\)=\\frac\{\\sum\_\{g\\in G\_\{r\};g\\subseteq R^\{\\prime\}\}w\(g\)\}\{\\sum\_\{g\\in G\_\{r\}\}w\(g\)\}\.\(3\)Here,GrG\_\{r\}is the set of distinct row groups,ggis one retrieved row set, andw⁡\(g\)w\(g\)is its weight\. Thus,RowScore⁡\(R′\)\\mathrm\{RowScore\}\(R^\{\\prime\}\)is the proportion of total row\-group weight covered byR′R^\{\\prime\}\. The column scoreColScore⁡\(C′\)\\mathrm\{ColScore\}\(C^\{\\prime\}\)is computed in the same way over the column groups\.

We combine the two scores as:

Support⁡\(R′,C′\)=RowScore⁡\(R′\)⋅ColScore⁡\(C′\)\.\\mathrm\{Support\}\(R^\{\\prime\},C^\{\\prime\}\)=\\sqrt\{\\mathrm\{RowScore\}\(R^\{\\prime\}\)\\cdot\\mathrm\{ColScore\}\(C^\{\\prime\}\)\}\.\(4\)
The support score is high only when the candidate sub\-table covers both the rows and columns repeatedly selected across retrieval samples\.

We then balance this support with sub\-table size:

S⁡\(R′,C′\)=Support⁡\(R′,C′\)ρ​\(R′,C′\)α,ρ⁡\(R′,C′\)=\|R′\|⋅\|C′\|\|R\|⋅\|H\|\.S\(R^\{\\prime\},C^\{\\prime\}\)=\\frac\{\\mathrm\{Support\}\(R^\{\\prime\},C^\{\\prime\}\)\}\{\\rho\(R^\{\\prime\},C^\{\\prime\}\)^\{\\alpha\}\},\\rho\(R^\{\\prime\},C^\{\\prime\}\)=\\frac\{\|R^\{\\prime\}\|\\cdot\|C^\{\\prime\}\|\}\{\|R\|\\cdot\|H\|\}\.\(5\)Here,ρ⁡\(R′,C′\)\\rho\(R^\{\\prime\},C^\{\\prime\}\)is the proportion of table cells retained by the candidate, and coefficientα∈\[0\.1,0\.3\]\\alpha\\in\[0\.1,0\.3\]controls the penalty on large sub\-tables\. We select the row–column combination with the highestS⁡\(R′,C′\)S\(R^\{\\prime\},C^\{\\prime\}\)as the final decomposed tableT′=T⁡\[R′,C′\]T^\{\\prime\}=T\[R^\{\\prime\},C^\{\\prime\}\]\.

##### Sub\-table refinement\.

After evidence aggregation,TabScopeperforms one refinement round by default to verify whether the sub\-tableT′T^\{\\prime\}is sufficient for answering the questionqq\. Givenqq, the full tableTT, andT′T^\{\\prime\}, the verifier determines whether additional rows, columns, or both are needed\. If necessary, the missing evidence is added toT′T^\{\\prime\}, which is then passed to the answer modelMM\.

### 3\.5Answer Generation

After scope selection, each question follows a single reasoning path\. The QA modelMManswers from the\(q,T′\)\(q,T^\{\\prime\}\)pair when localized reasoning is selected, and from\(q,T\)\(q,T\)pair otherwise\.

## 4Experiments

We evaluateTabScopeto answer three questions\.RQ1:How effectively does operation\-aware decomposition identify compact and sufficient evidence?RQ2:Can localization mitigate performance degradation on long tables?RQ3:Can question\-adaptive scope selection outperform fixed full\-table or localized reasoning?

DatasetTable Statistics\# QA PairsCols\.RowsTokensTrainValid\.TestWikiTQ6\.425\.4662\.611,3212,8314,344SLQA11\.0733\.89,786\.21,3242391,110WTQ\-SubTab1\.86\.5104\.8––4,344Table 1:Statistics of the evaluation resources, averaged over questions\.WikiTQmainly contains small and medium tables, whereas allSLQAtables exceed4,0964\{,\}096serialized tokens\.WTQ\-SubTabcontains silver sub\-tables for the4,3444\{,\}344WikiTQtest questions\.### 4\.1Experimental Setup

##### Base Models\.

We use two base LLMs from different families: LLaMA\-3\.3\-70B[Dubey et al\. \(2024\)](https://arxiv.org/html/2609.03395#bib.bib16), and GPT\-5\-mini[OpenAI \(2026\)](https://arxiv.org/html/2609.03395#bib.bib17)\. They cover both open\-source and closed\-source settings, as well as large and relatively smaller LLMs\. Detailed settings are provided in Appendix[D](https://arxiv.org/html/2609.03395#A4)\.

Figure 3:Generated QA pair examples\.
##### Benchmarks and Evaluation Resources\.

We evaluateTabScopeon three benchmarks\. Table[1](https://arxiv.org/html/2609.03395#S4.T1)shows the statistics for these benchmarks\.

##### WikiTableQuestions \(WikiTQ\)\.

WikiTableQuestions\([Pasupat and Liang, 2015](https://arxiv.org/html/2609.03395#bib.bib5)\)is a widely used TableQA benchmark with diverse question types and tables spanning a broad range of sizes, including tables which sizes exceed4,0964\{,\}096tokens\. We useWikiTQfor standard TableQA evaluation, table\-size analysis, and type\-wise scope analysis\.

CategoryMethodWikiTQSLQAGPTLLaMAAvg\.GPTLLaMAAvg\.DecompositionTableRAG\([Chen et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib20)\)69\.556\.863\.247\.449\.748\.6TabSQLify\([Nahid and Rafiei, 2024](https://arxiv.org/html/2609.03395#bib.bib12)\)73\.572\.372\.959\.334\.046\.7Table\-Critic\([Yu et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib22)\)–70\.1––52\.3–DATER\([Ye et al\., 2023](https://arxiv.org/html/2609.03395#bib.bib3)\)76\.370\.573\.456\.054\.255\.1Chain\-of\-Table\([Wang et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib10)\)75\.871\.873\.863\.157\.260\.2TabScope\(decomposition\-only\)82\.476\.879\.672\.361\.967\.1Full\-tableRoT\([Zhang et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib21)\)81\.778\.780\.270\.354\.162\.2CoT[Wei et al\. \(2022\)](https://arxiv.org/html/2609.03395#bib.bib1)82\.178\.580\.372\.162\.567\.3AdaptiveTabScope83\.381\.182\.273\.462\.868\.1Table 2:Exact\-match accuracy \(%\) onWikiTQandSLQA\. The decomposition\-only variant applies operation\-aware decomposition to every question, whereas theTabScopeadaptively selects between localized and full\-table reasoning\.GPTandLLaMAdenote GPT\-5\-mini and LLaMA\-3\.3\-70B, respectively\.Avg\.denotes the average across the two answer models and is omitted when one result is unavailable\. The best and second\-best results per column are shown in bold and underlined, respectively\. Rows highlighted in green denote variants of our method\.
##### SLQA\.

Existing TableQA benchmarks contain relatively few long tables \(token size exceeds4,0964\{,\}096tokens\), making it difficult to systematically evaluate long\-table reasoning\. We therefore constructSLQA, a dedicated long\-table TableQA benchmark\. We extract tables from Spider\([Yu et al\., 2018](https://arxiv.org/html/2609.03395#bib.bib18)\)whose table sizes exceed4,0964\{,\}096tokens, but replace the original NL\-to\-SQL questions with newly generated TableQA questions\. We use GPT\-4o mini\([OpenAI, 2024](https://arxiv.org/html/2609.03395#bib.bib19)\)to generate question–answer pairs from four evidence scopes: a cell, a row, a column, or a sub\-table\. The model first identifies an answer supported by the specified evidence and then formulates the corresponding question\. All generated pairs are manually reviewed with fewer than30%30\\%requiring correction\. The generation prompts and detailed analysis are provided in Appendix[E\.1](https://arxiv.org/html/2609.03395#A5.SS1)\. Figure[3](https://arxiv.org/html/2609.03395#S4.F3)shows examples of generated QA pairs\.

##### WTQ\-SubTab\.

Final\-answer accuracy alone does not reveal whether a decomposition method retrieves the correct intermediate rows and columns\. We therefore constructWTQ\-SubTab, a silver\-reference evaluation set derived fromWikiTQ\. Each instance consists of a question, its original table, and a silver sub\-table containing the rows and columns needed to answer or verify the question\.

We compare three construction strategies using200200randomly sampledWikiTQQA pairs with manually annotated gold sub\-tables\. Schema\-based construction first asks an LLM to identify question\-relevant schema elements and values, which are then mapped back to the original table\. Direct generation instead asks the LLM to predict the target sub\-table directly\. The third strategy applies a verifier to the directly generated sub\-table and repairs missing, invalid, or redundant selections\. Direct generation with refinement achieves the highest agreement with the human annotations and is therefore used to constructWTQ\-SubTab\. Detailed results are reported in Appendix[E\.2](https://arxiv.org/html/2609.03395#A5.SS2)\.

Given an instance\(q,T,a\)\(q,T,a\), an LLM selects the minimal supporting rows and columns\. A verifier then detects invalid, incomplete, or unnecessarily large selections and requests a repair when needed\. The resulting reference sub\-table is defined asT∗=T⁡\[R∗,C∗\]T^\{\*\}=T\[R^\{\*\},C^\{\*\}\], whereR∗R^\{\*\}andC∗C^\{\*\}denote the verified rows and columns\.

WTQ\-SubTabis used only to evaluate decomposition quality through row\-, column\-, and cell\-level matching\. Its silver annotations are not available toTabScopeduring inference\. Construction prompts are provided in Appendix[E\.3\.1](https://arxiv.org/html/2609.03395#A5.SS3.SSS1)\.

##### Baselines\.

We compareTabScopewith two groups of baselines\.

Decomposition\-based methodsreduce or transform the table before answering\. DATER\([Ye et al\., 2023](https://arxiv.org/html/2609.03395#bib.bib3)\)decomposes questions and tables to select relevant rows and columns\. Chain\-of\-Table\([Wang et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib10)\)iteratively applies table operations and uses the final transformed table for answer generation\. TabSQLify\([Nahid and Rafiei, 2024](https://arxiv.org/html/2609.03395#bib.bib12)\)generates SQL queries to construct question\-relevant sub\-tables\. TableRAG\([Chen et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib20)\)retrieves relevant schema and cells for large\-table reasoning, while Table\-Critic\([Yu et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib22)\)iteratively critiques and refines a candidate sub\-table before answer generation\. For a controlled comparison, we use each decomposition method only to produce its final sub\-table\. All resulting sub\-tables are passed to the same answer model using an identical chain\-of\-thought prompt and answer normalization\.

Full\-table reasoning methodsretain the original table during answer generation\. Full\-table CoT[Wei et al\. \(2022\)](https://arxiv.org/html/2609.03395#bib.bib1)serializes the complete table and reasons step by step over it\. RoT\([Zhang et al\., 2025](https://arxiv.org/html/2609.03395#bib.bib21)\)performs row\-wise reasoning before producing the final answer\. These baselines represent two fixed scope strategies: always localizing or always retaining the full table\.

##### Evaluation Metrics\.

ForWikiTQandSLQA, we report answer exact\-match accuracy using the official WikiTableQuestions evaluator\([Pasupat and Liang, 2015](https://arxiv.org/html/2609.03395#bib.bib5)\)\. ForWTQ\-SubTab, we independently compare the predicted rows, columns, and cells with their silver references\. We report exact match, which requires the predicted set to match the reference set completely, and F1 score, which measures partial overlap between the two sets\.

MethodF1Exact MatchCellRowColumnCellRowColumnTableRAG\([Chen et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib20)\)26\.5644\.1552\.303\.2013\.9216\.98TabSQLify\([Nahid and Rafiei, 2024](https://arxiv.org/html/2609.03395#bib.bib12)\)40\.8756\.2275\.679\.2326\.9539\.69Chain\-of\-Table\([Wang et al\., 2024](https://arxiv.org/html/2609.03395#bib.bib10)\)52\.9176\.8667\.1725\.3956\.2238\.20DATER\([Ye et al\., 2023](https://arxiv.org/html/2609.03395#bib.bib3)\)68\.0078\.4685\.9336\.6361\.5059\.34TabScope\(decomposition\-only\)70\.7082\.7886\.9541\.0370\.7460\.54Table 3:Sub\-table decomposition quality onWTQ\-SubTab\. We report F1 and exact match \(%\) at the cell, row, and column levels\. Methods are ordered from lower to higher average performance across the six metrics\. The best and second\-best results are shown in bold and underlined, respectively\.Question TypeWikiTQΔ\\DeltaSLQAΔ\\DeltaPreferred ScopeLookup\+1\.17\+1\.39LocalizedOrder/Superlative\+1\.01\+0\.53LocalizedLocal Reasoning\+3\.33–LocalizedCount\-Diff\+2\.13–LocalizedCount\-General\-2\.40\-2\.34Full tableCount\-Frequency\-2\.68\+2\.22Size\-dependentCompare\-1\.24–Full tableTable 4:Type\-wise localization gain in percentage points\.Δ\\Deltais computed as localized reasoning minus full\-table reasoning\. Positive values favor localization, while negative values favor full\-table reasoning\.WikiTQis dominated by small and medium tables, whereasSLQAcontains only large tables exceeding4,0964\{,\}096tokens\. “–” indicates insufficient examples\. Definitions of the question types and the complete type\-wise results are provided in Appendix[B](https://arxiv.org/html/2609.03395#A2)\.

### 4\.2Main Results

Table[2](https://arxiv.org/html/2609.03395#S4.T2)comparesTabScopewith fixed full\-table and decomposition\-based methods onWikiTQandSLQA, using GPT\-5\-mini and LLaMA\-3\.3\-70B as answer models\.

##### RQ1: Operation\-aware decomposition\.

The decomposition\-only variant consistently outperforms existing decomposition\-based methods\. OnWikiTQ, it improves over the strongest baseline by6\.16\.1and4\.54\.5points with GPT\-5\-mini and LLaMA\-3\.3\-70B, respectively\. The gains increase to9\.29\.2and4\.74\.7points onSLQA\. The larger improvement onSLQAsuggests that operation\-aware decomposition becomes particularly useful as tables grow longer and contain more irrelevant rows and columns\.

To determine whether these gains arise from better sub\-table selection, we directly evaluate decomposition quality onWTQ\-SubTab\. Predicted rows, columns, and cells are compared with the silver references inWTQ\-SubTabusing F1 and exact match\. F1 measures partial agreement with the reference, whereas exact match requires the complete predicted set to be correct\.

As shown in Table[3](https://arxiv.org/html/2609.03395#S4.T3),TabScopeachieves the best result across all six metrics\. Compared with DATER, the strongest baseline, it improves cell, row, and column F1 by2\.702\.70,4\.324\.32, and1\.021\.02points, respectively\. Under the stricter exact\-match criterion, the corresponding gains are4\.404\.40,9\.249\.24, and1\.201\.20points\. The largest improvement occurs in row exact match, indicating thatTabScopemore often recovers the complete set of rows required for the question rather than only a partially relevant subset\. At the same time, the improvements in cell F1 and cell exact match show that the selected rows and columns are jointly more consistent with the compact silver sub\-tables\. The QA gains in Table[2](https://arxiv.org/html/2609.03395#S4.T2)are consistent with the row\-, column\-, and cell\-level results onWTQ\-SubTab\. Together, these results show that operation\-aware decomposition produces sub\-tables that more closely match the silver references and better support answer generation\.

##### RQ2: Localization on long tables\.

As shown in Table[2](https://arxiv.org/html/2609.03395#S4.T2), the decomposition\-only variant achieves an average accuracy of67\.1%67\.1\\%onSLQA, outperforming the strongest decomposition baseline by6\.96\.9points and nearly matching full\-table CoT at67\.3%67\.3\\%\. This is notable becauseSLQAcontains only tables exceeding4,0964\{,\}096tokens\. The result shows that a large portion of the original table can be removed while retaining nearly the same overall QA accuracy, suggesting that localization can mitigate the distracting effect of long\-table context\.

However, the similar average performance of localized and full\-table reasoning hides substantial variation across question types\. Table[4](https://arxiv.org/html/2609.03395#S4.T4)shows that localization is more effective when the required rows and columns are concentrated within a small table region\. This includes entity lookup, ranking or extrema, reasoning over nearby records, and differences between two filtered counts\. In these cases, removing unrelated content makes the required relationships easier to identify\.

Full\-table reasoning remains stronger for questions requiring broader coverage, such as counting all matching rows or comparing multiple entities or groups\. Frequency counting further illustrates the interaction between question type and table size\. It favors full\-table reasoning onWikiTQbut shifts toward localization onSLQA, suggesting that preserving the complete table is useful at moderate sizes, while excessive context becomes increasingly harmful on longer tables\. Localization can therefore reduce long\-table degradation, but its effectiveness depends on both the reasoning requirement and the amount of table content\. Detailed type definitions and complete results are provided in Appendix[B](https://arxiv.org/html/2609.03395#A2)\.

##### RQ3: Question\-adaptive scope selection\.

The completeTabScopeaugments the decomposition\-only variant with scope selection, which determines whether each question should be answered from the localized sub\-table or the original full table\. As shown in Table[2](https://arxiv.org/html/2609.03395#S4.T2), this complete framework achieves the highest accuracy across both datasets and answer models\.

Compared with always applying operation\-aware decomposition, evidence scoping improves accuracy by0\.90\.9and4\.34\.3points onWikiTQwith GPT\-5\-mini and LLaMA\-3\.3\-70B, respectively\. The corresponding gains onSLQAare1\.11\.1and0\.90\.9points\. These improvements show that even a strong decomposition method should not be applied uniformly, since localization may remove rows or columns that remain useful for questions requiring broader table coverage\.

The complete framework also outperforms the strongest full\-table baseline in every setting\. OnWikiTQ, it improves accuracy by1\.21\.2points with GPT\-5\-mini and2\.42\.4points with LLaMA\-3\.3\-70B\. OnSLQA, the gains are1\.31\.3and0\.30\.3points, respectively\. Although full\-table reasoning retains all table content, it also introduces more irrelevant rows and columns for questions that depend on a restricted table region\.

These findings are consistent with the type\-wise results in Table[4](https://arxiv.org/html/2609.03395#S4.T4)\. Questions involving entity lookup, ranking, extrema, or a small group of related records often benefit from localization, whereas general counting and multi\-entity comparison typically require broader table coverage\. By using scope selection to select one of these two inputs for each question,TabScopeavoids both unnecessary table reduction and excessive irrelevant context\. This question\-adaptive choice makes the complete framework more reliable than either always\-localized or always\-full\-table reasoning\.

##### Ablation results\.

Table[5](https://arxiv.org/html/2609.03395#S4.T5)shows that all components contribute to the performance ofTabScope\. Removing evidence aggregation causes the smallest decrease, reducing accuracy by1\.31\.3points onWikiTQand0\.70\.7points onSLQA, while removing sub\-table refinement leads to slightly larger drops of1\.71\.7and1\.51\.5points\. These results suggest that aggregation mainly improves the stability of row and column selection, whereas refinement helps recover missing content from initially incomplete sub\-tables\. Removing operation\-aware retrieval has the largest effect among the decomposition components, decreasing accuracy by3\.13\.1points onWikiTQand2\.02\.0points onSLQA\. This confirms that semantic relevance alone may fail to preserve the rows and columns required for operations such as counting, comparison, ranking, and aggregation\.

Removing scope selection yields the decomposition\-only variant, which applies localization to every question\. This reduces accuracy by4\.34\.3points onWikiTQbut only0\.90\.9points onSLQA\. The larger drop onWikiTQis consistent with the type\-wise results, where some questions benefit from retaining the full table\. In contrast, the small decrease onSLQAshows that operation\-aware decomposition remains effective for most long\-table questions by removing substantial irrelevant content while preserving the information needed for answering\. Nevertheless, the complete framework still performs best, indicating that adaptive scope selection complements decomposition by retaining the full table when broader coverage is required\.

VariantWikiTQSLQATabScope81\.162\.8w/o evidence aggregation79\.8 \(−1\.3\-1\.3\)62\.1 \(−0\.7\-0\.7\)w/o sub\-table refinement79\.4 \(−1\.7\-1\.7\)61\.3 \(−1\.5\-1\.5\)w/o operation\-aware retrieval78\.0 \(−3\.1\-3\.1\)60\.8 \(−2\.0\-2\.0\)w/o scope selection76\.8 \(−4\.3\-4\.3\)61\.9 \(−0\.9\-0\.9\)Table 5:Ablation results using LLaMA\-3\.3\-70B, measured by exact\-match accuracy \(%\)\. Values in parentheses denote the decrease relative to theTabScope\.

## 5Conclusion

We presentedTabScope, a framework that treats table scope as a question\-dependent decision rather than a fixed preprocessing choice\. By combining question\-adaptive scope selection with operation\-aware decomposition,TabScopecan reduce distracting table content when localization is helpful while preserving the full\-table when broader coverage is required\. Experiments onWikiTQandSLQAshow that this design improves answer accuracy across both moderate\- and large\-scale tables, while the results onWTQ\-SubTabconfirm that the decomposed tables more closely match the rows, columns, and cells needed for answering\. These findings suggest that effective TableQA depends not only on how a table is processed, but also on deciding how much of the table should be retained for each question\.

## 6Limitations

Our evaluation focuses on English TableQA benchmarks and two representative LLMs\. AlthoughWikiTQandSLQAcover different table scales, evaluation across additional domains, languages, and model families would provide a broader assessment of generalization\. The current scope\-selection policy is based on a predefined question\-type taxonomy, and future work could explore more flexible routing strategies\.

## References

- N\. Abhyankar, V\. Gupta, D\. Roth, and C\. K\. ReddyH\-STAR: LLM\-driven hybrid SQL\-text adaptive reasoning on tables\.InNAACL,pp\. 8841–8863\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px1.p1.1)\.
- Chenet al\.\(2024\)S\. Chen, L\. Miculicich, J\. M\. Eisenschlos, Z\. Wang, Z\. Wang, Y\. Chen, Y\. Fujii, H\. Lin, C\. Lee, and T\. PfisterTableRAG: million\-token table understanding with language models\.InNeurIPS,pp\. 74899–74921\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p2.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.3.2),[Table 3](https://arxiv.org/html/2609.03395#S4.T3.2.3.1)\.
- Chenet al\.\(2020\)W\. Chen, H\. Wang, J\. Chen, Y\. Zhang, H\. Wang, S\. Li, X\. Zhou, and W\. Y\. WangTabFact: A large\-scale dataset for table\-based fact verification\.InICLR,Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p4.1),[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px3.p1.1)\.
- Chen \(2023\)W\. ChenLarge language models are few\(1\)\-shot table reasoners\.InEACL,pp\. 1090–1100\.Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p1.1)\.
- Chenget al\.\(2022\)Z\. Cheng, H\. Dong, Z\. Wang, R\. Jia, J\. Guo, Y\. Gao, S\. Han, J\. Lou, and D\. ZhangHiTab: A hierarchical table dataset for question answering and natural language generation\.InACL,pp\. 1094–1110\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px3.p1.1)\.
- Dubeyet al\.\(2024\)A\. Dubey, A\. Jauhri, A\. Pandey, A\. Kadian, A\. Al\-Dahle, A\. Letman, A\. Mathur, A\. Schelten, A\. Yang, A\. Fan,et al\.The Llama 3 herd of models\.CoRRabs/2407\.21783\.Cited by:[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px1.p1.1)\.
- Liuet al\.\(2024\)N\. F\. Liu, K\. Lin, J\. Hewitt, A\. Paranjape, M\. Bevilacqua, F\. Petroni, and P\. LiangLost in the Middle: how language models use long contexts\.Transactions of the Association for Computational Linguistics12,pp\. 157–173\.Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p1.1)\.
- Nahid and Rafiei \(2024\)M\. M\. H\. Nahid and D\. RafieiTabSQLify: enhancing reasoning capabilities of llms through table decomposition\.InNAACL,pp\. 5725–5737\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px2.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p2.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.4.1),[Table 3](https://arxiv.org/html/2609.03395#S4.T3.2.4.1)\.
- Nguyenet al\.\(2025\)G\. Nguyen, I\. Brugere, S\. Sharma, S\. Kariyappa, A\. T\. Nguyen, and F\. LécuéInterpretable llm\-based table question answering\.Trans\. Mach\. Learn\. Res\.2025\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px2.p1.1)\.
- OpenAI \(2024\)OpenAIGPT\-4o mini\.Note:[https://platform\.openai\.com/docs/models/\#gpt\-4o\-mini](https://platform.openai.com/docs/models/#gpt-4o-mini)Cited by:[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px4.p1.1)\.
- OpenAI \(2026\)OpenAIOpenAI GPT\-5 system card\.CoRRabs/2601\.03267\.External Links:2601\.03267Cited by:[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px1.p1.1)\.
- Panet al\.\(2022\)F\. Pan, M\. Canim, M\. R\. Glass, A\. Gliozzo, and J\. A\. HendlerEnd\-to\-end table question answering via retrieval\-augmented generation\.CoRRabs/2203\.16714\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px1.p1.1)\.
- Pasupat and Liang \(2015\)P\. Pasupat and P\. LiangCompositional semantic parsing on semi\-structured tables\.InACL/IJCNLP,pp\. 1470–1480\.Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p4.1),[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px3.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px3.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px7.p1.1)\.
- Wanget al\.\(2024\)Z\. Wang, H\. Zhang, C\. Li, J\. M\. Eisenschlos, V\. Perot, Z\. Wang, L\. Miculicich, Y\. Fujii, J\. Shang, C\. Lee,et al\.Chain\-of\-Table: evolving tables in the reasoning chain for table understanding\.InICLR,Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px2.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p2.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.7.1),[Table 3](https://arxiv.org/html/2609.03395#S4.T3.2.5.1)\.
- Weiet al\.\(2022\)J\. Wei, X\. Wang, D\. Schuurmans, M\. Bosma, F\. Xia, E\. Chi, Q\. V\. Le, and D\. ZhouChain\-of\-thought prompting elicits reasoning in large language models\.InNeurIPS,pp\. 24824–24837\.Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p3.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.10.1)\.
- Wuet al\.\(2025\)X\. Wu, J\. Yang, L\. Chai, G\. Zhang, J\. Liu, X\. Du, D\. Liang, D\. Shu, X\. Cheng, T\. Sun, T\. Li, Z\. Li, and G\. NiuTableBench: A comprehensive and complex benchmark for table question answering\.InAAAI,pp\. 25497–25506\.Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p4.1),[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px3.p1.1)\.
- Yeet al\.\(2023\)Y\. Ye, B\. Hui, M\. Yang, B\. Li, F\. Huang, and Y\. LiLarge language models are versatile decomposers: decompose evidence and questions for table\-based reasoning\.InSIGIR,pp\. 174–184\.Cited by:[§1](https://arxiv.org/html/2609.03395#S1.p1.1),[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p2.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.6.1),[Table 3](https://arxiv.org/html/2609.03395#S4.T3.2.6.1)\.
- Yuet al\.\(2025\)P\. Yu, G\. Chen, and J\. WangTable\-Critic: A multi\-agent framework for collaborative criticism and refinement in table reasoning\.InACL,pp\. 17432–17451\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px2.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p2.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.5.1)\.
- Yuet al\.\(2018\)T\. Yu, R\. Zhang, K\. Yang, M\. Yasunaga, D\. Wang, Z\. Li, J\. Ma, I\. Li, Q\. Yao, S\. Roman, Z\. Zhang, and D\. R\. RadevSpider: A large\-scale human\-labeled dataset for complex and cross\-domain semantic parsing and text\-to\-sql task\.InEMNLP,pp\. 3911–3921\.Cited by:[§E\.1](https://arxiv.org/html/2609.03395#A5.SS1.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px4.p1.1)\.
- Zhanget al\.\(2025\)X\. Zhang, D\. Wang, K\. Xu, Q\. Zhu, and W\. CheRoT: enhancing table reasoning with iterative row\-wise traversals\.InEMNLP,pp\. 559–579\.Cited by:[§4\.1](https://arxiv.org/html/2609.03395#S4.SS1.SSS0.Px6.p3.1),[Table 2](https://arxiv.org/html/2609.03395#S4.T2.2.9.2)\.
- Zhanget al\.\(2024\)Y\. Zhang, J\. Henkel, A\. Floratou, J\. Cahoon, S\. Deep, and J\. M\. PatelReAcTable: enhancing react for table question answering\.Proc\. VLDB Endow\.17\(8\),pp\. 1981–1994\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px2.p1.1)\.
- Zouet al\.\(2025\)J\. Zou, D\. Fu, S\. Chen, X\. He, Z\. Li, Y\. Zhu, J\. Han, and J\. HeGTR: graph\-table\-rag for cross\-table question answering\.CoRRabs/2504\.01346\.Cited by:[§2](https://arxiv.org/html/2609.03395#S2.SS0.SSS0.Px1.p1.1)\.

## Appendix AAppendix

## Appendix BQuestion Type\-wise Scope Selection Analysis

We derive the scope\-selection policy through an offline analysis on the validation set ofWikiTQ\. Table[6](https://arxiv.org/html/2609.03395#A2.T6)summarizes the question types definitions\.

Question TypeDefinitionLookupRetrieve an attribute of a specified entity or record\.Order/SuperlativeIdentify an item through ranking, maximum, minimum, or relative order\.Local ReasoningReason over a small, restricted region of the table, such as related or neighboring records\.Count\-DiffCount two filtered subsets and compare or compute the difference between them\.Count\-GeneralCount all records that satisfy one or more conditions\.Count\-FrequencyDetermine how often a particular value or category occurs\.CompareCompare values associated with multiple entities or groups\.Table 6:Definitions of the question types\.Table[7](https://arxiv.org/html/2609.03395#A2.T7)compares localized reasoning with full\-table CoT for each question type\. TheDiff\.column is computed as localized reasoning minus full\-table CoT, so a positive value indicates an advantage for localization\. Localized reasoning performs better for lookup, order/superlative, local reasoning, and count\-difference questions, whose evidence is typically concentrated within a restricted table region\. Full\-table reasoning is stronger for general counting, frequency counting, and comparison questions, which often require evidence distributed across a broader portion of the table\.

We further examine whether these preferences change with table size\. Table[8](https://arxiv.org/html/2609.03395#A2.T8)reports the same comparison on the large\-table validation subset\. Only question types with sufficient examples are reported\. The overall pattern remains stable, except for frequency counting, where localized reasoning becomes more effective on large tables\.

Based on these results, we define the scope\-selection policy in Table[9](https://arxiv.org/html/2609.03395#A2.T9)\. The default policy follows the overall validation\-set preference for each question type\. For large tables, we adopt the large\-table preference when sufficient validation examples are available\. Otherwise, we retain the default choice\.

Question TypeLocalizedFull\-table CoTDiff\.Lookup86\.51%85\.34%\+1\.17Order/Superlative85\.01%84\.00%\+1\.01Local Reasoning69\.90%66\.67%\+3\.33Count\-Diff76\.60%74\.47%\+2\.13Count\-General79\.78%82\.18%\-2\.40Count\-Frequency82\.14%84\.82%\-2\.68Compare67\.90%69\.14%\-1\.24Table 7:Type\-wise accuracy comparison between localized reasoning and full\-table CoT on the validation set ofWikiTQ\.Diff\.denotes localized reasoning minus full\-table CoT\. The better result for each type is highlighted in bold\.Question TypeLocalizedFull\-table CoTDiff\.Lookup70\.68%69\.29%\+1\.39Order/Superlative77\.66%77\.13%\+0\.53Count\-General76\.83%79\.17%\-2\.34Count\-Frequency84\.44%82\.22%\+2\.22Table 8:Type\-wise accuracy comparison on the large\-table validation subset ofSLQA\. Question types with insufficient examples are omitted\.Diff\.denotes localized reasoning minus full\-table CoT\.Question TypeDefault ScopeLarge\-table ScopeLookupLocalizedLocalizedOrder/SuperlativeLocalizedLocalizedLocal ReasoningLocalizedLocalizedCount\-DiffLocalizedLocalizedCount\-GeneralFull tableFull tableCount\-FrequencyFull tableLocalizedCompareFull tableFull tableTable 9:Scope\-selection policy derived from Tables[7](https://arxiv.org/html/2609.03395#A2.T7)and[8](https://arxiv.org/html/2609.03395#A2.T8)\. When the large\-table subset does not contain sufficient examples for a question type, the default validation\-set preference is retained\.
## Appendix CPrompt Templates

This appendix presents the prompt templates used byTabScope\. We omit benchmark\-specific demonstrations and implementation metadata for clarity, while retaining the instructions, input fields, and output constraints used in our experiments\.

### C\.1Operation\-Aware Retrieval

We use separate prompts for row and column retrieval\. Both prompts instruct the model to identify the operation required by the question and retrieve sufficient evidence for performing and verifying that operation\.

#### C\.1\.1Column Retrieval

Instruction:

Selectthecolumnsneededtoanswerthequestionusingthe

f\_col\(\)function\.

Returnexactlyonefunctioncall:

f\_col\(\[column\_1,column\_2,…\]\)

Requirements:

\-Copycolumnnamesexactlyfromthetableschema\.

\-Firstidentifythetableoperationrequiredbythequestion,

suchaslookup,filtering,comparison,ranking,neighborhood

retrieval,counting,oraggregation\.

\-Retainthecolumnsneededtoperformandverifytheoperation,

ratherthanselectingcolumnsonlybylexicaloverlap\.

\-Preserveidentifier,condition,comparison,ordering,counting,

andanswer\-bearingcolumnswheneverneeded\.

\-Donotoutputexplanations,code,orSQL\.

Table:

\{LINEARIZED\_TABLE\}

Optionalcaption:

\{TABLE\_CAPTION\}

Question:

\{QUESTION\}

Output:

#### C\.1\.2Row Retrieval

Instruction:

Selecttherowsneededtoanswerthequestionusingthe

f\_row\(\)function\.

Returnexactlyonefunctioncall:

f\_row\(\[row1,row3,…\]\)

Ifallrowsarerequired,return:

f\_row\(\[\*\]\)

Requirements:

\-Usetherownumbersshownintheinputtable\.

\-Firstidentifythetableoperationrequiredbythequestion,

suchaslookup,filtering,comparison,ranking,neighborhood

retrieval,counting,oraggregation\.

\-Retrieveenoughrowstoperformandverifytheoperation,

ratherthanselectingonlyalikelyanswerrow\.

\-Preservecomparisonsets,anchorrows,neighboringrows,and

aggregationinputswheneverneeded\.

\-Donotoutputexplanations,code,orSQL\.

Table:

\{LINEARIZED\_TABLE\}

Optionalcaption:

\{TABLE\_CAPTION\}

Question:

\{QUESTION\}

Output:

### C\.2Sub\-table Refinement

TabScopeperforms one refinement round to check whether the selected sub\-table contains sufficient information for answering the question\. The verifier may retain the current selection or add missing rows and columns\. The refined evidence is returned as a structured specification and used to construct the final sub\-table\.

Youarerefininganevidencesub\-tablefortablequestion

answering\.

Giventhequestion,thecurrentsub\-table,andtheavailable

informationfromtheoriginaltable,determinewhetherthe

sub\-tablecontainssufficientevidencetoanswerthequestion\.

ReturnonlyvalidJSON:

\{

"action":"keep"\|"expand",

"final\_rows":\[row\_id,…\],

"final\_columns":\["column\_name",…\],

"reason":"briefexplanation"

\}

Keepthecurrentrowsandcolumnswhenthesub\-tableis

sufficient\.Otherwise,addthemissingrows,columns,orboth\.

UseonlyrowIDsandcolumnnamesprovidedinthetablecontext\.

Donotgeneratenewtablevaluesoruseexternalknowledge\.

Question:

\{QUESTION\}

Currentsub\-table:

\{CURRENT\_SUBTABLE\_WITH\_ROW\_IDS\}

Originaltablecontext:

\{TABLE\_CONTEXT\}

### C\.3Answer Generation

After scope selection, each question follows only the selected reasoning path\. The placeholder\{TABLE\}is instantiated with the refined sub\-table when localized reasoning is selected, and with the original table otherwise\.

Youareaprecisetablequestionansweringassistant\.

Followtherequiredoutputformatexactly\.

Readthefollowingtableandanswerthequestionusingonlythe

informationprovidedinthetable\.

Table:

\{TABLE\}

Question:

\{QUESTION\}

Reasonstepbystepandreturnexactlytwosections:

<think\>

Yourreasoning

</think\>

<answer\>

Yourfinalanswer

</answer\>

Donotincludeanytextoutsidethesetwosections\.

### C\.4LLM\-Based Question\-Type Selection Prompt

The scope selector does not directly ask the LLM to choose between localized and full\-table reasoning\. Instead, the LLM assigns the input question to one predefined question type\. The fixed policy described in Appendix[B](https://arxiv.org/html/2609.03395#A2)then maps the predicted type and table\-size regime to the final reasoning scope\.

Classifythetablequestionaccordingtothereasoningrequired

toanswerit\.

Chooseexactlyonequestiontype:

\-"lookup":retrieveavalueassociatedwithaspecifiedentity

orrecord\.

\-"order\_superlative":identifyanitemthroughranking,

maximum,minimum,orrelativeorder\.

\-"local\_reasoning":reasonoverasmallsetofrelatedor

neighboringrecords\.

\-"count\_diff":counttwofilteredgroupsandcompareorcompute

thedifferencebetweenthem\.

\-"count\_general":countallrecordssatisfyingoneormore

conditions\.

\-"count\_frequency":determinehowoftenavalueorcategory

occurs\.

\-"compare":comparevaluesassociatedwithmultipleentities

orgroups\.

Selectthetypeaccordingtotheoperationandtablecoverage

requiredbythequestion\.Donotdirectlypredictwhetherthe

systemshouldusealocalizedsub\-tableorthefulltable\.

Question:

\{QUESTION\}

Tablecolumns:

\{TABLE\_COLUMNS\}

Tablesize:

\{NUMBER\_OF\_ROWS\}rows,\{NUMBER\_OF\_COLUMNS\}columns,

\{NUMBER\_OF\_TOKENS\}serializedtokens

Tablepreview:

\{TABLE\_PREVIEW\}

ReturnonlyvalidJSON:

\{

"question\_type":"lookup"\|"order\_superlative"\|

"local\_reasoning"\|"count\_diff"\|

"count\_general"\|"count\_frequency"\|"compare"

\}

## Appendix DDetailed Experimental Settings

##### Base LLMs and serving\.

For open\-source models, we use a local inference backend based onswift\.llmwith HuggingFace model weights\. For GPT\-5\-mini, we use the OpenAI Chat Completions API\. QA decoding uses a maximum generation budget of 2048 new tokens and model default input budget\. Retrieval sampling uses a temperature of0\.50\.5, while all other components use temperature00\.

## Appendix EDataset Construction Details

### E\.1Construction ofSLQA

##### Source tables\.

We constructSLQAfrom existing large tables in Spider\([Yu et al\., 2018](https://arxiv.org/html/2609.03395#bib.bib18)\)\. Specifically, we retain tables whose serialized representations exceed4,0964\{,\}096tokens under our preprocessing\. We do not reuse the original Spider questions because they are designed for NL\-to\-SQL evaluation and closely follow executable logical forms\. Instead, we generate new questions intended for direct question answering over serialized tables\.

##### Self\-adaptive QA generation\.

Our preliminary study found that assigning a predetermined answer to the model and asking it to generate a corresponding question often produced unnatural or ambiguous question–answer pairs\. The acceptance rate of this procedure was below50%50\\%in our manual evaluation\. We therefore use a self\-adaptive generation procedure\. Rather than forcing a predetermined answer, we provide an evidence scope and allow the model to first identify an answer supported by that evidence and then generate the corresponding question\. We use four evidence scopes: a single cell, a selected row, a selected column, and a selected sub\-table\. These scopes encourage questions requiring different amounts and configurations of table evidence\.

##### Reasoning coverage\.

We retain both SQL\-executable and non\-SQL\-executable questions\. SQL\-executable questions cover structured operations such as filtering, comparison, counting, and aggregation\. Non\-SQL\-executable questions support more flexible reasoning over semi\-structured table content and prevent the benchmark from being limited to rigid SQL logical forms\.

##### Quality control\.

Every generated pair is manually reviewed for answerability, table grounding, and answer correctness\. Valid pairs are accepted directly\. Questions with minor language or ambiguity issues are revised, and incorrect answers are corrected when the intended question remains valid\. Pairs that cannot be reliably repaired are discarded\. More than70%70\\%of the generated pairs are accepted without modification, while fewer than30%30\\%require manual correction\.

#### E\.1\.1QA\-Pair Generation Prompts

We use four prompt variants corresponding to the four evidence scopes\. For cell\-based generation, the model selects an answer cell directly\. For the other variants, the selected row, column, or sub\-table defines the evidence from which the question and answer are generated\.

Usethegiventableastheonlysourceofevidence\.

Tableheader:

\{TABLE\_HEADER\}

Tablecontent:

\{TABLE\_CONTENT\}

Randomlyselectonecellfromthetableastheanswerand

generateaquestionwhoseansweristhatcell\.

Generate10diversequestion–answerpairs\.

Returnonepairperlineusingexactlythefollowingformat:

Q:question;A:answer

Keepeachanswerconciseandreturnonlytheanswervalue\.

Donotprovideexplanationsoranytextoutsidethe

question–answerpairs\.

Usethegiventableastheonlysourceofevidence\.

Tableheader:

\{TABLE\_HEADER\}

Tablecontent:

\{TABLE\_CONTENT\}

Selectedrow:

\{SELECTED\_ROW\}

Generate4diversequestion–answerpairsusinginformation

supportedbytheselectedrow\.Foreachpair,firstidentify

avalidanswerandthenformulateaquestionwhoseanswercan

bederivedfromthetable\.

Returnonepairperlineusingexactlythefollowingformat:

Q:question;A:answer

Thequestionsmustbeunderstandablewithoutreferringto

"theselectedrow"or"thegivendata\."Keepeachanswer

conciseandreturnonlytheanswervalue\.Donotprovide

explanations\.

Usethegiventableastheonlysourceofevidence\.

Tableheader:

\{TABLE\_HEADER\}

Tablecontent:

\{TABLE\_CONTENT\}

Selectedcolumn:

\{SELECTED\_COLUMN\}

Generate4diversequestion–answerpairsusinginformation

supportedbytheselectedcolumn\.Foreachpair,firstidentify

avalidanswerandthenformulateaquestionwhoseanswercan

bederivedfromthetable\.

Returnonepairperlineusingexactlythefollowingformat:

Q:question;A:answer

Thequestionsmustbeunderstandablewithoutreferringto

"theselectedcolumn"or"thegivendata\."Keepeachanswer

conciseandreturnonlytheanswervalue\.Donotprovide

explanations\.

Usethegiventableastheonlysourceofevidence\.

Tableheader:

\{TABLE\_HEADER\}

Tablecontent:

\{TABLE\_CONTENT\}

Selectedsub\-table:

\{SELECTED\_SUBTABLE\}

Generate4diversequestion–answerpairsusinginformation

supportedbytheselectedsub\-table\.Foreachpair,first

identifyavalidanswerandthenformulateaquestionwhose

answercanbederivedfromthetable\.

Returnonepairperlineusingexactlythefollowingformat:

Q:question;A:answer

Thequestionsmustbeunderstandablewithoutreferringto

"theselectedsub\-table"or"thegivendata\."Keepeachanswer

conciseandreturnonlytheanswervalue\.Donotprovide

explanations\.

### E\.2Selection of the Silver Construction Strategy

We randomly sample150150WikiTableQuestions QA pairs and manually annotate the gold rows and columns required for each question\. We then compare three silver sub\-table construction strategies against these human annotations\.

Schema\-based construction first generates question\-related schema elements and values and then retrieves the corresponding rows and columns from the original table\. Direct generation predicts the target sub\-table directly from the question, reference answer, and original table\. Direct generation with refinement further uses a verifier to identify and repair missing, invalid, or redundant selections\.

Construction MethodCell F1Cell P\.Cell R\.Cell EMRow F1Col\. F1Schema\-based60\.3366\.8771\.7127\.3374\.3480\.06Direct Generation71\.5880\.5975\.2542\.6780\.3884\.55Direct Generation \+ Refinement74\.6785\.5877\.4844\.6782\.9090\.15Table 10:Comparison of silver sub\-table construction strategies on200200randomly sampled WikiTableQuestions QA pairs with manually annotated gold sub\-tables\. Results are reported as percentages\. The best and second\-best results are shown in bold and underlined, respectively\.Table[10](https://arxiv.org/html/2609.03395#A5.T10)shows that direct generation substantially improves over schema\-based construction\. Verifier\-guided refinement further increases all six metrics, raising cell F1 from71\.58%71\.58\\%to74\.67%74\.67\\%and column F1 from84\.55%84\.55\\%to90\.15%90\.15\\%\. We therefore use direct generation with refinement to constructWTQ\-SubTab\.

### E\.3Construction ofWTQ\-SubTab

Most TableQA datasets provide only question–table–answer triples and do not annotate the rows and columns needed to support each answer\. We constructWTQ\-SubTabto enable direct evaluation of intermediate sub\-table decomposition\.

##### Direct evidence construction\.

For eachWikiTQinstance\(q,T,a\)\(q,T,a\), an LLM predicts a structured evidence specificationE=\(τ,p,R∗,C∗\)E=\(\\tau,p,R^\{\*\},C^\{\*\}\)\. Here,τ\\taudenotes the inferred reasoning type,ppspecifies the required evidence scope, andR∗R^\{\*\}andC∗C^\{\*\}denote the selected rows and columns\. The reasoning types cover lookup, filtering, comparison, superlative and ordinal selection, neighborhood reasoning, counting, aggregation, and Boolean reasoning\.

The evidence policy specifies whether the reference should contain only the answer\-bearing evidence, the full comparison domain, all instances contributing to an aggregation, or the required neighboring context\. The silver sub\-table is then extracted from the original table asT∗=T⁡\[R∗,C∗\]T^\{\*\}=T\[R^\{\*\},C^\{\*\}\]\. The model outputs row identifiers and column names rather than regenerating table contents, ensuring that all selected evidence is grounded in the original table\.

##### Verifier\-guided repair\.

The initial evidence specification may contain invalid indices, omit necessary evidence, or retain unnecessary table content\. A verifier therefore checks whether the selected rows and columns are valid, sufficient, and compact\. It also examines whether the selected evidence matches the inferred reasoning type and evidence policy\.

When an issue is detected, the verifier feedback is passed to a repair prompt\. The repair step may add missing rows or columns, remove redundant evidence, or revise the reasoning type and evidence policy\. Only verified constructions are retained as silver references\.

##### Evaluation usage\.

WTQ\-SubTabis used to evaluate row selection, column selection, and cell\-level evidence coverage\. The reference answers and silver sub\-tables are used only during offline construction and evaluation\. They are not provided toTabScopeduring inference\.

#### E\.3\.1Silver Sub\-Table Construction Prompts

We construct silver reference sub\-tables using direct evidence selection followed by verifier\-guided repair\. Because this procedure is used only for offline evaluation\-set construction, the prompts may access the reference answers\. Implementation\-specific fields and engineering details are omitted for clarity\.

Giventhequestion,referenceanswer,andfulltable,selectthe

smallestsub\-tablecontainingsufficientevidencetoansweror

verifythequestion\.

ReturnonlyvalidJSON:

\{

"reasoning\_type":"lookup"\|"filter"\|"comparison"\|

"superlative"\|"ordinal"\|"neighbor"\|"count"\|

"aggregation"\|"boolean"\|"other",

"evidence\_policy":"answer\_only"\|"comparison\_domain"\|

"all\_relevant"\|"neighbor\_context",

"rows":\[row\_id,…\],

"columns":\["column\_name",…\],

"reason":"briefexplanation"

\}

UseonlyvalidrowIDsandexactcolumnnamesfromthetable\.

Retainallevidencerequiredbythereasoningoperationwhile

avoidingunnecessaryrowsandcolumns\.

Question:

\{QUESTION\}

Referenceanswer:

\{GOLD\_ANSWERS\}

Fulltable:

\{TABLE\_MARKDOWN\}

ReturnonlytheJSONobject\.

Thepreviouslyselectedsub\-tablewasfoundtocontainmissing,

invalid,orunnecessaryevidence\.

Usingtheverifierfeedback,returnthesmallestcorrected

sub\-tablethatissufficienttoanswerorverifythequestion\.

ReturnonlyvalidJSON:

\{

"reasoning\_type":"lookup"\|"filter"\|"comparison"\|

"superlative"\|"ordinal"\|"neighbor"\|"count"\|

"aggregation"\|"boolean"\|"other",

"evidence\_policy":"answer\_only"\|"comparison\_domain"\|

"all\_relevant"\|"neighbor\_context",

"rows":\[row\_id,…\],

"columns":\["column\_name",…\],

"reason":"briefexplanation"

\}

UseonlyvalidrowIDsandexactcolumnnamesfromthetable\.

Addmissingevidenceandremoveunnecessaryevidencewhen

needed\.

Question:

\{QUESTION\}

Referenceanswer:

\{GOLD\_ANSWERS\}

Previousprediction:

\{PREVIOUS\_SPEC\}

Verifierfeedback:

\{VERIFIER\_FEEDBACK\}

Fulltable:

\{TABLE\_MARKDOWN\}

ReturnonlythecorrectedJSONobject\.