top of page

COSAS VEREDES

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.

 
 
 
  • fjroar
  • 20 jun 2022
  • 5 Min. de lectura

Figura 1: Código de implementación de la fórmula de cálculo de RWA para hipotecas


Lo que pretendo con esta entrada es hacer un poco de “calculo gordo y poco fino” sobre unos datos cualesquiera tomados de kaggle y comparar los algoritmos utilizados por los actuales Data Scientist bajo un entorno regulatorio a la clásica regresión logística (y por ende credit scoring). ¡Ojo! Que no voy a hablar de Machine Learning, sino que lo que voy a hacer es comparar un algoritmo clásico frente a uno de corte más actual y por tanto no me meteré en lo que significaría realmente un aprendizaje realmente automatizado, lo que quedaría para otra entrada.

En este sentido, voy a tratar de un modo muy simplista, un tema muy complejo y delicado como es el del riesgo de crédito en banca y lo que tiene que ver con la estimación del capital regulatorio, donde se habla constantemente que con pequeñas mejoras de estimación, se conseguiría liberar grandes cantidades de dinero, pero … ¿Es esto cierto? ¿Cómo hacer una cuantificación de lo que se dice basados en datos? Para hacer lo anterior, consideré los datos de https://www.kaggle.com/datasets/uciml/default-of-credit-card-clients-dataset Unos 30.000 registros con una tasa de impago del 20% que son datos que los asimilaré a una posible cartera hipotecaria y para lo que voy a hacer una aproximación sencilla de estimación de mejora de un algoritmo avanzado frente a uno clásico.

