En el episodio de hoy de Un podcast ninja sobre Big Data terminamos de repasar las 43 reglas del Machine Learning de Google.
En los dos últimos episodios hemos repasado reglas sobre cómo ir introduciendo poco a poco y únicamente cuando sea necesario el Machine learning en proyectos que ya están en marcha y cómo ir de menos a más.
Sin obcecarnos con utilizar el último modelo de Machine Learning, el más potente ni el más brillante del estado del arte.
Sino que empezamos poco a poco con modelos sencillos, comprobamos que les llegan los datos que queremos que les lleguen y que van sacando resultados que cuadran con los objetivos.
Hemos repasado también reglas sobre cómo sacar el máximo partido a los datos que le pasamos al modelo de Machine Learning y que aprenda a inferir los patrones de la manera más precisa posible posible pero sin caer en aprenderse los datos de entrenamiento de memoria, el temido overfitting.
Todo esto, gracias a las reglas relacionadas con la ingeniería de características. El arte de transformar los datos en información útil para el modelo.
Los mandamientos que vamos a tratar hoy están relacionados con todo aquello que sucede una vez ya nos hemos peleado al menos una vez con todos los pasos para poner a funcionar un modelo de Machine Learning en nuestro sistema.
Sin embargo, en el mundo real no hay ningún modelo que nos vaya a servir para siempre y vamos a tener que re-entrenar con mayor o menor frecuencia dependiendo del caso de uso pero es algo a lo que nos vamos a tener que hacer a la idea.
Para empezar vamos a tener que lidiar con las diferencias entre los datos de entrenamiento y los datos que se va a encontrar el modelo cuando tenga que hacer predicciones.
Con datos reales.
Lo primero que observaremos es una desviación entre el rendimiento del modelo cuando lo estábamos entrenando y cuando está en producción.
La clásica situación en la que le enseñáis a vuestra mascota a hacer un truco, lo aprende perfectamente pero cuando le vais a mostrar a alguien vuestras habilidades como adiestrador, el animal ha sufrido una pérdida absoluta de memoria y no hace nada.
Algo parecido.
Aquí no es que el modelo nos quiera dejar mal en presencia de jefes y clientes sino que hay cosas que puede que no hayamos tenido en cuenta como
Hay veces que las predicciones de los modelos pueden influir en cómo se etiquetan los datos para el entrenamiento de futuras versiones del modelo así que en cierta manera, el modelo estaría aprendiendo indirectamente de sus propias predicciones.
Un ejemplo muy directo de esto sería la situación en la que todo el mundo empieza a utilizar IA para crear contenido en internet.
En un momento dado, habrá tanto contenido en Internet generado por IA que las nuevas versiones aprenderían de lo que otros modelos han generado.
Estas situaciones, en las que la desviación entre el entrenamiento y la fase de producción, que es aquella en la que el modelo llega al mundo real, como si dijéramos, es muy grande, pueden hacer que el rendimiento de nuestro modelo disminuya o se vuelva inservible directamente.
Por tanto…
La mejor manera de asegurarnos de que no tenemos una desviación entre nuestra fase de entrenamiento y cuando servimos los resultados es ir guardando todos estos datos para utilizarlos en nuestro dataset de entrenamiento.
Si hay algún sitio en el que se da importancia a los datos es en datos.ninja.
Peeeero, por mucho que nos gusten los datos y aunque a veces nos cueste reconocerlo...
Hay veces que tenemos demasiados datos y tenemos que quedarnos con un conjunto más pequeño de todos los datos que tenemos y descartar el resto.
Aunque sea para entrenar el modelo.
Bien.
Pues cuando nos vemos obligados a hacer esto puede que la tentación sea quedarnos con las mil primeras observaciones, las mil primeras filas del dataset y descartar el resto.
🚨 ERROR 🚨
Esto, para hacerlo bien, hay que decidir la probabilidad con la que nos quedamos con cada una de las observaciones y luego le daremos el peso (importancia) que le corresponde a cada una de estas observaciones.
Por ejemplo, si estamos desarrollando un modelo de IA para la predicción de la probabilidad de que un determinado paciente padezca una enfermedad y tenemos
Para nuestro caso, serán más importante las muestras procedentes de participantes en el ensayo clínico que las de un paciente genérico.
En el caso de tener que reducir los datos de entrenamiento procuraremos darle más importancia a las del ensayo en vez de muestrear el dataset aleatoriamente.
Esta os la explico con un ejemplo.
Estamos intentando predecir el comportamiento del algoritmo de Instagram.
Tal vez el secreto mejor guardado de la historia de la humanidad 🤫
Pues si estuviéramos intentando crear un modelo de Machine Learning capaz de predecir si un post va a hacerse viral, podríamos estar usando como características el número de me gustas, los comentarios o las veces que se ha compartido.
El tema es que si tenemos este post en concreto en nuestro dataset de entrenamiento es bastante probable que estas características hayan cambiado desde el momento del entrenamiento al momento actual por lo que la predicción podría cambiar y tendríamos desviación entre lo que obtenemos en entrenamiento y en predicción lo cual podría afectar al rendimiento del modelo como veíamos antes.
Para solucionarlo…
Pues eso. Reutilizar es bien 🙂
Probarlo de esta manera es lo que nos dirá si el modelo generaliza bien a nuevos datos que no ha visto antes, que es lo que nos interesa, o lo hemos sobreajustado con los datos de entrenamiento.
Me explico.
Imaginad que estamos ante el clásico problema de Machine Learning de clasificar correos de entrada como Spam o no spam.
Si un correo es spam, se filtra y no se muestra al usuario.
Va directamente a la bandeja de spam.
Entonces si el modelo deja pasar un correo que nuestro usuario marca como SPAM podemos vernos en la tentación de utilizar este ejemplo como parte de un nuevo conjunto de datos de entrenamiento.
Sin embargo, estaríamos introduciendo un sesgo de muestreo porque este mail que ha pasado el filtro pero que el usuario ha marcado como spam no es representativo de todos los mails de spam sino de los que pasaron el filtro.
Una manera de afrontar esto sería bloquear casi todos los mails menos un porcentaje muy pequeño que sí llegarían al usuario, lo cual degradaría un poco el rendimiento del modelo porque estamos dejando pasar algunos mails de spam.
Sin embargo, el usuario marcaría los correos de spam sin que estos hayan pasado ningún filtro anterior.
Por lo tanto, los datos serían de más calidad para nuestro nuevo dataset de entrenamiento.
¿Qué significa esto?
Pues volvemos a la piedra angular de Google, que es quien nos envía estos mandamientos, y esta es el rankeado de resultados de búsqueda en internet.
Entonces, nos ponemos en la piel de esta gente a cargo de los modelos de IA que ordenan los resultados de búsqueda en google y resulta que nos hemos currado un nuevo modelo que pone patas arriba el orden de los resultados de búsqueda.
Como cambiar el orden de los resultados de búsqueda hace que cambie cómo interactúa el usuario con los distintos resultados, esto va a cambiar también los futuros resultados de búsqueda, que a su vez serán diferentes y volverán a cambiar los rankings de otras consultas y así… se convierte esto en un ciclo sin fin….
Bien.
Pues para que este efecto mariposa de cambiar el modelo de IA de rankeado no se nos vaya de las manos lo que se suele hacer es dar importancia a las características que son únicas para consultas específicas.
Esto consigue que no aparezcan en los resultados siempre los más populares, sino los más concretos para la consulta en cuestión.
De ahí el llamado long tail de SEO.
Por ejemplo, en el caso de aplicaciones en un market no vamos a recomendar siempre la misma app porque sea popular sino que el objetivo es fijarnos en las características que nos hagan considerar lo que el usuario realmente busca.
Todos sabemos que es más probable que la gente haga clic en el primer resultado que se muestra.
Entonces… ¿se interactúa más con un resultado que se muestra en primer lugar porque es más interesante o porque está en primer lugar?
Es un poco como el problema del huevo y la gallina 🐓
Para poder salir de dudas, una opción es añadir como característica el orden en el que aparece el resultado para futuros entrenamientos.
Así el modelo aprenderá que la característica en la que le pasamos el orden de aparición en los resultados es importante y le asignará un peso elevado.
El modelo aprenderá que aparecer en primera posición es importante para obtener más clics peeero a la hora de predecir no vamos a tener esa información porque estamos puntuando a los candidatos antes de decidir en qué orden vamos a mostrarles.
Sí, también tenemos que monitorizar la desviación entre los resultados de entrenamiento y fase de predicción para ver si ha llegado el momento de re-entrenar el modelo.
Que será cuando está desviación sea notable.
Una de dos, o cambiamos el objetivo del modelo de ML para que se alineen mejor con los objetivos generales del producto.
Por ejemplo, si estabamos optimizando para maximizar los clics de usuario, podríamos cambiar el enfoque para optimizar la participación o satisfacción del usuario.
O, podemos cambiar los objetivos del producto para que estén más en sintonía con lo que nuestro sistema de aprendizaje automático puede lograr de manera efectiva.
Esto ya, depende de cada caso.
Todo ninja del Machine Learning tiene como labor la optimización de un objetivo.
Una vez que se mejora ese objetivo lo suficiente el modelo estará listo para su lanzamiento.
O no…
Podría ser que tuviéramos métricas a corto plazo (Clics, conversiones, comentarios, tiempo que pasa el usuario en nuestra web o app) que estuviéramos mejorando y sin embargo, hacemos un experimento y el objetivo a medio plazo empeora.
Conseguimos más clics pero a medio plazo se pierden usuarios.
Nuestro modelo no llegaría a la fase de lanzamiento aunque se mejoran los objetivos a corto.
El truco aquí, como hemos visto en otros episodios, es saber cómo relacionar estas métricas con los objetivos reales del negocio.
Lo que se busca realmente es aumentar la satisfacción de los usuarios, llegar a más gente y, por supuesto, aumentar el beneficio.
El modelo de ML no puede salir adelante si va en contra de estos objetivos a medio plazo.
Un ensemble no es más que una combinación de varios modelos.
Su objetivo es predecir la misma cosa pero al trabajar unidos, en este caso combinados, rinden mejor.
Les dedicaremos, por supuesto, un episodio del podcast.
Pero por supuesto, siempre buscando el equilibrio entre lo que nos va a costar incorporar esas nuevas fuentes de datos y el beneficio que podemos obtener.
Cuando estamos diseñando un sistema de recomendación, por un lado tendremos como objetivo personalizar los resultados para cada usuario peeero por otro lado tenemos características como pueden ser “me gustas”, comentarios, número de veces que se ha compartido el contenido…
Estas características indican popularidad.
La magia de los sistemas de recomendación está en combinar contenido popular con contenido personalizado sin olvidar diversificar el contenido para que los usuarios no se aburran.
Eso es lo que hace google con youtube, por ejemplo.
Una de las técnicas que se suele usar en sistemas de recomendación es ver que les interesa a personas con las que estáis conectadas.
En las RRSS, por ejemplo.
Sin embargo, muchas veces los intereses de un usuario pueden variar dependiendo de la plataforma. Aunque las personas con las que conecta siguen siendo las mismas.
Y puede ser muy útil capturar estos datos y utilizarlos si estamos construyendo sistemas de recomendación.
Y con esta terminaríamos las 43 reglas del Machine Learning de Google.
Si aún seguís por aquí deciros que sois unos ninjas hardcore porque algunas de estas reglas que os he explicado muy MUY por encima son complejas, no os creáis…
Si os habéis quedado con ganas de más, podéis encontrar el artículo completo escrito por Google aquí.
Espero que el episodio de hoy os sea de provecho y que aprendáis algo de valor.
Si es así, no olvidéis dejar una valoración de 5 estrellas del podcast en Apple podcasts, en Spotify, en Ivoox, en Google podcast 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.