En el episodio de hoy de Un podcast ninja sobre Big Data vamos a hablar de las las 43 reglas del Machine Learning de Google.
Google lleva haciendo Machine Learning desde antes de que fuera mainstream y algo habrán aprendido de todas las líadas, de los aciertos y sobretodo de la cantidad de datos que manejan.
Porque imaginad la cantidad de datos…
Sin hablar de las fotos de Google Fotos, el email en Gmail…
Os hacéis una idea… me parece
Bien.
Pues en todos esos productos hay modelos de Machine Learning funcionando así que algo de Machine Learning sabrá esta gente.
Otra historia es que hayan sabido petarlo con sus modelos generativos tanto como OpenAI, que me parece que no… pero eso ya lo hablamos otro día si eso.
Y menos ahora que parece que ya no se saca nada al mercado que no diga en el subtítulo “hecho con Inteligencia Artificial”.
Está claro que la IA mola pero lo primero y fundamental antes de lanzar un producto con machine learning es tener datos.
Si por ejemplo tenemos una tienda online y pensamos que lo que más molaría de la historia es meterle un modelo de Machine Learning que recomiende al comprador justo algo que no sabía que quería pero que nosotros vendemos pues sí… tenéis razón.
Eso sería una venta casi asegurada.
Lo que pasa es que si no tenemos los datos adecuados igual no ha llegado el momento del Machine Learning para nosotros.
Primero tenemos que conseguir los datos que necesitaremos para entrenar ese modelo.
Y de mientras, podemos usar el sentido común y mostrarle los 5 productos que más se venden en nuestra tienda online.
Seguro que con eso ya tenemos una buena parte del camino hecho.
Ya no digo antes de empezar a entrenar el modelo de machine learning sino incluso antes de decidir lo que queréis que haga ese modelo.
Monitorizad lo que pasa en vuestro sistema.
En vuestra tienda online o en lo que sea que queráis vitaminar con machine learning.
Por ejemplo, el número de formularios de contacto que recibís con preguntas de un determinado producto o los productos que se compran juntos en el mismo ticket.
Lo que sea de interés y que pueda ser medido, servirá para tener una visión más general sobre todo el sistema.
Aquí los analistas de datos es donde brillan más fuerte.
Ellos deciden qué se puede medir, qué es interesante medir y qué nos va a dar una visión sobre las cosas que van cambiando y las que no.
¿Recordáis hace medio minuto cuando os decía que antes de desplegar ningún modelo de Machine learning mejor usar el sentido común?
Especialmente si aún no tenemos datos para entrenar ese modelo.
Bueno pues el sentido común tiene que ser sencillo.
Me explico.
Si trabajo en UberEATS y para calcular el tiempo que va a tardar un cliente en recibir su cena lo que hago es promediar lo que han tardado los últimos 10 repartos, pues el sentido común me vale.
Ahora que si promedio los resultados de la semana pasada pero además tengo en cuenta el día de la semana que es, y si es sábado tengo que multiplicar el tiempo por dos, porque claro… todo el mundo pide los sábados y además los restaurantes están a tope.
Y además, resulta que esta persona vive a más de 5 km del centro de la ciudad y entonces le añado un 25% adicional de tiempo por transporte.
Pues sí, puede que todo esto sea también sentido común y el resultado sea mejor que el de promediar el tiempo de los últimos 10 repartos.
Pero se nos ha ido de las manos.
Mantener y mejorar la lógica de este criterio va a ser un lío.
En cuanto tengamos datos suficientes, mejor probar el Machine Learning.
Así que vamos a por ello, vamos a suponer que ya tenemos datos suficientes y estamos a tope con la idea de integrar Machine Learning en el sistema.
Total… Nuestro sentido común estaba empezando a complicarse.
Antes de sacar de la chistera de los modelos de Inteligencia Artificial la red neuronal de miles de parámetros o cualquier otra cosa brillante y muy complicada pensad que cuando queremos integrar Inteligencia Artificial en un producto, al principio, el entrenamiento del modelo va a ser uno más de las decenas de quebraderos de cabeza con los que vamos a tener que lidiar.
Así que siendo buena gente con nosotros mismos, mejor empezar por un modelo de Machine Learning que no nos vaya a dar muchos problemas.
En este punto del proyecto nuestra mayor preocupación va a ser cómo hacer llegar datos al modelo. Cómo meter el modelo en nuestro sistema sin que se rompa nada y aprender a diferenciar un modelo que funciona mal de uno que funciona razonablemente bien.
Una vez que hayamos metido el modelo más simple del mundo en nuestro sistema sin romper nada, que conseguimos hacerle llegar los datos correctamente y vemos que aprende razonablemente bien podremos trabajar en un modelo mejor.
Por un lado tenemos que ser capaces de ver qué datos le están llegando al modelo cuando lo estamos entrenando.
Imaginad que estamos trabajando en Uber para predecir el tiempo que tardan en llegan los pedidos y resulta que cuando le pasamos al modelo en entrenamiento los datos, resulta que el promedio de lo que han tardado los restaurante en preparar los pedidos la última semana está mal calculado y ese valor está llegando a cero.
¡Cómo si los pedidos se entregaran instantáneamente!
Horror 😱
Es por eso, que es importante comprobar que la acnalización de datos funciona correctamente.
De la misma manera tenemos que ser capaces de ver si los resultados del modelo son parecidos en el entrenamiento y cuando lo sacamos a producción.
Muchas veces las canalizaciones que diseñamos son muy parecidas de un proyecto a otro.
Y no vamos a empezar desde el principio cada vez para hacer prácticamente lo mismo.
¡Qué ineficiente sería eso!
Normalmente tiramos del viejo copiar-pegar, lo que pasa es que si no tenemos muy claro lo que se está haciendo en esa canalización de la que estamos partiendo para nuestro proyecto o no prestamos suficiente atención podríamos cargamos alguna columna de datos que antes no necesitábamos pero ahora sí.
Esto les pasó en Google cuando estaban trabajando en el modelo de Machine Learning que seleccionaba las publicaciones que veía el usuario en Google+, la red social que tenía Google.
Un minuto de silencio por Google+ 🥲
Para hacer esa canalización habían copiado otra del modelo que seleccionaba posts en tendencia y que, por tanto desechaba las publicaciones antiguas, así que el usuario nunca veía publicaciones antiguas.
Ni en la sección de tendencias ni en la de posts recomendados.
Igual por eso, tuvieron que cerrar.
Pensad que si a nosotros nos ha servido ese parámetro que hemos calculado al principio, cuando no contábamos con Machine Learning para resolver el problema pues igual al modelo también le sirve.
Podemos usar este parámetro que calculábamos con nuestro sentido común, este heurístico, como una característica para entrenar al modelo.
Asimismo podemos entrenar al modelo con todos los parámetros que utilizábamos para calcular este mismo heurístico.
Ahora bien, de nuevo… sin enloquecer porque no queremos que la complejidad de todo el sistema se dispare.
La idea de entrenar un modelo de Machine Learning una vez y desplegarlo de por vida no aplica al mundo real.
Importante tenerlo en cuenta.
Hay que monitorizar el rendimiento del modelo de Machine Learning todo el rato y ver si se está degradando.
Igual tarda un día, igual una semana, igual varios meses… depende del caso de uso, peeero hay que tener esto monitorizado y controlado.
Creo que aquí está claro que mejor descubrir un fallo en los ensayos que en medio de la función cuando todo el público está mirando.
Así que antes de exportar el modelo, conviene hacer una última comprobación de su rendimiento sobre datos que no ha visto antes.
Imaginad que parte de los datos con los que se entrena vuestro modelo dejan de actualizarse por un fallo en el sistema.
Igual no son las características que más afectan al modelo.
Igual deja de actualizarse el tiempo que está tardando un restaurante en preparar los pedidos pero en vez de que el valor se vaya a cero pues se queda fijo en el último que capturó.
El modelo no va a ver su rendimiento caer en picado en ese instante peeeero con el tiempo igual empiezan a deteriorarse sus resultados.
Para evitar esto, es una buena opción monitorizar algunas estadísticas sobre las características que entrenan al modelo.
Esta regla es de sentido común… si las características que alimentan al modelo no están documentadas y la persona al cargo de diseñarlas y mantenerlas se va tendremos cosas que alimentan nuestra Inteligencia Artificial que ni idea de qué son.
Hemos dicho antes que no metíamos Inteligencia Artificial en un sistema porque está de moda sino porque queremos mejorar algo.
Probablemente lo que queremos mejorar las métricas que empezamos a medir en la regla número 2.
Por ejemplo, si tenemos una web, igual nos interesa optimizar el número de clics que los usuarios hacen en la web y el tiempo que permanecen en ella.
Muchas veces si aumentamos el número de clics que un usuario hace al visitar una web pues igual aumentaremos el tiempo que permanece en ella.
Para empezar nos vale y no tenemos que combinarlas métricas de maneras complejas.
Puede que el objetivo de UberEATS sea que el usuario quede satisfecho con su cena y que ahora sea un poco más feliz porque no ha tenido que cocinar.
Lo que pasa es que no es un objetivo que realmente podamos observar directamente.
Estos objetivos hay que traducirlos para intentar averiguar si nos estamos acercando a eso o no.
Por ejemplo, si el cliente ha quedado satisfecho es probable que vuelva al día siguiente.
Eso sí se puede medir.
Es posible que deje una valoración positiva de su experiencia.
Eso también se puede medir.
Los modelos de Machine Learning saben optimizar métricas que se pueden medir pero es cosa de humanos lo de traducir esos resultados al cumplimiento de los objetivos del producto o negocio.
Hay modelos grandes y complejos…
ChatGPT por ejemplo, ¿cómo podríamos interpretar por qué nos responde lo que nos responde?
Sin embargo, existen modelos más fáciles de interpretar en los que si las predicciones que obtiene el modelo comienzan a ser erróneas podríamos incluso saber de manera directa de dónde viene el problema.
Modelos de regresión, por ejemplo.
Tal vez luego, una vez que tengamos el problema más trabajado nos dé mejores resultados migrar a modelos complejos de deep learning y demás.
Pero ser capaces de interpretar el modelo que hemos elegido nos ahorrará quebraderos de cabeza en la fase de depuración de problemas.
Esta regla no aplica a todos los modelos de Machine Learning en general.
Es bastante específica del problema que tiene Google en la IA dedicada a rankear los resultados de búsqueda en Google Search.
Ya lo veíamos en el episodio 48.
Para seleccionar los resultados que aparecen en las búsquedas de Google y asegurar que es contenido de calidad hay varias características que el modelo de Machine Learning tiene en cuenta.
Bien.
Sin embargo, la gente es avispada y particularmente la que se dedica a generar spam.
De manera que pillan las cosas que hacen que Google seleccione uno u otro resultado para rankear.
Después, de manera artificial, potencian estas características en sus páginas para “engañar” en cierta manera a la IA de Google y conseguir aparecer en los primeros puestos de los resultados de búsqueda.
Aunque no sean resultados de calidad sino SPAM.
Sin embargo, no se puede penalizar al modelo de Machine Learning por hacer lo que ha sido entrenado para hacer.
Al fin y al cabo, el artículo de SPAM cumplía todos los requisitos para estar arriba en los resultados de búsqueda.
Así que además de un modelo para ordenar contenido de calidad hay que tener en cuenta otro, que seguramente tenga que entrenarse de una manera mucho más continua, que detecte webs de spam y las filtre.
Aquí tendríamos dos modelos diferentes que en cierta manera colaboran. Uno que tiene que entrenarse de manera contínua para ser capaz de detectar las prácticas de los spammers y filtrar este contenido de la búsqueda y otro capaz de rankear contenido de calidad.
Esta regla, refleja la batalla contínua de Google para que su buscador funcione.
Y ni con esas nos libramos de las páginas puerta en la mayoría de las búsquedas que hacemos en internet.
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.