El monitoreo de modelos en MLOps es la pieza que casi siempre olvidamos después de poner un modelo en producción. Aquí vas a ver cómo construir un modelo baseline que sirva como referencia para detectar data drift y decidir cuándo reentrenar tu pipeline.
La idea es sencilla pero poderosa: necesitas un punto de comparación. Sin él, no puedes saber si los datos que llegan hoy se parecen a los que entrenaron tu modelo o si ya cambiaron tanto que tu sistema quedó obsoleto.
¿Qué es un modelo baseline y por qué lo necesitas en producción?
Un modelo baseline o dummy es un modelo deliberadamente simple cuyo objetivo no es ganar precisión, sino servir de referencia para estudiar la estabilidad del sistema que ya tienes en producción.
¿Qué es un modelo dummy en MLOps? Es un modelo simple que se usa como referencia inicial para comparar el comportamiento del modelo en producción y detectar si los datos o las predicciones han cambiado con el tiempo.
El modelo en producción no siempre es una red neuronal con atención ni una arquitectura complicada. A veces un modelo simple resuelve el problema. Lo importante es que cuando los datos cambien, tengas con qué comparar.
¿Cómo preparar los datos para un análisis de data drift?
El flujo arranca leyendo el CSV procesado que ya generaron tareas previas de extracción y transformación dentro del proyecto. Una buena práctica es ejecutar describe() para ver el total de registros, etiquetas, valores únicos y la moda, y visualizar las primeras filas para confirmar la estructura.
En este caso de ticket classification aparecen tres clases con un fuerte desbalance:
- Préstamos hipotecarios: 16 376 tickets.
- Servicios de cuentas de banco: 2 358 tickets.
- Reportes de crédito o tarjetas prepagadas: 227 tickets.
Ese desbalance va a marcar todo el comportamiento del baseline. Después se separan las variables: X_test toma la columna de texto procesado y Y toma relevant_topic, que se decodifica de string a entero usando un JSON de mapeo para que el modelo pueda inferir.
¿Por qué usar TF-IDF para representar el texto?
Como trabajamos con texto, necesitamos una representación numérica. Aquí entra la frecuencia inversa de documento (TF-IDF), que asigna pesos a las palabras dándole más importancia a las más significativas dentro de cada ticket.
Se instancia el vectorizer, se aplica fit_transform sobre los datos de entrenamiento y luego transform sobre los de test. Con esa representación lista, ya puedes dividir en train y test y empezar a construir el baseline.
¿Cómo construir un DummyClassifier con estrategia constante?
El primer intento usa DummyClassifier de Scikit-learn con estrategia constant. Para alimentar esa constante, se calcula la clase mayoritaria del conjunto de entrenamiento con value_counts() sobre Y_train y se toma la etiqueta más frecuente.
Los pasos son directos:
- Crear la variable
majority_class con la etiqueta más común en train.
- Instanciar
DummyClassifier(strategy='constant', constant=majority_class).
- Hacer
fit con X_train y Y_train.
- Generar predicciones con
predict sobre X_test.
- Imprimir el
classification_report comparando reales contra predichos.
El resultado es contundente: las 5 689 muestras de prueba se clasifican como clase 2 (préstamos hipotecarios). El precision y el recall para las clases 0 y 1 quedan en cero. Y aquí viene lo interesante: ese fallo no es un bug, es exactamente lo que un dummy con estrategia constante hace cuando hay desbalance fuerte.
¿Por qué un DummyClassifier predice solo la clase mayoritaria? Porque su estrategia constante está diseñada para devolver siempre la misma etiqueta. Eso evidencia el desbalance del dataset y confirma que necesitas un baseline un poco más expresivo.
¿Cómo mejorar el baseline con Support Vector Machine?
Dado que el primer dummy no sirve como referencia útil, el segundo intento usa un Support Vector Classifier (SVC) de Scikit-learn, manteniendo la simplicidad pero con algo más de capacidad para diferenciar clases.
La configuración es mínima a propósito:
kernel='linear' para mantenerlo ligero.class_weight='balanced' para que el modelo compense el desbalance internamente.random_state=42 para reproducibilidad.
Se vuelve a vectorizar con un tfidf_vectorizer (aplicando fit_transform a train y transform a test), se hace fit con los datos representados, y luego se generan predicciones tanto sobre test como sobre train para comparar comportamientos. También se importa roc_auc_score para evaluar más allá de precision y recall.
¿Qué hacer cuando el baseline sigue fallando?
Incluso con SVM lineal y class_weight='balanced', el comportamiento puede seguir sesgado hacia la clase 2 por la magnitud del desbalance (16 376 frente a 227). Eso no significa que el ejercicio falle: significa que el baseline te está diciendo algo real sobre tus datos.
La recomendación es explorar otros modelos sencillos, ajustar parámetros mínimos y probar técnicas de balanceo o representación distintas, sin caer en la tentación de hacer el baseline tan complejo como el modelo de producción. Su valor está justamente en ser simple y estable.
¿Cómo conecta el baseline con el monitoreo y el reentrenamiento?
Una vez tienes un baseline aceptable, divides tus datos en una muestra de referencia y una muestra actual. La de referencia representa cómo lucían los datos cuando el modelo en producción funcionaba bien. La actual representa lo que está llegando hoy.
Si al comparar distribuciones detectas data drift, ejecutas acciones automáticas:
- Disparar el pipeline de reentrenamiento.
- Regenerar la representación TF-IDF con los datos nuevos.
- Volver a evaluar contra el baseline actualizado.
- Reemplazar el modelo en producción si supera el umbral definido.
Así el modelo deja de ser un artefacto estático y se convierte en un sistema vivo que reacciona cuando la realidad cambia. ¿Has implementado algo similar en tus propios pipelines? Cuéntalo en los comentarios.