Para lo anterior conviene saber que el capital regulatorio viene a ser como ese dinero que el banco debe tener en la hucha por si se produce un impago masivo por parte de sus clientes, o una crisis, … y poder seguir funcionando dotando de liquidez los depósitos de sus clientes. Así pues, cada vez que un banco concede un crédito, asume el riesgo de que el cliente no se lo devuelva íntegramente y para ello debe hacer una reserva de dinero para que, en grandes números, los que paguen, cubran a los que no pagan. Estas reservas de capital son revisadas anualmente y hay como 2 esquemas principales, el primero es que un banco reserva un 35% del riesgo que asume (en una hipoteca) y lo manda a la “huchaca” y el segundo es que el regulador permite que el banco calcule un porcentaje de reserva en función del riesgo de impago, basado en sus propios datos, acorde a la siguiente fórmula para hipotecas (véase https://www.bde.es/f/webbde/SJU/normativa/circulares/c200803.pdf pg 94):


En esta fórmula hay 2 parámetros fundamentales que debe estimar la entidad bancaria y son el parámetro PD (probability of default o probabilidad de que un cliente pague o no pague) y LGD (loss given default o el dinero que finalmente, dado que ha impagado, no se va definitivamente a recuperar, a veces se llama también severidad), en este ejercicio se va a suponer que el LGD es constante siempre vale 0.45

Pues bien, la fórmula anterior que proviene del modelo de Vacisek (ver por ejemplo https://www.cemla.org/PDF/boletin/PUB_BOL_LXII-03-03.pdf ) para riesgo de crédito y cuya obtención no resulta sencilla, aunque por ley la tienes que utilizar, esta fórmula tiene en cuenta consideraciones como la correlación del impago que se suele suponer como R = 0.15 y que se consiga tener capital suficiente a un percentil del 99.9%, según se considera en dicha formulación.

Pues bien, en este trabajo lo que se hace es estimar 2 modelos de riesgo de crédito (que podrían ser por ejemplo de admisión) uno bajo un algoritmo tipo regresión logística y otro bajo otro de tipo random forest, dado que los datos estaban relativamente bien, se dejaron todas las variables explicativas (salvo la ID) y la explicada (que se denomina target) y construyo los modelos que muestro en el código de mi github https://github.com/FJROAR/Ejemplo-Blog-RWA obteniendo los siguientes resultados en cuanto a área bajo la curva:

Regresión Logística: 72.38% Random Forest: 76.33%

Figura 2: Curvas ROC realizadas con la librería ROCR


Una de las cosas que se observa en los datos es que la tasa de default era del 20% y no es realista (el banco estaría quebrado no, lo siguiente … si fuera así), en este caso se va a suponer un calibrado “grosero” a un tasa promedio más comedida. Este proceso de calibrado en la realidad suele ser bastante complejo y requiere de un ciclo completo de al menos unos 10 años, pero aquí sencillamente se va a suponer que la probabilidad media real (incondicionada o independiente a la muestra) estaría en torno al 1% y por tanto lo que se crea es un factor f que convertiría la tasa promedio del dataset original en unas medias en torno a dicho 1% con el factor:

f = 0.01 / tasa ~ 0.04

Pues bien, tras esto se aplica una política de riesgos “trivial” del tipo que sólo se acepta riesgo si la probabilidad predicha y calibrada por el modelo resulta ser menor al 1%, se trabaja con el conjunto test, que no se usó en la muestra. Cuando sucede eso y si se suponen que las hipotecas de media están en torno a los 150.000€ se obtienen las siguientes cifras para cada una de la modalidad estándard o avanzada en la estimación “grosera” del riesgo de crédito que en el citado conjunto test resultan ser de:

Regresión Logística Random Forest

Modelo Estándard: 317.625.000 Modelo Estándard: 306.547.500

Modelo Avanzado: 368.339.934 Modelo Avanzado: 300.048.403

En este caso y para las pocas exposiciones que se consideran (casi unas 10.000 exposiciones) se observan cosas interesantes como:

  • No por aplicar un modelo construido a partir de datos mejora las metodologías estándard de los reguladores, hay que ver cómo son las carteras y si realmente hay muchas exposiciones de bajo riesgo

  • Un modelo avanzado puede mejorar a uno clásico y suponer un importante ahorro de capital, en este caso, frente a la propia metodología estándard el ahorro sería de un 2.12%, pero es que si se compara frente a lo que supondría el Modelo Estándard de una regresión logística, dicho ahorro estaría en torno al 5.86

  • Por tanto ¿Merece la pena pagar el coste de regulación en hacer que un modelo de analítica avanzada sea más interpretable o mejor detallado? Claramente implica mucho más trabajo pero el dilema a considerar es si porque resulta complejo pero funciona, ¿Es admisible que se deje o no inmovilizado más o menos capital?

  • Es claro que la regulación debe exigir, si alguna vez acepta un algoritmo avanzado, una elevada batería de test y de pruebas, pero también parece claro que el incentivo para que las entidades bancaria atraigan talento y hagan cosas avanzadas y bien, está también ahí

  • Indicar que en estadística no existen “los siempres”, ni “los nuncas”, todo depende, y bajo mi experiencia también es cierto que una logística bien trabajada puede igualar y en ocasiones superar perfectamente a un random forest o algoritmo superior si se actúa, como he visto en más de una ocasión como no “autómatas preparadores de datos” sino como auténticos científicos a los que les gusta analizar datos y aplicar técnicas analíticas


Finalmente conviene recordar que los cálculos a realizar en casos reales y bajo entornos regulados resultan mucho más complejos que los aquí realizados. Con esta entrada sólo se desea demostrar de modo muy divulgativo y práctico como algoritmos avanzados podrían permitir una mejora de la predictividad de los modelos actuales formados por Credit Scoring y Regresiones Logísticas en su mayoría.

 
 
 
  • fjroar
  • 9 ene 2022
  • 2 Min. de lectura

Como ya venía anunciando, una de las aficiones que rellena parte importante de mi psique es la astrofotografía, y como no podía ser de otra manera, ya voy tratando de incorporar cosas que conozco de mi otra vida como Data Scientist y en esta ocasión el tema ha ido por hacer un álbum que sea capaz de recoger mis fotos, por el momento las mayoría realizadas aquí en Madrid y poderlas acceder de un modo sencillo y rápido.


Uno de los últimos descubrimientos es la librería magick para el tratamiento de imágenes y poderlas mostrar por ejemplo vía shiny con toda su calidad. Así pues mi problema era que quería crear un album ordenado de fotos de modo que me lo pueda llevar al móvil y que pueda consultarlas para repetirlas o mejorarlas con toda su información. Así pues, dada la foto:


Quiero saber, cómo la hice, en qué condiciones, con qué equipo, etc Y tenerlo todo apuntado en cuadernos aunque puede ser hasta bonito, al final cuando tengas cientos (que aún no es mi caso), no es práctico irte al campo con un cacharro más que además tienes que manipular entre otras muchas cosas


Así pues me puse manos a la obra con R y monté este shiny que lo iré enriqueciendo poco a poco:



Además dejo una sesión para que los que se metan en el blog puedan ir directamente al shiny y ver las últimas novedades:



En la construcción de todo debo admitir que al principio con las librería usuales de tratamiento de imágenes de R no me daban un buen resultado, hasta que el amigo Carlos Ortega me sugirió la libraría magick de R. Es una librería que la he utilizado para otro ingenio más que comentaré en otra entrada, pero por lo pronto aquí, me permitió montar todo el album por el momento de 8 fotos y permite no sólo el acceso a la imagen, sino la manipulación de esta agrandándola, pintando cosas sobre ellas en el pixel exacto que elijas, e incluso admite manipulaciones de tipo de tratamiento de imagen.

Debo admitir que al principio estuve un poco reacio de usar R y me tiré por el mundo Python que tanta fama tiene con el tema imagen, pero el descubrimiento por mi parte de esta librería ha marcado un antes y un después tanto para temas de aficiones propias como para aplicaciones a nivel más profesional.

 
 
 

© 2021 by Francisco J. Rodríguez Aragón. Proudly created with Wix.com

bottom of page