MLOps y producción

Un modelo entrenado no es un producto. Es un artefacto que debe integrarse en un sistema, recibir datos, responder en un tiempo razonable, monitorearse y actualizarse cuando el mundo cambia. MLOps es la disciplina que hace que eso sea repetible.

El ciclo completo

El modelo es la parte pequeña

En un sistema real, el código del modelo suele ser una fracción mínima del total. El resto es infraestructura de datos, validación, serving, logging, dashboards y procesos. La deuda técnica de ML viene de las fronteras entre esos componentes:

• Cambios en la fuente de datos que rompen el esquema.
• Preprocesado duplicado entre entrenamiento y serving que se desincroniza.
• Dependencias no fijadas que cambian el comportamiento al reinstalar.
• Métricas que no se registran y decisiones que no se pueden auditar.
• Modelos que se degradan sin que nadie lo note.

Niveles de madurez

Guardar el modelo no basta. Debes guardar la misma transformación que se aplicó a los datos, las versiones de las librerías y la configuración. Un modelo sin su pipeline es un artefacto incompleto.

Qué guardar

El pipeline como unidad

import json
import joblib
import sklearn
from datetime import datetime, timezone

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.impute import SimpleImputer
from sklearn.ensemble import RandomForestClassifier

pipeline = Pipeline([
    ("imputar", SimpleImputer(strategy="median")),
    ("escalar", StandardScaler()),
    ("modelo", RandomForestClassifier(
        n_estimators=300, max_depth=12, random_state=42, n_jobs=-1
    ))
])

pipeline.fit(X_train, y_train)

# Guardar pipeline completo, no solo el estimador final
joblib.dump(pipeline, "modelo_v1.joblib", compress=3)

metadatos = {
    "nombre": "churn-classifier",
    "version": "1.0.0",
    "fecha": datetime.now(timezone.utc).isoformat(),
    "sklearn": sklearn.__version__,
    "features": list(X_train.columns),
    "metrica_validacion": {"f1": 0.71, "roc_auc": 0.83},
    "semilla": 42
}
with open("modelo_v1.json", "w", encoding="utf-8") as f:
    json.dump(metadatos, f, indent=2, ensure_ascii=False)

# Verificación: cargar y comparar con el original
cargado = joblib.load("modelo_v1.joblib")
assert (cargado.predict(X_test) == pipeline.predict(X_test)).all()
print("artefacto verificado")

Buenas prácticas de serialización

• Evita pickle para modelos de terceros no confiables: puede ejecutar código al cargar. Usa formatos seguros (ONNX, SavedModel) cuando compartas entre equipos.
• Fija versiones: un modelo guardado con una versión de Scikit-learn puede no cargar igual en otra.
• Incluye un test de humo: un ejemplo de entrada y su salida esperada. Si el artefacto no reproduce esa salida, no se despliega.
• Registra el hash: permite verificar que el artefacto desplegado es el que se evaluó.

Una API de inferencia convierte un modelo en un servicio. Debe validar la entrada, responder en un tiempo predecible, manejar errores sin caerse y registrar lo suficiente para diagnosticar problemas.

Contrato de la API

from contextlib import asynccontextmanager
from typing import Literal

import joblib
import numpy as np
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field, field_validator

MODELO = None
VERSION = "1.0.0"

@asynccontextmanager
async def lifespan(app: FastAPI):
    global MODELO
    MODELO = joblib.load("modelo_v1.joblib")
    yield
    MODELO = None

app = FastAPI(title="Churn API", version=VERSION, lifespan=lifespan)

class Cliente(BaseModel):
    antiguedad_meses: int = Field(ge=0, le=600)
    gasto_mensual: float = Field(ge=0, le=100000)
    num_productos: int = Field(ge=1, le=20)
    reclamos_ultimo_ano: int = Field(ge=0, le=100)
    tipo_contrato: Literal["mensual", "anual", "bienal"]

    @field_validator("gasto_mensual")
    @classmethod
    def gasto_razonable(cls, v: float) -> float:
        if v > 50000:
            raise ValueError("gasto fuera del rango soportado por el modelo")
        return v

class Prediccion(BaseModel):
    churn: bool
    probabilidad: float
    modelo_version: str

