Cuarto proyecto y un enemigo nuevo: el desbalanceo extremo. Vas a construir un detector de transacciones fraudulentas con tarjeta en el que solo el 1 % de los casos son fraude — el escenario donde la accuracy engaña, los umbrales se deciden en euros y las métricas del módulo 6 se ganan el sueldo. El problema te resultará familiar por partida doble: es el detector de spam del teorema de Bayes de 02-05 con dinero en juego, y el pariente supervisado de las anomalías en pedidos que cazaste con DBSCAN en 05-04 — solo que aquí sí tenemos etiquetas históricas de fraude, así que podemos entrenar clasificadores. Usaremos un dataset sintético generado en el propio código (los datasets reales de fraude son confidenciales por naturaleza; el clásico público de Kaggle llega anonimizado por PCA), lo que además nos da control total sobre el experimento.

1. Definición del problema, costes y métrica objetivo
2. Generación del dataset sintético
3. EDA con clases desbalanceadas
4. Por qué la accuracy miente al 99 %
5. Estrategias contra el desbalanceo
6. Modelado y comparación con CV
7. La curva precision-recall y el AUC-PR
8. El umbral óptimo, en euros
9. Evaluación final en test
10. Conclusiones y conexión con producción

• Problema: clasificación binaria — ¿esta transacción es fraudulenta (1) o legítima (0)?
• La asimetría que lo gobierna todo: los dos errores no cuestan lo mismo. Un fraude no detectado (falso negativo) cuesta el importe defraudado más la gestión, digamos 150 € de media; bloquear una transacción legítima (falso positivo) cuesta la revisión manual y la fricción con el cliente, digamos 5 €. Esta matriz de costes, como aprendiste en 06-04 "Curva ROC y AUC", decidirá el umbral.
• Métricas: precision, recall y F1 de la clase fraude (06-02 "Métricas de evaluación"), curva precision-recall con su AUC-PR como métrica de comparación entre modelos, y el coste total en euros como métrica final de negocio. La accuracy queda vetada, y enseguida verás por qué.

make_classification genera un problema de clasificación con estructura controlada; con weights=[0.99, 0.01] imponemos el desbalanceo. Después vestimos las features abstractas con nombres y escalas realistas para poder razonar como analistas:

Qué estamos simulando y qué no: las columnas generadas son combinaciones gaussianas abstractas a las que ponemos nombres para razonar con ellas — la estructura del problema (pocas features informativas, 1 % de positivos, algo de ruido en etiquetas) sí es fiel a la realidad; los valores no son horas ni euros literales. En un caso real, features como dist_domicilio_km o ratio_importe_medio saldrían de la ingeniería de características de 03-06 sobre el historial del titular — exactamente como construiste el RFM de MercaFresh.

Dividimos estratificando, imprescindible con un 1 % de positivos (06-01):

Con desbalanceo, los histogramas globales son inútiles: los fraudes desaparecen bajo la masa legítima. La herramienta correcta es comparar distribuciones por clase:

El density=True es la clave: normaliza cada histograma para poder superponer 370 fraudes sobre 37.000 legítimas. Busca las features donde las dos campanas se separan (las informativas) y las que se solapan por completo (las que apenas aportarán). Este mismo gráfico, comparando "hoy" contra "el histórico", será tu detector de drift en producción — lo retomamos al final.

El experimento que lo demuestra, con el DummyClassifier en el papel de estafador de métricas:

Un modelo que dice "todo es legítimo" acierta el 99 % de las veces y no detecta un solo fraude: coste total = todos los fraudes pagados. Es el ejemplo canónico de 06-02: cuando las clases están desbalanceadas, la accuracy mide sobre todo la proporción de la clase mayoritaria. Desde aquí, precision/recall/F1 de la clase fraude y euros.

Tres familias, de más simple a más invasiva:

1. class_weight="balanced": el modelo pondera cada ejemplo de fraude ~99 veces más en su función de pérdida. No toca los datos, una línea, casi siempre lo primero que probar.
2. Mover el umbral: entrenar normal, pero no cortar en 0,5 sino donde la matriz de costes diga (06-04). Es la estrategia más honesta porque separa el modelo (probabilidades) de la decisión (umbral de negocio).
3. Remuestreo: cambiar el propio train. Sobremuestrear la minoría (duplicar fraudes, o generar sintéticos interpolados con SMOTE, disponible en la librería imbalanced-learn) o submuestrear la mayoría. En código lo ilustramos con resample de sklearn:

Regla de oro: el remuestreo se aplica solo al train, jamás al test (queremos evaluar contra la realidad del 1 %) y, si se combina con CV, dentro de cada partición — remuestrear antes de dividir duplica fraudes entre train y validación: la fuga de 06-01 en versión desbalanceada.

Tres modelos del curso con class_weight donde existe, comparados con CV estratificada (06-03) sobre AUC-PR (average_precision), recall y precision:

Resultados orientativos:

