Glosario de MLOps

Los términos que aparecen una y otra vez en el Curso de MLOps y en cualquier conversación sobre llevar modelos de machine learning a producción y mantenerlos vivos. Como todo glosario de la academia, crece con cada bloque nuevo del curso.

Ciclo de vida y reproducibilidad

MLOps — el conjunto de prácticas para llevar modelos de ML a producción y mantenerlos funcionando: automatizar el entrenamiento, el despliegue y el monitoreo. Es DevOps aplicado a machine learning, sumándole que aquí también cambian los datos, no solo el código.

Ciclo de vida de ML (ML lifecycle) — el recorrido completo de un modelo: datos, entrenamiento, evaluación, despliegue, monitoreo y reentrenamiento. A diferencia del software clásico, no termina al desplegar: un modelo se degrada solo con el tiempo y hay que volver a empezar el ciclo.

Reproducibilidad — poder volver a obtener exactamente el mismo modelo a partir del mismo código, datos y configuración. La base de todo MLOps: si no puedes reproducir un resultado, no puedes depurarlo ni confiar en él.

DVC (Data Version Control) — herramienta que versiona datasets y modelos como Git versiona código: guarda los archivos grandes aparte y en el repo solo queda un puntero liviano. Permite hacer checkout de la versión exacta de datos con la que se entrenó un modelo.

Versionado de datos — llevar registro de qué versión de los datos se usó en cada experimento. Sin esto, un modelo entrenado con un dataset viejo es imposible de reproducir aunque tengas el código intacto.

Seed — el número que fija el azar (mezclas, inicialización de pesos, splits). Fijar la seed es lo que hace que dos corridas del mismo código den el mismo resultado; olvidarla es la causa más común de “me daba otra métrica ayer”.

Experimentos y modelos

Experiment tracking — registrar automáticamente cada corrida de entrenamiento: qué configuración usaste, qué datos y qué resultados diste. Reemplaza la planilla Excel y los nombres de archivo tipo modelo_final_v3_bueno.pkl.

MLflow — la plataforma open source más usada para tracking de experimentos y model registry. Registra runs, guarda artefactos y sirve de catálogo central de modelos. La herramienta base del curso.

Weights & Biases (W&B) — plataforma comercial de experiment tracking con dashboards muy pulidos y colaboración en equipo. La alternativa popular a MLflow cuando quieres visualización lista para usar.

Run — una ejecución individual de entrenamiento con su configuración y resultados. Cada vez que entrenas queda un run registrado; comparar runs es como eliges el mejor modelo.

Params / métricas / artefactos — las tres cosas que registra un run. Los params son la configuración de entrada (learning rate, épocas); las métricas son los resultados (accuracy, F1); los artefactos son los archivos que salen (el modelo, gráficos, el dataset).

Model registry — el catálogo central de modelos entrenados: cada modelo con su versión, su stage y su historial. La fuente única de verdad sobre “qué modelo está en producción ahora mismo”.

Versión de modelo — cada iteración registrada de un modelo en el registry (v1, v2, v3). Permite saber exactamente qué se desplegó y volver atrás si algo sale mal.

Alias / stage — el puntero que dice en qué punto del ciclo está una versión dentro del registry. En MLflow actual son aliases (champion = la que sirve de verdad, challenger = la candidata en prueba) más tags; los stages clásicos (staging / production / archived) quedaron obsoletos desde la 2.9. Mover champion a otra versión es el gesto de “esto ya está listo”.

Linaje (lineage) — la cadena que conecta un modelo con los datos, el código y la configuración exactos que lo produjeron. Responde la pregunta de auditoría “¿de dónde salió este modelo?”.

Rollback de modelo — volver a una versión anterior del modelo cuando la nueva falla en producción. Gracias al registry es tan simple como re-apuntar el alias champion a la versión previa, sin reentrenar nada.

Pipelines y features

Pipeline de entrenamiento — la secuencia automatizada de pasos que va de los datos crudos al modelo entrenado y validado: ingesta, validación, features, entrenamiento, evaluación. Convierte un notebook manual en algo que corre solo y repetible.

Orquestador — la herramienta que ejecuta los pasos del pipeline en orden, maneja dependencias, reintentos y horarios. Es el “director de orquesta” que decide qué corre, cuándo y qué hacer si algo falla.

