Bienvenido al Curso de MLOps. La meta del curso completo es una sola: tomar ese modelo de Machine Learning que entrenaste en un notebook y operarlo en producción manteniéndolo vivo — que siga acertando semana tras semana, aunque el mundo cambie. Para eso recorreremos todo el ciclo: versionar datos y código para poder reproducir, experiment tracking (registrar qué probaste), model registry (cuál modelo es el oficial), pipelines de entrenamiento, serving (servirlo como API), monitoreo, drift (cuando los datos se desvían), reentrenamiento y gobernanza. Si vienes de Del notebook a producción, este curso retoma justo donde quedó ese puente. Y si estás pensando en el Curso de Deploy de Agentes: son complementarios pero distintos, y aclarar esa diferencia es lo primero que hace este módulo.

La tesis del módulo

El software tradicional es determinista: le das el mismo input y te da el mismo output para siempre. Un modelo de ML depende de DATOS que cambian, así que se degrada solo aunque nadie toque una línea de código. MLOps es toda la ingeniería que existe para reproducir, desplegar y vigilar ese modelo antes de que se pudra en silencio.

El problema: los modelos mueren en el notebook

La mayoría de los modelos de ML nunca llega a nadie. Se quedan en una celda de Jupyter que corrió una vez, con un accuracy bonito, y ahí terminan. Los que sí llegan a producción enfrentan un destino peor: se degradan en silencio. Nadie tocó el código, pero el modelo que hace seis meses acertaba el 92% hoy acierta el 74%, y nadie se dio cuenta hasta que un cliente reclamó.

MLOps (Machine Learning Operations, las operaciones para llevar y mantener modelos de ML en producción) es la disciplina que ataca esas dos muertes: la del notebook que nunca se despliega, y la del modelo desplegado que se pudre sin avisar.

MLOps no es LLMOps: la diferencia con Deploy de Agentes

Antes de seguir, una aclaración que evita confusiones durante todo el curso. Existe un curso hermano, el de Deploy de Agentes, y suena parecido pero apunta a otra cosa:

El Curso de Deploy de Agentes es LLMOps: desplegar aplicaciones de agentes que llaman a un LLM ya entrenado por otro. Ahí el modelo es una caja cerrada que consumes por API; tu trabajo es la app alrededor — tools, reintentos, costo, observabilidad.
Este Curso de MLOps es el ciclo de vida de un MODELO de ML que tú entrenas: los datos con que se entrena, cómo se versiona, cómo se registra, cómo se sirve y cómo se reentrena cuando se degrada.

Dicho corto: en LLMOps operas una app que usa un modelo ajeno; en MLOps operas el modelo mismo, desde sus datos hasta su jubilación.

ML vs software tradicional: la diferencia central

Esta es la idea que hace que MLOps exista como disciplina aparte de DevOps. El software tradicional es determinista: escribes una función que suma dos números y sumará esos números igual hoy, mañana y en diez años. Su comportamiento vive en el código, y el código no cambia solo.

Un modelo de ML es distinto. Su comportamiento no vive solo en el código, sino en los datos con que se entrenó. Y los datos del mundo real cambian: cambian los clientes, cambian los precios, cambia el fraude, cambia la moda. El código del modelo queda idéntico, pero el mundo que describía ya no existe. Resultado: el modelo se degrada solo, sin que nadie lo edite. A esto se le llama informalmente que el modelo “envejece”.

	Software tradicional	Modelo de ML
Comportamiento vive en	El código	El código y los datos de entrenamiento
Es determinista	Sí: mismo input, mismo output	No: es probabilístico
Se degrada solo	No: si nadie lo toca, sigue igual	Sí: el mundo cambia y el modelo no
Se prueba con	Tests (pasa / falla)	Métricas (accuracy, F1) sobre datos
Para reproducir necesitas	El código	Código + datos + entorno + seed
El bug clásico	Una excepción, un crash	Predicciones malas sin error visible

Ojo: el fallo más peligroso de un modelo no lanza una excepción. El sistema responde con total normalidad — solo que sus predicciones ya no sirven. Por eso el monitoreo (módulo 9) no es opcional: es la única forma de ver una degradación que no tira ningún error.

El ciclo de vida de ML: un loop cerrado

