MLOps nel 2026: MLflow, Model Registry e domande da colloquio tecnico

Le domande da colloquio su MLOps sono passate da specializzazione di nicchia a componente centrale delle assunzioni in data science e machine learning engineering nel 2026. I team non chiedono più soltanto come viene addestrato un modello; indagano su come viene tracciato, versionato, distribuito e monitorato una volta che il traffico reale lo raggiunge. Questa guida affronta le domande che ricorrono nei colloqui MLOps, raggruppate per fase del ciclo di vita, con esempi MLflow che rispecchiano configurazioni di produzione.

Domande da colloquio MLOps sul ciclo di vita del machine learning

Q1: Che cos'è l'MLOps e in cosa differisce dal DevOps?

L'MLOps applica ai sistemi di machine learning principi del DevOps come automazione, CI/CD e monitoraggio, aggiungendo poi tre preoccupazioni che il software tradizionale non ha: versionamento dei dati, versionamento del modello e validazione continua rispetto alle distribuzioni dei dati in tempo reale. Nel DevOps classico, il codice è l'unico artefatto che cambia. Nell'MLOps, codice, dati e modello addestrato vengono versionati in modo indipendente, e ciascuno dei tre può degradare silenziosamente la qualità dell'output senza che venga modificata una sola riga di codice. Il celebre articolo Hidden Technical Debt in Machine Learning Systems evidenzia che il codice del modello è una piccola frazione di un sistema ML reale, mentre pipeline di dati, monitoraggio e configurazione dominano la superficie complessiva.

Q2: Illustra le fasi del ciclo di vita di un modello ML in produzione.

Una risposta solida nomina cinque fasi e l'artefatto prodotto da ciascuna: ingestione e validazione dei dati (un dataset versionato), sperimentazione (run tracciate con metriche), registrazione del modello (un modello versionato e promuovibile), deployment (un endpoint di serving o un job batch) e monitoraggio (telemetria di drift e prestazioni che rientra nel ciclo di riaddestramento). Gli intervistatori ascoltano per cogliere il ciclo di feedback: il monitoraggio deve ricollegarsi alla sperimentazione, altrimenti il sistema è una pipeline a senso unico che si deteriora nel tempo.

Tracking degli esperimenti con un esempio pratico di MLflow

Il tracking degli esperimenti è la base su cui si costruiscono la maggior parte delle domande MLOps, quindi una risposta in stile tutorial MLflow che mostra un logging reale ha peso. MLflow registra parametri, metriche e artefatti per ogni run, il che rende qualsiasi risultato riproducibile a partire dal suo run ID.

Q3: Come cattura MLflow un esperimento tramite il tracking e perché il run ID è importante?

Ogni chiamata a mlflow.start_run() apre una run che registra iperparametri, metriche e il modello serializzato. Il run ID è l'identificatore immutabile che collega una metrica al codice, ai parametri e allo snapshot dei dati esatti che l'hanno prodotta, ed è ciò che rende un esperimento riproducibile mesi dopo.

# 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

L'argomento name sostituisce il deprecato artifact_path in MLflow 3.x, un cambiamento che vale la pena citare per dimostrare consapevolezza dell'API attuale. I candidati che fanno riferimento al tracking delle feature e dei dataset tramite i pattern di validazione delle pipeline ML tendono a ottenere un punteggio più alto, perché la riproducibilità dipende dall'intera pipeline, non solo dal modello.

Model Registry 2026: versionamento e promozione

Il Model Registry di MLflow trasforma l'artefatto di una run in un oggetto governato e promuovibile. Il cambiamento recente più rilevante, nonché un frequente oggetto di indagine nei colloqui del 2026, è l'abbandono degli stage con nome.

Q4: Come promuove un modello il Model Registry di MLflow e cosa è cambiato nel 2026?

Le versioni precedenti di MLflow promuovevano i modelli attraverso stage fissi denominati Staging, Production e Archived. MLflow 3.x deprecia questi stage in favore di alias e tag, perché un elenco di stage cablato nel codice non poteva esprimere topologie di deployment reali come champion, challenger o shadow. Un alias è un puntatore mutabile a una versione, quindi la promozione diventa la riassegnazione dell'alias anziché la modifica del modello.

# 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")

Poiché i consumatori caricano models:/churn-classifier@champion, un rollback è una singola riassegnazione di alias a una versione precedente, senza redeploy. La documentazione ufficiale del Model Registry di MLflow tratta in dettaglio la governance degli alias e i trigger tramite webhook.

Pattern di deployment e serving nel machine learning

Le domande sul deployment distinguono i candidati che hanno messo in produzione modelli da quelli che li hanno soltanto addestrati. La scelta del pattern segue il budget di latenza, non le preferenze personali.

Q5: Confronta il deployment batch, online e streaming nel machine learning.

| Pattern | Latenza | Caso d'uso tipico | Superficie di serving | |---------|---------|------------------|-----------------| | Batch | Da ore a giornaliera | Scoring del churn, aggiornamento delle raccomandazioni | Job schedulato che scrive su una tabella | | Online (real-time) | Decine di millisecondi | Controlli antifrode, ranking al momento della richiesta | Endpoint REST o gRPC | | Streaming | Sub-secondo, continuo | Rilevamento di anomalie su flussi di eventi | Consumer su una coda di messaggi |

