MLOps es DevOps para modelos
Un sistema de ML es un modelo más pipelines de datos, evaluación, despliegue y monitorización. MLOps es la disciplina que mantiene todo el conjunto correcto a lo largo del tiempo. Los modelos se degradan silenciosamente — sin stack trace, sin crash, solo respuestas cada vez más erróneas — así que la barra operacional es más alta que para el software ordinario.
Tracking de experimentos
Cada corrida de entrenamiento necesita registrar sus parámetros, versión de código, dataset, métricas y artefactos. Sin tracking, “¿qué corrida produjo el modelo en producción?” no tiene respuesta. Una corrida es una tupla: (commit de datos, commit de código, hiperparámetros, semilla) → (métricas, artefacto del modelo). Regístralo todo; la reproducibilidad es el cimiento de la ingeniería de ML.
Pipelines de datos y el data leak
Los modelos son consumidores downstream de datos. Si el pipeline cambia el significado de una feature entre entrenamiento y serving — mismo nombre de columna, distinta definición — el modelo se rompe silenciosamente. Reglas:
- Versiona tus datasets como código.
- Valida esquema y distribuciones en cada corrida del pipeline.
- Nunca entrenes con datos del futuro (features calculadas con la etiqueta, o con datos que no existirían en tiempo de predicción).
Evaluación offline
Antes de enviar a producción, mide el modelo candidato contra el modelo de producción sobre un conjunto de test congelado:
| Comprobación | Pregunta que responde |
|---|---|
| Mejora de métrica | ¿Es mejor en la métrica elegida? |
| Desglose por segmento | ¿Hay algún segmento de usuarios que empeora? |
| Análisis por slices | ¿Es justo entre grupos? |
| Plan de A/B | ¿Qué mediremos en producción? |
La evaluación también debe estresar al modelo en casos adversariales y de borde, no solo en el camino feliz.
El registro de modelos
Un registro almacena cada modelo candidato con sus metadatos y un flujo de promoción: candidato → validado → staged → producción. El rollback es una operación del registro: apuntar producción de vuelta al modelo anterior. Nunca copies archivos del modelo a mano; siempre pasa por el registro.
Drift y reentrenamiento
Los modelos se degradan a medida que la realidad cambia:
- Data drift — los inputs cambian (nuevos productos, nuevas palabras, estacionalidad).
- Concept drift — la relación entre inputs y etiquetas cambia.
Monitoriza las distribuciones de input y la calidad de predicción en producción. Cuando el drift cruza un umbral, reentrena y reevalúa. La cadencia de reentrenamiento es una decisión de producto: demasiado frecuente desperdicia cómputo, demasiado rara degrada la calidad.
CI/CD para ML
Los pipelines de modelos también llevan CI/CD:
- CI — lint y test del código del pipeline; ejecuta validación de datos; entrena un modelo smoke pequeño.
- CD — en el merge, reentrena, evalúa contra el modelo en producción y haz gate por la evaluación.
- Deploy — promueve a través del registro con rollback automático ante regresión de métricas.
El modelo, no el código, es el artefacto desplegable — por eso los gates de evaluación reemplazan a los tests unitarios como barra de release.
Guardarraíles en producción
Incluso con RAG y fine-tuning, las salidas de LLM necesitan guardarraíles en runtime: chequeos de input (prompt injection, PII), chequeos de output (violaciones de política, contenido dañino) y restricciones de dominio permitido. Loguea inputs y outputs para auditoría. Los guardarraíles son una capa separada y testeable — no un deseo en el prompt.
Trayectoria de práctica
- Lista cada artefacto que una corrida de entrenamiento debe registrar para ser reproducible.
- Describe un escenario de data leak que destruiría silenciosamente la accuracy.
- Dibuja un flujo de promoción y rollback usando un registro de modelos.
- Define data drift vs concept drift con un ejemplo de cada uno.
- Diseña una capa de guardarraíles para un chatbot LLM orientado a cliente.