Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Implementazione
Nell'ingegneria del software, l'immissione del codice in produzione richiede la dovuta diligenza, poiché il codice potrebbe comportarsi in modo imprevisto, un comportamento imprevisto dell'utente potrebbe compromettere il software e possono verificarsi casi limite imprevisti. Gli ingegneri e DevOps gli ingegneri del software di solito utilizzano test unitari e strategie di rollback per mitigare questi rischi. Con il machine learning, la messa in produzione dei modelli richiede una pianificazione ancora maggiore, poiché si prevede che l'ambiente reale subisca variazioni e, in molte occasioni, i modelli vengono convalidati in base a metriche che fungono da proxy per le metriche aziendali reali che stanno cercando di migliorare.
Segui le best practice riportate in questa sezione per contribuire ad affrontare queste sfide.
Argomenti
Automatizza il ciclo di implementazione
Il processo di formazione e implementazione deve essere completamente automatizzato per prevenire errori umani e garantire che i controlli di compilazione vengano eseguiti in modo coerente. Gli utenti non devono disporre di autorizzazioni di accesso in scrittura all'ambiente di produzione.
Amazon SageMaker Pipelines
Quando crei pipeline CI/CD per distribuire il tuo modello, assicurati di etichettare gli artefatti della build con un identificatore di build, una versione o un commit del codice e una versione dei dati. Questa pratica consente di risolvere eventuali problemi di distribuzione. L'etichettatura è talvolta necessaria anche per i modelli che effettuano previsioni in campi altamente regolamentati. La capacità di lavorare a ritroso e identificare i dati, il codice, la build, i controlli e le approvazioni esatti associati a un modello di machine learning può contribuire a migliorare in modo significativo la governance.
Parte del lavoro della pipeline CI/CD consiste nell'eseguire test su ciò che sta costruendo. Sebbene si preveda che i test delle unità di dati avvengano prima che i dati vengano acquisiti da un feature store, la pipeline è comunque responsabile dell'esecuzione dei test sull'input e sull'output di un determinato modello e del controllo delle metriche chiave. Un esempio di tale verifica consiste nel convalidare un nuovo modello su un set di convalida fisso e nel confermare che le sue prestazioni siano simili al modello precedente utilizzando una soglia prestabilita. Se le prestazioni sono notevolmente inferiori al previsto, la build dovrebbe fallire e il modello non dovrebbe entrare in produzione.
L'uso estensivo di pipeline CI/CD supporta anche le pull request, che aiutano a prevenire l'errore umano. Quando si utilizzano le pull request, ogni modifica al codice deve essere esaminata e approvata da almeno un altro membro del team prima di poter passare alla produzione. Le pull request sono utili anche per identificare il codice che non rispetta le regole aziendali e per diffondere le conoscenze all'interno del team.
Scegli una strategia di implementazione
MLOpsle strategie di implementazione includono blue/green, canary, shadow, and A/B i test.
Blu/verde
Blue/green deployments are very common in software development. In this mode, two
systems are kept running during development: blue is the old environment (in this case, the
model that is being replaced) and green is the newly released model that is going to
production. Changes can easily be rolled back with minimum downtime, because the old system
is kept alive. For more in-depth information about blue/greenimplementazioni nel contesto di SageMaker, consulta il post del blog Distribuzione e monitoraggio sicuri degli SageMaker endpoint Amazon con AWS CodePipeline e
Canary
Le implementazioni di Canary sono simili alle blue/green deployments in that both keep two models running together. However, in canary deployments, the new model is rolled out to users incrementally, until all traffic eventually shifts over to the new model. As in blue/green implementazioni, il rischio è mitigato perché il nuovo modello (e potenzialmente difettoso) viene monitorato attentamente durante l'implementazione iniziale e può essere ripristinato in caso di problemi. In SageMaker, è possibile specificare la distribuzione iniziale del traffico utilizzando. InitialVariantWeightAPI
Shadow
È possibile utilizzare le distribuzioni shadow per portare in produzione un modello in sicurezza. In questa modalità, il nuovo modello funziona insieme a un modello o processo aziendale precedente ed esegue inferenze senza influenzare alcuna decisione. Questa modalità può essere utile come controllo finale o esperimento di maggiore fedeltà prima di promuovere il modello alla produzione.
La modalità Shadow è utile quando non è necessario alcun feedback sull'inferenza dell'utente. È possibile valutare la qualità delle previsioni eseguendo l'analisi degli errori e confrontando il nuovo modello con il vecchio modello, nonché monitorare la distribuzione dell'output per verificare che sia come previsto. Per scoprire come eseguire la distribuzione shadow con SageMaker, consulta il post del blog Deploy shadow ML models in Amazon SageMaker
Test A/B
Quando i professionisti del machine learning sviluppano modelli nei loro ambienti, le metriche per cui ottimizzano sono spesso proxy delle metriche aziendali che contano davvero. Ciò rende difficile stabilire con certezza se un nuovo modello migliorerà effettivamente i risultati aziendali, come le entrate e la percentuale di clic, e ridurrà il numero di reclami degli utenti.
Prendiamo in considerazione il caso di un sito di e-commerce in cui l'obiettivo aziendale è vendere il maggior numero possibile di prodotti. Il team addetto alla revisione sa che le vendite e la soddisfazione dei clienti sono direttamente correlate a recensioni informative e accurate. Un membro del team potrebbe proporre un nuovo algoritmo di classificazione delle recensioni per migliorare le vendite. Utilizzando i test A/B, potrebbero distribuire i vecchi e i nuovi algoritmi a gruppi di utenti diversi ma simili e monitorare i risultati per vedere se gli utenti che hanno ricevuto previsioni dal modello più recente hanno maggiori probabilità di effettuare acquisti.
I test A/B aiutano anche a valutare l'impatto aziendale dell'instabilità e della deriva del modello. I team possono mettere in produzione nuovi modelli con una certa frequenza, eseguire test A/B su ciascun modello e creare un grafico basato sull'età rispetto alle prestazioni. Ciò aiuterebbe il team a comprendere la deriva e la volatilità dei dati di produzione.
Per ulteriori informazioni su come eseguire test A/B con SageMaker, consulta il post sul blog A/B Testing ML models in production using Amazon SageMaker
Considera i tuoi requisiti di inferenza
Con SageMaker, puoi scegliere l'infrastruttura sottostante per implementare il tuo modello in diversi modi. Queste funzionalità di invocazione dell'inferenza supportano diversi casi d'uso e profili di costo. Le opzioni disponibili includono l'inferenza in tempo reale, l'inferenza asincrona e la trasformazione in batch, come illustrato nelle sezioni seguenti.
Inferenza in tempo reale
L'inferenza in tempo reale è ideale per carichi di lavoro di inferenza in cui sono richiesti requisiti in tempo reale, interattivi e a bassa latenza. Puoi implementare il tuo modello nei servizi di SageMaker hosting e ottenere un endpoint che può essere utilizzato per l'inferenza. Questi endpoint sono completamente gestiti, supportano la scalabilità automatica (vedi Automatically scale Amazon SageMaker models) e possono essere implementati in più zone di disponibilità.
Se disponi di un modello di deep learning creato con Apache MXNet PyTorch, oppure TensorFlow, puoi anche utilizzare Amazon SageMaker Elastic Inference (EI). Con EI, puoi collegare il frazionario GPUs a qualsiasi SageMaker istanza per accelerare l'inferenza. È possibile selezionare l'istanza client per eseguire l'applicazione e collegare un acceleratore EI per utilizzare la quantità di GPU accelerazione corretta per le proprie esigenze di inferenza.
Un'altra opzione consiste nell'utilizzare endpoint multimodello, che forniscono una soluzione scalabile ed economica per l'implementazione di un gran numero di modelli. Questi endpoint utilizzano un contenitore di server condiviso abilitato a ospitare più modelli. Gli endpoint multimodello riducono i costi di hosting migliorando l'utilizzo degli endpoint rispetto all'utilizzo di endpoint a modello singolo. Inoltre riducono il sovraccarico di implementazione, poiché SageMaker gestiscono il caricamento dei modelli in memoria e il loro ridimensionamento in base ai modelli di traffico.
Per ulteriori best practice per la distribuzione di modelli ML in SageMaker, consulta le migliori pratiche di implementazione nella documentazione. SageMaker
Inferenza asincrona
Amazon SageMaker Asynchronous Inference è una funzionalità che mette in coda le richieste in entrata e le SageMaker elabora in modo asincrono. Questa opzione è ideale per richieste con payload di grandi dimensioni (fino a 1 GB), lunghi tempi di elaborazione e requisiti di latenza quasi in tempo reale. L'inferenza asincrona consente di risparmiare sui costi scalando automaticamente il numero di istanze a zero quando non ci sono richieste da elaborare, in modo da pagare solo quando l'endpoint sta elaborando le richieste.
Trasformazione in batch
Utilizza la trasformazione in batch quando desideri eseguire le seguenti operazioni:
Pre-elaborare i set di dati per rimuovere disturbi o distorsioni che possono interferire con l’addestramento o l'inferenza.
Ottenere inferenze da set di dati di grandi dimensioni.
Eseguire l'inferenza quando non è necessario un endpoint persistente.
Associare record di input alle inferenze per facilitare l'interpretazione dei risultati.
