Feature Engineering

Há uma crença crescente, especialmente entre praticantes entusiastas da inteligência artificial, de que os grandes modelos de linguagem (Large Language Models — LLMs) tornaram obsoleta a necessidade de engenharia manual de features. O argumento é intuitivo: se um modelo como o GPT-4 pode escrever código, raciocinar sobre dados, deduzir padrões e até propor transformações analíticas, por que um cientista de dados precisaria ainda gastar horas construindo variáveis derivadas, codificando categorias, normalizando distribuições ou extraindo features de séries temporais?

A resposta, como quase sempre acontece em ciência, é profundamente matizada. Este artigo propõe um exame rigoroso desta questão, apoiado em literatura acadêmica recente, estudos de benchmark, e nos avanços mais significativos em AutoML e LLMs aplicados à ciência de dados. A tese central que defenderemos é a seguinte: feature engineering não foi substituída pelos LLMs — ela foi transformada, amplificada e, em determinados contextos, parcialmente automatizada por eles. Mas sua relevância, longe de ter diminuído, permanece fundamentalmente intacta, especialmente no domínio mais prevalente do machine learning na indústria: os dados tabulares.

 

Uma breve história da Feature Engineering

A engenharia de features como prática sistemática nasce com o próprio machine learning supervisionado. Pedro Domingos, em seu seminal artigo “A Few Useful Things to Know About Machine Learning” (Communications of the ACM, 2012), afirma que o conhecimento de domínio, traduzido em boas features, frequentemente determina o sucesso de um modelo mais do que a escolha do algoritmo em si. Esta afirmação, feita há mais de uma década, permanece empiricamente válida.

A era pré-deep learning era dominada por engenheiros de features que operavam como artesãos do dado: no campo da visão computacional, histogramas de gradientes orientados (HOG) e descritores SIFT foram engenhados manualmente para detectar bordas e texturas; no processamento de linguagem natural, n-gramas, TF-IDF e features de POS-tagging eram laboriosamente construídas; em finanças, médias móveis, volatilidade realizada e indicadores técnicos eram as features que alimentavam modelos de trading.

O paradigma mudou radicalmente com o advento das redes neurais profundas. A partir de 2012, com o AlexNet demonstrando que representações hierárquicas podiam ser aprendidas diretamente de pixels brutos (Krizhevsky, Sutskever & Hinton, 2012), generalizou-se a ideia de que o deep learning eliminaria a necessidade de feature engineering manual em domínios como imagem, áudio e texto. E, nestes domínios específicos, esta visão se provou amplamente correta.

Porém — e este é o ponto crucial — o mundo do machine learning não é composto apenas de imagens e texto. A maior parte dos problemas de negócios, da saúde, da ciência e da engenharia opera com dados tabulares: planilhas, bancos de dados relacionais, séries temporais estruturadas. E é precisamente neste domínio que feature engineering permanece não apenas relevante, mas frequentemente indispensável.

 

Fundamentos: Por que Features importam

Para compreender a persistência da feature engineering, é necessário revisitar seus fundamentos teóricos. Um modelo de machine learning é, em última análise, uma função matemática que mapeia um espaço de entrada X para um espaço de saída Y. A qualidade dessa função depende criticamente de como o espaço de entrada é construído.

Features mal construídas introduzem três tipos de problemas. Primeiro, ausência de sinal: quando variáveis relevantes não estão representadas no conjunto de entrada, o modelo não pode aprender relações que não foram codificadas. Segundo, ruído irrelevante: features não informativas aumentam a dimensionalidade sem contribuir para o aprendizado, causando problemas de generalização, especialmente em algoritmos sensíveis à maldição da dimensionalidade. Terceiro, violação de premissas algorítmicas: algoritmos lineares pressupõem relações lineares entre features e alvo; distribuições altamente assimétricas podem prejudicar modelos baseados em gradiente; variáveis categóricas com alta cardinalidade precisam ser representadas de formas específicas dependendo do algoritmo.

