E115 - Demo: Modularización y guardado de outputs

Resumen

En este episodio, Rodo continúa la serie sobre cómo llevar un Jupyter Notebook ajeno a un proyecto estructurado y productivo. Se repasa la evolución del repositorio mediante tags de git: paso de Jupyter a Quarto, ambientes virtuales, reestructuración en carpetas, separación del EDA y del preproceso en archivos modulares, y un archivo `pipeline` que los conecta. Se defiende trabajar con scripts ejecutados de forma interactiva (por ejemplo, en Positron) en lugar de notebooks, y guardar los outputs importantes (modelos, gráficos en PDF, datasets intermedios) con IDs de archivo. También se tratan argparse, parámetros globales, `logging` frente a `print` y un problema al graficar desde terminal, resuelto con el motor `Agg`. Hay una sección de memes y una discusión sobre usar LLMs sin entender el código. Las conclusiones: todo el desarrollo puede hacerse solo con código, commits ordenados e iteración interactiva, y lo importante hay que guardarlo.

Capítulos

• 00:00
  IntroPresentación de la segunda parte de la serie: modularizar el código, guardar outputs y explorar de forma iterativa pensando en el producto final.
• 00:39
  Contexto general y trabajo anteriorEl repositorio es público y su evolución está marcada con tags de git como hitos. El punto de partida es un Jupyter Notebook de otra persona que se quiere dejar listo para producción.
• 01:53
  Repaso sobre por qué no usar Jupyter NotebookHay que pensar desde el comienzo qué se hará con el modelo (evaluar clientes, extraer un CSV, subirlo a una página o a la nube). Por eso Rodo prefiere trabajar con scripts adaptados a la necesidad.
• 03:22
  Transformación de Jupyter Notebook a QuartoSe limpió código y se pasó a un archivo Quarto, que es código plano y no esconde metadatos como el notebook. Se puede usar con R, Python y otros lenguajes, y se abre con Ctrl+Shift+F4 en el IDE.
• 04:16
  Ambientes virtualesSe muestra cómo seleccionar el intérprete y crear un ambiente virtual desde la paleta de comandos, con un archivo de requirements. Los ambientes aíslan las versiones de librerías y hacen reproducible el proyecto. Se menciona Docker para otro episodio.
• 06:48
  Reestructuración del proyectoSe agregan carpetas (model, pipelines, preprocessing y files con datasets de input, intermedios y output). Lo que no es código se ignora en git, manteniendo solo la estructura (por ejemplo, con `.gitkeep`). Rodo no ve sentido en la carpeta `source` típica de Cookiecutter.
• 09:33
  README y Canvas AnalyticsConviene documentar en el README los pasos para activar el ambiente, instalar requirements y ejecutar el proyecto, y también el objetivo y los enlaces útiles. Ayuda a retomar el proyecto tras un tiempo.
• 10:18
  Separación del EDA del pipeline generalEl monolito inicial se separó en EDA y preproceso. El EDA exploratorio se borra si no se va a reutilizar, ya que git permite recuperarlo, y se conserva solo si se convierte en un reporte (por ejemplo, un HTML) como producto.
• 14:12
  Cómo ejecutar de forma interactiva y algunas herramientas de PositronSe ejecutan líneas o bloques desde el script con Ctrl+Enter, y Ctrl+Shift+Home selecciona desde el inicio hasta la línea actual. Positron incluye un explorador de datos comparable a Data Wrangler de VS Code.
• 18:06
  Separación del preproceso en distintos archivos y por qué es útilDividir el preproceso permite aplicar de forma idéntica los pasos comunes a entrenamiento y evaluación, y mejorar secciones sin romper el resto. El costo es más archivos en disco, que puede pesar con datos muy grandes. Se menciona el guardado particionado con Parquet y PyArrow para filtrar y leer en paralelo.
• 23:10
  Importancia de respaldar la historia del desarrolloLos mensajes de commit y los tags explican las decisiones, y los comentarios con `!` advierten, por ejemplo, que un reemplazo no introduce data leakage. Las fechas de commit muestran cuándo y cómo se desarrolló. La conversación deriva a las horas de sueño de Rodo.
• 30:10
  MemesPausa de memes con chistes sobre exigencias de consultoras (real-time data), issues de GitHub abiertos hace años, leer la documentación y los errores, y "haz el maldito preproceso". Se aconseja usar LLMs para buscar ideas con cautela. Hay debate sobre modo oscuro y sobre eliminar o imputar datos faltantes (depende del contexto).
• 40:10
  Noticias de PositronPositron permite activar atajos de RStudio en los settings. Por detrás usa Ark, una librería intermediaria que ejecuta consultas. Rodo lo usa desde hace unos 5 meses, alterna con RStudio y VS Code, y tuvo problemas con git en Windows. Se comparan los IDEs con asistencia LLM (Cursor) y el costo frente al tiempo.
• 50:39
  Modificación de OHE originalEl One Hot Encoding estaba hecho en dos lugares (ColumnTransformer y OneHotEncoder aparte), y Rodo lo ordenó. Se deja SMOTE por ahora, pero se comenta un artículo sobre por qué no usarlo.
• 52:24
  PipelineEl archivo `pipeline` llama en orden a todos los scripts, con IDs únicos de archivo (a01, b01, etc.) que facilitan buscarlos con Ctrl+P y rastrear de dónde salió cada output. En el chat se discute que SMOTE no sirve bien para variables categóricas.
• 56:07
  Opiniones sobre usar LLMs sin entenderPasarle el dataset a un LLM está bien para tareas simples o un primer borrador, pero hay que entender lo que se obtiene, porque los LLM alucinan. Se comenta la cifra de que cerca del 25 % del código de Google lo genera IA, que quizá cuenta el autocompletado.
• 01:02:25
  Argparse para enviar comandos desde la terminalEl pipeline recibe argumentos por terminal, por ejemplo el periodo. Podría automatizarse con la fecha actual.
• 01:03:42
  Parámetros globalesUn archivo `params` simple define cosas como la plataforma (para decidir entre `python.exe` o `python`) y un periodo por defecto. Es una forma sencilla entre muchas posibles.
• 01:05:00
  Uso de logging versus printSe usa la librería `logging` para guardar en un archivo con timestamp lo que antes se imprimía, y se recomienda `print` al inicio y pasar a `logging.info` cuando la idea está madura. Un reemplazo global convierte entre ambos. El log sirvió para depurar un error donde el print no mostraba nada, y se señala que imprimir en terminal ralentiza el código.
• 01:14:10
  Problema con figure desde terminal y uso de engine AggAl ejecutar desde `os.system`, la figura bloqueaba el código porque no había acceso al motor gráfico. Con logs se localizó la línea y se resolvió usando el backend `Agg` de matplotlib si el entorno no es interactivo. Además, el modelo se redujo a una sola versión (XGBoost), se debate el uso de ramas en git y se explica por qué guardar la curva ROC en PDF.
• 01:32:48
  CierreLos mensajes finales: se puede desarrollar todo solo con código, commits ordenados e iteración interactiva, y hay que guardar los outputs importantes. Se anuncia una entrevista con el profesor John Atkinson sobre LLMs.

Palabras clave