PaperlayerView exact revision on arXiv

Source-linked AI summary

Rethinking Table Pruning in TableQA: From Sequential Revisions to Gold Trajectory-Supervised Parallel Search

Yu Guo, Shenghao Ye, Shuangwu Chen, Zijian Wen, Tao Zhang, Qirui Bai, Dong Jin, Yunpeng Hou, Huasen He, Jian Yang, Xiaobin Tan

arXiv:2601.03851v2cs.CL

TL;DR

TableQA pruning seeks to remove irrelevant table content, but existing methods rely on critique signals that can miss answer-critical data and sequential revisions that cannot explore alternatives. TabTrim trains a pruner and verifier using gold SQL-derived pruning trajectories, then searches multiple candidate trajectories in parallel. It reports state-of-the-art performance across diverse tabular reasoning tasks, with TabTrim-8B reaching 73.5% average accuracy and outperforming the strongest baseline by 3.2%.

  • Problem

    Existing pruning methods use critique signals that may miss answer-critical data and sequential revisions that cannot backtrack to explore alternative pruning trajectories.

    Source: §1 · pp. 1–2

  • Method

    TabTrim derives gold pruning trajectories from intermediate sub-tables in gold SQL execution, trains a pruner and verifier to align stepwise pruning with them, and searches candidates in parallel.

    Source: §1 · p. 2

  • Results

    73.5% average accuracy: TabTrim-8B outperforms the strongest baseline by 3.2% and achieves state-of-the-art performance across diverse tabular reasoning tasks.

    Source: §1 · p. 2

  • Takeaways & Limitations

    TabTrim consistently outperforms strong baselines on WikiTQ, TabFact, and TableBench in table pruning and downstream table reasoning.

    Source: §5 · p. 8

    Evaluation is limited to 4B and 8B parameter regimes by computational resource constraints, leaving scaling laws and performance with stronger base models uncharacterized.

    Source: Limitations · p. 9

Abstract

from arXiv · show

Table Question Answering (TableQA) benefits significantly from table pruning, which extracts compact sub-tables by eliminating redundant cells to streamline downstream reasoning. However, existing pruning methods typically rely on sequential revisions driven by unreliable critique signals, often failing to detect the loss of answer-critical data. To address this limitation, we propose TabTrim, a novel table pruning framework which transforms table pruning from sequential revisions to gold trajectory-supervised parallel search. TabTrim derives a gold pruning trajectory using the intermediate sub-tables in the execution process of gold SQL queries, and trains a pruner and a verifier to make the step-wise pruning result align with the gold pruning trajectory. During inference, TabTrim performs parallel search to explore multiple candidate pruning trajectories and identify the optimal sub-table. Extensive experiments demonstrate that TabTrim achieves state-of-the-art performance across diverse tabular reasoning tasks: TabTrim-8B reaches 73.5% average accuracy, outperforming the strongest baseline by 3.2%, including 79.4% on WikiTQ and 61.2% on TableBench.

1 Introduction

Existing table-pruning approaches can make unreliable stepwise judgments and become trapped in a single revision path. TabTrim uses gold SQL-derived pruning trajectories for supervision and parallel search to explore alternatives.

1 Introduction

  • Existing critique signals may miss answer-critical data: program execution checks detect syntax or runtime errors, while LLM self-judgments can be inconsistent.A program can execute successfully yet remove answer-critical cells; self-reflection may rationalize erroneous reasoning or over-criticize valid steps.Source: §1 · pp. 1–2
  • Sequential revisions follow one pruning trajectory, leaving them unable to backtrack and explore alternatives and making suboptimal results more likely.The paper identifies unreliable critique and single-trajectory revision as fundamental limitations of existing pruning.Source: §1 · p. 2
  • Gold SQL execution intermediates provide a reliable pruning trajectory, while parallel candidate search expands exploration and can avoid local optima.The trajectory is grounded in verified query results and can critique each pruning step.Source: §1 · p. 2
  • TabTrim derives gold pruning trajectories from intermediate sub-tables in gold SQL execution and trains a pruner and verifier to align stepwise pruning with them.At inference, parallel search explores multiple candidate trajectories to identify an optimal sub-table.Source: §1 · p. 2
  • 73.5% average accuracy: TabTrim-8B outperforms the strongest baseline by 3.2% across diverse tabular reasoning tasks.The reported results also include 79.4% on WikiTQ and 61.2% on TableBench.Source: §1 · p. 2

