View a markdown version of this page

Fase 3. Definire la pipeline - AWS Guida prescrittiva

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 3. Definire la pipeline

Definizione della pipeline ML.

In questo passaggio vengono definite la sequenza e la logica delle azioni che la pipeline eseguirà. Ciò include i passaggi discreti, nonché i relativi ingressi e uscite logici. Ad esempio, qual è lo stato dei dati all'inizio della pipeline? Proviene da più file con diversi livelli di granularità o da un singolo file flat? Se i dati provengono da più file, è necessario un unico passaggio per tutti i file o passaggi separati per ogni file per definire la logica di preelaborazione? La decisione dipende dalla complessità delle fonti di dati e dalla misura in cui sono preelaborate.

Nella nostra implementazione di riferimento, utilizziamo AWS Step Functions, che è un orchestratore di funzioni senza server, per definire le fasi del flusso di lavoro. Tuttavia, il framework ML Max supporta anche altri sistemi di pipeline o macchine a stati come Apache AirFlow (vedi la sezione Diversi motori per l'orchestrazione delle pipeline) per promuovere lo sviluppo e l'implementazione di pipeline ML.

Utilizzo dell'SDK Step Functions

Per definire la pipeline ML, utilizziamo innanzitutto l'API Python di alto livello fornita da AWS Step Functions Data Science SDK (Step Functions SDK) per definire due componenti chiave della pipeline: passaggi e dati. Se si pensa a una pipeline come a un grafo aciclico diretto (DAG), i passaggi rappresentano i nodi sul grafico e i dati vengono visualizzati come bordi diretti che collegano un nodo (step) al successivo. Esempi tipici di fasi di apprendimento automatico includono la preelaborazione, la formazione e la valutazione. Step Functions SDK fornisce una serie di passaggi integrati (come TrainingStep) che è possibile utilizzare. Esempi di dati includono input, output e molti set di dati intermedi prodotti da alcune fasi della pipeline. Quando si progetta una pipeline ML, non si conoscono i valori concreti degli elementi di dati. È possibile definire segnaposto di dati che fungono da modello (in modo simile ai parametri delle funzioni) e contengono solo il nome dell'elemento di dati e i tipi di dati primitivi. In questo modo, puoi progettare un progetto di pipeline completo senza conoscere in anticipo i valori concreti dei dati che viaggiano sul grafico. A tale scopo, puoi utilizzare le classi placeholder in Step Functions SDK per modellare in modo esplicito questi modelli di dati.

Le pipeline ML richiedono anche parametri di configurazione per eseguire un controllo dettagliato sul comportamento di ogni fase ML. Questi segnaposto di dati speciali sono chiamati segnaposto parametrici. Molti dei loro valori sono sconosciuti quando si definisce la pipeline. Esempi di segnaposto per parametri includono i parametri relativi all'infrastruttura definiti durante la progettazione della pipeline (ad esempio, Regione AWS l'URL dell'immagine del contenitore) e i parametri relativi alla modellazione ML (come gli iperparametri) che definisci quando esegui la pipeline.

Estensione dello Step Functions SDK

Nella nostra implementazione di riferimento, uno dei requisiti era quello di separare le definizioni delle pipeline ML dalla creazione e distribuzione di pipeline ML concrete utilizzando impostazioni di parametri specifiche. Tuttavia, alcuni dei passaggi integrati in Step Functions SDK non ci consentivano di passare tutti questi parametri segnaposto. Invece, ci si aspettava che i valori dei parametri fossero ottenuti direttamente durante la fase di progettazione della pipeline tramite chiamate API di configurazione SageMaker AI. Ciò funziona bene se l'ambiente SageMaker AI in fase di progettazione è identico all'ambiente di runtime SageMaker AI, ma ciò accade raramente nelle impostazioni del mondo reale. Un abbinamento così stretto tra tempo di progettazione e runtime della pipeline e il presupposto che l'infrastruttura della piattaforma ML rimanga costante, ostacola in modo significativo l'applicabilità della pipeline progettata. In effetti, la pipeline ML si interrompe immediatamente quando la piattaforma di implementazione sottostante subisce anche la minima modifica.

Per superare questa sfida e produrre una solida pipeline ML (che volevamo progettare una sola volta ed eseguire ovunque), abbiamo implementato i nostri passaggi personalizzati estendendo alcuni dei passaggi integrati, tra cui, e. TrainingStepModelStepTransformerStep Queste estensioni sono fornite nel progetto ML Max. Le interfacce di questi passaggi personalizzati supportano molti più segnaposto di parametri che possono essere compilati con valori concreti durante la creazione della pipeline o quando la pipeline è in esecuzione.