Introducing Hybrid Machine Learning

Ripubblicato da Platone

Seguaci: 0

Gartner prevede che entro la fine del 2024, il 75% delle imprese passerà dalla fase pilota all’operatività dell’intelligenza artificiale (AI) e, a lungo termine, la stragrande maggioranza dei carichi di lavoro finirà nel cloud. Per alcune aziende che intendono migrare al cloud, la complessità, l'entità e la durata delle migrazioni potrebbero essere scoraggianti. La velocità dei diversi team e la loro voglia di nuovi strumenti possono variare notevolmente. Il team di data science di un’azienda potrebbe essere desideroso di adottare la più recente tecnologia cloud, mentre il team di sviluppo delle applicazioni è concentrato sull’esecuzione delle proprie applicazioni web in sede. Anche con un piano pluriennale di migrazione al cloud, alcune versioni dei prodotti devono essere realizzate sul cloud per raggiungere i risultati aziendali.

Per questi clienti proponiamo modelli ibridi di machine learning (ML) come passaggio intermedio nel percorso verso il cloud. I modelli ML ibridi sono quelli che coinvolgono un minimo di due ambienti di elaborazione, in genere risorse di elaborazione locali come laptop personali o data center aziendali, e il cloud. Con i modelli di architettura ML ibrida descritti in questo post, le aziende possono raggiungere gli obiettivi aziendali desiderati senza dover attendere il completamento della migrazione al cloud. In fin dei conti, vogliamo supportare il successo dei clienti in tutte le forme e forme.

Abbiamo pubblicato un nuovo whitepaper, Apprendimento automatico ibrido, per aiutarti a integrare il cloud con l'infrastruttura ML locale esistente. Per ulteriori white paper di AWS, consulta Whitepaper e guide di AWS.

Modelli di architettura ML ibrida

Il white paper offre una panoramica dei vari modelli di machine learning ibridi nell'intero ciclo di vita del machine learning, inclusi lo sviluppo del modello di machine learning, la preparazione dei dati, la formazione, la distribuzione e la gestione continua. La tabella seguente riepiloga gli otto diversi modelli di architettura ML ibrida discussi nel whitepaper. Per ogni modello forniamo un'architettura di riferimento preliminare oltre ai vantaggi e agli svantaggi. Identifichiamo anche un criterio “quando muoverci” per aiutarti a prendere decisioni, ad esempio, quando il livello di impegno per mantenere e ridimensionare un determinato modello ha superato il valore che fornisce.

Mercato	Training	Distribuzione
Sviluppa su personal computer, forma e ospita nel cloud	Formazione locale, distribuzione nel cloud	Fornisci modelli ML nel cloud alle applicazioni ospitate in locale
Sviluppa su server locali, addestra e ospita nel cloud	Archivia i dati localmente, addestrali e distribuiscili nel cloud	Ospita modelli ML con Lambda@Edge per applicazioni on-premise
	Sviluppa nel cloud connettendoti ai dati ospitati in sede	Formarsi con un provider SaaS di terze parti per ospitare nel cloud
	Formazione nel cloud, distribuzione di modelli ML on-premise	Orchestra carichi di lavoro di machine learning ibridi con Kubeflow e Amazon EKS Anywhere

In questo post, approfondiamo il modello di architettura ibrida per la distribuzione, concentrandoci sulla fornitura di modelli ospitati nel cloud alle applicazioni ospitate in sede.

Panoramica sull'architettura

Il caso d'uso più comune per questo modello ibrido sono le migrazioni aziendali. Il tuo team di data science potrebbe essere pronto per la distribuzione nel cloud, ma il team dell'applicazione sta ancora eseguendo il refactoring del codice per l'hosting su servizi nativi del cloud. Questo approccio consente ai data scientist di portare sul mercato i loro modelli più recenti, mentre il team dell'applicazione valuta separatamente quando, dove e come spostare il resto dell'applicazione nel cloud.

Il diagramma seguente mostra l'architettura per ospitare un modello ML tramite Amazon Sage Maker in una regione AWS, fornendo risposte alle richieste provenienti da applicazioni ospitate in locale.

Approfondimento tecnico

In questa sezione, approfondiamo l'architettura tecnica e ci concentriamo sui vari componenti che compongono esplicitamente il carico di lavoro ibrido e facciamo riferimento a risorse altrove, se necessario.