DAG (Directed Acyclic Graph) — la forma de representar un pipeline: un grafo de tareas con flechas de dependencia y sin ciclos. Cada nodo es un paso y las flechas dicen qué debe terminar antes de qué.

Airflow — el orquestador open source más veterano y extendido. Defines los DAGs en Python; potente y flexible, aunque pesado de operar. El estándar de facto en muchas empresas.

Prefect — orquestador moderno pensado como alternativa más liviana y “pythónica” a Airflow. Menos ceremonia para armar y correr pipelines de datos y ML.

Kubeflow — plataforma de MLOps sobre Kubernetes: pipelines, entrenamiento y serving en un mismo ecosistema. Poderoso pero exige saber Kubernetes; apunta a equipos grandes.

Vertex AI Pipelines — el servicio gestionado de Google Cloud para correr pipelines de ML sin administrar la infraestructura. La opción “todo incluido” si ya vives en GCP.

Feature store — el repositorio central de features (las variables que alimentan al modelo), calculadas una vez y reutilizadas en entrenamiento y en producción. Su gran promesa es evitar que cada equipo recalcule lo mismo de forma distinta.

Feast — el feature store open source más conocido. Orquesta las features entre su versión offline (para entrenar) y online (para servir), manteniéndolas consistentes.

Feature offline / online — las dos caras de una feature. La offline vive en el data warehouse y sirve para entrenar con histórico; la online vive en una base rápida y sirve para responder en producción en milisegundos. Que ambas se calculen igual es clave.

Train-serve skew — la diferencia entre cómo se calcula una feature al entrenar y cómo se calcula al servir. Es el bug silencioso número uno de MLOps: el modelo se ve bien en las pruebas y falla en producción porque recibe datos calculados distinto.

CI/CD/CT y serving

CI/CD (Integración y Entrega Continuas) — las prácticas de DevOps para probar y desplegar código automáticamente en cada cambio. En ML se aplican al código del pipeline, pero no bastan: también cambian los datos y el modelo.

CT (Continuous Training) — la pieza que MLOps agrega a CI/CD: reentrenar el modelo de forma automática cuando llegan datos nuevos o cuando el rendimiento baja. Es lo que distingue una plataforma de ML madura de un simple despliegue de código.

Validación de datos — chequear automáticamente que los datos que entran cumplen lo esperado (rangos, tipos, nulos, distribución) antes de entrenar o predecir. Frena la basura en la puerta en vez de descubrirla en la métrica.

Validación de modelo — la compuerta que decide si un modelo recién entrenado merece desplegarse: se compara contra el que está en producción y contra umbrales mínimos. Si no mejora o empeora, no pasa.

Great Expectations — librería open source para validación de datos: defines “expectativas” (esta columna nunca es nula, este valor está entre 0 y 100) y genera un reporte de qué se cumplió. El chequeo de calidad de datos automatizado.

pandera — librería liviana de validación de datos para DataFrames: defines el contrato como código (pa.Column, pa.Check) y validate(lazy=True) junta todos los errores de una vez en vez de morir en el primero. La opción del curso para el contrato de datos en CI.

Serving — poner el modelo a responder predicciones a quien las pida. Es el paso de “tengo un archivo con un modelo” a “tengo un servicio que otros pueden usar”.

Batch — servir predicciones por lotes: procesas miles de casos de una vez, en un horario, y guardas los resultados. Ideal cuando no necesitas respuesta al instante (por ejemplo, un scoring nocturno).

Online / real-time — servir predicciones una a una y al momento, respondiendo a cada petición en milisegundos. Lo que necesita una app que reacciona al usuario en vivo.

Endpoint — la dirección (una URL/API) donde vive el modelo servido y a la que se le mandan datos para recibir la predicción. La cara pública del modelo en producción.

BentoML — framework open source para empaquetar un modelo como servicio listo para desplegar: le pones una API, lo metes en un contenedor y queda servible. Simplifica el salto de modelo a endpoint.

Seldon — plataforma de serving sobre Kubernetes orientada a producción: escalado, versiones y despliegues avanzados como canary y shadow. Para cuando el serving se pone serio.

