Cuando tus "mejores" features empeoran el modelo

Cuando tus "mejores" features empeoran el modelo

¿Conoces esa sensación? Pasas días diseñando una feature preciosa. Captura exactamente la señal que buscabas. Entrenas, evalúas, y el F1 de la Clase 2 sube de 0.72 a 0.78. Sonríes. Mandas al leaderboard y... tu puntuación bajó. Qué pasó? Acabas de chocarte con el trade-off del feature engineering.

Es una trampa en la que cae casi todo data scientist al menos una vez. Yo caí hace unos meses y me costó una semana entera de debugging. Así que déjame explicarte qué pasa realmente bajo el capó, por qué tus features manuales tan listas pueden volverse en tu contra, y cómo montar un workflow de evaluación que no te mienta.

La trampa clásica: la victoria de una métrica es la derrota de otra

Te pinto el escenario exacto. Estaba construyendo un modelo multi-clase para un cliente. El baseline iba bien. Añadí dos features hechas a mano: **Gravedad del Impacto** y **Ratio Energético**. Ambas salían de datos de sensores crudos, pensadas para pillar una clase de fallo rara. Tenían sentido físico. En validación, el F1 de la Clase 2 subió de 0.72 a 0.78. Bonito, ¿no?

Pues no tan rápido. Cuando miré el panorama completo, el F1 de la Clase 0 y la Clase 1 había bajado en ambas. El leaderboard —que usaba una media ponderada entre todas las clases— era más bajo que mi baseline. El modelo había aprendido a sacrificar las clases mayoritarias para que la minoritaria luciera mejor.

Esto no es mala suerte. Es la realidad matemática de un presupuesto de probabilidad compartido. En la mayoría de modelos multi-clase, subir la confianza de una clase reduce la de otra. Si tus features nuevas correlacionan mucho con las existentes, no estás añadiendo información —estás amplificando ruido y sesgo.

¿Por qué las features manuales se vuelven en contra?

La multicolinealidad es un asesino silencioso

Cuando tu feature nueva correlaciona con dos o tres existentes, el modelo reparte el crédito entre ellas. En modelos basados en árboles, esto puede esconder splits importantes. En modelos lineales, infla coeficientes. Resultado: predicciones menos estables, sobre todo en datos nuevos.

Lo peor es que la multicolinealidad no siempre daña el accuracy en training. Hasta puede ayudarte a memorizar ruido. Pero en cuanto la distribución de test se mueve un poco, tu feature tan lista se convierte en una losa.

El trade-off Precision/Recall

Si diseñaste una feature para encontrar la Clase 2, probablemente subes recall para la Clase 2 mientras destruyes precision para la Clase 1. Imagina que el threshold se mueve. Más ejemplos caen en Clase 2, pero muchos son en realidad Clase 1 o Clase 0. Tu macro score baja aunque tu "clase objetivo" mejore.

Lo veo constantemente en detección de fraude. Alguien construye una feature que pilla más fraude, pero también marca un montón de transacciones legítimas. El recall de fraude sube, pero el false positive rate se duplica. En el mundo real eso significa clientes enfadados y un equipo de soporte muy estresado.

Las métricas de leaderboard suelen ser agregadas

La mayoría de leaderboards usan una métrica escalar única —accuracy, macro-F1, kappa ponderado, log loss. Ese escalar esconde el desglose por clase. Si optimizas para un trozo, no estás optimizando para el todo. Una ganancia de cinco puntos en F1 de Clase 2 puede borrarse con una caída de tres puntos en otras dos clases, según los pesos.

Por eso lo primero que hago ahora es leer la métrica de la competición o proyecto con lupa. Si es weighted F1, las mejoras en una clase rara valen poco. Si es macro-F1, todas las clases pesan igual, incluso las que no te importan.

Un caso real: datos de sensores

Vamos con un ejemplo concreto. Imagina una planta con sensores de temperatura, vibración y presión. Baseline: 0.85 macro-F1 en tres clases de fallo.

Creé un **ratio energético** = amplitud vibración / varianza presión. Tenía sentido físico. Impactos de alta energía deberían indicar fallos graves. En training, el F1 de Clase 2 subió a 0.81. Pero en cross-validation la ganancia no aguantaba. Por qué? El ratio energético correlacionaba mucho con vibración y presión en crudo —multicolinealidad otra vez. En test, ruido de sensor a baja presión hacía explotar el ratio, mandando al modelo a falsos positivos de Clase 2.

La solución fue contraintuitiva: en vez de añadir el ratio crudo, usé una feature residual —la parte de vibración *no* explicada por presión. Esa señal ortogonal sí añadía info nueva, y el leaderboard subió en todas las clases. Lección: no preguntes "¿mi feature tiene sentido?". Pregunta "¿mi feature da info que mi modelo actual no tiene ya?".

Otro ejemplo: predicción de churn en e-commerce

Trabajé con una empresa de cajas por suscripción. Marketing quería un **score de engagement** combinando frecuencia de login, tickets de soporte y menciones en redes. Sonaba genial. Pero el score era solo una suma ponderada de features existentes. Al añadirlo al modelo, los rankings de importancia se movieron, pero el AUC se quedó plano. Peor: la calibración empeoró para usuarios de bajo engagement porque el score dominaba la loss.

Acabamos cambiando el score artesanal por un simple conteo de categorías de features distintas contactadas en los últimos siete días. Esa feature pequeña, menos correlacionada, dio un lift real. La lección se repite: a veces la feature menos llamativa es la mejor.

Cómo evaluar features sin que te engañen

1. Monta un scorecard multi-métrica