A feature engineering aborda todos estes problemas de forma sistemática e orientada pelo conhecimento de domínio. Técnicas como criação de features de interação, transformações logarítmicas, extração de componentes de data/hora, agrupamentos estatísticos por categoria, encodings supervisionados (target encoding, CatBoost encoding) e combinações polinomiais são parte do repertório standard.

O survey de Mumuni & Mumuni (2025), publicado no Journal of Information and Intelligence com título “Automated data processing and feature engineering for deep learning and big data applications”, demonstra que, mesmo em pipelines de deep learning, a automação de tarefas de processamento de dados e engenharia de features é motivada pela necessidade de lidar com volumes massivos de dados heterogêneos e complexos, reconhecendo que esta fase permanece como um dos maiores gargalos operacionais.

 

O Problema dos dados tabulares: Onde os LLMs ainda tropeçam

O estudo de Grinsztajn, Oyallon & Varoquaux (NeurIPS 2022), “Why do tree-based models still outperform deep learning on typical tabular data?”, é provavelmente o benchmark mais citado sobre este tema na literatura recente. Com 20.000 horas de computação em busca de hiperparâmetros e 45 datasets de domínios variados, os autores chegaram a conclusões que desafiam a narrativa de substituição:

Modelos baseados em árvores — XGBoost e Random Forests — permanecem como estado da arte em dados tabulares de médio porte (cerca de 10.000 amostras), mesmo sem considerar sua velocidade superior.

Os autores identificam três razões fundamentais para esta superioridade, todas diretamente relacionadas à natureza do feature engineering:

  1. Robustez a features não informativas: redes neurais têm performance significativamente degradada pela presença de variáveis irrelevantes, enquanto modelos de árvore as ignoram naturalmente. Isso significa que a seleção de features — uma atividade de engenharia — tem impacto desproporcional em modelos neurais.
  2. Preservação da orientação dos dados: dados tabulares têm uma base natural (os atributos originais) que frequentemente codifica as melhores features. Transformações que envolvem combinações lineares de features — como as usadas implicitamente por redes neurais — podem perder este viés útil.
  3. Capacidade de aprender funções irregulares: padrões em dados tabulares frequentemente são descontínuos, esparsos e idiossincráticos — exatamente o tipo de estrutura que modelos de árvore capturam bem e redes neurais encontram dificuldade.

O estudo de Shwartz-Ziv & Armon, “Tabular data: Deep learning is not all you need” (Information Fusion, 2022), corrobora esta visão ao demonstrar que o XGBoost consistentemente supera modelos de deep learning recentes mesmo nos datasets utilizados nos próprios artigos que propunham esses modelos, sugerindo que os benchmarks publicados muitas vezes são otimizados para favorecer a nova arquitetura proposta.

O estudo de Uddin et al. (PLoS ONE, 2024), “Confirming the statistically significant superiority of tree-based machine learning algorithms over their counterparts for tabular data”, vai além da constatação empírica e demonstra significância estatística para a superioridade de algoritmos baseados em árvore, usando testes formais de hipótese. E, crucialmente, modelos baseados em árvore são justamente os que mais se beneficiam de uma engenharia de features cuidadosa.

 

LLMs entram no jogo da Engenharia de Features

Se por um lado os LLMs não substituíram a necessidade de feature engineering nos domínios onde ela é mais crítica, por outro lado eles abriram uma nova fronteira: a possibilidade de automatizar e augmentar o próprio processo de engenharia de features usando conhecimento semântico e raciocínio em linguagem natural.

Esta é uma distinção fundamental que muitas vezes se perde no debate público. A questão não é “LLMs eliminam a feature engineering?” mas sim “LLMs podem fazer feature engineering por nós, de forma melhor ou mais eficiente do que humanos?”. E aqui a resposta começa a ser — em condições específicas e bem delimitadas — sim.

