En el episodio de hoy de Un Podcast Ninja sobre Big Data terminamos la saga de episodios dedicados a las etapas de un proyecto de Machine Learning. Hoy hablamos del despliegue del modelo y su monitorización.
Hoy vamos a hablar de todo lo que nos queda por hacer una vez hemos entrenado el modelo de Machine Learning. Todas esas cosas de las que nunca hablan en los cursos de Inteligencia Artificial.
La mayoría de los modelos de Machine Learning que se entrenan en el mundo nunca llegan a ser utilizados. Especialmente si forman parte de algún programa de estudios de Inteligencia Artificial o Ciencia de datos.
Y es una pena…. ¡Con todo lo que hemos hecho para llegar hasta aquí!
Comenzamos en el episodio 13, por el planteamiento del problema y las cosas que deberíamos preguntarnos para comenzar con buen pie…
Después de esto, pasamos al episodio 14 para construir un dataset de entrenamiento tope de gama que nos permita entrenar un modelo tope de gama.
El modelo más potente entrenado con datos mediocres nos dará un resultado mediocre.
Vimos que un dataset tiene que ser representativo, en el mejor de los casos los datos de entrenamiento se obtendrán en el mismo entorno en el que luego se va a utilizar el modelo.
Deberían de ser también consistentes y fiables. Es decir, recolectados de la misma manera y de fuentes que más o menos funcionan todo el rato, no por ejemplo, un sensor que solo nos da datos 1 vez al mes, cuando le da por funcionar y el resto nada.
Y datos en cantidad, que eso siempre viene bien.
Además, también vimos cómo etiquetar esos datos para poder formar el conjunto de datos de entrenamiento completo.
Y la semana pasada, en el episodio 15, vimos cómo entrenar el modelo.
Pues para que ese modelo no pase a ser parte de todos los modelos de Machine Learning entrenados y olvidados del mundo hoy vamos a ver la etapa de despliegue.
Pero lo primero, antes de desplegar nada, sería presentar los resultados al cliente. Esta fase puede que sí lleguen a vivirla algunos de los modelos de Machine Learning que nacen en los programas de estudios de Inteligencia Artificial y que requieran presentar los resultados a un profesor.
Pero hay algunas diferencias en la manera de hacerlo…
La principal es que el profesor sabe de Machine Learning y tiene unas expectativas más realistas. Sin embargo, las expectativas de un cliente no especialista en IA podrían ser un poco demasiado altas. Y el hype podría matar al proyecto.
Por ejemplo, el cliente podría pensar que el modelo de Machine Learning “entiende” lo que está resolviendo. Aquí sería buena idea mostrar algunos casos en los que el modelo no haya acertado en su predicción. Especialmente, aquellos casos que igual estarían super claros para un humano.
También es una buena práctica dejar en casa los términos abstractos. Si me decís que el modelo tiene una precisión del 97% yo voy a escuchar que acierta siempre, o casi, pero vamos que acierta mucho.
Ahora si decís que de todos los sobaos que pasan por de la línea de producción en un día el modelo etiqueta como sobaos correctos a 20 que estaban mal y descarta 30 sobaos que estaban bien pues hay más probabilidades de que el cliente se haga una idea correcta sobre qué esperar de los resultados.
Si dejamos contento al cliente con los resultados ha llegado la hora de que nuestro modelo se despliegue. Es decir, que vaya a ser utilizado en un entorno real.
La manera más común para desplegar un modelo de Machine Learning es mediante una API. Una API no es más que una capa de abstracción que permite comunicarse a dos aplicaciones. En este caso, una de ellas sería nuestro modelo de Machine Learning que espera unos datos para hacer una predicción o inferencia y la aplicación que genera esos datos y espera un resultado.
Básicamente, hace falta una API porque las aplicaciones pueden haber sido desarrolladas en distintos lenguajes y es mucho más fácil hacer esta capa que traducir cualquiera de las dos apps al otro lenguaje, que igual ni tenemos acceso a él, ni sabemos hacerlo e integrarlas.
Como un intérprete de las naciones unidas que hace que el representante de la India se entienda con el de Brasil sin necesidad de que el indio aprenda brasileño ni viceversa.
Para esto hay que garantizar que la aplicación que va a pasar los datos al modelo y va a usar la predicción tenga conexión a internet,porque si no no va a poder acceder al modelo y no va a funcionar.
Bueno, pues decidimos si queremos que la API de nuestro modelo esté en un servidor propio que tenga siempre conexión a internet o en la nube y listo.
A veces, la opción de una API no es válida para el problema. Por ejemplo, si no va a haber internet donde se tenga que utilizar o si los datos que va a utilizar son super sensibles y secretos de manera que no pueden salir del dispositivo del usuario, ni siquiera a través de una conexión segura.
En este caso, se podría hacer una mini versión del modelo que se ejecutara directamente en un teléfono móvil o en dispositivo muy pequeñito con mucha menos capacidad que un ordenador. Sería el caso, por ejemplo, de las cámaras que detectan automáticamente caras antes de hacer una foto.
Y luego, la tercera opción para desplegar un modelo es hacerlo en el navegador. Este caso podría usar una API pero tiene la ventaja de que en vez de usar los recursos de un servidor donde vive el modelo para calcular la predicción, que serían los tuyos. Usaría los recursos del navegador de quién está utilizando el modelo. Lo que implica menos dinero gastado en servidores.
O si pasa lo mismo con los datos que en el caso anterior, que son muy delicados y no deberían salir del ordenador del usuario, ni tan siquiera encriptados.
Podría parecer que el una vez que elijamos como desplegar el modelo, ese modelo que entrenamos con aquellos datos que con tanto cuidado habíamos recolectado y preparado pues ya habríamos terminado.
Pero tampoco porque los modelos tienen tendencia a perder efectividad con el tiempo. Los datos evolucionan. Dependiendo del caso de uso pueden evolucionar más o menos rápido pero cambian.
Puede ser que sean datos estacionales, como podría ser un ecommerce de ropa en el que se comprará más ropa de invierno cuando las temperaturas bajan o puede que los patrones de comportamiento cambien de manera drástica. Por ejemplo, usuarios de una red social que pierde popularidad frente a otra.
El modelo, como los datos que lo han entrenado, está vivo y es necesario monitorizar su rendimiento porque es posible que necesite ser re-entrenado con un nuevo dataset de entrenamiento. Algunos modelos envejecen mejor que otros.
Por ejemplo, en el caso de clasificación de sobaos de una línea de producción tal vez no veamos una disminución del rendimiento del modelo hasta que se cambie la forma del sobao o la iluminación de la fábrica o algo así, pero en el caso de detección de fraude en un ecommerce los cambios son mucho más rápido. Los timadores no paran de idear nuevas formas de defraudar.
Además, deberíamos mantener vigilados los objetivos que queríamos cumplir cuando planteamos el problema. Y no me refiero al rendimiento del modelo si no que si rescatamos la escuela de yoga online que quería incorporar un sistema que recomendara nuevas clases a sus alumnos según sus preferencias, deberíamos de ser capaces de ver si realmente los alumnos están más satisfechos, si acaban haciendo esas clases y si el número de bajas de la plataforma ha disminuido.
Así que en cuanto hayamos desplegado nuestro modelo de Machine Learning y esté haciendo sus primeras predicciones hay que empezar a pensar en recolectar y etiquetar nuevos datos para volver a re-entrenar el modelo cuando su rendimiento empiece a deteriorarse.
Como veis, hay mucho más allá en un proyecto de Machine Learning que conseguir entrenar un modelo que consiga un 99% de precisión en sus predicciones sobre un conjunto de datos que nos viene dado.
Espero que os guste el episodio 😊
Si es así, no olvidéis dejar un «Me gusta» y algún comentario al episodio en Ivoox o una valoración de 5 estrellas del podcast en Apple podcasts, en Spotify, en Google podcasts o donde quiera que escuchéis el podcast.
Recordad que si tenéis cualquier duda o pregunta podéis contactar conmigo a través del formulario de contacto o podemos seguir la conversación en Twitter.
Muchas gracias por estar ahí y os espero en el próximo episodio de Un Podcast Ninja sobre Big Data.