Fase 2. Creare gli script runtime

In questo passaggio, integrerai il modello sviluppato nel passaggio 1 e il relativo codice di supporto associato in una piattaforma ML per la formazione e l'inferenza pronte per la produzione. Nello specifico, ciò comporta lo sviluppo di script runtime in modo che il modello possa essere incorporato in SageMaker. Questi script Python standalone includono funzioni di callback SageMaker predefinite e variabili d'ambiente. Sono eseguiti all'interno di un contenitore SageMaker ospitato su un'istanza Amazon Elastic Compute Cloud (Amazon EC2). LaDocumentazione di Amazon SageMaker Python SDKfornisce informazioni dettagliate su come questi callback e la configurazione ausiliaria funzionano insieme per la formazione e l'inferenza. (Ad esempio, consultaPrepara uno script di allenamento scikit-learneImplementa un modello scikit-learnnella documentazione di SageMaker.) Le sezioni seguenti forniscono ulteriori suggerimenti per lo sviluppo di script di runtime ML, in base alla nostra esperienza di utilizzoAWSclienti.

Utilizzo di processi di elaborazione

SageMaker offre due opzioni per eseguire l'inferenza del modello in modalità batch. È possibile utilizzare un SageMakerlavoro di elaborazioneo aprocesso di trasformazione in batch. Ciascuna opzione presenta vantaggi e svantaggi.

Un processo di elaborazione è costituito da un file Python che viene eseguito all'interno di un contenitore SageMaker. Il processo di elaborazione consiste in qualsiasi logica inserita nel file Python. Ha questi vantaggi:

• Quando comprendi la logica di base di un lavoro di formazione, i processi di elaborazione sono semplici da configurare e facili da comprendere. Condividono le stesse astrazioni dei lavori di formazione (ad esempio, l'ottimizzazione del conteggio delle istanze e della distribuzione dei dati).

• I data scientist e gli ingegneri ML hanno il pieno controllo sulle opzioni di manipolazione dei dati.

• Il data scientist non deve gestire alcuna logica dei componenti I/O tranne che per le familiari funzionalità di lettura/scrittura.

• È un po 'più semplice eseguire i file in ambienti non Sagemaker, il che facilita lo sviluppo rapido e i test locali.

• Se si verifica un errore, un processo di elaborazione ha esito negativo non appena lo script ha esito negativo e non vi è attesa imprevista di tentativi.

D'altra parte, i processi di trasformazione batch sono un'estensione del concetto di endpoint SageMaker. In fase di runtime, questi processi importano funzioni di callback, che quindi gestiscono l'I/O per la lettura dei dati, il caricamento del modello e le previsioni. I processi di trasformazione Batch presentano i seguenti vantaggi:

• Usano un'astrazione di distribuzione dei dati che differisce dall'astrazione utilizzata dai lavori di formazione.

• Usano lo stesso file principale e la stessa struttura di funzioni sia per l'inferenza batch che per l'inferenza in tempo reale, il che è conveniente.

• Dispongono di un meccanismo di tolleranza ai guasti integrato basato su retrò. Ad esempio, se si verifica un errore su un batch di record, verrà riprovato più volte prima che il processo venga terminato come errore.

Grazie alla sua trasparenza, alla facilità d'uso in più ambienti e alla sua astrazione condivisa con i lavori di formazione, abbiamo deciso di utilizzare il processo di elaborazione anziché il processo di trasformazione batch nell'architettura di riferimento presentata in questa guida.

È necessario eseguire script runtime Python localmente prima di distribuirli nel cloud. In particolare, si consiglia di utilizzare la clausola di protezione principale quando si strutturano gli script Python e si eseguono test unitari.

Utilizzo della clausola di protezione principale

Utilizzare una clausola di protezione principale per supportare l'importazione dei moduli e per eseguire lo script Python. L'esecuzione di script Python singolarmente è utile per il debug e l'isolamento dei problemi nella pipeline ML. È consigliabile eseguire le operazioni seguenti:

• Utilizzare un parser di argomenti nei file di elaborazione Python per specificare i file di input/output e la loro posizione.

• Fornisci una guida principale e le funzioni di test per ogni file Python.

• Dopo aver testato un file Python, incorporarlo nelle diverse fasi della pipeline ML, indipendentemente dal fatto che si stia utilizzando un file PythonAWS Step Functionsmodello o processo di elaborazione SageMaker.

• UtilizzaAsserzioneistruzioni nelle sezioni critiche dello script per facilitare il test e il debug. Puoi ad esempio usare unAsserzioneistruzione per garantire che il numero di funzioni del set di dati sia coerente dopo il caricamento.

Test unitari

Il test unitario degli script runtime scritti per la pipeline è un compito importante che viene spesso ignorato nello sviluppo della pipeline ML. Questo perché l'apprendimento automatico e la scienza dei dati sono campi relativamente nuovi e sono stati lenti ad adottare pratiche di ingegneria software consolidate come il test unitario. Poiché la pipeline ML verrà utilizzata nell'ambiente di produzione, è essenziale testare il codice della pipeline prima di applicare il modello ML alle applicazioni reali.

Il test unitario dello script runtime fornisce inoltre i seguenti vantaggi esclusivi per i modelli ML:

• Previene trasformazioni impreviste di dati. La maggior parte delle pipeline ML coinvolge molte trasformazioni di dati, quindi è fondamentale che queste trasformazioni funzionino come previsto.

• Convalida la riproducibilità del codice. Qualsiasi casualità nel codice può essere rilevata mediante test unitari con diversi casi d'uso.

• Applica la modularità del codice. I test unitari sono solitamente associati alla misura di copertura del test, ovvero il grado in cui una particolare suite di test (una raccolta di casi di test) esegue il codice sorgente di un programma. Per ottenere un'elevata copertura dei test, gli sviluppatori modularizzano il codice, perché è difficile scrivere test unitari per una grande quantità di codice senza suddividerlo in funzioni o classi.

• Impedisce l'introduzione di codici o errori di bassa qualità nella produzione.

È consigliabile utilizzare un framework maturo di test unitario, ad esempiopytestper scrivere i casi di test unitari, perché è più facile gestire test unitari estesi all'interno di un framework.

Importante

Il test unitario non garantisce che tutte le custodie angolari siano testate, ma può aiutarti a evitare errori in modo proattivo prima di distribuire il modello. Si consiglia inoltre di monitorare il modello dopo l'installazione, per garantire l'eccellenza operativa.