TACO: Task-Aware Column Description Generation Using Large Language Models Ting Cai1 , Rakesh R. Menon2 , Yiru Chen2 , Zifan Liu2 , Yuan Tian3 , Fei Wu2 , Anudeep Chimakurthi2 , Prashanthi Ramamurthy2 , Sunav Choudhary2 , Kun Qian2 , Yunyao Li2 1
University of Wisconsin-Madison 3 Purdue University, 2 Adobe,
[email protected], [email protected], {rakeshra, yiruc, zifanl, feiw, achimakurthi, pramamur, schoudha, kunq, yunyaol}@adobe.com
arXiv:2606.21685v1 [cs.CL] 19 Jun 2026
Abstract
Observer_LU
Structured data is ubiquitous, and large language models (LLMs) are increasingly leveraged to reason over such data in tasks such as entity linking, table question answering, and natural language-to-SQL translation. However, opaque and uninformative column names—prevalent in real-world datasets—limit the ability of LLMs to identify correct columns, thereby hindering semantic reasoning. To support effective semantic retrieval and understanding, columns must be enriched with accurate, context-aware descriptions. We present TACO, an automatic three-stage framework for taskaware column description generation. TACO generates enriched descriptions incorporating domain-relevant cues and refines them by optimizing their utility for downstream reasoning tasks. Extensive experiments across public and proprietary datasets show that TACO consistently outperforms existing methods, improving downstream entity linking performance by up to 52%. We further demonstrate that incorporating user feedback with TACO yields additional performance gains.
1
OI
String
W_Phn
String
A/T
String
How many observations per observer?
Description Generation OI captures the abbreviated initials of an observer's name, serving as a unique identifier for attributing and counting the number of observations recorded by each observer.
Figure 1: An illustrative example of column description generation, where the generated description provides enough context to choose the correct column for answering the question.
difficult to interpret. Even widely used humancurated benchmarks, such as BIRD (Li et al., 2024; Wretblad et al., 2024), exhibit this issue; e.g., there are tables containing opaque column names such as A2 without any accompanying descriptions. Semantic enrichment, particularly through column description generation, is essential for improving the interpretability of relational data and its usability in conversational systems. Figure 1 shows an example of the column description generation task. For example, given the column OI in a scientific observation table, a generated description might state “OI captures the abbreviated initials of an observer’s name, serving as a unique identifier ...”. Such metadata can substantially aid downstream tasks: an NL2SQL system can answer the query “How many observations per observer?” far more effectively when provided with the description rather than just the column name OI. Recent advances in large language models (LLMs) have inspired efforts to automatically enrich table semantics by generating column descrip-
Introduction
Structured data is ubiquitous across enterprise, governmental, and scientific domains. A wide range of tasks, such as entity linking, table question answering, keyword search, and natural language–to–SQL (NL2SQL) translation, require accurate interpretation of the schema semantics. However, in practice, the vast majority of datasets provide only minimal or cryptic metadata. Column names are often abbreviated (e.g., esal for “employee salary") or domain-specific, while column descriptions are often missing altogether. For instance, our analysis of five large enterprise datasets (over tens of thousands of columns) from a data vendor, revealed that over 95% of columns lacked descriptions, and more than 40% contained abbreviations that were 1
tions. A common approach is to prompt LLMs with table and column names (and optionally data values) to produce column descriptions (Wretblad et al., 2024; Zhang et al., 2025a). However, existing LLM-based solutions, which rely on few-shot prompting and operate in a single pass, exhibit three fundamental limitations. First, LLMs often interpret abbreviations inconsistently, expanding the same abbreviation differently across columns within the same dataset. For example, the abbreviation “wt” may be interpreted as “witness” in wt_species_code but as “weight” in wt_stake, even though both should share the same meaning within the same table. Second, generated descriptions frequently introduce hallucinations or irrelevant details. Third, the descriptions are often noisy or overly generic, with key semantic cues missing. Together, these issues limit the effectiveness of the descriptions in downstream tasks. To overcome these challenges, we propose TACO (Task-Aware Column description generation), a novel three-step framework: Column name expansion resolves abbreviations prior to description generation, ensuring consistent interpretation across columns. Expanding them jointly over the full dataset also provides richer semantic signals. Description generation produces semantically rich descriptions guided by table context. In addition, the descriptions are augmented with synonyms, keywords, and proxy search queries for better semantic retrieval. Description revision simulates downstream tasks (e.g., semantic retrieval) to refine and disambiguate descriptions based on their performance in these tasks, generating task-aware descriptions that remedy overly generic LLM outputs and missing semantic cues. As an extension, TACO can elicit human feedback for abbreviation expansions in which it exhibits low confidence. The resulting humanprovided corrections are then propagated across the dataset to refine column descriptions, enabling TACO to flexibly adapt to a human-in-the-loop setting. Our contributions are as follows:
tion, and downstream-task-informed revision. • Through extensive experiments on both public benchmarks and proprietary datasets for the task of entity linking, we demonstrate that TACO outperforms state-of-the-art baselines, achieving up to 52% improvements in retrieval performance. • We provide a new evaluation dataset to facilitate and benchmark research on task-aware column description generation.
2
Problem Statement
We formally define the task of column description generation as follows. Let a dataset be represented as a collection of tables T = {t1 , t2 , · · · , tm }, where m is the number of tables in the dataset. Each table ti = (ni , Ci ) consists of a table name ni and a set of column names Ci = {ci1 , ci2 , · · · , ciu }, where u is the number of columns in the table. The objective is to generate, for every column cij , a natural language description dij that conveys its semantics and facilitates downstream tasks such as NL2SQL, keyword search, table QA and entity linking. Formally, we seek a mapping fθ : (ni , Ci , T ) → {di1 , di2 , · · · , diu },
(1)
where θ denotes the parameters of the model used to generate the descriptions. Unlike prior work that directly applies a single prompt to compute dij , we decompose fθ into three stages: (1) Abbreviation expansion produces expanded forms ĉij for each column name cij and n̂i for each table name ni . (2) Description generation generates candidate descriptions d˜ij conditioned on expanded column and table names. (3) Description revision refines d˜ij into final description dij by incorporating feedback from simulated downstream tasks. We restrict our inputs to metadata, namely table and column names, and assume no access to column values. This choice is motivated by data privacy and compliance constraints, as raw database values may contain sensitive information subject to regulation (Regulation, 2016; Illman and Temple, 2019) and are often prohibited from being exposed to learning systems. As a result, metadata-only access is a common assumption in prior schema linking and NL2SQL works (Zhang et al., 2023b; Tian et al., 2023; Lei et al., 2020; Tian et al., 2024; Maamari et al., 2024).
• We introduce TACO, a comprehensive threestep solution that produces consistent, semantically rich, and task-aware column descriptions through dataset-wide column name expansion, context-guided description genera2
Tables
Abbreviation Expansion
Description Generation
Column Name Expansion
Description
Synonyms
Table Name Expansion
Keywords
Proxy Queries
Table name expansion. We also expand each table name ni into a concise natural language title n̂i using the expanded columns as context. When a table contains more than k columns, we randomly sample k columns to control prompt length. The full prompt to generate the table expansion can be found in Appendix 8.3. We enforce ground expansions by conditioning the prompt on information implied by the columns and prohibiting the introduction of new domain terms or external explanations.
Description Revision Simulated Query Generation
Simulated Vector Search
Description Revision
Figure 2: Overview of TACO. TACO has three main stages: Abbreviation Expansion, Description Generation, and Description Revision.
3
3.2
Given the expanded table name and expanded column names, we generate column descriptions using a prompt applied to groups of K columns per table. Each prompt conditions on the expanded table name together with the expanded names of the K columns. To ensure grounded and consistent descriptions, we include explicit constraints in the prompt; the full prompt is provided in Appendix 8.4. Specifically, the prompt enforces the following rules: (i) disambiguate columns with similar names within the same table, (ii) avoid inventing fields or data, and (iii) prefer domain-agnostic phrasing unless the table context clearly indicates otherwise. Each generated description is structured to support semantic retrieval and consists of four components: (i) a one-sentence overview, (ii) a set of aliases, (iii) a set of relevant keywords, and (iv) a collection of proxy user queries that approximate potential search intents for retrieving the column. As an example, the description generated for OI includes the following:
Method
In this section, we present TACO, a modular framework for task-aware column description generation that addresses three limitations of single-prompt baselines: inconsistent abbreviation interpretation, hallucinated or weakly grounded descriptions, and a lack of downstream awareness. As illustrated in Figure 2, TACO consists of three sequential stages. Abbreviation expansion performs dataset-level expansion to ensure consistent interpretation across columns. Next, Description generation conditions on enriched schema context and expanded column names, reducing reliance on opaque identifiers and mitigating hallucinations. Finally, Description revision leverages semantic retrieval as a downstream proxy to refine descriptions based on task performance, explicitly injecting downstream awareness. 3.1
Description Generation
Abbreviation Expansion
In this section, we explain how we expand the abbreviated column names and table names into schema-consistent, semantically grounded name expansions.
Overview: “OI captures the abbreviated initials of an observer’s name ...” Aliases: “observer code”, “scientist initials” Keywords: “unique ID”, “observer initials” Proxy Queries: “identify observer by initials”, “find observer abbreviation in data”
Column name expansion. We expand each abbreviated column name cij into a schemaconsistent natural language expansion ĉij using a LLM-based component that conditions on schema context, including other columns within the same table and related tables. We implement this component using the C OLUMBO method (Cai et al., 2025), which (i) exploits intra-table and inter-table column context, (ii) performs token-level chain-of-thought expansion, and (iii) enforces dataset-level consistency so that the same abbreviation is expanded uniformly across the schema.
3.3
Description Revision
After abbreviation expansion and structured description generation, some columns remain difficult to disambiguate due to overlapping semantics. In particular, columns may share similar surface forms or refer to closely related concepts. Figure 3 illustrates such a case, where two columns refer to closely related but different concepts, leading to an incorrect top-1 retrieval. To address this issue, we design a revision stage that explicitly incorporates 3
larity of the embeddings, and ϕ is the embedding function. We collect the top V competing columns for that query and ask the LLM to revise d˜c into a more distinctive description d̃′ c . For efficiency, we group all queries associated with the same column into a single prompt and ask the LLM to perform a single revision per column. Finally, we evaluate the effectiveness of the revision by comparing the average cosine similarity of the original and revised descriptions against all simulated queries:
Query: How many amphibian call count records are there in total? Top 1: Column Name
Number_Observed
Description
The total count of individual amphibians detected during a specific observation event as recorded.
Expected:
Not Top-Ranked Revision needed
Column Name
RecordID
Description
A unique identifier assigned to each record, ensuring each observation entry is distinguishable. Revise
Column Name
RecordID
Description
A unique identifier that distinguishes each record, enabling accurate tracking of all entries. This identifier is essential for counting the total number of records in the amphibian call count dataset.
M
1 X r(q (m) , d˜c ) M m=1
4
downstream retrieval behavior. The key idea is to simulate semantic retrieval and use the retrieval failures to guide refinement. Specifically, for each column we prompt the LLM to generate plausible user queries, perform vector search over all candidate columns using the generated descriptions, and detect cases where the intended column (the column used to generate the query) is not ranked first. In such cases, we gather the descriptions of the top competing columns together with the intended column and prompt the LLM to revise the intended column to make the description more distinctive and better aligned with the query. This process encourages the revised descriptions to reduce overlap among semantically similar columns and ultimately improves retrieval performance in downstream tasks, as shown in the experiment section (Section 6). More precisely, for each column c with description d˜c , we instruct the LLM to first generates M (default to be 3) plausible user queries {q (1) , · · · , q (M ) }. Each query q (m) is embedded and compared via cosine similarity against the embeddings of all candidate column descriptions, including the one-sentence overview, aliases, keywords, and proxy queries. We consider the case as a retrieval error if the highest-scoring description does not correspond to the intended column c, i.e., c
1 X r(q (m) , d̃′ c ). M m=1
The final description dc is set to d̃′ c only if it achieves a higher average similarity than the original d˜c . Otherwise, we retain the existing description. Prompts for both query generation and description revision are provided in Appendix 8.5.
Figure 3: An example of description revision. Aliases, keywords, and proxy user queries are revised as well, but are not shown for conciseness.
arg max r(q (m) , d˜c′ ) ̸= c, ′
M
vs.
Human-in-the-Loop Extension
This section considers how additional human input can be incorporated to improve name expansions. This serves as an initial demonstration, and a more comprehensive study of human-in-the-loop strategies is left to future work. The prompts mentioned in this section can be found in Appendix 8.6. 4.1
Identification of Expansions Requiring Human Verification
To automatically identify low-confidence expansions for human verification, we leverage an LLM as a judge. Given a table, its expanded table name, a column name, and a candidate column name expansion, we prompt the LLM to assess whether the expansion is likely to be correct in the table context and outputs a score on a 0 to 5 scale, where 0 indicates very unlikely and 5 indicates very likely to be correct. These scores are used to automatically flag low-confidence cases that need human verification. 4.2
Human-Revised Expansion Propagation
When human users provide verified expansions for specific table and column names, this feedback can be propagated to improve the quality of other expansions. To integrate such feedback at scale while avoiding LLM context-window limitations, we adopt a retrieval-based strategy. Specifically, for a target column, we retrieve two types of curated feedback: (i) verified expansions from other columns within the same table, and (ii) verified
(2)
where r(q, d) = ⟨ϕ(q), ϕ(d)⟩ is the cosine simi4
source
dataset
# tables
# columns
# queries
SNAILS
ASIS ATBI CWO KIS NPFM NTSB NYSED PILB SBOD∗
36 28 13 18 27 40 27 21 2,588
245 192 71 157 190 1,611 423 196 90,477
245 192 71 157 190 1,611 423 196 90,477
Retail Finance Tech Tech-H
669 88 127 127
5,241 1,291 10,227 10,227
2,102 735 6,470 78
Enterprise
tail, Finance, Tech, Tech-H that comes from different domains, where Tech and Tech-H use the same table schemas, while Tech-H has a harder set of queries. The table schemas come from the real customer data, and the gold query-column sets are generated by the data vendors. We evaluate on four proprietary enterprise datasets provided by a data vendor, namely Retail, Finance, Tech, and Tech-H, which span multiple domains. Tech and Tech-H share the same table schemas, while Tech-H contains a more challenging set of queries. The table schemas are derived from real customer data, and the gold query column annotations are generated by the data vendor.
Table 1: Statistics of the evaluation datasets. SBOD includes nine subdatasets (see Appendix 8). Tech and Tech-H share the same table inputs, while Tech-H contains more challenging queries.
6
We conduct extensive experiments across public and proprietary enterprise datasets to evaluate the effectiveness of TACO on semantic column retrieval. In addition, we conduct sensitivity analyses and ablation studies, and evaluate the effectiveness of the human-in-the-loop extension.
expansions from columns with the same name in other tables. These retrieved examples are then incorporated into the prompt to guide the LLM in revising candidate expansions.
5
Experiments
Evaluation Dataset
Experimental Setup and Metrics We use vector search as the primary downstream task to evaluate retrieval performance. Specifically, natural language queries are embedded and matched against vector representations formed by concatenating table_name.column_name with the column description, and performance is evaluated by the system’s ability to retrieve the intended columns. This setting reflects real-world scenarios where vector-based semantic retrieval serves as the core mechanism for schema grounding and data discovery. We use column retrieval performance to evaluate the contribution of description generation independently of other components in end-to-end tasks such as NL2SQL. We report Hit@K (H@K), which shows whether the correct column appears in the top K results.
We describe the evaluation sets for our experiments. Each dataset contains the table names, associated column names, and a set of gold query-column pairs. Dataset statistics are in Table 1. We focus on retrieving target columns referred to by natural language queries, which is a foundational step in NL2SQL, schema linking, and data discovery. Public Dataset We construct public evaluation datasets based on SNAILS (Luoma and Kumar, 2025), an NL2SQL benchmark that includes column names with varying levels of abbreviation and corresponding ground-truth name expansions. We create gold query-column pairs for keyword search as follows. For each table, we first use the gold expansions of the table and column names and prompt the LLM to generate a potential user query targeting that column. For example, given the table name emp_info and column name e_sal, the generated query would be “what is the average salary for the employee in the company?” We provide in-context examples drawn from the SNAILS gold natural language and SQL pairs as a reference to generate the queries. We then manually inspect and verify the correctness and soundness of the generated column-query pair.
Methods The most closely related work is by Wretblad et al. (2024), which uses a single prompt to directly generate column descriptions with an LLM. Several other studies on metadata generation (Zhang et al., 2025a; Gao and Luo, 2025; Singh et al., 2025; Anonymous, 2024) also rely on LLMgenerated column descriptions, but primarily treat them as an intermediate step for table-level description generation rather than as a standalone retrieval artifact. These approaches largely follow a promptonly paradigm similar to Wretblad et al. (2024).
Proprietary Dataset We use four enterprise datasets obtained from a data vendor, namely Re5
Accordingly, we use the method of Wretblad et al. (2024) as the representative baseline for promptonly column description generation. In addition, we introduce our own baseline, S2-only, which applies the prompt from Step 2 of our pipeline to directly generate column descriptions, without abbreviation expansion or description revision. In summary, the evaluated methods are as follows: SSCD (Wretblad et al., 2024): A LLM-based approach that generates column descriptions using a single prompt. S2-only: A simplified variant of TACO that applies Step 2 (description generation) only, without abbreviation expansion or description revision. TACO: The full TACO pipeline, including name expansion, description generation, and description revision. Note that no human-in-the-loop input is used unless otherwise stated in Section 6.4. We use GPT-4o for LLM-based generation with temperature set to 0 and all other parameters at their default values, and all-MiniLM-L12-v2 (Reimers and Gurevych, 2019) for embedding generation. 6.1
lines. All other models and parameters remain unchanged. Table 3 shows that TACO consistently outperforms other methods. Embedding Models We change the embedding model from all-MiniLM-L12-v2 to all-MiniLML6-v2, and keep the other setups the same. Table 4 shows that TACO outperforms the other baselines under a different embedding model. LLM Model We use another LLM model gpt4.1-mini, and compare the three methods. Table 5 shows the results of the three methods using a different LLM model and TACO consistently outperforms the other baselines. Hyperparameter V In the description revision section, we use the simulated vector search results from the competing top V columns and ask LLM to revise the descriptions. Currently, we use V = 30. In this section, we vary V to be different numbers and report the results. Figure 4 shows that TACO is robust to different values of V .
Retreival Performance 6.3
We compare TACO against SSCD and S2-only on the evaluation datasets constructed from SNAILS and proprietary enterprise data. We also include Raw Schema as a reference point, which performs retrieval by embedding only the concatenation of the table and column names (e.g., table_name.column_name). From Table 2, we can see that all three methods outputperform Raw Schema, which shows that LLM-generated descriptions are helpful in the downstream retrieval task. Moreover, TACO consistently outperforms SSCD across all experiments and metrics, by 3-38% absolute accuracy on H@1, 0-49% on H@5, and 0-52% on H@10, demonstrating more effective description generation. We further find that TACO performs substantially better than or comparable to S2-only, underscoring the benefits of column name expansion and description revision. 6.2
Ablation studies
To demonstrate the effectiveness of TACO’s components, we perform an ablation study by removing each component in turn and comparing it with the full pipeline. Table 6 shows the results obtained by removing the expansion module and the revision module. The results show that both modules contribute meaningfully to TACO’s performance. 6.4
Additional Human Input
We evaluate the impact of incorporating additional human input for column and table name expansions. We compare four strategies: (i) Random: We randomly select 10% of columns and provide their correct column and table name expansions. (ii) Score: We evaluates expansion correctness and select the 10% of column names with the highest uncertainty for human verification by an LLM. (iii) RandomRev: After randomly curating 10% of columns, we provide the human feedback to the LLM to revise the remaining column expansions. (iv) Score-Rev: After selecting column names based on uncertainty scores, we use the human-provided expansions to guide the LLM in revising the remaining column names. Figure 5 shows that random sampling and score-based sampling have similar performance, where the revising step helps both methods.
Sensitivity Analysis
We conduct a sensitivity analysis by varying the embedding method, embedding model, LLM model, and TACO hyperparameters. Due to the number of experiments and space limitations, we report results only on the first six public datasets. Embedding Method We only embed the column descriptions and compare TACO over the two base6
dataset H@1
Raw schema H@5 H@10
H@1
SSCD H@5 H@10
H@1
S2-only H@5 H@10
H@1
TACO (ours) H@5 H@10
ASIS ATBI CWO KIS NPFM NTSB NYSED PILB SBO
0.05 0.11 0.07 0.07 0.08 0.03 0.05 0.16 0.03
0.12 0.20 0.32 0.21 0.22 0.09 0.16 0.31 0.05
0.16 0.29 0.45 0.29 0.29 0.12 0.26 0.39 0.08
0.13 0.10 0.06 0.15 0.11 0.06 0.16 0.20 0.04
0.22 0.24 0.28 0.29 0.21 0.12 0.28 0.32 0.08
0.26 0.34 0.38 0.35 0.27 0.14 0.34 0.37 0.11
0.26 0.33 0.31 0.38 0.25 0.20 0.22 0.46 0.11
0.47 0.56 0.72 0.64 0.46 0.38 0.42 0.75 0.27
0.58 0.66 0.85 0.78 0.54 0.47 0.55 0.86 0.36
0.29 0.43 0.30 0.53 0.42 0.18 0.27 0.42 0.11
0.54 0.71 0.69 0.78 0.66 0.39 0.53 0.76 0.27
0.68 0.82 0.83 0.87 0.74 0.48 0.63 0.86 0.35
Retail Finance Tech Tech-H
0.38 0.52 0.40 0.29
0.57 0.72 0.54 0.58
0.65 0.79 0.60 0.60
0.41 0.48 0.32 0.29
0.66 0.72 0.49 0.53
0.74 0.80 0.56 0.59
0.35 0.58 0.42 0.56
0.53 0.77 0.61 0.73
0.60 0.82 0.66 0.76
0.44 0.62 0.42 0.53
0.66 0.79 0.57 0.72
0.74 0.82 0.61 0.76
Table 2: TACO versus baseline methods on retrieval performance.
H@1
V=10 V=20 V=30
H@5
0.75
H@10
0.2
0.25
0.0 ASIS ATBI CWO KIS NPFM NTSB
0.00 ASIS ATBI CWO KIS NPFM NTSB
0.75 0.50 0.25 0.00 ASIS ATBI CWO KIS NPFM NTSB
(a)
(b)
(c)
0.4
0.50
Figure 4: Retrieval performance as we vary V , the number of competing columns used for description revision. dataset
SSCD H@1 H@5
S2-only H@1 H@5
TACO H@1 H@5
dataset
SSCD H@1 H@5
S2-only H@1 H@5
TACO H@1 H@5
ASIS ATBI CWO KIS NPFM NTSB
0.13 0.08 0.08 0.15 0.08 0.06
0.27 0.38 0.28 0.37 0.27 0.22
0.33 0.40 0.28 0.54 0.38 0.20
ASIS ATBI CWO KIS NPFM NTSB
0.16 0.22 0.28 0.30 0.23 0.16
0.27 0.31 0.24 0.44 0.34 0.22
0.30 0.43 0.44 0.47 0.44 0.20
0.19 0.16 0.20 0.24 0.16 0.10
0.50 0.55 0.70 0.63 0.47 0.39
0.56 0.73 0.61 0.73 0.64 0.41
Table 3: Retrieval performance when we embed only the descriptions. dataset
SSCD H@1 H@5
S2-only H@1 H@5
TACO H@1 H@5
ASIS ATBI CWO KIS NPFM NTSB
0.14 0.12 0.07 0.17 0.11 0.07
0.27 0.34 0.28 0.36 0.25 0.23
0.31 0.41 0.34 0.47 0.41 0.18
0.24 0.24 0.28 0.27 0.23 0.11
0.51 0.56 0.69 0.66 0.44 0.42
0.52 0.58 0.62 0.72 0.59 0.39
0.60 0.73 0.73 0.78 0.72 0.42
Table 5: Retrieval performance using a different LLM. dataset
No-Exp H@1 H@5
No-Rev H@1 H@5
TACO H@1 H@5
ASIS ATBI CWO KIS NPFM NTSB
0.33 0.33 0.30 0.35 0.27 0.21
0.29 0.40 0.31 0.48 0.32 0.21
0.33 0.40 0.28 0.54 0.38 0.20
0.56 0.71 0.70 0.75 0.65 0.38
0.59 0.60 0.70 0.69 0.48 0.39
0.49 0.66 0.69 0.72 0.63 0.39
0.56 0.73 0.61 0.73 0.64 0.41
Table 6: Ablation study on TACO. No-Exp removes the expansion step, and No-Rev removes the revision step.
Table 4: Retieval performance when we use all-MiniLML6-v2 as the embedding model.
6.5
0.41 0.47 0.58 0.64 0.46 0.35
7
TACO for non-abbreviated column names
Related Work
Column Description Generation. Prior work has investigated generating natural language descriptions for table schemas. Wretblad et al. (2024) focus on column description generation using a single LLM prompt, evaluating performance on NL2SQL tasks and through human assessment. Several recent efforts extend this line to both column and table descriptions (Zhang et al., 2025a;
We also consider the setting where column names contain no abbreviations. Since abbreviation expansion is unnecessary, we remove Step 1 and directly apply description generation followed by the revision module. Table 7 reports results comparing three methods under this setting, where both column and table names have no abbreviations. TACO outperforms the other baselines by up to 7%. 7
(a)
(b)
(c)
Figure 5: Retrieval performance using different human-in-the-loop strategies. dataset
SSCD H@1 H@5
S2-only H@1 H@5
TACO H@1 H@5
ASIS ATBI CWO KIS NPFM NTSB
0.62 0.76 0.79 0.70 0.74 0.52
0.68 0.89 0.77 0.79 0.85 0.60
0.71 0.84 0.83 0.82 0.86 0.59
0.88 0.96 0.97 0.90 0.95 0.84
0.90 0.98 0.99 0.97 0.97 0.88
Table Understanding and Enrichment. Column name expansion is a special case of the broader challenge of table understanding (Wang et al., 2024; Nahid and Rafiei, 2024; Nguyen et al., 2025; Cheng et al., 2022) and enrichment. This includes enhancing data understanding (Fang et al., 2024), facilitating discovery (Freire et al., 2025; Kayali et al., 2023, 2024), and supporting reasoning tasks such as table-to-text generation (Zhao et al., 2023b,a; Kasner et al., 2023; Yang et al., 2022; Gong et al., 2019) and table question answering (Pal et al., 2023; Xie et al., 2022; Herzig et al., 2020). Another related area is semantic type inference, where systems classify columns into predefined categories such as zip code, address, or date (Deng et al., 2022; Feuer et al., 2024; Hulsebos et al., 2019; Suhara et al., 2021; Zhang et al., 2020; He et al., 2021; Hulsebos et al., 2023).
0.95 1.00 0.99 0.97 0.98 0.88
Table 7: Comparison on non-abbreviated names.
Anonymous, 2024; Singh et al., 2025; Zhang et al., 2025b; Tian et al., 2025; Gao and Luo, 2025). For example, Zhang et al. (2025a) generate table-level descriptions to support readability and search, with column descriptions serving as supporting context. Anonymous (2024) propose generating both table and column descriptions and employ an LLM-as-ajudge framework to identify high-quality outputs. Singh et al. (2025) generate descriptions for a proprietary dataset, assuming the availability of curated business glossaries; their approach handles abbreviations by aligning against these glossaries. Gao and Luo (2025) further scale the task to generate database-level descriptions. These works demonstrate the utility of schema descriptions, but they generally treat column names at face value and rely on either glossaries or single-prompt generation without addressing abbreviation-heavy realworld settings.
Other related tasks include schema matching and ontology alignment, where LLMs are leveraged to align columns across heterogeneous datasets or to external knowledge graphs (Lobo et al., 2023; Yang et al., 2025; Vandemoortele et al., 2024).
8
Conclusion
We presented TACO, a task-aware framework for column description generation that combines abbreviation expansion, schema-informed description generation, and revision to produce accurate and distinctive descriptions. Experiments show consistent improvements over baselines across multiple datasets, benefiting semantic retrieval tasks. Our work demonstrates the challenges posed by abbreviation-heavy schemas and the necessity of addressing them in practical systems. These contributions emphasize the importance of robust schema interpretation and open up future research directions, including the integration of cell-level information and domain-specific knowledge resources to further improve semantic understanding.
Abbreviation Expansion. NameGuess (Zhang et al., 2023a) has explicitly addressed abbreviated column names in tables, introducing a benchmark with synthetic abbreviations and showing that LLMs can outperform fine-tuned models in oneshot prompting. Columbo (Cai et al., 2025) improves upon NameGuess and introduces a more robust framework to solve column name expansion and evaluate their method over several new benchmarks. Follow-up work (Anonymous, 2025) explores generating more realistic abbreviations, Luoma and Kumar (2025) analyze how varying levels of abbreviation affect downstream tasks like NL2SQL without proposing an expansion method. 8
Limitations
Juliana Freire, Grace Fan, Benjamin Feuer, Christos Koutras, Yurong Liu, Eduardo Peña, Aécio S. R. Santos, Cláudio T. Silva, and Eden Wu. 2025. Large language models for data discovery and integration: Challenges and opportunities. IEEE Data Eng. Bull., 49(1):3–31.
Our evaluation dataset is not fully comprehensive, as queries generated for a given column may also be relevant to other semantically related columns. For instance, given a column name salary in the employee table, an LLM-generated query such as “what is the average salary for all employees?” could also pertain to related columns like base or stock that describe components of employee compensation. Constructing a truly complete dataset would therefore require substantial manual effort to capture such cross-column relationships. Nevertheless, to our knowledge no public benchmark currently exists for this task, and we release our dataset as an initial resource for the community, with plans to extend it into a more comprehensive benchmark in future work.
Yingqi Gao and Zhiling Luo. 2025. Automatic database description generation for text-to-sql. Preprint, arXiv:2502.20657. Heng Gong, Xiaocheng Feng, Bing Qin, and Ting Liu. 2019. Table-to-text generation with effective hierarchical encoder on three dimensions (row, column and time). In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), pages 3143–3152, Hong Kong, China. Association for Computational Linguistics. Yeye He, Jie Song, Yue Wang, Surajit Chaudhuri, Vishal Anil, Blake Lassiter, Yaron Goland, and Gaurav Malhotra. 2021. Auto-tag: Tagging-data-by-example in data lakes.
References
Jonathan Herzig, Pawel Krzysztof Nowak, Thomas Müller, Francesco Piccinno, and Julian Eisenschlos. 2020. TaPas: Weakly supervised table parsing via pre-training. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, pages 4320–4333, Online. Association for Computational Linguistics.
Anonymous. 2024. Tabmeta: Table metadata generation with LLM-curated dataset and LLM-judges. In Submitted to ACL Rolling Review - June 2024. Under review. Anonymous. 2025. Realistic training data generation and rule enhanced decoding in LLM for nameguess. In Submitted to ACL Rolling Review - December 2024. Under review.
Madelon Hulsebos, Paul Groth, and Çagatay Demiralp. 2023. Adatyper: Adaptive semantic column type detection.
Ting Cai, Stephen Sheen, and AnHai Doan. 2025. Columbo: Expanding abbreviated column names for tabular data using large language models. Preprint, arXiv:2508.09403.
Madelon Hulsebos, Kevin Zeng Hu, Michiel A. Bakker, Emanuel Zgraggen, Arvind Satyanarayan, Tim Kraska, Çagatay Demiralp, and César A. Hidalgo. 2019. Sherlock: A deep learning approach to semantic data type detection. In Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, KDD 2019, pages 1500–1508. ACM.
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 Proceedings of the 60th annual meeting of the association for computational linguistics (volume 1: long papers), pages 1094–1110.
Erin Illman and Paul Temple. 2019. California consumer privacy act. The Business Lawyer, 75(1):1637– 1646.
Xiang Deng, Huan Sun, Alyssa Lees, You Wu, and Cong Yu. 2022. TURL: table understanding through representation learning. SIGMOD Rec., 51(1):33–40.
Zdeněk Kasner, Ekaterina Garanina, Ondrej Platek, and Ondrej Dusek. 2023. TabGenie: A toolkit for tableto-text generation. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), pages 444–455, Toronto, Canada. Association for Computational Linguistics.
Xi Fang, Weijie Xu, Fiona Anting Tan, Jiani Zhang, Ziqing Hu, Yanjun Qi, Scott Nickleach, Diego Socolinsky, Srinivasan Sengamedu, and Christos Faloutsos. 2024. Large language models (llms) on tabular data: Prediction, generation, and understanding–a survey. arXiv preprint arXiv:2402.17944.
Moe Kayali, Anton Lykov, Ilias Fountalis, Nikolaos Vasiloglou, Dan Olteanu, and Dan Suciu. 2023. Chorus: foundation models for unified data discovery and exploration. arXiv preprint arXiv:2306.09610.
Benjamin Feuer, Yurong Liu, Chinmay Hegde, and Juliana Freire. 2024. Archetype: A novel framework for open-source column type annotation using large language models. Proc. VLDB Endow., 17(9):2279– 2292.
Moe Kayali, Fabian Wenz, Nesime Tatbul, and Çağatay Demiralp. 2024. Mind the data gap: Bridging
9
llms to enterprise data integration. arXiv preprint arXiv:2412.20331.
Yoshihiko Suhara, Jinfeng Li, Yuliang Li, Dan Zhang, Çagatay Demiralp, Chen Chen, and Wang-Chiew Tan. 2021. Annotating columns with pre-trained language models. CoRR, abs/2104.01785.
Wenqiang Lei, Weixin Wang, Zhixin Ma, Tian Gan, Wei Lu, Min-Yen Kan, and Tat-Seng Chua. 2020. Reexamining the role of schema linking in text-to-sql. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pages 6943–6954.
Yuan Tian, Jonathan K. Kummerfeld, Toby Jia-Jun Li, and Tianyi Zhang. 2024. Sqlucid: Grounding natural language database queries with interactive explanations. In Proceedings of the 37th Annual ACM Symposium on User Interface Software and Technology, UIST ’24, New York, NY, USA. Association for Computing Machinery.
Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Ruiying Geng, Nan Huo, and 1 others. 2024. Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls. Advances in Neural Information Processing Systems, 36.
Yuan Tian, Daniel Lee, Fei Wu, Tung Mai, Kun Qian, Siddhartha Sahai, Tianyi Zhang, and Yunyao Li. 2025. Text-to-sql domain adaptation via human-llm collaborative data annotation. In Proceedings of the 30th International Conference on Intelligent User Interfaces, IUI ’25, page 1398–1425, New York, NY, USA. Association for Computing Machinery.
Elita Lobo, Oktie Hassanzadeh, Nhan Pham, Nandana Mihindukulasooriya, Dharmashankar Subramanian, and Horst Samulowitz. 2023. Matching table metadata with business glossaries using large language models. arXiv preprint arXiv:2309.11506.
Yuan Tian, Zheng Zhang, Zheng Ning, Toby Jia-Jun Li, Jonathan K. Kummerfeld, and Tianyi Zhang. 2023. Interactive text-to-SQL generation via editable stepby-step explanations. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 16149–16166, Singapore. Association for Computational Linguistics.
Kyle Luoma and Arun Kumar. 2025. Snails: Schema naming assessments for improved llm-based sql inference. Proc. ACM Manag. Data, 3(1). Karime Maamari, Fadhil Abubaker, Daniel Jaroslawicz, and Amine Mhedhbi. 2024. The death of schema linking? text-to-sql in the age of well-reasoned language models. arXiv preprint arXiv:2408.07702.
Nathan Vandemoortele, Bram Steenwinckel, SV Hoecke, and Femke Ongenae. 2024. Scalable table-to-knowledge graph matching from metadata using llms.
Md Mahadi Hasan Nahid and Davood Rafiei. 2024. Tabsqlify: Enhancing reasoning capabilities of llms through table decomposition. arXiv preprint arXiv:2404.10150.
Zilong Wang, Hao Zhang, Chun-Liang Li, Julian Martin Eisenschlos, Vincent Perot, Zifeng Wang, Lesly Miculicich, Yasuhisa Fujii, Jingbo Shang, Chen-Yu Lee, and 1 others. 2024. Chain-of-table: Evolving tables in the reasoning chain for table understanding. arXiv preprint arXiv:2401.04398.
Thi-Nhung Nguyen, Hoang Ngo, Dinh Phung, ThuyTrang Vu, and Dat Quoc Nguyen. 2025. Improving table understanding with llms and entity-oriented search. arXiv preprint arXiv:2508.17028.
Niklas Wretblad, Oskar Holmström, Erik Larsson, Axel Wiksäter, Oscar Söderlund, Hjalmar Öhman, Ture Pontén, Martin Forsberg, Martin Sörme, and Fredrik Heintz. 2024. Synthetic sql column descriptions and their impact on text-to-sql performance. arXiv preprint arXiv:2408.04691.
Vaishali Pal, Andrew Yates, Evangelos Kanoulas, and Maarten de Rijke. 2023. MultiTabQA: Generating tabular answers for multi-table question answering. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 6322–6334, Toronto, Canada. Association for Computational Linguistics.
Nils Reimers and Iryna Gurevych. 2019. Sentence-bert: Sentence embeddings using siamese bert-networks. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics.
Tianbao Xie, Chen Henry Wu, Peng Shi, Ruiqi Zhong, Torsten Scholak, Michihiro Yasunaga, Chien-Sheng Wu, Ming Zhong, Pengcheng Yin, Sida I. Wang, Victor Zhong, Bailin Wang, Chengzu Li, Connor Boyle, Ansong Ni, Ziyu Yao, Dragomir Radev, Caiming Xiong, Lingpeng Kong, and 4 others. 2022. UnifiedSKG: Unifying and multi-tasking structured knowledge grounding with text-to-text language models. In Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing, pages 602– 631, Abu Dhabi, United Arab Emirates. Association for Computational Linguistics.
Mayank Singh, Abhijeet Kumar, Sasidhar Donaparthi, and Gayatri Karambelkar. 2025. Leveraging retrieval augmented generative llms for automated metadata description generation to enhance data catalogs. Preprint, arXiv:2503.09003.
Duo Yang, Ioannis Dasoulas, and Anastasia Dimou. 2025. Matching table metadata to knowledge graphs: A data augmentation perspective. In ELLIS workshop on Representation Learning and Generative Models for Structured Data.
Protection Regulation. 2016. Regulation (eu) 2016/679 of the european parliament and of the council. Regulation (eu), 679(2016):10–13.
10
Jingfeng Yang, Aditya Gupta, Shyam Upadhyay, Luheng He, Rahul Goel, and Shachi Paul. 2022. TableFormer: Robust transformer modeling for tabletext encoding. In Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 528–537, Dublin, Ireland. Association for Computational Linguistics.
dataset
# tables # columns # queries
Banking Business Partners Finance General Human Resources Inventory and Production Reports Sales Opportunities Service
Dan Zhang, Yoshihiko Suhara, Jinfeng Li, Madelon Hulsebos, Çagatay Demiralp, and Wang-Chiew Tan. 2020. Sato: Contextual semantic type detection in tables. Proc. VLDB Endow., 13(11):1835–1848.
40 40 61 71 28 65 40 20 40
1758 1456 1994 1053 455 1960 744 290 902
1758 1456 1994 1053 455 1960 744 290 902
Table 8: 9 datasets in SBOD
Haoxiang Zhang, Yurong Liu, Aécio Santos, Juliana Freire, and 1 others. 2025a. Autoddg: Automated dataset description generation using large language models. arXiv preprint arXiv:2502.01050. Jiani Zhang, Zhengyuan Shen, Balasubramaniam Srinivasan, Shen Wang, Huzefa Rangwala, and George Karypis. 2023a. NameGuess: Column name expansion for tabular data. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 13276–13290, Singapore. Association for Computational Linguistics.
dataset
TACO TACO+Table Desc H@1 H@5 H@10 H@1 H@5 H@10
ASIS ATBI CWO KIS NPFM NTSB
0.29 0.43 0.30 0.53 0.42 0.18
0.54 0.71 0.69 0.78 0.66 0.39
0.68 0.82 0.83 0.87 0.74 0.48
0.30 0.47 0.34 0.50 0.41 0.19
0.56 0.76 0.72 0.76 0.66 0.39
0.68 0.82 0.77 0.87 0.75 0.48
Table 9: add another module for table description before generating the column description
Tianshu Zhang, Kun Qian, Siddhartha Sahai, Yuan Tian, Shaddy Garg, Huan Sun, and Yunyao Li. 2025b. Evoschema: Towards text-to-sql robustness against schema evolution. Proc. VLDB Endow., 18(10):3655–3668.
Appendix 8.1
SNAILS SBOD dataset
Table 8 shows the details of the sub-datasets in the SBOD dataset from SNALS (Luoma and Kumar, 2025).
Yunjia Zhang, Avrilia Floratou, Joyce Cahoon, Subru Krishnan, Andreas C Müller, Dalitso Banda, Fotis Psallidas, and Jignesh M Patel. 2023b. Schema matching using pre-trained language models. In 2023 IEEE 39th International Conference on Data Engineering (ICDE), pages 1558–1571. IEEE.
8.2
Incorporating Table Description
To demonstrate that TACO is an extensible framework, we add a new module to generate table description before the step 2 (column description generation), and use the table description as the input for the column description as well. Table 9 shows the performance when we add the table description module to TACO.
Yilun Zhao, Zhenting Qi, Linyong Nan, Boyu Mi, Yixin Liu, Weijin Zou, SIMENG HAN, RUIZHE CHEN, Xiangru Tang, Yumo Xu, Dragomir Radev, and Arman Cohan. 2023a. QTSumm: Query-focused summarization over tabular data. In The 2023 Conference on Empirical Methods in Natural Language Processing.
8.3
Yilun Zhao, Haowei Zhang, Shengyun Si, Linyong Nan, Xiangru Tang, and Arman Cohan. 2023b. Investigating table-to-text generation capabilities of large language models in real-world information seeking scenarios. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing: Industry Track, pages 160–175.
Prompt of Table Name Expansion
Figure 6 shows the prompt for table name expansion. 8.4
Prompt of Column Description Generation
Figure 7 shows the prompt for column description generation. The {context} includes the randomly sampled column names from the same table. 8.5
Prompt of Column Description Revision
Figure 8 shows the prompt for the simulated query generation. Figure 9 shows the prompt to revise the generated descriptions based on simulated downstream tasks feedback. 11
Given the following information about a table in the {domain} area: Table Name: {table_name} Column Names: {column_names} Column Expansion (generated by LLM, may be wrong): {column_expansion} Can you expand the table name into full form English words or phrases? Follow the following rules when you expand: 1. do not add any extra information or explanation in your final expansion. 2. Do not mutate the numbers appear in the attribute names. 3. Keep the original orders of the attribute names. 4. If a token is already in full form, its expansion should be itself and do not paraphrase it. First anaylze the context of the table and explain your expansion of the table name. At last, output your answer in a JSON format where the key is the original table name and the value is the expanded table name.
Figure 6: Prompt for Table Name Expansion
You are a helpful assistant. Your task is to generate descriptions for attributes in the {domain} vertical. These descriptions aim to help downstream search engines to identify related attributes towards user queries. The attributes are all from the same table, the table has the following information: - table name: {table_name} - column names: {context} For each attribute, you will be provided with the attribute name. Your job is to generate a description for the attribute that is concise, informative, nonambiguous, relevant to the domain and help the downstream search engines to understand the attribute. 1. Moreover, you should also ensure that you do not directly paraphrase the original description nor simply explain the attribute. 2. You should try to describe the attribute name to make it more easily to be searched. 3. You should describe the attribute name in a whole and not just describe a single part. 4. Do not hallucinate or make up any ifnormation that is not in the attribute name, altdisplay, original_desc or expansion. Apart from the description, you should also try to generate the following information helpful for downstream search engines: 1. a list of keywords that are relevant to the attribute, separated by commas. 2. a list of synonyms that are relevant to the attribute, separated by commas. 3. a list of potential search queries that are relevant to the attribute, separated by commas. When you generate the keywords, synonyms and search queries, make sure 1. they are relevant to the attribute and the domain. 2. don't generate vague or generic keywords, synonyms or search queries. 3. make it very specific to the attribute and the domain. The attribute information is as follows: attribute_name: {column_name} Can you generate the description, keywords, synonyms and search queries for each of the attribute ? Please return the result in a JSON format. Also can you do a self revision: 1. first explain your understanding of the attribute and the task. 2. then generate the description, keywords, synonyms and search queries. 3. finally, pinpoint the drawbacks of your generated description, keywords, synonyms and search queries and revise them if necessary. 4. return the final result in a JSON format where the key is the column name (make sure it is in the exact format of the input column names), the value is a dictionary with keys being descriptions, keywords, synonyms, and search queries.
Figure 7: Prompt for column description generation
12
Given the examples below (each attribute is in table_name.column_name format), can you generate queries for my input attribute? You can generate 3 queries for each input attribute: attribute: tblFieldDataTurtleMeasurements.age query: How many five year old turtles were measured? attribute: tblFieldDataTurtleMeasurements.LocationlD query: How many turtles were measured at each location where turtles were measured? attribute: tblFieldDataTurtleMeasurements.Weight query: what is the average weight of all turtles? attribute: tblFieldDataSnakeDataCollection.SVL query: what is the highest snake snout-to-vent length recorded? attribute: tblFieldDataGreenCardObservations.Species_Code query: how many distinct species were documented on a reptile survey green card? attribute: tblFieldDataTurtleTrapSurveys.Trap_Type query: How many records are logged for each turtle trap type? attribute: tblFieldDataTurtleMeasurements.gravid query: how many turtle measurements were of turtles carrying eggs or young? Input attributes: {insert} Output in a JSON format where the keys are the attribute name and the values are the list of generated queries. The format should be: ### final result { "placeholder_attribute_name": [ "place_holder_query_ 1 ", "place_holder_query_2", "place_holder_query_3" ] }
Figure 8: Prompt for column query generation
Given the column name: {answer} (which is the correct column name for the following queries), when embed only on the LLM generated descripions of this column name and perform vector search, the correct column name is not returned as the first rank in the result. The actual description of the column is: {actual_description} Given the following results from the vector search: Query: {query} Rank of the column name: {rank} Top 30 vector search result: {result} 1. Can you explain in detail why the correct column is not rank the first in the returned results compared to other column's descriptions? 2. Can you focus on how to revise the description (together with the synonyms, keywords, search_queries) for the column '{answer}' so that its cosine similairty between the query increases and the vector search result is better? Provide the 3 most relevant synonyms, keywords and user queries. Return the revised enrichment as the same JSON format.
Figure 9: Prompt for description revision using results from simulated queries
13
8.6
Prompt of Human Input
Figure 10 shows the prompt for using LLM-as-ajudge to evaluate the column expansions from step 1. Figure 11 shows the prompt to re-generate the column expansions based on human input.
14
Given the following information about a table in the {domain} area: Table Name: {table_name} Table Expansion {generated by LLM, may be wrong): {table_expansion} Column Name and Column Expansion {expansions are generated by LLM, may be wrong): {column_name}: {column_expansion} Task: For the table name and each column name: 1. Assign a confidence score from O to 5 indicating how likely you think the provided expansion is correct, based on your knowledge and the information given: 0: Very likely incorrect; almost certainly wrong. 1: Likely incorrect; probably wrong, very little matches. 2: Possibly incorrect; some clues, but mostly doubtful. 3: Uncertain; about equally likely to be correct or incorrect. 4: Likely correct; mostly matches your understanding, but with minor doubts. 5: Almost certainly correct; matches standard usage, very high confidence. 2. Briefly explain your reasoning for the assigned score. Output the result in a JSON format, where the keys are the table name and the column names (keep them in the original format) and the value is a dictionary with the following keys 1. expansion: the provided expansion, 2. score: the ambiguity score, 3. reason: a short reason for the score
Figure 10: Prompt for LLM-as-a-judge for the column expansions
Given the following information about a table in the {domain} area: Table Name: {table_name} Table Expansion (generated by LLM, may be wrong): {table_expansion} Column Name and Column Expansion (expansions are generated by LLM, may be wrong): {column_name}: {column_expansion} Given the following user feedback, in the format of [ original_table_name.original_column_name, expanded_table_name.expanded_column_name ]: 1. user expansion from the same table: {user_feedback_from_the_same_table} 2. user expansion from other tables: {user_feedback_from_the_other_table} Please revise the table expansion and column expansions based on the user feedback. Return the revised table expansion and column expansions in the JSON format, where the keys are the original table name and column names (do not add table name in front of the column names in the keys) and the values are the revised expansions.
Figure 11: Prompt for re-generating column expansions based on retrieved human input expansions
15