KServe — el estándar de serving de modelos sobre Kubernetes (antes KFServing). Ofrece endpoints escalables, escala a cero y despliegues progresivos de forma nativa.

Monitoreo y drift

Monitoreo de modelos — vigilar en producción que el modelo siga sano: calidad de las predicciones, latencia y, sobre todo, si los datos que llegan cambiaron. Un modelo sin monitoreo se degrada en silencio hasta que alguien reclama.

Ground truth — el resultado real que se quería predecir, conocido después. Comparar la predicción contra el ground truth es la única forma directa de medir si el modelo sigue acertando; el problema es que a veces llega tarde o nunca.

Evidently — librería open source para monitoreo de modelos y detección de drift: genera reportes visuales y en JSON comparando los datos de producción contra los de entrenamiento. La API actual (from evidently import Report) es la default desde la 0.7 (2025). La herramienta práctica del bloque de monitoreo.

Data drift — cuando los datos de entrada en producción cambian su distribución respecto a los de entrenamiento (llegan clientes de otra edad, otro país, otra temporada). El modelo sigue igual, pero el mundo que ve ya no es el mismo.

Concept drift — cuando cambia la relación misma entre las entradas y lo que hay que predecir: los mismos datos ahora significan otra cosa (un patrón de fraude que antes no lo era). Más traicionero que el data drift porque los datos “se ven normales”.

PSI (Population Stability Index) — métrica que resume cuánto se movió la distribución de una variable entre entrenamiento y producción. Por convención: bajo 0.1 estable, 0.1–0.25 alerta, sobre 0.25 drift claro. El semáforo estándar del data drift.

Test KS (Kolmogorov-Smirnov) — prueba estadística que mide si dos muestras vienen de la misma distribución. Se usa para detectar drift en variables numéricas: si el test dice que ya no son iguales, algo cambió.

Reentrenamiento y gobernanza

Reentrenamiento — volver a entrenar el modelo con datos frescos para recuperar el rendimiento que el drift le fue quitando. El cierre del ciclo de vida: no arreglas el modelo viejo, produces uno nuevo con la realidad actual.

Trigger — la condición que dispara un reentrenamiento automático: puede ser por calendario (cada semana), por volumen de datos nuevos o por una alerta de drift. Es lo que convierte el CT en algo que reacciona solo.

Champion / challenger — el patrón para reemplazar modelos con seguridad: el champion es el que está en producción; el challenger es el candidato que compite contra él con datos reales antes de destronarlo. Solo gana si demuestra ser mejor.

Shadow deployment — desplegar un modelo nuevo en paralelo que recibe el tráfico real y predice, pero cuyas respuestas no se usan. Sirve para verlo actuar sin riesgo antes de darle el control.

Canary — soltar el modelo nuevo a un porcentaje pequeño del tráfico (un 5%) y subirlo de a poco si todo va bien. Limita el daño de un modelo malo a una fracción de los usuarios.

Model governance — el conjunto de reglas, permisos y registros que aseguran que los modelos en producción son auditables, aprobados y responsables. Cobra sentido cuando un modelo toma decisiones que afectan personas o dinero.

Model card — la ficha técnica de un modelo: para qué sirve, con qué datos se entrenó, qué tan bien funciona, sus límites y sus sesgos conocidos. La documentación mínima para usarlo con responsabilidad.

Fairness — que el modelo no discrimine sistemáticamente contra ciertos grupos (por género, edad, origen). Parte de la gobernanza: un modelo puede tener buena accuracy global y aun así ser injusto con una minoría.

Niveles de madurez MLOps (Google 0/1/2) — la escala de referencia de Google para ubicar dónde está un equipo. Nivel 0: todo manual, del notebook al despliegue a mano. Nivel 1: pipeline de entrenamiento automatizado con reentrenamiento continuo (CT). Nivel 2: CI/CD del pipeline mismo, donde hasta los cambios de código del pipeline se prueban y despliegan solos. El mapa para saber cuál es tu próximo paso.

Material relacionado

• ¿Qué es MLOps? — el bloque que abre el curso y define el ciclo de vida.
• Gobernanza y madurez — el cierre: cómo hacer el ML auditable y cómo medir tu nivel.