El peligro del Stacking de Modelos en Riesgo de Crédito

En numerosas empresas por las que he pasado como consultor o trabajando en ellas, me he encontrado en numerosas ocasiones stacking de modelos frente a simple mixturas de estos y cuando pregunto la razón, la verdad es que nadie me suele dar una respuesta clara.

Hoy me ha dado por usar Python, que en este blog lo uso poco la verdad (aunque lo mismo e incluso mejor cabe hacerlo con R):

Sucede fundamentalmente en banca y seguros que un proveedor ofrece un modelo externo (que lo denomina “variable” para que entre mejor en el cliente) para predecir mejor, por ejemplo, el Riesgo de Crédito y simultáneamente le ofrece adicionalmente el servicio de construir un modelo que integre dicha “variable” (que no olvidemos que es un modelo), con los datos propios de dicho cliente y por un precio adicional, el proveedor vende la consulta al dato, haciendo “su Agosto”.

Bueno, no soy yo quién va a opinar sobre lo bueno o lo malo de lo anterior, pero si me gustaría advertir a los clientes que compran ese tipo de desarrollos que tenga bien claro qué están comprando en base a lo que he visto a lo largo de mi vida laboral.

En general, lo que están comprando es un stacking de modelos y habitualmente se vende que dicho stacking va a ser mejor que usar cada uno de los modelos por separado pero … ¿Es esto cierto?

Antes de discutir sobre lo anterior, hay que tener en cuenta que hay otras opciones como la mixtura de modelos, que puede ofrecer en ocasiones mejores resultados que el stacking además de otras ventajas como:

• En la mixtura no se estiman parámetros de las variables internas con la externa, por tanto, su puesta en producción es más sencilla

• Siempre se mantiene el modelo de proveedor de forma separada al interno, por lo que si hay que cambiar de proveedor no hay que re-estimar todos los parámetros con el coste en tiempo y dinero que supone eso. Además, siempre se podrá optar o bien por el modelo interno o bien por el del proveedor de modo separado

• Si hay errores operacionales, la reparación es más sencilla que si los 2 modelos están bajo una misma fórmula de stacking

• La mixtura es fácil de optimizar y se puede dar fácilmente grados de credibilidad de un modelo frente a otro, además bajo la mixtura, no sólo se tiene que considerar un único modelo, sino que pueden entrar en juego más de uno

Pues bien, dicho lo anterior me he encontrado en no pocas ocasiones que algunos de los stacking de modelos que, en teoría por usar más variables deberían de ser al menos tan buenos como el modelo sin stacking, sin embargo resultan peores y claro, no puedo hacer uso de datos privados para mostrar mi aseveración pero sí puedo tomar algunos datos de kaggle y ver si esto es posible que pase o no y para mi sorpresa, puede que sí.

Lo anterior proviene de un notebook que podéis encontrar en: https://github.com/FJROAR/Ejemplo-Blog-Stacking

Aunque no son los mejores datos para esta prueba, la verdad es que resultan bastante sencillos de manejar y me sorprendió lo siguiente:

• Si un cliente tiene un determinado modelo (pongámoslo sencillo con una regresión logística, a veces el cliente no tiene el modelo y es donde el proveedor le ofrece el hacerlo todo a la vez pero sin comprobar si el modelo con variables internas sólo era o no mejor que el otro con la variable externa que dicho proveedor vende):

• Llega un proveedor y le ofrece un stacking basado en otra regresión logística (que idealmente use otras variables distintas):

• Entonces realiza un stacking de los anteriores modelos (olvidándose por tanto del inicialmente construido por ellos, si es que lo tenían, que muchas veces ni tan siquiera se tiene) y se encuentra lo siguiente:

Como se observa, en este ejemplo, donde ambos modelos con una ROC del 52% directamente serían malos, se observa que, bajo un stacking, no se consigue una mejora, sino que empeora aún más si es que esto es posible... Es decir que, si un cliente le ha pagado al proveedor el servicio de consultoría, directamente ha tirado su dinero para tener algo más malo que lo que tenían inicialmente cuando lo esperable es al menos una mejora que compense el gasto además del coste de poner todo eso en producción, documentarlo, ... ¿Ocurre esto siempre? Obviamente no, pero conviene advertir que aunque he visto que esto pasa en ocasiones, lo que no suelo ver nunca es estudios serios de porqué se ha optado por el stacking frente a una simple mixtura, sabiendo además que aparte de los costes de consultoría o de desarrollo interno del modelo, están las dificultades de puesta y mantenimiento en producción del modelo anteriormente comentados.

Entonces ¿Qué ocurriría en este ejemplo bajo una mixtura simple? En este caso se observaría lo siguiente:

Tampoco la mixtura mejora, pero al menos no empeora (¡Ojo! Que a veces también puede empeorar si no se tiene cuidado).

Como se observa, la mixtura ha sido muy fácil a nivel de código (véase la reducción en líneas de código de una opción frente a otra), se observa que no ha hecho falta re-entrenar nada y los modelos están por fuera, al menos, si no mejora la mixtura, lo que si nos ahorra es una pasta en consultoría y nos da flexibilidad por si mañana viene un nuevo proveedor que nos promete increíbles mejoras, de cambiar o no.

Viendo este tipo de cosas que repito, me las he encontrado en más de un sitio, al menos en mi caso, mucha tiene que ser la mejora de un stacking frente a una mixtura para que yo recomiende lo primero frente a lo segundo y desde luego, todo justificado con datos y no con ideas no contrastadas y peregrinas.