O ponto de inflexão conceitual é que LLMs treinados em vastos corpora de texto técnico, científico e de código possuem algo que ferramentas tradicionais de AutoFE (Automated Feature Engineering) não têm: conhecimento prévio de domínio codificado em seus pesos. Um LLM sabe que, em dados de saúde, IMC pode ser calculado a partir de peso e altura. Sabe que, em finanças, ratios como P/L e EV/EBITDA têm significado econômico específico. Sabe que, em dados de transporte, a hora do dia e o dia da semana afetam padrões de tráfego de formas não lineares.

Esta capacidade — de propor features semanticamente significativas baseadas em compreensão conceitual do domínio, não apenas em operações matemáticas cegas sobre os dados — é qualitativamente diferente de tudo que existia antes em AutoML.

 

CAAFE: O marco da engenharia semântica automatizada

O trabalho mais influente nesta direção é o CAAFE — Context-Aware Automated Feature Engineering — apresentado por Hollmann, Müller e Hutter no NeurIPS 2023. O paper estabelece um framework metodologicamente elegante e empiricamente robusto:

Mecanismo: CAAFE utiliza um LLM (especificamente GPT-4) para gerar iterativamente novas features para datasets tabulares, baseando-se na descrição textual do dataset e amostras dos dados. O LLM propõe transformações na forma de código Python executável, acompanhadas de explicações sobre a utilidade de cada feature gerada. Após cada proposta, o sistema executa a transformação, avalia o impacto na performance do classificador downstream via validação cruzada, e mantém apenas as features que melhoram o ROC AUC. Este ciclo se repete por K iterações.

Resultados: apesar da simplicidade metodológica, o CAAFE melhora a performance em 11 de 14 datasets avaliados, elevando o ROC AUC médio de 0,798 para 0,822 — uma melhoria comparável à diferença entre usar regressão logística e Random Forest nos mesmos dados. Em um exemplo ilustrativo no dataset Tic-Tac-Toe Endgame, o ROC AUC saltou de 0,888 para 1,0 em apenas duas iterações de engenharia.

O CAAFE representa o que os autores chamam de “AutoML semântico” — uma extensão dos sistemas clássicos de AutoML que finalmente endereça a fase de engenharia de dados, historicamente deixada ao cargo exclusivo dos humanos. Segundo os próprios autores, citando o relatório State of Data Science da Anaconda (2020), cientistas de dados dedicam apenas 23% do seu tempo à construção e ajuste de modelos; os outros 77% são gastos em tarefas de engenharia e preparação de dados.

Uma observação crítica importante: CAAFE é explicitamente semi-automático. Ele depende que o usuário forneça descrições contextuais do dataset, e sua eficácia é diretamente proporcional à qualidade dessa contextualização. Isso sugere que o papel do cientista de dados não desaparece — ele se transforma: em vez de propor features manualmente, o praticante agora deve articular o conhecimento de domínio de forma que o LLM possa explorá-lo eficientemente.

 

LLM-FE: Otimização evolutiva com raciocínio de linguagem

Avançando sobre os fundamentos do CAAFE, o framework LLM-FE — apresentado em março de 2025 em paper no arXiv (Abhyankar et al., 2025) — combina a capacidade semântica dos LLMs com técnicas de busca evolutiva para descobrir features de alto impacto em tarefas de aprendizado tabular.

A inovação central do LLM-FE é tratar o processo de engenharia de features como um problema de otimização combinatória onde o LLM opera como um otimizador evolutivo inteligente: em vez de explorar o espaço de possíveis transformações de forma aleatória ou heurística (como faziam os métodos clássicos de AutoFE), o LLM usa seu conhecimento do domínio para direcionar a busca para regiões promissoras do espaço de features.

O sistema fornece ao LLM não apenas a descrição do dataset e metadados das features, mas também amostras representativas dos dados e instruções explícitas para raciocinar sobre a relevância contextual de cada transformação proposta. O LLM é instruído a gerar features novas com justificativa passo-a-passo para sua relevância.