Prendiamo il caso d'uso reale di un'azienda di vendita al dettaglio il cui team di sviluppo dell'applicazione ha ospitato l'applicazione Web di e-commerce in sede. L'azienda desidera migliorare la fedeltà al marchio, aumentare le vendite e i ricavi e aumentare l'efficienza utilizzando i dati per creare esperienze cliente più sofisticate e uniche. Intendono aumentare il coinvolgimento dei clienti del 50% aggiungendo un widget "consigliato per te" sulla schermata iniziale. Tuttavia, hanno difficoltà a offrire esperienze personalizzate a causa delle limitazioni dei sistemi statici e basati su regole, delle complessità e dei costi, e degli attriti con l’integrazione della piattaforma a causa della loro attuale architettura legacy, on-premise.

Il team dell'applicazione ha una strategia di migrazione aziendale di 5 anni per rifattorizzare la propria applicazione Web utilizzando l'architettura nativa del cloud per passare al cloud, mentre i team di scienza dei dati sono pronti per iniziare l'implementazione nel cloud. Con il modello di architettura ibrida descritto in questo post, l'azienda può raggiungere rapidamente i risultati aziendali desiderati senza dover attendere il completamento della migrazione aziendale di 5 anni.

I data scientist sviluppano il modello ML, eseguono la formazione e distribuiscono il modello addestrato nel cloud. L'applicazione Web di e-commerce ospitata in locale utilizza il modello ML tramite gli endpoint esposti. Esaminiamolo in dettaglio.

Nella fase di sviluppo del modello, i data scientist possono utilizzare ambienti di sviluppo locali, come installazioni PyCharm o Jupyter sul proprio personal computer, e quindi connettersi al cloud tramite Gestione dell'identità e dell'accesso di AWS (IAM) e interfaccia con le API del servizio AWS tramite il file Interfaccia della riga di comando di AWS (AWS CLI) o un SDK AWS (come Boto3). Hanno anche la flessibilità di utilizzo Amazon Sage Maker Studio, un'unica interfaccia visiva basata sul Web fornita con pacchetti e kernel comuni di data science preinstallati per lo sviluppo del modello.

I data scientist possono sfruttare le funzionalità di formazione di SageMaker, incluso l'accesso a istanze CPU e GPU on-demand, ottimizzazione automatica dei modelli, istanze Spot gestite, checkpoint per il salvataggio dello stato dei modelli, formazione distribuita gestita e molto altro, utilizzando l'SDK di formazione SageMaker e API. Per una panoramica sui modelli di training con SageMaker, vedere Addestra un modello con Amazon SageMaker.

Dopo aver addestrato il modello, i data scientist possono distribuire i modelli utilizzando le funzionalità di hosting di SageMaker ed esporre un endpoint REST HTTP(s) che fornisce previsioni per terminare le applicazioni ospitate in locale. I team di sviluppo delle applicazioni possono integrare le proprie applicazioni locali per interagire con il modello ML tramite endpoint ospitati da SageMaker per ottenere i risultati dell'inferenza. Gli sviluppatori di applicazioni possono accedere ai modelli distribuiti tramite richieste API (Application Programming Interface) con tempi di risposta di pochi millisecondi. Ciò supporta casi d'uso che richiedono risposte in tempo reale, come consigli personalizzati sui prodotti.

L'applicazione client in locale si connette con il modello ML ospitato sull'endpoint ospitato SageMaker su AWS su una rete privata utilizzando una connessione VPN o Direct Connect, per fornire risultati di inferenza agli utenti finali. L'applicazione client può utilizzare qualsiasi libreria client per richiamare l'endpoint utilizzando una richiesta HTTP Post insieme alle credenziali di autenticazione necessarie configurate a livello di codice e al payload previsto. SageMaker dispone anche di comandi e librerie che astraggono alcuni dettagli di basso livello come l'autenticazione utilizzando le credenziali AWS salvate nel nostro ambiente dell'applicazione client, come SageMaker endpoint di chiamata comando runtime dall'AWS CLI, client runtime SageMaker da Boto3 (SDK AWS per Python) e la classe Predictor di SageMaker SDK Python.

Per rendere l'endpoint accessibile su Internet, possiamo utilizzare Gateway API Amazon. Anche se puoi accedere direttamente agli endpoint ospitati da SageMaker da API Gateway, un modello comune che puoi utilizzare è l'aggiunta di un file AWS Lambda funzione nel mezzo. Puoi utilizzare la funzione Lambda per l'eventuale preelaborazione, che potrebbe essere necessaria per inviare la richiesta nel formato previsto dall'endpoint, o la postelaborazione per trasformare la risposta nel formato richiesto dall'applicazione client. Per ulteriori informazioni, vedere Chiama un endpoint del modello Amazon SageMaker utilizzando Amazon API Gateway e AWS Lambda.