def transformar(cliente: Cliente) -> np.ndarray:
    contrato = {"mensual": 0, "anual": 1, "bienal": 2}[cliente.tipo_contrato]
    return np.array([[
        cliente.antiguedad_meses,
        cliente.gasto_mensual,
        cliente.num_productos,
        cliente.reclamos_ultimo_ano,
        contrato
    ]], dtype=float)

@app.get("/health")
def health():
    return {"status": "ok" if MODELO is not None else "unavailable"}

@app.post("/predict", response_model=Prediccion)
def predict(cliente: Cliente) -> Prediccion:
    if MODELO is None:
        raise HTTPException(status_code=503, detail="modelo no disponible")
    X = transformar(cliente)
    prob = float(MODELO.predict_proba(X)[0, 1])
    return Prediccion(
        churn=prob >= 0.5,
        probabilidad=round(prob, 4),
        modelo_version=VERSION
    )

Patrones de serving

• Online: petición individual, baja latencia, respuesta inmediata. Es lo que hace esta API.
• Batch: se procesan lotes periódicamente; más eficiente para grandes volúmenes.
• Streaming: el modelo consume eventos continuos y emite predicciones.
• Edge: el modelo se ejecuta en el dispositivo, sin conexión.

«En mi máquina funciona» es el síntoma de un entorno no reproducible. Docker empaqueta código, dependencias y configuración en una imagen que se ejecuta igual en tu portátil, en CI y en el servidor.

Imagen, contenedor y capas

• Imagen: plantilla inmutable con sistema base, dependencias y código.
• Contenedor: instancia en ejecución de una imagen.
• Capas: cada instrucción del Dockerfile crea una capa. El orden afecta el caché: pon lo que cambia menos arriba.

FROM python:3.11-slim

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1 \
    PIP_NO_CACHE_DIR=1

WORKDIR /app

# 1) Dependencias primero: se cachean si no cambian
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 2) Código y artefacto después
COPY src/ ./src/
COPY artifacts/modelo_v1.joblib ./artifacts/

# 3) Usuario sin privilegios
RUN useradd --create-home appuser && chown -R appuser:appuser /app
USER appuser

EXPOSE 8000

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"

CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

# Construir la imagen
docker build -t churn-api:1.0.0 .

# Ejecutar el contenedor
docker run --rm -p 8000:8000 churn-api:1.0.0

# Probar el endpoint
curl -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"antiguedad_meses": 12, "gasto_mensual": 45.5, "num_productos": 2, "reclamos_ultimo_ano": 1, "tipo_contrato": "mensual"}'

# Ver logs y tamaño
docker logs 
docker images churn-api

Errores frecuentes en Docker

Reproducibilidad más allá de Docker

Una imagen fija el entorno, pero también debes fijar los datos y el azar. Registra el hash del dataset, las semillas y la versión del código. Sin eso, dos ejecuciones con la misma imagen pueden producir modelos distintos.

La integración continua verifica que el código sigue funcionando; el despliegue continuo lo publica. En ML hay una tercera pieza: los datos y el modelo también necesitan versiones, pruebas y trazabilidad.

Qué debe probar un pipeline de ML

Versionar datos y modelos

Git versiona código, no datasets grandes. Para datos se usan DVC, LakeFS o almacenamiento con hashes; para modelos, un registro (MLflow, W&B, un bucket con metadatos). Lo importante es poder responder: ¿con qué datos, código e hiperparámetros se produjo este artefacto?

name: ml-pipeline

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - run: pip install -r requirements.txt
      - name: Tests unitarios
        run: pytest -q
      - name: Validación de datos
        run: python scripts/validate_data.py --data data/train.csv
      - name: Test de humo del artefacto
        run: python scripts/smoke_test.py --model artifacts/modelo_v1.joblib
      - name: Construir imagen
        run: docker build -t churn-api:${{ github.sha }} .
      - name: Escanear imagen
        run: trivy image --exit-code 1 --severity HIGH,CRITICAL churn-api:${{ github.sha }}

Estrategias de despliegue

• Recreate: se reemplaza la versión anterior. Simple, con downtime.
• Rolling: se actualizan instancias gradualmente. Sin downtime, pero conviven versiones.
• Blue-green: dos entornos idénticos; se cambia el tráfico cuando el nuevo está validado.
• Canary: se envía un porcentaje pequeño de tráfico a la nueva versión y se compara con la anterior.
• Shadow: la nueva versión recibe tráfico duplicado sin afectar a usuarios; se comparan predicciones.

