top of page

COSAS VEREDES

Para muchos de aquellos que hacen modelos de Credit Scoring, como es mi caso, estoy casi seguro de que os habréis preguntado ¿Cómo puedo incorporar analítica más avanzada a esto y que además mantenga la estructura de interpretación sencilla que me ofrece un Credit Scoring?


Pues bien, esto es un tema que lo trataré en https://eventum.upf.edu/101896/detail/ii-congreso-de-r-y-xiii-jornadas-de-usuarios-de-r.html pero a lo que voy ahora es a ofrecer una vía sencilla que responda a la anterior pregunta, sin meterme en demasiado lío con lo que significaría ir hacia un Machine Learning, que lo dejo para la charla o para otro post posterior.


Pues bien, el Credit Scoring como es bien sabido se estructura en 2 partes fundamentales, la parte del trameado de variables y la de la construcción de un modelo de regresión logística subyacente. Una vez hechas estas 2 partes, el siguiente paso, la construcción de la tarjeta de puntuación se hace de un modo sencillo ya que mediante logaritmos se transforma la salidad habitual de probabilidades de estos modelos como suma de puntos a partir de los scoring parciales.


Una extensión, bastante natural en mi opinión, sería permitir que las regresiones ridge y/o lasso puedan hacer el papel de la regresión logística subyacente y así se estaría dando al menos, posibilidad de introducir estos modelos paradigmáticos del Machine Learning y por tanto se podría jugar con hiperparámetros como el elastic net al que nos habilita la librería de R glmnet:



Entonces el tema es ¿Cómo hacer todo lo anterior de una manera sencilla en R? Pues la respuesta va a ser mediante el uso por un lado de una de mis librerías favoritas como es la scorecard, por supuesto también con el uso de la citada librería glmnet y finalmente con la contribución que os hago sobre una función que he preparado y que he denominado scorecard_glmnet(), esta función tiene como entrada 3 elementos, 2 de los cuáles son los elementos que necesita la función scorecard() de la dichosa librería scorecard y un tercer elemento como es el valor del lambda, con el que se va a penalizar los coeficientes, donde recomiendo que para elegirlo se haga uso de la función cv.glmnet() de la librería glmnet, que si no se pone, se tomará lambda = 0.


Pues bien con mi función, que la podéis utilizar y trastear como os de la gana si la tomáis de mi git en esta url https://github.com/FJROAR/R-function-scorecard_glmnet, se genera una salida totalmente compatible con scorecard_ply() también de la librería scorecard() y que permite generar, posteriormente y en un paso super sencillo, la tarjeta de puntuación como si fuera cualquier modelo de Credit Scoring (todo esto está en el código del git con un ejemplo adicional para que podáis reproducir y para lo que os recomiendo que os descarguéis el dataset https://www.kaggle.com/datasets/mlg-ulb/creditcardfraud), con lo que ya se habría generado una tarjeta de puntuación, ahora sí con un algoritmo propio del Machine Learning (que se conocía, en caso de la ridge desde los años 70 y en el caso de la Lasso desde el 96 ideada por el gran Robert Tibshirani).


Para finalizar, quiero indicar que el interés en compartir esta entrada es simplemente tratar de facilitar la vida a gente que esté trabajando con estas técnicas de CS con R por lo que estoy seguro de que hay realizaciones de este tipo, seguramente mejor montada que la que yo ofrezco, ya que esta es una idea muy natural que estoy seguro que ha sido muy explorada, aunque aquí la he sacado porque creo que más de uno es posible que no lo muy claro.

 
 
 

En esta ocasión voy a explicar cómo hacer uso de la capacidad de ejecución de script de R creados en R studio para plantear la ejecución de un proceso mecanizado donde intervenga un modelo genérico serializado vía R sin intervención humana a nivel de ejecución, aunque el modelo haya sido entrenado, desarrollado y serializado en un entorno aparte.


Además aprovecho para comentar una serie de recomendaciones basadas en mi experiencia válidas tanto para R como para Python en la construcción y creación de este tipo de procesos donde la ejecución va a ser on premise.



Aunque el desarrollo que cuento está basado en el anterior esquema con denominaciones (por supuesto) ficticias, en este proceso mezclo datos con origen en SAS con elementos con código R, sin embargo voy a ser descriptivo dando sólo indicaciones, ya que al ser un caso real no puedo compartir demasiado detalle técnicos ni por supuesto datos reales.