Os resultados publicados demonstram que o LLM-FE supera consistentemente os métodos de engenharia de features estado da arte, identificando features contextualmente relevantes que melhoram a performance downstream em modelos como XGBoost e TabPFN. O framework representa uma síntese entre o melhor dos mundos: a eficiência computacional de abordagens tradicionais de AutoFE combinada com a profundidade semântica dos LLMs.

 

FREEFORM e o conhecimento biológico codificado em LLMs

Um dos estudos mais intrigantes nesta área vem do campo da genômica. O trabalho de Han et al. (publicado no PMC em 2025), descrevendo o framework FREEFORM — Free-flow Reasoning and Ensembling for Enhanced Feature Output and Robust Modeling — explora se LLMs podem realizar engenharia de features para dados de genótipo tabular, um domínio onde o conhecimento especializado é profundo e altamente técnico.

O problema é desafiador: dados de genótipo são de alta dimensionalidade, os efeitos de epistasia (interações entre variantes genéticas) são complexos, e a literatura biomédica relevante é vasta demais para que qualquer cientista de dados possa absorver completamente. O FREEFORM utiliza GPT-4o como backbone principal para raciocínio de alto nível sobre quais features construir, implementando princípios de chain-of-thought e ensembling para aumentar a robustez.

Os resultados revelam algo notável: os modelos de linguagem mais fracos foram surpreendentemente competitivos com o GPT-4o na tarefa de engenharia de features, sugerindo que a capacidade de construir termos de interação e expressões multiplicativas simples está dentro das capacidades de raciocínio da maioria dos LLMs modernos. A limitação encontrada foi na seleção de features altamente específicas (como variantes genéticas associadas a condições raras), onde o conhecimento especializado codificado nos pesos do LLM pode ser incompleto ou inconsistente.

Este resultado tem implicações importantes: os LLMs são mais eficazes como motores de engenharia de features quando o domínio é suficientemente coberto por seu treinamento. Em domínios altamente especializados ou com literatura muito recente, o conhecimento de domínio humano permanece insubstituível.

 

Os limites dos LLMs na Engenharia de Features

A euforia com os resultados promissores não pode obscurecer as limitações significativas e bem documentadas dos LLMs neste papel. Uma análise honesta exige que estas sejam discutidas com o mesmo rigor.

Alucinações e transformações inválidas

LLMs podem gerar código Python sintaticamente correto que é semanticamente inválido no contexto do problema. O CAAFE mitigou este risco implementando validação em múltiplos estágios — parsing de AST, execução em sandbox, verificação de performance empírica — mas não eliminou completamente o problema. Frameworks sem esta camada de validação podem introduzir features que parecem razoáveis mas são matematicamente incoerentes ou produzem vazamento de dados (data leakage).

Limitações de contexto e escala

Datasets com muitas features e muitas amostras rapidamente excedem as janelas de contexto dos LLMs. O CAAFE, por exemplo, tem suas limitações operacionais em torno de 100 features — acima disso, o TabPFN (o classificador downstream usado nos experimentos) nem sequer consegue processar todas as features geradas. Para problemas de alta dimensionalidade, os LLMs precisam operar sobre representações comprimidas dos dados, potencialmente perdendo informações relevantes.

Dependência de descrições de qualidade

A eficácia de frameworks como CAAFE e LLM-FE é fortemente condicionada pela qualidade das descrições textuais fornecidas pelo usuário. Quando nomes de colunas são crípticos (ex.: “var_1”, “col_42”) ou quando as descrições do dataset são vagas, o LLM perde seu principal diferencial — o conhecimento de domínio — e sua performance regride para níveis próximos aos de métodos de AutoFE sem contexto semântico.

Dados sensíveis e privacidade

Frameworks que dependem de LLMs hospedados em nuvem (como GPT-4 via API da OpenAI) são inadequados para datasets contendo informações sensíveis. O paper FeRG-LLM (NAACL 2025, Findings) explicita esta limitação e propõe uma alternativa baseada em modelos locais (Llama 3.1 de 8B parâmetros), demonstrando que a funcionalidade pode ser preservada sem enviar dados a servidores externos — mas a um custo de performance.

