Sviluppo delle applicazioni moderne - Machine Learning e intelligenza artificiale
Gli strumenti di machine learning più moderni sono open source e scritti in Python. In quanto tale, una piattaforma di apprendimento automatico deve fornire il supporto nativo per framework open source e Python. Inoltre, dovrebbe consentire agli utenti di personalizzare gli ambienti di apprendimento automatico installando le proprie librerie o aggiornando quelli già installati. La piattaforma dovrebbe consentire ai data scientist di formare i propri modelli su dati strutturati, non strutturati o semi-strutturati, ridimensionando l'estrazione, la trasformazione e il carico (ETL) o le fasi di formazione verticalmente o orizzontalmente per varie risorse di computazione.
Infine, una piattaforma di apprendimento automatico deve garantire che i modelli possano essere facilmente distribuiti per consumo in tempo reale con un minimo attrito (idealmente tramite una semplice chiamata REST), pur conservando la derivazione del modello distribuito per garantire che possa essere sottoposto ad audit e riprodotto.
Questo documento descrive i principi di progettazione associati alla creazione di una piattaforma di apprendimento automatico e un percorso di implementazione ottimale. Utilizzare questo pattern per creare piattaforme di apprendimento automatico che soddisfino le esigenze degli utenti data scientist.
Principi di progettazione
Questa architettura implementa i principi di sviluppo delle applicazioni moderne nei modi seguenti:
- Principio: Utilizzare quadri open source leggeri e linguaggi di programmazione maturi
Utilizza ambienti conda anziché ambienti virtuali Python o immagini Docker. Forniamo ambienti conda data science curati che contengono una raccolta di librerie Python selezionate per risolvere un particolare caso d'uso. Gli ambienti Conda offrono in genere il giusto livello di isolamento in Python, offrono flessibilità consentendo l'esecuzione di più ambienti nello stesso ambiente notebook o nello stesso processo batch e sono più facili da creare rispetto alle immagini Docker. Gli ambienti Conda sono anche facili da esportare e importare perché sono semplici archivi (gzip e zip).
Inizia con il nostro set di ambienti conda pronto all'uso. Questi ambienti vengono aggiornati regolarmente per garantire che i pacchetti in essi contenuti riflettano la versione più recente disponibile. Ogni ambiente è dotato di documentazione ed esempi di codice. Gli ambienti possono essere utilizzati per la creazione, la formazione e la distribuzione di modelli di machine learning in Python 3.6 e versioni successive. Adottare questi ambienti per garantire la compatibilità tra diversi componenti dell'architettura.
- Principio: creare applicazioni sotto forma di servizi che comunicano tramite le API
Adotta la funzione di distribuzione dei modelli di Data Science, che distribuisce un modello dal catalogo modelli come endpoint HTTP scalabile che altre applicazioni possono utilizzare. Garantire che l'ambiente di formazione del modello contenga le stesse dipendenze di terze parti dell'ambiente di distribuzione può rappresentare una sfida. Le distribuzioni dei modelli di data science affrontano tale sfida tirando l'ambiente conda corretto per eseguire il modello dietro l'endpoint HTTP. Le distribuzioni dei modelli forniscono anche l'autenticazione e l'autorizzazione IAM (Oracle Cloud Infrastructure) Identity and Access Management, in modo da non dover creare e configurare il proprio protocollo di gestione degli utenti e degli accessi.
Un'alternativa accettabile è la distribuzione di modelli di apprendimento automatico tramite Oracle Functions, che possono essere utilizzati come backend per il gateway API. Questa opzione offre flessibilità, soprattutto quando si definisce l'API o si utilizza un protocollo di autorizzazione diverso, ad esempio OAuth o l'autenticazione di base. Tuttavia, richiede più lavoro per voi, è meno automatizzato ed è più soggetto a errore utente. Oracle Functions richiede la creazione dell'immagine Docker personale e la verifica che tutte le dipendenze richieste e la versione runtime Python corrispondano all'ambiente di formazione. La maggior parte dei team di data science dovrebbe evitare questa opzione.
- Principio: Automatizza la creazione, il test e la distribuzione
DevOps riguarda lo sviluppo software: una serie di processi e automazione incentrati su sviluppo, test, valutazione, distribuzione e monitoraggio di modelli in produzione. Preferisci l'uso di modelli ripetibili, verificabili e riproducibili attraverso processi e implementazioni di modelli in Data Science. Evita la formazione e la distribuzione dei modelli direttamente da una sessione notebook in cui è più difficile creare, eseguire e automatizzare i test. Assicurarsi che tutto il codice per preparare i dati, formare il modello e definire i test sia controllato a livello di versione. Esegui le pipeline di creazione e distribuzione attraverso il servizio DevOps OCI o direttamente dai job in Data Science. Eseguire la serie di test di introspezione modello inclusi nel codice standard artifact catalogo modello. Se eseguito correttamente, questi test riducono al minimo il numero di errori che si verificano quando il modello viene distribuito in produzione.
- Principio: utilizzo di servizi completamente gestiti per eliminare la complessità a livello di sviluppo di applicazioni, runtime e gestione dei dati
Se un data scientist documenta i propri asset di dati tramite OCI Data Catalog, esegue job di elaborazione dei dati su larga scala con OCI Data Flow o build, treni e distribuisce modelli di apprendimento automatico tramite Data Science, tutte queste soluzioni sono completamente gestite. Ci occupiamo del provisioning, dell'applicazione di patch e della protezione di questi ambienti. Una soluzione completamente gestita riduce notevolmente il carico operativo dei team di data scientist, i cui obiettivi sono formare e distribuire modelli, non gestire l'infrastruttura. Una buona piattaforma di apprendimento automatico fornisce varie offerte dell'infrastruttura (CPU, GPU, forme flessibili) senza necessità di ulteriore configurazione.
- Principio: monitoraggio e rintracciabilità end-to-end dello strumento
Tutti i carichi di lavoro devono disporre di metriche dello stato di base emesse tramite il servizio di monitoraggio OCI. Gli utenti possono definire soglie delle metriche personalizzate per gli avvisi e ricevere una notifica o intervenire quando viene raggiunta una determinata soglia. In questo modo potranno monitorare lo stato operativo dei job, delle sessioni notebook o delle distribuzioni dei modelli.
Consente agli utenti di inviare log personalizzati al servizio di log OCI dai job e dalle distribuzioni dei modelli. Nella maggior parte dei casi, i data scientist desiderano anche monitorare i processi in esecuzione nei job (ad esempio iterazione della formazione o punteggio di convalida non in linea) oppure acquisire vettori di funzioni o previsioni modello da una distribuzione del modello. Questo è un modello comune. Assicurati che possano accedere al servizio di registrazione OCI ed eseguire semplici analisi esplorative mediante il servizio OCI Logging Analytics.
- Principio: Implementare un approccio approfondito alla difesa per proteggere le applicazioni e i dati
Una buona piattaforma di apprendimento automatico limita l'accesso ai data scientist solo alle risorse necessarie per svolgere le proprie attività. Seguire il principio dei privilegi minimi sui gruppi di data scientist. Inoltre, utilizzare le funzioni principali delle risorse sugli utenti per l'autenticazione o l'autorizzazione ad altre risorse. In questo modo si impedisce agli utenti di inserire le credenziali principali utente all'interno di sessioni o job di notebook.
Assicurarsi che tutti gli utenti abbiano accesso a OCI Vault e che le relative credenziali per accedere alle origini dati di terze parti siano memorizzate e cifrate nel Vault. Le sessioni notebook in particolare dovrebbero essere accessibili solo agli utenti che le hanno create; configurare i criteri di accesso in modo da concedere l'accesso alle sessioni notebook e ai job solo al creatore di tali risorse. In questo modo si impedisce a più utenti di accedere allo stesso ambiente di notebook, condividere chiavi private e sovrascrivere lo stesso codice. Limita l'accesso in uscita alla rete Internet pubblica ogni volta che ha senso. Configura e seleziona le VNIC secondarie (rete cloud virtuale e selezione di subnet) per l'avvio di sessioni e job di notebook e impedisce agli utenti di scaricare set di dati o librerie da siti non protetti.
Architettura
È possibile implementare i principi di progettazione utilizzando una distribuzione basata su questa architettura motivata.
Descrizione dell'immagine maf_ai_ml_design_pattern.png
L'architettura prevede i componenti elencati di seguito.
- Servizio Data Integration
Oracle Cloud Infrastructure Data Integration è un servizio cloud completamente gestito, multi-tenant, serverless e nativo che ti consente di eseguire task ETL comuni come l'inclusione di dati da origini diverse, la pulizia, la trasformazione e la ridefinizione di tali dati, nonché il caricamento efficiente per indirizzare le origini dati su OCI.
L'inclusione dei dati da varie origini (ad esempio Amazon Redshift, Azure SQL Database e Amazon S3) in Object Storage e Autonomous Data Warehouse è il primo passo di questo processo.
- Storage degli oggetti e Autonomous Database
Lo storage degli oggetti e Autonomous Data Warehouse offrono il livello di storage per i dati cronologici utilizzati per formare i modelli di machine learning. Lo storage degli oggetti può essere utilizzato come livello di storage dei dati sia di origine che di destinazione per eseguire job di elaborazione dei dati personalizzati e ETL utilizzando il flusso di dati.
- Data Catalog OCI
Un data lake composto da più tabelle in Autonomous Data Warehouse, bucket nello storage degli oggetti e migliaia di asset di dati diventa disponibile rapidamente. Per i data scientist, il problema è quello della scopertaabilità. Non sono DBA eppure devono identificare rapidamente quali data asset sono importanti per risolvere un particolare problema aziendale. Il Data Catalog di Oracle Cloud Infrastructure consente ai data scientist di identificare rapidamente i data asset candidati per formare i modelli di machine learning.
Data Catalog è una soluzione di rilevamento e governance dei dati completamente gestita e self-service per i dati aziendali. Offre un unico ambiente di collaborazione per la gestione dei metadati tecnici, aziendali e operativi. È possibile raccogliere, organizzare, trovare, accedere, comprendere, arricchire e attivare questi metadati.
- Servizio Data Flow OCI
Prima che i dati siano pronti per l'apprendimento automatico, è necessario applicare su larga scala diverse operazioni di "wrangling" dei dati grezzi nello storage degli oggetti o in Autonomous Data Warehouse. I data scientist devono essere puliti, uniti, denormalizzati, deduplicati, imputati, scalati e formati adatti per la formazione dei modelli (in genere un data frame). Questo passo viene in genere eseguito dai tecnici dei dati, ma un maggior numero di data scientist si sta impegnando in questo passo. Il toolkit di fatto per eseguire questi passi è Apache Spark e ti consigliamo di utilizzare Oracle Cloud Infrastructure Data Flow.
Data Flow è un servizio completamente gestito per l'esecuzione delle applicazioni Spark. Consente di concentrarsi sulle applicazioni e fornisce un ambiente di runtime semplice per eseguirle. Offre un'interfaccia utente semplice e intuitiva con supporto API per l'integrazione con applicazioni e flussi di lavoro. Non devi perdere tempo con l'infrastruttura di base, il provisioning dei cluster o l'installazione del software.
- OCI Data Science
Oracle Cloud Infrastructure Data Science è una piattaforma completamente gestita che i team di data science possono utilizzare per creare, formare, gestire e implementare i propri modelli di machine learning su OCI. Data Science include sessioni di notebook, job, un catalogo di modelli, distribuzioni di modelli e l'SDK Python Accelerated Data Science (ADS). I dati possono essere inseriti in sessioni notebook o job da varie origini dati e trasformati in funzioni predittive per la formazione sui modelli. Le sessioni notebook sono ambienti IDE in cui i data scientist possono creare prototipi di trasformazioni richieste per progettare le funzioni e formare il modello. Tali passi possono essere realizzati su larga scala con mansioni. Dopo aver formato i modelli, vengono memorizzati in un livello di storage modello gestito (catalogo modelli) e posizionati nell'area intermedia per la distribuzione. I modelli possono essere distribuiti come endpoint HTTP mediante distribuzioni di modelli. Dopo la distribuzione, i modelli possono essere utilizzati da applicazioni di terze parti, indipendentemente dal fatto che siano gestiti in hosting su OCI o altrove.
- Oracle Machine Learning
Oracle Machine Learning offre anche funzioni per creare, formare e distribuire modelli per i dati nel database. Oracle Machine Learning offre un'interfaccia notebook Zeppelin che consente ai data scientist di formare i modelli utilizzando la libreria client Python OML4Py. OML offre inoltre un approccio senza codice per la formazione dei modelli con l'interfaccia utente AutoML. La distribuzione di modelli come API REST può essere eseguita tramite Oracle Machine Learning Services. Tuttavia, il supporto per il software open source è limitato.
- Servizi di intelligenza artificiale
I servizi AI offrono una raccolta di API di modello predefinite e personalizzabili su casi d'uso che spaziano dal linguaggio, dalla visione, dal discorso, dalle decisioni e dalle previsioni. I servizi AI forniscono previsioni di modello accessibili tramite gli endpoint API REST. Questi servizi offrono modelli pre-addestrati all'avanguardia e devono essere considerati e valutati prima di formare modelli di machine learning personalizzati utilizzando i servizi da 1 a 6. In alternativa, i servizi Oracle Machine Learning offrono anche una serie di modelli pre-addestrati per linguaggio (argomento, parole chiave, riepilogo, somiglianza) e visione.
Considerazioni
Quando si implementano machine learning e intelligenza artificiale, prendere in considerazione queste opzioni.
- Fornire scalabilità orizzontale in ogni fase del ciclo di vita di sviluppo del modello
Offri scalabilità orizzontale per i passi ETL e di elaborazione dei dati (tramite il flusso di dati OCI), la formazione del modello stessa e la distribuzione del modello. Inoltre, considerare la possibilità di utilizzare le GPU sia sul lato della formazione del modello che sul lato della distribuzione.
- Garantire la riproducibilità dei modelli
I modelli sono sottoposti ad audit e devono essere riprodotti. La produzione di un modello richiede che i riferimenti al codice sorgente, ai set di dati di formazione e convalida e all'ambiente (librerie e architettura di terze parti) siano forniti al salvataggio di un modello. Utilizzare i riferimenti al repository Git ed eseguire il commit degli hash per tenere traccia del codice. Utilizzare lo storage degli oggetti per salvare istantanee di set di dati di formazione e convalida. Includere un riferimento a un ambiente conda pubblicato come parte dei metadati del modello.
- Codice, funzioni e modelli di controllo delle versioni
Questa considerazione riguarda la riproducibilità del modello. È possibile eseguire la versione dei modelli direttamente nel catalogo dei modelli di Data Science. Integra l'uso di Git come parte di un IDE Data Science (ad esempio, JupyterLab) o in un motore di esecuzione della formazione come i job Data Science. È possibile eseguire la versione delle funzioni sotto forma di set di dati mediante uno strumento, ad esempio Storage degli oggetti o Storage di file di grandi dimensioni (LFS), che supporta il controllo delle versioni degli oggetti per impostazione predefinita.
- Package, condivisione e riutilizzo di dipendenze runtime di terze parti
Riutilizza gli stessi ambienti conda in notebook, job e distribuzioni modello. In questo modo si riduce anche il rischio di mancate corrispondenze delle dipendenze di terze parti tra questi passi.
- Deve essere indipendente dall'origine dati e limitare i trasferimenti di dati
Il trasferimento dei dati in un ambiente di formazione modello richiede molto tempo. Utilizzare volumi a blocchi condivisibili in ambienti notebook o job di formazione il più possibile. Conservare gli snapshot del set di dati locale a scopo di formazione e convalida dei modelli.
Pattern alternativi
- Implementazione di una VM di data science dal marketplace OCI come alternativa al servizio di data science gestito
L'immagine VM Data Science è disponibile sia per le famiglie di forme CPU che per le famiglie di forme GPU NVIDIA. L'ambiente offre una serie completa di librerie di apprendimento automatico e IDE che possono essere utilizzati dai data scientist. Non fornisce tuttavia funzionalità di implementazione dei modelli. La distribuzione dei modelli può essere ottenuta tramite la distribuzione di modelli OCI Data Science o tramite Oracle Functions.
- Oracle Machine Learning (notebook OML, AutoML UI, Servizi, OML4Py) nel database per la creazione, la formazione e la distribuzione di modelli di machine learning nel database
Questo pattern alternativo offre funzionalità potenti quando i dati necessari per formare il modello si trovano nel database. Questo pattern presenta limitazioni relative al supporto software open source per l'apprendimento automatico.
- Distribuzione di modelli sotto forma di API REST tramite il registro OCI, Oracle Functions e il gateway API
Questo modello è applicabile ai clienti che stanno formando i propri modelli nell'ambiente di immagine VM Data Science o tramite OCI Data Science. Questo pattern fornisce un percorso alternativo alla distribuzione dei modelli di apprendimento automatico sotto forma di endpoint API REST. Un'immagine Docker con l'artifact di modello formato deve essere creata e distribuita nel registro OCI, è possibile creare una funzione Oracle dall'immagine docker e distribuita come risorsa backend del gateway API.
- Distribuzione della piattaforma ML Kubeflow OSS su OKE
Questo pattern offre una soluzione standalone e offre al cliente la possibilità di eseguire carichi di lavoro di apprendimento automatico basati su container su Oracle Container Engine for Kubernetes. Kubeflow è un'offerta OSS che offre tutte le funzionalità chiave di una piattaforma di apprendimento automatico.
Antipattern
Non consigliamo una flotta di VM integrata con uno stack OSS di apprendimento automatico personalizzato. I progetti di apprendimento automatico si basano in genere su più librerie OSS che presentano dipendenze complesse e spesso in conflitto e vulnerabilità della sicurezza che richiedono aggiornamenti costanti dei pacchetti. Consigliamo servizi gestiti che assumono il carico di creare ambienti pronti all'uso e sicuri.