Conversación con Pau Rué

Pau Rué es licenciado en matemáticas y doctor en física computacional por la Universitat Politècnica de Catalunya. Después de una corta etapa como investigador en la University of Cambridge (Reino Unido, 2013-2016) decidió dar el salto a la industria, primero como Data Scientist (Schibsted, 2016-2018) y luego como manager de un equipo de Machine Learning y Data Engineering (Telefónica Alpha, 2018-2019). Desde hace dos años es Director of Data en Typeform, donde ha creado desde cero los equipos de Machine Learning y Data Platform.

Empecemos con un pequeño viaje en el tiempo. En el año 2000, tuviste que tomar una decisión importante: tu carrera universitaria ¿Por qué escogiste Matemáticas? 

Opté por lo fácil. Se me daban bien y disfrutaba resolviendo problemas y acertijos matemáticos. Ya en el instituto apuntaba maneras: mi trabajo final fue crear un algoritmo basado en reglas trigonométricas para diseñar rotondas que reemplazaran cruces e intersecciones de tráfico. Desde entonces mi pasión ha sido intentar resolver problemas reales con el uso de datos y modelos matemáticos.

Y una vez acabaste tus estudios universitarios comenzaste una andadura profesional muy interesante, en la has tenido la oportunidad de trabajar en entornos de los más variopinto. ¿Cuál dirías que ha sido el aprendizaje más dulce que has tenido en todo este tiempo? ¿Y el más amargo?

Variopinto es un término que describe bien mi trayectoria. Pasé de modelizar procesos biológicos con ecuaciones diferenciales a predecir el comportamiento de usuarios en online marketplaces. Aún así, me gusta pensar que mi recorrido tiene un sentido: el intentar entender la realidad a través de los datos.

El aprendizaje más dulce y a la vez el más amargo es relativamente reciente: para llegar lejos uno no puede ir solo. Para mí es muy gratificante ver salir a la luz grandes proyectos fruto del trabajo de un equipo del que me siento responsable. A su vez, mantener a un conjunto de individuos motivados, gestionar sus expectativas, hacerlos crecer y acompañarlos en los cambios inevitables es una carga de responsabilidad que requiere darlo todo, y aún dándolo todo no siempre sale como uno se espera. 

Por tu trayectoria, has vivido de lleno la eclosión de los modelos de Machine Learning (ML). Cuando hablamos de estos modelos, el énfasis se suele poner en el trabajo de modelización que típicamente hacen los Data Scientists. Pero los dos sabemos que hace falta mucho más para que un buen modelo para que ML aporte valor a una organización ¿Cuáles son esos otros aspectos que se han de tener en cuenta?

Leía el otro día la entrevista que hiciste a Cristina Bellido donde comentaba que un buen modelo predictivo es aquel que se usa. No podría estar más de acuerdo: los modelos de ML que aportan valor son los que se usan. En este sentido, los aspectos más importantes a tener en cuenta son 

• El conocimiento del dominio del problema: por ejemplo, es difícil hacer un buen modelo de predicción de abandono de clientes sin entender el customer journey, o un modelo de detección de fraude sin saber del delito o violación en cuestión.

• El ciclo de vida del modelo: quién y cómo va a consumir los resultados, quién va hacer seguimiento del rendimiento e impacto del modelo, y cómo se va a garantizar la sostenibilidad del mismo.

• Capacidad de desarrollo y operacionalización de soluciones de ML: aunque algunas soluciones de ML son simples procesos de transformación de datos (p.e., añadir una columna de predicción en una tabla), otras son equiparables al desarrollo de features de producto (p.e., sistemas de recomendación) y es necesario tratarlas como tales desde el principio.

¿Cuáles son los dos o tres grandes errores típicos que las empresas cometen a la hora de poner en marcha proyectos de Machine Learnings

Reportes recientes sugieren que sólo entre el 10 y el 20% de los proyectos de ML salen a producción (Gartner, Venturebeat). Titular facilón pero que contiene una gran verdad: no se ha establecido aún un conjunto de buenas prácticas para ML en la industria y muchos nos encontramos en modo ensayo y error. Aún así, parece que los principales errores a la hora de poner en marcha proyectos de ML son:

• No tener una hipótesis de trabajo clara: es difícil justificar un proyecto de ML a largo plazo si uno no puede contar qué está resolviendo y qué espera de la solución aportada. Es algo obvio pero que me he encontrado frecuentemente.

