TableCopilot: A Table Assistant Empowered by Natural Language Conditional Table Discovery

Gang Chen; Guanyu Jiang; Huan Li; Ke Chen; Lidan Shou; Lingxi Cui

REVIEW 3 major objections 4 minor 17 references

TableCopilot: A Table Assistant Empowered by Natural Language Conditional Table Discovery

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper introduces natural-language conditional table discovery and a cross-fusion scorer, Crofuma, that outperforms six single-input table-discovery methods by at least 12% on NDCG@5.

desk verdict A genuinely new task formulation and a working demo, but the evaluation as written under-specifies the baseline adaptation and the train/test split, so the headline 12% NDCG@5 gain is plausible yet unverifiable from the paper alone. read the letter →

arxiv 2507.08283 v1 pith:XSNSQWLI submitted 2025-07-11 cs.DB

Lingxi Cui , Guanyu Jiang , Huan Li , Ke Chen , Lidan Shou , Gang Chen This is my paper

classification cs.DB

keywords tablediscoverynaturallanguageconditionalcross-fusionmatchingunionjoinassistantcontrastivelearningHNSWindexing

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper introduces natural-language conditional table discovery (nlcTD), a search setting in which the user supplies both a query table and a natural language condition, and the system must return tables that are unionable or joinable with the query table and also satisfy the condition. It proposes Crofuma, a cross-fusion scorer that separates matching into a single-modal table score and a cross-modal condition score, then aggregates the two at query time. TableCopilot packages this scorer inside an LLM-driven assistant so a user can go from a vague request to retrieved, analysis-ready tables in one session. The paper's central empirical claim is that Crofuma outperforms six existing keyword-, union-, and join-based discovery methods by at least 12% on NDCG@5 on the released nlcTables benchmark.

What carries the argument

The load-bearing object is the cross-fusion scoring function $\rho_k = \mathrm{MLP}(h_c) + \lambda \rho_t$, where $\rho_t$ is the single-modal table score and $h_c$ concatenates a condition-table matching vector and a condition-metadata matching vector. The condition-table vector is built from $\hat{h}_i = \mathrm{concat}(t_i, c, t_i - c, t_i \circ c)$ followed by a tanh layer and max-pooling across candidate tables, on the principle that the relevant content in a large candidate set is what the condition most activates. A pretrained column encoder trained by contrastive learning produces the column embeddings, and an HNSW (Hierarchical Navigable Small World) index gives coarse candidates in under 500 ms in the prototype. The same machinery handles NL-only, table-only, union, and join queries by dropping or weighting the missing channel.

What would settle it

Re-running the benchmark with the six baselines fed a uniform, documented NL-condition adapter (for example, appending the condition as a synthetic column or keyword query) and with NDCG computed on a held-out query set would settle the 12% claim; if the margin disappears on that reproduction, the cross-fusion advantage is not established.

Watch

Extended reading notes

Core claim

Crofuma's central idea is to treat the query table and the natural language condition as two independent evidence channels and fuse them only at scoring time. For the table channel, the query table's key column is matched by cosine similarity for join discovery, and unionability is scored by maximum bipartite matching over column similarities. For the language channel, the condition embedding is combined with candidate-table embeddings through concatenation, element-wise subtraction, and Hadamard product, then max-pooled over candidates and matched against table metadata with a text-encoder backbone; the two condition representations feed an MLP. The final score is the weighted sum of the table score and the MLP condition score, which is trained with mean-squared error against gold labels and remains meaningful when one input is absent. On nlcTables, the paper reports NDCG@5 of 0.4124 for conditional union and 0.6674 for conditional join, against best baselines of 0.3675 and 0.5571.

Load-bearing premise

The reported margin assumes the six single-input baselines were adapted to the natural language condition in a fair way and that the NDCG scores come from queries held out from training Crofuma's fusion MLP.

Editorial extensions

If this is right

