E7 - La vida de un Data Scientist - Expectativa versus realidad

Resumen

El episodio contrasta la expectativa con la realidad en la vida de un Data Scientist, usando el diagrama estándar de un proyecto de ciencia de datos (definición del problema, adquisición, preparación, modelado, visualización y comunicación, despliegue y mantenimiento). Los tres hablantes cuentan su motivación inicial (juegos, IA que juega Mario, AlphaZero) y las dificultades reales de cada etapa. Los problemas más repetidos son los encargos ambiguos tipo "aumenta las ventas", la falta de acceso y de diccionarios de datos, y datos sucios y sin documentar. Sus consejos centrales son preguntar mucho, decir que no cuando no hace falta un modelo, "ver para creer" con los datos y desconfiar de métricas demasiado buenas. También recomiendan parametrizar y ordenar el código desde la preparación de datos, mostrar avances a la contraparte de forma constante y monitorear los modelos en producción. Al final estiman el porcentaje de tiempo de cada fase, y la preparación de datos y el despliegue y mantenimiento son las que más pesan.

Capítulos

• 00:00
  IntroPresentan el tema: lo que no te cuentan en la universidad ni en las entrevistas sobre ser Data Scientist. Cuentan sus motivaciones iniciales: el juego Go y el documental sobre AlphaZero, una IA que juega Mario, videojuegos y el sueño de trabajar en Blizzard.
• 01:22
  El proceso de un proyecto de Data Science estandardEligen un diagrama típico encontrado en Google y repasan sus pasos: definición del problema, adquisición, preparación, planificación y construcción del modelo (train/test/validation), visualización y comunicación, y despliegue y mantenimiento. Proponen estimar el tiempo de cada fase en porcentajes, no en meses.
• 06:16
  Problem FramingLos clientes llegan con peticiones ambiguas ("auméntame las ventas", "haz magia"), a veces sin un problema real, y piden redes neuronales cuando bastaría una tabla dinámica en Excel o una regresión lineal. Aconsejan el "paso cero" de decidir si hace falta ciencia de datos, decir que no, apoyarse en el líder, hacer muchas preguntas y acotar el marco. Cuentan el caso de un amigo al que pidieron encontrar la "causa raíz" de fallas, con un problema mal definido. Estiman unos 5% de tiempo para esta fase.
• 29:19
  Data AdquisitionEsperan acceso inmediato y diccionario de datos, pero se encuentran con derivaciones circulares entre personas, Excel con columnas que cambian, archivos Word, equipos que esperan datos durante cinco meses y cuentas que tardan semanas. Consejos: no creerle a nadie hasta ver los datos, no dar fechas antes de verlos, pedir muestras si los datos son enormes y, si es seguro que llegarán, generar datos sintéticos para avanzar. Proponen documentar y abrir el código de ingesta. Estiman entre 5% y 15%.
• 41:59
  Data PreparationEs la fase que más tiempo consume: datos muy sucios, campos que nadie conoce, y dudas sobre cuándo imputar con la media o descartar. Recomiendan contrastar la intuición de la contraparte, doble chequear antes de refutar una hipótesis, preferir transformaciones que se puedan explicar al negocio y aprovechar el conocimiento de dominio (ejemplo del ganador de una competencia financiera). Destacan parametrizar y modularizar desde aquí, borrar código muerto confiando en el historial, y desaconsejan Jupyter para producción. Cuentan el caso de un modelo que se ejecutaba a mano durante cinco días. Reconocen que a veces el análisis exploratorio no encuentra nada y que hay que documentar esos fracasos.
• 01:04:41
  Model Planning and BuildingUnen planificación y construcción. La brecha está en el desempeño: en datos reales las métricas son mucho menores que en los ejemplos de juguete. Un AUC muy alto suele indicar data leakage (ejemplo de los NA que explicaban perfectamente la variable objetivo). Un AUC de 0,57 a 0,7 puede ser útil si mejora el proceso actual. La calidad de los datos pesa más que el tipo de modelo. Un caso de negocio con costos permite decidir si un modelo mediocre se usa o se guarda. Asignan unos 5% a cada subfase.
• 01:16:11
  Visualization and CommunicationLa expectativa de que todos aplaudirán el trabajo choca con resultados negativos o poco relevantes, que conviene comunicar pronto. Hay que conocer a la audiencia (técnica o stakeholder), confiar en el líder para depurar diapositivas y tener la versión técnica como documentación. Recomiendan libros de storytelling con datos y anécdotas de talleres poco útiles. Aconsejan no dejar pasar tres meses sin mostrar avances.
• 01:24:28
  Deploymnent and Maintenance"En mi PC corre" no basta: el Machine Learning Engineer rechaza proyectos desordenados, con rutas absolutas o sin buenas prácticas. Los problemas de infraestructura y arquitectura hacen que a veces haya que enviar resultados a mano. Una vez en producción hay que monitorear que lleguen bien los datos, el desempeño y la estabilidad de las variables, y decidir si vale la pena mantener el modelo. Asignan 35%–40% de tiempo a esta fase.
• 01:32:21
  CierreResumen de que el episodio se basa en su experiencia práctica y no en la teoría, con consejos para cada etapa. Se despiden.

Palabras clave