• Usar ML como un martillo dorado en busca de clavos: en general los Data Scientists tienen tendencia a usar modelos avanzados a problemas sencillos. Mi sugerencia es siempre empezar por establecer un baseline con el enfoque más sencillo, que muchas veces no requiere ML.

• Arrancar un proyecto sin un plan de operacionalización. Llevo un tiempo haciendo de consultor a startups tecnológicas sobre ML y el principal problema es siempre el mismo: hay un prototipo de ML prometedor pero no hay una estrategia clara de puesta a producción. Se generan fricciones entre Data Scientists e ingenieros y el proyecto se ralentiza o muere.

Centrándonos un poco más en las personas ¿qué tipo de perfiles hacen falta para llevar a cabo proyectos de Machine Learning? Aquí te pediría que para cada rol me des tu definición y el objetivo principal que tienen

Machine Learning es un campo relativamente nuevo y no se han asentado aún roles tan definidos como en ingeniería de software (backend, front-end, SRE). Aún así, los dos roles principales son:

• Data Scientist/ML specialist: Es alguien con conocimientos técnicos en análisis de datos, modelización estadística y machine learning, y con la capacidad de entender y parametrizar un problema de negocio. 

• ML/MLOps engineer: Un ingeniero de software Backend con conocimientos del ciclo de vida de los modelos de Machine Learning, arquitectura de software y operacionalización de modelos. En algunas compañías los Data Engineers asumen este rol.

Cuando el otro día me hablaste del rol de Analytics Engineer, he de confesarte que no lo tenía muy presente. Cuando me he puesto a indagar, he visto en muchas de las conversaciones de este tipo de perfiles se habla de DBT(data build tool). ¿Podrías decirme en qué consiste un dbt? ¿En qué momento una empresa ha de invertir en este tipo de herramientas? Porque imagino que hace falta una cierta madurez en el campo del Dato

Es un rol relativamente reciente que surge gracias a la adopción de un stack de datos moderno basados en Data Lakes y Cloud Data Warehouses como Snowflake, BigQuery, o Redshift.  Estos stacks difieren de los procedimientos clásicos de ETL (extracción, transformación y carga de datos por sus siglas en inglés) para dar lugar a las ELT. En las ELT, los datos en crudo son extraídos y directamente cargados en el Data Lake/Warehouse. Así, las transformaciones se producen a demanda usando los potentes motores de procesado de datos de los data warehouses OLAP.

En este contexto aparece dbt, una herramienta que permite escribir, testear y ejecutar tareas de transformación de datos dentro del data warehouse. Dbt permite crear lógica de negocio y analytics de forma modular y reusable, usando sintaxis SQL. Es decir, permite adoptar buenas prácticas de ingeniería de software sin perder la expresividad y legibilidad de SQL. Con lo que la barrera de entrada para la transformación de datos es sustancialmente menor que antiguamente.

Así es como nace el Analytics Engineer. Un rol con conocimiento de negocio y las buenas prácticas de ingeniería que se dedica principalmente a la transformación y modelización de datos para su posterior uso por parte de Data Analysts y Data Scientists.  En la práctica, los Analytics Engineers son BI developers con una orientación más fuerte a negocio y desenvoltura en procesos de ELT.

Y ya que hablamos de herramientas, me gustaría que me contaras las principales herramientas que un equipo de Machine Learning ha de utilizar en su día a día y para qué se utilizan cada una de ellas

Para entender las herramientas necesarias es importante entender los pasos del desarrollo de productos de ML. Todo proyecto parte de la formulación del problema, seguido de la colección de datos, exploración, limpieza y etiquetado de los mismos, y finalmente su modelización. La modelización incluye experimentación con distintos modelos, y el entrenado y validación de los mismos con datos independientes. En este punto se llega al prototipo que, si cumple con las expectativas, puede llevarse a producción. La fase de puesta en producción debería tener una etapa de experimentación con datos reales (para medir impacto), el despliegue, la monitorización contínua y entrada en el ciclo de reentrenamiento. Cada una de estas etapas requiere herramientas específicas. Listo algunas:

• Para la formulación del problema y potenciales soluciones se puede usar un framework como el ML model canvas. 