Conditional discovery becomes a concrete benchmarkable task: future table assistants can measure whether they satisfy a user's stated constraints, not just whether they find structurally similar tables.
Because the fusion is a weighted sum of two scores, the same model can serve NL-only search and table-only search without retraining, so nlcTD does not require separate discovery tools.
The sub-500 ms coarse-ranking stage means the discovery step can be embedded inside an interactive LLM conversation without a noticeable wait.
End-to-end prototypes can chain discovery into downstream analysis in one workspace, so a user can retrieve unionable tables and immediately run cleaning or question-answering on the result.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the margin holds on repositories larger than 22,080 tables, conditional discovery could become the default entry point for data-lake search, shifting the hard part from schema matching to intent parsing.
Ablating $\lambda$ and the fusion formulation (e.g., replacing max-pooling with attention) would localize the source of the gain; the paper compares whole systems, not components.
The two-channel pattern is portable: querying structured objects by 'example plus constraint' is a generic retrieval shape, so the scorer could transfer to API schemas or knowledge-graph subgraphs with the same offline/online split.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper does something real: it defines nlcTD, a table-discovery scenario where the user supplies both a query table and a natural-language condition, and it ships a working prototype with public code, data, and a video. That alone is worth a serious look. The proposed method, Crofuma, is a sensible assembly of known pieces—column contrastive learning for table embeddings, a max-pooling condition–table interaction, RoBERTa for metadata matching, and HNSW for candidate retrieval. Nothing here is revolutionary, and the paper doesn't pretend otherwise. The task definition is the contribution, and it is a good one.

Where the paper gets soft is in the evaluation. Table 1 reports NDCG@5 for Crofuma against six baselines, but the text never says how those single-input baselines were adapted to receive both the query table and the NL condition. GTR and StruBert are text-based; Santos, Starmie, Josie, and Deepjoin expect a table. If they were run with only one input, the comparison is structurally unfavorable and the “at least 12%” margin is not evidence of superiority on nlcTD—it is evidence that a system with both inputs beats systems given one. The second gap is the training/evaluation split. Equation 4 optimizes the MLP over the full query set Q, and Section 2.4 gives no indication that a held-out subset was used for the NDCG numbers. If the same queries are used for both, the result could be measuring in-sample fit rather than retrieval quality. Both omissions are load-bearing because the central claim is precisely that Crofuma beats these methods on this task. They are also easy to fix: state the split, describe the baseline adaptation, add error bars. The benchmark is introduced by the same group, but it is public, so readers can check; that partially mitigates the self-evaluation concern.

The architecture itself is fine. The fusion weight λ is hand-chosen, but that is a minor issue for a demo system. The paper is honest that Crofuma reuses existing components, and the ability to fall back to single-input queries is a nice practical touch.

This is a demo-track paper, and judged at that level it is a solid submission that needs a revision, not rejection. For anyone working on data discovery or LLM-assisted table tools, the nlcTD framing is worth knowing about and citing. The evaluation gaps are real, so I would not accept the 12% claim on faith, but I would send it to referees—they can ask for the missing details and the public artifacts let them verify.

Referee Report

3 major / 4 minor

Summary. The paper introduces nlcTD, a table-discovery scenario in which a query is composed of a user-supplied natural-language condition and a query table. The authors propose Crofuma, a cross-fusion method that combines a table scorer with a learned NLC (natural-language condition) scorer, and present TableCopilot, an LLM-based assistant that uses Crofuma to support table discovery and downstream analysis. The central empirical claim is that Crofuma outperforms six existing single-input table-discovery methods by at least 12% on NDCG@5 on the nlcTables benchmark, which the same group released. The paper also describes the system architecture, offline indexing, online query processing, and a demonstration prototype with a runtime case study.

Significance. If the empirical claim is supported, the paper would make a useful contribution by extending table discovery to a natural-language-conditioned setting and by demonstrating a working LLM-based assistant that integrates discovery with analysis. The paper is commendable for releasing code, datasets, an instructional video, and a live demo, which would enable reproducibility and follow-up work. The proposed cross-fusion architecture is simple and plausible, and the compatibility with single-input settings is a practical strength. However, the significance currently hinges almost entirely on Table 1, and the evaluation section omits information that is essential for interpreting that table: no train/test split is defined despite Eq. (4) optimizing over the full query set, no error bars accompany the NDCG values, and no protocol is given for how single-input baselines were adapted to receive both the query table and the NL condition. These omissions directly affect whether the headline 12% improvement is evidence of a genuinely superior method.

major comments (3)

