TableCopilot: LLM Table Discovery

• TableCopilot is an LLM-powered table discovery system that retrieves union- or join-compatible tables through Natural Language Conditional Table Discovery (NLCTD).
• It employs a dual-scoring mechanism combining structural table matching with natural language condition scoring, significantly outperforming state-of-the-art methods.
• The system features an interactive, session-oriented interface that supports query refinement and is applicable in domains like recruiting, finance, and bioinformatics.

Searching arXiv for the specified paper to ground the article and citation. TableCopilot is an LLM-powered table assistant designed for interactive table discovery and analysis in large repositories of heterogeneous tables. It is introduced together with the task of Natural Language Conditional Table Discovery (NLCTD), in which a user provides both a query table $T'$ and a natural-language condition $C$, and the system returns a ranked list of tables $T_i \in T$ that can be union- or join-merged with $T'$ while satisfying the semantic constraints expressed in $C$ (Cui et al., 11 Jul 2025). The system is motivated by the observation that many table assistants assume a well-formed table already exists in the workspace, whereas practical workflows often begin with no table or only a partial table sketch.

1. Problem setting and motivation

TableCopilot is centered on NLCTD, a search task over a large repository of tables $T$. In this setting, the user supplies a query table $T'$—which may be empty—and a natural-language condition such as “applicants must graduate in 2023 or 2024, CS grade >90.” The retrieval target is not merely topically related tables, but tables that satisfy two simultaneous constraints: structural compatibility with the query table through union or join, and semantic compatibility with the natural-language condition (Cui et al., 11 Jul 2025).

The motivating gap is explicitly framed against existing LLM-based table assistants such as TableLLM, iDataLake, and AutoTQA. Those systems are described as focusing on analytics or question answering over a table that is already present, rather than on discovering relevant tables from a data lake or table pool. TableCopilot therefore addresses an earlier stage in the analytic pipeline: acquiring the tables to be analyzed.

Three difficulties define the problem. First, scale prevents loading millions of heterogeneous tables into an LLM because of token limits and privacy concerns. Second, expressiveness is limited if retrieval relies on keywords or single-table queries, since complex multi-facet requirements are often expressed in natural language. Third, structure matters because tables are two-dimensional objects, so matching must account for schema- and column-level relationships rather than treating tables as unstructured text alone. This suggests that table discovery requires a retrieval formulation that is simultaneously structural, semantic, and interactive.

2. System organization and interaction model

TableCopilot is implemented as a pipeline in which an LLM-mediated controller routes requests either to table discovery or to downstream table-analysis tasks. A user begins by issuing a natural-language request or a GUI operation in the interface. A controller prompt in an LLM, exemplified with GPT-4o, determines whether the request is a discovery task, identified through a query table or NL-only search intent, or instead a task such as TableQA, data cleaning, or visualization. Discovery requests are sent to the CROFUMA retrieval module (Cui et al., 11 Jul 2025).

The discovery pipeline has distinct offline and online phases. In the offline phase, every repository column is encoded with a contrastively pretrained column encoder using a PLM backbone, while metadata such as captions and descriptions is encoded with a text encoder based on BERT or RoBERTa. The resulting column and metadata embeddings are concatenated and indexed with HNSW. In the online phase, the query table $T'$ and natural-language condition $C$ are embedded, top-$N$ candidates are retrieved through the HNSW index, and each candidate is rescored with fine-grained table and NL-condition scores before final aggregation.

The interactive design is a substantive part of the system rather than a superficial wrapper. The model panel allows selection among retrieval backends, including CROFUMA, Starmie, and Auctus, and supports adjustment of weights between table matching and NL matching. The history panel permits reuse of earlier query tables and conditions. The workspace supports incremental table addition or removal and allows a user to refine the NL condition or replace the query table during a session. A plausible implication is that TableCopilot is intended not only as a one-shot retriever but as a session-oriented discovery environment.

3. CROFUMA architecture

CROFUMA is the retrieval model underlying TableCopilot. Its defining characteristic is a cross-fusion design that combines a single-modal table scorer with a cross-modal natural-language-condition scorer. The final ranking score is a weighted combination of these two signals (Cui et al., 11 Jul 2025).

For the table scorer, the formulation depends on whether the search is join-style or union-style. In join-style search, the model identifies the join key column embedding $C$0 in $C$1 and compares it with the same column in a candidate table using cosine similarity:

$C$2

In union-style search, a bipartite graph $C$3 is constructed between the columns of $C$4 and $C$5, with edge weights defined by column-level cosine similarity. The unionability score is then given by maximum weighted matching:

$C$6

The NLC scorer has three components. First, for condition-table matching, if $C$7 denotes the NL-condition embedding and $C$8 the candidate-table embedding, the model forms a four-way interaction:

$C$9

$T_i \in T$0

and then applies max-pooling over all $T_i \in T$1:

$T_i \in T$2

Second, for condition-metadata matching, table captions and descriptions are encoded via RoBERTa or T5 and matched with the same NL encoder to obtain $T_i \in T$3. Third, these representations are fused:

$T_i \in T$4

$T_i \in T$5

The final score is

$T_i \in T$6

where $T_i \in T$7 is a tunable weight. Training is end-to-end for the NLC MLP and fusion weights using MSE loss against human-labeled relevance $T_i \in T$8:

$T_i \in T$9