Un modelo en producción no es estático. Las entradas cambian, el comportamiento de los usuarios cambia y la relación entre ambos puede cambiar. El monitoreo existe para detectar esa degradación antes de que afecte a las decisiones.

Tres tipos de cambio

Qué monitorear

Etiquetas tardías

En muchos problemas la etiqueta real llega semanas después (impago, reingreso, fallo). No puedes esperar para monitorear. Alternativas: usar proxies, muestras etiquetadas manualmente, o comparar la distribución de scores con la esperada. Documenta el retraso y no confundas ausencia de queja con buen rendimiento.

import numpy as np
from scipy.stats import ks_2samp

def psi(referencia, produccion, bins=10):
    """Population Stability Index para una feature numérica."""
    cortes = np.quantile(referencia, np.linspace(0, 1, bins + 1))
    cortes[0], cortes[-1] = -np.inf, np.inf
    p, _ = np.histogram(referencia, bins=cortes)
    q, _ = np.histogram(produccion, bins=cortes)
    p = np.clip(p / max(1, p.sum()), 1e-6, None)
    q = np.clip(q / max(1, q.sum()), 1e-6, None)
    return float(np.sum((p - q) * np.log(p / q)))

for columna in features:
    valor_psi = psi(train[columna].dropna(), prod[columna].dropna())
    ks, p_valor = ks_2samp(train[columna].dropna(), prod[columna].dropna())
    estado = "ALTO" if valor_psi > 0.25 else "moderado" if valor_psi > 0.1 else "estable"
    print(f"{columna:>20s} PSI={valor_psi:.3f} KS={ks:.3f} p={p_valor:.4f} -> {estado}")

# Distribución de scores: comparar con referencia
print("tasa de positivos train:", (score_train >= 0.5).mean())
print("tasa de positivos prod :", (score_prod >= 0.5).mean())

Cuando un modelo influye en crédito, empleo, salud o seguridad, la pregunta no es solo si funciona, sino si podemos explicar, auditar y limitar su uso. La gobernanza es el conjunto de decisiones y controles que hacen eso posible.

Preguntas de gobernanza

• Propósito: ¿para qué está autorizado el modelo y para qué no?
• Datos: ¿qué datos se usaron, con qué base legal y durante cuánto tiempo se conservan?
• Responsabilidad: ¿quién responde cuando el modelo se equivoca?
• Explicabilidad: ¿puede una persona afectada recibir una razón comprensible?
• Supervisión: ¿hay revisión humana en decisiones de alto impacto?
• Auditoría: ¿se conservan versiones, entradas y salidas para reconstruir decisiones?

Privacidad en la práctica

Explicabilidad: qué puedes prometer

La explicabilidad no es un único concepto. Puedes ofrecer:

• Explicaciones globales: qué features importan en promedio (importancia, SHAP agregado).
• Explicaciones locales: por qué esta predicción concreta (SHAP, LIME, contrafactuales).
• Transparencia del proceso: qué datos, versión y reglas se aplicaron, aunque el modelo sea una caja negra.

Ninguna técnica prueba causalidad. Una explicación SHAP describe la contribución al score del modelo, no el efecto causal de la variable en el mundo. Sé explícito sobre esa diferencia.

Auditoría mínima

1. Identificador único de la decisión.
2. Timestamp y versión del modelo.
3. Entradas relevantes (con la debida protección de datos).
4. Salida y umbral aplicado.
5. Regla o intervención humana, si la hubo.
6. Política de retención y acceso.

Este es el cierre operativo del curso. Antes de decir que un modelo está «listo para producción», recorre esta lista. No es una formalidad: cada punto corresponde a un fallo que ocurre con frecuencia.

Antes de desplegar

Después de desplegar

Errores que deberías evitar

• Desplegar sin un test de humo del artefacto.
• Confiar en que el preprocesado de producción coincide con el de entrenamiento.
• Monitorear solo latencia y errores HTTP.
• No versionar datos ni semillas.
• Ignorar la deriva porque «el modelo funcionaba en el test».
• Automatizar decisiones de alto impacto sin revisión humana.