{"id":4670,"date":"2026-04-01T08:00:00","date_gmt":"2026-04-01T08:00:00","guid":{"rendered":"https:\/\/volcano.com.br\/?p=4670"},"modified":"2026-03-18T17:01:25","modified_gmt":"2026-03-18T17:01:25","slug":"feature-engineering","status":"publish","type":"post","link":"https:\/\/volcano.com.br\/index.php\/2026\/04\/01\/feature-engineering\/","title":{"rendered":"Feature Engineering"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

H\u00e1 uma cren\u00e7a crescente, especialmente entre praticantes entusiastas da intelig\u00eancia artificial, de que os grandes modelos de linguagem (Large Language Models \u2014 LLMs) tornaram obsoleta a necessidade de engenharia manual de features. O argumento \u00e9 intuitivo: se um modelo como o GPT-4 pode escrever c\u00f3digo, raciocinar sobre dados, deduzir padr\u00f5es e at\u00e9 propor transforma\u00e7\u00f5es anal\u00edticas, por que um cientista de dados precisaria ainda gastar horas construindo vari\u00e1veis derivadas, codificando categorias, normalizando distribui\u00e7\u00f5es ou extraindo features de s\u00e9ries temporais?<\/p>

A resposta, como quase sempre acontece em ci\u00eancia, \u00e9 profundamente matizada. Este artigo prop\u00f5e um exame rigoroso desta quest\u00e3o, apoiado em literatura acad\u00eamica recente, estudos de benchmark, e nos avan\u00e7os mais significativos em AutoML e LLMs aplicados \u00e0 ci\u00eancia de dados. A tese central que defenderemos \u00e9 a seguinte: feature engineering n\u00e3o foi substitu\u00edda pelos LLMs \u2014 ela foi transformada, amplificada e, em determinados contextos, parcialmente automatizada por eles<\/strong>. Mas sua relev\u00e2ncia, longe de ter diminu\u00eddo, permanece fundamentalmente intacta, especialmente no dom\u00ednio mais prevalente do machine learning na ind\u00fastria: os dados tabulares.<\/p>

\u00a0<\/h2>

Uma breve hist\u00f3ria da Feature Engineering<\/h2>

A engenharia de features como pr\u00e1tica sistem\u00e1tica nasce com o pr\u00f3prio 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\u00ednio, traduzido em boas features, frequentemente determina o sucesso de um modelo mais do que a escolha do algoritmo em si. Esta afirma\u00e7\u00e3o, feita h\u00e1 mais de uma d\u00e9cada, permanece empiricamente v\u00e1lida.<\/p>

A era pr\u00e9-deep learning era dominada por engenheiros de features que operavam como artes\u00e3os do dado: no campo da vis\u00e3o 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\u00eddas; em finan\u00e7as, m\u00e9dias m\u00f3veis, volatilidade realizada e indicadores t\u00e9cnicos eram as features que alimentavam modelos de trading.<\/p>

O paradigma mudou radicalmente com o advento das redes neurais profundas. A partir de 2012, com o AlexNet demonstrando que representa\u00e7\u00f5es hier\u00e1rquicas podiam ser aprendidas<\/em> 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\u00ednios como imagem, \u00e1udio e texto. E, nestes dom\u00ednios espec\u00edficos, esta vis\u00e3o se provou amplamente correta.<\/p>

Por\u00e9m \u2014 e este \u00e9 o ponto crucial \u2014 o mundo do machine learning n\u00e3o \u00e9 composto apenas de imagens e texto. A maior parte dos problemas de neg\u00f3cios, da sa\u00fade, da ci\u00eancia e da engenharia opera com dados tabulares<\/strong>: planilhas, bancos de dados relacionais, s\u00e9ries temporais estruturadas. E \u00e9 precisamente neste dom\u00ednio que feature engineering permanece n\u00e3o apenas relevante, mas frequentemente indispens\u00e1vel.<\/p>

\u00a0<\/h2>

Fundamentos: Por que Features importam<\/h2>

Para compreender a persist\u00eancia da feature engineering, \u00e9 necess\u00e1rio revisitar seus fundamentos te\u00f3ricos. Um modelo de machine learning \u00e9, em \u00faltima an\u00e1lise, uma fun\u00e7\u00e3o matem\u00e1tica que mapeia um espa\u00e7o de entrada X para um espa\u00e7o de sa\u00edda Y. A qualidade dessa fun\u00e7\u00e3o depende criticamente de como o espa\u00e7o de entrada \u00e9 constru\u00eddo.<\/p>

Features mal constru\u00eddas introduzem tr\u00eas tipos de problemas. Primeiro, aus\u00eancia de sinal<\/strong>: quando vari\u00e1veis relevantes n\u00e3o est\u00e3o representadas no conjunto de entrada, o modelo n\u00e3o pode aprender rela\u00e7\u00f5es que n\u00e3o foram codificadas. Segundo, ru\u00eddo irrelevante<\/strong>: features n\u00e3o informativas aumentam a dimensionalidade sem contribuir para o aprendizado, causando problemas de generaliza\u00e7\u00e3o, especialmente em algoritmos sens\u00edveis \u00e0 maldi\u00e7\u00e3o da dimensionalidade. Terceiro, viola\u00e7\u00e3o de premissas algor\u00edtmicas<\/strong>: algoritmos lineares pressup\u00f5em rela\u00e7\u00f5es lineares entre features e alvo; distribui\u00e7\u00f5es altamente assim\u00e9tricas podem prejudicar modelos baseados em gradiente; vari\u00e1veis categ\u00f3ricas com alta cardinalidade precisam ser representadas de formas espec\u00edficas dependendo do algoritmo.<\/p>

A feature engineering aborda todos estes problemas de forma sistem\u00e1tica e orientada pelo conhecimento de dom\u00ednio. T\u00e9cnicas como cria\u00e7\u00e3o de features de intera\u00e7\u00e3o, transforma\u00e7\u00f5es logar\u00edtmicas, extra\u00e7\u00e3o de componentes de data\/hora, agrupamentos estat\u00edsticos por categoria, encodings supervisionados (target encoding, CatBoost encoding) e combina\u00e7\u00f5es polinomiais s\u00e3o parte do repert\u00f3rio standard.<\/p>

O survey de Mumuni & Mumuni (2025), publicado no Journal of Information and Intelligence<\/em> com t\u00edtulo “Automated data processing and feature engineering for deep learning and big data applications”, demonstra que, mesmo em pipelines de deep learning, a automa\u00e7\u00e3o de tarefas de processamento de dados e engenharia de features \u00e9 motivada pela necessidade de lidar com volumes massivos de dados heterog\u00eaneos e complexos<\/strong>, reconhecendo que esta fase permanece como um dos maiores gargalos operacionais.<\/p>

\u00a0<\/h2>

O Problema dos dados tabulares: Onde os LLMs ainda trope\u00e7am<\/h2>

O estudo de Grinsztajn, Oyallon & Varoquaux (NeurIPS 2022), “Why do tree-based models still outperform deep learning on typical tabular data?”, \u00e9 provavelmente o benchmark mais citado sobre este tema na literatura recente. Com 20.000 horas de computa\u00e7\u00e3o em busca de hiperpar\u00e2metros e 45 datasets de dom\u00ednios variados, os autores chegaram a conclus\u00f5es que desafiam a narrativa de substitui\u00e7\u00e3o:<\/p>

Modelos baseados em \u00e1rvores \u2014 XGBoost e Random Forests \u2014 permanecem como estado da arte em dados tabulares de m\u00e9dio porte (cerca de 10.000 amostras), mesmo sem considerar sua velocidade superior.<\/p><\/blockquote>

Os autores identificam tr\u00eas raz\u00f5es fundamentais para esta superioridade, todas diretamente relacionadas \u00e0 natureza do feature engineering:<\/p>

  1. Robustez a features n\u00e3o informativas<\/strong>: redes neurais t\u00eam performance significativamente degradada pela presen\u00e7a de vari\u00e1veis irrelevantes, enquanto modelos de \u00e1rvore as ignoram naturalmente. Isso significa que a sele\u00e7\u00e3o de features \u2014 uma atividade de engenharia \u2014 tem impacto desproporcional em modelos neurais.<\/li>
  2. Preserva\u00e7\u00e3o da orienta\u00e7\u00e3o dos dados<\/strong>: dados tabulares t\u00eam uma base natural (os atributos originais) que frequentemente codifica as melhores features. Transforma\u00e7\u00f5es que envolvem combina\u00e7\u00f5es lineares de features \u2014 como as usadas implicitamente por redes neurais \u2014 podem perder este vi\u00e9s \u00fatil.<\/li>
  3. Capacidade de aprender fun\u00e7\u00f5es irregulares<\/strong>: padr\u00f5es em dados tabulares frequentemente s\u00e3o descont\u00ednuos, esparsos e idiossincr\u00e1ticos \u2014 exatamente o tipo de estrutura que modelos de \u00e1rvore capturam bem e redes neurais encontram dificuldade.<\/li><\/ol>

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

    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\u00e9m da constata\u00e7\u00e3o emp\u00edrica e demonstra signific\u00e2ncia estat\u00edstica<\/strong> para a superioridade de algoritmos baseados em \u00e1rvore, usando testes formais de hip\u00f3tese. E, crucialmente, modelos baseados em \u00e1rvore s\u00e3o justamente os que mais se beneficiam de uma engenharia de features cuidadosa.<\/p>

    \u00a0<\/h2>

    LLMs entram no jogo da Engenharia de Features<\/h2>

    Se por um lado os LLMs n\u00e3o substitu\u00edram a necessidade de feature engineering nos dom\u00ednios onde ela \u00e9 mais cr\u00edtica, por outro lado eles abriram uma nova fronteira: a possibilidade de automatizar e augmentar<\/em> o pr\u00f3prio processo de engenharia de features usando conhecimento sem\u00e2ntico e racioc\u00ednio em linguagem natural.<\/p>

    Esta \u00e9 uma distin\u00e7\u00e3o fundamental que muitas vezes se perde no debate p\u00fablico. A quest\u00e3o n\u00e3o \u00e9 “LLMs eliminam a feature engineering?” mas sim “LLMs podem fazer feature engineering por n\u00f3s, de forma melhor ou mais eficiente do que humanos?”. E aqui a resposta come\u00e7a a ser \u2014 em condi\u00e7\u00f5es espec\u00edficas e bem delimitadas \u2014 sim.<\/p>

    O ponto de inflex\u00e3o conceitual \u00e9 que LLMs treinados em vastos corpora de texto t\u00e9cnico, cient\u00edfico e de c\u00f3digo possuem algo que ferramentas tradicionais de AutoFE (Automated Feature Engineering) n\u00e3o t\u00eam: conhecimento pr\u00e9vio de dom\u00ednio codificado em seus pesos<\/strong>. Um LLM sabe que, em dados de sa\u00fade, IMC pode ser calculado a partir de peso e altura. Sabe que, em finan\u00e7as, ratios como P\/L e EV\/EBITDA t\u00eam significado econ\u00f4mico espec\u00edfico. Sabe que, em dados de transporte, a hora do dia e o dia da semana afetam padr\u00f5es de tr\u00e1fego de formas n\u00e3o lineares.<\/p>

    Esta capacidade \u2014 de propor features semanticamente significativas baseadas em compreens\u00e3o conceitual do dom\u00ednio, n\u00e3o apenas em opera\u00e7\u00f5es matem\u00e1ticas cegas sobre os dados \u2014 \u00e9 qualitativamente diferente de tudo que existia antes em AutoML.<\/p>

    \u00a0<\/h2>

    CAAFE: O marco da engenharia sem\u00e2ntica automatizada<\/h2>

    O trabalho mais influente nesta dire\u00e7\u00e3o \u00e9 o CAAFE \u2014 Context-Aware Automated Feature Engineering<\/em> \u2014 apresentado por Hollmann, M\u00fcller e Hutter no NeurIPS 2023. O paper estabelece um framework metodologicamente elegante e empiricamente robusto:<\/p>

    Mecanismo<\/strong>: CAAFE utiliza um LLM (especificamente GPT-4) para gerar iterativamente novas features para datasets tabulares, baseando-se na descri\u00e7\u00e3o textual do dataset e amostras dos dados. O LLM prop\u00f5e transforma\u00e7\u00f5es na forma de c\u00f3digo Python execut\u00e1vel, acompanhadas de explica\u00e7\u00f5es sobre a utilidade de cada feature gerada. Ap\u00f3s cada proposta, o sistema executa a transforma\u00e7\u00e3o, avalia o impacto na performance do classificador downstream via valida\u00e7\u00e3o cruzada, e mant\u00e9m apenas as features que melhoram o ROC AUC. Este ciclo se repete por K itera\u00e7\u00f5es.<\/p>

    Resultados<\/strong>: apesar da simplicidade metodol\u00f3gica, o CAAFE melhora a performance em 11 de 14 datasets avaliados<\/em>, elevando o ROC AUC m\u00e9dio de 0,798 para 0,822 \u2014 uma melhoria compar\u00e1vel \u00e0 diferen\u00e7a entre usar regress\u00e3o log\u00edstica 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\u00e7\u00f5es de engenharia.<\/p>

    O CAAFE representa o que os autores chamam de “AutoML sem\u00e2ntico” \u2014 uma extens\u00e3o dos sistemas cl\u00e1ssicos de AutoML que finalmente endere\u00e7a a fase de engenharia de dados, historicamente deixada ao cargo exclusivo dos humanos. Segundo os pr\u00f3prios autores, citando o relat\u00f3rio State of Data Science da Anaconda (2020), cientistas de dados dedicam apenas 23% do seu tempo \u00e0 constru\u00e7\u00e3o e ajuste de modelos; os outros 77% s\u00e3o gastos em tarefas de engenharia e prepara\u00e7\u00e3o de dados.<\/p>

    Uma observa\u00e7\u00e3o cr\u00edtica importante: CAAFE \u00e9 explicitamente semi-autom\u00e1tico<\/em>. Ele depende que o usu\u00e1rio forne\u00e7a descri\u00e7\u00f5es contextuais do dataset, e sua efic\u00e1cia \u00e9 diretamente proporcional \u00e0 qualidade dessa contextualiza\u00e7\u00e3o. Isso sugere que o papel do cientista de dados n\u00e3o desaparece \u2014 ele se transforma: em vez de propor features manualmente, o praticante agora deve articular o conhecimento de dom\u00ednio de forma que o LLM possa explor\u00e1-lo eficientemente.<\/p>

    \u00a0<\/h2>

    LLM-FE: Otimiza\u00e7\u00e3o evolutiva com racioc\u00ednio de linguagem<\/h2>

    Avan\u00e7ando sobre os fundamentos do CAAFE, o framework LLM-FE \u2014 apresentado em mar\u00e7o de 2025 em paper no arXiv (Abhyankar et al., 2025) \u2014 combina a capacidade sem\u00e2ntica dos LLMs com t\u00e9cnicas de busca evolutiva para descobrir features de alto impacto em tarefas de aprendizado tabular.<\/p>

    A inova\u00e7\u00e3o central do LLM-FE \u00e9 tratar o processo de engenharia de features como um problema de otimiza\u00e7\u00e3o combinat\u00f3ria onde o LLM opera como um otimizador evolutivo inteligente: em vez de explorar o espa\u00e7o de poss\u00edveis transforma\u00e7\u00f5es de forma aleat\u00f3ria ou heur\u00edstica (como faziam os m\u00e9todos cl\u00e1ssicos de AutoFE), o LLM usa seu conhecimento do dom\u00ednio para direcionar a busca para regi\u00f5es promissoras do espa\u00e7o de features.<\/p>

    O sistema fornece ao LLM n\u00e3o apenas a descri\u00e7\u00e3o do dataset e metadados das features, mas tamb\u00e9m amostras representativas dos dados e instru\u00e7\u00f5es expl\u00edcitas para raciocinar sobre a relev\u00e2ncia contextual de cada transforma\u00e7\u00e3o proposta<\/strong>. O LLM \u00e9 instru\u00eddo a gerar features novas com justificativa passo-a-passo para sua relev\u00e2ncia.<\/p>

    Os resultados publicados demonstram que o LLM-FE supera consistentemente os m\u00e9todos de engenharia de features estado da arte<\/strong>, identificando features contextualmente relevantes que melhoram a performance downstream em modelos como XGBoost e TabPFN. O framework representa uma s\u00edntese entre o melhor dos mundos: a efici\u00eancia computacional de abordagens tradicionais de AutoFE combinada com a profundidade sem\u00e2ntica dos LLMs.<\/p>

    \u00a0<\/h2>

    FREEFORM e o conhecimento biol\u00f3gico codificado em LLMs<\/h2>

    Um dos estudos mais intrigantes nesta \u00e1rea vem do campo da gen\u00f4mica. O trabalho de Han et al. (publicado no PMC em 2025), descrevendo o framework FREEFORM \u2014 Free-flow Reasoning and Ensembling for Enhanced Feature Output and Robust Modeling<\/em> \u2014 explora se LLMs podem realizar engenharia de features para dados de gen\u00f3tipo tabular, um dom\u00ednio onde o conhecimento especializado \u00e9 profundo e altamente t\u00e9cnico.<\/p>

    O problema \u00e9 desafiador: dados de gen\u00f3tipo s\u00e3o de alta dimensionalidade, os efeitos de epistasia (intera\u00e7\u00f5es entre variantes gen\u00e9ticas) s\u00e3o complexos, e a literatura biom\u00e9dica relevante \u00e9 vasta demais para que qualquer cientista de dados possa absorver completamente. O FREEFORM utiliza GPT-4o como backbone principal para racioc\u00ednio de alto n\u00edvel sobre quais features construir, implementando princ\u00edpios de chain-of-thought<\/em> e ensembling para aumentar a robustez.<\/p>

    Os resultados revelam algo not\u00e1vel: os modelos de linguagem mais fracos foram surpreendentemente competitivos com o GPT-4o na tarefa de engenharia de features<\/strong>, sugerindo que a capacidade de construir termos de intera\u00e7\u00e3o e express\u00f5es multiplicativas simples est\u00e1 dentro das capacidades de racioc\u00ednio da maioria dos LLMs modernos. A limita\u00e7\u00e3o encontrada foi na sele\u00e7\u00e3o de features altamente espec\u00edficas (como variantes gen\u00e9ticas associadas a condi\u00e7\u00f5es raras), onde o conhecimento especializado codificado nos pesos do LLM pode ser incompleto ou inconsistente.<\/p>

    Este resultado tem implica\u00e7\u00f5es importantes: os LLMs s\u00e3o mais eficazes como motores de engenharia de features quando o dom\u00ednio \u00e9 suficientemente coberto por seu treinamento. Em dom\u00ednios altamente especializados ou com literatura muito recente, o conhecimento de dom\u00ednio humano permanece insubstitu\u00edvel.<\/p>

    \u00a0<\/h2>

    Os limites dos LLMs na Engenharia de Features<\/h2>

    A euforia com os resultados promissores n\u00e3o pode obscurecer as limita\u00e7\u00f5es significativas e bem documentadas dos LLMs neste papel. Uma an\u00e1lise honesta exige que estas sejam discutidas com o mesmo rigor.<\/p>

    Alucina\u00e7\u00f5es e transforma\u00e7\u00f5es inv\u00e1lidas<\/h3>

    LLMs podem gerar c\u00f3digo Python sintaticamente correto que \u00e9 semanticamente inv\u00e1lido no contexto do problema. O CAAFE mitigou este risco implementando valida\u00e7\u00e3o em m\u00faltiplos est\u00e1gios \u2014 parsing de AST, execu\u00e7\u00e3o em sandbox, verifica\u00e7\u00e3o de performance emp\u00edrica \u2014 mas n\u00e3o eliminou completamente o problema. Frameworks sem esta camada de valida\u00e7\u00e3o podem introduzir features que parecem razo\u00e1veis mas s\u00e3o matematicamente incoerentes ou produzem vazamento de dados (data leakage).<\/p>

    Limita\u00e7\u00f5es de contexto e escala<\/h3>

    Datasets com muitas features e muitas amostras rapidamente excedem as janelas de contexto dos LLMs. O CAAFE, por exemplo, tem suas limita\u00e7\u00f5es operacionais em torno de 100 features \u2014 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\u00e7\u00f5es comprimidas dos dados, potencialmente perdendo informa\u00e7\u00f5es relevantes.<\/p>

    Depend\u00eancia de descri\u00e7\u00f5es de qualidade<\/h3>

    A efic\u00e1cia de frameworks como CAAFE e LLM-FE \u00e9 fortemente condicionada pela qualidade das descri\u00e7\u00f5es textuais fornecidas pelo usu\u00e1rio. Quando nomes de colunas s\u00e3o cr\u00edpticos (ex.: “var_1”, “col_42”) ou quando as descri\u00e7\u00f5es do dataset s\u00e3o vagas, o LLM perde seu principal diferencial \u2014 o conhecimento de dom\u00ednio \u2014 e sua performance regride para n\u00edveis pr\u00f3ximos aos de m\u00e9todos de AutoFE sem contexto sem\u00e2ntico.<\/p>

    Dados sens\u00edveis e privacidade<\/h3>

    Frameworks que dependem de LLMs hospedados em nuvem (como GPT-4 via API da OpenAI) s\u00e3o inadequados para datasets contendo informa\u00e7\u00f5es sens\u00edveis. O paper FeRG-LLM (NAACL 2025, Findings) explicita esta limita\u00e7\u00e3o e prop\u00f5e uma alternativa baseada em modelos locais (Llama 3.1 de 8B par\u00e2metros), demonstrando que a funcionalidade pode ser preservada sem enviar dados a servidores externos \u2014 mas a um custo de performance.<\/p>

    Custo computacional e financeiro<\/h3>

    A itera\u00e7\u00e3o entre gera\u00e7\u00e3o de features, re-treinamento do modelo downstream e avalia\u00e7\u00e3o de performance pode ser computacionalmente cara, especialmente com datasets maiores. O CAAFE estima um custo de aproximadamente US$ 0,50 por 10 itera\u00e7\u00f5es em um dataset de 1.000 linhas e 10 colunas usando GPT-4 \u2014 o que escala rapidamente para problemas mais complexos e pode tornar a abordagem invi\u00e1vel em contextos de or\u00e7amento limitado.<\/p>

    \u00a0<\/h2>

    O conhecimento de dom\u00ednio n\u00e3o \u00e9 opcional<\/h2>

    Um dos argumentos mais sofisticados em defesa da relev\u00e2ncia cont\u00ednua da feature engineering humana \u00e9 epistemol\u00f3gico, n\u00e3o apenas pr\u00e1tico. Ele diz respeito \u00e0 natureza do conhecimento que informa boas features.<\/p>

    O conhecimento de dom\u00ednio necess\u00e1rio para construir features verdadeiramente poderosas frequentemente n\u00e3o est\u00e1 dispon\u00edvel em forma textual process\u00e1vel por LLMs. Ele est\u00e1 em:<\/p>