Comienzo por el caso de negocio que en sí consiste en crear un proceso que se ejecute automáticamente y sin intervención considerando lo siguiente:


  • Paso 1: Diariamente se descarga y prepara información, creando una tabla de variables explicativas con identificación de clientes y distintas columnas que serán variables explicativas de un modelo estadístico (regresión logística, random forest, xgboost, ...)


  • Paso 2: Ordenación de la tabla anterior mediante el citado modelo que habrá sido previamente construido y entrenado bajo entorno R (también podría considerarse modelos en Python, para ello habría que usar la librería reticulate y todo sería casi igual)


  • Paso 3: Generación de unos conjuntos de salida para que sean leídos por una aplicación de negocio


  • Todo lo anterior debe ejecutarse a una determinada hora que podemos suponer que serán las 9.00 a.m


¿Cómo conseguir lo anterior? En este momento conviene observar una serie de consejos a contemplar:


  • En primer lugar conviene separar el entorno laboratorio analítico del entorno puesta en producción, esto se podría conseguir creando una simple estructura de carpetas del tipo:

Nota: También podria considerarse una denominación más cercana a los esquemas

MLOps, pero trato creo que así queda más claro, dado el tipo de proceso elegido.


  • El entorno datalab es el entorno que se utilizaría para entrenar (en paralelo al proceso de ejecución), desarrolar y documentar el modelo, en general puede constar de una serie de subcarpetas adicionales de las que suelo usar principalmente la siguiente estructura:


Aquí los nombre pueden cambiarse más o menos pero la idea es tener:


- Una carpeta para el código

- Otra para los datos

- Otra para la documentación

- Y para mí la más importante: una carpeta para el modelo serializado que

finalmente sería el llamado por el proceso


Nota: Es normal por ejemplo crear un modelo y posteriormente entrenar otro con

más datos y/o variables, en estos casos conviene que esta carpeta datalab tenga

una denominación del tipo datalab_xx que permita saber cuál es la última versión

que debe considerarse.


  • En la carpeta pap (paso a producción) directamente hay código y suelo sencillamente añadir una sub-carpeta adicional:

Es decir una carpeta redundante con la anterior y donde habrá un único modelo

serializado que es el que efectivamente se va a usar en producción. Esta carpeta

sólo contiene un único fichero, modelo serializado que será copia de la versión

entrenada más actual disponible


  • Como segundo paso hay que entrenar, documentar y finalmente serializar el modelo que se quiere poner en producción, pero … Probablemente a alguien le pueda haber chocado el concepto “serializar” y eso ¿Qué es exactamente? Pues consiste en generar un archivo, que en este caso será de tipo .R que contenga la información necesaria para que cuando le llegue una tabla con las variables utilizadas en el modelo, sencillamente se aplique el algoritmo que se ha entrenado en el área datalab, de modo que una adecuada serialización a este nivel se consigue mediante el uso de save()


que permite guardar cualquier tipo de objeto, en particular un modelo creado en R.


Así pues, en R al igual que en Python, se puede perfectamente serializar modelos para

ser llamados posteriormente en otro código distinto mediante la función load()


El modelo serializado se guardará por tanto en la estructura: datalab/Rmodel

  • En tercer lugar se define el proceso de puesta en producción este proceso es el que va a ser clave y se recomienda lo siguiente:


  • Es recomendable definir un código que se puede llamar 01_functions.R que puede contener la lista de librerías necesarias y las funciones que nosotros mismos tengamos que definir para la preparación de los datos.


  • Otro código que sulelo definir es 02_process.R aquí está toda la lógica del proceso que suele consistir por lo general en lo siguiente:


  • Acceso a los datos y preparación de una tabla con la selección de registros y columnas necesarias para que el modelo genere una determinada probabilidad, predicción, etc

  • Llamada mediante load("Rmodel/model.R") del objeto modelo

  • Asociación y ordenación de los datos y uso de la instrucción predict() o similar para generar las predicciones del citado objeto modelo

  • Generación de las tablas de salida en una carpeta física

En ocasiones y si el proceso es muy largo, conviene separar el 02_process.R en

distintos sub-códigos, esto ayuda a la localización de errores tanto en la creación

del proceso como en su ejecución posterior.


  • Un código main.R que llame a los códigos anteriores mediante la instrucción source():

source(“01_functions.R)

