E34 - Cómo se ve un flujo de MLOps sano, y algunas herramientas y metodologías importantes

Resumen

Episodio de enCoders (grabado el 25/04/2023) en el que los conductores explican qué es MLOps: la combinación de Machine Learning, operaciones (DevOps) y algo de Data Engineering para llevar modelos a producción de forma fácil, escalable y automática, sin fricción entre equipos de analítica y de TI. Describen el ciclo de vida de un proyecto analítico (objetivo, datos, procesamiento, modelo, validación, piloto, monitoreo y degradación por data/concept drift) y la prueba de concepto como etapa iterativa. Recorren las piezas de un flujo "sano": bases de datos y credenciales automáticas, ambiente de desarrollo (contenedores, estructura de carpetas común), buenas prácticas (git, documentación, tests, code review), Data Quality, versionamiento de modelos, pipelines claros y CI/CD. Defienden que cualquier modelo, simple o complejo, se beneficia de MLOps. La segunda mitad incluye conversación abierta con el chat (carreras, portafolio, inglés, lenguajes) y un cierre con feature store, dashboards de seguimiento y un listado de herramientas.

Capítulos

• 00:00
  IntroPresentación del tema: MLOps, algunas herramientas útiles y cómo se vería un flujo sano; se repasa el punteo del episodio.
• 00:15
  Qué es MLOps?Mezcla de Machine Learning y operaciones, con algo de Data Engineering; busca que los modelos salgan a producción con poca fricción. Antes había equipos de analytics y de TI separados con objetivos distintos; luego los Data Scientist pasaron a productivizar. Producción implica funcionar 24/7 con servidores, RAM, CPU y bases de datos, y escalar de uno a ~30 proyectos requiere especialistas.
• 03:46
  Por qué es tan importante?Un modelo que no está en producción no da provecho; los más útiles se ejecutan constantemente. Exige servidores de respaldo, imágenes de backup y conocer mejores prácticas y herramientas.
• 06:03
  Cuál es la relación entre MLOps y DevOps?DevOps cubre integración continua, tests automáticos, release, despliegue y monitoreo; MLOps es casi lo mismo pero añade datos, reentrenamiento y versionamiento de modelos. Se usa el ejemplo de cambios de código en Twitch para justificar la automatización y un framework de trabajo estándar.
• 09:30
  Qué es un MLOpsE?Persona que asegura que el flujo completo funcione y define las herramientas.
• 09:41
  Relación entre un MLOpsE y DSs y DAsDepende de la empresa; típicamente empaqueta modelos, los pone en un servidor, controla su periodicidad y entrega de outputs. Con Data Analysts puede productivizar dashboards. Se aclara que la sesión es conceptual y basada en la experiencia diaria, no un bootcamp.
• 12:10
  El ciclo de vida de un proyecto analíticoObjetivo, obtención de datos, limpieza, modelo, test, validación, piloto con porcentaje reducido de población y despliegue gradual, y monitoreo continuo por degradación (data drift, concept drift). Se destaca la etapa iterativa de prueba de concepto y que la métrica final es el desempeño en la vida real, no el AUC en test.
• 17:23
  Tipos de herramientas y/o metodologías necesarias para un ciclo de vida sano"Sano" significa escalable, automático y con detección de errores y avisos; lo manual (reentrenar a mano con clics, copiar código a un servidor) no lo es.
• 18:57
  Bases de datosRelacionales, data lake, datos no estructurados, archivos, grafos, imágenes. Hacen falta credenciales que permitan extracción automática aunque expiren (p. ej. cada 8 horas), guardadas de forma segura con varias capas de seguridad.
• 20:18
  Ambiente de desarrolloAmbiente centralizado (p. ej. SageMaker) versus imágenes en contenedores (Docker) fáciles de distribuir y actualizar. Opinión de que un Data Scientist debe saber git y lo básico de Docker. Se discute estructura de carpetas común (convención sobre configuración, velocidad vs. flexibilidad), documentación legible y accesible, Kedro y Snakemake, formateadores (PEP 8, Black, hooks), variables de ambiente y contexto del proyecto (diccionario de datos, proceso de negocio).
• 39:27
  MemesBloque de memes: gradient descent y óptimo global, deuda técnica, caos al pasar un notebook de Jupyter a producción, dependencia de proveedores (vendor lock-in) y SAS. Se discute que se necesita MLOps con cualquier modelo (incluso regresión lineal) y que el costo escala con el número de modelos; mínimo viable: servidor de desarrollo separado del productivo, cron, logs y rollback. Crítica a los Jupyter Notebooks por guardar el contenido (salidas) dentro del archivo, lo que complica el versionamiento.
• 57:11
  Buenas práctivas de desarrolloDocumentación, git, código modularizado, buenos nombres de variables, comentarios solo cuando hacen falta, unit tests, no dejar contraseñas en el código, "modo de prueba" con pocos datos, ambientes de desarrollo similares y code review como práctica fundamental. Se menciona que el ambiente de desarrollo distinto del de producción genera caos.
• 01:01:48
  Data QualityRevisar la calidad de los datos, medir fluctuaciones de métricas relevantes y enviar alertas automáticas; es un componente nuevo de MLOps respecto de DevOps. Siguen consultas del chat sobre Front/Back end (no necesarios para un Data Scientist) y metodologías ágiles (el manifiesto ágil, scrum modificado, comunicación).
• 01:02:40
  Versionamiento de modelosAsignar un ID a cada modelo y relacionarlo con el commit de git y los hiperparámetros para saber con qué código se generó y cuál llevar a producción.
• 01:08:21
  Pipelines de ejecución clarosDiseñar el pipeline como flujo de datos: cada script con input y output (un modelo también es un dato), con checkpoints intermedios; dividir scripts largos facilita depurar y revisar en equipo.
• 01:10:21
  CI/CDIntegración continua (GitLab, Bitbucket, Jenkins, Travis, CircleCI, GitHub Actions) y entrega continua para pasar a producción de forma automática o con validación humana tras pasar los tests.
• 01:13:35
  Raid de TodoCode, conversaciones varias y resumen hasta este puntoTras un raid, conversación con el chat: presentación del podcast y del trabajo de los conductores (Entel, clases en Practicum), R vs. Python, inglés, matemáticas y estadística, bases de datos para practicar (Kaggle), Pandas vs. Polars, consejos para Juniors, carreras para ser analista/Data Scientist, la importancia de un portafolio, plataformas para practicar y rol del Machine Learning engineer. Hacia el 01:46 se resumen los temas vistos (bases de datos, ambiente, buenas prácticas, Data Quality, versionamiento, pipelines, CI/CD, rollback) y se menciona que MLOps se enfoca en producción más que en el entrenamiento.
• 01:55:25
  Feature StoreLugar donde guardar columnas o variables ya procesadas (p. ej. propensión de fuga por cliente) para reutilizarlas entre modelos; es algo pendiente de implementar en su trabajo.
• 01:57:16
  Dashboards de seguimiento de modelosMedir fluctuaciones de métricas relevantes, detectar cambios en los datos y enviar alertas para distinguir errores reales de cambios en las condiciones del entorno.
• 01:57:49
  Aplicaciones que pueden servir para cada puntoTracking de experimentos (MLflow, Kedro), versionamiento de datos (DVC), CI/CD, puesta en producción (TensorFlow Extended), monitoreo (Great Expectations), plataformas end to end (SageMaker, Kubeflow, Blue Target) y otras (Databricks, H2O). Lo importante es entender el problema antes de elegir herramienta.
• 02:01:20
  CierreAgradecimientos, recordatorio del discord y de la próxima sesión.

Palabras clave