• Para la modelización son imprescindibles los frameworks ML de código abierto (scikit-learn, tensorflow, pytorch, spacy, etc.), que permiten usar modelos complejos con tan solo invocar unas pocas líneas de código y despreocuparse de la implementación de los mismos. Eso permite la iteración rápida en la fase exploratoria, que es lo que en el pasado hacía inviable la apuesta por soluciones de ML.

• Para esta fase exploratoria es aconsejable usar una herramienta de computación interactiva como Jupyter, así como también un sistema de registro de experimentos y modelos como MLflow.

• También son muy útiles las herramientas de prototipado de aplicaciones como Streamlit y Gradio. Estas sirven muchas veces para hacer demos interactivas y testear internamente el modelo.

• Para la fase de operacionalización y despliegue, dependerá mucho del servicio final a ofrecer (streaming, http endpoint o batch), pero en general podemos usar la misma infraestructura de datos: un data lake para la ingesta de datos; un sistema de orquestación de flujos de trabajo como Airflow o Prefect que nos permita entrenar regularmente los modelos con datos nuevos.

• Otras herramientas deseables son un repositorio central de features(feature store, e.g., Tecton o Databricks Feature Store), que principalmente garantizan que el cálculo de features entre las fases de entrenamiento y predicción sea consistente, y que las features de un modelo estén disponibles para otros. 

Y en términos de infraestructuras y de plataformas, ¿qué recomendaciones darías para tener un entorno robusto y escalable? 

Mi consejo es invertir en crear una buena infraestructura moderna: un data lake, un cloud data warehouse moderno, un bus de procesado de datos en streaming como Kafka y un runtime environment escalable basado en Kubernetes.

Imagina que esta conversación la está leyendo alguien de una PYME. Seguramente no va a tener capacidad ni los recursos para abordar todos los temas que hemos ido planteando ¿Cuáles tendrían que ser los primeros pasos para el viaje hacia Machine Learning?

El primer paso debería ser identificar un primer caso de uso donde ML pueda aportar valor. Esto puede ir desde intentar predecir abandono de clientes a la automatización de la inspección visual de calidad de un producto. Una vez identificado ese caso, el siguiente paso es comprobar si ML puede realmente aportar valor con una pequeña prueba de concepto. Existen muchas herramientas y servicios externos que pueden ayudar a validar ese punto sin necesidad de una gran inversión. Sin ir más lejos, los principales cloud providers ofrecen potentes APIs de ML , e incluso entornos cloud de ML relativamente sencillos de usar (p.e., Amazon Sagemaker). 

En los últimos tiempos también están cobrando protagonismo los modelos de Deep Learning. ¿Cómo cambia todo lo que hemos hablado hasta ahora en esta Conversación si en lugar de Machine Learning tenemos que abordar proyectos de NLP, Reconocimiento de Imágenes, etc? 

Sin duda, la aparición de modelos Deep Learning ha supuesto toda una revolución en los últimos años. Estos modelos dan un alto rendimiento en tareas de detección y generación de patrones sobre datos no estructurados (p.e., texto, imágenes, audio o video). Además, muchos de estos modelos están disponibles ya pre-entrenados sobre grandes conjuntos de datos.

El principal reto en estos modelos es que requieren entrenar y almacenar una gran cantidad de parámetros. Hace pocos días Microsoft y Nvidia anunciaban un nuevo modelo de lenguaje natural con más de 500 mil millones (109) de parámetros y modelos de uso más extendido como BERT (2019) no bajan de los centenares de millones. El entrenamiento de estos modelos requiere hardware especializado (múltiples GPU o TPU) y en algunos casos también se requiere para la fase de inferencia. Este hecho, que en principio conlleva ser una barrera a la adopción, ha precipitado todo lo contrario: en los últimos años cada vez más compañías, como OpenAI, Clarifai o HuggingFace,  ofrecen acceso a estos modelos a través de APIs. El resultado parece ser una rápida comoditización de este tipo de modelos.

Esto cambia por completo lo comentado anteriormente: Deep Learning (DL) deja de ser una ventaja competitiva para muchas empresas pero también pone al alcance de cualquiera tecnologías como la transcripción y síntesis de voz, el reconocimiento de imágenes, o el procesado de texto. Estas son herramientas que los desarrolladores de software pueden manejar fácilmente sin necesidad de un conocimiento profundo de DL/ML.

