Detección de fraude con datos públicos: la métrica que importa cuando el 0.17% de los registros es fraude
Los sistemas de detección de fraude basados en reglas detectan el fraude del año pasado y saturan a los analistas con falsos positivos. El aprendizaje automático es el siguiente paso evidente, y las diapositivas de todos los proveedores muestran un ROC-AUC cercano a 0.98. Construimos una prueba de concepto — como investigación, con un conjunto de datos público, no para un cliente — para entender qué significa realmente esa cifra cuando el fraude representa una fracción de un punto porcentual de los datos.
Qué construimos
El conjunto de datos es el de transacciones europeas con tarjeta disponible públicamente en Kaggle: transacciones reales y anonimizadas, con un 0.1727% etiquetado como fraude. Reservamos un conjunto de prueba de 56,962 registros y entrenamos cuatro clasificadores con el resto — regresión logística como modelo de referencia, y luego XGBoost, CatBoost y LightGBM. Sin modelos de grafos, sin puntuación en tiempo real, sin asistente de investigación: cuatro modelos, una pregunta.
La pregunta era en qué métrica confiar.
Qué medimos
En el conjunto de prueba reservado:
| Modelo | ROC-AUC | PR-AUC |
|---|---|---|
| XGBoost | 0.9804 | 0.8770 |
| CatBoost | 0.9768 | 0.8757 |
| Regresión logística | 0.9736 | 0.7222 |
| LightGBM | 0.9529 | 0.8518 |
Lee la primera columna y todos los modelos parecen excelentes. Lee la segunda y el panorama cambia: el modelo de referencia que obtiene 0.97 en ROC-AUC cae a 0.72 en precisión-exhaustividad, y la diferencia entre los modelos con boosting y el de referencia — pequeña en la métrica que todos citan — es grande en la que describe el día del analista.
El hallazgo
ROC-AUC favorece a los modelos de eventos poco frecuentes. Cuando el 99.83% de los registros es legítimo, un modelo puede ordenar casi todo correctamente y aun así enviar al equipo de fraude una cola de alertas en su mayoría equivocadas. ROC-AUC premia ese ordenamiento. El AUC de precisión-exhaustividad plantea la pregunta que el equipo realmente tiene — de las alertas que genero, cuántas son fraude y cuánto fraude se me escapa — y esa es la cifra que debe ir en la diapositiva.
Los dos modelos con boosting están muy cerca, y la elección es operativa. XGBoost y CatBoost difieren apenas por un error de redondeo en ambas métricas. Cuál se implementa depende de la latencia, las herramientas y quién lo mantiene — no de la clasificación de resultados. (Nuestro propio README nombró a CatBoost como ganador; las cifras del notebook señalan a XGBoost. La fuente es el notebook; estamos corrigiendo el README. Ese es el tipo de discrepancia que un conjunto de evaluación existe para detectar.)
Vale la pena conservar el modelo de referencia. La regresión logística con un PR-AUC de 0.72 es el modelo que implementas en la primera semana mientras el modelo con boosting se gana su lugar, y el que el equipo de cumplimiento puede interpretar.
Qué todavía necesitaría un sistema en producción
Todo lo que esta POC deliberadamente no hizo. Tus propias transacciones, bajo tus propios controles, con el equilibrio de clases que realmente tienes. Variables derivadas de relaciones — cuentas que comparten dispositivos o direcciones de pago — que un clasificador de un solo registro no puede ver: ahí es donde las variables de grafos justifican su costo. Puntuación en tiempo real para los pagos, un registro de auditoría que un regulador pueda revisar, monitoreo para el día en que el fraude se adapte al modelo y, sobre todo, una cola de alertas ajustada junto con los analistas que la usarán: la priorización y la explicación determinan si un modelo se utiliza, y ninguna métrica offline mide eso.
Este caso de uso está más alejado del software que usa la mayoría de las empresas que los otros que prototipamos. Aun así, nos enseñó algo general: elige la métrica que describe el día de la persona, no la que mejor se ve en la diapositiva.