LO QUE NO TE CUENTA TU CONSULTOR PARTE III: El humo del Machine Learning de los primeros años

En un momento del tiempo llegó el Machine Learning para sustituir a la minería de datos a toda cosa anterior, algo a lo que está pasando con la IA, pero de un modo muy brusco se pasó de los análisis tradicionales a otros, en ocasiones algo más livianos, que sin ser malos del todo, hay que tener cierto cuidado.

A partir del 2014 se popularizan los svm, random forest y posteriormente irrumpirían los xgboost y demás modelos que me gusta llamarlos de analítica avanzada, junto con una pléyade de Data Scientist que básicamente metían vectores y sacaban ginis o roc altos y "a rular".

Así pues, el negocio de la consultoría se reinventa y ahora se pasó de estudiar la variable y de hablar de consistencia lógica de un modelo comprensible por el usuario, a algo que este no controlaba y lo peor de todo, el propio usuario lo prefería hasta el punto de llegar a escuchar afirmaciones del tipo "si lo entiendo es que es malo" y claro está, de nuevo surgen proyectos como setas tras unos días de lluvia en un bosque polaco.

Se generan modelos de esta nueva analítica y los más versados te presentaban gráficos del tipo importancia de las variables (normalizados o no como el siguiente):

Y los clientes, muchos sin entender pues ven que hay como una variable muy importante, otra sólo un poco importante, que cabría hasta la posibilidad de desecharla, pero nada como quién oye llover en muchas ocasiones porque le cuentan la historia de que si modelos débiles se unen para crear otro más fuete y si patatín o si patatán ...

Lo anterior se puede conseguir ejecutando por ejemplo el siguiente código:

library(dplyr)

library(scorecard)

library(ISLR)

library(ranger)

library(ggplot2)

data("Default")

df <- Default

df$default <- ifelse(df$default == "Yes", 1, 0)

df_list <- split_df(df, y = "default", ratios = c(0.6, 0.4), seed = 30)

label_list <- lapply(df_list, function(x) x$default)

df_train <- df_list$train

df_test <- df_list$test

# Modelo Random Forest con ranger

set.seed(123)

rf_model <- ranger(

formula = factor(default) ~ .,

data = df_train, importance = "impurity", probability = TRUE

)

imp <- data.frame(

Variable = names(rf_model$variable.importance),

Importancia = rf_model$variable.importance

)

ggplot(imp, aes(x = reorder(Variable, Importancia), y = Importancia)) +

geom_col(fill = "#0072B2") +

coord_flip() +

labs(

title = "Importancia de variables (Random Forest - ranger)",

x = "Variable",

y = "Importancia"

) +

theme_minimal()

Entonces ahora cabe hacerse la pregunta ¿Qué significa lo anterior? Lo anterior no es más que una medida de lo que se denomina impureza o cómo de mezcladas están las clases en un nodo de un árbol (o conjunto de árboles entremezclados como es este caso). Por lo que se tiene una medida bastante relativa y condicionada al dataset y al modelo en concreto plantead sin mucha más base teórica detrás, se elude el tema del signo y para alguien que no sabe, hasta te compra el modelo, máxime si le muestras el siguiente gráfico de desempeño:

pred_rf <- predict(rf_model, data = df_test)$predictions[,2]

perf_eva(label = df_test$default, pred = pred_rf,

title = "Curva Gini - Random Forest (ranger)",

show_plot = "roc",

binomial_metric = "gini")

Es decir, tenemos un AUC del 92.78% en test y un modelo de analítica avanzada donde las variables no se entienden bien cómo intervienen ¡Qué más se puede pedir!

Entonces ¿Qué ocurre si se trabaja desde la estadística tradicional y se plantea una regresión logística? Pues se obtiene la siguiente tabla característica:

m1 <- glm(default ~ ., data = df_train, family = binomial)

summary(m1)

Donde llama la atención que desde este punto de vista una variable como es la de income no es significativa y convendría eliminarse, además es contraintuitiva ¿Quiere decir que a mayor ingreso mayor probabilidad de impago? Lógicamente sale del modelo y quedaría tal como sigue:

Ahora parece que gana fuerza, desde un punto de vista del p-valor la variable student pero desde el sentido común y desde el siguiente gráfico asociado (visto en un post anterior), se tiene que univariantemente, a poco que se mire la variable el resultado es el siguiente:

Es decir, bajo el gráfico anterior el signo debería ser positivo, sin embargo resulta negativo, lo que va en contra del análisis univariante y es que como se puede observar a continuación, se observa que los que son estudiantes tienen un mayor nivel de balance y por tanto existe un grado de correlación hasta cierto punto peligrosa que conviene eliminar del modelo:

df_train %>%

group_by(student) %>%

summarise(m_balance = mean(balance))

Por tanto cabe plantear el modelo más simple y con sentido siguiente:

Y claro, si tú ibas con esto en el año 2018, te salían múltiples "expertiños" tanto de los consultores como del propio cliente diciendo que "si era una caca de la vaca", que si "no pagaban para cosas sencillas", que si ... Te habías currado el estudio de las variables, pero como ofreces algo que se entiende frente a un random forest dudoso, pues mejor tirarlo a la basura, prácticamente "te corrian a gorrazos", pues bien chavales ¿Cómo sería el performance de un sencillo modelo como el anterior? Si lo aplicamos sobre el test se obtiene lo siguiente:

Es decir, un AUC del 95.29, unos 3 puntos por encima y con sólo una variable, frente a 3 que usa un modelo de analítica avanzada como es el random forest, además se han descartado las variables por razones claras de sentido común y de negocio mediante su visualización.

Finalmente, y a pesar de este ejemplo, he visto en muchísimas ocasiones lo contrario, es decir que los modelos analítica avanzada suelen superar en la mayoría de los casos a los tradicionales en cuanto performance se refiere (si se manda al cuerno la interpretabilidad, claro está) y esta victoria se consigue cuando se introducen tablas en estos algoritmos y se trabaja lo mínimo las variables, pero cuando se hace algo que se quiere que tenga sentido, la diferencia ya no resulta tan aplastante, por tanto desde mi punto de vista, la irrupción en R y Python de estos modelos avanzados vienen a ser una caja de herramientas que debemos conocer los que nos dedicamos a esto, pero desde luego no nos dejemos impresionar por el humo de estas entelequias, pidamos contrastes con modelos más sencillos, pidamos análisis marginales de las contribuciones de las variables al modelo, veamos los EDAs que son fundamentales en cualquier proyecto y con toda una documentación clara y formal, entonces yo y cualquiera va aceptaremos un modelo de analítica avanzada, mientras tanto frente a los complicadores me aparto hacia la rama de los simplificadores y me complico eso sí, cuando sea necesario, no por modas.