[Section 2.4, Table 1, Eq. (4)] The evaluation does not describe a train/test split, while Eq. (4) optimizes the MLP using the mean squared error over the entire query set Q. If the NDCG@5 scores in Table 1 are computed on the same queries used to train the MLP, then the reported advantage of Crofuma could reflect in-sample fit rather than retrieval quality. The authors must specify exactly which query set was used for training the MLP and which was held out for evaluation, and they should report test-only NDCG@5 values, ideally with variance or significance information across multiple runs.
[Section 2.4, Table 1] The six baselines are described as single-input methods, but the nlcTD task provides both a query table and a natural-language condition. The paper never states how table-only methods (Santos, Starmie, Josie, Deepjoin) or text-only methods (GTR, StruBert) were given the other input, or whether they were run with only one input. If the baselines were not adapted to consume both modalities, the comparison is structurally unfavorable and the claimed 12% gain is not evidence of superior nlcTD capability. A precise per-baseline adaptation protocol is needed, and if any baseline was run in its original single-input form, the paper should say so explicitly and interpret the results accordingly.
[Section 2.4, Table 1] Table 1 displays two columns labeled identically as "NDCG@5" for each scenario (nlc-Union and nlc-Join), yet each method has two distinct numbers in those columns. The table header is therefore ambiguous, and the reader cannot tell whether the second column is NDCG@10, NDCG@1, or another metric. Since the abstract and conclusion rely on specific NDCG@5 numbers, the authors must relabel the columns and ensure the reported comparisons use the correct metric.

minor comments (4)

[Section 2.2] The sentence "This index achieves an average query time of less than 500 ms for each in a repository containing 7,500+ tables" contains a grammatical error; it should read "for each query" or "for each search request."
[Section 2.3, Eq. (1)-(4)] The notation is inconsistent about whether |T| denotes the full repository or the candidate set after HNSW coarse ranking. Eq. (4) sums over all |T| tables, but the NLC scorer is applied only to retrieved candidates; please clarify the candidate-set notation.
[References] Reference [5] contains a typo in the author list ("Yand Zhang" should be "Yang Zhang"), and the DOI in the VLDB publication notice is an unfilled placeholder "https://doi.org/10.1145/xxxx."
[Section 2.3] The choice of the fusion weight λ is not discussed; if λ is hand-tuned on the evaluation benchmark, this should be stated and its sensitivity should be reported, since it directly controls the contribution of the table scorer versus the NLC scorer.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: Crofuma's score is a supervised MLP plus a fixed similarity, and Table 1 is an empirical evaluation, not an identity. The only circularity-adjacent issues are an unpublished train/test split and unstated baseline adaptation, which are evaluation-protocol gaps rather than demonstrated circular reductions.

full rationale

Walking the derivation chain, Crofuma's final score (Eq. 4) is obtained by training an MLP with MSE loss against gold labels y_k and adding a lambda-weighted fixed table-similarity rho_t. This is a standard supervised scoring model; the table score is a learning-free cosine or bipartite-matching similarity, and the NLC score is a learned text-match module. Nothing in these equations defines the gold labels, the nlcTables benchmark, or the NDCG@5 numbers, so there is no step in which the reported prediction is equivalent to its inputs by construction. The benchmark [1] is hosted by the authors' own SuDIS-ZJU group, but it is a public dataset and is not invoked as a uniqueness theorem or as a reason to forbid alternative methods, so it is at most a minor self-citation with independent empirical content. Two protocol omissions are worth flagging explicitly as non-circularity risks: (i) Eq. 4 optimizes over all q in Q while Section 2.4 reports NDCG@5 on nlcTables without any stated train/test split, leaving open the possibility that Table 1 measures in-sample fit; and (ii) the six baselines are all 'single-input' methods, and the paper never states how GTR, StruBert, Santos, Starmie, Josie, or Deepjoin were given the NL condition in the nlcTD scenario, so the at-least-12% margin could partly reflect an asymmetric input setup. Both are validity concerns about the evaluation protocol, not circular reductions visible in the paper's equations.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The central empirical claim relies on the assumption that the nlcTables benchmark is representative and correctly labeled, and that the baseline adaptation is fair. The method's design assumes table relevance can be decomposed into a linear combination of column similarity and NL-condition similarity. No new physical entities or mediators are introduced.

free parameters (1)

lambda (fusion weight) = not reported
Section 2.3 combines table score and NLC score with a weighting factor lambda; the paper does not state its value or whether it is tuned on a validation set.

assumptions (5)

