El catálogo de trampas de Data Science: 20 formas de que un modelo mienta con cara de éxito

Un accuracy del 95% no significa que tu modelo sea bueno. A veces significa que ni siquiera está haciendo su trabajo.

Hoy pedirle a una IA "armame un modelo de churn con este CSV" te devuelve, en menos de un minuto, un notebook prolijo, con gráficos lindos y una métrica alta. El costo de producir algo que parece correcto se desplomó a cero. Y ahí está el problema nuevo: si todo parece bien, lo único que quedó valioso es saber cuál de esas salidas está bien.

Distinguir plausible de correcto no es un don. Es un catálogo finito de trampas con las que todo el que lleva un tiempo se comió un garrón una vez y se lo tatuó. Este es ese catálogo. Para cada una: qué es (el mecanismo), cómo huele (la señal que la delata) y cómo la cazás (qué hacés). No es teoría: es la diferencia entre entregar un modelo que funciona y entregar confianza en basura.

Acto 1 — Trampas de datos (antes de modelar nada)

Estas son las peores, porque contaminan todo lo que viene después. Un modelo entrenado sobre datos con fuga puede dar métricas espectaculares y no servir para absolutamente nada en producción.

1. Fuga del objetivo (target leakage)

Qué es. Una de tus features contiene información que en la vida real no vas a tener en el momento de predecir, porque se genera después del evento que querés predecir. El caso clásico de churn: una columna fecha_de_baja o motivo_cancelacion que solo se llena cuando el cliente ya se fue. El modelo "aprende" a mirar esa columna y adivina el futuro con información del futuro.

Cómo huele. Métricas sospechosamente perfectas (99% de AUC), y una sola feature con una importancia que aplasta al resto. Cuando algo funciona demasiado bien, no festejes: desconfiá.

Cómo la cazás. Por cada columna, preguntate: "¿tendría este valor disponible en el instante exacto en que necesito predecir?". Si la respuesta es "no, esto se llena después" → afuera. Es la pregunta más importante de todo el proyecto y la que casi nadie se hace.

2. Fuga en el preprocesamiento (train/test leakage)

Qué es. Ajustás un StandardScaler, un imputador de faltantes o un encoder sobre todo el dataset y después hacés el split. El problema: el scaler ya "vio" la media y el desvío del test. Información del test se filtró al entrenamiento por la ventana de atrás. Tu evaluación queda inflada y mentirosa.

Cómo huele. El modelo valida bárbaro y en producción rinde peor, sin una explicación obvia.

Cómo la cazás. Primero spliteás, después ajustás — y solo sobre train. La forma de blindarlo es meter todo el preprocesamiento en un Pipeline de scikit-learn: el .fit se aplica solo al train dentro de cada fold, sin excepciones.

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

# El scaler se ajusta SOLO con el train de cada fold. Cero fuga.
pipe = Pipeline([
    ("scaler", StandardScaler()),
    ("clf", LogisticRegression()),
])
# cross_val_score parte internamente y ajusta el pipe fold por fold

3. Fuga temporal (usar split aleatorio en series de tiempo)

Qué es. Tus datos tienen orden temporal (ventas, sesiones, sensores) y hacés un train_test_split aleatorio. Terminás entrenando con datos de mañana para predecir hoy. En producción vas a predecir siempre hacia adelante, nunca hacia atrás.

Cómo huele. Backtest hermoso, desempeño real decepcionante. El modelo "sabía" tendencias futuras que no existían al momento de decidir.

Cómo la cazás. Split por tiempo, no al azar: entrenás con el pasado, validás con el futuro. Usá TimeSeriesSplit en vez de KFold. Y ojo con features que resumen el futuro (promedios calculados sobre toda la serie).

4. Desbalance de clases y la trampa del accuracy

Qué es. Cuando una clase es rara —churn 5%, fraude 0,1%, enfermedad 2%— predecir siempre la clase mayoritaria ("no churnea") ya te da 95% de accuracy sin que el modelo haya aprendido nada. El accuracy alto es un espejismo.

Cómo huele. Accuracy altísimo pero el modelo no detecta ni un solo caso de la clase que te importa. Mirás la matriz de confusión y la fila de la minoría está vacía.

Cómo la cazás. Mirá el balance de clases antes que cualquier métrica. Cuando hay desbalance, el accuracy no sirve: usá matriz de confusión, precision, recall, F1 y sobre todo PR-AUC (área bajo la curva precision-recall), que se concentra en la clase rara. Esta es la misma lógica de detectar fraude cuando el 0,1% es todo lo que importa.

5. Faltantes que no son aleatorios (MNAR)

Qué es. Rellenás los NaN con la media y seguís. Pero muchas veces que un dato falte es en sí mismo información: el ingreso lo dejan en blanco los que ganan mucho, la encuesta la abandonan los insatisfechos. Imputar con la media borra esa señal y sesga todo.

