Papá!!! No me ponen en producción mi xgboost

He conocido a más de uno que con una mayor o menor dosis de ingenuidad pretende, sin conocer el stack tecnológico real, crear modelos de analítica avanzada y ponerlos en producción como sin tal cosa hasta que le llega su primer “baño de realidad”.

Y sí amigos, ya bien entrado el siglo XXI, existen cosas que muchos milennials ignoran pero que siguen siendo fundamentales en su vida aunque lo igneren. Una de ellas es el COBOL, un lenguaje que nació a finales de los 50, en concreto en 1959 y donde hay que destacar que, aunque en verdad intervino un equipo (el comité CODASYL Comité on Data Systems Languages) en su creación, fue una mujer, Grace Hopper, por aquel entonces almirante de la marina de los EEUU, a quien se le considera su “madre intelectual”, la que asienta sus bases, por lo que se consigue lograr un lenguaje suficientemente legible en inglés, estándar y portable para aplicaciones de negocio que aún a día de hoy está en la mayoría de las entidades de cierto calibre, a pesar de que algunos listos como Elon Musk, van a hacerlo desaparecer... ¿Lo logrará?

Una de las razones por las que traigo aquí el lenguaje es porque como es comentado, es un elemento esencial en la sociedad y no son pocas las grandes empresas que lo están utilizando y a pesar de sus ventajas, impone sus limitaciones. Así por ejemplo ¿Quién no usa actualmente una tarjeta de crédito/débito para hacer una compra? Este acto tan sumamente cotidiano, en la mayoría de los casos tiene un soporte COBOL donde los entornos de programación aún resultan un poco “salvajes” para estas nuevas generaciones acostumbradas a los notebooks y a los IDEs de juguete que te hacen creer que ya lo dominas todo:

Aunque el proceso es aún más largo, me interesa el punto donde se introduce modelización en todo este proceso y es justamente cuando se pasa la tarjeta de crédito por el TPV de un establecimiento para hacer una compra, en ese momento y en cuestión de segundos, un programa COBOL bajo (suponiendo entorno IBM) CICS (Customer Information Control System) realiza de modo rápido y seguro:

·        La lectura de los datos de la tarjeta y del cliente.

·        Consulta saldos, límites y estado de la cuenta (DB2/VSAM).

·        Aplica reglas de negocio (importe máximo, financiación, bloqueos).

·        Devuelve aprobado o denegado en milisegundos.

Justo donde se Aplica reglas de negocio es donde interviene uno o varios modelos, junto con un conjunto adicional de reglas que acompaña a todo el proceso de decisión, en muchos de los casos totalmente automática.

Es pues en el punto anterior donde se enfoca este trabajo y donde se va a desprender el porqué la regresión logística junto con (o sin) la metodología credit scoring es a día de hoy aún la más utilizada y con la que cualquier estadístico aka data scientist puede fácilmente hacer ganar a su empresa su primer millón de euros (o mucho más), dejando para otro día modelos como los random forest o xgboost. Además, voy a ser más preciso ya que no voy a tratar aquí sobre la construcción de un modelo de credit scoring, sino que de lo que voy a tratar es ¿Cuáles son las pautas que se deben observar para poner un modelo en producción bajo este tipo de entornos?

Claramente aquí la diferencia con los sistemas Cloudera y otros más actuales, donde se pueden “poner en producción” modelos de analítica avanzada es evidente y desde luego, un desarrollador de modelos actual debe tener unas ideas generales de cómo funciona si no quiere tener conflictos con los que finalmente le pondrán el modelo en producción, ya que los desarrolladores en mainframes tipo IBM hablan un lenguaje totalmente distinto basado en las entradas y salidas de un programa COBOL que para nada se parecen a R, Python, C, java, SQL o cualquier cosa que se esté usando en los últimos 50 años.

¿Qué debe tener preparado un modeler actual para llevar a cabo una puesta en producción en COBOL?

1. Por lo pronto, y aunque no es totalmente obligatorio, conviene que la propuesta a implementar sea de tipo credit scoring y la razón es sencilla, bajo esta metodología, se pueden ir observando lo que se denominan los scoring parciales que se comentan en el apartado (3). En todo caso, no resultaría muy complicado poner un modelo en producción tipo regresión logística ridge / lasso o incluso decisión trees, aunque, si nos vamos a random forest o modelos más avanzados, la implementación se complicaría enormemente al tener que generar un programa COBOL que sería extraordinariamente largo y más complejo de validar su funcionamiento, por tanto no va a ser normal encontrarlos en la realidad

   
   

2. Lo segundo es haber elegido variables que existan y sean accesibles en el momento de la solicitud por nuestros sistemas. En ocasiones, el programador de COBOL tendrá que crear nuevas variables a partir de combinaciones de las existentes, por tanto, es factible crear (y se hace a menudo) en nuestros modelos interacciones entre variables o combinaciones de éstas

   
   

3. La principal ventaja de la metodología de credit scoring es que cada una de las variables que compone el modelo se discretiza a unos valores que suelen ser los valores WoE que ahora no se van a tratar y de aquí se convierten en tramos de score, por tanto, el modelo final es una suma de lo que se denominan scoring parciales y que no son más que el aporte de cada variable por separado, así pues, cada variable aporta un número de posibles valores que se tomarán en función del valor real que aporta la variable y dada una solicitud de compra, lo que hace el modelo es generar una puntuación tal como sigue:

   
   

   Score = Score base + Score Parcial 1 + …+ Score Parcial p

   
   

4. Un valor habitual que se toma para Score base es el de 600 o uno cercano, aunque puede variar por diversas razones que tampoco se discuten aquí