domain assumption Table relevance for nlcTD can be decomposed as a weighted sum of a table similarity score and an NL-condition similarity score.
Eq. (4) defines the final score as MLP(hc) + lambda * rho_t, assuming linear, query-independent combination of the two signals.
domain assumption The metadata (caption/description) of a table reflects its content sufficiently for text matching.
Section 2.3 condition-metadata matching uses RoBERTa to match the NL condition to table captions, following LakeCompass [5].
domain assumption Max-pooling over the candidate set extracts the most relevant table content for the NL condition.
Eq. (3) applies MaxPooling across candidate hidden vectors, citing GTR [12] for the interaction design.
domain assumption The nlcTables benchmark provides valid gold labels for the nlcTD task.
Section 2.4 evaluates on nlcTables [1], built by the same group; no annotation procedure or inter-annotator agreement is described.
domain assumption HNSW coarse ranking does not exclude relevant tables before fusion.
Section 2.2-2.3 first retrieves a limited candidate set from the HNSW index, then applies cross-fusion; relevant tables missed by the index cannot be recovered.

how reviews work

0 comments

Cite this review

Pith. "Pith review of TableCopilot: A Table Assistant Empowered by Natural Language Conditional Table Discovery." pith.science (2026). https://pith.science/paper/XSNSQWLI

@misc{pith2026250708283,
  author       = {Pith},
  title        = {Pith review of: TableCopilot: A Table Assistant Empowered by Natural Language Conditional Table Discovery},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XSNSQWLI}},
  note         = {Machine review of arXiv:2507.08283}
}

read the original abstract

The rise of LLM has enabled natural language-based table assistants, but existing systems assume users already have a well-formed table, neglecting the challenge of table discovery in large-scale table pools. To address this, we introduce TableCopilot, an LLM-powered assistant for interactive, precise, and personalized table discovery and analysis. We define a novel scenario, nlcTD, where users provide both a natural language condition and a query table, enabling intuitive and flexible table discovery for users of all expertise levels. To handle this, we propose Crofuma, a cross-fusion-based approach that learns and aggregates single-modal and cross-modal matching scores. Experimental results show Crofuma outperforms SOTA single-input methods by at least 12% on NDCG@5. We also release an instructional video, codebase, datasets, and other resources on GitHub to encourage community contributions. TableCopilot sets a new standard for interactive table assistants, making advanced table discovery accessible and integrated.

Figures

Figures reproduced from arXiv: 2507.08283 by the authors.

**Figure 1.** Overall Architecture of TableCopilot. workspace status (e.g., an empty or incomplete table for search, and a complete table for analysis and manipulation). Table Assistant Pipeline. The assistant performs two key tasks: (1) identifying whether the human instruction involves a table discovery request and (2) handling table analysis and processing tasks beyond discovery. For a table discovery request, the assistant re… view at source ↗

**Figure 2.** The Graphical User Interface of TableCopilot. For a live demonstration, visit our project website on GitHub [2]. 3 DEMONSTRATION Artifacts and Demonstration Materials. TableCopilot is built on the Flask framework and comprises over 10,000 lines of backend and frontend code. To encourage participation from developers and researchers, we provide an instructional video, the codebase, and additional resources on GitHu… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

17 extracted references · 15 canonical work pages

[1]

nlcTables

2025. nlcTables. https://github.com/SuDIS-ZJU/nlcTables

work page 2025
[2]

Crofuma Project

2025. Crofuma Project. https://sudis-zju.github.io/table-copilot/

work page 2025
[3]

S Castelo, R Rampin, A Santos, A Bessa, F Chirigati, and J Freire. 2021. Auctus: a dataset search engine for data discovery and augmentation. PVLDB, 2791–2794

work page 2021
[4]

R Castro Fernandez, Z Abedjan, F Koko, G Yuan, S Madden, and M Stonebraker

work page
[5]

C Chai, Y Deng, Y Zhan, Z Cao, Y Zhang, L Cao, Z Wang, Yand Zhang, Y Yuan, G Wang, and N Tang. 2024. LakeCompass: An End-to-End System for Data Maintenance, Search and Analysis in Data Lakes. PVLDB, 4381–4384

work page 2024
[6]

L Cui, H Li, K Chen, L Shou, and G Chen. 2024. Tabular Data Augmentation for Machine Learning: Progress and Prospects of Embracing Generative AI. ArXiv, arXiv:2407.21523