Todo el curso se ordena alrededor de una idea: el ciclo de vida de un modelo no es una línea recta que termina en el deploy, es un loop que se cierra. Entrenas, evalúas, registras, despliegas, monitoreas… y ese monitoreo dispara un nuevo entrenamiento. Un modelo vivo da vueltas por este ciclo una y otra vez.

         ┌────────────────────────────┐
         │                            │
         ▼                            │
    ┌──────────┐                      │
    │  DATOS   │                      │
    └────┬─────┘                      │
         ▼                            │
    ┌──────────┐                      │
    │ FEATURES │                      │
    └────┬─────┘                      │
         ▼                            │
    ┌──────────┐                      │
    │ ENTRENAR │                      │
    └────┬─────┘                      │
         ▼                            │
    ┌──────────┐                      │
    │ EVALUAR  │                      │
    └────┬─────┘                      │
         ▼                            │
    ┌──────────┐                      │
    │ REGISTRAR│                      │
    └────┬─────┘                      │
         ▼                            │
    ┌──────────┐                      │
    │ DESPLEGAR│                      │
    └────┬─────┘                      │
         ▼          se degrada        │
    ┌──────────┐    reentrenar        │
    │MONITOREAR├──────────────────────┘
    └──────────┘

Cada etapa de ese loop es uno o varios módulos del curso. Features son las variables de entrada que el modelo usa para decidir (por ejemplo, edad e ingreso de un cliente). Registrar es guardar el modelo entrenado como una versión oficial. La flecha de vuelta — de monitorear a datos — es el corazón de MLOps: es lo que separa un modelo vivo de uno abandonado.

MLOps vs DevOps vs LLMOps

MLOps hereda mucho de DevOps (la cultura y herramientas para desplegar software de forma continua y confiable). De hecho, buena parte del pipeline es idéntica, y por eso el módulo de rollout se apoya en lo que ya viste en Rollout y confiabilidad. Pero MLOps agrega dos ejes que DevOps no tiene: los datos y la degradación.

	DevOps	MLOps	LLMOps
Qué operas	Software determinista	Modelo de ML que entrenas	App de agente sobre un LLM ajeno
Qué versionas	Código	Código + datos + modelo	Prompts + código de la app
Se degrada solo	No	Sí (drift de datos)	El modelo base no; la app sí puede
Prueba de calidad	Tests unitarios	Tests + métricas sobre datos	Evals de respuestas
El ciclo se cierra por	Bugs / features nuevas	Degradación → reentrenar	Cambios de prompt / de datos
Curso	(base común)	Este	Deploy de Agentes

La fila que manda es “se degrada solo”: es la razón de que MLOps necesite monitoreo y reentrenamiento como ciudadanos de primera clase, cosa que un pipeline de DevOps puro no contempla.

Errores comunes

Creer que el proyecto termina en el deploy. El deploy es la mitad del trabajo. Un modelo en producción sin monitoreo es una bomba de tiempo que se degrada sin avisar.
Tratar un modelo como si fuera software determinista. Un test que pasa no garantiza que el modelo acierta: hay que medir métricas sobre datos reales, y volver a medirlas seguido.
Confundir MLOps con LLMOps. Consumir un LLM por API (Deploy de Agentes) no es lo mismo que operar el ciclo de vida de un modelo que tú entrenas. Distintos problemas, distintas herramientas.
Versionar solo el código. Sin versionar los datos y el entorno, no puedes reproducir el modelo que está en producción — y si no lo reproduces, no lo puedes arreglar ni auditar. Ese es el tema del módulo 2.
Pensar que “más accuracy en el notebook” = mejor en producción. El notebook mide sobre datos del pasado; producción enfrenta datos nuevos que el modelo nunca vio.

La frase para llevarse

“El software se rompe con un error que puedes ver; un modelo de ML se pudre en silencio con predicciones que parecen normales. MLOps es la ingeniería que hace visible esa muerte lenta y la revierte.”

Qué viene

Módulo 2: reproducibilidad. Por qué versionar solo el código no alcanza, cómo versionar datasets grandes que no caben en git, y la herramienta que lo resuelve: DVC. Sin reproducibilidad no hay MLOps, así que empezamos por ahí.

MLOps — Módulo 1: qué es MLOps y por qué