2 TabTrim

TabTrim replaces sequential pruning revisions with gold-trajectory-supervised pruning and parallel search. It derives training trajectories from gold SQL execution and combines a trajectory-supervised pruner with a loss-aware verifier.

2.1 Trajectory Construction

  • TabTrim executes decomposed gold SQL operations to create stepwise sub-table trajectories, plus off-trajectory negatives by modifying gold operations.The operations focus on answer-critical row filtering and column projection; trajectory construction uses existing single-table Text-to-SQL data without additional manual annotation.Source: §2.1 · p. 3

2.2 Gold Trajectory-supervised Pruner

  • The pruner first learns from progression and correction samples, then uses direct preference optimization to favor the gold next sub-table over alternatives.The supervised objective trains it to follow the gold trajectory and recover from erroneous pruning; the preference stage addresses subtle semantic errors.Source: §2.2 · p. 3

2.3 Loss-aware Verifier

  • The verifier scores each sub-table against the final gold-trajectory table using an α-weighted F-score that penalizes loss of answer-critical data.Recall represents preserved answer-critical data, precision reflects retained redundancy, and α > 1 emphasizes recall.Source: §2.3 · p. 4

2.4 Parallel Trajectory Search

  • Parallel search generates candidate sub-tables from multiple retained trajectories, scores them with the verifier, and expands top-ranked candidates toward a final output.The implementation uses beam search: each retained sub-table proposes b candidates after initialization, and the highest-scoring explored sub-table is returned for downstream reasoning.Source: §2.4 · p. 4

3 Experiments

TabTrim-8B leads the reported benchmarks overall, and analyses examine its behavior across question difficulty, training and verification choices, search budgets, downstream reasoners, and token use. Ablations and scaling comparisons report gains from trajectory supervision, loss-aware scoring, and parallel search.

3.1 Experimental Setup

  • Training uses over 80K WikiSQL and SQUALL samples; evaluation covers WikiTQ, TabFact, and TableBench with exact-match or binary accuracy.TabTrim-4B and TabTrim-8B use Qwen3 pruners and a Qwen3-0.6B verifier; default search settings are k=b=2 and Dmax=4.Source: §3.1 · pp. 4–5

3.2 Main Results

  • 73.5% average accuracy lets TabTrim-8B outperform Table-Critic (70.3%) by 3.2% across WikiTQ, TabFact, and TableBench.TabTrim-8B also reaches 79.4% on WikiTQ and 91.2% on TabFact; TableBench gains over the strongest baseline are 5.8% on TB-NR, 2.0% on TB-FC, and 0.9% on TB-DA.Source: Table 1 · p. 5, §3.2 · pp. 5–6

3.3 Fine-grained Analysis on Hardness

  • TabTrim-8B exceeds Table-Critic and TALON at every WikiTQ hardness level, with the most pronounced gains on Extra Hard questions.Hardness levels are assigned by GPT-4o's empirical success rate across 100 sampled answers per question.Source: Figure 3 · p. 6, §3.3 · p. 6

3.4 Ablation Study

  • Without pruner training, accuracy drops 24.7% on WikiTQ and 11.6% on TableBench; removing DPO or correction samples also degrades performance.The authors report that correction samples support robustness to off-trajectory sub-tables and that process-supervised trajectories are essential for effective pruning.Source: §3.4 · p. 6, Table 2 · p. 6
  • Balanced α=1 scoring loses 1.6% on WikiTQ and 2.9% on TableBench compared with loss-aware α=1.5 scoring.The balanced variant reduces emphasis on retaining answer-critical data.Source: Table 3 · p. 6, §3.4 · p. 7
  • Verifier-likelihood ranking loses 5.2%/4.5%, while disabling search loses 6.5%/6.1% on WikiTQ/TableBench, respectively.The ablations compare verifier-based ranking with pruner-likelihood ranking and parallel search with sequential revisions under a matched call budget.Source: §3.4 · p. 7, Table 4 · p. 7

