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

Thursday, December 14, 2017

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.
Figura 1 : 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).
Figura 2 : 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 inputWeb 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.


Figura 3 : Generación del experimento predictivo.



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


Figura 4: Detalles del proceso.
Figura 4 : Detalles del proceso.

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).


Figura 5: Simplificación del algoritmo.
Figura 5 : Simplificación del algoritmo.



  

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.
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 7: Botón "Test".
Figura 7: Botón "Test".

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

Opción 2:

La segunda opción es seleccionar “Test Preview”

Figura 9: Opción Test preview.
Figura 9: Opción 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:


Figura 10: Portal web services.
Figura 10 : Portal web services.

Puede ser en el mismo formato que hemos visto antes:


Figura 11: Formulario por defecto.
Figura 11 : Formulario por defecto.


O en formato .csv:


Figura 12: Formulario 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.
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.
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).
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.
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:

Figura 17: Diccionario de datos.
Figura 17 : Diccionario de datos.

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,Embarked
892,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.
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.
Figura 19 : Resultados de aplicar el modelo predictivo.
Figura 20: Detalle del resultado.
Figura 20 : Detalle del resultado.


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.

No te pierdas ninguno de nuestros post. Suscríbete a LUCA Data Speaks.

No comments:

Post a Comment