La domanda successiva chiede quasi sempre come servire il caso online. Un modello MLflow racchiude il proprio ambiente, quindi servirlo è un unico comando eseguito su un URI del registry.

# 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: Come riducono il rischio i deployment blue-green e canary in un rollout di modelli?

Il blue-green mantiene due ambienti identici e sposta tutto il traffico in una sola volta dopo che il nuovo modello ha superato i controlli, offrendo un percorso di rollback immediato. Il canary instrada una piccola percentuale di traffico verso la nuova versione, osserva le metriche in tempo reale e poi aumenta gradualmente. Per i modelli, il canary è di solito più sicuro perché i problemi di qualità del modello emergono solo di fronte a input reali, e un canary limita il raggio d'azione a una frazione degli utenti.

Testing e CI/CD per le pipeline di machine learning

Q7: Cosa testa una CI/CD in una pipeline ML che una pipeline software standard non testa?

Una pipeline di CI software esegue test unitari e di integrazione sul codice. Una pipeline ML aggiunge test sui dati e sul modello: validazione dello schema sui dati in ingresso, controlli di distribuzione affinché una run di addestramento non ingerisca silenziosamente feature corrotte, e un gate di qualità del modello che fa fallire la build quando un candidato ottiene un punteggio inferiore al champion attuale su un holdout set fisso. La continuous delivery per l'ML promuove quindi un artefatto-modello, non solo un'immagine container, e il gate di promozione è una soglia metrica anziché la sola suite di test superata. Una pipeline rigorosa fissa anche gli snapshot dei dati e le versioni delle dipendenze in modo che qualsiasi riesecuzione sia deterministica, ed è questo che distingue una build riproducibile da una che semplicemente supera i test oggi.

Monitoraggio, data drift e riaddestramento del modello

Un modello distribuito si degrada man mano che il mondo cambia sotto di esso, quindi le domande sul monitoraggio sono il punto in cui emerge il segnale di seniority.

Q8: Come si rileva il data drift e quale metrica lo quantifica?

Il data drift indica che la distribuzione degli input di produzione si è allontanata dalla distribuzione di addestramento. Il Population Stability Index (PSI) è una misura comune e indipendente dal framework: suddivide una distribuzione di riferimento in bin, confronta le frequenze di produzione rispetto a quei bin e somma le differenze logaritmiche pesate.

# 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)

Oltre a una metrica implementata a mano, i team di produzione ricorrono a strumenti come Evidently per tracciare drift delle feature, drift del target e qualità dei dati in modo schedulato. Una risposta completa distingue il data drift (spostamento degli input) dal concept drift (spostamento della relazione input-output), perché il secondo non può essere colto osservando solo gli input e richiede esiti etichettati.

Q9: Cosa dovrebbe innescare una pipeline di riaddestramento?

Il riaddestramento a cadenza temporale fissa è l'opzione più semplice, ma spreca risorse di calcolo quando nulla è cambiato e reagisce lentamente quando qualcosa si rompe. Trigger migliori sono basati su metriche: riaddestrare quando il PSI supera una soglia, quando una metrica di valutazione in tempo reale scende sotto un minimo, o quando un backtest schedulato su dati appena etichettati peggiora. Il job di riaddestramento registra quindi un challenger, che un rollout canary confronta con il champion attuale prima che venga riassegnato qualsiasi alias.

Domande da colloquio di system design MLOps

Q10: Progetta una piattaforma che serve centinaia di modelli con feature coerenti.

L'elemento centrale atteso è un feature store, che risolve il training-serving skew calcolando le feature una sola volta e servendo valori identici sia all'addestramento sia all'inferenza. Strumenti come Feast forniscono un offline store per l'addestramento e un online store a bassa latenza per il serving. Un design completo nomina anche un model registry per il versionamento, un tracking server per la lineage, un orchestratore per le pipeline e un livello di monitoraggio che chiude il ciclo verso il riaddestramento. Ancorare la risposta a un lavoro reale sulle feature, come i compromessi trattati in questa guida al colloquio sul feature engineering, segnala esperienza pratica anziché memoria di diagrammi.

Conclusione

• Inquadrare l'MLOps come DevOps più versionamento di dati e modelli: riproducibilità, sicurezza nella promozione e monitoraggio sono i tre assi su cui gli intervistatori assegnano il punteggio
• Conoscere il cambiamento dell'API in MLflow 3.x: alias e tag sostituiscono gli stage deprecati Staging e Production, e log_model ora accetta name anziché artifact_path
• Abbinare il pattern di deployment al budget di latenza e preferire il canary al blue-green per i rollout dei modelli, perché i problemi di qualità emergono solo di fronte a input reali
• Quantificare il drift con una metrica concreta come il PSI e distinguere il data drift dal concept drift, poiché solo uno dei due è visibile senza etichette
• Innescare il riaddestramento su metriche anziché sul calendario, e instradare il challenger risultante attraverso un canary prima di riassegnare l'alias champion
• Nominare un feature store in qualsiasi risposta di system design per colmare il divario del training-serving skew prima che venga sollevato come domanda di follow-up