No.trackees solo F1 de Clase 2. Haz un scorecard que incluya:

- Macro-F1 y weighted-F1
- Precision y recall por clase
- Log loss o Brier score (para calibración)
- Una nota de si las métricas por clase se movieron en la misma dirección

Esto es lo que suelo imprimir tras cada experimento:

| Métrica | Baseline | Feature Nueva | Veredicto |
|---|---|---|---|
| Clase 0 F1 | 0.88 | 0.84 | Mal |
| Clase 1 F1 | 0.82 | 0.79 | Mal |
| Clase 2 F1 | 0.72 | 0.78 | Bien |
| Macro-F1 | 0.81 | 0.80 | Mal |

Un vistazo y la historia está clara. La feature brillante ayudó a una clase pero jodió a las otras. Sin este scorecard, habría mandado el modelo y me habría llevado la sorpresa.

2. Haz una auditoría de correlación

Antes de añadir una feature manual, mira su correlación con las existentes. Usa `df.corr()` de pandas y busca valores absolutos فوق 0.7. Si tu feature nueva está muy pegada a las viejas, plantea:

- Tirar una de las redundantes
- Residualizar (regresar la feature nueva sobre las viejas, quedarte con el residuo)
- Selección de features con `SelectKBest` o `RFECV` de scikit-learn

La guía oficial de feature selection de scikit-learn tiene enfoques muy prácticos: https://scikit-learn.org/stable/modules/feature_selection.html

3. Usa SHAP para ver efectos direccionales

Tras entrenar, calcula valores SHAP para ver exactamente cómo afecta tu feature nueva a cada clase. A veces una feature sirve para Clase 2 pero daña activamente a Clase 1. Un summary plot de SHAP te lo enseña al momento. La librería es open-source y bien mantenida en https://github.com/shap/shap.

He pillado varias features "geniales" que tenían SHAP fuertemente positivos para una clase pero aún más negativos para otra. Ese es el trade-off que necesitas ver *antes* de subir.

4. Prueba ablaciones

Ablación = quitar una feature y ver qué pasa. Sorprendentemente raro en feature engineering manual. Yo siempre corro tres experimentos:

- Baseline con features viejas
- Baseline + feature nueva
- Baseline + feature nueva, menos una vieja correlacionada

Si el tercero gana al segundo, resolviste multicolinealidad. Si el segundo pierde contra el primero, quita la feature. Si el segundo gana pero el leaderboard dice lo contrario, investiga tu setup de validación.

Un tercer ejemplo: clasificación de triaje médico

Una vez trabajé con un prototipo de symptom-checker. Objetivo: triar pacientes en tres niveles de urgencia. Construí un **score de comorbilidad** sumando condiciones pre-existentes. Mejoraba detección de alta urgencia, pero hacía que el modelo ignorara la gravedad del síntoma *actual*. Un paciente con un síntoma leve y una comorbilidad caía en alta urgencia, aunque su riesgo real era bajo.

El problema: mi feature era demasiado dominante. El modelo se enganchó a ella porque era fácil de splitear, e ignoró las features de texto más ricas y matizadas. Este es otro trade-off clave: **dominancia de feature**. Una feature artesanal fuerte puede desplazar a otras más débiles pero más informativas. Regularización e interacciones ayudan, pero lo simple suele ganar.

La lección grande: las features no son gratis

Cada feature que añades sube complejidad, tiempo de entrenamiento, y riesgo de overfitting. La regularización ayuda, pero no arregla una feature fundamentalmente redundante. Hay que ver cada feature como una apuesta: debe justificar su sitio añadiendo señal nueva y estable en múltiples métricas.

También aprendí que cuando el leaderboard baja tras añadir una feature, la causa casi nunca es "la métrica está mal". Es que perseguía un óptimo local. El modelo no es tonto —hace exactamente lo que le pedí. Yo pedí lo equivocado.

FAQ

¿Por qué mi F1 subió en una clase pero mi score total en leaderboard bajó?

Porque el leaderboard probablemente usa media ponderada o macro. Tu modelo puede estar sacrificando precision o recall en otras clases para ganar en la que te enfocaste. Evalúa siempre la matriz de confusión completa antes de emocionarte.

¿Cuál es la mejor forma de manejar features multicolineales?

Mira correlación primero. Si dos features correlacionan mucho, tira una o usa versión residualizada de la nueva. Regularización tipo L1 o L2 puede estabilizar, pero quitar redundancia suele ser más efectivo que parchear con penalizaciones.

¿El feature engineering manual sigue sirviendo en ML moderno?

Sí, pero solo cuando codifica conocimiento de dominio que no está ya en el modelo. Si una feature es solo combinación matemática de las existentes, suele no ayudar. Si captura señal genuina nueva, puede ser potente. La clave es verificar que *realmente* añade info independiente.

¿Cómo sé si una feature de verdad ayuda?

Compara baseline y modelo con la feature usando múltiples métricas y cross-validation. Haz ablación. Mira feature importance y SHAP. Si la mejora es inconsistente entre folds o métricas, probablemente estés overfitteando ruido.

Reflexiones finales

Conozco el subidón de construir la feature perfecta. Sientes que has descifrado el código. Pero el leaderboard es el árbitro final. Cuanto antes metas evaluación multi-métrica en tu workflow, menos tiempo perderás en features que solo ayudan a un trozo del problema.

La próxima vez que vayas a meter esa feature lista de "gravedad del impacto", para. Pregúntate: "¿Esto añade info nueva, o solo amplifica señal que ya tengo?". Tu yo del futuro —y tu ranking en el leaderboard— te lo agradecerán.