SlowGuess/NeurIPS_2023_OCR huggingface dataset:
There is great variability in the improvement size depending on whether (1) a problem is amenable to feature engineering, i.e. is there a mapping of features that explains the data better and that can be expressed through simple code; and (2) the quality of the dataset description (e.g., the balance-scale dataset contains an accurate description of how the dataset was constructed). Per dataset performance can be found in Table 1. CAAFE takes 4:43 minutes to run on each dataset,  $90\%$  of the time is spent on the LLM's code generation and  $10\%$  on the evaluation of the generated features. In Appendix F we plot the performance, time and cost of CAAFE across feature engineering iterations, showing the tradeoff between these parameters. For the 14 datasets, 5 splits and 10 CAAFE iterations, CAAFE generates 52 faulty features  $(7.4\%)$  in the generation stage, from which it recovers (see Figure 3).
Incorporating Classical AutoFE Methods Classical AutoFE methods can readily be combined with our method, one simply runs CAAFE first and then lets a classical AutoFE method find further feature extensions, as we did in Table 2. For less powerful downstream classifiers, namely Logistic Regression and Random Forests, we observe that applying AutoFE additionally to CAAFE improves performance further. The AutoML method TabPFN on the other hand is not improved by applying the evaluated AutoFE methods. This discrepancy might stem from the larger hypothesis space (complexity) of TabPFN, it can get all necessary information from the data directly. For all combinations of classifiers and additional AutoFE methods, we can see that CAAFE improves performance on average.
Our study presents a novel approach to integrating domain knowledge into the AutoML process through Context-Aware Automated Feature Engineering (CAAFE). By leveraging the power of large language models, CAAFE automates feature engineering for tabular datasets, generating semantically meaningful features and explanations of their utility. Our evaluation demonstrates the effectiveness of this approach, which complements existing automated feature engineering and AutoML methods.
This work emphasizes the importance of context-aware solutions in achieving robust outcomes. We expect that LLMs will also be useful for automating other aspects of the data science pipeline, such as data collection, processing, model building, and deployment. As large language models continue to improve, it is expected that the effectiveness of CAAFE will also increase.
Dataset descriptions play a critical role in our method; however, in our study, they were derived solely from web-crawled text associated with public datasets. If users were to provide more accurate and detailed descriptions, the effectiveness of our approach could be significantly improved.
However, our current approach has some limitations. Handling datasets with a large number of features can lead to very large prompts, which can be challenging for LLMs to process effectively. The testing procedure for adding features is not based on statistical tests, and could be improved using techniques of previous feature engineering works. LLMs, at times, exhibit a phenomenon known as "hallucinations.", where models produce inaccurate or invented information. Within CAAFE, this might result in the generation of features and associated explanations that appear significant and are logically presented, even though they may not be grounded in reality. Such behavior can be problematic, especially when individuals place trust in these systems for essential decision-making or research tasks. Finally, the usage of LLMs in automated data analysis comes with a set of societal and ethical challenges. Please see Section B for a discussion on the broader impact and ethical considerations.
Future research may explore prompt tuning, fine-tuning language models, and automatically incorporating domain-knowledge into models in other ways. Also, there may lie greater value in the interaction of human users with such automated methods, also termed human-in-the-loop AutoML (Lee & Macke, 2020), where human and algorithm interact continuously. This would be particularly easy with a setup similar to CAAFE, as the input and output of the LLM are interpretable and easily modified by experts.
GPT-4 (OpenAI, 2023a) was used in the following ways: to help us iterate on LaTeX formatting and diagram plotting; for text summarization; and as a copyediting tool; for rephrasing proposals.
B Broader Impact Statement
B.1 Social Impact of Automation
The broader implications of our research may contribute to the automation of data science tasks, potentially displacing workers in the field. However, CAAFE crucially depends on the users inputs for feature generation and processing and provides an example of human-in-the-loop AutoML. The automation of routine tasks could free up data scientists to focus on higher-level problem-solving and decision-making activities. It is essential for stakeholders to be aware of these potential consequences, and to consider strategies for workforce education and adaptation to ensure a smooth transition as AI technologies continue to evolve.
B.2 Replication of Biases
AI algorithms have been observed to replicate and perpetuate biases observed in their training data distribution. CAAFE leverages GPT-4, which has been trained on web crawled data that contains existing social biases and generated features may be biased on these biases. An example study of such biases in web-crawled data was done by Prabhu & Birhane (2020). When data that contains demographic information or other data that can potentially be used to discriminate against groups, we advise not to use CAAFE or to proceed with great caution, double checking the generated features.
We would like to mention the best practice studies on fairness for AutoML by Weerts et al. (2023) and on bias in the use of LLMs by Talboy & Fuller (2023).
Weerts et al. (2023) give recommendations for what AutoML developers can do to improve fairness-conscious AutoML, and we follow the three most emphasized closely. i) We clearly emphasize the limitations and biases of our method. ii) We emphasize the 'Usefulness' comment that our prompt asks the LLM to write into our UI to "help users identify sources of fairness-related harm", as Weerts et al. (2023) write. iii) We execute code only after asking the user for explicit confirmation that it does not contain dangerous actions or biases; these kinds of design decisions are called "seam-full design" by (Weerts et al., 2023).
(Talboy & Fuller, 2023) give recommendations on how to best use LLMs. Their recommendation, which we as interface developers can more easily follow, is the one they emphasize the most. Namely, that "LLMs [...] should be used as decision support tools, not final decision makers. We follow this closely by not allowing the LLM to execute code without the user's explicit consent.
The choice of benchmarks can also introduce dangerous biases in machine learning methods, as there are only a few that dominate the landscape (Raji et al., 2021). We address this problem by using datasets from two different sources (Kaggle and OpenML). In addition, we use multiple datasets from each source.
How Can Biases Arise in CAAFE? Since we are using a trained model (the LLM) to define the training setup (features used) of a downstream classifier trained on potentially biased data, we can have bias at three levels: i) at the level of the LLM, and ii) at the level of the generated features, ii) at the level of the downstream classifier.
The level of the downstream classifier is affected by the previous two levels, but is not directly affected by CAAFE, so we do not discuss it in detail. Here, as in any data science application, the user must be careful to use unbiased data. The way we set up CAAFE has some robustness against biases in the first two steps, which are controlled by CAAFE:
i) We use GPT-4, where great care has been taken to mitigate biases – still it does contain biases in its generations. We add a statement that choosing a language model that is trained to mitigate biases is a crucial step for the user to tackle this problem.
ii) Feature engineering operations by the LLM are only retained if they lead to improvements in cross-validation, due to the way our method is set up (we generate code and verify that it improves performance at each step). This gives us a slightly better defense against bias than using the LLM outputs directly, since biases that are present in the LLM but not in the data are discarded.
However, since the biases of the LLM and the dataset are most likely not independent, there is still a risk that the two will be aligned. To illustrate this risk and make users aware of potential problems, we include an illustrative Example (see end of this reply).
Simple Example We have built a fake dataset that has only one feature, a person's name, and as output we want to predict whether the person is a doctor or a nurse. The description of the dataset used in our challenge is
Doctor-or-Nurse is a dataset that asks to predict whether a person is a doctor or a nurse just based on their name.  
The intentionally biased sample of the dataset shown to the LLM in the prompt is Columns in 'df' (true feature dtypes listed here, categoricals encoded as int): Name (object): NaN-freq [0.0%], Samples ['Anna', 'Jack', 'Frank', 'Laura', 'Travis', 'Sophia']  
is_doctor (int): NaN-freq [0.0%], Samples [0, 1, 1, 0, 1, 0]
In all cases in this sample a name commonly associated with male gender is associated with a doctor. Additionally, we only used female names ending in an "a".
We can see that GPT-4 tends to suggest an attribute that uses the typically gender-associated ending of the name to classify, i.e. it generates the following output
Listing 1: CAAFE output
Feature: end_with_a
# Usefulness: Names ending with "a" might be more common in females. Assuming there might be a gender bias in the doctor or nurse profession, this could provide some useful information.
# Input samples: ['Anna', 'Jack', 'Frank']
df['end_with_a'] = df['Name'].str.endsWith('a').astype(int)
We can see that our prompt actually makes it very easy to detect the bias of the LLM in this case, since the 'Usefulness' comment the LLM is asked to provide, at least in this non-cherry-picked example, just gives away its bias.
B.3 AI Model Interpretability
As the adoption of advanced AI methods grows, it becomes increasingly important to comprehend and interpret their results. Our approach aims to enhance interpretability by providing clear explanations of model outputs and generating simple code, thus making the automated feature engineering process more transparent.
B.4 Risk of increasing AI capabilities
We do not believe this research affects the general capabilities of LLMs but rather demonstrates their application. As such we estimate our work does not contribute to the risk of increasing AI capabilities.
Code release In an effort to ensure reproducibility, we release code to reproduce our experiments at https://github.com/automl/CAAFE We release a minimal demo at a simple demo.
Availability of datasets All datasets used in our experiments are freely available at OpenML.org (Vanschoren et al., 2014) or at kaggle.com, with downloading procedures included in the submission.
D Full LLM Prompt
Figure 5 shows the full prompt for one exemplary dataset. The generated prompts are in our repository: https://github.com/automl/CAAFE/tree/main/data/generated_code.
Figure 5: Full LLM Prompt for the CMC dataset. The generated code will be the reply to this prompt.
E.1 Semantic Blinding
Semantic information, i.e. the context of the dataset and its columns, is crucial and can only be captured through laborious human work or our novel approach of using LLMs - this is the core of our approach. To further verify and quantify this claim, we perform an experiment where the context of the dataset is left out (i.e. feature names and dataset description are not given to the LLM). We find a strong drop in performance from an average AUROC of 0.822 to 0.8 over all datasets for GPT-4.
Table 4: CAAFE with semantic and without "Semantic Blinding". For "Semantic Blinding" feature names and the dataset description is concealed to CAAFE. Mean ROC AUC and average rank (ROC AUC) per downstream classification method and feature extension method is shown. Best performing AutoFE method per classifier is shown in bild. The features generated by CAAFE are chosen with TabPFN as classifier. Ranks are calculated across all classifiers and feature engineering methods.
No FE	GPT-3.5 Semantic Blinding	Default	GPT-4 Semantic Blinding	Default
Log. Reg.	Mean	0.749	0.754	0.763	0.749	0.769
Mean Rank	19.6	19.1	17.8	19.3	17.4
Random Forest	Mean	0.782	0.789	0.79	0.783	0.803
Mean Rank	17.2	16.5	16.8	16.5	14.6
ASKL2	Mean	0.807	0.812	0.815	0.809	0.818
Mean Rank	9.17	9.29	8.16	8.88	8.59
Autogluon	Mean	0.796	0.803	0.803	0.801	0.812
Mean Rank	12.9	12.2	11.6	12.7	10.3
TabPFN	Mean	0.798	0.807	0.806	0.8	0.822
Mean Rank	10.5	9.33	9.71	9.33	7.59
E.2 Per Dataset Results
Table 5: ROC AUC OVO results per dataset and downstream classification method. CAAFE optimized for strong performance on TabPFN.
AutoFE-Base	CAAFE	AutoFE-Base + CAAFE
AutoFeat	DFS	GPT-3.5	GPT-4	GPT-4 + AF	GPT-4 + DFS
airlines	0.6211 ±.04	0.6076 ±.04	0.595 ±.04	0.619 ±.04	0.6203 ±.04	0.602 ±.04	0.5966 ±.04
balance-scale	0.8444 ±.29	0.8438 ±.30	0.8428 ±.31	0.844 ±.31	0.882 ±.26	0.8812 ±.27	0.8773 ±.27
breast-w	0.9783 ±.02	0.9713 ±.03	0.9783 ±.02	0.9809 ±.02	0.9809 ±.02	0.9713 ±.03	0.9809 ±.02
cmc	0.7375 ±.02	0.7384 ±.02	0.7349 ±.02	0.7383 ±.02	0.7393 ±.02	0.7386 ±.02	0.7362 ±.02
credit-g	0.7824 ±.03	0.7819 ±.03	0.7824 ±.03	0.7824 ±.03	0.7832 ±.03	0.784 ±.03	0.7824 ±.03
diabetes	0.8427 ±.03	0.8414 ±.03	0.8417 ±.03	0.8434 ±.03	0.8425 ±.03	0.8432 ±.03	0.8382 ±.03
eucalyptus	0.9319 ±.01	0.9321 ±.01	0.9319 ±.01	0.9317 ±.01	0.9319 ±.00	0.9323 ±.01	0.9319 ±.01
jungle_chess..	0.9334 ±.01	0.9197 ±.01	0.9284 ±.01	0.9361 ±.01	0.9453 ±.01	0.9535 ±.01	0.94 ±.01
⟨Kaggle⟩health-insurance	0.5745 ±.02	0.5805 ±.03	0.5753 ±.02	0.5745 ±.02	0.5748 ±.02	0.5777 ±.03	0.5782 ±.03
⟨Kaggle⟩pharyngitis	0.6976 ±.03	0.6976 ±.03	0.6976 ±.03	0.6976 ±.03	0.7078 ±.04	0.7073 ±.04	0.6976 ±.03
⟨Kaggle⟩kidney-stone	0.7883 ±.04	0.7856 ±.04	0.7929 ±.04	0.7873 ±.04	0.7903 ±.04	0.7875 ±.04	0.7967 ±.03
⟨Kaggle⟩spaceship-titanic	0.838 ±.02	0.8486 ±.02	0.8443 ±.02	0.8383 ±.02	0.8405 ±.02	0.853 ±.02	0.8486 ±.02
pc1	0.9035 ±.01	0.9046 ±.01	0.9035 ±.01	0.9087 ±.02	0.9093 ±.01	0.908 ±.01	0.9035 ±.01
tic-tac-toe	0.6989 ±.08	0.6989 ±.08	0.6291 ±.10	0.6989 ±.08	0.9536 ±.06	0.9536 ±.06	0.938 ±.06
E.3 Generated Prompts and Code
You can find the generated prompts and the respective LLM generated code in our repository: https://github.com/cafeautomatedfeatures/CAFE/tree/main/datagenerated_code.
F Compute
Figure 6: Mean ROC AUC OVO, inference cost for GPT and time spent with an increasing number of feature generation runs.
Figure F illustrates the increasing performance but also cost and time spent for more feature engineering iterations. Prediction for LLMs is done per token and so the generation of code takes dominates the 4:43 minutes evaluation time of CAAFE on average per dataset. For GPT-3.5 this time is reduced to about 1/4. Also for GPT-3.5 the cost is reduced to 1/10 as of the writing of this paper. For the evaluation of TabPFN we use one Nvidia RTX 2080 Ti as well as 8 Intel(R) Xeon(R) Gold 6242 CPU @ 2.80GHz CPU cores.
G Datasets
Name	# Features	# Samples	# Classes	OpenGL ID / Kaggle Name
balance-scale	4	125	3	11
breast-w	9	69	2	15
cmc	9	1473	3	23
credit-g	20	1000	2	31
diabetes	8	768	2	37
tic-tac-toe	9	95	2	50
eucalyptus	19	736	5	188
pc1	21	1109	2	1068
airlines	7	2000	2	1169
jungle_chess_2pcs_raw_endgamecomplete	6	2000	3	41027
pharyngitis	19	512	2	pharyngitis
health-insurance	13	2000	2	health-insurance-lead-prediction-raw-data
spaceship-titanic	13	2000	2	spaceship-titanic
kidney-stone	7	414	2	playground-series-s3e12
Table 6: Test datasets used for the evaluation. See Section 4 for a description of the datasets used.
G.1 Dataset Collection and Preprocessing
OpenML datasets We use small datasets from OpenGL (Vanschoren et al., 2013; Feurer et al.) that have descriptive feature names (i.e. we do not include any datasets with numbered feature names). Datasets on OpenGL contain a task description that we provide as user context to our method and that we clean from redundant information for feature engineering, such as author names or release history. While some descriptions are very informative, other descriptions contain much less information. We remove datasets with more than 20 features, since the prompt length rises linearly with the number
of features and exceeds the permissible 8,192 tokens that standard GPT-4 can accept. We show all datasets we used in Table 6 in Appendix G. When datasets are perfectly solvable with TabPFN alone (i.e. reaches ROC AUC of 1.0) we reduce the training set size for that dataset to  $10\%$  or  $20\%$  of the original dataset size. This is the case for the datasets "balance-scale"  $(20\%)$ , "breast-w"  $(10\%)$  and "tic-tac-toe"  $(10\%)$ . We focus on small datasets with up to 2000 samples in total, because feature engineering is most important and significant for smaller datasets.
Kaggle datasets We additionally evaluate CAAFE on 4 datasets from Kaggle that were released after the knowledge cutoff of our LLM Model. These datasets contain string features as well. String features allow for more complex feature transformations, such as separating Names into First and Last Names, which allows grouping families. We drop rows that contain missing values for our evaluations. Details of these datasets can also be found in Table 6 in Appendix G.
G.2 Dataset Descriptions
The dataset descriptions used were crawled from the respective datasource. For OpenML prompts uninformative information such as the source or reference papers were removed. Figures 20 show the parsed dataset descriptions used for each dataset.
**Balance Scale Weight & Distance Database**
This data set was generated to model psychological experimental results. Each example is classified as having the balance scale tip to the right, tip to the left, or be balanced. The attributes are the left weight, the left distance, the right weight, and the right distance. The correct way to find the class is the greater of (left-distance * left-weight) and (right-distance * right-weight). If they are equal, it is balanced.
Attribute description
The attributes are the left weight, the left distance, the right weight, and the right distance.
Figure 7: Dataset description for balance-scale.
**Breast Cancer Wisconsin (Original) Data Set.** Features are computed from a digitized image of a fine needle aspirate (FNA) of a breast mass. They describe characteristics of the cell nuclei present in the image. The target feature records the prognosis (malignant or benign).
Figure 8: Dataset description for breast-w.
7. Attribute Information:
4. Relevant Information: This dataset is a subset of the 1987 National Indonesia Contraceptive Prevalence Survey. The samples are married women who were either not pregnant or do not know if they were at the time of interview. The problem is to predict the current contraceptive method choice (no use, long-term methods, or short-term methods) of a woman based on her demographic and socio-economic characteristics.
1. Wife's age (numerical)  
2. Wife's education (categorical) 1=low, 2, 3, 4=high  
3. Husband's education (categorical) 1=low, 2, 3, 4=high  
4. Number of children ever born (numerical)  
5. Wife's religion (binary) 0=Non-Islam, 1=Islam  
6. Wife's now working? (binary) 0=Yes, 1=No  
7. Husband's occupation (categorical) 1, 2, 3, 4  
8. Standard-of-living index (categorical) 1=low, 2, 3, 4=high  
9. Media exposure (binary) 0=Good, 1=Not good  
10. Contraceptive method used (class attribute) 1=No-use  
2=Long-term  
3=Short-term
Figure 9: Dataset description for cmc.
**German Credit dataset**
This dataset classifies people described by a set of attributes as good or bad credit risks.
This dataset comes with a cost matrix:
```
Good Bad (predicted)
Good 0 1 (actual)
Bad 5 0
```
It is worse to class a customer as good when they are bad (5), than it is to class a customer as bad when they are good (1).
Attribute description
1. Status of existing checking account, in Deutsche Mark.
2. Duration in months
3. Credit history (credits taken, paid back duly, delays, critical accounts)
4. Purpose of the credit (car, television,...)
5. Credit amount
6. Status of savings account/bonds, in Deutsche Mark.
7. Present employment, in number of years.
8. Installment rate in percentage of disposable income
9. Personal status (married, single,...) and sex
10. Other debtors / guarantors
11. Present residence since X years
12. Property (e.g. real estate)
13. Age in years
14. Other installment plans (banks, stores)
15. Housing (rent, own,...)
16. Number of existing credits at this bank
17. Job
18. Number of people being liable to provide maintenance for
19. Telephone (yes, no)
20. Foreign worker (yes, no)
Figure 10: Dataset description for credit-g.
4. Relevant Information: Several constraints were placed on the selection of these instances from a larger database. In particular, all patients here are females at least 21 years old of Pima Indian heritage. ADAP is an adaptive learning routine that generates and executes digital analogs of perceptron-like devices. It is a unique algorithm; see the paper for details.
7. For Each Attribute: (all numeric-valued)  
1. Number of times pregnant  
2. Plasma glucose concentration a 2 hours in an oral glucose tolerance test  
3. Diastolic blood pressure (mm Hg)  
4. Triceps skin fold thickness (mm)  
5. 2-Hour serum insulin (mu U/ml)  
6. Body mass index (weight in kg/(height in m)^2)  
7. Diabetes pedigree function  
8. Age (years)  
9. Class variable (0 or 1)  
Relabeled values in attribute 'class'  
From: 0 To: tested_negative  
From: 1 To: tested_positive
Figure 11: Dataset description for diabetes.
**Tic-Tac-Toe Endgame database**  
This database encodes the complete set of possible board configurations at the end of tic-tac-toe games, where "x" is assumed to have played first. The target concept is "win for x" (i.e., true when "x" has one of 8 possible ways to create a "three-in-a-row").
Figure 12: Dataset description for tic-tac-toe.
**Eucalyptus Soil Conservation**
The objective was to determine which seedlots in a species are best for soil conservation in seasonally dry hill country. Determination is found by measurement of height, diameter by height, survival, and other contributing factors.
It is important to note that eucalypt trial methods changed over time; earlier trials included mostly 15 - 30cm tall seedling grown in peat plots and the later trials have included mostly three replications of eight trees grown. This change may contribute to less significant results.
Experimental data recording procedures which require noting include:
- instances with no data recorded due to experimental recording procedures require that the absence of a species from one replicate at a site was treated as a missing value, but if absent from two or more replicates at a site the species was excluded from the site's analyses.
- missing data for survival, vigour, insect resistance, stem form, crown form and utility especially for the data recorded at the Morea Station; this could indicate the death of species in these areas or a lack in collection of data.
Attribute Information
1. Abbrev - site abbreviation - enumerated
2. Rep - site rep - integer
3 . Locality - site locality in the North Island - enumerated
4. Map_Ref - map location in the North Island - enumerated
5. Latitude - latitude approximation - enumerated
6. Altitude - altitude approximation - integer
7. Rainfall - rainfall (mm pa) - integer
8. Frosts - frosts (deg. c) - integer
9. Year - year of planting - integer
10. Sp - species code - enumerated
11. PMCno - seedlot number - integer
12. DBH - best diameter base height (cm) - real
13. Ht - height (m) - real
14. Surv - survival - integer
15. Vig - vigour - real
16. Ins_res - insect resistance - real
17. Stem_Fm - stem form - real
18. Crown_Fm - crown form - real
19. Branch_Fm - branch form - real