This architecture explicitly separates structural table compatibility from semantic conditioning while still allowing fusion at ranking time. The reported ablations indicate that both components are necessary.

4. Data, training procedure, and implementation

The primary training resource is NLCTABLES, a dataset containing 627 realistic NLCTD queries spanning NL-only, union, join, and fuzzy settings, together with 22,080 candidate tables containing between 1 and 69.5K rows and at most 33 columns, and 21,200 gold labels (Cui et al., 11 Jul 2025). This dataset operationalizes the NLCTD setting by coupling query intent, candidate tables, and graded relevance.

Preprocessing includes contrastive learning on real column pairs from Starmie to pretrain the column encoder, along with metadata normalization through lowercasing and stopword removal. The column encoder is BERT-base with 768-dimensional embeddings, pretrained and then contrastively fine-tuned with learning rate $T'$0. The NL encoder and metadata encoder are RoBERTa-base, also with 768-dimensional representations. The fusion MLP uses two hidden layers of size 512 with $T'$1 activations.

For indexing, the system uses HNSW on 23K embeddings with $T'$2 and $T'$3, reported to achieve $T'$4 s per recall. Optimization uses batch size 64, AdamW with learning rate $T'$5 and weight decay $T'$6, and early stopping on validation NDCG@5. These implementation details indicate that TableCopilot is engineered as a hybrid system: dense retrieval for coarse search, followed by specialized reranking for task-specific relevance.

5. Empirical evaluation

Evaluation is reported with NDCG@5, MAP, and recall@K. Baselines include keyword-search methods GTR and StruBERT, union-search systems Santos and Starmie, and join-search systems Josie and DeepJoin (Cui et al., 11 Jul 2025). The comparison is therefore positioned across multiple retrieval paradigms rather than against only one family of methods.

The principal quantitative result is that CROFUMA outperforms state-of-the-art single-input methods by at least 12% absolute gain in NDCG@5 on both union and join tasks. The reported numbers are $T'$7 versus $T'$8 for union, and $T'$9 versus $C$0 for join, with statistical significance at $C$1 under a paired $C$2-test. Within the article’s evidentiary frame, these gains support the claim that combining query-table structure with natural-language conditions materially improves retrieval quality.

Ablation results further isolate the model’s components. Removing the NL-condition scorer reduces NDCG@5 by approximately 15%, while setting $C$3, which removes the table score, reduces performance by approximately 8%. The qualitative example given is that CROFUMA ranks “scholarship” above “stu_club” when the NL condition is “average grade >80,” whereas table-only or keyword methods fail. This example is consistent with the system’s stated goal: retrieval conditioned jointly on schema compatibility and semantic constraints.

A common misconception would be to treat TableCopilot as a generic semantic table search engine. The reported experiments instead describe a more specific retrieval problem in which the query includes relational intent, such as unionability or joinability, and a natural-language condition that materially changes relevance.

6. Interface, released artifacts, and operational scope

The user interface is divided into a Search Panel, a Result Panel, and a Processing Panel (Cui et al., 11 Jul 2025). The Search Panel supports upload or selection of a query table, entry or editing of the NL condition, choice between union and join, and selection of model and parameters. The Result Panel provides side-by-side previews of top-$C$4 tables with separate table and NL scores, along with “Add to workspace” controls. The Processing Panel supports downstream operations after insertion into the workspace, including data cleaning, augmentation, joins, unions, and TableQA mediated by the LLM.

The released artifacts include source code with a Flask backend and React frontend, pretrained CROFUMA models, index files, the NLCTABLES dataset, preprocessing scripts, a Dockerfile, setup instructions, and an instructional video. Deployment instructions include cloning the repository, building and running Docker on port 5000, and supplying either a GPT-4 API key or a local LLM endpoint. These artifacts place TableCopilot within the reproducibility-oriented tradition of research systems that couple algorithmic contribution with an executable prototype.

The operational scope extends beyond laboratory evaluation to example scenarios such as recruiter dashboards assembling applicant shortlists from multiple HR tables, finance analysts discovering and merging quarterly reports in corporate data lakes, and bioinformatics pipelines that search gene-expression tables conditioned on experimental metadata. These scenarios are presented as illustrations of NLCTD rather than as benchmarked deployments.

7. Limitations and research directions

The authors note three main limitations. First, the current NL condition encoder represents the condition as a single vector, which may be insufficient for multi-sentence or stepwise conditions. Second, real-time index updates for newly inserted tables are not yet supported. Third, privacy and compliance issues remain unresolved when retrieving from sensitive data lakes (Cui et al., 11 Jul 2025). These constraints delimit the current system’s applicability, especially in environments where repositories evolve continuously or governance requirements are strict.

Several extensions are proposed. One is iterative, multi-turn NLCTD in which the assistant asks clarifying questions. Another is fine-tuning the LLM itself, for example through a table-adapted GPT, for end-to-end retrieval and analysis. A third is incorporation of schema links or foreign-key graphs for deeper join inference. This suggests that TableCopilot can be situated at the intersection of neural table retrieval, interactive data integration, and LLM-assisted analytics, with current work emphasizing retrieval modularity rather than a monolithic end-to-end model.

Within that trajectory, TableCopilot’s central contribution is the formalization of NLCTD and the corresponding CROFUMA architecture that combines table-only and cross-modal matching in a unified assistant. Its significance lies less in replacing downstream table analysis than in addressing the antecedent step of discovering the relevant tables in the first place.