3.5 Analysis of Scaling

  • Accuracy rises monotonically with greater maximum depth or beam width on both datasets; TabTrim also beats matched-budget Best-of-N at every depth.The Best-of-N baseline uses the same pruner and verifier, with N=k·b independent rollouts.Source: Figure 4 · p. 7, §3.5 · p. 7, Figure 5 · p. 7

3.6 Analysis of Plug-and-Play Gains

  • TabTrim-selected sub-tables consistently boost accuracy for both evaluated open-source downstream reasoners across WikiTQ and TableBench, indicating they reduce distracting noise while preserving answer-critical data.Source: Table 5 · p. 8, §3.6 · p. 8

4 Related Work

Prior table reasoning work includes table-aware models and LLM-based approaches that serialize tables or decompose queries. Table pruning and critique methods seek to manage distracting content and pruning errors, but critique signals can be unreliable in sequential revision workflows.

4 Related Work

  • Table reasoning moved from table-aware task models toward serializing tables for LLM reasoning and query decomposition, though irrelevant content can distract.The passage cites task-specific pretraining and fine-tuning, open-text reasoning, and decomposition strategies.Source: §4 · p. 8
  • Pruning filters noise through executable SQL or Python programs or iterative LLM reasoning, but early pruning errors can propagate into reasoning failure.The cited methods include program-based filtering and iterative reasoning approaches.Source: §4 · p. 8
  • Critique methods use execution feedback or LLM judges for revision, but sequential workflows may miss errors that discard answer-critical data.TabTrim instead trains a pruner and verifier from step-wise sub-table trajectory supervision and maintains competing trajectories through parallel search.Source: §4 · p. 8

5 Conclusion

TabTrim combines step-wise pruning supervision with parallel search to reduce answer-critical data loss and simplify sub-tables for downstream reasoning. Experiments on WikiTQ, TabFact, and TableBench show consistent outperformance of strong baselines.

Conclusion

  • TabTrim performs parallel search over competing pruning trajectories while a pruner generates sub-tables and a verifier scores them.The system discards low-quality branches during search.Source: §5 · p. 8
  • Step-wise supervision from sub-table trajectories trains the pruner to reduce answer-critical data loss during table pruning.The framework pairs the pruner with a verifier that scores intermediate sub-tables.Source: §5 · p. 8
  • Experiments on WikiTQ, TabFact, and TableBench show that TabTrim consistently outperforms strong baselines in downstream table reasoning.Source: §5 · p. 8

Limitations

The evaluation is limited to 4B and 8B parameter regimes because of computational resource constraints. TabTrim's scaling laws and performance ceiling with stronger base models remain uncharacterized.

Limitations

  • Computational constraints confine the evaluation to the 4B and 8B parameter regimes.Source: Limitations · p. 9
  • The scaling laws and performance ceiling of TabTrim with stronger base models remain uncharacterized because larger-model fine-tuning requires substantial computation.Source: Limitations · p. 9

Ethics Statement

TabTrim aims to improve the reliability of multi-step table pruning, but its LLM-based system may still produce incorrect answers or incomplete sub-tables. The authors advise verifying critical outputs and state that they follow the licenses and usage policies of the open-source resources used.

Ethics Statement

  • As an LLM-based system, TabTrim still risks generating factually incorrect answers or incomplete sub-tables.Source: Ethics Statement · p. 9
  • The authors advise users to exercise caution and verify critical outputs in real-world deployments.Source: Ethics Statement · p. 9
  • The research uses open-source models and frameworks, including Qwen3, PyTorch, and Hugging Face, under their respective licenses and usage policies.Source: Ethics Statement · p. 9

A Additional Implementation Details

The appendix derives pruning trajectories from ordered SQL operations, constructs executable negative examples by modifying those operations, and represents sub-tables as subsets of canonicalized cells.

A.1 SQL Decomposition

  • Gold SQL is parsed into an abstract syntax tree and linearized into clause-level operations in logical execution order.Trajectory operations focus on WHERE-based row selection and column projection for attributes affecting the answer.Source: §A.1 · p. 11

A.2 SQL Modification

  • Negative examples come from executable, non-trivial modifications to row-selection predicates and column-pruning decisions.Predicate variants alter values, operators, or conjunctions; column variants drop answer-relevant attributes or retain irrelevant ones.Source: §A.2 · p. 12
  • Table 7 reports a sensitivity analysis of the correction weight λ in the pruner training objective.Source: Table 7 · p. 12

