🎙 Episodio 52. Uber, Machine Learning sobre ruedas

En el episodio de hoy de Un podcast ninja sobre Big Data hablamos sobre Uber y cómo utiliza el Machine Learning, que lo utiliza y mucho. 🚙

Uber

Uber se fundó en 2009 después de un par de malas experiencias de un tal Garrett Camp con los taxistas o con el transporte público en general.

La primera fue una nochevieja en Nueva York, que se debe de poner aquello fatal para encontrar taxi, y se tuvo que gastar $800 en un conductor privado para volver a su casa.

La segunda, al poco tiempo, cuando se fue de viaje a París. Estaba él dando una vuelta por París y se puso a nevar y no hubo manera humana de que encontrara un taxi, el pobre hombre.

Así que pensó que había que arreglar eso de alguna manera. Y nació Uber.

Al principio era una app que permitía reservar un transporte privado de lujo.

Pero con el tiempo permitieron que cualquiera pudiera ser conductor de Uber, incluso con su propio coche.

Ahora es distinto a aquellos años salvajes en los que cualquiera podía dedicarse a llevar pasajeros de un lado a otro de la ciudad en su coche particular y sacarse un dinero extra.

Hace falta licencia y todo eso.

Uber es básicamente un marketplace en el que el objetivo es juntar conductores de coches con gente que necesita ir a algún lado.

Porque aunque se dedica al negocio del transporte, Uber no tiene flota de coches.

Las otras líneas de negocio de Uber: UberEats y Uber Freights

Lo que sí tiene es un par de líneas de negocio además del transporte de viajeros que son UberEats para el reparto de comida a domicilio y Uber Freights, otro marketplace que une clientes con servicios de logística.

El principio es el mismo en las tres líneas de negocio y el Machine Learning ha sido desde hace mucho tiempo fundamental en su éxito.

Nadie quiere pedir un Uber y estar esperando media tarde a que llegue.

Nadie quiere pedir una pizza con UberEats y que llegue fría.

Cómo se usa el Machine Learning en Uber

Así que entre algunos de los casos de uso del Machine Learning en Uber están:

  • La predicción del tiempo de llegada del Uber
  • La asignación de conductores o repartidores
  • La selección de la mejor ruta
  • La detección de fraude ya que si se produce algún problema a la hora del pago de un servicio por parte de un cliente el conductor sigue cobrando y Uber asume el coste

Los inicios del Machine learning en Uber

Uber ha tenido científicos de datos en plantilla prácticamente desde el principio. Éstos se dedicaban a la creación de modelos predictivos con varias herramientas como R, scikit-learn, que es una librería de Python, modelos personalizados…

Precisamente algunas de las herramientas de las que hablábamos en el episodio de la semana pasada.

Por otro lado, tenían un equipo de ingeniería separado que se encargaba de intentar hacer funcionar esos modelos en producción.

Eran los inicios y eran equipos muy pequeñitos.

Iban trabajando un poco sobre la marcha, me lo imagino un poco así:

Llega el Data Scientist y le decía al equipo de ingeniería: “oye mira que he entrenado este modelo que predice el tiempo que va a tardar  el Uber en llegar, a ver si lo puedes desplegar”

No tenían unos flujos de trabajo establecidos con canalizaciones de datos que permitieran reproducir los resultados.

No había un sitio en el que guardaran los resultados de los distintos experimentos que hacían a la hora de entrenar los modelos para poder comparar los resultados.

Michelangelo: La plataforma de Machine Learning de Uber

 Así que en 2015 empezaron a trabajar en Michelangelo.

La plataforma de Machine Learning de Uber se encarga de estandarizar los flujos de trabajo y las herramientas de los distintos equipos para entrenar y desplegar los modelos de ML que utilizan para dar sus servicioa.

Predicción de tiempo de entrega del pedido en UberEATS con XGBoost

La app de UberEats se alimenta de los resultados de un montón de modelos de Machine learning que se entrenan en Michelangelo.

Uno para predecir el tiempo de entrega del pedido.

Uno para ordenar los resultados de los restaurantes cuando el usuario hace una búsqueda.

Uno para autocompletar la búsqueda del usuario.

Etc.

Hay varios, pero nos vamos a centrar en el de predicción del tiempo de entrega del pedido.

Cuando hacemos un pedido a UberEATS, éste llega al restaurante para que lo prepare.

El restaurante confirma el pedido y prepara la comida, lo que llevará su tiempo dependiendo de lo que haya que preparar y el lío que haya en las cocinas del restaurante en ese momento.

Cuando la comida está casi lista, se envía a un repartidor de Uber para que la recoja.

Luego, el repartidor llega al restaurante, tiene que aparcar, recoger la comida, volver a su moto o bici o lo que sea y llegar hasta el cliente,  lo que depende además de la ruta y el tráfico. 

El objetivo del modelo de Machine Learning que se entrena en Michelangelo es predecir la duración total de todo este proceso que cómo véis depende de muchos factores.

Durante años, los científicos de datos de Uber usaron la plataforma Michelangelo para entrenar modelos basados en árboles de decisión, en concreto el famoso modelo XGBoost.

Para entrenarlo utilizaban características que ya venían en la solicitud del pedido como la hora del día y la ubicación de entrega.

También usaban características históricas, como el tiempo promedio de preparación de comidas de ese restaurante de los últimos siete días.

Y características calculadas en tiempo casi real, como el tiempo promedio de preparación de comidas en ese restaurante durante la última hora.

