Un modello che resta nella cartella di output di un job non è ancora un asset: non ha un nome stabile, non ha una versione a cui una pipeline di rilascio possa puntare e non porta con sé le informazioni necessarie a servirlo. La registrazione è il passaggio in cui diventa un oggetto governato, riferibile in YAML come azureml:nome:versione e tracciabile fino al job che lo ha prodotto. In Azure Machine Learning quel passaggio è tanto più semplice quanto più il modello rispetta un formato che la piattaforma sa leggere.

Registrare un modello MLflow, non un file serializzato

MLflow distingue un artefatto da un modello. Un artefatto è un file qualsiasi prodotto da un run, scritto con mlflow.log_artifact: chi lo riceve deve sapere per conto proprio come caricarlo. Un modello MLflow è invece un artefatto su cui la piattaforma può fare assunzioni forti, perché la cartella contiene un file MLmodel che è la sola fonte di verità su come caricarlo e usarlo. Lo si produce con mlflow.<flavor>.log_model, e quel file dichiara i flavor (il contratto specifico del framework, più il flavor python_function comune a tutti), la signature e l ambiente descritto in conda.yaml.

La signature è il contratto dati fra il modello e il server che lo esegue: quando è presente, MLflow applica i tipi in ingresso. Ne esistono due famiglie, column-based per dati tabulari — il modello riceve un pandas.DataFrame — e tensor-based per array n-dimensionali, che riceve numpy.ndarray. L autologging tenta di inferirla; se l inferenza non produce ciò che serve, la si dichiara al momento del log.

Il vantaggio operativo ricorre in tutto l esame: un modello MLflow si distribuisce su endpoint online o batch senza fornire scoring script né environment, e il deployment genera automaticamente il file swagger.

La registrazione avviene con CLI v2, SDK v2 o studio, e il tipo va dichiarato: mlflow_model, custom_model oppure triton_model. In una pipeline conviene registrare dall output del job, così resta tracciata la relazione fra versione e run.

$schema: https://azuremlschemas.azureedge.net/latest/model.schema.json
name: credit-default
type: mlflow_model
path: azureml://jobs/tidy-pen-9f3k1/outputs/artifacts/paths/model/
tags:
  stage: candidate
az ml model create -f model.yml

Una regola che l esame ama: di un modello registrato si possono aggiornare solo description e tags. Tutto il resto è immutabile, quindi correggere un modello significa pubblicare una nuova versione.

Impacchettare la feature retrieval specification con l artefatto

Se le feature arrivano da un feature store, l artefatto da solo non basta: in inferenza il codice di scoring deve sapere quali feature cercare e dove. La feature retrieval specification è l artefatto che le elenca, e quelle feature possono provenire da più feature set e anche da più feature store. Si genera con l SDK del feature store, tipicamente con generate_feature_retrieval_spec.

Due vincoli non negoziabili: il file si chiama feature_retrieval_spec.yaml, il nome non si può cambiare, e deve stare nella cartella radice dell artefatto del modello. Se non è lì, la lineage fra modello e feature set non viene tracciata e il codice di scoring non trova la lista da caricare. Il packaging è responsabilità del training job: se i dati di addestramento vengono dal component di feature retrieval integrato, lo spec è già nella radice del dataset prodotto e basta copiarlo nell output del modello.

import os, shutil

shutil.copy(
    os.path.join(args.training_data, "feature_retrieval_spec.yaml"),
    args.model_output,
)

In inferenza online la funzione init() dello scoring script risolve lo spec a partire dalla variabile AZUREML_MODEL_DIR e inizializza il lookup sull online store: le feature di produzione sono così le stesse dell addestramento.

Valutare il modello con i principi di AI responsabile

La Responsible AI dashboard riunisce in un unica interfaccia strumenti che altrimenti vivrebbero in librerie separate: analisi dei dati, model overview e valutazione di fairness, error analysis, interpretabilità con importanza delle feature globale e locale, counterfactual what-if e analisi causale. Il debug si legge in tre stadi — identificare errori e disparità, diagnosticarne la causa, mitigare — e i componenti si scelgono in base alla domanda che ci si pone.

Dal punto di vista MLOps il dettaglio decisivo è che la dashboard non è solo un pannello dello studio: si genera come pipeline job usando i component pubblicati nel registry, dal costruttore degli insight fino al component di gather che li unisce. Diventa così riproducibile e inseribile in un workflow di GitHub Actions come gate prima della promozione. La scorecard PDF derivata dalla dashboard è il formato con cui quei risultati si condividono con chi presidia conformità e rischio. Vanno ricordati i limiti dichiarati: classificazione e regressione su dati tabulari, modelli MLflow con implementazione scikit-learn, dataset come DataFrame in formato Parquet.

Archiviare invece di cancellare

Quando una versione esce di produzione, l operazione corretta non è eliminarla ma archiviarla: az ml model archive --name credit-default --version 3 la nasconde dalle query di elenco, mentre il modello resta referenziabile e utilizzabile nei workflow che lo puntano ancora. Se si omette la versione, il comando archivia tutte le versioni; e una nuova versione creata sotto un contenitore archiviato nasce a sua volta archiviata.

Per il resto il ciclo di vita si governa con i metadati: tag che indicano lo stadio di promozione e ricerca degli asset nel workspace, perché sei mesi dopo si possa risalire dal modello in produzione al job che lo ha prodotto.

Da ricordare per l esame

  • Un modello MLflow ha MLmodel, flavor, signature e ambiente: è ciò che abilita il deployment senza scoring script né environment. Un artefatto qualsiasi no.
  • I tipi registrabili sono mlflow_model, custom_model e triton_model; registrare dall output del job con un path azureml://jobs/... conserva la lineage. Di un modello registrato sono mutabili solo description e tags.
  • La feature retrieval specification si chiama feature_retrieval_spec.yaml e sta nella radice dell artefatto, con quel nome esatto.
  • La Responsible AI dashboard si genera anche come pipeline job dai component del registry; la scorecard PDF serve agli stakeholder non tecnici.
  • Archiviare nasconde dagli elenchi ma non elimina, e le nuove versioni sotto un contenitore archiviato nascono archiviate.