ML Portfolio · Eduardo Rdgz-Á
Modelo de ranking que ayuda al equipo de revisión manual a inspeccionar primero las transacciones más sospechosas. Entrenado sobre 1M de transacciones bancarias anonimizadas.
Dataset: BAF · NeurIPS 2022 · ver paper ↗
El problema
El sector bancario procesa millones de transacciones cada día. Solo cerca del 1% son fraudulentas, pero el costo de no detectarlas — chargebacks, multas regulatorias, pérdida de confianza del cliente — se multiplica rápido. Cada fraude inspeccionado a tiempo es dinero que no sale del banco.
Cuando los fraudes son tan raros, las métricas tradicionales engañan. Un modelo que dijera "no es fraude" a todas las transacciones tendría 99% de accuracy y sería completamente inútil. El reto real no es clasificar en blanco y negro, sino ordenar las transacciones por riesgo para que el equipo de revisión manual sepa qué mirar primero.
Cada transacción recibe una probabilidad de fraude entre 0 y 1, y el equipo de revisión inspecciona las más altas. Con el umbral de decisión por defecto, el modelo detecta cerca del 80% del fraude marcando solo las transacciones que lo superan — un balance que puedes ajustar en vivo en la siguiente sección.
A continuación, cómo medimos si el modelo cumple esa promesa, cómo se comporta al mover el umbral de decisión, qué features pesan más, y tres casos reales con la predicción del modelo desplegado.
Sección 01 · Qué tan bueno es
Evaluación sobre 200 000 transacciones que el modelo no vio durante entrenamiento. Se comparan dos versiones del mismo algoritmo: una baseline sin tuning y la versión final ajustada con Optuna.
Entre más pegada al vértice superior izquierdo, mejor distingue el modelo entre transacciones legítimas y fraudulentas. El modelo optimizado mejora +0.055 respecto a la versión inicial.
Fuente: 200 000 transacciones de test, dataset BAF (NeurIPS 2022).
Muestra qué tan preciso es el modelo conforme aumenta su cobertura de fraude. La curva cae gradualmente — el modelo mantiene precisión útil incluso al capturar una fracción mayor del fraude total.
Fuente: 200 000 transacciones de test, dataset BAF (NeurIPS 2022).
Sección 02 · Decisión de producto
El threshold es el punto a partir del cual el modelo declara una transacción como sospechosa. No existe un valor "correcto" — depende de cuánta capacidad de revisión manual tenga el equipo. Subirlo reduce falsas alarmas pero deja escapar fraude; bajarlo atrapa más fraude pero genera más trabajo. Mueve el slider para ver el efecto en vivo sobre las 200 000 transacciones de test.
0.50 —
Fuente: 200 000 transacciones de test, dataset BAF (NeurIPS 2022). Threshold por defecto: 0.50.
Nota: el threshold por defecto (0.5) es una referencia neutral, no un valor óptimo. En producción, el threshold depende del costo relativo entre un fraude no detectado y una falsa alarma — una decisión del negocio, no del modelo.
Sección 03 · Por qué predice lo que predice
Un modelo que solo arroja una probabilidad no le sirve al equipo de revisión: necesitan saber qué levantó la sospecha para investigar. SHAP atribuye a cada variable cuánto empujó la decisión hacia "fraude" o "legítimo". Aquí se muestran las 20 variables que más pesan en promedio sobre 2 000 transacciones de test.
El estatus de vivienda y el sistema operativo del dispositivo son las señales más determinantes. Variables de comportamiento reciente — frecuencia de solicitudes, visitas a sucursal — pesan más que datos demográficos estáticos como la edad del cliente.
Fuente: SHAP TreeExplainer sobre 2 000 transacciones de test del dataset BAF.
Sección 04 · El modelo en producción
Selecciona un caso para enviarlo al modelo desplegado en este servidor. Cada caso es una transacción real del conjunto de test: el modelo nunca la vio durante el entrenamiento.
Fuente: dataset BAF (NeurIPS 2022). Predicción y atribuciones SHAP calculadas en vivo por el modelo desplegado en este servidor.
Sección 05
Documentación pensada para tres audiencias distintas. El código completo, las decisiones de diseño con su justificación, y el análisis exploratorio paso a paso.
Código completo en GitHub. Backend FastAPI, frontend Astro, modelo, notebook y CI.
→5 minutos de lectura. Decisiones clave: desbalance, threshold, features, tuning.
→EDA, baseline, tuning con Optuna, SHAP. Para discusión técnica profunda.
→Sweetviz auto-generado: distribución de cada feature, correlaciones, comparativa fraude vs legítimo.
→Stack técnico