Azure | TIC, TAC, TEP: Aprender en el siglo XXI

octubre 10, 2021
de Paloma Recuero 1 comentario

Tu primer experimento en Azure ML Studio: El caso del Titanic (IV y fin) ¿Vivirán? : Prueba y puesta en producción del modelo

Por fin llegamos al final de nuestro experimento de creación de un modelo predictivo Machine Learning (ML) en Azure ML Workplace. Tras los post de introducción a la herramienta, creación del experimento y construcción del modelo, tan sólo nos quedaba probarlo con el conjunto de datos de Test y ver los pasos que hay que dar para “operativizarlo”. Y eso es precisamente lo que vamos a ver en este post.

5. Cómo convertir el experimento de entrenamiento en un experimento predictivo.

Una vez entrenado el modelo, ya podemos usarlo para hacer predicciones. Para ello, lo desplegamos como servicio web. Los usuarios pueden enviar los datos de entrada (input data) al modelo y el servicio devuelve la predicción de resultados. Para convertir el experimento de entrenamiento en predictivo, lo primero es ejecutarlo (“Run” en la barra de iconos inferior). El siguiente paso es seleccionar “Set up web service/Predictive web service”.

Ejecutamos el algoritmo y lo implementamos como web service.

Como hemos probado dos algoritmos diferentes, nos solicita seleccionar uno de ellos:

Seleccionamos el modelo de entrenamiento (entre las dos opciones).

En este este caso, elegimos el “Two-Class Decision Forest”, así que borramos la rama que habíamos creado para probar el otro algoritmo. Se genera una nueva pestaña “Predictive experiment” donde vemos que de forma dinámica se han ido agregando una serie de elementos y eliminando otros. En concreto, el objetivo es eliminar todos aquellos módulos que hacían falta para entrenar el modelo, pero ahora ya no son necesarios. También se agregan dos nuevos módulos Web service input y Web service output, que identifican los datos de entrada que se van a incorporar al modelo y los datos que devuelve el servicio. Aunque este proceso se ejecuta de forma automática al seleccionar la opción Set Up Web Service, también puede hacerse de forma manual, o incluso puede ser necesario “retocarlo” manualmente después.

En la parte inferior podemos ver los detalles del proceso de creación del experimento predictivo:

En este caso, vamos a recurrir al retoque manual. Una vez generado el modelo, entrenado y validado, ya no es necesario que los datos de test recorran todo el flujo del experimento. El módulo Web service input puede entrar directamente en el de Score Model. La operación es tan sencilla como arrastrar el módulo a la parte baja del diagrama (borrando en enlace que lo conectaba con el módulo Train.csv), y después conectarlo con el módulo Score Model).

(Más detalle sobre cómo preparar el modelo en How to prepare your model for deployment in Azure Machine Learning Studio).

5.1 Lo implementamos como web service

Una vez creado el experimento predictivo, lo vamos a implementar como servicio web. Para ello, lo primero que tenemos que hacer desde el entorno del experimento (experiment canvas) es ejecutarlo (“Run”). Una vez haya terminado de ejecutarse, seleccionamos Deploy Web Service y después, Deploy Web Service New. Se abre la página del portal Machine Learning Web Service portal opens. Nota: para implementar un Nuevo servicio web debes tener los permisos configurados en esa suscripción. Para saber cómo confirgurarlos en caso de que fuera necesario consultar: Manage a Web service using the Azure Machine Learning Web Services portal.

Figura 6: Consola web services en Azure ML Studio.

Vemos que ha generado una API que ejecutará nuestro modelo predictivo y a la que podremos acceder de distintas formas.

Opción 1:

La más sencilla de ellas es desde esta misma pantalla, seleccionando el botón azul “Test”.Vemos cómo se abre un cuadro de diálogo en el que podemos ir introduciendo a mano los valores de las distintas variables para que nos prediga si ese pasajero concreto, según el modelo que hemos entrenado, sobrevivirá o no.

Figura 8: Formulario para introducir manualmente los valores de los parámetros.

Opción 2:

La segunda opción es seleccionar “Test Preview”

Esta opción nos lleva al portal Azure ML web services, donde, si seleccionamos la opción “Test end point”, bajo el icono “Basics”, accedemos a una versión web de este mismo formulario para agregar los valores individuales de las distintas variables de un caso concreto:

Puede ser en el mismo formato que hemos visto antes:

O en formato .csv:

Opción 3:

La tercera opción es llamar a la API desde Excel, seleccionando el icono de Excel que aparece bajo APP. Al elegir esta opción, se descarga un fichero Excel con un add-on que permite conectar con los servicios web de Azure.