L'applicazione client in locale si connette con i modelli ML ospitati su SageMaker su AWS su una rete privata utilizzando una connessione VPN o Direct Connect, per fornire risultati di inferenza agli utenti finali.

Il diagramma seguente illustra come il team di data science sviluppa il modello ML, esegue la formazione e distribuisce il modello addestrato nel cloud, mentre il team di sviluppo dell'applicazione sviluppa e distribuisce l'applicazione Web di e-commerce in locale.

Approfondimento sull'architettura

Dopo che il modello è stato distribuito nell'ambiente di produzione, i data scientist possono utilizzarlo Monitor modello Amazon SageMaker per monitorare continuamente la qualità dei modelli ML in tempo reale. Possono anche impostare un sistema di attivazione automatica degli avvisi quando si verificano deviazioni nella qualità del modello, come deviazioni dei dati e anomalie. Log di Amazon CloudWatch raccoglie file di registro monitorando lo stato del modello e avvisa quando la qualità del modello raggiunge determinate soglie. Ciò consente ai data scientist di intraprendere azioni correttive, come la riqualificazione dei modelli, il controllo dei sistemi a monte o la risoluzione dei problemi di qualità senza dover monitorare manualmente i modelli. Con i servizi gestiti AWS, il tuo team di data science può evitare gli svantaggi legati all'implementazione di soluzioni di monitoraggio da zero.

I tuoi data scientist possono ridurre il tempo complessivo necessario per distribuire i propri modelli ML in produzione automatizzando i test di carico e l'ottimizzazione dei modelli tra le istanze SageMaker ML utilizzando Raccomandatore di inferenza Amazon SageMaker. Aiuta i tuoi data scientist a selezionare il tipo e la configurazione di istanza migliori (come conteggio delle istanze, parametri del contenitore e ottimizzazioni del modello) per i loro modelli ML.

Infine, è sempre una buona pratica separare l'hosting del tuo modello ML dall'hosting della tua applicazione. In questo approccio, i data scientist utilizzano risorse dedicate per ospitare il loro modello ML, in particolare quelle separate dall'applicazione, il che semplifica notevolmente il processo per promuovere modelli migliori. Si tratta di un passo fondamentale nel volano dell’innovazione. Ciò impedisce inoltre qualsiasi forma di stretto accoppiamento tra il modello ML ospitato e l'applicazione, consentendo così al modello di essere altamente performante.

Oltre a migliorare le prestazioni del modello con tendenze di ricerca aggiornate, questo approccio offre la possibilità di ridistribuire un modello con dati aggiornati. La pandemia globale di COVID-19 ha dimostrato la realtà che i mercati cambiano continuamente e che il modello ML deve rimanere aggiornato con le ultime tendenze. L'unico modo per soddisfare tale requisito è poter riqualificare e ridistribuire il modello con dati aggiornati.

Conclusione

Dai un'occhiata al white paper Apprendimento automatico ibrido, in cui esaminiamo modelli aggiuntivi per l'hosting di modelli ML tramite Lambda @ Edge, Avamposti AWS, Zone locali AWSe Lunghezza d'onda AWS. Esploriamo modelli di ML ibridi nell'intero ciclo di vita del ML. Cerchiamo di sviluppare localmente, mentre forniamo e distribuiamo nel cloud. Discutiamo modelli per la formazione locale da distribuire sul cloud e persino per ospitare modelli ML nel cloud per servire le applicazioni in locale.

Come stai integrando il cloud con la tua infrastruttura ML locale esistente? Condividi il tuo feedback sul machine learning ibrido nei commenti per consentirci di continuare a migliorare i nostri prodotti, funzionalità e documentazione. Se desideri coinvolgere gli autori di questo documento per un consiglio sulla tua migrazione al cloud, contattaci all'indirizzo ibrido-ml-support@amazon.com.

Informazioni sugli autori

Alak Eswaradass è un Solutions Architect presso AWS, con sede a Chicago, Illinois. La sua passione è aiutare i clienti a progettare architetture cloud utilizzando i servizi AWS per risolvere le sfide aziendali. Esce con le sue figlie ed esplora la vita all'aria aperta nel tempo libero.

Emilia Webber si è unito ad AWS subito dopo il lancio di SageMaker e da allora ha cercato di parlarne al mondo! Oltre a creare nuove esperienze ML per i clienti, Emily ama meditare e studiare il buddismo tibetano.

Roop Bagni è un Solutions Architect presso AWS specializzato in AI/ML. È appassionato di machine learning e aiuta i clienti a raggiungere i loro obiettivi aziendali. Nel tempo libero gli piace leggere e fare escursioni.