En el módulo 2 aprendiste a reproducir un resultado. Pero en la práctica no entrenas un modelo: entrenas cincuenta. Cambias la profundidad del árbol, pruebas otro learning rate, agregas una feature, y cada corrida deja un archivo. A la tercera tarde ya tienes una carpeta con modelo_final.pkl, modelo_final_v2.pkl, modelo_final_v2_bueno.pkl y modelo_final_DEFINITIVO.pkl, y no tienes idea de cuál dio el mejor F1 ni con qué configuración. Ese caos tiene solución, y es el tema de este módulo.

La tesis del módulo

Si no registras cada experimento de forma sistemática, tu memoria es tu base de datos — y tu memoria miente. Experiment tracking convierte “creo que el de ayer andaba mejor” en una tabla ordenada donde comparas runs por métrica y sabes exactamente qué configuración ganó.

Qué es un run y qué es experiment tracking

Dos términos que usaremos todo el módulo:

Un run (corrida) es una ejecución de tu entrenamiento con una configuración concreta: estos hiperparámetros, estos datos, este seed. Cada vez que corres train.py, eso es un run.
Experiment tracking (registro de experimentos) es guardar de forma automática, por cada run, todo lo necesario para entenderlo y compararlo después: sus params (los hiperparámetros), sus métricas (accuracy, F1, etc.), sus artefactos (el modelo, un gráfico) y la versión de datos y código.

La idea es simple pero poderosa: en vez de nombres de archivo, tienes una base de datos de experimentos. Filtras, ordenas por métrica, comparas dos runs lado a lado y ves qué cambió.

Dónde encaja el tuning de hiperparámetros

Si hiciste el módulo de validación y tuning, ya sabes qué hiperparámetros ajustar y cómo buscarlos (grid search, random search). Experiment tracking es donde esa búsqueda se vuelve sistemática: cada combinación que prueba tu grid search es un run, y en vez de perder los resultados en la salida de la consola, quedan registrados y comparables. El tuning te dice qué probar; el tracking recuerda qué pasó con cada prueba.

MLflow: el estándar para trackear

MLflow es una herramienta open source para experiment tracking (y más — el registry del módulo 4 también es de MLflow). Registra cada run contra un tracking server y te da una interfaz web para comparar. Es el estándar de facto; una alternativa popular en la nube es Weights & Biases (W&B), con una idea muy parecida.

El patrón mínimo: abres un run, logueas params y métricas, guardas el modelo, cierras el run.

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

# Apunta al tracking server (local o remoto)
mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("clasificador-fraude")

SEED = 42
params = {"n_estimators": 200, "max_depth": 8, "random_state": SEED}

# start_run abre un run; el 'with' lo cierra solo al terminar
with mlflow.start_run(run_name="rf-prof8"):
    model = RandomForestClassifier(**params)
    model.fit(X_train, y_train)

    preds = model.predict(X_val)
    f1 = f1_score(y_val, preds)

    # 1. Params: los hiperparámetros de este run
    mlflow.log_params(params)

    # 2. Métricas: los resultados que quieres comparar
    mlflow.log_metric("f1", f1)

    # 3. Artefacto libre: un archivo cualquiera (un gráfico, un CSV)
    mlflow.log_artifact("matriz_confusion.png")

    # 4. El modelo, con su firma, listo para el registry (módulo 4)
    mlflow.sklearn.log_model(model, name="modelo")

    # Deja registrada la versión de datos para poder reproducir
    mlflow.set_tag("datos_version", "train.csv@v3")

Si no quieres loguear a mano cada cosa, MLflow trae autolog, que intercepta el entrenamiento y registra params, métricas y el modelo automáticamente para las librerías soportadas:

import mlflow

mlflow.sklearn.autolog()   # captura params, métricas y modelo solo

with mlflow.start_run():
    model.fit(X_train, y_train)   # todo se loguea sin más código

El flujo: de muchos runs al mejor modelo

Trackear tiene sentido por lo que viene después: comparar. Cada run va al tracking server; en la interfaz los ordenas por métrica y el mejor sale a flote.

   run 1   ─┐
   run 2   ─┤
   run 3   ─┤     ┌───────────────────┐
    ...     ├──►  │  TRACKING SERVER  │
   run 49  ─┤     │  params, métricas,│
   run 50  ─┘     │  artefactos, tags │
                  └─────────┬─────────┘
                            ▼
                  ┌───────────────────┐
                  │  COMPARAR runs    │
                  │  por métrica      │
                  └─────────┬─────────┘
                            ▼
                  ┌───────────────────┐
                  │   MEJOR MODELO    │
                  └───────────────────┘

Ese “mejor modelo” no queda como un .pkl suelto: en el módulo 4 lo promovemos al registry, con su linaje intacto — sabiendo de qué run salió, con qué datos y con qué métrica.

Qué loguear en cada run

No todo se loguea igual. Esta es la clasificación que usa MLflow y conviene tener clara:

Tipo	Qué es	Ejemplos	Cómo
Params	Config de entrada, fija en el run	`max_depth`, `learning_rate`, `seed`	`log_param(s)`
Métricas	Resultados numéricos, comparables	`f1`, `accuracy`, `loss`	`log_metric`
Artefactos	Archivos que produce el run	modelo, gráficos, reporte	`log_artifact`, `log_model`
Tags	Etiquetas para filtrar y rastrear	versión de datos, autor, rama git	`set_tag`

La regla: params son lo que decidiste antes de entrenar (no cambian durante el run); métricas son lo que mides después (y pueden evolucionar por época). La versión de datos como tag es la que amarra este módulo con el módulo 2: sin ella, un run comparado es una métrica sin contexto.

Ojo: loguear la métrica sin loguear la versión de los datos es una trampa. Dos runs con el mismo F1 pero entrenados sobre datasets distintos no son comparables. Trackea siempre el datos_version (el hash del .dvc) junto con params y métricas.

Errores comunes

Comparar de memoria. “El de la mañana andaba mejor” no es un dato. Si no está en el tracking server, no existe.
Nombres de archivo como sistema de versiones. modelo_final_v2_bueno.pkl no dice params, ni métricas, ni datos. Es el síntoma exacto que el tracking elimina.
Loguear métricas pero no la versión de datos. Vuelve los runs incomparables. Métricas sin contexto de datos engañan.
Loguear todo a mano y olvidar la mitad. Si tu librería soporta autolog, úsalo: captura lo esencial sin depender de tu disciplina.
Un tracking server solo en tu laptop. Si el equipo no comparte el server, cada quien tiene su historia y nadie puede comparar contra el resto.

La frase para llevarse

“Sin experiment tracking, tu mejor modelo es el que recuerdas; con tracking, es el que las métricas prueban. Y las métricas no se olvidan de con qué datos se entrenaron.”

Qué viene

Módulo 4: model registry. Ya tienes el run ganador; ahora hay que convertirlo en el modelo oficial que va a producción — con versiones, aliases (champion / challenger) y linaje, para saber siempre qué está desplegado y poder volver atrás.

MLOps — Módulo 3: experiment tracking — no pierdas qué funcionó