Cómo huele. Columnas con faltantes concentrados en un grupo, no repartidos al azar. Si el patrón de ausencia correlaciona con el target, es una bomba.

Cómo la cazás. Antes de imputar, estudiá por qué faltan. A veces la mejor feature es una bandera binaria estaba_vacío. Es lo que desarrollo en lo que los valores faltantes te están gritando.

6. Sesgo del superviviente

Qué es. Analizás solo los datos que "sobrevivieron" hasta llegar a tu tabla, ignorando los que se cayeron en el camino. El ejemplo de guerra: reforzar los aviones donde volvían agujereados, cuando había que reforzar donde no había agujeros (esos aviones no volvían). Tu dataset ya está filtrado por un proceso que no ves.

Cómo huele. Conclusiones sobre "clientes exitosos", "usuarios activos" o "campañas que funcionaron" sin mirar a los que abandonaron o nunca entraron.

Cómo la cazás. Preguntate siempre qué datos NO están en la tabla y por qué. El detalle completo, en el sesgo del superviviente.

Acto 2 — Trampas de evaluación (creer que medís lo que no medís)

Acá el modelo ya está entrenado. La trampa es convencerte de que anda bien cuando la vara con la que lo medís está torcida.

7. No tener un baseline

Qué es. Presentás "85% de accuracy" como un logro sin saber contra qué se compara. Si predecir la clase mayoritaria o la media histórica ya te da 84%, tu modelo carísimo aportó un 1%.

Cómo huele. Un número presentado solo, sin referencia. "Es bueno" no significa nada sin un "¿comparado con qué?".

Cómo la cazás. Siempre empezá por el baseline tonto: DummyClassifier/DummyRegressor, predecir la mayoría, la media, o "lo mismo que ayer". Tu modelo tiene que superarlo con claridad para justificar su existencia.

8. La métrica equivocada para el problema

Qué es. Optimizás accuracy cuando lo que importa es no dejar pasar un caso (recall) o no dar falsas alarmas (precision). En detección de fraude, un falso negativo cuesta miles; en un filtro de spam agresivo, un falso positivo te tira un mail importante a la basura. No todos los errores cuestan igual.

Cómo huele. La métrica se eligió por costumbre ("uso accuracy porque sí"), no por el costo real de cada tipo de error en el negocio.

Cómo la cazás. La métrica sale del negocio, no del default. Preguntá: ¿qué cuesta más, un falso positivo o un falso negativo? Elegí la métrica en función de eso. Lo trato en el costo oculto de los falsos positivos.

9. Data snooping y p-hacking

Qué es. Probás cientos de features, modelos y umbrales, y te quedás con la combinación que dio mejor en el test. Al hacerlo, ajustaste al ruido del test: encontraste algo "significativo" por puro azar. Con un umbral del 5%, de cada 20 cosas sin sentido que pruebes, una da significativa de casualidad.

Cómo huele. Un resultado brillante que apareció después de muchísima búsqueda, y que no se sostiene cuando lo probás en datos nuevos.

Cómo la cazás. Guardá un conjunto de test que se toca una sola vez, al final. Tomá las decisiones con validación cruzada sobre train. Y desconfiá de lo que pescaste entre miles de intentos: es la misma trampa detrás de lo que un p-valor NO significa y de las correlaciones espurias.

10. Overfitting disfrazado de buen resultado

Qué es. El modelo memoriza el train en vez de aprender el patrón general. Rinde perfecto en lo que ya vio y mal en lo nuevo.

Cómo huele. Brecha grande entre performance de train y de validación (99% vs 72%). Un modelo demasiado complejo para la cantidad de datos que tenés.

Cómo la cazás. Validación cruzada, regularización, y comparar siempre train contra validación. Si la brecha es grande, el modelo está memorizando. (Ojo, hay un fenómeno contraintuitivo donde pasarse de parámetros vuelve a mejorar: el doble descenso.)

11. Selección de features usando todo el dataset

Qué es. Elegís las "mejores" variables mirando su correlación con el target sobre todo el dataset, y recién después spliteás. Ya usaste el test para decidir. Es leakage otra vez, más sutil.

Cómo la cazás. La selección de features es parte del modelo: va dentro del pipeline y se ajusta solo con train, fold por fold. Nunca antes del split.

Acto 3 — Trampas de interpretación (los números te mienten en la cara)

El modelo puede estar bien y aun así vos podés leer mal lo que dice.

12. Confundir correlación con causalidad

Qué es. Dos cosas se mueven juntas y concluís que una causa la otra. Pero puede ser azar, una tendencia compartida, o una tercera variable que mueve a las dos. Que el helado y los ahogamientos suban juntos no significa que el helado ahogue: es el verano.

Cómo la cazás. Exigí un mecanismo plausible planteado antes de mirar los datos. Si no podés contar por qué A causaría B, tratá la correlación como sospechosa. Todo el desarrollo, en correlaciones espurias.

13. La paradoja de Simpson

