Cómo evaluar si un modelo de ML funciona de verdad

El 95% de accuracy en un dataset de impago con el 5% de positivos no significa nada: el modelo que predice siempre 'no impaga' obtiene ese resultado sin aprender nada. La métrica que eliges define lo que el modelo optimiza, y si eliges mal, optimizas lo incorrecto.

El problema de las métricas globales. Accuracy en datasets desbalanceados es la trampa más común. Para clasificación binaria donde los positivos son raros (fraude, impago, enfermedad), las métricas útiles son ROC-AUC (qué tan bien separa el modelo, independientemente del umbral) y PR-AUC (área bajo la curva precisión-recall, más informativa cuando los positivos son pocos). Para problemas de coste asimétrico, lo que importa es cuánto cuesta cada tipo de error para tu negocio.

Fugas de datos: la fuente de evaluaciones optimistas. Si el preprocesado (escalado, encoding, imputación de valores ausentes) se hace antes de la validación cruzada, el modelo ha visto indirectamente los datos de validación durante el entrenamiento. El resultado: métricas en validación que no se reproducen en producción. La solución es que el preprocesado viva dentro del pipeline, ajustándose únicamente con los datos de entrenamiento de cada partición.

Calibración: cuando el score tiene que ser una probabilidad. Si el modelo dice 0,7 de probabilidad de impago, ¿ocurre impago en el 70% de esos casos? Si la respuesta es no, el modelo no está calibrado. Puedes tener un buen ROC-AUC y aun así necesitar calibración para tomar decisiones basadas en el score. El Brier score y la curva de calibración dicen si las probabilidades son fiables; Platt scaling o calibración isotónica las corrigen cuando no lo son.

El umbral de decisión no es 0,5. El umbral que minimiza el error total no es necesariamente el mejor para tu negocio. Si un falso negativo (dejar pasar fraude) cuesta 10 veces más que un falso positivo (bloquear una transacción legítima), el umbral óptimo refleja esa asimetría. Optimizar el umbral para el coste real del negocio suele cambiar el resultado operativo más que cambiar de algoritmo.

Análisis de error por segmento. Una métrica global de 0,87 ROC-AUC puede esconder que el modelo funciona bien en un segmento y mal en otro. Hay que analizar el error por subgrupos relevantes para el problema: antigüedad del cliente, categoría de producto, región, etc. Los errores concentrados en un segmento son un problema de datos o de ingeniería de variables, no de algoritmo.

La regla que aplico: antes de entregar cualquier modelo, el informe de evaluación tiene que incluir al menos ROC-AUC y PR-AUC en un conjunto de test reservado, la curva de calibración, el umbral elegido con su justificación y el análisis de error por segmento. Sin eso, no se puede afirmar que el modelo funciona.