Fíjate en que las columnas @0,5 son casi anecdóticas: dependen de un umbral que aún no hemos decidido. El AUC-PR, en cambio, evalúa la calidad del ranking de probabilidades en todos los umbrales a la vez — por eso es la métrica de comparación. Y una nota sobre ROC-AUC: con 1 % de positivos suele salir altísimo (0,95+) para todos, porque los verdaderos negativos abundantes lo inflan; la curva precision-recall, que ignora los verdaderos negativos, es mucho más exigente y realista aquí. Es el matiz final que quedó apuntado en 06-04.

Elegido el HistGradientBoosting, dibujamos su curva con probabilidades de CV (sin tocar test):

La línea gris es humillante y necesaria: un clasificador aleatorio tiene precision = 1 % en este problema. Toda la curva por encima es mérito del modelo. La curva es un menú de compromisos: cada punto es un umbral posible — más recall (cazar más fraudes) pagando precision (más falsas alarmas). ¿Cuál elegir? El que minimice euros.

Aplicamos la matriz de costes a cada umbral candidato, como en 06-04 pero con moneda:

Con un falso negativo 30 veces más caro que un falso positivo, el umbral óptimo cae muy por debajo de 0,5 (típicamente entre 0,05 y 0,15): compensa revisar muchas transacciones legítimas con tal de cazar más fraudes. Compara el coste del umbral óptimo con dos referencias: el umbral 0,5 "por defecto" y la política "no bloquear nada" (= todos los fraudes pagados). La diferencia, en euros, es el argumento con el que este proyecto se defiende ante negocio — mucho más persuasivo que cualquier F1.

Entrenamos con todo el train, aplicamos el umbral decidido y abrimos el test una única vez:

El informe final debe contar tres números: recall de fraude (qué fracción del fraude cazamos), precision (qué fracción de las alertas son reales — es la carga de trabajo del equipo de revisión) y el ahorro en euros frente a no hacer nada. Si coinciden razonablemente con lo estimado en CV, el protocolo fue limpio.

• Dividir sin estratificar. Con 1 % de positivos, una división aleatoria puede dejar el test casi sin fraudes y las métricas se vuelven ruido. stratify=y siempre.
• Remuestrear antes de dividir. Duplicar fraudes y luego repartir train/test pone copias del mismo fraude a ambos lados: métricas infladas e ilusorias. Remuestreo solo en el train, y dentro de cada partición si hay CV.
• Presumir de ROC-AUC. Un 0,95 de ROC-AUC con 1 % de positivos puede convivir con una precision del 8 %. Reporta AUC-PR y la curva precision-recall.
• Fijar el umbral con el test. El umbral es un hiperparámetro de la decisión: se elige con CV sobre el train. Elegirlo mirando el test es sobreajustar la decisión final.
• Dar la matriz de costes por eterna. Los 150 €/5 € son estimaciones de negocio que cambian (importes medios, coste del equipo de revisión). Documenta las cifras y recalcula el umbral cuando cambien.

1. IsolationForest, el primo no supervisado. Entrena sklearn.ensemble.IsolationForest ignorando las etiquetas y comprueba cuántos fraudes reales aparecen entre sus anomalías, conectando con el enfoque de 05-04 "Análisis de agrupamiento DBSCAN". Pista: usa contamination=0.01; es la herramienta para el arranque en frío, cuando aún no hay etiquetas históricas.
2. Sensibilidad a la matriz de costes. Recalcula el umbral óptimo para varios escenarios (FN = 50 €, 300 €; FP = 1 €, 20 €) y dibuja cómo se mueve. Pista: si el umbral óptimo apenas cambia entre escenarios plausibles, tu decisión es robusta; si baila, negocio debe afinar sus estimaciones antes de desplegar.
3. Drift temporal. Simula que el fraude evoluciona: genera un segundo dataset con random_state distinto y algo más de class_sep o un desplazamiento sumado a dos features, y evalúa el modelo antiguo sobre él. Pista: mide cuánto caen recall y AUC-PR y qué histogramas por clase delatan el cambio — estás reproduciendo en miniatura el ciclo de 08-03.

Este proyecto te ha enseñado a trabajar cuando la clase que importa es una aguja en un pajar: estratificar todo, desconfiar de la accuracy (y hasta del ROC-AUC), comparar modelos por AUC-PR, y sobre todo separar el modelo de la decisión — las probabilidades las da el algoritmo, el umbral lo dan los euros, exactamente el método de 06-04 llevado a sus últimas consecuencias. También has visto el arsenal contra el desbalanceo (pesos de clase, umbral, remuestreo) y sus trampas. Y queda la advertencia final, que conecta con 08-02 "Implementación de modelos en producción" y 08-03 "Mantenimiento y monitoreo de modelos": el fraude es el problema con más drift que existe, porque al otro lado hay adversarios que se adaptan a tu detector — el modelo que hoy ahorra miles de euros se degrada en meses, y el monitoreo por histogramas y el reentrenamiento periódico no son opcionales sino parte del producto. Con esto cierras el bloque de proyectos supervisados; en el último proyecto volvemos a casa, a MercaFresh, para cerrar el círculo con el aprendizaje no supervisado: segmentar a los clientes de principio a fin.