MLOps en 2026: MLflow, Model Registry y preguntas de entrevista técnica

Las preguntas de entrevista sobre MLOps pasaron de ser una especialidad de nicho a convertirse en una parte central de la contratación en ciencia de datos e ingeniería de machine learning en 2026. Los equipos ya no preguntan únicamente cómo se entrena un modelo; indagan cómo se rastrea, versiona, despliega y monitorea una vez que el tráfico real llega a él. Esta guía recorre las preguntas que se repiten en las entrevistas de MLOps, agrupadas por etapa del ciclo de vida, con ejemplos de MLflow que reflejan configuraciones de producción.

Preguntas de entrevista sobre MLOps y el ciclo de vida del machine learning

Q1: ¿Qué es MLOps y en qué se diferencia de DevOps?

MLOps aplica principios de DevOps como la automatización, el CI/CD y el monitoreo a los sistemas de machine learning, y luego suma tres preocupaciones que el software tradicional no tiene: versionado de datos, versionado de modelos y validación continua frente a distribuciones de datos en vivo. En el DevOps clásico, el código es el único artefacto que cambia. En MLOps, el código, los datos y el modelo entrenado se versionan de forma independiente, y cualquiera de los tres puede degradar silenciosamente la calidad de la salida sin que cambie una sola línea de código. El citado artículo Hidden Technical Debt in Machine Learning Systems sostiene que el código del modelo es una fracción pequeña de un sistema de ML real, mientras que los pipelines de datos, el monitoreo y la configuración dominan la superficie.

Q2: Recorra las etapas del ciclo de vida de un modelo de ML en producción.

Una respuesta sólida nombra cinco etapas y el artefacto que cada una produce: ingesta y validación de datos (un dataset versionado), experimentación (ejecuciones registradas con métricas), registro del modelo (un modelo versionado y promocionable), despliegue (un endpoint de servicio o un trabajo por lotes) y monitoreo (telemetría de drift y desempeño que retroalimenta el reentrenamiento). Los entrevistadores prestan atención al ciclo de retroalimentación: el monitoreo debe conectarse de vuelta con la experimentación; de lo contrario, el sistema es un pipeline unidireccional que se degrada con el tiempo.

Seguimiento de experimentos con un ejemplo de tutorial de MLflow

El seguimiento de experimentos es la base sobre la que se construyen la mayoría de las preguntas de MLOps, por lo que una respuesta tipo tutorial de MLflow que muestre un registro real tiene peso. MLflow registra parámetros, métricas y artefactos por cada ejecución, lo que hace que cualquier resultado sea reproducible a partir de su run ID.

Q3: ¿Cómo captura MLflow tracking un experimento y por qué importa el run ID?

Cada llamada a mlflow.start_run() abre una ejecución que registra hiperparámetros, métricas y el modelo serializado. El run ID es el identificador inmutable que vincula una métrica con el código, los parámetros y la instantánea de datos exactos que la produjeron, y es lo que hace que un experimento sea reproducible meses después.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

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

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

El argumento name reemplaza al obsoleto artifact_path en MLflow 3.x, un cambio que vale la pena mencionar para demostrar conocimiento de la API actual. Los candidatos que hacen referencia al seguimiento de features y datasets a través de patrones de validación de pipelines de ML suelen obtener mejores calificaciones, porque la reproducibilidad depende de todo el pipeline, no solo del modelo.

Model Registry 2026: versionado y promoción

El Model Registry de MLflow convierte el artefacto de una ejecución en un objeto gobernado y promocionable. El cambio reciente más importante, y una pregunta frecuente en las entrevistas de 2026, es el abandono de las etapas con nombre.

Q4: ¿Cómo promociona un modelo el Model Registry de MLflow y qué cambió en 2026?

Las versiones anteriores de MLflow promocionaban los modelos a través de etapas fijas llamadas Staging, Production y Archived. MLflow 3.x deja obsoletas esas etapas en favor de alias y etiquetas, porque una lista de etapas fija no podía expresar topologías de despliegue reales como champion, challenger o shadow. Un alias es un puntero mutable a una versión, de modo que promocionar se convierte en reasignar el alias en lugar de mutar el modelo.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Como los consumidores cargan models:/churn-classifier@champion, un rollback es una única reasignación de alias a una versión anterior, sin necesidad de redesplegar. La documentación oficial del Model Registry de MLflow cubre en profundidad la gobernanza de alias y los disparadores por webhook.

Patrones de despliegue y servicio de machine learning

Las preguntas sobre despliegue separan a los candidatos que han puesto modelos en producción de los que solo los han entrenado. La elección del patrón sigue el presupuesto de latencia, no la preferencia personal.

Q5: Compare el despliegue de machine learning por lotes, en línea y en streaming.

| Patrón | Latencia | Caso de uso típico | Superficie de servicio | |--------|----------|--------------------|------------------------| | Por lotes | De horas a diario | Scoring de churn, actualización de recomendaciones | Trabajo programado que escribe en una tabla | | En línea (tiempo real) | Decenas de milisegundos | Verificación de fraude, ranking al momento de la solicitud | Endpoint REST o gRPC | | Streaming | Menos de un segundo, continuo | Detección de anomalías en flujos de eventos | Consumidor en una cola de mensajes |

