Columbo: Expanding Abbreviated Column Names for Tabular Data Using Large Language Models (2025)

Abstract: Expanding the abbreviated column names of tables, such as “esal” to “employee salary”, is critical for many downstream NLP tasks for tabular data, such as NL2SQL, table QA, and keyword search. This problem arises in enterprises, domain sciences, government agencies, and more. In this paper, we make three contributions that significantly advance the state of the art. First, we show that the synthetic public data used by prior work has major limitations, and we introduce four new datasets in enterprise/science domains, with real-world abbreviations. Second, we show that accuracy measures used by prior work seriously undercount correct expansions, and we propose new synonym-aware measures that capture accuracy much more accurately. Finally, we develop Columbo, a powerful LLM-based solution that exploits context, rules, chain-of-thought reasoning, and token-level analysis. Extensive experiments show that Columbo significantly outperforms NameGuess, the current most advanced solution, by 4-29%, over five datasets. Columbo has been used in production on EDI, a major data lake for environmental sciences.

## introduction tabular data is ubiquitous in companies, domain sciences, government agencies, and others @xcite . using this data well, however, has been difficult. a major reason is that the names of the tables and columns are often abbreviated, appearing quite cryptic (see figure 1 and appendix a.1). this makes it hard for downstream nlp tasks to process the tables. in particular, a recent work @xcite ) shows that using abbreviated column names significantly reduce accuracy for three nlp tasks, nl2sql, schema-based relation detection, and table qa, by 10.54%, 40.5%, and 3.83%, respectively. that work also argues that expanding column names improves the readability of the tables, enables data integration, and improves keyword search (to discover relevant tables). another recent work @xcite shows that abbreviated column names significantly reduce the accuracy of nl2sql. our own experience working with a major data lake (edirepository.org) also shows that expanding column names improves the accuracy of keyword search, schema matching (i.e., finding columns that are semantically the same), and column annotation with the concepts in a given ontology (see "columbo in production" in the experiment section). thus, table/column name expansion is a core challenge for the fast growing direction of nlp tasks for tabular data, and has received growing attention @xcite @xcite @xcite . the goal is to expand table/column names into meaningful english phrases, such as "esal" to "employee salary", "edtph" into "employee day time phone", "1997lgnut-sext" into "1997 long-term nutrient study experiment", and so on. clearly, this can enormously help downstream applications. for example, given a user query "employee phone", a keyword search application can correctly return the table "emps(ename, esal, edtph, ...)" if it knows that "edtph" means "employee day time phone". as far as we can tell, the most advanced work for this challenge is nameguess in emnlp-2023 by amazon aws @xcite . that work focuses on column name expansion and frames it as a natural language generation problem. it proposes a solution that uses llms to obtain 69.3% exact-match accuracy (using gpt4), in contrast to 43.4% accuracy obtained by human. nameguess has clearly showed the promise of using llms to expand abbreviated column names. but it has three major limitations, as we discuss below. in this paper we describe columbo, which addresses these limitations and significantly advances the state of the art. first, nameguess experimented with just one dataset, which is public data from the cities of san francisco, chicago, and los angeles (a.k.a. open city data). we show later that llms achieve lower accuracy on enterprise data (coming from companies) and domain science data. thus, we believe that a good benchmark for column name expansion cannot contain just public data. in this work we introduce four more datasets that come from enterprises and domain sciences. another problem is that nameguess synthetically creates the abbreviated column names, e.g., by randomly dropping, shuffling, or replacing characters from english phrases. so many abbreviated column names in its dataset look "unrealistic", e.g., "r" for "area", "mmj" for "medical", and llms struggle to correctly expand such names. given that we do not yet have good methods to synthetically create abbreviated column names, we believe that a good benchmark for column name expansion should also contain abbreviated column names that come from real data. the four datasets introduced in this paper contain column names abbreviated by humans. later we show that llms indeed can leverage their vast knowledge about real-world abbreviation patterns to correctly expand these names. the second limitation is that nameguess computes accuracy in a restricted way. the most important accuracy measure, exact match, computes the fraction of columns where the name predicted by llms exactly matches the "gold" name. this penalizes cases of minor variations, e.g., "geography identifier" vs "geographical identifier", "photo credit" vs "picture credit", etc. to solve this, we introduce a new accuracy measure called "synonymaware exact match". we show that this new measure captures the performance of column name expansion solutions much more accurately. the third limitation is that nameguess uses a rather basic llm solution. it simply asks the llm to expand the names of the columns (given a few expansion examples). we have developed a significantly more powerful solution. our solution pro-vides a lot of context information to the llm, e.g., the name of the target table and the topics of similar tables (we infer these topics using llms). we ask the llm to follow a set of rules (that help generate the correct expansions) and use chain-of-thought reasoning. finally, we reason about column name expansion at the token level, i.e., we translate each column name into a sequence of tokens, expand each token into an english phrase, then combine the phrases to obtain the column name expansion. together, these features help our solution significantly improve accuracy compared to nameguess. in summary, we make the following contributions: columbo has been used in production on edi, a major data lake for environmental sciences. we briefly describe this experience in section 6. the code and datasets (except finance and university, for which we do not have permission to release) are available at github.com/anhaidgroup/columbo. ## problem definition similar to nameguess, given a set of tables (e.g., those in a data lake), we seek to expand the column names. expanding the table names is more complicated, as we discuss in section 6, and hence is deferred to future work. we assume that each column name c can be represented as a sequence t 1 d 1 . . . d n-1 t n , where each d i is a delimiter (i.e., a special character such as '_', '-', the space character, or the empty character) and each t i is a token that can be expanded into a meaningful english phrase e(t i ). phrase e(t i ) must contain all characters of token t i , in that order. for example, column name "esal" can be tokenized into tokens "e" and "sal", separated by the empty-character delimiter. token "e" expands to "employee" and token "sal" expands to "salary". other expansion examples are "rm" → "room" and "cd"→ "certificate deposit". the expansion e(c) of column c is then the concatenation of the expansions of its tokens. in many application contexts, we cannot access the data tuples of the tables, for reasons of privacy, compliance, performance, etc. @xcite . so here we consider the input to be just the (abbreviated) table names and column names. nameguess shows that state-of-the-art hosted llms such as gpt-4 achieves the highest accuracy for column name expansion @xcite . as a result, here we focus on these llms, specifically on gpt-4o. in future work we will consider open-source llms that can be deployed in-house. ## new datasets we now make the case that a good benchmark for column name expansion cannot contain just public data with synthetic abbreviations. it must also contain non-public data with real-world abbreviations. we then introduce four new such datasets. specifically, nameguess uses just one dataset obtained from the open data portals of san francisco, chicago, and los angeles, covering business, education, health, etc. to evaluate expansion solutions, nameguess needs both abbreviated column names and the gold (i.e., correct) expansions. to do this, nameguess uses heuristic rules to find column names that are meaningful english phrases. it abbreviates these names, e.g., by randomly shuffling, dropping, or replacing characters. finally, it applies solutions to the abbreviated names to see if they can recover the original column names. our experiments with the nameguess dataset revealed two problems. first, we found that llms achieve a much higher accuracy on this dataset compared to the four enterprise/science datasets (e.g., 81.5% vs 63.2-73.8% em accuracy, see to address this problem, in this paper we use the five datasets described in the second problem with the nameguess dataset is that it is difficult to accurately mimic human's abbreviation patterns. thus, many synthetic abbreviated column names look "unrealistic", and llms struggle to expand these. ## new accuracy measures nameguess uses three accuracy measures. em computes the fraction of columns where the predicted expansion x exactly matches the gold expansion g. word-level f 1 is 2p r/(p + r), where p is the fraction of tokens in x that occur in g, and r is the fraction of tokens in g that occur in x. bert-score f 1 is computed similarly, except that two tokens are considered equivalent if the cosine similarity score of their bert-based embedding vectors is high @xcite . among these three measures, em is most intuitive, but as defined, it is too restrictive. it regards cases of minor variations, e.g., "geography location" vs "geographical location", "picture credit" vs "photo credit", as not matched. to address this problem, we examined the five datasets described in section 3, and created synonym pairs, e.g., "geography" = "geographical", "picture" = "photo". given a gold expansion g, we use these synonym pairs to create all gold variations, e.g., one may wonder if the bert-based f 1 score captures ideas similar to the synonym-based em approach. we found that this is not the case, because there are many synonyms that are very specific to a particular vertical. being trained mostly on public data, bert is not aware of such synonyms. examples include "time 0" vs "initial", "site" vs "hub", "log" vs "logarithm", "met" vs "meteorological" in edi, "prime" vs "principal" in university, and "sedol" vs "stock exchange daily official list" in finance. ## the columbo solution we now describe the columbo solution, which improves upon nameguess. given a table t , nameguess sends batches of 10 column names from t to the llm. it provides several examples of column name expansion, e.g., "c_name"→ "customer name", then asks the llm to expand the above 10 column names. nameguess does not exploit any additional information, e.g., the table name. in contrast, columbo exploits the names of table t and related tables, rules, chain-of-thought reasoning, token-level analysis, and more. specifically, the key insight behind columbo is that, to solve this problem well, we should use all available information and reason at a deeper level. consequently, we use llms because to expand a column name correctly, we need a lot of domain knowledge. llms have been trained on tons of data and can be viewed as very large stores of domain knowledge. so applying llms to this problem is promising. second, we observed that when expanding column names, llms keep making similar mistakes. this is why we formulate a set of general rules (in the prompt) telling llms not to make these mistakes. third, we observed that there is a well-known chain-of-thought (cot) process that a human typically follows to expand a column name: first expand each token, then combine these token-level expansions to obtain the columnlevel expansion. this suggests that cot can be well matched to this problem. finally, we perform token-level analysis by identifying tokens with potentially incorrect expansion rules and fixing those. figure 2 describes the columbo architecture, which consists of 3 modules: summarizer, generator, and reviser. we now describe these modules, then discuss the rationales behind the design decisions. the summarizer: this module creates two kinds of summaries to be used by subsequent modules (see lines 1-8 of the algorithm in figure 3 ). let s be the set of table schemas for which we want to expand the column names. we first send batches of k table schemas from s to the llm, and ask it to cluster the k tables into groups (currently @xmath0. for each group g, we ask the llm to provide a group summary d g , which is a short english phrase that best summarizes g, and similarly, for each table t in group g, we also ask for a table summary d t that best summarizes t . appendix a.3 shows the prompt for a sample batch and the output of the llm. for example, it shows that 3 tables businessentity(moddate, bid,rid), businessentityaddress(moddate, aid, atypeid, bid, rid), businessentitycontact(moddate, personid, bid, ctypeid, rid) have been clustered into a group, with group summary "business entity structure", and that table businessentity(moddate, bid,rid) has the summary "represents a generic business entity that can be a person, vendor, or customer". after processing all tables in s (via batches of up to k tables), we perform a "global merge" that merges all groups with the same summary. thus, the summarizer produces a clustering of all input tables into groups, where each group g has a summary d g , and each table t has a summary d t . the generator: this module expands the column names (see lines 9-14 of the algorithm in figure 3 ). specifically, for each table t (in the set s), we send batches of p columns of t to the llm, and ask it to expand the p column names (currently @xmath1. we structure the llm prompt for each batch as follows. first, we provide the context, which is the name of table t , as well as the names and table summaries of up to q tables (randomly sampled) from the same group as t (currently @xmath2. second, we specify a set of rules, e.g., "expand all abbreviations in a column name", "do not expand numbers", "do not add extra words or explanations", etc. finally, unlike nameguess which just asks the llm for the expansion e(c) of a given column name c, we ask the llm to provide a chainof-thought reasoning that leads to the expansion. specifically, we ask the llm to parse column name c into a sequence of tokens, then provide the expansion for each token, then concatenate these expansions into e(c). we provide a few examples of such reasoning in the prompt. thus, for each input column name c, this module produces a sequence of tokens t 1 . . . t n , and expansion rules for the tokens: t 1 → e 1 , . . . , t @xmath3. we call this output the e2 record for column c (where "e2" stands for "expansion & explanation"). the expansion of c is then the string e 1 . . . e n . appendix a.4 shows the prompt for a sample set of columns and the output of the llm. the reviser: this module improves upon the output of the generator, by identifying tokens with potentially incorrect expansion rules, then trying to fix those (see lines 15-20 of the algorithm in figure 3 ). specifically, we first process the e2 records (output by the generator) to identify the set p of all tokens that have more than one expansion rule, e.g., @xmath4. next, for each token @xmath5, we ask the llm if x should have just one expansion rule, and if so, to identify that rule. to help the llm make the above decisions, we provide it with the summaries of all groups, and all expansion rules of token x (that we have identified from the e2 records). for each expansion rule of x, we also provide its frequency (i.e., the number of column names in which that expansion rule is used), and a sample table schema in which that expansion rule is used. we optimize the above process by using a set of rules to decide which tokens in p to send to the llm. for example, if a token @xmath6, then we do not send x to the llm, because it is likely that x has more than one correct expansion, e.g., @xmath7. suppose the llm has identified a set q of pairs (x, e), where token x should always be expanded into e. then we use q to modify the e2 records (produced by the generator). the reviser outputs the modified e2 records as final records, and the expansions of the column names can be quickly obtained from these e2 records. appendix a.5 shows the prompt for a sample token and the output of the llm. discussion: we now discuss the rationales behind the major design decisions. consider the generator. this module asks the llm to perform chainof-thought reasoning in which it translates the column name into a sequence of tokens, then finds the expansion of each token. we found that this improves the llm's accuracy. further, this gives us the tokens and their expansion rules, which enable token-level analysis, such as the one carried out by the reviser. we also found that just supplying examples of column name expansion was not enough. llms were still prone to producing incorrect output, e.g., adding extra words, explanations, changing word orders, etc. adding rules asking the llm not to do so helps improve accuracy (see the experiments). intuitively, providing context can help expand column names. for example, the llm may incorrectly expand column russ_cd to "russian code". but being told this column is in table rus-sell_index, it can correctly expand the column to "russell code". so we provide the llm with the name of the target table t . we also cluster all the input tables so that we can find the tables related to t , and provide a subset of these tables to the llm, as additional context. to provide this subset of tables, we can just send their schemas to the llm. but it turns out that many of these tables can have a large number of columns (e.g., 200+), making their schemas too large. this is why in the summarizer we ask the llm to provide for each table a short table summary. then instead of sending the full table schema, we just send the (shorter) table name and summary. now consider the reviser. if we can provide the llm with information about the entire dataset, i.e., the entire set of table schemas s, it can more accurately decide if a token x has just one expansion in s (e.g., russ should always be expanded to "russell"). but sending all table schemas in s to the llm is impractical. so in the summarizer we ask the llm to provide a short group summary for each group of tables, then send the llm just the summaries of all groups. ## experiments we now evaluate columbo, using the five datasets described in overall performance: second, nameguess achieves lower em accuracies on the enterprise (finance, university, aw) and science (edi) datasets, compared to the public (ng) dataset: 63.2-73.8% vs 81.5%. this suggests that llms perform worse on non-public data (prior work @xcite has reached the same conclusion). finally, columbo is able to improve the em accuracy of nameguess on the non-public datasets by a large amount, from 63.2-73.8% to 87.6-93.3%, but it "struggles" to improve the em accuracy of nameguess on the public dataset ng, from 81.5% to just 85.2%. we believe this is because many column names in ng look "unrealistic", as they are synthetically abbreviated (as we discussed in section 4). so the llm fails to expand many such columns, resulting in a small em improvement. overall, the results in ## conclusion expanding the abbreviated column names for tabular data is critical for many downstream nlp tasks. in this paper we have significantly advanced the state of the art for this problem. first, we showed that synthetic public data used by prior work is not sufficient for experiments, and we introduced four new datasets in enterprise/science domains, with real-world abbreviations. second, we showed that accuracy measures used by prior work undercount correct expansions, and we proposed new synonymaware measures that capture accuracy much more accurately. finally, we developed columbo, a powerful llm-based solution, and described extensive experiments, which show that columbo outperforms prior work by 4-29% accuracy on five datasets. for future work we will explore improving columbo, exploiting data tuples where available, using in-house llms, and developing solutions to expand abbreviated table names.