Paper deep dive
TabScope: Question-Adaptive Scope Selection for Table Question Answering
Yuxiang Wang, Junhao Gan, Jianzhong Qi
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 9/4/2026, 3:05:31 AM
Summary
The paper introduces TabScope, a question-adaptive framework for Table Question Answering (TableQA) that dynamically selects between localized (sub-table) and full-table reasoning based on question type. It addresses performance degradation in Large Language Models (LLMs) on large tables by using an operation-aware decomposer to construct question-specific sub-tables when beneficial. The authors also introduce SLQA, a benchmark for long-table QA, and silver reference sub-tables (WTQ-SUBTAB) for evaluating evidence selection quality.
Entities (10)
Relation Signals (9)
TabScope → evaluatedon → WikiTQ
confidence 95% · Experiments on WikiTQ and SLQA show that localization is particularly effective...
TabScope → evaluatedon → SLQA
confidence 95% · Experiments on WikiTQ and SLQA show that localization is particularly effective...
SLQA → isbenchmarkfor → long-table question answering
confidence 95% · construct SLQA, a benchmark based on real-world long tables.
TabScope → uses → operation-aware table decomposition
confidence 95% · The framework constructs question-specific sub-tables through operation-aware table decomposition...
WTQ-SUBTAB → derivedfrom → WikiTQ
confidence 90% · WTQ-SUBTAB, a silver-reference evaluation set derived from WikiTQ.
TabScope → outperforms → Full-table CoT
confidence 90% · adaptive selection between localized and full-table reasoning achieves the best overall performance.
TabScope → usesbasemodel → Llama-3.3-70B
confidence 90% · We use two base LLMs from different families: LLaMA-3.3-70B...
TabScope → usesbasemodel → GPT-5-mini
confidence 90% · We use two base LLMs from different families: ... GPT-5-mini (OpenAI, 2026).
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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 construct SLQA, a benchmark based on real-world long tables. Experiments on WikiTQ and SLQA show 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.
Tags
Links
- Source: https://arxiv.org/abs/2609.03395v1
- Canonical: https://arxiv.org/abs/2609.03395v1
Trouble viewing inline? Open PDF directly →
Full Text
58,892 characters extracted from source content.
Expand or collapse full text
TabScope: Question-Adaptive Scope Selection for Table Question Answering Yuxiang Wang, Junhao Gan, Jianzhong Qi The University of Melbourne yuxiang.wang8@student.unimelb.edu.au junhao.gan, jianzhong.qi@unimelb.edu.au Abstract Large Language Models (LLMs) have shown strong performance on table question answer- ing, yet their accuracy often degrades as ta- ble size increases. We find that this degra- dation is not uniform across question types. Localization-sensitive questions are particu- larly 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 frame- work constructs question-specific sub-tables through operation-aware table decomposition and uses the predicted question type to de- termine the appropriate reasoning mode. We further introduce silver reference sub-tables for evaluating evidence selection and construct SLQA, 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 perfor- mance. These results highlight that long-table QA requires deciding not only how to local- ize, but also when to localize. Our code and datasets will be made available upon publica- tion of the paper. 1 Introduction Large Language Models (LLMs) have demon- strated strong reasoning capabilities for table ques- tion answering (TableQA), particularly when com- bined with chain-of-thought (CoT) prompting (Wei et al., 2022; Chen, 2023). However, their perfor- mance remains sensitive to table size. As tables grow longer, LLMs struggle to identify the small set of rows and columns needed to support the an- swer from noisy inputs, leading to lower answer accuracy (Ye et al., 2023; Liu et al., 2024). Our analysis shows that this degradation varies across question types. Localization is particularly Small / Medium Tables Large Tables 0 20 40 60 80 Full-table QA accuracy 80.3 67.3 Performance drops (a) Longer tables are harder Find one specific value Find the best item Count across many rows Localization improves accuracy Full table performs better Localize Localize Keep full table (b) The best scope depends on the question 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) Localiza- tion helps questions requiring compact regions, whereas questions involving many rows or entities favor full- table reasoning. Small/medium and large tables corre- spond to WikiTQ and SLQA, respectively. effective when the answer depends on a small, re- stricted table region. In contrast, questions requir- ing broad comparison sets, complete aggregation domains, or information distributed across many rows may benefit from retaining the full table. De- composition may otherwise remove necessary con- text or introduce retrieval errors. Figure 1 sum- marizes 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? We regard TableQA as a question-adaptive rea- soning problem rather than a fixed decomposition arXiv:2609.03395v1 [cs.CL] 3 Sep 2026 pipeline, especially for long tables. We propose TABSCOPE, which first determines whether a ques- tion is better served by the full table or a com- pact sub-table. When localization is expected to be beneficial, TABSCOPE uses 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 addi- tional limitations for studying evidence localization. First, datasets such as WikiTableQuestions (Pasu- pat and Liang, 2015) 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 selec- tion. Second, most existing benchmarks (Pasupat and Liang, 2015; Chen et al., 2020; Wu et al., 2025) 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 gener- ating validated question–answer pairs from real-world tables and use it to buildSLQA, a benchmark for long-table question answering. 2 Related Work Recent LLM-based TableQA methods increasingly address the difficulty of reasoning over large ta- bles by reducing, retrieving, or transforming rel- evant rows and columns before answer genera- tion. 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 anno- tations, 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 rele- vant evidence before reasoning. DATER (Ye et al., 2023) uses LLMs to decompose both table and questions, selecting relevant rows and columns for downstream reasoning. H-STAR (Abhyankar et al., 2025) similarly extracts relevant table regions within a hybrid symbolic–textual framework. Oth- ers use retrieval-augmented methods for table rea- soning. TableRAG (Chen et al., 2024) retrieves rel- evant schema and cell information for large-scale table understanding, T-RAG (Pan et al., 2022) com- bines dense table retrieval with generation for open- domain TableQA, and GTR (Zou et al., 2025) per- forms 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 selec- tion operation-aware and treats localization as a question-dependent decision. Program-guided table decomposition.Another direction obtains intermediate tables through ex- plicit operations or executable programs. Chain-of- Table (Wang et al., 2024) iteratively transforms the table during reasoning and treats intermediate ta- bles as evolving reasoning states. Table-Critic (Yu et al., 2025) iteratively critiques and refines the intermediate table before answer generation. Re- AcTable (Zhang et al., 2024) combines LLM rea- soning with tools such as SQL and Python ex- ecutors to manipulate tabular data step by step. TabSQLify (Nahid and Rafiei, 2024) constructs question-relevant sub-tables through SQL queries, while Plan-of-SQLs (Nguyen et al., 2025) executes a sequence of SQL steps to provide interpretable intermediate reasoning traces. In contrast, TAB- SCOPE does not require a full operation chain or executable program, and applies decomposition only when localized reasoning is helpful. Evidence supervision and long-table evaluation. Most TableQA benchmarks, such as WikiTable- Questions, provide tables, questions, and final an- swers, but no explicit annotations of the supporting rows and columns (Pasupat and Liang, 2015). This limits direct evaluation of intermediate sub-tables. In addition, many commonly used benchmarks con- tain relatively small tables, typically under 4K table tokens, making them less suited for evaluating long- Table YearRegionProductSalesCostProfit 2021 North America Product A8,1005,0003,100 2021EuropeProduct A6,2003,8002,400 2022 North America Product A9,0005,4003,600 2022EuropeProduct A6,7004,1002,600 2023 North America Product A11,2004,8256,375 2023 North America Product B8,4004,9003,500 .................. 2 Question ? What is the total profit of Product A in North America in 2023? 3 Question-Type Selection Sec3.3 Predict question type Lookup Order Local Reasoning Compare 4 Scope Selection Policy Sec3.3 ⚖ Type-to-scope policy Localized reasoning (Decomposition) Full-table reasoning Localized Reasoning (Decomposition) 5 Operation-Aware Retrieval Sec3.4 Filtering Comparison Aggregation Counting Sorting Evidence Aggregation Sec3.4 YearRegionProductProfit 2023 North America Product A6,375 North America Product B3,500 ............ 9 Sub-Table Refinement Sec3.4 Is the sub-table sufficient? ✓ Yes (Sufficient) × No (Expand) 10 Refined Sub-Table Sec3.4 Full-Table Reasoning 5b Full-Table CoT Reasoning Given(Table,question) YearRegionProductSalesCostProfit 2021 North America Product A8,1005,0003,100 2021EuropeProduct A6,2003,8002,400 2022 North America Product A9,0005,4003,600 2022EuropeProduct A6,7004,1002,600 2023 North America Product A11,2004,8256,375 2023 North America Product B8,4004,9003,500 .................. +Question 11 Answer Generation Sec3.5 烙 Answer: 6,375 1 3 ... 4 ... 5 6 2023 ............ 78 YearRegionProductProfit 2023 North America Product A6,375 9 Figure 2: Overview of TABSCOPE. 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. table reasoning (Chen et al., 2020; Wu et al., 2025; Cheng et al., 2022). We address these gaps by con- structing silver reference sub-tables for evaluating decomposition quality and by introducingSLQA, a benchmark built from real-world long tables. 3 Methodology 3.1 Problem Formulation Given a tableT, a questionq, and a reference an- swera, the goal of TableQA is to predict an an- swerˆathat matchesa. We represent the table as T = (H,R), whereH = h 1 ,...,h m denotes the column headers andR = r 1 ,...,r n denotes the table rows. For each question, a model can ei- ther reason over the full tableTor reduce it to a question-specific sub-tableT ′ . We define the sub-table asT ′ = T [R ′ ,C ′ ], whereR ′ ⊆ Rand C ′ ⊆ Hare the selected rows and columns. Our goal is not to always minimize the table, but to se- lect the appropriate table scope for each question. 3.2 Overview of TABSCOPE We propose TABSCOPE, a question-adaptive frame- work that selects the appropriate table scope be- fore answer generation. As illustrated in Figure 2, TABSCOPE consists 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. (i) When localization is selected, an operation-aware decomposer retrieves the required rows and columns and refines them into a question-specific sub-table. (i) The answer model generates the answer from the selected input, either the refined sub-table or the original full table. 3.3 Question-Adaptive Scope Selection TABSCOPE is designed to determine whether lo- calization should be applied to each question. The scope selector consists of an LLM-based question- type classifierC θ and a fixed type-to-scope policy π. Given a questionqand tableT, the classifier predicts a predefined question typeˆτ. The policy then selects the reasoning mode according to the predicted type and table-size regime: ˆτ = C θ (q,T ), z = π ˆτ,s(T ) , z ∈local, full. (1) Here,s(T )denotes the table-size regime. Ifz = local, TABSCOPE constructs a question-specific sub-table before answer generation. Otherwise, it bypasses decomposition and reasons directly over the original table. We deriveπthrough 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 addition- ally account for table size when the preferred mode changes on large tables. At inference time, the LLM predicts onlyˆτ, while the fixed policy deter- mines the final scope. The classification prompt is provided in Appendix B.4, and the type-wise anal- ysis used to define π is reported in Appendix A. 3.4 Operation-Aware Table Decomposition When the scope selector chooses localized reason- ing, TABSCOPE constructs 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 ques- tion and table content. The decomposer has three steps: operation-aware retrieval, evidence aggre- gation, and sub-table refinement. All the prompts used are shown in Appendix B. Operation-aware retrieval. The decomposer first identifies the operation required by the ques- tion, such as lookup, filtering, comparison, or counting. This operation determines both the rows and columns to retrieve. For example, for the ques- tion “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 evi- dence 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 re- trieval more robust, we sampleKretrieval outputs for the same question, where K = 4 by default. We aggregate row retrievals and column re- trievals separately. Each retrieval output is treated as a candidatec, which contains either a selected row set or a selected column set. Each candidate is assigned a reliability scores(c). When generation confidence is available for the LLM,s(c)is com- puted from the average token log probability of the candidate. Otherwise, we sets(c) = 0, reducing w(g)to frequency-based voting. Candidates that select the same normalized row set or column set are merged into a candidate group g. For each group, we compute a support weight: w(g) = X c∈g exp(s(c)).(2) Here,w(g)measures how strongly the retrieval samples support groupg. The termexp(s(c))con- verts 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 ′ and candidate column setsC ′ , removing duplicate candidates. We then enumerate the resulting row–column combina- tions and score each candidate sub-tableT [R ′ ,C ′ ] using the support and compactness criteria defined below. For a candidate row set R ′ , we compute: RowScore(R ′ ) = P g∈G r ;g⊆R ′ w(g) P g∈G r w(g) .(3) Here,G r is the set of distinct row groups,g is one retrieved row set, andw(g)is its weight. Thus,RowScore(R ′ )is the proportion of total row- group weight covered byR ′ . The column score ColScore(C ′ )is computed in the same way over the column groups. We combine the two scores as: Support(R ′ ,C ′ ) = p RowScore(R ′ )· ColScore(C ′ ). (4) The support score is high only when the candi- date 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| . (5) Here,ρ(R ′ ,C ′ )is the proportion of table cells retained by the candidate, and coefficientα ∈ [0.1, 0.3]controls the penalty on large sub-tables. We select the row–column combination with the highestS(R ′ ,C ′ )as the final decomposed table T ′ = T [R ′ ,C ′ ]. Dataset Table Statistics# QA Pairs Cols. Rows TokensTrain Valid.Test WikiTQ6.425.4662.6 11,321 2,831 4,344 SLQA11.0 733.8 9,786.21,324239 1,110 WTQ-SUBTAB1.86.5104.8– 4,344 Table 1: Statistics of the evaluation resources, aver- aged over questions.WikiTQmainly contains small and medium tables, whereas allSLQAtables exceed4,096 serialized tokens. WTQ-SUBTAB contains silver sub- tables for the 4,344 WikiTQ test questions. AdditionalInfoCostDetailsItem 'Weight': '1.2kg', 'Battery': '12 hrs' 1200DellXPS13Laptop 'Camera': '48MP', 'Chipset': 'A17 Bionic' 999iPhone15Smartphone ............ 'Brand': 'Amazon', 'Assistant': 'Alexa' 99Amazon Echo Smart Speaker 'Provider': 'Google Drive', 'Storage': '1TB' 10CloudStorageSubscription ... ...... ... Table Title: ItemInformation Q:What is the name of the smartphone mentioned in the table? A:iPhone15 Q:Which brand produces the Smart Speaker and what voice assistant does it use? A:Amazon,Alexa Q:What is thepriceofthefirstitem? A:1200 Q:WhichischeaperLaptopor Smartphone? A:Smartphone Figure 3: Generated QA pair examples. Sub-table refinement. After evidence aggrega- tion, TABSCOPE performs one refinement round by default to verify whether the sub-tableT ′ is suf- ficient for answering the questionq. Givenq, the full tableT, andT ′ , the verifier determines whether additional rows, columns, or both are needed. If necessary, the missing evidence is added toT ′ , which is then passed to the answer model M . 3.5 Answer Generation After scope selection, each question follows a sin- gle reasoning path. The QA modelManswers from the(q,T ′ )pair when localized reasoning is selected, and from (q,T ) pair otherwise. 4 Experiments We evaluate TABSCOPE to answer three questions. RQ1: How effectively does operation-aware de- composition identify compact and sufficient evi- dence? RQ2: Can localization mitigate perfor- mance degradation on long tables? RQ3: Can question-adaptive scope selection outperform fixed full-table or localized reasoning? 4.1 Experimental Setup Base Models. We use two base LLMs from dif- ferent families: LLaMA-3.3-70B (Dubey et al., 2024), and GPT-5-mini (OpenAI, 2026). They cover both open-source and closed-source settings, as well as large and relatively smaller LLMs. De- tailed settings are provided in Appendix C. Benchmarks and Evaluation Resources. We evaluate TABSCOPE on three benchmarks. Table 1 shows the statistics for these benchmarks. WikiTableQuestions (WikiTQ).WikiTableQues- tions (Pasupat and Liang, 2015) is a widely used TableQA benchmark with diverse question types and tables spanning a broad range of sizes, includ- ing tables which sizes exceed4,096tokens. We useWikiTQfor standard TableQA evaluation, table- size analysis, and type-wise scope analysis. SLQA.Existing TableQA benchmarks contain rel- atively few long tables (token size exceeds4,096to- kens), making it difficult to systematically evaluate long-table reasoning. We therefore constructSLQA, a dedicated long-table TableQA benchmark. We ex- tract tables from Spider (Yu et al., 2018) whose ta- ble sizes exceed4,096tokens, but replace the orig- inal NL-to-SQL questions with newly generated TableQA questions. We use GPT-4o mini (Ope- nAI, 2024) 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 for- mulates the corresponding question. All generated pairs are manually reviewed with fewer than30% requiring correction. The generation prompts and detailed analysis are provided in Appendix D.1. Figure 3 shows examples of generated QA pairs. WTQ-SUBTAB. Final-answer accuracy alone does not reveal whether a decomposition method re- trieves the correct intermediate rows and columns. We therefore construct WTQ-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 using 200randomly sampledWikiTQQA pairs with man- ually 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 gen- eration instead asks the LLM to predict the target sub-table directly. The third strategy applies a veri- fier 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 there- fore used to construct WTQ-SUBTAB. Detailed results are reported in Appendix D.2. CategoryMethod WikiTQ SLQA GPTLLaMA Avg. GPTLLaMA Avg. Decomposition TableRAG (Chen et al., 2024)69.556.863.247.449.748.6 TabSQLify (Nahid and Rafiei, 2024)73.572.372.959.334.046.7 Table-Critic (Yu et al., 2025)–70.1–52.3– DATER (Ye et al., 2023)76.370.573.456.054.255.1 Chain-of-Table (Wang et al., 2024)75.871.873.863.157.260.2 TABSCOPE (decomposition-only)82.476.879.672.361.967.1 Full-table RoT (Zhang et al., 2025)81.778.780.270.354.162.2 CoT (Wei et al., 2022)82.178.580.372.162.567.3 AdaptiveTABSCOPE83.381.182.273.462.868.1 Table 2: Exact-match accuracy (%) onWikiTQandSLQA. The decomposition-only variant applies operation-aware decomposition to every question, whereas the TABSCOPE adaptively selects between localized and full-table reasoning. GPT and LLaMA denote 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. Given an instance(q,T,a), an LLM selects the minimal supporting rows and columns. A veri- fier then detects invalid, incomplete, or unneces- sarily large selections and requests a repair when needed. The resulting reference sub-table is defined asT ∗ = T [R ∗ ,C ∗ ], whereR ∗ andC ∗ denote the verified rows and columns. WTQ-SUBTAB is used only to evaluate decom- position quality through row-, column-, and cell- level matching. Its silver annotations are not avail- able to TABSCOPE during inference. Construction prompts are provided in Appendix D.3.1. Baselines. We compare TABSCOPE with two groups of baselines. Decomposition-based methods reduce or trans- form the table before answering. DATER (Ye et al., 2023) decomposes questions and tables to select relevant rows and columns. Chain-of-Table (Wang et al., 2024) iteratively applies table operations and uses the final transformed table for answer gener- ation. TabSQLify (Nahid and Rafiei, 2024) gen- erates SQL queries to construct question-relevant sub-tables. TableRAG (Chen et al., 2024) retrieves relevant schema and cells for large-table reasoning, while Table-Critic (Yu et al., 2025) iteratively cri- tiques and refines a candidate sub-table before an- swer 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 methods retain the orig- inal table during answer generation. Full-table CoT (Wei et al., 2022) serializes the complete table and reasons step by step over it. RoT (Zhang et al., 2025) performs row-wise reasoning before produc- ing 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 of- ficial WikiTableQuestions evaluator (Pasupat and Liang, 2015). For WTQ-SUBTAB, we indepen- dently 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. 4.2 Main Results Table 2 compares TABSCOPE with fixed full-table and decomposition-based methods onWikiTQand SLQA, using GPT-5-mini and LLaMA-3.3-70B as answer models. RQ1: Operation-aware decomposition. The decomposition-only variant consistently outper- forms existing decomposition-based methods. On WikiTQ, it improves over the strongest baseline by 6.1and4.5points with GPT-5-mini and LLaMA- 3.3-70B, respectively. The gains increase to9.2 and4.7points onSLQA. The larger improvement on SLQAsuggests 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 de- Method F1Exact Match CellRowColumnCellRowColumn TableRAG (Chen et al., 2024)26.5644.1552.303.2013.9216.98 TabSQLify (Nahid and Rafiei, 2024)40.8756.2275.679.2326.9539.69 Chain-of-Table (Wang et al., 2024)52.9176.8667.1725.3956.2238.20 DATER (Ye et al., 2023)68.0078.4685.9336.6361.5059.34 TABSCOPE (decomposition-only)70.7082.7886.9541.0370.7460.54 Table 3: Sub-table decomposition quality on WTQ-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 Type WikiTQ ∆ SLQA ∆ Preferred Scope Lookup+1.17+1.39Localized Order/Superlative+1.01+0.53Localized Local Reasoning+3.33–Localized Count-Diff+2.13–Localized Count-General-2.40-2.34Full table Count-Frequency-2.68+2.22Size-dependent Compare-1.24–Full table Table 4: Type-wise localization gain in percentage points.∆is computed as localized reasoning minus full-table reasoning. Positive values favor localization, while negative values favor full-table reasoning.WikiTQ is dominated by small and medium tables, whereasSLQA contains only large tables exceeding4,096tokens. “–” indicates insufficient examples. Definitions of the ques- tion types and the complete type-wise results are pro- vided in Appendix A. composition quality on WTQ-SUBTAB. Predicted rows, columns, and cells are compared with the silver references in WTQ-SUBTAB using 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, TABSCOPE achieves the best result across all six metrics. Compared with DATER, the strongest baseline, it improves cell, row, and column F1 by2.70,4.32, and1.02points, respectively. Under the stricter exact-match crite- rion, the corresponding gains are4.40,9.24, and 1.20points. The largest improvement occurs in row exact match, indicating that TABSCOPE more 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 com- pact silver sub-tables. The QA gains in Table 2 are consistent with the row-, column-, and cell-level results on WTQ-SUBTAB. Together, these results show that operation-aware decomposition produces sub-tables that more closely match the silver refer- ences and better support answer generation. RQ2: Localization on long tables.As shown in Table 2, the decomposition-only variant achieves an average accuracy of67.1%onSLQA, outperforming the strongest decomposition baseline by6.9points and nearly matching full-table CoT at67.3%. This is notable becauseSLQAcontains only tables ex- ceeding4,096tokens. The result shows that a large portion of the original table can be removed while retaining nearly the same overall QA accuracy, sug- gesting that localization can mitigate the distracting effect of long-table context. However, the similar average performance of lo- calized and full-table reasoning hides substantial variation across question types. Table 4 shows that localization is more effective when the required rows and columns are concentrated within a small table region. This includes entity lookup, rank- ing or extrema, reasoning over nearby records, and differences between two filtered counts. In these cases, removing unrelated content makes the re- quired relationships easier to identify. Full-table reasoning remains stronger for ques- tions 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 pre- serving the complete table is useful at moderate sizes, while excessive context becomes increas- ingly harmful on longer tables. Localization can therefore reduce long-table degradation, but its ef- fectiveness depends on both the reasoning require- ment and the amount of table content. Detailed type definitions and complete results are provided in Appendix A. RQ3: Question-adaptive scope selection. The complete TABSCOPE augments 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, 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.9and4.3points onWikiTQwith GPT-5-mini and LLaMA-3.3-70B, respectively. The corresponding gains onSLQAare1.1and0.9 points. 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. On WikiTQ, it improves accuracy by1.2points with GPT-5-mini and2.4points with LLaMA-3.3-70B. OnSLQA, the gains are1.3and0.3points, respec- tively. 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. Questions involving en- tity lookup, ranking, extrema, or a small group of related records often benefit from localization, whereas general counting and multi-entity compar- ison typically require broader table coverage. By using scope selection to select one of these two inputs for each question, TABSCOPE avoids both unnecessary table reduction and excessive irrele- vant context. This question-adaptive choice makes the complete framework more reliable than either always-localized or always-full-table reasoning. Ablation results. Table 5 shows that all compo- nents contribute to the performance of TABSCOPE. Removing evidence aggregation causes the small- est decrease, reducing accuracy by1.3points on WikiTQand0.7points onSLQA, while removing sub-table refinement leads to slightly larger drops of1.7and1.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 Variant WikiTQ SLQA TABSCOPE81.162.8 w/o evidence aggregation79.8 (−1.3)62.1 (−0.7) w/o sub-table refinement79.4 (−1.7)61.3 (−1.5) w/o operation-aware retrieval78.0 (−3.1)60.8 (−2.0) w/o scope selection76.8 (−4.3)61.9 (−0.9) Table 5: Ablation results using LLaMA-3.3-70B, mea- sured by exact-match accuracy (%). Values in parenthe- ses denote the decrease relative to the TABSCOPE. components, decreasing accuracy by3.1points on WikiTQand2.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. Removingscopeselectionyieldsthe decomposition-onlyvariant,whichapplies localization to every question.This reduces accuracy by4.3points onWikiTQbut only0.9 points 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, indi- cating that adaptive scope selection complements decomposition by retaining the full table when broader coverage is required. 5 Conclusion We presented TABSCOPE, 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, TABSCOPE can reduce dis- tracting table content when localization is help- ful while preserving the full-table when broader coverage is required. Experiments onWikiTQand SLQAshow that this design improves answer ac- curacy across both moderate- and large-scale ta- bles, while the results on WTQ-SUBTAB confirm that the decomposed tables more closely match the rows, columns, and cells needed for answer- ing. 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. 6 Limitations Our evaluation focuses on English TableQA bench- marks and two representative LLMs. Although WikiTQandSLQAcover different table scales, eval- uation across additional domains, languages, and model families would provide a broader assessment of generalization. The current scope-selection pol- icy is based on a predefined question-type taxon- omy, and future work could explore more flexible routing strategies. References Nikhil Abhyankar, Vivek Gupta, Dan Roth, and Chan- dan K. Reddy. 2025. H-STAR: LLM-driven hybrid SQL-text adaptive reasoning on tables. In NAACL, pages 8841–8863. Si-An Chen, Lesly Miculicich, Julian M Eisenschlos, Zifeng Wang, Zilong Wang, Yanfei Chen, Yasuhisa Fujii, Hsuan-Tien Lin, Chen-Yu Lee, and Tomas Pfister. 2024. TableRAG: Million-token table under- standing with language models. In NeurIPS, pages 74899–74921. Wenhu Chen. 2023. Large language models are few(1)- shot table reasoners. In EACL, pages 1090–1100. Wenhu Chen, Hongmin Wang, Jianshu Chen, Yunkai Zhang, Hong Wang, Shiyang Li, Xiyou Zhou, and William Yang Wang. 2020. TabFact: A large-scale dataset for table-based fact verification. In ICLR. Zhoujun Cheng, Haoyu Dong, Zhiruo Wang, Ran Jia, Jiaqi Guo, Yan Gao, Shi Han, Jian-Guang Lou, and Dongmei Zhang. 2022. HiTab: A hierarchical table dataset for question answering and natural language generation. In ACL, pages 1094–1110. Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. 2024. The Llama 3 herd of models. CoRR, abs/2407.21783. Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paran- jape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024. Lost in the Middle: How language mod- els use long contexts. Transactions of the Association for Computational Linguistics, 12:157–173. Md Mahadi Hasan Nahid and Davood Rafiei. 2024. Tabsqlify: Enhancing reasoning capabilities of llms through table decomposition. In NAACL, pages 5725– 5737. Giang Nguyen, Ivan Brugere, Shubham Sharma, San- jay Kariyappa, Anh Totti Nguyen, and Freddy Lécué. 2025. Interpretable llm-based table question answer- ing. Trans. Mach. Learn. Res., 2025. OpenAI. 2024. GPT-4o mini.https://platform. openai.com/docs/models/#gpt-4o-mini. OpenAI. 2026. Openai GPT-5 system card. CoRR, abs/2601.03267. Feifei Pan, Mustafa Canim, Michael R. Glass, Alfio Gliozzo, and James A. Hendler. 2022. End-to-end ta- ble question answering via retrieval-augmented gen- eration. CoRR, abs/2203.16714. Panupong Pasupat and Percy Liang. 2015. Composi- tional semantic parsing on semi-structured tables. In ACL/IJCNLP, pages 1470–1480. Zilong Wang, Hao Zhang, Chun-Liang Li, Julian Martin Eisenschlos, Vincent Perot, Zifeng Wang, Lesly Mi- culicich, Yasuhisa Fujii, Jingbo Shang, Chen-Yu Lee, et al. 2024. Chain-of-Table: Evolving tables in the reasoning chain for table understanding. In ICLR. Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. 2022. Chain-of-thought prompting elicits rea- soning in large language models. In NeurIPS, pages 24824–24837. Xianjie Wu, Jian Yang, Linzheng Chai, Ge Zhang, Jia- heng Liu, Xeron Du, Di Liang, Daixin Shu, Xianfu Cheng, Tianzhen Sun, Tongliang Li, Zhoujun Li, and Guanglin Niu. 2025. Tablebench: A comprehensive and complex benchmark for table question answering. In AAAI, pages 25497–25506. Yunhu Ye, Binyuan Hui, Min Yang, Binhua Li, Fei Huang, and Yongbin Li. 2023. Large language mod- els are versatile decomposers: Decompose evidence and questions for table-based reasoning. In SIGIR, pages 174–184. Peiying Yu, Guoxin Chen, and Jingjing Wang. 2025. Table-Critic: A multi-agent framework for collabora- tive criticism and refinement in table reasoning. In ACL, pages 17432–17451. Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, Zilin Zhang, and Dragomir R. Radev. 2018. Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task. In EMNLP, pages 3911–3921. Xuanliang Zhang, Dingzirui Wang, Keyan Xu, Qingfu Zhu, and Wanxiang Che. 2025. RoT: Enhancing table reasoning with iterative row-wise traversals. In EMNLP, pages 559–579. Yunjia Zhang, Jordan Henkel, Avrilia Floratou, Joyce Cahoon, Shaleen Deep, and Jignesh M. Patel. 2024. Reactable: Enhancing react for table question answer- ing. Proc. VLDB Endow., 17(8):1981–1994. Jiaru Zou, Dongqi Fu, Sirui Chen, Xinrui He, Zihao Li, Yada Zhu, Jiawei Han, and Jingrui He. 2025. GTR: graph-table-rag for cross-table question answering. CoRR, abs/2504.01346. Question TypeDefinition LookupRetrieve an attribute of a specified en- tity or record. Order/SuperlativeIdentify an item through ranking, max- imum, minimum, or relative order. Local Reasoning Reason over a small, restricted region of the table, such as related or neigh- boring records. Count-DiffCount two filtered subsets and com- pare or compute the difference be- tween 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 multi- ple entities or groups. Table 6: Definitions of the question types. A Appendix A Question Type-wise Scope Selection Analysis We derive the scope-selection policy through an offline analysis on the validation set ofWikiTQ. Table 6 summarizes the question types definitions. Table 7 compares localized reasoning with full- table CoT for each question type. The Diff. 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 typi- cally concentrated within a restricted table region. Full-table reasoning is stronger for general count- ing, 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 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. 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.17 Order/Superlative85.01%84.00%+1.01 Local Reasoning69.90%66.67%+3.33 Count-Diff76.60%74.47%+2.13 Count-General79.78%82.18%-2.40 Count-Frequency82.14%84.82%-2.68 Compare67.90%69.14%-1.24 Table 7: Type-wise accuracy comparison between local- ized 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.39 Order/Superlative77.66%77.13%+0.53 Count-General76.83%79.17%-2.34 Count-Frequency84.44%82.22%+2.22 Table 8: Type-wise accuracy comparison on the large- table validation subset ofSLQA. Question types with insufficient examples are omitted. Diff. denotes local- ized reasoning minus full-table CoT. B Prompt Templates This appendix presents the prompt templates used by TABSCOPE.We omit benchmark-specific demonstrations and implementation metadata for clarity, while retaining the instructions, input fields, and output constraints used in our experiments. B.1 Operation-Aware Retrieval We use separate prompts for row and column re- trieval. Both prompts instruct the model to identify the operation required by the question and retrieve sufficient evidence for performing and verifying that operation. B.1.1 Column Retrieval Column Retrieval Prompt Instruction: Select the columns needed to answer the question using the f_col() function. Return exactly one function call: f_col([column_1, column_2, ...]) Requirements: - Copy column names exactly from the table schema. - First identify the table operation required by the question, such as lookup, filtering, comparison, ranking, neighborhood Question TypeDefault ScopeLarge-table Scope LookupLocalizedLocalized Order/SuperlativeLocalizedLocalized Local ReasoningLocalizedLocalized Count-DiffLocalizedLocalized Count-GeneralFull tableFull table Count-FrequencyFull tableLocalized CompareFull tableFull table Table 9: Scope-selection policy derived from Tables 7 and 8. When the large-table subset does not contain sufficient examples for a question type, the default validation-set preference is retained. retrieval, counting, or aggregation. - Retain the columns needed to perform and verify the operation, rather than selecting columns only by lexical overlap. - Preserve identifier, condition, comparison, ordering, counting, and answer-bearing columns whenever needed. - Do not output explanations, code, or SQL. Table: LINEARIZED_TABLE Optional caption: TABLE_CAPTION Question: QUESTION Output: B.1.2 Row Retrieval Row Retrieval Prompt Instruction: Select the rows needed to answer the question using the f_row() function. Return exactly one function call: f_row([row 1, row 3, ...]) If all rows are required, return: f_row([*]) Requirements: - Use the row numbers shown in the input table. - First identify the table operation required by the question, such as lookup, filtering, comparison, ranking, neighborhood retrieval, counting, or aggregation. - Retrieve enough rows to perform and verify the operation, rather than selecting only a likely answer row. - Preserve comparison sets, anchor rows, neighboring rows, and aggregation inputs whenever needed. - Do not output explanations, code, or SQL. Table: LINEARIZED_TABLE Optional caption: TABLE_CAPTION Question: QUESTION Output: B.2 Sub-table Refinement TABSCOPE performs one refinement round to check whether the selected sub-table contains suffi- cient information for answering the question. The verifier may retain the current selection or add miss- ing rows and columns. The refined evidence is returned as a structured specification and used to construct the final sub-table. Sub-table Refinement Prompt You are refining an evidence sub-table for table question answering. Given the question, the current sub-table, and the available information from the original table, determine whether the sub-table contains sufficient evidence to answer the question. Return only valid JSON: "action": "keep" | "expand", "final_rows": [row_id, ...], "final_columns": ["column_name", ...], "reason": "brief explanation" Keep the current rows and columns when the sub-table is sufficient. Otherwise, add the missing rows, columns, or both. Use only row IDs and column names provided in the table context. Do not generate new table values or use external knowledge. Question: QUESTION Current sub-table: CURRENT_SUBTABLE_WITH_ROW_IDS Original table context: TABLE_CONTEXT B.3 Answer Generation After scope selection, each question follows only the selected reasoning path.The placeholder TABLEis instantiated with the refined sub-table when localized reasoning is selected, and with the original table otherwise. System Prompt You are a precise table question answering assistant. Follow the required output format exactly. User Prompt Read the following table and answer the question using only the information provided in the table. Table: TABLE Question: QUESTION Reason step by step and return exactly two sections: <think> Your reasoning </think> <answer> Your final answer </answer> Do not include any text outside these two sections. B.4 LLM-Based Question-Type Selection Prompt The scope selector does not directly ask the LLM to choose between localized and full-table reason- ing. Instead, the LLM assigns the input question to one predefined question type. The fixed policy described in Appendix A then maps the predicted type and table-size regime to the final reasoning scope. Question-Type Selection Prompt Classify the table question according to the reasoning required to answer it. Choose exactly one question type: - "lookup": retrieve a value associated with a specified entity or record. - "order_superlative": identify an item through ranking, maximum, minimum, or relative order. - "local_reasoning": reason over a small set of related or neighboring records. - "count_diff": count two filtered groups and compare or compute the difference between them. - "count_general": count all records satisfying one or more conditions. - "count_frequency": determine how often a value or category occurs. - "compare": compare values associated with multiple entities or groups. Select the type according to the operation and table coverage required by the question. Do not directly predict whether the system should use a localized sub-table or the full table. Question: QUESTION Table columns: TABLE_COLUMNS Table size: NUMBER_OF_ROWS rows, NUMBER_OF_COLUMNS columns, NUMBER_OF_TOKENS serialized tokens Table preview: TABLE_PREVIEW Return only valid JSON: "question_type": "lookup" | " order_superlative" | "local_reasoning" | "count_diff" | "count_general" | "count_frequency" | " compare" C Detailed Experimental Settings Base LLMs and serving.For open-source mod- els, we use a local inference backend based on swift.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 of 0.5, while all other components use temperature0. D Dataset Construction Details D.1 Construction of SLQA Source tables. We constructSLQAfrom existing large tables in Spider (Yu et al., 2018). Specifically, we retain tables whose serialized representations exceed4,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 ques- tion 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 correspond- ing question often produced unnatural or ambigu- ous question–answer pairs. The acceptance rate of this procedure was below50%in our manual eval- uation. 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 se- lected 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 opera- tions such as filtering, comparison, counting, and aggregation. Non-SQL-executable questions sup- port more flexible reasoning over semi-structured table content and prevent the benchmark from be- ing limited to rigid SQL logical forms. Quality control. Every generated pair is manu- ally reviewed for answerability, table grounding, and answer correctness. Valid pairs are accepted directly. Questions with minor language or am- biguity issues are revised, and incorrect answers are corrected when the intended question remains valid. Pairs that cannot be reliably repaired are dis- carded. More than70%of the generated pairs are accepted without modification, while fewer than 30% require manual correction. D.1.1 QA-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. Cell-Based QA Generation Use the given table as the only source of evidence. Table header: TABLE_HEADER Table content: TABLE_CONTENT Randomly select one cell from the table as the answer and generate a question whose answer is that cell. Generate 10 diverse question--answer pairs. Return one pair per line using exactly the following format: Q: question; A: answer Keep each answer concise and return only the answer value. Do not provide explanations or any text outside the question--answer pairs. Row-Based QA Generation Use the given table as the only source of evidence. Table header: TABLE_HEADER Table content: TABLE_CONTENT Selected row: SELECTED_ROW Generate 4 diverse question--answer pairs using information supported by the selected row. For each pair, first identify a valid answer and then formulate a question whose answer can be derived from the table. Return one pair per line using exactly the following format: Q: question; A: answer The questions must be understandable without referring to "the selected row" or "the given data." Keep each answer concise and return only the answer value. Do not provide explanations. Column-Based QA Generation Use the given table as the only source of evidence. Table header: TABLE_HEADER Table content: TABLE_CONTENT Selected column: SELECTED_COLUMN Generate 4 diverse question--answer pairs using information supported by the selected column. For each pair, first identify a valid answer and then formulate a question whose answer can be derived from the table. Return one pair per line using exactly the following format: Q: question; A: answer The questions must be understandable without referring to "the selected column" or "the given data." Keep each answer concise and return only the answer value. Do not provide explanations. Sub-Table-Based QA Generation Use the given table as the only source of evidence. Table header: TABLE_HEADER Table content: TABLE_CONTENT Selected sub-table: SELECTED_SUBTABLE Generate 4 diverse question--answer pairs using information supported by the selected sub-table. For each pair, first identify a valid answer and then formulate a question whose answer can be derived from the table. Return one pair per line using exactly the following format: Q: question; A: answer The questions must be understandable without referring to "the selected sub-table" or "the given data." Keep each answer concise and return only the answer value. Do not provide explanations. D.2 Selection of the Silver Construction Strategy We randomly sample150WikiTableQuestions QA pairs and manually annotate the gold rows and columns required for each question. We then com- pare 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, ref- erence answer, and original table. Direct generation with refinement further uses a verifier to identify and repair missing, invalid, or redundant selections. Table 10 shows that direct generation substan- tially improves over schema-based construction. Verifier-guided refinement further increases all six metrics, raising cell F1 from71.58%to74.67% and column F1 from84.55%to90.15%. We there- fore use direct generation with refinement to con- struct WTQ-SUBTAB. D.3 Construction of WTQ-SUBTAB Most TableQA datasets provide only question– table–answer triples and do not annotate the rows and columns needed to support each answer. We construct WTQ-SUBTAB to enable direct evalua- tion of intermediate sub-table decomposition. Direct evidence construction.For eachWikiTQ instance(q,T,a), an LLM predicts a structured evidence specificationE = (τ,p,R ∗ ,C ∗ ). Here, τdenotes the inferred reasoning type,pspecifies the required evidence scope, andR ∗ andC ∗ de- note the selected rows and columns. The reasoning types cover lookup, filtering, comparison, superla- tive and ordinal selection, neighborhood reasoning, counting, aggregation, and Boolean reasoning. The evidence policy specifies whether the refer- ence should contain only the answer-bearing evi- dence, the full comparison domain, all instances contributing to an aggregation, or the required neighboring context. The silver sub-table is then ex- tracted from the original table asT ∗ = T [R ∗ ,C ∗ ]. The model outputs row identifiers and column names rather than regenerating table contents, en- suring that all selected evidence is grounded in the original table. Construction MethodCell F1Cell P.Cell R.Cell EMRow F1Col. F1 Schema-based60.3366.8771.7127.3374.3480.06 Direct Generation71.5880.5975.2542.6780.3884.55 Direct Generation + Refinement74.6785.5877.4844.6782.9090.15 Table 10: Comparison of silver sub-table construction strategies on200randomly 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. Verifier-guided repair.The initial evidence spec- ification may contain invalid indices, omit neces- sary evidence, or retain unnecessary table content. A verifier therefore checks whether the selected rows and columns are valid, sufficient, and com- pact. It also examines whether the selected ev- idence 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-SUBTAB is 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 to TABSCOPE during inference. D.3.1Silver Sub-Table Construction Prompts We construct silver reference sub-tables using di- rect 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. Direct Silver Sub-Table Construction Given the question, reference answer, and full table, select the smallest sub-table containing sufficient evidence to answer or verify the question. Return only valid JSON: "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": "brief explanation" Use only valid row IDs and exact column names from the table. Retain all evidence required by the reasoning operation while avoiding unnecessary rows and columns. Question: QUESTION Reference answer: GOLD_ANSWERS Full table: TABLE_MARKDOWN Return only the JSON object. Silver Sub-Table Repair The previously selected sub-table was found to contain missing, invalid, or unnecessary evidence. Using the verifier feedback, return the smallest corrected sub-table that is sufficient to answer or verify the question. Return only valid JSON: "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": "brief explanation" Use only valid row IDs and exact column names from the table. Add missing evidence and remove unnecessary evidence when needed. Question: QUESTION Reference answer: GOLD_ANSWERS Previous prediction: PREVIOUS_SPEC Verifier feedback: VERIFIER_FEEDBACK Full table: TABLE_MARKDOWN Return only the corrected JSON object.