{"id":"152b584d-b2dd-44a6-8e4c-feb538e1cd83","arxiv_id":"2412.07629","paper_version":4,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"An iterative divide-and-conquer selector that merges cell-level subtables from small windows improves table question answering over prior subtable-based selectors on WikiTQ and WikiSQL.","lead":"PieTa selects the relevant cells of a large table in small chunks, merges those chunks, and repeats until the table stops shrinking, so a question-answering model only sees the useful part. It reports higher accuracy than earlier subtable selection methods on the WikiTQ and WikiSQL benchmarks.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The iterative loop in Algorithm 1 is monotone decreasing, so any answer cell not selected in the first divide/conquer pass is gone forever; the paper measures this first-pass recall only on WikiSQL, not on WikiTQ, leaving the central QA claim with an unmeasured failure mode.","rationale":"The paper is clear and internally coherent, and the reported improvements over ITR, Dater, and TabSQLify are plausible. I read the algorithm in good faith and found a structural property that the authors do not discuss: the iterative loop is monotone decreasing, not a constructive multi-resolution merge. This makes the first-pass union the only mechanism that can add information; later passes can only remove cells. The reader's weakest assumption was that local windows always contain enough evidence, which is the right area. My concern sharpens it: because of monotonicity, even a single missed gold cell in pass 1 is irrecoverable, so the entire WikiTQ claim rests on first-pass recall there. The paper reports high first-pass recall on WikiSQL (Table 2) but no equivalent WikiTQ selection metric, even though WikiTQ is the benchmark with the larger accuracy gains. This is a load-bearing gap rather than a fatal flaw: the natural test is to measure first-pass recall on WikiTQ and compare one-pass with full-iteration QA. If the test shows near-perfect first-pass recall and no QA degradation from pruning, the published claims stand. That is why I keep the reader's CONDITIONAL verdict rather than upgrading or rejecting it. I also credit the paper for reporting subtable-selection precision/recall at all, for the clear ablation of window sizes, and for the explicit limitation that the selector is trained independently of the reader; these reduce the risk but do not close the WikiTQ first-pass gap.","tokens_in":16259,"tokens_out":13525,"duration_ms":133282,"concrete_test":"On a random sample of ~200 WikiTQ dev instances with SQL-derived gold subtables (e.g., from SQUALL), run only the first divide/conquer pass of PieTa on the original table and compute cell-level recall of the first-pass union against the gold subtable. Also compare final QA EM (after full iteration) with one-pass-only EM. If first-pass recall is near 100% and final EM does not beat one-pass EM, the concern is mitigated; if first-pass recall is materially below 100% or final EM drops when answer cells are pruned, the central claim has a real soft spot.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Algorithm 1 (lines 6-16) computes T^{t+1} as the union of selector outputs on windows of T^t. Since every output V_i is a subwindow of its input window W_i, and the windows cover T^t, T^{t+1} is always a subset of T^t. The process therefore cannot grow the table: it is monotone pruning. The final subtable is a subset of the first-pass union, and any cell omitted in the first pass cannot reappear in later iterations. This makes the first divide/conquer pass the sole source of recall for the entire pipeline. The paper's only cell-level recall evidence is Table 2 on WikiSQL (first-pass recall 99.65, final recall 99.12); no analogous subtable-selection recall is reported on WikiTQ. WikiTQ contains the harder questions (superlatives, comparisons, multi-row dependencies) and larger tables, which is precisely the regime where a local w x w window may lack the evidence needed to identify a gold cell. If a required cell is missing from the first-pass union, iteration cannot recover it, and the final reader may fail no matter how strong it is. The paper's description of multi-resolution merging 'capturing dependencies across multiple rows and columns' is not supported by the algorithm as written: the union operation only combines local selections, and every subsequent iteration only deletes cells. This is not a criticism of the reported numbers; it is a structural property of Algorithm 1 that needs direct evidence on WikiTQ.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"PieTa is a subtable-selection framework for table question answering. Given a question and a table, the method iteratively slides w×w windows over the current table, prompts a fine-tuned Llama-3.1 selector to mark relevant cells in each window (using a coordinate representation), and unions the selected cells into a new, smaller table; iteration stops when the table no longer changes. The resulting subtable is then fed to an existing reader. Training targets are derived from SQL annotations (SQUALL for WikiTQ, WikiSQL for WikiSQL) by selecting condition and answer columns within each window and retaining rows that satisfy the conditions present in that window. The paper reports subtable-selection precision/recall on WikiSQL and end-to-end exact-match accuracy on WikiTQ and WikiSQL with multiple readers, together with ablations of learning mode, output representation, and window size. The central claim is that this simple iterative union procedure outperforms prior subtable-selection and holistic baselines, with headline results of 63.65 EM for PieTa+GPT-3.5 on WikiTQ versus 59.21 for TabSQLify and 91.83 for PieTa+TaPEx on WikiSQL versus 89.31 for the holistic baseline.","tokens_in":16544,"tokens_out":6304,"duration_ms":56034,"significance":"If the claimed results hold, PieTa is a useful and unusually simple contribution to subtable-based table QA. Its strengths are the explicit algorithms, the coordinate-output representation that addresses a real weakness of index- and table-based selection, the comparison across multiple readers and baselines, and a meaningful ablation study. The reported WikiSQL selection recall (99.65% first-pass, 99.12% final in Table 2) suggests the selector is effective on that dataset, and the WikiTQ QA gains are nontrivial. The main weakness is that the algorithm's decisive structural property—its monotone pruning, whereby any cell omitted in the first divide/conquer pass is permanently lost—is not directly evaluated on WikiTQ, the harder dataset. The paper is not circular: the QA readers are fixed external models and the selection targets are derived from SQL annotations. However, the evidence gap around first-pass recall on WikiTQ is load-bearing for the claim that the method captures multi-row and multi-column dependencies.","major_comments":[{"comment":"The iterative loop is monotone decreasing: each V_i^t is a subwindow of its input window W_i, the windows cover T^t, and therefore T^{t+1} = union_i V_i^t is always a subset of T^t. As a result, any cell not selected in the first divide/conquer pass is gone forever, and the final subtable is a subset of the first-pass union. This makes first-pass recall the sole source of recall for the entire pipeline. The paper's only cell-level selection recall evidence is Table 2 on WikiSQL (first-pass recall 99.65, final recall 99.12); no analogous first-pass or final recall is reported for WikiTQ, which contains the harder questions (superlatives, comparisons, multi-row dependencies) and larger tables. The text's claim in Section 3.1 and the Conclusion that the iterative merging 'captures dependencies across multiple rows and columns' is not supported by the algorithm as written: no operation combines evidence across windows to select a cell that was not already selected locally. The authors should measure first-pass and final subtable recall on WikiTQ (for example, on a manually annotated sample or through a clearly described proxy) and provide failure analysis for cases where the required answer cell is never selected.","section":"Section 3.1, Algorithm 1 (lines 6-16)"},{"comment":"The training targets are constructed from SQL annotations by selecting condition and answer columns within each w×w window and then keeping only rows that satisfy all conditions present in that window. This assumes that for every relevant window, the condition cells and answer cells are jointly visible within the window, or that a window lacking a condition imposes no row restriction. The paper does not quantify how often this local-evidence assumption fails, particularly on WikiTQ, where a question may require comparing or ordering cells across distant rows or columns (e.g., the 'next aircraft after Cessna 404 Titan' example in Section 1). Because of the monotone pruning property of Algorithm 1, a single failure of this assumption in the first pass cannot be repaired by later iterations. The paper should estimate the frequency of such local-evidence failures on the test sets, or otherwise demonstrate that the selector can propagate information across windows.","section":"Section 3.2, data generation and target construction"}],"minor_comments":[{"comment":"The example question is phrased as 'List each of engines with diesel fuel produced from 1988-2001' in the text but as 'produced from 1998-2001' in the Figure 4 caption and in the table values; the year should be made consistent.","section":"Section 3.4 and Figure 4"},{"comment":"The enumeration of possible target window sizes as {[1,1], ..., [w,w]} omits the zero-row cases [0,1]...[0,w] that are later discussed and appear in the histogram; the text should reconcile the enumeration with the actual sample space.","section":"Appendix A.5"},{"comment":"The loop bounds in Algorithm 2 are confusing: the 'for i = 0 to R by 1' loop with an assignment 'i = R - w' inside the body suggests clamping, but as written it may re-process or skip windows; rewriting the loops as 'for i = 0 to R-w' and 'for j = 0 to C-w' would make the sliding-window behavior unambiguous.","section":"Appendix A.2, Algorithm 2"},{"comment":"The text says TabSQLify was evaluated with both Llama3.1 and GPT-3.5 and the better model was selected, but the Llama3.1 result is not reported; reporting it would make the comparison more transparent.","section":"Section 4.1, TabSQLify comparison"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is not circular and the proposed method is simple enough to be reproducible, but the missing WikiTQ selection-recall evidence speaks directly to the central claim. I would ask the authors to supply that evidence or otherwise bound the first-pass failure rate before considering acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"PieTa is a solid incremental step in subtable selection for table QA. The iterative windowing with cell-level union and the coordinate output representation are a genuinely new combination, and the empirical work is mostly careful: ablations on learning type, representation, and window size, plus comparisons against ITR, Dater, TabSQLify, and holistic readers. The QA gains are real and consistent across WikiTQ and WikiSQL and across OmniTab, GPT-3.5, and TaPEx; PieTa+GPT-3.5 at 63.65 EM on WikiTQ versus 59.21 for TabSQLify is a good headline. I think the central claim—union subtables built from local selections help readers more than prior selectors—holds up.\n\nThat said, the paper's description of 'multi-resolution ... capturing dependencies across multiple rows and columns' is stronger than the algorithm warrants. In Algorithm 1, every conquer step returns a subwindow of its input window, so T^(t+1) is a subset of T^t. The loop never adds cells; it only prunes. So the first divide-and-conquer pass is the sole source of recall. If a needed cell is missed there, iteration cannot recover it. The paper reports first-pass recall only on WikiSQL (99.65), not on WikiTQ, where questions are harder and tables larger. That is a real gap, and it should be addressed with cell-level recall on WikiTQ before acceptance. It does not invalidate the reported QA numbers; those are empirical. But it does mean the 'multi-resolution dependency capture' claim needs to be rephrased to something like 'pruning via re-windowing of candidate cells,' which is still useful.\n\nOther soft spots are milder: no code or trained models released (promised upon acceptance), no error bars or multiple runs (the authors say the algorithm has no random elements, but the LM and fine-tuning do have some stochasticity), and training targets come from SQL annotations whose condition coverage on WikiTQ is not quantified. The counterexample where TabSQLify beats PieTa with TaPEx on WikiTQ is minor.\n\nFor the reviewer: I would send this to a serious venue. The method is novel enough, the ablations are informative, and the main structural issue is fixable with additional evaluation. I would not desk-reject.","headline":"A solid, incremental subtable-selection method whose reported QA gains hold up, but whose 'multi-resolution' framing overstates a monotone pruning loop; referee it, but ask for WikiTQ cell-level recall and code.","tokens_in":17106,"tokens_out":2949,"would_cite":true,"duration_ms":26456,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"PieTa selects a union subtable through an iterative divide-and-conquer on table windows, improving table QA exact match over prior subtable selectors.","keywords":["table question answering","subtable selection","divide and conquer","language models","coordinate representation","union subtable","windows","exact match"],"falsifier":"Take a WikiTQ test question whose gold answer requires two condition columns that never appear together in any 4×4 window containing the answer cells, and check whether the final union subtable still contains the gold answer row; if a nontrivial fraction of such cross-window questions lose their answer cells, the local-window sufficiency assumption is violated. A direct numerical version would compare the oracle union of per-window gold selections to the gold subtable and show the gap in exact match on the test set.","tokens_in":16032,"feed_emoji":"🧩","tokens_out":6156,"duration_ms":49853,"temperature":0.7,"pith_summary":"The paper tries to establish that a practical subtable selector can be built from a divide-and-conquer strategy: slice a large table into overlapping windows, ask a fine-tuned language model to mark the relevant cells inside each window, merge the marked cells into a union subtable, and repeat until the subtable stops changing. The central claim is that this union subtable, although looser than the ideal 'gold' subtable that intersects all conditions, is accurate enough that feeding it to an existing reader improves exact-match answers on WikiTableQuestions and WikiSQL over both holistic readers and prior subtable selection methods. A sympathetic reader would care because the approach sidesteps the long-context limits of transformers and only requires the selector to reason about small local windows. The paper's headline evidence is a WikiTQ exact match of 63.65 with a GPT-3.5 reader, versus 59.21 for a leading SQL-decomposition baseline and 59.13 for a dense-retrieval baseline.","feed_headline":"Iterative window unions lift WikiTQ accuracy to 63.65","feed_subtitle":"A divide-and-conquer subtable selector beats SQL-decomposition and retrieval baselines with the same GPT-3.5 reader.","key_machinery":"The load-bearing mechanism is the coordinate-based union subwindow selection loop: each window is a w×w slice of the current table, the selector predicts a same-shaped grid of coordinate tokens marking relevant cells, and the cells marked anywhere are merged into a new table. What this does is convert a global table-reasoning problem into a series of local cell-classification problems, letting the language model work within a short context while the iteration captures long-range dependencies. A second piece of machinery is the training target construction: subwindows are labeled by selecting condition columns and answer columns within each window and then keeping the rows that satisfy all conditions present in that window, with balancing and value-based augmentation. The paper also introduces the coordinate representation as an alternative to index-based and full-table representations, which they show degrades less on cell-embedded conditions and avoids cascading generation errors.","core_discovery":"Given a question and a table, PieTa constructs a subtable by iteratively dividing the current table into w×w windows with a sliding stride of 1, using a fine-tuned Llama3.1 selector to emit coordinate tokens (such as <2,3> or <empty,empty>) that mark which cells in each window answer the question, and then taking the set union of all selected cells as the next table. This loop runs until a fixed point is reached, with the window size w fixed at 4. The key discovery is that the resulting union subtable, which is about 13.9% of the original table's cell count, performs nearly as well as the theoretical gold subtable in downstream QA while being far easier to generate, and it outperforms existing subtable selectors on exact match across multiple readers. The coordinate representation is what makes this possible: it preserves the original window structure, so a condition matching a cell value rather than a column header can still be selected, and it avoids the error compounding of autoregressive table generation.","pith_inferences":["The same window-union recipe could transfer to long-document QA or multi-hop retrieval, where local evidence must be combined across distant spans.","The paper's result suggests a general design principle: relax a global selection into a union of local selections; precision suffers slightly but recall stays high, which may be the right trade for downstream models.","A testable extension is to replace the fixed window with content-aware windowing (e.g., grouping by column semantics) to reduce the number of iterations and further shrink the union subtable.","Because the selector is reader-agnostic, jointly fine-tuning the selector and reader could close the remaining gap to gold-subtable performance, as the paper notes in its limitations section."],"forward_implications":["On WikiTQ, PieTa with a GPT-3.5 reader reaches 63.65 exact match, outperforming TabSQLify (59.21) and ITR (59.13) with the same reader class.","On WikiSQL, PieTa with TaPEx reaches 91.83 exact match versus 89.31 for the holistic TaPEx baseline, and also exceeds the holistic OmniTab baseline.","Union subtables average 13.91% of the original table's cells, so downstream readers work with far shorter contexts while losing little accuracy relative to gold subtables.","Subtable selection recall stays above 99% across WikiSQL test conditions while precision improves by 47.43 percentage points over ITR, indicating the union strategy is robust across answer-row and condition-column counts.","Varying table size from under 50 to over 400 cells, PieTa keeps EM higher than ITR, Dater, TabSQLify, and holistic readers."],"supporting_citations":[{"why":"Supplies the WikiTableQuestions test set that supports the headline WikiTQ results.","marker":"Pasupat and Liang, 2015"},{"why":"Supplies the WikiSQL dataset and SQL-derived gold column/row labels used for training the selector.","marker":"Zhong et al., 2017"},{"why":"Provides the TaPEx reader that is improved to 91.83 EM on WikiSQL.","marker":"Liu et al., 2022"},{"why":"Provides the OmniTab reader used in both datasets and the experimental protocol.","marker":"Jiang et al., 2022"},{"why":"ITR is the primary row/column retrieval baseline that PieTa outperforms in precision and QA accuracy.","marker":"Lin et al., 2023"},{"why":"TabSQLify is the strongest SQL-decomposition baseline and the source of the GPT-3.5 reader configuration.","marker":"Nahid and Rafiei, 2024"},{"why":"SQUALL provides SQL annotations for 11,468 WikiTQ questions, scaling the training data for subwindow targets.","marker":"Shi et al., 2020"}],"fun_headline_variants":["PieTa: iterative window unions for subtable QA","Divide-and-conquer subtable selection lifts WikiTQ","PieTa shrinks tables to 14% and keeps answers","PieTa: coordinate tokens select relevant cells"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The selector trained on windows from SQUALL and WikiSQL tables must generalize to arbitrary test windows, and for every window the question's answer can be determined from the condition and answer columns present within that window alone, so the union of per-window selections covers the needed evidence.","fun_headline_variants_meta":{"raw":{"variants":["PieTa: iterative window unions for subtable QA","Divide-and-conquer subtable selection lifts WikiTQ","PieTa shrinks tables to 14% and keeps answers","PieTa: coordinate tokens select relevant cells"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000925,"raw_usage":{"total_tokens":3947,"prompt_tokens":913,"completion_tokens":3034,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":529,"completion_tokens_details":{"reasoning_tokens":2967}},"tokens_in":529,"tokens_out":3034,"duration_ms":22001,"temperature":1.0,"reasoning_tokens":2967,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T18:37:28.066337+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a WikiTQ test question whose gold answer requires two condition columns that never appear together in any 4×4 window containing the answer cells, and check whether the final union subtable still contains the gold answer row; if a nontrivial fraction of such cross-window questions lose their answer cells, the local-window sufficiency assumption is violated. A direct numerical version would compare the oracle union of per-window gold selections to the gold subtable and show the gap in exact match on the test set.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the TaPEx reader that is improved to 91.83 EM on WikiSQL."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"TabSQLify is the strongest SQL-decomposition baseline and the source of the GPT-3.5 reader configuration."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"SQUALL provides SQL annotations for 11,468 WikiTQ questions, scaling the training data for subwindow targets."}],"review_version":1}