Resumen
El episodio 83 de enCoders presenta las metodologías de trabajo en ciencia de datos: por qué importan, qué riesgos reducen y cómo se comparan los frameworks más conocidos (KDD, CRISP-DM y TDSP de Microsoft). Los presentadores explican que una buena metodología reduce riesgos, mejora la productividad y el conocimiento generado. A diferencia del desarrollo de software tradicional, en ciencia de datos hay mucha más iteración y ensayo y error, porque no se sabe de antemano con qué se va a encontrar uno. Se recomienda partir con CRISP-DM si no se tiene nada y luego migrar a algo más actual como TDSP, que no es cíclico y permite trabajar en paralelo, o a una metodología propia adaptada al equipo. También se tratan MLOps (automatización, versionado, testeo, monitoreo, reproducibilidad, arquitectura modular) y las metodologías ágiles, donde se critica que se enseñen como ritual más que como herramienta. La conclusión: tomar una base, adaptarla al equipo y evitar estructuras rígidas.
Capítulos
- 00:00IntroPresentación del episodio 83: metodologías de trabajo en ciencia de datos, primero las que se basan en pasos (paso 1, paso 2…) y luego su relación con las metodologías ágiles. Dejan para el final, si alcanza el tiempo, las prácticas de trabajo en equipo ya tratadas en otros streams.
- 02:13Por qué es importante tener una buena metodología de trabajo y diferencia con desarrollo de software tradicionalUna metodología ayuda a reducir riesgos, mejorar productividad y mejorar el insight generado. En desarrollo de software uno puede planificar a largo plazo; en ciencia de datos hay mucha más iteración y prueba y error, y usar las mismas metodologías lleva a problemas. Las metodologías ágiles ayudan, pero hay que ser flexible y no volverse inflexible por la herramienta.
- 04:07Algunos riesgosRiesgos de construcción del equipo (los Data Engineer son clave al inicio para tener datos estandarizados), comunicación del equipo, datos faltantes (se explica MNAR, missing not at random, con el ejemplo de un marcapasos que falla), suposiciones erróneas, errores de código y data leakage. También reproducibilidad (código que no corre al traspasarlo), sesgos de género o socioeconómicos, y la intuición de revisar la distribución de los datos contra lo esperado.
- 12:38En qué areas se enfoca el trabajoComposición del equipo, definición del proceso, ética (se mencionan corrientes como la utilitarista y la complejidad de definir "bien"), calidad de los insights, workflow de puesta en producción y monitoreo.
- 14:53Cuando no tienes ninguna metodologíaSin metodología cada persona hace lo que le parece correcto. Una metodología estándar genera una identidad del área de datos, un "sello" de cómo se hacen las cosas, que puede ser bueno (rápido) o malo (burocrático).
- 16:55KDD (década de los '90)Knowledge Discovery in Databases, con cinco etapas: selección, preprocesamiento, transformación, data mining e interpretación y evaluación. Se critica que asume que los datos existen y que no tiene etapa de entrega de un producto al cliente; es muy de laboratorio.
- 20:09CRISP-DM (1999)El más usado, aún hoy; sirve para partir si no se tiene nada. Etapas: entendimiento del negocio, entendimiento de datos, preparación, modelado, evaluación y deployment. Se discute el caso de un proyecto que murió por falta de datos útiles ("garbage in, garbage out") y qué hacer cuando hay muchos datos que el negocio no aprovecha: hacer una prueba simple de máximo un mes y "venderla" proactivamente. El modelado es un detalle frente a la preparación de datos, salvo en negocios donde el modelo es el core (ej. recomendación en Netflix).
- 37:16MemesMeme sobre trabajar con datos sucios por apuro, que luego "te persigue". Se recomienda depurar con muy pocos datos (unas 100 filas) y solo después entrenar con todo. También se comparte un caso de pipeline "automático" que en realidad dependía de clics manuales, y se recomiendan páginas de referencia (Data Science PM) y el libro "Designing Machine Learning Systems".
- 46:51TDSP (Contemporáneo, editado en marzo 2024)Team Data Science Process de Microsoft: etapas de business understanding, data acquisition y understanding, modeling, deployment y customer acceptance. No es cíclico: las fases coexisten y distintas personas pueden trabajar en paralelo. Se debate el criterio de cierre/aceptación, el costo de oportunidad de seguir refinando un modelo, y la falta de una etapa de soporte y de monitoreo con alertas y reentrenamiento con revisión humana.
- 58:42OtrosMención de SEMMA (hecho por SAS) y Domino (evolución de CRISP-DM), que los presentadores no han usado. Se indica que estos frameworks pueden combinarse con metodologías ágiles como Kanban, Scrum o Lean.
- 01:01:40MLOps, Automatización, Continuous XTodo debe quedar automatizado (continuous delivery, integration, training); el reentrenamiento debe tener un check humano. Se sugiere que el MLOps engineer devuelva el proyecto al data scientist con feedback para que lo corrija y luego lo automatice.
- 01:02:45Versionado, Experiments Tracking, TestingVersionar modelos, código y datos para lograr reproducibilidad, y hacer seguimiento de experimentos. El testeo suele quedar relegado; se sugieren validaciones simples en código (ej. mínimo de registros, nulos, distribución, clases presentes) que hagan fallar el proceso.
- 01:09:58Monitoring, Reproducibility, Loosely Coupled Architecture (Modularity), ML-based Software Delivery MetricsArquitectura modular (scripts separados de preprocesamiento, entrenamiento y evaluación) para que un cambio no afecte otras partes, evitando monolitos y parametrizando en vez de hardcodear. También se recomienda medir varias métricas del modelo a la vez.
- 01:14:04Metodologías genéricas de trabajo: Waterfall, manifiesto ágil, metodologías ágilesSe remite al episodio 16 sobre el manifiesto ágil. Critican que las consultoras enseñen la metodología como fin en sí mismo, contrario a priorizar personas sobre herramientas, y destacan la retrospectiva como la ceremonia más importante porque permite adaptar la forma de trabajar.
- 01:17:55CierreConclusión: las metodologías dan identidad y estandarización; TDSP destaca por no ser cíclico y reflejar mejor la realidad. Lo importante es tomar una base y adaptarla al equipo, evitando estructuras rígidas.