Model Registry

Un registro dei modelli è un sistema centralizzato per organizzare, versionare, governare e recuperare modelli di machine learning lungo tutto il loro ciclo di vita. Collega i file dei modelli, come i pesi del modello appresi, con i metadati che descrivono come ciascun modello è stato addestrato, valutato, approvato e distribuito. In quanto componente fondamentale delle operazioni di machine learning, un registro offre ai team una fonte affidabile per decidere quale versione del modello debba gestire il traffico di produzione.

Come funziona un registro dei modelli#

La registrazione del modello inizia dopo che un ciclo di addestramento produce un modello candidato. Il registro crea una voce con nome, assegna una versione e registra le informazioni necessarie per comprendere e riprodurre l'artefatto. Una voce tipica include:

• Artefatto del modello: I pesi serializzati, la logica di preelaborazione, i file di configurazione o un riferimento alla loro posizione di archiviazione.
• Versione: Un identificatore immutabile che distingue un candidato da un altro.
• Metriche e parametri: Accuratezza della validazione, precisione, richiamo (recall), latenza, dettagli del dataset, iperparametri e altre misurazioni.
• Lineage (Provenienza): Connessioni tra il modello, il suo codice sorgente, l'esecuzione dell'addestramento e i dati.
• Stato: Etichette come candidato, approvato, rifiutato, campione (champion) o archiviato.
• Informazioni di distribuzione: Ambienti ed endpoint che utilizzano attualmente la versione.

Le piattaforme implementano queste idee in modo diverso. Il flusso di lavoro del registro dei modelli MLflow utilizza modelli registrati, versioni, alias e tag, mentre il registro dei modelli Amazon SageMaker supporta gruppi di modelli, stati di approvazione, lineage e automazione della distribuzione. Alcuni sistemi registrano anche una firma del modello: lo schema di input e output atteso descritto nella documentazione sulla firma dei modelli di Snowflake.

Alias come champion o production forniscono nomi stabili che possono spostarsi tra versioni immutabili. Come spiegato nella guida agli alias dei modelli Vertex AI, un'applicazione può richiedere un alias senza inserire nel codice un numero di versione fisso.

Registro dei modelli vs concetti correlati#

Un registro dei modelli si sovrappone a diversi strumenti ML ma serve a uno scopo distinto:

• Il monitoraggio degli esperimenti registra le esecuzioni di addestramento, inclusi parametri, metriche e artefatti intermedi. Un registro riceve output selezionati da quegli esperimenti e li gestisce come candidati al rilascio.
• L'archiviazione degli artefatti contiene file di grandi dimensioni. Un registro può archiviare direttamente tali file, ma può anche fungere da indice di metadati che punta a un'archiviazione a oggetti esterna. L'architettura del registro dei modelli Kubeflow illustra questo design incentrato sui metadati.
• Il controllo di versione versiona il codice, mentre un registro dei modelli versiona gli artefatti addestrati e i loro metadati specifici per l'ML. Il registro dei modelli GitLab può collegare le versioni del modello a processi CI/CD, log, metriche e parametri.
• La distribuzione del modello rende un modello selezionato disponibile per l'inferenza. Il registro identifica l'artefatto approvato; il sistema di distribuzione lo esegue.
• Il monitoraggio del modello osserva il comportamento in produzione dopo il rilascio. I risultati del monitoraggio possono attivare la valutazione, il riaddestramento, la registrazione e la promozione di una versione sostitutiva.

Un registro agisce quindi come punto di controllo tra la fase di sperimentazione e la produzione, anziché sostituire ogni componente circostante.

Applicazioni nel mondo reale#

In un sistema di ispezione manifatturiera, gli ingegneri possono riaddestrare un rilevatore di difetti ogni volta che telecamere, materiali o design dei prodotti cambiano. Il registro può conservare il riferimento al dataset di ciascun modello, la precisione media media (mAP), la latenza di inferenza e il formato hardware supportato. Dopo che i test confermano che la versione 12 migliora il rilevamento dei graffi senza aumentare i falsi allarmi, un supervisore può promuoverla e conservare la versione 11 per un rollback immediato.

Nell'analisi delle immagini mediche, più team possono valutare i candidati per il rilevamento dei tumori. La registrazione preserva i risultati della validazione, la configurazione dell'addestramento, il proprietario responsabile e la cronologia delle approvazioni per ciascuna versione. Le applicazioni di produzione possono essere limitate ai modelli revisionati, mentre le versioni precedenti rimangono disponibili per audit e riproducibilità. I controlli basati sui ruoli, come quelli descritti per la governance del registro dei modelli di Snowflake, aiutano a prevenire la sostituzione non autorizzata o l'ispezione di artefatti sensibili.

Registrazione dei modelli nei flussi di lavoro Ultralytics#

Ultralytics Platform offre una gestione centralizzata dei modelli per annotare dataset, addestrare, confrontare risultati, esportare, distribuire e monitorare modelli di visione artificiale. Il suo flusso di lavoro documentato per la gestione dei modelli sulla piattaforma supporta pesi .pt caricati e modelli prodotti tramite cloud o addestramento remoto.

Il seguente flusso di lavoro documentato addestra Ultralytics YOLO26 localmente inviando al contempo il modello risultante, la configurazione, le metriche e i log a un progetto Platform con nome:

import os

from ultralytics import YOLO

# Authenticate remote training with Ultralytics Platform
os.environ["ULTRALYTICS_API_KEY"] = "YOUR_API_KEY"

model = YOLO("yolo26n.pt")

model.train(
    data="coco8.yaml",
    epochs=3,
    project="username/model-registry-demo",
    name="candidate-001",
)

Il nome del progetto e dell'esecuzione rende il candidato individuabile insieme ai modelli correlati. I team possono valutarlo, utilizzare l'integrazione MLflow di Ultralytics per la registrazione aggiuntiva degli esperimenti o applicare l'esportazione del modello YOLO quando un modello registrato deve essere eseguito su uno specifico hardware cloud o edge.

Guida pratica al registro#

Tratta ogni versione registrata come immutabile. Usa alias leggibili dall'uomo per la distribuzione, conserva le prove di validazione e definisci requisiti di promozione chiari. Una politica di denominazione basata sul Semantic Versioning può comunicare i cambiamenti di compatibilità, sebbene anche le versioni incrementate automaticamente siano efficaci.

Soprattutto, registra pacchetti di modelli completi anziché file di pesi non spiegati. Regole di preelaborazione mancanti, nomi di classi, schemi di input, dipendenze o riferimenti al dataset possono rendere un modello apparentemente valido impossibile da riprodurre o non sicuro da distribuire. Controlli di accesso, test automatizzati, cancelli di approvazione, log di audit e procedure di rollback trasformano un registro dei modelli da un catalogo di file in una salvaguardia di produzione affidabile.