Figura 13: Llamada a la API desde Excel.

Por defecto, carga una muestra de los sample data, para poder empezar a trabajar.

Figura 14: Detalle del módulo de conexión a los web services desde Excel.

5.2 Probamos el funcionamiento del algoritmo como web service (según la opción 1).

Recordamos que, para entrenar el modelo nos descargamos de Kaggle el conjunto de datos Train.csv. Lo dividimos en dos partes (80/20) para poder hacer un Scoring del modelo y obtuvimos resultados como éste (Visualizando, dentro del Módulo “Scored Model”, el Scored Dataset). En este conjunto de datos, sabíamos qué pasajeros había sobrevivido, y cuáles no. El modelo ha aprendido a predecir la supervivencia “Scored Label”, basándose en los datos de entrenamiento de forma que cuando obtiene un “Scored Probability” > 0,5, le asigna un “Scored Label”= 1, Superviviente. Y si es menor, “Scored Label” = 0, Fallecido.

Figura 15: Scored dataset (datos de entrenamiento).

Ahora, vamos a comprobar cómo funciona el algoritmo al aplicarlo sobre el conjunto de datos de test.csv. Lo descargamos de Kaggle, como hicimos con el anterior. Los datos tienen este aspecto:

Figura 16: Aspecto de los datos del test.csv descargado de Kaggle.

Nos vendrá bien recordar el “Diccionario de Datos” porque vamos a agregar a mano alguno de estos ejemplos:

Si recordamos la “Opción 1”, la más básica, seleccionábamos “Test” y se nos abría un formulario para ir introduciendo los datos nuevos de forma manual.Si cogemos, por ejemplo, el primer registro: PassengerId,Pclass,Name,Sex,Age,SibSp,Parch,Ticket,Fare,Cabin,Embarked892,3,”Kelly, Mr. James”, male,34.5,0,0,330911,7.8292,,Q y queremos calcular la probabilidad de que este pasajero fuera superviviente, seleccionamos “survived”=1 y vamos rellenando el resto de los datos:

Figura 18: Agregamos manualmente los datos de esta pasajera.

El resultado de la predicción (si seleccionamos ver detalles) es:

Figura 19: Resultados de aplicar el modelo predictivo.

Como el valor “Scored Probabilities” es 0,625, por tanto, mayor que 0,5, el modelo predice que esta pasajera si sobrevivirá. Evidentemente, esta forma de probar nuestro modelo no resulta nada práctica para ponerlo en producción o hacer predicciones masivas. En ese caso, ya tocaría “aflojar la mosca”. Ejecutar algoritmos tiene siempre un coste en computación. Desde una Raspberry Pi a un HAL9000 (Space Odyssey) o un Cray).

Nosotros lo dejamos aquí, pero los interesados, pueden investigar un poco sobre el modelo de costes. Se paga por la computación necesaria para entrenar al modelo, por la computación necesaria para llamar al “scoring” (modelo entrenado) a escala, y en particular las llamadas al modelo entrenado “operacionalizado” en la Web API.

Con este post, cerramos la serie sobre el experimento de supervivencia del Titanic, donde hemos creado nuestro propio modelo de predicción en Azure Machine Learning Studio, haciendo el proceso completo, desde la carga y depuración de los datos, la generación del modelo, su entrenamiento, scoring, generación del modelo en formato web service y prueba sobre el conjunto de datos de test.

Esperamos que os haya sido útil y que os animéis a generar otros modelos basados en otros algoritmos y, en definitiva, seguir aprendiendo cada día un poco más de Ciencia de Datos.

Puedes encontrar la serie completa aquí:

Post publicado en ThinkBig Empresas en 2017. Habrá cambios en el software, pero se puede aplicar la misma dinámica a la nueva versión.

octubre 9, 2021
de Paloma Recuero 3 comentarios

Tu primer experimento en Azure ML Studio: El caso del Titanic (III): Entrenando el modelo

Bienvenidos a la tercera entrega del tutorial ejemplo de creación de un modelo de Machine Learning (ML) en Azure ML Workplace aplicado al dataset de pasajeros del Titanic. Tras la introducción a la herramienta que hicimos en la primera parte, en la segunda, creamos el experimento, y llevamos a cabo todos los procesos de carga, depuración y tratamiento de los datos, previos a la creación del modelo predictivo. Ahora, es el momento de construir el modelo.

4. Construcción del Modelo

En el primer post del experimento explicamos lo que eran los datos de entrenamiento y los datos de test (“Concepto Training Data vs Testing Data). Ahora vamos a dividir nuestro dataset de forma aleatoria en esos dos conjuntos de datos. Usaremos el 70% de los datos como datos de entrenamiento, y el 30% que nos reservamos nos servirá para evaluar la eficacia de nuestro modelo a la hora de predecir valores futuros o desconocidos. Para ello, usaremos el modulo de “Split”, siguiendo estos pasos:

En el menú “Data Transformation” (a la izquierda) seleccionamos “Sample and SplitSplit Data”.
Lo conectamos con el elemento anterior del flujo (“Select columns in Dataset”)
En el menú “Properties”, a la derecha damos al parámetro “fraction of rows in the first dataset” el valor 0.7. Esto significa que el 70% de los datos se asignarán de forma aleatoria al nodo de salida izquierdo (“1”), mientras que el 30% se asignará al nodo derecho (“2”) Esta partición de los datos en proporción 70/30 es un valor habitual en Machine Learning, pero podemos definir distintas proporciones según el problema.

Imagen de consulta de la búsqueda visual

4.1 Selección del algoritmo

Ya ha llegado el momento de identificar qué tipo de problema tenemos entre manos, y en qué tareas conocidas lo podemos descomponer. Para ello, nos puede resultar muy útil releer estos post de la serie de Machine Learning:

Así, podemos ver que se trata de un caso de aprendizaje supervisado, donde la clase de respuesta o variable objetivo es un valor categórico “0”=superviviente, “1”=fallecido. Por tanto, estamos ante un problema de clasificación binario o de clase dos. Podemos consultar, por ejemplo, la cheat-sheet de algoritmos machine Learning de Azure para intentar determinar qué algoritmo puede funcionar mejor en este caso. Hemos “recortado” la parte que nos interesa para verlo mejor. Por tanto, desde el botón START, seguimos la ruta, predecir categorías (“predicting categories”), dos categorías y vemos que nos propone una serie de algoritmos, indicando sus características más relevantes. Vamos a probar con el algoritmo de árbol de decisión.

Figura3: Extracto de la cheat-sheet de algorimos de Azure ML.

El concepto en el que se basan los árboles de decisión es, dado un conjunto de datos de entrada, con unos atributos bien definidos, puede ser clasificado totalmente basándose en decisiones sobre cada uno de ellos. Cada nodo de un árbol es una pregunta a la que hay que responder, y de él salen distintas ramas hacia cada una de las respuestas posibles. Una vez hemos llegado a los nodos “hoja” (los finales), el algoritmo ha clasificado correctamente el dato de entrado o ha dado con la decisión correcta. Visualmente lo veríamos así. En cada nodo se plantea una pregunta. En este caso, las preguntas clasifican por sexo, por edad y por tener familiares directos embarcados. Clasifica cada caso según estos parámetros y les asigna la etiqueta “Survived” o “Died”. Bajo cada etiqueta, tenemos la probabilidad de supervivencia y el porcentaje de casos observados. Así, según este diagrama, veríamos que un 36% del pasaje eran mujeres, y su probabilidad de supervivencia fue del 0,73. El 61% de los pasajeros eran hombres y el 2% niños. Entre los niños, las probabilidades de supervivencia eran mucho mayores (0,89) entre aquellos que iban acompañados de familiares directos. Aunque se suele decir aquello de “Las mujeres y los niños primero”, parece ser que en este caso fue “Los niños y los hombres primeros”, ya que, entre los hombres, la probabilidad de supervivencia fue del 0,83.

Figura 4: Ejemplo de visualización de un árbol de decisión.

Los árboles de decisión son muy populares porque son sencillos de construir y de comprender, siendo a la vez muy eficientes. Por eso, tras ver este ejemplo de visualización de uno de ellos, vamos a ver qué resultados obtenemos a aplicar este algoritmo al dataset de nuestro experimento.

4.2 Comienza el “entrenamiento”.

Figura 6: Agregamos el módulo correspondiente al algoritmo.

Para seleccionar el algoritmo, agregamos el módulo desde “Machine Learning/Initialize Model/Classification”. Aunque nos podría funcionar cualquier de los algoritmos de clasificación de dos variables, vamos a elegir el algoritmo “Two-class decission forest”.

Figura 5: Elegimos el algoritmo del menú Machine Leaning.

Ahora, agregamos un módulo de entrenamiento (desde “Machine Learning/Train/Train Module”) y lo conectamos al algoritmo y a la parte izquierda del módulo Split, que correspondía a los datos de entrenamiento (el 70% del dataset).Como en este caso no sólo queremos predecir el valor de una variable (si la persona sobrevivió o no al naufragio), sino que también queremos predecir la probalilidades de supervivencia que tenía un individuo determinado según el valor de ciertas variables, vamos a agregar también un módulo de Scoring. Desde la ruta “Machine Learning/Score/Score Module”. Conectamos el módulo de Scoring al módulo de entrenamiento del modelo, y a los datos “reservados” (el 30% que corresponde a la salida derecha del módulo Split data). Si tenemos dudas sobre qué lado del módulo es el que corresponde, siempre podemos visualizar los datos desde el menú contextual del módulo Split.