La pregunta de seguimiento casi siempre indaga cómo servir el caso en línea. Un modelo de MLflow empaqueta su propio entorno, por lo que servirlo es un único comando contra una URI del registro.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: ¿Cómo reducen el riesgo los despliegues blue-green y canary en el lanzamiento de un modelo?

Blue-green mantiene dos entornos idénticos y conmuta todo el tráfico de una sola vez después de que el nuevo modelo pasa las verificaciones, lo que ofrece una vía de rollback instantánea. Canary enruta un pequeño porcentaje del tráfico a la nueva versión, observa las métricas en vivo y luego escala de forma gradual. Para los modelos, canary suele ser más seguro porque los problemas de calidad del modelo solo se manifiestan frente a entradas reales, y un canary limita el radio de impacto a una fracción de los usuarios.

Pruebas y CI/CD para pipelines de machine learning

Q7: ¿Qué prueba el CI/CD en un pipeline de ML que un pipeline de software estándar no prueba?

Un pipeline de CI de software ejecuta pruebas unitarias y de integración sobre el código. Un pipeline de ML añade encima pruebas de datos y de modelo: validación de esquema en los datos entrantes, comprobaciones de distribución para que una ejecución de entrenamiento no ingiera silenciosamente features corruptas y una compuerta de calidad del modelo que hace fallar la compilación cuando un candidato puntúa por debajo del champion actual sobre un conjunto de holdout fijo. Por lo tanto, la entrega continua para ML promociona un artefacto de modelo, no solo una imagen de contenedor, y la compuerta de promoción es un umbral de métrica en lugar de únicamente una suite de pruebas en verde. Un pipeline riguroso también fija las instantáneas de datos y las versiones de dependencias para que cualquier reejecución sea determinista, que es lo que separa una compilación reproducible de una que simplemente pasa hoy.

Monitoreo, drift de datos y reentrenamiento de modelos

Un modelo desplegado se degrada a medida que el mundo cambia bajo sus pies, por lo que las preguntas sobre monitoreo son donde aparece la señal de seniority.

Q8: ¿Cómo se detecta el drift de datos y qué métrica lo cuantifica?

El drift de datos significa que la distribución de las entradas de producción se ha alejado de la distribución de entrenamiento. El Índice de Estabilidad Poblacional (PSI, por sus siglas en inglés) es una medida común e independiente del framework: divide una distribución de referencia en bins, compara las frecuencias de producción contra esos bins y suma las diferencias logarítmicas ponderadas.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Más allá de una métrica hecha a mano, los equipos de producción recurren a herramientas como Evidently para rastrear el drift de features, el drift de objetivo y la calidad de los datos de forma programada. Una respuesta completa distingue el drift de datos (cambian las entradas) del drift de concepto (cambia la relación entre entrada y salida), porque el segundo no puede detectarse observando solo las entradas y requiere resultados etiquetados.

Q9: ¿Qué debería disparar un pipeline de reentrenamiento?

El reentrenamiento por tiempo con una cadencia fija es la opción más simple, pero desperdicia cómputo cuando nada ha cambiado y reacciona con lentitud cuando algo se rompe. Mejores disparadores son los basados en métricas: reentrenar cuando el PSI cruza un umbral, cuando una métrica de evaluación en vivo cae por debajo de un piso o cuando un backtest programado sobre datos recién etiquetados empeora. El trabajo de reentrenamiento registra entonces un challenger, que un despliegue canary compara contra el champion actual antes de reasignar cualquier alias.

Preguntas de entrevista sobre diseño de sistemas de MLOps

Q10: Diseñe una plataforma que sirva cientos de modelos con features consistentes.

La pieza central esperada es un feature store, que resuelve el sesgo entre entrenamiento y servicio (training-serving skew) al calcular las features una sola vez y servir los valores idénticos tanto al entrenamiento como a la inferencia. Herramientas como Feast ofrecen un almacén offline para el entrenamiento y un almacén online de baja latencia para el servicio. Un diseño completo también nombra un model registry para el versionado, un servidor de tracking para el linaje, un orquestador para los pipelines y una capa de monitoreo que cierra el ciclo de vuelta al reentrenamiento. Fundamentar la respuesta en trabajo real con features, como los compromisos que se abordan en esta guía de entrevista sobre feature engineering, señala experiencia práctica en lugar de memorización de diagramas.

Conclusión

• Enmarcar MLOps como DevOps más versionado de datos y modelos: reproducibilidad, seguridad en la promoción y monitoreo son los tres ejes que califican los entrevistadores
• Conocer el cambio de API de MLflow 3.x: los alias y las etiquetas reemplazan a las etapas obsoletas Staging y Production, y log_model ahora recibe name en lugar de artifact_path
• Ajustar el patrón de despliegue al presupuesto de latencia y optar por canary en lugar de blue-green para los lanzamientos de modelos, porque los problemas de calidad solo aparecen frente a entradas en vivo
• Cuantificar el drift con una métrica concreta como el PSI y distinguir el drift de datos del drift de concepto, ya que solo uno es visible sin etiquetas
• Disparar el reentrenamiento según métricas y no según el calendario, y enrutar el challenger resultante a través de un canary antes de reasignar el alias champion
• Nombrar un feature store en cualquier respuesta de diseño de sistemas para cerrar la brecha del training-serving skew antes de que surja como pregunta de seguimiento