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à.
Fase 2: Creare gli script di runtime

In questo passaggio, integri il modello sviluppato nella fase 1 e il codice di supporto associato in una piattaforma ML per l'addestramento e l'inferenza pronti per la produzione. In particolare, ciò comporta lo sviluppo di script di runtime in modo che il modello possa essere incorporato nell'intelligenza artificiale. SageMaker Questi script Python autonomi includono funzioni di callback AI SageMaker predefinite e variabili di ambiente. Vengono eseguiti all'interno di un contenitore SageMaker AI ospitato su un'istanza Amazon Elastic Compute Cloud (Amazon EC2). La documentazione dell'SDK Amazon SageMaker AI Python
Utilizzo dei processi di elaborazione
SageMaker L'intelligenza artificiale offre due opzioni per eseguire l'inferenza del modello in modalità batch. È possibile utilizzare un processo di elaborazione SageMaker AI o un processo di trasformazione in batch. Ogni opzione presenta vantaggi e svantaggi.
Un processo di elaborazione è costituito da un file Python che viene eseguito all'interno di un contenitore SageMaker AI. Il processo di elaborazione consiste nella logica inserita nel file Python. Presenta questi vantaggi:
-
Una volta compresa la logica di base di un processo di formazione, i processi di elaborazione sono semplici da configurare e facili da capire. Condividono le stesse astrazioni dei lavori di formazione (ad esempio, l'ottimizzazione del numero di istanze e della distribuzione dei dati).
-
I data scientist e gli ingegneri di machine learning hanno il pieno controllo sulle opzioni di manipolazione dei dati.
-
Il data scientist non deve gestire alcuna logica dei componenti I/O ad eccezione delle familiari funzionalità di lettura/scrittura.
-
È leggermente più semplice eseguire i file in ambienti non basati sull'SageMaker intelligenza artificiale, il che favorisce lo sviluppo rapido e i test locali.
-
Se si verifica un errore, un processo di elaborazione fallisce non appena lo script fallisce e non ci sono attese impreviste per un nuovo tentativo.
D'altra parte, i processi di trasformazione in batch sono un'estensione del concetto di endpoint SageMaker AI. In fase di esecuzione, questi job importano funzioni di callback, che quindi gestiscono l'I/O per la lettura dei dati, il caricamento del modello e l'elaborazione delle previsioni. I lavori di trasformazione in Batch presentano i seguenti vantaggi:
-
Utilizzano un'astrazione di distribuzione dei dati che differisce dall'astrazione utilizzata dai lavori di formazione.
-
Utilizzano lo stesso file di base e la stessa struttura di funzioni sia per l'inferenza in batch che per l'inferenza in tempo reale, il che è conveniente.
-
Sono dotati di un meccanismo di tolleranza agli errori integrato basato su tentativi. Ad esempio, se si verifica un errore in un batch di record, verrà riprovato più volte prima che il processo venga terminato per errore.
Grazie alla sua trasparenza, alla sua facilità d'uso in più ambienti e all'astrazione condivisa con i processi di formazione, abbiamo deciso di utilizzare il processo di elaborazione anziché il processo di trasformazione in batch nell'architettura di riferimento presentata in questa guida.
È necessario eseguire gli script di runtime Python localmente prima di distribuirli nel cloud. In particolare, ti consigliamo di utilizzare la clausola main guard quando strutturi i tuoi script Python ed esegui il test delle unità.
Utilizzo della clausola main guard
Usa una clausola main guard 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:
-
Usa un parser di argomenti nei file di elaborazione Python per specificare i file di input/output e le loro posizioni.
-
Fornisci una guida principale e funzioni di test per ogni file Python.
-
Dopo aver testato un file Python, incorporalo nelle diverse fasi della pipeline ML, indipendentemente dal fatto che tu stia utilizzando un AWS Step Functions modello o un processo di elaborazione SageMaker AI.
-
Utilizza le istruzioni Assert nelle sezioni critiche dello script per facilitare il test e il debug. Ad esempio, è possibile utilizzare un'istruzione Assert per garantire che il numero di funzionalità del set di dati sia costante dopo il caricamento.
Test unitari
Il test unitario degli script di runtime scritti per la pipeline è un'attività importante che viene spesso ignorata nello sviluppo di pipeline ML. Questo perché l'apprendimento automatico e la scienza dei dati sono campi relativamente nuovi e hanno tardato ad adottare pratiche di ingegneria del software consolidate come i test unitari. Poiché la pipeline ML verrà utilizzata nell'ambiente di produzione, è essenziale testare il codice della pipeline prima di applicare il modello ML alle applicazioni del mondo reale.
Il test unitario dello script di runtime offre anche i seguenti vantaggi esclusivi per i modelli ML:
-
Impedisce trasformazioni impreviste dei dati. La maggior parte delle pipeline ML comporta 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.
-
Rafforza la modularità del codice. I test unitari sono generalmente associati alla misura di copertura del test, che è 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 codice o errori di bassa qualità nella produzione.
Ti consigliamo di utilizzare un framework di unit test maturo come pytest
Importante
I test unitari non possono garantire che tutti gli corner case vengano testati, ma possono aiutarvi a evitare in modo proattivo gli errori prima di implementare il modello. Si consiglia di monitorare il modello anche dopo l'implementazione, per garantire l'eccellenza operativa.