Detección de fraude: por qué tu modelo está mal evaluado

El 0.1% de las transacciones es fraude. Ese número rompe casi todo lo que aprendiste de clasificación. Si evalúas tu modelo de fraude como uno normal, te está mintiendo. Trabajé riesgo y datos en banca, y el fraude es otro animal —por una razón que casi nadie menciona.

Por qué el fraude es distinto a la mora

La mora es un fenómeno relativamente estable: la gente no deja de pagar para engañar a tu modelo. El fraude sí: hay un adversario que se adapta. El patrón que detectas este mes, el defraudador lo cambia el siguiente —justamente porque lo detectaste. No estás prediciendo: estás persiguiendo a alguien que sabe que lo persigues. Eso cambia cómo entrenas (reentrenamiento frecuente) y cómo evalúas (sobre datos recientes, no históricos).

La trampa de la métrica

Con 0.1% de positivos, un modelo que dice "no hay fraude" a todo tiene 99.9% de accuracy. Inútil. Y el AUC ROC se ve hermoso incluso cuando el modelo es malo, porque hay un océano de negativos que infla la curva. La métrica honesta acá es precision-recall (el área bajo esa curva) y, sobre todo, el costo real de cada tipo de error.

El umbral se elige por costo, no por F1

Bloquear una compra legítima molesta a un cliente bueno y cuesta. Dejar pasar un fraude cuesta mucho más, y a veces es un tema regulatorio. Esos dos costos no son simétricos, y casi nunca los conoce el científico de datos solo: se definen con negocio y con riesgo. El mejor modelo de fraude es una conversación de costos con un modelo adentro.

La idea que se queda

El fraude no se gana con el algoritmo más complejo. Se gana entendiendo el desbalance, midiendo con la métrica correcta y poniéndole precio al error —antes de elegir el umbral, no después.

Ver en video

El desarrollo completo —adversario, métricas y umbral por costo— está en mi canal: Cristina Chapoñán | Data & IA — busca "Detección de fraude: por qué tu modelo está mal evaluado".

¿Mides tus modelos desbalanceados con ROC o con precision-recall? ¿Por qué? Cuéntame.