arXiv 2024
[7]

Y Dong, C Xiao, T Nozawa, M Enomoto, and M Oyamada. 2023. DeepJoin:Joinable Table Discovery with Pre-Trained Language Models. PVLDB, 2458–2470

work page 2023
[8]

G Fan, J Wang, Y Li, D Zhang, and R J. Miller. 2023. Semantics-aware Dataset Discovery from Data Lakes with Contextualized Column-based Representation Learning. PVLDB, 1726–1739

work page 2023

Show all 17 references

[9]

Miller, and M Riede- wald

A Khatiwada, G Fan, R Shraga, Z Chen, W Gatterbauer, R. Miller, and M Riede- wald. 2023. SANTOS: Relationship-based Semantic Table Union Search. Proc. ACM Manag. Data, 1–25

2023
[10]

P Li, Y He, D Yashar, W Cui, S Ge, H Zhang, D R Fainman, D Zhang, and S Chaudhuri. 2024. Table-GPT: Table Fine-tuned GPT for Diverse Table Tasks. Proc. ACM Manag. Data, 176

2024
[11]

Davison, and J Heflin

M Trabelsi, Z Chen, S Zhang, B D. Davison, and J Heflin. 2022. StruBERT: Structure-aware BERT for Table Search and Matching. In WWW. 442–451

2022
[12]

F Wang, K Sun, M Chen, J Pujara, and P Szekely. 2021. Retrieving Complex Tables with Multi-Granular Graph Representation Learning. SIGIR, 1472–1482

2021
[13]

J Wang, G Li, and J Feng. 2025. iDataLake: An LLM-Powered Analytics System on Data Lakes. Data Engineering, 57

2025
[14]

X Zhang, S Luo, B Zhang, Z Ma, J Zhang, G Li Y Li, Z Yao, K Xu, J Zhou, D Zhang-Li, J Yu, S Zhao, J Li, and J Tang. 2024. TABLELLM: Enabling Tabular Data Manipulation by LLMs in Real Office Usage Scenarios. ArXiv, arXiv:2403.19318

2024 arXiv
[15]

E Zhu, D Deng, F Nargesian, and R J. Miller. 2019. JOSIE: Overlap Set Similarity Search for Finding Joinable Tables in Data Lakes. InProc. ACM SIGMOD.847–864

2019
[16]

J Zhu, P Cai, K Xu, L Li, Y Sun, S Zhou, H Su, L Tang, and Q Liu. 2024. Autotqa: Towards autonomous tabular question answering through multi-agent large language models. PVLDB, 3920–3933

2024
[2018]

ICDE, 1001–1012

Aurum: A Data Discovery System. ICDE, 1001–1012

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

nlcTables

2025. nlcTables. https://github.com/SuDIS-ZJU/nlcTables

work page 2025

[2] [2]

Crofuma Project

2025. Crofuma Project. https://sudis-zju.github.io/table-copilot/

work page 2025

[3] [3]

S Castelo, R Rampin, A Santos, A Bessa, F Chirigati, and J Freire. 2021. Auctus: a dataset search engine for data discovery and augmentation. PVLDB, 2791–2794

work page 2021

[4] [4]

R Castro Fernandez, Z Abedjan, F Koko, G Yuan, S Madden, and M Stonebraker

work page

[5] [5]

C Chai, Y Deng, Y Zhan, Z Cao, Y Zhang, L Cao, Z Wang, Yand Zhang, Y Yuan, G Wang, and N Tang. 2024. LakeCompass: An End-to-End System for Data Maintenance, Search and Analysis in Data Lakes. PVLDB, 4381–4384

work page 2024

[6] [6]

L Cui, H Li, K Chen, L Shou, and G Chen. 2024. Tabular Data Augmentation for Machine Learning: Progress and Prospects of Embracing Generative AI. ArXiv, arXiv:2407.21523

arXiv 2024

[7] [7]

Y Dong, C Xiao, T Nozawa, M Enomoto, and M Oyamada. 2023. DeepJoin:Joinable Table Discovery with Pre-Trained Language Models. PVLDB, 2458–2470

work page 2023

[8] [8]

G Fan, J Wang, Y Li, D Zhang, and R J. Miller. 2023. Semantics-aware Dataset Discovery from Data Lakes with Contextualized Column-based Representation Learning. PVLDB, 1726–1739

work page 2023