E125 - Demo: Ejecución de un modelo y pipeline multilenguaje

Resumen

En este episodio (el cuarto de la serie sobre productivización) Rodrigo muestra cómo pasar de un modelo ya entrenado a un script de ejecución que evalúa datos nuevos y entrega un resultado accionable, y luego presenta un pipeline multilenguaje (R y Python). Retoma el proyecto estructurado a partir del Jupyter Notebook de un estudiante de bootcamp: scripts con inputs y outputs que sirven de checkpoints, Docker y un parámetro de modo de prueba. La conclusión central es que un modelo sin acción posterior no sirve: hay que predecir sobre datos nuevos y entregar el resultado, conservando las columnas informativas (IDs). Recomienda un único pipeline parametrizado, con los `if` en el pipeline y no escondidos en los scripts, para no duplicar código. Defiende guardar en formatos como Feather o Parquet porque conservan los tipos y permiten pasar datos entre lenguajes. Repasa el data leakage con el ejemplo de la imputación. Cierra insistiendo en que lo importante es seguir estándares y usar la mejor herramienta para cada tarea, no una forma exacta de hacerlo.

Capítulos

• 00:00
  IntroPresenta el episodio 125, cuarto de la serie de productivización: crear el script de ejecución de un modelo ya entrenado y luego un pipeline multilenguaje.
• 00:48
  Recordatorio Estructuración del Proyecto y Uso de DockerRepasa el proyecto de un estudiante de bootcamp, convertido de un Jupyter Notebook en carpetas y scripts, con un Dockerfile y WSL para tener una terminal Linux. Cada script tiene inputs y outputs que funcionan como checkpoints: si falla el a02, no hace falta volver a ejecutar el a01.
• 02:21
  Parámetros y Modo de PruebaEl modo de prueba es un booleano que se pasa por terminal para ejecutar el código con pocos datos (por ejemplo 100 filas) y un solo modelo o un solo punto de hiperparámetros, de modo que corra en 10 segundos en vez de 2 horas. Dice que no conoce una librería que lo resuelva por completo y que además hay que imputar valores para que existan todas las clases al calcular la performance.
• 07:24
  Evaluación y validación del modeloSeñala que el proyecto solo limpiaba datos y entrenaba, sin entregar resultados a nadie. Hace falta una sección que tome el modelo y datos nuevos, genere un score (por ejemplo para préstamos, fuga o encuestas) y lo guarde o envíe. Los data scientists junior suelen pasar esto por alto, sobre todo los de perfil teórico.
• 11:44
  Discusión sobre metodologías y prácticasComentan que entregar el score no basta: entre el score y la venta o retención hay muchas capas. Rodrigo cita el modelo KDD, del 89, que no incluye producción ni uso del modelo con otros datos, y lo desaconseja por crear malas prácticas. Remite al episodio 83 sobre metodologías.
• 15:30
  Diferencia entre scripts de ejecución y entrenamiento. Importancia de un pipelineDuplicar los scripts para entrenamiento y evaluación (1 y 1') obliga a mantener dos copias y arriesga formatos inconsistentes. Propone un solo flujo con un booleano de evaluación que omita lo exclusivo del entrenamiento, como la división train/test. Prefiere dejar los `if` en el pipeline, con argumentos tipo `argparse`, y no dentro de los scripts.
• 22:10
  Dudas del chatHablan de vacaciones y responden preguntas sobre la utilidad del modo de prueba y sobre cómo buscar casos de uso de ML en una empresa (escuchar los problemas de las áreas y priorizar la factibilidad). Rodrigo dice que el modo de prueba se paga: le tomó 1 o 2 horas implementarlo y ahorra tiempo en cada iteración posterior. Un participante comenta que su ejecución demora unas dos horas sin modo de prueba. Se destaca además que el trabajo con datos es iterativo y exige validar las tablas intermedias.
• 29:22
  Discusión sobre uso de `if`s en pipelinesUn participante prefiere dos pipelines (train y eval) o scripts independientes, y le incomodan los `if` escondidos. Rodrigo defiende un solo pipeline con argumentos como `is_eval` e `is_prod`, con los `if` visibles fuera de los scripts. Se coincide en que duplicar scripts por caso produce errores al olvidar actualizar uno. Aclaran que los tests y el modo de prueba son complementarios, y que se pueden poner tests entre scripts (un tema para un episodio futuro).
• 37:30
  MemesMeme de "cuándo voy a poder correr mi Notebook en producción": un notebook se puede ejecutar, pero un proyecto necesita outputs separados (tabla, dataset, imagen) que el notebook no entrega. Rodrigo defiende que se puede productivizar en R con `Rscript` desde la terminal y mezclarlo con Python. Comentan ggplot, plotly, Shiny y Dash, la sintaxis de R y que el código nunca será perfecto.
• 44:59
  Cambios en el código de evaluación del modeloMuestra el pipeline original, sin `if`, y el uso acotado del modo de prueba para usar un singleton en vez de un grid search sobre una malla grande. Menciona que nadie del grupo conoce el framework "raza" que preguntaron en el chat.
• 46:21
  Importancia de las Columnas InformativasLas columnas que antes se descartaban (customer ID, fechas) pasan a llamarse columnas informativas o de ID, porque hay que saber a quién entregar cada score. Se guardan aparte, después de los filtros, con las mismas filas y el mismo orden que los datos del modelo.
• 47:18
  Guardado y Formatos de DatosRecomienda guardar dos tablas: IDs con el resultado y la tabla completa, porque suelen pedir columnas adicionales luego. Describe el script de evaluación: parámetros (modo de prueba, si se entrena, periodo), lectura del modelo con joblib, `predict` con clase y probabilidad, y guardado en Feather. Feather conserva tipos y es rápido, usa Apache Arrow y se lee desde R y otros lenguajes. Usa Parquet para bases grandes particionadas por mes, consultables con herramientas tipo Athena. También discuten el tipado de Python y el uso de Excel.
• 01:00:39
  Multi-Lenguaje y Preprocesamiento de DatosHace un resumen para quienes llegaron tarde: el proceso no termina al entrenar, hay que predecir y entregar a alguien que actúe. Introduce el data leakage como el filtrado de datos del futuro hacia el presente.
• 01:03:59
  Data Leakage y Evaluación de ModelosUna columna con datos de tres meses en el futuro debe eliminarse del entrenamiento y de la evaluación. Imputar nulos usando otros clientes (Random Forest, KNN) mezcla información entre train y test y es leakage; reemplazar por un valor fijo como cero no lo es. Una performance sospechosamente alta o una variable demasiado importante es una señal de alerta, y no hay un método definitivo para detectarlo.
• 01:09:09
  Ejemplo de script multilenguajeMuestra un script en R con Arrow y `read_feather` que filtra por periodo y guarda con `write_feather`. En el pipeline se llama con `Rscript` y los mismos parámetros, intercalado con scripts de Python. Prefiere R para el preprocesamiento por los pipes y las funciones de iteración por columnas (`across`), y menciona dbplyr y la ausencia de gráficos de torta en ggplot. Menciona reticulate como alternativa menos limpia que compartir archivos. Discuten rendimiento de lectura y data.table frente a pandas y polars.
• 01:17:37
  CierreRecapitula: ejecución de un modelo entrenado sobre datos nuevos, modo de prueba, parámetros, formatos y uso de varios lenguajes. Reitera que sí se puede productivizar en R, que lo importante es seguir estándares (pipelines de desarrollo y producción parametrizables) y que el repositorio irá en la descripción y en Discord.

Palabras clave