source(“02_process.R)







  • Y finalmente llega la parte más importante, el poder ejecutar todo lo anterior sin necesidad de ni tan siquiera de abrir Rstudio. Y es que, a día de hoy existen lo que se denomina “robots” u “agentes”, que están diseñados para que puedan ejecutar un fichero que suelo llamar execution.bat, que se crea con el notepad al guardarse como fichero tipo batch. Así pues teniendo un fichero como el anterior hay que dotarlo del siguiente contenido:


  • Una ruta válida para un fichero de tu versión de R que se denomina Rscript.exe y que en mi caso se encuentra en:


C:\Program Files\R\R-4.2.1\bin\Rscript.exe


Es justamente la existencia de este ejecutable lo que permite por tanto la

ejecución de scripts basados en R.


  • Una ruta a tu fichero main.R que cabe suponer que podría estar en:


C:\modelo\pap\main.R


Pues bien, escribiendo en vuestro fichero exectuion.bat las anteriores rutas

absolutas entre comillas, tendríais preparada ya la ejecución lista para que un

agente ejecute todos los días a la hora prevista el proceso.


Si en vuestra empresa, tienen un servidor on-premise para este tipo de procesos, tan sólo basta con instalar R y las librerías que utilicéis en dicho servidor y seguir estos pasos una vez establecidas las rutas en el fichero .bat, el robot podrá ejecutarlo sin problema.


Antes de terminar algunos consejos:


  • A la gente de sistemas (o a quién se encargue posteriormente de la parametrización del agente) hay que pasarle la carpeta denominada pap, esta la moverán a alguna ruta del servidor y la pondrán ahí. Es muy importante que todo lo que esté en R haga uso de rutas relativas, no absolutas, las únicas rutas absolutas a considerar es la que se están en el fichero execution.bat que deberá adaptarse a la máquina que se vaya a utilizar.


  • En ocasiones (cuando trabajo con SAS y con algunos formatos más extraños) necesito hacer una descarga previa de datos del servidor SAS donde éstos se hallen y usar la librería haven posteriormente. Todo lo dicho aquí es análogo, sólo que suelo cambiar ligeramente el contenido de la carpeta pap dando lugar a una estructura como sigue, compliance con el esquema expuesto al principio de esta entrada:

Básicamente lo que hago es mover los datos de los servidores SAS a la carpeta data

mediante una gran librería como es sftp que con devtools se puede descargar de:



  • En el fichero Rmodel debe estar el fichero serializado modelo que puede llamarse genéricamente como model.R el cual se llamaría desde el 02_process.R mediante load(“Rmodel/model.R) es recomendable crear carpetas tipo datalab cada vez que se genera un modelo y que exista una numeración del tipo datalab_01, datalab_02, … si se hacen varias versiones o mejoras del modelo, de modo que sean el modelo serializado de la versión más elevada el que se copie y pegue en la subcarpeta pap/Rmode con un nombre adecuado pero siempre el mismo, en mi caso suelo usar model.R


  • Funciones como Sys.Date() son convenientes de ser utilizadas en 02_process.R de modo que cuando el robot o agente llame al main.R y este a su vez al 02_process.R, permita crear resultados separados por fecha de ejecución para seguimientos posteriores.


  • Finalmente cabe indicar que es recomendable ser claros en el código escrito por R y recomiendo usar librarías como dplyr y hacer uso del operador %>% que permite la generación de códigos claros y compactos, siempre y cuándo los claros y compactos seamos nosotros mismo, porque no es cierto que la programación en R sea más o menos legible o compleja que en Python, es sencillamente el que crea el código, el que hace que este pueda ser realmente legible o un auténtico horror



El año 2014 fue importante para mí porque me di cuenta que algo nuevo estaba pasando con la estadística que convenía aprender y agregarlo a la base de conocimiento, esa cosa nueva era el Machine Learning que ya desde el 2010 tanto en R como en Python se iban implementando en librerías que cada vez serían más sólidas.

Pues bien, a día de hoy vuelvo a sentirme desactualizado y ya casi a mis cuarenta y todos, creo que hay que ponerse al día con el tema de los Transformers.

Figura 1: Clasificación textual de “Party at my house, tomorrow afternoon” mediante un transformer entrenado con textos del dataset emotions