Qué es. Una tendencia que existe en los grupos por separado se da vuelta cuando juntás todo. Un tratamiento puede ser mejor en hombres y mejor en mujeres, pero peor "en total", solo por cómo se reparten los casos.

Cómo huele. Un promedio global que contradice lo que ves cuando segmentás.

Cómo la cazás. Segmentá siempre por las variables relevantes antes de sacar conclusiones agregadas. El caso completo, en la paradoja de Simpson.

14. Mirar solo los números resumen

Qué es. Te quedás con la media, el desvío y la correlación, sin graficar. Dos datasets con estadísticas idénticas pueden tener formas completamente distintas: uno una recta, otro un dinosaurio.

Cómo la cazás. Graficá antes de concluir. Siempre. Es la lección del cuarteto de Anscombe y del Datasaurio: los números resumen esconden la forma.

15. Confundir importancia de features con causalidad

Qué es. El modelo dice que la feature X "pesa mucho" y concluís que X causa el resultado. La importancia mide poder predictivo, no causa. Una feature puede ser importante solo porque es proxy de otra cosa (o porque es leakage, ver trampa 1).

Cómo la cazás. Usá la importancia para entender el modelo, no el mundo. Para hablar de causa necesitás diseño experimental (A/B) o inferencia causal, no un ranking de importancias.

16. Extrapolar fuera del rango de entrenamiento

Qué es. El modelo aprendió con edades de 20 a 60 y le pedís que prediga para alguien de 90. Fuera del rango visto, la mayoría de los modelos inventan. Y en muchas dimensiones, casi todos los puntos nuevos están "lejos" de lo conocido.

Cómo la cazás. Conocé el rango de tus datos de entrenamiento y desconfiá de predicciones fuera de él. Es una cara de la maldición de la dimensionalidad.

Acto 4 — Trampas de producción (el modelo bueno que se pudre solo)

El modelo pasó todas las pruebas y salió a producción. El trabajo no terminó: acá empieza otro conjunto de trampas.

17. Data drift y concept drift

Qué es. El mundo cambia y tus datos de entrenamiento envejecen. Data drift: cambia la distribución de las entradas (llegó un público nuevo). Concept drift: cambia la relación entre entradas y salida (lo que predecía churn el año pasado ya no aplica). El modelo se degrada en silencio.

Cómo huele. Performance que baja de a poco sin que nadie tocó nada.

Cómo la cazás. Monitoreo continuo: comparás la distribución de los datos de producción contra los de entrenamiento y disparás una alarma cuando se despegan. El modelo no es un entregable, es algo vivo que hay que vigilar.

18. Training-serving skew

Qué es. Las features que calculás en producción no son idénticas a las que usaste al entrenar. Una unidad distinta, un timezone, un default que cambió, un cálculo hecho con otra librería. El modelo recibe algo levemente distinto a lo que aprendió.

Cómo huele. Métricas offline buenas, comportamiento raro online, sin explicación en el modelo.

Cómo la cazás. Reutilizá exactamente el mismo código de features en train y en serving (idealmente el mismo pipeline). Logueá las features de producción y compará con las de entrenamiento.

19. Feedback loops

Qué es. El modelo afecta los datos que va a usar en el futuro. Un recomendador que solo muestra ciertos productos hace que solo esos se compren, "confirmando" que eran los buenos. El modelo termina aprendiendo de sus propias decisiones y se muerde la cola.

Cómo la cazás. Reservá una fracción de tráfico aleatorio (exploración) para no aprender solo de lo que el modelo ya eligió. Y medí el efecto causal de las recomendaciones, no la correlación que el propio modelo generó.

20. Optimizar la métrica y no el objetivo (métrica como blanco)

Qué es. "Cuando una medida se vuelve el objetivo, deja de ser una buena medida" (ley de Goodhart). Optimizás clicks y llenás el producto de clickbait; optimizás tiempo en pantalla y arruinás la experiencia. La métrica sube y el negocio real empeora.

Cómo la cazás. Distinguí la métrica proxy (lo que medís) del objetivo real (lo que querés). Vigilá métricas de contrapeso (guardrails) que se caerían si estuvieras rompiendo algo aunque tu métrica principal suba.

El resumen que te llevás

Ninguna de estas trampas es magia negra. Son un catálogo finito, y cada senior las aprendió una por una, casi siempre a los golpes. La diferencia entre un análisis que parece correcto y uno que está correcto son estas veinte preguntas hechas a tiempo.

Tres reglas que las resumen casi todas:

• Si algo funciona demasiado bien, desconfiá. El 99% suele ser fuga, no talento.
• Splitteá primero, ajustá después — y no dejes que el test se filtre por ninguna ventana.
• La métrica y el mecanismo salen del negocio, no del default. Un número sin un "¿comparado con qué?" y sin un "¿por qué pasaría esto?" no prueba nada.

En una época donde producir un análisis cuesta cero, esto —saber ver el error que el resto deja pasar— es lo único que no se automatiza. No es lo que sabés escribir: es lo que sabés cazar.