A.3 Cell-index Canonicalization

  • Sub-table states are represented as subsets of the canonicalized cell set, with cells indexed by row and column.Source: §A.3 · p. 12

B.1 Experiment Setup

Experiments used eight NVIDIA A100 40GB GPUs, trained models for two epochs, and report TabTrim accuracy averaged over three runs. The setup specifies optimization and inference settings for the pruner and verifier.

B.1 Experiment Setup

  • TabTrim experiments ran on 8 NVIDIA A100 40GB GPUs, trained all models for 2 epochs, and averaged accuracy over 3 runs.Across datasets, the reported standard deviation was within 1% absolute accuracy.Source: §B.1 · pp. 12–13
  • The pruner used full-parameter fine-tuning with a 2 × 10−5 peak learning rate, followed by DPO at 2 × 10−6 with β = 0.2.The correction weight was λ = 1.Source: §B.1 · p. 13
  • The Qwen3-0.6B verifier used a 5 × 10−5 peak learning rate; inference used top-p 0.95, temperature 0.6, and a 4,096-token generation limit.The setup used AdamW, a cosine learning-rate schedule, and 3% warmup.Source: §B.1 · p. 13

B.2 Dataset Details

The evaluation spans WikiTQ, TabFact, and TableBench, while sensitivity analyses examine correction weight and verifier recall bias. Both analyses report improved performance with recovery-oriented settings, with limited gains from further tuning beyond moderate values.

B.2 Dataset Details

  • WikiTQ contains 22,033 questions over 2,108 Wikipedia tables; TabFact contains 118,275 statements grounded in 16,573 Wikipedia tables.WikiTQ training and test tables are disjoint; TabFact asks whether statements are entailed or refuted by table evidence.Source: §B.2 · p. 13
  • TableBench has 886 samples across four task categories and 18 subcategories, with questions requiring an average of 6.3 reasoning steps.The training corpus excludes tables overlapping with test benchmarks.Source: §B.2 · p. 13

C.1 Sensitivity to Correction Weight

  • Increasing correction weight λ from 0.3 to 1.0 generally improves EM on WikiTQ and TableBench, with marginal gains beyond approximately 0.8.The analysis holds training data, base model, optimization setup, and inference budget fixed; it interprets the trend as evidence that recovery learning helps mitigate off-trajectory errors.Source: §C.1 · p. 14

C.2 Sensitivity to Recall-bias Parameter

  • A recall-biased verifier setting (α > 1) consistently improves EM over α = 1 on WikiTQ and TableBench, peaking around α ∈[1.5, 1.7].Performance remains competitive for nearby values, suggesting moderate rather than precise tuning is needed.Source: §C.2 · p. 14

C.3 Error Analysis

Error analysis finds that most failures occur during downstream reasoning rather than selection of answer-critical table data. The appendices also describe deployment considerations, pruning evaluation, training examples, answerer prompting, and related work.

C.3 Error Analysis

  • On 100 failed TabTrim-8B examples, answer-critical selection errors account for 7%, while numerical computation and aggregation/counting account for 42% and 38%.The authors identify arithmetic and aggregation robustness in the answerer as the primary direction for further gains.Source: §C.3 · p. 14

C.4 Deployment-oriented Cost Analysis

  • Shared query-and-table prompt prefixes can be computed once and reused across parallel-search branches in self-hosted settings.The authors also note that a more compact sub-table representation could reduce decoding overhead without changing the algorithm.Source: §C.4 · p. 14

C.5 Table Pruning Effectiveness

  • The pruning evaluation randomly samples 200 correctly answered WikiTQ and TabFact instances and measures token counts before and after pruning.Table 10 reports average token counts and compression rates, but the supplied passages do not give their values.Source: §C.5 · p. 14

D.1 Example of training data for Pruner

D.2 Example of training data for Verifier

D.3 Prompt of Answerer

E Additional Related Work

  • The related-work discussion places table reasoning and text-to-SQL among structured reasoning tasks requiring schema, content, and compositional-procedure understanding.It also situates LLM reasoning across areas including vision-language modeling, chart understanding, mathematics, and web agents.Source: E Additional Related Work · pp. 14–15
Loading 2601.03851v2…