Cuando el modelo estaba entrenado gracias a Michelangelo se desplegaba y era invocado mediante solicitudes de red a través de los microservicios de UberEATS.

De esta manera las predicciones de tiempo de entrega se muestran a los clientes de UberEATS antes de realizar un pedido y también durante el restos se fases, es decir mientras la comida se está preparando y luego en reparto.

Cada vez que revisaban el modelo basado en XGBoost para predecir el tiempo de entrega de un pedido lo entrenaban sobre un conjunto de datos más grande.

Además se trataba de un modelo con más parámetros y llegó un momento en el que se volvió un poco insostenible.

¿Y por qué? 

Pues porque ya no podían aumentar la precisión del modelo sin aumentar la latencia.

Es decir, el tiempo de respuesta que tarda el usuario en ver cuándo va a llegar su pedido.

No vale de mucho que el tiempo que predice UberEats sea exacto a la milésima de segundo si tienes que esperar 5 minutos para saberlo.

Nadie pasa 5 minutos mirando una app para saber lo que va a tardar en llegar su cena.

Nos aburrimos antes.

Así que decidieron explorar modelos de Deep Learning para sustituir al anterior basado en XGBoost.

Deep Learning en Michelangelo

El requisito era que la predicción se devolviera en pocos milisegundos y que la precisión fuera mejor que la del modelo que ya tenían.

Otro requisito para adoptar un modelo basado en deep learning en lugar de XGBoost era que se pudiera usar para las otras líneas de negocio.

La solución que desarrollaron se llama DeepETA y está basada en transformers.

Cómo funciona Michelangelo

Este flujo de trabajo es prácticamente el mismo para todos los casos de aplicación de Machine Learning en Uber.

La asignación de conductores, la selección de la mejor ruta, la detección de fraude… Todos siguen el mismo flujo de trabajo con Michelangelo.

Así que la plataforma tiene un flujo de trabajo de 6 pasos:

Gestión de datos

El primero es la gestión de los datos, que es uno de los pasos más importantes y costosos.

A partir de los datos en crudo se generan características que luego puedan ser utilizadas durante el entrenamiento del modelo.

Algunas características son directamente datos que se obtienen de la petición del usuario pero otras son calculadas. Antes hacía referencia por ejemplo al tiempo promedio que ha tardado un restaurante en servir un pedido en los últimos 7 días o en la última hora.

En Michelangelo se almacenan las características de una forma centralizada para que puedan ser utilizadas por los distintos equipos en Uber.

Cada equipo va añadiendo nuevas características que considera de valor.

Estas características son las que se utilizan para el entrenamiento del modelo, el segundo paso.

Entrenamiento del modelo

Michelangelo soporta el entrenamiento de modelos de regresión lineal y logística, de redes neuronales, modelos no supervisados, árboles de decisión y series temporales.

Incluso se añaden algoritmos desarrollados internamente por Uber.

Para el entrenamiento en la plataforma de Michelangelo únicamente tienen que indicar:

  • El tipo de modelo a entrenar
  • Una referencia a los datos de entrada y características a usar
  • Los requisitos en cuanto a potencia de cálculo como la cantidad de memoria que necesitan o si tienen que usar o no GPUs

Y el entrenamiento se lleva a cabo en un cluster.

Cuando el modelo está entrenado la plataforma devuelve un informe con las métricas de rendimiento y el modelo se guarda en un repositorio de modelos para su posterior análisis.

Si todo está correcto se despliega el modelo y ya está listo para usarse.

Validación del modelo

El Machine Learning va mucho de prueba y error por lo que normalmente no se entrena un modelo y ya a la primera tenéis algo que está listo para desplegar.

No.

Lo habitual es estar entrenando modelos continuamente, con distintas combinaciones de características, de parámetros, de algoritmos de optimización…

Las combinaciones se van al infinito y por eso antes de llegar a nuestro mejor modelo probamos muchas variantes y las evaluamos.

De hecho no es poco común tener que hacer cientos de entrenamientos antes de llegar a un modelo pasable.

Para cada modelo que se entrena en Michelangelo se almacena cierta información que ayuda a hacer seguimiento de los experimentos:

  • Quién entreno el modelo
  • Cuándo se entreno el modelo
  • La configuración completa con las características que se usaron, los valores de los hiperparámetros, etc...
  • El conjunto de datos se usó tanto para el entrenamiento como para la validación
  • Las métricas de rendimiento que obtuvo el modelo.

Con todo eso luego pueden trabajar en la configuración adecuada del modelo para obtener los mejores resultados.

El cuarto paso es el despliegue del modelo y ya el quinto es cuando se realizan las predicciones. 

Monitorización del modelo

Por último, Michelangelo soporta la monitorización del modelo una vez desplegado.

Para asegurar que un modelo sigue funcionando bien, es fundamental monitorizar sus predicciones y así garantizar que los datos que siguen fluyendo por las canalizaciones son precisos y no han cambiado.

Para ello, Michelangelo automáticamente almacena un porcentaje de predicciones y las compara con lo que realmente sucede.

Con esta información puede generar un informe de la precisión del modelo en cada momento.

Cuando la precisión se degrada con el tiempo, sabrán que es hora de volver a la fase de entrenamiento.

Y todo esto es lo que hay detrás de cada vez que pedís la cena a UberEats y os dice que llega en 45 minutos.

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.

Boletín Ninja

Suscríbete a la newsletter y recibe la guía ninja del Big Data y la Inteligencia Artificial.

Guía ninja del Big Data
Copyright © 2023  Â· Datos 🥷 · Todos los derechos reservados