Al conectar los datos de test al modelo entrenado, vemos cuán bueno es el modelo que hemos entrenado con el training test para clasificar los casos nuevos que habíamos separado del dataset original. Comparando los valores reales de ese conjunto de datos (sabemos de cada individuo si sobrevivió o no), con lo que ha predicho el modelo, podemos calcular su precisión.

Figura 7: Conectamos los módulos Train Model y Score Model.

Por último, como vamos a querer evaluar el modelo, añadimos a continuación un módulo de evaluación desde “Machine Learning/Evaluate/ Evaluate Model” y lo conectamos con el de Score. Una vez hecho esto, ponemos el modelo a trabajar pulsando “Run”.

4.3 Evaluamos el modelo

Cada problema en Machine Learning tiene un objetivo diferente. Por tanto, las prioridades a la hora de evaluar si el rendimiento es bueno o malo se basarán en distintas métricas. En este caso, vamos a elegir maximizar el área bajo la curva RoC (RoC Auc). Explicar cómo se utilizan las curvas ROC para evaluación de modelos queda fuera del alcance de este post (haremos uno específico). Pero, por ahora, nos basta con tener en cuenta que este área posee un valor comprendido entre 0,5 y 1, donde 1 representa un valor diagnóstico perfecto y 0,5 es una prueba sin capacidad discriminatoria diagnóstica. En diagnósticos médicos, si el AUC es 0,8 significa que existe un 80% de probabilidad de que el diagnóstico realizado a un enfermo sea más correcto que el de una persona sana escogida al azar. Por esto, siempre se elige la prueba diagnóstica que presente mayor área bajo la curva.

Como valores de referencia para evaluar un modelo por este método tenemos:

[0.5, 0.6): Test descartable, malo
[0.6, 0.75): Test regular.
[0.75, 0.9): Test bueno.
[0.9, 0.97): Test muy bueno.
[0.97, 1): Test ¿demasiado bueno?

En el módulo “Evaluate Model/evaluation results/visualize”, podemos ver la curva ROC, la proporción de Falsos Positivos/Falsos Negativos (ver post sobre “Tipos de error en ML”), el valor AUC y otras métricas. En concreto, el valor AUC es de 0.814, es un valor bueno.

¿Cómo podríamos mejorar este valor?. Por ejemplo, ajustando los parámetros del algoritmo. Si nos vamos al módulo del algoritmo, podemos definir propiedades como el número de árboles que queremos que cree, la profundidad, el tipo de muestreo etc. En un futuro post específico sobre este algoritmo los veremos con detalle.

Figura 10: Menú de ajuste de parámetros del modelo.

Si visualizamos el módulo “Train Model” (desde su menú contextual) podemos incluso ver los árboles que ha creado, preguntando en cada nodo sobre diferentes parámetros.

Figura 11: Visualización de un detalle de uno de los árboles que ha construido el modelo.

4.4 Comparamos con otros modelos

Si queremos comparer nuestro modelo con otro basado en un algoritmo diferente, no tenemos más que elegir otro algoritmo, copiar y pegar los módulos que “Train Model” y “Score Model” que ya teníamos, y conectarlos entre ellos y con los conjuntos de datos de la misma forma que hemos hecho antes. La salidad del “Score Module” la llevamos al “Evaluation Module” que teníamos anteriormente y así podemos comparar el rendimiento de dos modelos de machine Learning que hemos entrenado por separado.

El Nuevo valor de AUC con el modelo “Two-Class Boosted Decision” es ligeramente superior, pero en este caso, al ser tan pequeña la diferencia, sería conveniente tener en cuenta otros valores como la exactituc (“Accuracy”) o la precisión (“precisión”).

Figura 13: Nuevo valor AUC con el segundo algoritmo.

En este ejemplo, el mejor algoritmo teniendo en cuenta estas últimas métricas, sería el Two class decisión forest.Et voilà. Hemos construido nuestro primer modelo machine Learning en Azure ML Studio, lo hemos entrenado con el dataset del Titanic, hemos analizado su rendimiento comparándolo con el de otro algoritmo distinto y ya, sólo nos quedaría operativizarlo.

En el próximo post, cerramos la serie y probamos nuestro modelo con el dataset de Test que nos descargaremos de Kaggle.

¡No te pierdas el final de nuestro experimento!