Por lo que como se observa, tras pasar la tarjeta por el TPV se genera una suma tal como sigue y la decisión de aceptar / rechazar se tomará en función de si el valor Score es suficientemente elevado, junto con reglas adicionales que como se ha comentado, es habitual que existan.

No obstante, aún no se ha respondido a la pregunta anterior ¿Qué debe preparar el modeler? Pues básicamente cuando por ejemplo se trabaja en R, como suele ser mi caso, los elementos a preparar son básicamente un conjunto de datos sintéticos y controlados de al menos 25 – 50 test. El soporte para esto puede ser Excel y si se quiere validar la implementación de un scoring en no más de una mañana, se debe hacer en colaboración con el que haya hecho el programa COBOL. Y sí, he dicho bien, validar la programación de un modelo en COBOL se hace en una mañana o incluso en menos tiempo, aunque bien es cierto que he visto validaciones donde se han tirado meses y en general las razones han sido:

• El modeler no tenía preparado un juego de pruebas adecuado

• El programador Cobol no había creado un programa con los requerimientos

En general, los requerimientos no suelen ser complicados, no obstante, es habitual tener que hacer correcciones sobre la validación, por eso como best practice conviene que el programa esté creado y que la persona que lo haya hecho esté durante la validación, en esta se contrasta lo siguiente a través, generalmente del uso de un servicio web que emula la petición en real de un cliente donde se graban los valores reales de las variables (aquí se supone que hay sólo 3 variables en el modelo):

• Si se supone que hay 3 variables, el score se puede expresar mediante el siguiente pseudocódigo (que debe ser pasado a COBOL):

  SCORE = 600

IF EDAD >= 18 AND EDAD < 30 THEN SCORE = SCORE - 5

IF EDAD >= 31 AND EDAD < 35 THEN SCORE = SCORE + 5

IF EDAD >= 36 AND EDAD < 45 THEN SCORE = SCORE + 10

IF EDAD >= 46 AND EDAD < 55 THEN SCORE = SCORE + 15

IF EDAD >= 55 THEN SCORE = SCORE + 10

IF INGRESOS < 1000 THEN SCORE = SCORE - 10

IF INGRESOS >= 1000 AND INGRESOS < 2000 THEN SCORE = SCORE + 0

IF INGRESOS > 2000 THEN SCORE = SCORE + 15

         IF VINCULA = ‘BAJA’ THEN SCORE = SCORE – 8

         IF VINCULA = ‘MEDIA’ THEN SCORE = SCORE + 3

         IF VINCULA = ‘ALTA’ THEN SCORE = SCORE + 10

• Una vez se convierte lo anterior a COBOL, el programador en este lenguaje puede ir viendo si se realiza todo de modo correcto cada vez que se introduzca un Test, así este programa junto con el data scientist para el primer caso debería observar que al principio la variable score toma el valor 600, después el 595, tras esto mantiene el 595 y finalmente debe tomar el valor 587 y análogamente con el Test 2, la evolución sería 600, 610, 625 y 636

  
  

• Para concluir la validación conviene realizar tantos test como tramos existan y prestar especial atención en los puntos límites donde existen >= o <=

El COBOL a pesar de su antigüedad no es un lenguaje difícil, si bien no es un código para programar temas complejos a nivel algorítmico. Es un programa enfocado para mover ficheros, valores en dichos ficheros y hacerlo de un modo rápido, perdurable en el tiempo y sin errores. Así pues, una de las razones por las que persiste este lenguaje es porque es rápido y es muy resiliente a errores, una vez se verifica que el código funciona correctamente. Por otro lado, es un leguaje auditable, si bien es cierto que es un lenguaje que requiere mucho código, es decir, como se observa en la primera figura, crear un Hola mundo, no se hace con 2 líneas y requiere ser por tanto muy específico en cualquier instrucción que se genere, así pues, el fragmento anterior de código tendría una forma aproximada de:

       WORKING-STORAGE SECTION.

01 EDAD            PIC 9(3).

               01 INGRESOS   PIC 9(7).

               01 VINCULA       PIC X(5).

01 SCORE           PIC S9(4).

       PROCEDURE DIVISION.

           MOVE 600 TO SCORE

           IF EDAD >= 18 AND EDAD < 30

               SUBTRACT 5 FROM SCORE

           END-IF

         IF EDAD >= 31 AND EDAD < 35

               ADD 5 TO SCORE

           END-IF

           IF EDAD >= 36 AND EDAD < 45

               ADD 10 TO SCORE

           END-IF

           IF EDAD >= 46 AND EDAD < 55

               ADD 15 TO SCORE

           END-IF

           IF EDAD >= 55

               ADD 10 TO SCORE

           END-IF

           IF INGRESOS < 1000

               SUBTRACT 10 FROM SCORE

           END-IF

           IF INGRESOS >= 1000 AND INGRESOS < 2000

               ADD 0 TO SCORE

           END-IF

           IF INGRESOS > 2000

               ADD 15 TO SCORE

           END-IF

           IF VINCULA = 'BAJA'

               SUBTRACT 8 FROM SCORE

           END-IF

           IF VINCULA = 'MEDIA'

               ADD 3 TO SCORE

           END-IF

           IF VINCULA = 'ALTA'

               ADD 10 TO SCORE

           END-IF

Finalmente, espero haber aclarado un poco el porqué cuesta poner en producción un modelo tipo xgboost y por qué el credit scoring o la regresión logística siguen siendo aún los que más ingresos generan y espero haber levantado la curiosidad de más de uno en este lenguaje, cuyos programadores van desapareciendo y resultan cada vez más cotizados al igual que los fontaneros y los electricistas… Sino lo creéis, veréis cuando se os rompa una cañería ...