Recuerdo perfectamente un proyecto donde, después de semanas intentando afinar un modelo de predicción con redes neuronales complejas, los resultados seguían siendo mediocres. La frustración era real. Revisé cada capa, cada hiperparámetro, y nada. Un colega, con mucha más calma que yo en ese momento, me preguntó: “¿Y qué hay de los datos brutos? ¿Has pasado tiempo de verdad con ellos?”. Esa pregunta me golpeó. Había caído en la trampa de buscar la solución en el algoritmo de moda, olvidando que la magia rara vez está ahí. La magia, o al menos el 80% de ella, suele estar en lo que le das de comer al modelo. Ahí es donde entra el feature engineering.
¿Qué es el “Feature Engineering” para mí?
Para mucha gente, “feature engineering” suena a pre-procesamiento de datos: escalar, codificar categóricas, imputar nulos. Sí, es parte de ello, pero para mí es mucho más profundo. Es el arte de usar el conocimiento del dominio para transformar los datos brutos en características que un algoritmo pueda entender y, lo que es más importante, usar para aprender patrones significativos. Es darle contexto y significado a los números y palabras.
Piénsalo así: si le das a tu modelo un puñado de números sin procesar de un sensor, probablemente se apañará para encontrar alguna correlación. Pero si tú, como experto, sabes que la variación de esos números en los últimos cinco minutos es un indicador clave de un fallo, y le proporcionas esa característica (la derivada, el rango, la media móvil), tu modelo no tendrá que “descubrir” esa relación. Se la has servido en bandeja. Es como darle el mapa del tesoro en lugar de solo las coordenadas.
Por qué me obsesiona (y me ahorra dolores de cabeza)
1. Modelos más simples, mejores resultados
He visto innumerables veces cómo un modelo simple (una regresión logística o un árbol de decisión) con características bien diseñadas supera a un modelo complejo de deep learning alimentado con datos brutos. ¿Por qué? Porque el feature engineering ya ha hecho gran parte del trabajo de extracción de patrones. Menos complejidad en el modelo significa menos riesgo de Overfitting y Underfitting y, a menudo, una inferencia más rápida. Si el problema puede resolverse con un cuchillo, ¿para qué usar una sierra mecánica?
2. Interpretación, no adivinanzas
Cuando trabajo en proyectos donde la explicabilidad es clave (y para mí, eso es casi siempre), las características claras son oro. Si mi modelo predice que un cliente va a abandonar, y puedo decir que la característica “número de llamadas al soporte en el último mes” es la que más peso tiene, tengo una historia que contar. Una historia que los stakeholders pueden entender y con la que pueden actuar. XAI es crucial, y el buen feature engineering es su mejor aliado. Es mi antídoto contra la “caja negra” que tanto me inquieta.
3. La verdad incómoda de los datos
Muchos se apresuran a buscar el último modelo de Transformers o la red neuronal más grande. Yo me pregunto: ¿y qué hay de los datos? Como ya he dicho en Datos para IA: La verdad incómoda que nadie quiere oír, la calidad y el significado de tus datos son el pilar. El feature engineering es la herramienta principal para maximizar ese significado. Es darle vida a esos datos inertes.
Mi proceso (sin recetas mágicas, solo disciplina)
Mi acercamiento al feature engineering no es una serie de pasos rígidos, sino una mentalidad.
- Entender el dominio, de verdad: Paso tiempo hablando con los expertos del negocio. ¿Qué variables usan ellos mentalmente para tomar decisiones? ¿Qué interacciones entre ellas son importantes? Sus intuiciones son mis hipótesis.
- Exploración profunda: Hago mucho análisis exploratorio. Visualizaciones, correlaciones, distribuciones. Busco anomalías, patrones ocultos, y empiezo a “sentir” los datos. Jupyter Notebooks y un buen café son mis compañeros aquí.
- Prototipar, iterar, validar: No me caso con la primera característica que se me ocurre. Pruebo, evalúo el impacto en el rendimiento del modelo (siempre con validación cruzada, claro), y lo más importante: me pregunto si la característica tiene sentido lógico. Si mi modelo mejora, pero la característica es un churro inexplicable, algo huele mal.
- No tener miedo a la sencillez: A veces, una característica es tan simple como un
if/elseo una resta. No hay que inventar la rueda si un tornillo simple hace el trabajo. De hecho, a menudo las más simples son las más robustas y explicables.
Lo que evito
- Crear características por crear: No se trata de tener más features, sino de tener las buenas. La redundancia o características irrelevantes solo añaden ruido y complican el modelo.
- Ignorar la distribución de los datos: Transformar características sin entender su distribución puede hacer más daño que bien. Logaritmos, raíces cuadradas, o transformaciones de Box-Cox tienen su momento y lugar.
- Data Leakage: Esto es un clásico. Crear características usando información que no estaría disponible en el momento de la predicción. Un error que te puede costar un proyecto. Siempre me lo pregunto: ¿este dato existirá cuando el modelo esté en producción?
En definitiva, el feature engineering no es una fase más de tu pipeline de ML; es una parte central, crítica, y la que a menudo diferencia un modelo que funciona en un demo de uno que aporta valor en el mundo real. Es mi superpoder cuando los algoritmos de moda no cumplen sus promesas, y te animo a que sea el tuyo también.