Aunque se puede fijar su fecha de aparición en el 2017, creo que ya existían cosas que se podían usar desde el 2020 y además, atacando a temas que a mí siempre me ha gustado como ha sido el Natural Language Processing NLP.

Así pues, que me pongo a ello y lo mejor para ello, más que poner por Linkedin y demás sitios referencias de otros autores es hacer algo e ir aprendiendo de la mano de algún libro bueno. Esta obra (seguramente ya entre otras muchas) recomendable es la titulada como “Natural Language Processing with Tranformers” de la editorial O’Reilly y los autores Lewis tunstall, Leandro von Werra & Thomas Wolf, de donde gran parte del código al que referencio aquí, lo he tomado de ahí.

Para este primer post de Transformers, he creído interesante hablar de mi primer “hola mundo” que de lo que son en sí, para lo cual, entre muchos recursos en español remito a https://www.aprendemachinelearning.com/como-funcionan-los-transformers-espanol-nlp-gpt-bert/

En este primer “hola mundo” siguiendo el mencionado libro, he sido capaz de crear mi primer transforme totalmente entrenado con una base de texto y puesto a disposición de quién lo quiera usar bajo la plataforma Hugging Face, así pues, con un conjunto de datos accesible vía Hugging Face, donde se parte de una clasificación de 16.000 textos procedentes en inglés etiquetados en 6 categorías o emociones, llegué a crear un modelo predictivo donde manipulé todos los hiperparámetros que me permitieron ajustar la parte de la red encoder a mi caso particular. Creando un modelo con la siguiente capacidad predictiva:




Figura 2: Matriz de confusión del modelo entrenado


Es instructivo seguir los códigos y adaptar los elementos del libro, ya que hay muchas dificultades de cosas que hay que retocar para que finalmente funcione además de que en la plataforma Hugging Face debe crearse un repositorio para alojar el modelo, así pues, para entender bien el libro conviene tener una base de Python, Git y ser hábil buscando soluciones técnicas tanto en Chat GPT como en Stack Overflow (no todo lo sabe Chat GPT …) y así logro un Google Colab que funciona (tras casi 4 horas de entrenamiento ya que no pago licencia y los recursos son los que son …) mi propio modelo, cuyo código de desarrollo que dejo aquí por si es de utilidad para alguien: https://colab.research.google.com/drive/1OPzGA5j5wsNOtiGvdSVzWZFbgYgxhvKU?hl=es#scrollTo=yVAixWnM-WMQ (ojo, que tendréis que daros de alta en la plataforma Hugging Face y pedir vuestro token y desde luego si alguien tiene problemas en su ejecución me puede pedir ayuda porque el tema de hacer un “push” a la plataforma no está muy fino y tras casi 4h de entrenamiento perderlo todo, tampoco es cosa …)

Una vez hecho el modelo la plataforma permite hacer como una “puesta en producción” y la utilización por todo el mundo con las siguientes pocas líneas de código que podéis encontrar en mi github: https://github.com/FJROAR/Ejemplo-Transformers-Clasifica01


Figura 3: 16 líneas de código python para ejecutar y representar el resultado del modelo sobre un posible tweet genérico


Y que generaría la anterior Figura 1. Nótese que si se cambia la línea 10 por “The party at my house was canceled”, entonces todo cambia en el sentido correcto:

Figura 4: Cambio de sentido cuando se trata de clasificar un nuevo tweet


Finalmente, para no extenderme demasiado algunas conclusiones al respecto:


  • Los transformes están aquí, han venido para quedarse y hay que estar al día, hay que tocarlos y aplicarlos, no basta sólo con leer, os animo a que os actualicéis y sigáis aprendiendo.


  • El que no se actualice en esto, en 5 años quedará desfasado porque a saber con qué se estará trabajando ... De hecho tenía que haber empezado con esto incluso bastante antes, al igual que pasó cuando irrumpió el Machine Learning, estamos ante una revolución que ya lleva algún tiempo.


  • En mi opinión todavía se tienen que simplificar más algunos métodos y mejorar algunas cosas, pero se está en un momento “técnicamente dulce” donde con un poco de conocimiento, se puede crear modelos muy potentes, pero aún es necesario una mínima base técnica.


  • El NLP siempre me ha gustado mucho, pero me había dado resultados no muy buenos, el wordtovec y demás, no es que fuese una maravilla, pero esto me ha sorprendido gratamente y ojalá hubiera estado habilitado hace unos años.



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

bottom of page