Custo computacional e financeiro

A iteração entre geração de features, re-treinamento do modelo downstream e avaliação de performance pode ser computacionalmente cara, especialmente com datasets maiores. O CAAFE estima um custo de aproximadamente US$ 0,50 por 10 iterações em um dataset de 1.000 linhas e 10 colunas usando GPT-4 — o que escala rapidamente para problemas mais complexos e pode tornar a abordagem inviável em contextos de orçamento limitado.

 

O conhecimento de domínio não é opcional

Um dos argumentos mais sofisticados em defesa da relevância contínua da feature engineering humana é epistemológico, não apenas prático. Ele diz respeito à natureza do conhecimento que informa boas features.

O conhecimento de domínio necessário para construir features verdadeiramente poderosas frequentemente não está disponível em forma textual processável por LLMs. Ele está em:

  • Conversas informais entre especialistas, tacitamente compartilhadas
  • Heurísticas acumuladas ao longo de décadas de prática clínica, industrial ou financeira
  • Intuições sobre o processo gerador de dados que não foram formalizadas em nenhum artigo
  • Conhecimento sobre artefatos específicos de coleta de dados em um determinado hospital, sensores industriais, ou sistema de transações financeiras

Este conhecimento tácito — no sentido de Polanyi (1966) — é fundamentalmente difícil de capturar por qualquer sistema que opere sobre texto. Um médico experiente que percebe que certos padrões de temperatura de admissão hospitalar em conjunto com o horário de coleta indicam uma artefato do processo, e não um dado clínico real, carrega um conhecimento que nenhum LLM pode extrair de artigos. Um engenheiro de processos que sabe que determinada leitura de sensor é sistematicamente ruidosa durante turnos noturnos possui informação causal que um LLM simplesmente não tem acesso.

Neste sentido, a feature engineering humana não apenas complementa os LLMs — ela representa uma classe de conhecimento epistemicamente distinta que, por enquanto, permanece fora do alcance da automação.

 

Feature Engineering e a crise da explicabilidade

Um ângulo frequentemente negligenciado no debate é o da explicabilidade e interpretabilidade dos modelos. O Regulamento de Inteligência Artificial da União Europeia (EU AI Act), que entrou em vigor em agosto de 2024 com implementação progressiva até 2026, impõe requisitos de explicabilidade para sistemas de IA de alto risco — incluindo aplicações em saúde, crédito, emprego e infraestrutura crítica.

Features bem engenhadas têm uma propriedade crucial para a explicabilidade: elas são interpretáveis. Uma feature como “razão entre dívida e patrimônio” em um modelo de crédito é intrinsecamente interpretável; a importância desta feature no modelo (via SHAP values, por exemplo) tem significado direto para reguladores, clientes e auditores. Em contraposição, as representações internas aprendidas por uma rede neural profunda — por mais poderosas que sejam — são notoriamente opacas.

O survey de Mumuni & Mumuni (2025) sinaliza especificamente que métodos de deep learning aplicados a dados tabulares “frequentemente ignoram os aspectos semânticos dos dados”, e que sua operação de “caixa preta” torna os resultados difíceis de explicar — uma limitação crítica em domínios regulados.

Ferramentas como SHAP (SHapley Additive exPlanations) e LIME, que ganharam tração significativa em 2024, funcionam mais efetivamente sobre espaços de features interpretáveis. Uma feature engineering cuidadosa, portanto, não apenas melhora a performance do modelo — ela também pavimenta o caminho para a explicabilidade exigida tanto por reguladores quanto pelo mercado.

O CAAFE, curiosamente, endereça parcialmente esta questão ao gerar explicações textuais para cada feature proposta — o que representa uma forma de explicabilidade no nível da construção das variáveis, não apenas no nível das predições do modelo final.

 

O futuro: simbiose, não substituição

O quadro que emerge da literatura é inequívoco: estamos caminhando para um paradigma de simbiose entre feature engineering humana e LLMs, não para um cenário de substituição unilateral.

