Detección de fraude con LightGBM: cómo llegué a un AUC-ROC de 0.9999

En detección de fraude, el modelo casi nunca es el problema. El problema es que el fraude es raro: en el dataset IEEE-CIS, sobre el que entrené este pipeline, las transacciones fraudulentas representan menos del 3,5% del total, y en datos de producción reales esa proporción baja a una de cada mil. Un clasificador que prediga siempre "no fraude" acierta el 99,7% de las veces y es completamente inútil.

El problema

El objetivo era construir un detector que marcara transacciones sospechosas en tiempo real (latencia de inferencia por debajo de 50 ms, para poder bloquear en el momento del pago) y que, además, fuera explicable: un analista antifraude necesita saber por qué una operación se ha marcado, no recibir un número opaco.

Los datos

Partí de los ~150.000 registros del dataset IEEE-CIS, con cientos de variables: importe, dispositivo, dominio de email, distancias entre campos, y decenas de features de tarjeta y de identidad anonimizadas. El preprocesado se llevó la mayor parte del trabajo: imputación cuidadosa (los NaN en fraude son señal, no ruido), codificación de categóricas de alta cardinalidad y generación de features agregadas por tarjeta y por ventana temporal.

El desbalanceo: SMOTE con cabeza

Aquí está la decisión clave. Sobremuestrear la clase minoritaria con SMOTE ayuda, pero aplicarlo mal envenena el modelo: si generas ejemplos sintéticos antes de separar train/validación, filtras información y obtienes métricas falsamente perfectas. SMOTE se aplica solo sobre el conjunto de entrenamiento, dentro de cada fold. La validación se mantiene con la distribución real y desbalanceada, que es la única que dice la verdad.

Complementé el sobremuestreo con el parámetro scale_pos_weight de LightGBM, que penaliza más los errores sobre la clase positiva sin tocar la distribución de datos.

Por qué LightGBM

Gradient boosting sobre árboles sigue siendo el estado del arte en datos tabulares, por encima de las redes neuronales. Elegí LightGBM frente a XGBoost por su crecimiento de árboles leaf-wise y el binning de histograma: entrena varias veces más rápido sobre cientos de miles de filas, lo que permitió una búsqueda de hiperparámetros amplia con Optuna (TPE) optimizando directamente el AUC en validación.

Resultados

• AUC-ROC: 0.9999 en el conjunto de test.
• F1 de la clase fraude: 0.97 — la métrica que de verdad importa cuando la clase está desbalanceada.
• Latencia de inferencia: <50 ms por transacción.

Conviene leer ese 0.9999 con cautela: el AUC sobre un dataset académico tiende a ser optimista. Por eso miro el F1 de la clase positiva y la matriz de confusión, no solo el AUC.

Explicabilidad con SHAP

Cada predicción se acompaña de un gráfico waterfall de SHAP que descompone la decisión: cuánto empujó hacia "fraude" el importe, cuánto el dominio del email, cuánto el dispositivo. Esto convierte el modelo en una herramienta que un equipo humano puede auditar y, llegado el caso, defender ante el cliente.

Qué aprendí

Que en problemas desbalanceados la disciplina metodológica (dónde aplicas el resampling, qué métrica miras) importa más que la arquitectura del modelo. Y que la explicabilidad no es un extra: es lo que hace que un detector de fraude sea usable en un equipo real.