E61 - Qué es MLOps... con memes

Resumen

En este episodio, Rodolfo (con Cris, Mati y comentarios del chat) presenta una charla sobre MLOps ilustrada con memes. Parte de por qué surge la disciplina: los modelos en producción fallan por cambios en los datos, múltiples usuarios, necesidad de reentrenar y de volver atrás. Explica que viene de DevOps y que busca cerrar la brecha entre desarrollo y operación, y debate sobre la falta de comunicación entre ambos mundos. Recorre el ciclo de vida de un modelo, la reproducibilidad, el uso de git y tags, CI/CD, el monitoreo (drift, calidad de datos, métricas), la escalabilidad y la eficiencia de costos, los roles de seguridad y gobierno, y la flexibilidad de herramientas. Concluye que MLOps es una necesidad vigente, que la responsabilidad del monitoreo recae por defecto en el ML engineer aunque se comparte con el Data Scientist, y recomienda git desde el inicio, evitar Jupyter Notebooks en producción, usar Quarto y definir una estructura de proyecto.

Capítulos

• 00:00
  IntroBienvenida al episodio 61, una charla con memes sobre MLOps pensada como base para otras presentaciones. Se retoma un tema ya tratado en un episodio anterior, pasando rápido por lo repetido.
• 00:44
  Qué es MLOpsSe explica que al llevar un modelo a producción los datos cambian, hay que atender a muchos usuarios, reentrenar con cuidado y poder volver atrás. Se discute si el término es "inventado" o marketing: concluyen que es un concepto legítimo derivado de DevOps y que seguía vigente antes del auge de la IA generativa.
• 04:57
  Pero funcionaba en mi máquinaEl problema típico al pasar un proyecto a otro computador: rutas absolutas en vez de relativas, ambiente virtual mal definido, código mal versionado y distintos sistemas operativos.
• 05:38
  Definición de MLOpsEs una mezcla de Machine Learning y Operations, derivada de DevOps (desarrollo + operaciones).
• 06:12
  Integración entre ML y DevOpsDevOps busca comunicar desarrollo y operación para que la transición sea rápida y sin problemas (ejemplo: desarrollo quiere publicar y operaciones pregunta en qué máquina y con cuánta RAM). Se discuten casos reales de desarrolladores que no se interesan por lo que viene después y de equipos de operaciones rígidos, y la importancia de conocer lo mínimo del trabajo del otro. Llegan comentarios del chat que confirman la experiencia y se propone invitar a alguien que gestione equipos de datos.
• 17:04
  Ciclo de vida de un modeloEl Data Scientist suele ver solo la parte de crear el modelo, pero el ciclo es más extenso (versionado de modelos, producción, etc.). Se debate que el Data Scientist hace mucho más que modelar (armar el dataset, crear variables), que los cursos asumen datos listos, y que el marketing glamoriza el modelado. Se distinguen Data Engineer, ML Engineer y MLOps Engineer.
• 26:35
  Automatización y replicabilidadSe definen repetibilidad (misma máquina), replicabilidad (otro laboratorio similar), reproducibilidad (ambiente totalmente distinto) y reusabilidad. Se discute el desacoplamiento del código respecto de la plataforma (se critica a kedro por acoplar) y que la reproducibilidad es base de la ciencia.
• 32:55
  Colaboración y comunicación a lo largo del equipoGit (con GitHub, Bitbucket, GitLab) como herramienta central de colaboración; se destacan los tags para marcar versiones estables, el miedo a romper cosas y la necesidad de tests unitarios en proyectos analíticos. Se estima que entender git bien toma cerca de un año, y se menciona `git stash` como ejemplo de uso práctico.
• 40:42
  CI/CDIntegración continua: cada cambio en el repositorio dispara tests, construcción y reentrenamiento del modelo. Se distinguen Continuous Delivery (llevar a un ambiente de staging para pruebas) y Deployment (poner en producción), y Deployment (instalar una versión) frente a Release (poner a disposición del usuario). Se responde una pregunta del chat sobre automatizar la generación de features para un modelo de detección de fraude (cron, pipeline, guardar el output en parquet/csv, coordinar con ingeniería de datos).
• 52:02
  Monitoreo y mantenimientoLos modelos se degradan con el tiempo (un ejemplo cita modelos inservibles en tres meses). Se monitorea rendimiento, costos, versiones, drift del input, calidad de datos, predicciones, métricas de negocio y métricas del modelo (F1, precisión, recall, R²). Se recomienda Great Expectations para validar el input y se debate quién es responsable: por defecto el ML engineer. También hay una digresión sobre rotación de junior y dar feedback al renunciar.
• 01:09:02
  Escalabilidad y eficienciaUn modelo debe servir a tantas personas como sea necesario; los modelos batch son más fáciles de escalar que los de tiempo real. El tamaño del docker/modelo impacta el costo al multiplicarse por muchas máquinas, y escalar mal provoca caídas, como en lanzamientos de videojuegos.
• 01:12:56
  Seguridad y gobiernoSe presentan roles posibles: expertos de negocio, Data Scientist, ML Engineer, MLOps Engineer, ML Governance y ML Architect (muchos no existen en todas las empresas). Governance asegura accesos, encriptación y políticas. Se plantea que "XOps" tiene sentido como término general de operación.
• 01:17:32
  Flexibilidad de herramientasConviene usar herramientas intercambiables y conocer una de cada tipo y cómo se conectan. Con el auge de la IA generativa el financiamiento de herramientas MLOps cayó y sobrevivirán unas pocas con buena comunidad y soporte.
• 01:19:23
  Buenas prácticasNo usar Jupyter Notebooks en producción (se hará una charla en la PyCon), usar Quarto (mezcla Markdown con código en R, Python, etc.), usar git todos los días, tener una estructura de proyecto definida, y ser cuidadoso al hacer cambios en producción y monitorearlos.
• 01:22:01
  ReferenciasLas referencias se compartirán en el Discord.
• 01:22:14
  CierreAgradecimientos, invitación a dejar dudas y sugerencias de temas en el Discord.

Palabras clave