Esta simbiose opera em vários níveis complementares:

LLMs como aceleradores do processo exploratório

Frameworks como CAAFE e LLM-FE são mais produtivos quando usados para acelerar a fase exploratória — gerando candidatas a features que o cientista de dados então inspeciona, valida e refina. Isso reduz drasticamente o tempo gasto em brainstorming inicial sem eliminar o julgamento humano sobre quais features fazem sentido no contexto do negócio.

Feature Engineering como curadoria epistemológica

O papel do engenheiro de features está se deslocando da construção de baixo nível (escrever o código para calcular uma média móvel) para a curadoria epistemológica de alto nível: articular o conhecimento de domínio de forma que os LLMs possam explorá-lo, validar as features propostas contra o entendimento causal do processo gerador de dados, e identificar casos onde o LLM propõe transformações que são numericamente válidas mas causalmente espúrias.

Domínios especializados continuam dependendo de especialistas humanos

Em áreas como genômica (conforme demonstrado pelo FREEFORM), sistemas industriais de IoT, finanças quantitativas de alta frequência, e diagnóstico médico especializado, o conhecimento de domínio necessário para construir as melhores features frequentemente excede o que está disponível no corpus de treinamento dos LLMs. Aqui, a feature engineering especializada humana permanece insubstituível.

A emergência do “Semantic AutoML”

O termo cunhado pelos autores do CAAFE — “Semantic AutoML” — aponta para uma nova classe de sistemas que combina a automação clássica do AutoML com a semântica dos LLMs. Esta classe de sistemas não elimina a necessidade de feature engineering, mas muda quem pode praticá-la: ao tornar o processo mais acessível a especialistas de domínio que não são programadores, o Semantic AutoML democratiza a criação de features sem tornar obsoleto o conhecimento especializado.

O papel crescente dos dados tabulares fundacionais

Um desenvolvimento paralelo relevante é o surgimento de modelos fundacionais para dados tabulares, como o TabPFN (Hollmann et al., 2022) — um transformer treinado em milhões de datasets sintéticos que pode realizar classificação em novos datasets sem re-treinamento. Estes modelos representam uma abordagem radicalmente diferente: em vez de aprender a fazer feature engineering, eles aprendem a fazer meta-aprendizado sobre a estrutura dos próprios dados tabulares. Porém, mesmo estes modelos se beneficiam de features bem construídas como entrada — reforçando, novamente, que feature engineering e aprendizado de representações não são mutuamente exclusivos.

A questão com que abrimos este artigo — feature engineering ainda é relevante, ou foi substituída pelos LLMs? — pode agora ser respondida com precisão e evidência:

Feature engineering não foi substituída. Foi reposicionada.

No domínio mais prevalente do machine learning industrial — dados tabulares — modelos baseados em árvore (XGBoost, Random Forest, LightGBM) continuam sendo estado da arte, e eles continuam se beneficiando imensamente de features bem construídas. A evidência empírica de Grinsztajn et al. (2022), Shwartz-Ziv & Armon (2022) e Uddin et al. (2024) é robusta e convergente neste ponto.

Os LLMs, por sua vez, abriram uma nova fronteira promissora ao demonstrar que o conhecimento de domínio codificado em seus pesos pode ser mobilizado para propor, testar e refinar features de forma semi-automatizada — como evidenciado pelos frameworks CAAFE (NeurIPS 2023), LLM-FE (arXiv 2025) e FREEFORM (PMC 2025). Mas esta automação tem limites claros: ela depende da qualidade das descrições fornecidas, falha em domínios altamente especializados, tem custo computacional relevante, e produz resultados que ainda precisam de curadoria humana.

O verdadeiro legado desta era não é a obsolescência da engenharia de features, mas a sua evolução epistemológica: de uma prática artesanal e intensiva em trabalho manual, para uma disciplina híbrida onde humanos com conhecimento de domínio profundo colaboram com sistemas de IA para explorar o espaço de features de forma mais eficiente, interpretável e democratizada.