Y si volvemos al ámbito de las personas, tú has creado y gestionado equipos de ML con perfiles muy distintos. ¿Cuál es la clave para que surja la magia y que sea un equipo de alto rendimiento? 

Crear una cultura e identidad propias en el equipo que refuercen valores como la diversidad de opiniones, la seguridad psicológica, la franqueza radical y la motivación por tener impacto. Es más fácil de decir que de hacer.

En ese sentido, también quería saber tu opinión sobre los squads / modelos cross-funcionales. Muchas empresas de desarrollo de producto apuestan por equipos mixtos con personas de Ingeniería y personas de Producto. ¿Deberían los Data Engineers y Data Scientists ser parte de estos equipos? ¿O es mejor que den servicio desde fuera del “squad”?

Mi respuesta va a decepcionar: depende. En mi opinión los equipos de datos deberían seguir los mismos principios organizacionales que los equipos de producto, ingeniería, etc. Un marco que a mi me ayuda mucho a estructurar equipos es el de Team Topologies, de Matthew Skelton y Manuel Pais. Por ejemplo, muchas veces tiene sentido tener un equipo de Plataforma de Datos cuya misión sea crear herramientas y servicios internos que permitan a otros equipos consumir datos de forma autónoma. En ese caso es importante que el modelo de plataforma esté claro porque la tendencia natural es tratar los Data Engineers como un equipo de operaciones y hundirlo a peticiones, y eso lleva a crear un cuello de botella. Por otro lado, muchos Data Scientists trabajan en resolver problemas de negocio, en ese sentido están alineados en objetivo con otras funciones (producto, marketing, ingeniería, etc.). En este caso tiene sentido que formen parte de un equipo mixto (stream-aligned según Matthew y Manuel). En este último caso el reto es que los Data Scientist formen una comunidad funcional, fomenten la polinización cruzada y no queden aislados. Eso puede lograrse fomentando ritos y actividades entre ellos en base a su función e intereses (lo que vendrían a ser los Guilds en el modelo Spotify) 

Termina esta frase. Un buen data engineer es...

Alguien que tiene siempre presente que su trabajo es habilitar a otros en el uso de datos.

¿Qué es para ti la Inteligencia Artificial? 

Yo entiendo la IA como la simulación de distintos aspectos de la inteligencia humana a través de algoritmos, datos y computadoras. Me considero pragmático y mi interés reside en la IA débil (weak AI), que consiste en resolver tareas específicas como transcripción de voz, reconocimiento facial, generación de lenguaje natural o predicción de estructura de proteínas. 

Recientemente entrevisté a Cristina Bellido (Directora de Data Analytics de VidaCaixa) y le pedí que lanzara una pregunta para la siguiente persona a entrevistar. Su pregunta fue: ¿Crees que los modelos de IA con autoaprendizaje van a ser mayoritarios en el corto plazo? ¿En qué horizonte?

Es una muy buena pregunta. En lo que refiere a soluciones de IA basadas en Machine Learning hay algunas iniciativas muy interesantes que ya son una realidad y es sólo cuestión de tiempo que los equipos de datos las vayan integrando.

Un ejemplo es MLOps, el conjunto de prácticas de despliegue y mantenimiento de modelos en producción. Estas prácticas incluyen la monitorización y re-entrenamiento automatizado de modelos para garantizar el rendimiento de los mismos. En los dos últimos años se ha dado una eclosión de soluciones comerciales de MLOps (y quizás un exceso de bombo publicitario) pero lo más importante es que estas son prácticas cada vez más equipos de datos están adoptando.

Otro ejemplo son los frameworks de AutoML, que tienen por objetivo encontrar de forma automática un modelo de ML óptimo para una tarea específica dado un conjunto de datos. La ambición de estos frameworks es acercar la práctica de ML a un público no experto. Los grandes proveedores de cloud (AWS, Google Cloud Platform) llevan ya un tiempo ofertando estos servicios y sus resultados son aceptables. El principal reto que veo es que atacan un punto muy concreto del trabajo del Data Scientist (modelización) pero no el resto (formulación del problema, adquisición y limpiado de datos, análisis exploratorio, etc.), con lo que no evitan la necesidad de un Data Scientist En este sentido creo que su adopción generalizada está aún lejos.

Y tú ¿qué pregunta le harías a la próxima persona entrevistada?

¿Qué aplicaciones de datos e IA crees que podrían hacer nuestra sociedad mejor?