Os engenheiros de features que sobreviverão — e prosperarão — neste novo paradigma não são aqueles que constroem melhor cada feature individual manualmente. São aqueles que entendem profundamente por que certas features importam, que sabem articular este conhecimento de forma que sistemas como CAAFE e LLM-FE possam explorá-lo, e que possuem o julgamento epistemológico para separar features causalmente sólidas de correlações espúrias, mesmo quando estas últimas emergem de sistemas de IA aparentemente confiáveis.

O futuro da feature engineering não é humano ou máquina. É humano e máquina, em colaboração íntima.

 

Fontes

  1. Grinsztajn, L., Oyallon, E., & Varoquaux, G. (2022). Why do tree-based models still outperform deep learning on typical tabular data? Advances in Neural Information Processing Systems (NeurIPS 2022), 35, 507–520.
    https://arxiv.org/abs/2207.08815
  2. Hollmann, N., Müller, S., & Hutter, F. (2023). Large Language Models for Automated Data Science: Introducing CAAFE for Context-Aware Automated Feature Engineering. Advances in Neural Information Processing Systems (NeurIPS 2023).
    https://arxiv.org/abs/2305.03403
  3. Abhyankar, S. et al. (2025). LLM-FE: Automated Feature Engineering for Tabular Data with LLMs as Evolutionary Optimizers. arXiv preprint arXiv:2503.14434.
    https://arxiv.org/html/2503.14434v1
  4. Han, Y. et al. (2025). Knowledge-Driven Feature Selection and Engineering for Genotype Data with Large Language Models (FREEFORM). PubMed Central / PMC.
    https://pmc.ncbi.nlm.nih.gov/articles/PMC12150712/
  5. Mumuni, A., & Mumuni, F. (2025). Automated data processing and feature engineering for deep learning and big data applications: A survey. Journal of Information and Intelligence, 3(2), 113–153.
    https://doi.org/10.1016/j.jiixd.2024.01.002
  6. Shwartz-Ziv, R., & Armon, A. (2022). Tabular data: Deep learning is not all you need. Information Fusion.
    https://www.sciencedirect.com/science/article/abs/pii/S1566253521002360
  7. Uddin, S. et al. (2024). Confirming the statistically significant superiority of tree-based machine learning algorithms over their counterparts for tabular data. PLoS ONE, 19(4), e0301541.
    https://pmc.ncbi.nlm.nih.gov/articles/PMC11025817/
  8. FeRG-LLM (2025). Feature Engineering by Reason Generation with LLMs. Findings of NAACL 2025.
    https://aclanthology.org/2025.findings-naacl.237.pdf
  9. Domingos, P. (2012). A few useful things to know about machine learning. Communications of the ACM, 55(10), 78–87.
    https://dl.acm.org/doi/10.1145/2347736.2347755
  10. Anaconda (2020). State of Data Science 2020.
    https://www.anaconda.com/state-of-data-science-2020
  11. Hollmann, N., Müller, S., Eggensperger, K., & Hutter, F. (2022). TabPFN: A Transformer That Solves Small Tabular Classification Problems in a Second. arXiv preprint arXiv:2207.01848.
    https://arxiv.org/abs/2207.01848
  12. Kanter, J. M., & Veeramachaneni, K. (2015). Deep Feature Synthesis: Towards Automating Data Science Endeavors. 2015 IEEE International Conference on Data Science and Advanced Analytics (DSAA).
    https://ieeexplore.ieee.org/document/7344858
  13. Sandgarden Learn — Feature Engineering Survey (2025). The Art of Feature Engineering: Turning Raw Data into Machine Learning Gold.
    https://www.sandgarden.com/learn/feature-engineering
  14. arXiv:2406.03505 (2025). LLMs and Tree of Thoughts for Feature Engineering in Tabular Data Classification.
    https://arxiv.org/pdf/2406.03505
  15. CAAFE — GitHub Repository (PriorLabs, 2023).
    https://github.com/PriorLabs/CAAFE