GS Caltex, azienda sudcoreana del settore energia e chimico, ha adottato Amazon SageMaker Canvas e Amazon SageMaker Pipelines per collegare i modelli creati dagli ingegneri di processo ai workflow di produzione. La strategia prevede una chiara divisione dei compiti: gli ingegneri di processo costruiscono e validano i modelli in Canvas senza scrivere codice, sfruttando la loro conoscenza dei processi; gli ingegneri di machine learning (ML) configurano i pipeline di SageMaker per il deployment e le inferenze programmate.

Da SageMaker Canvas a SageMaker Pipelines: il percorso di consegna

Il trasferimento degli asset da Canvas a Pipelines richiedeva ancora un lavoro di integrazione manuale. Gli ingegneri ML dovevano impostare i percorsi dei dati di produzione, fornire la configurazione del modello e collegare i job di preprocessing e inferenza. GS Caltex ha automatizzato questo handoff, riutilizzando gli asset creati in Canvas.

Il risultato è stato significativo: il tempo di deployment è passato da circa una settimana a poche ore. Inoltre, la società esegue inferenze batch ogni 30 minuti, eliminando la necessità di endpoint sempre attivi e riducendo notevolmente i costi di inferenza.

Panoramica della soluzione

Il workflow MLOps di GS Caltex si articola in due percorsi principali: preparazione di una nuova versione del modello per il deployment e esecuzione di inferenze batch con il modello già distribuito.

Con SageMaker Canvas è possibile preparare visivamente i dati, costruire modelli e generare predizioni batch. Inoltre, è possibile registrare i modelli validati nel SageMaker Model Registry direttamente da Canvas. GS Caltex ha costruito un processo di handoff separato per trasformare questi asset in passaggi eseguibili di SageMaker Pipelines.

Ruoli e responsabilità

Gli ingegneri di processo conoscono le variabili e i dati alla base dei processi industriali e valutano l’utilità delle predizioni del modello. Gli ingegneri ML, invece, convertono gli asset in job di produzione, gestiscono le versioni dei modelli e la cronologia di esecuzione.

    • Preparazione dati: flusso di preprocessing creato con Data Wrangler in Canvas → job di preprocessing in SageMaker Processing.
    • Sviluppo modello: modello addestrato e risultati di valutazione in Canvas → versioni modello e stato di approvazione nel Model Registry.
    • Predizione: validazione delle predizioni in Canvas → inferenza batch ogni 30 minuti con modello approvato.
    • Operazioni: sviluppo e validazione dei singoli modelli → storico di esecuzione dei passi, risultati memorizzati e gestione degli errori.

Architettura di riferimento

Il diagramma sottostante (non mostrato) illustra il flusso di consegna degli asset di Canvas agli ingegneri ML per il deployment e l’inferenza programmata. Gli ingegneri ML utilizzano Amazon S3 per i flussi di preprocessing e il Model Registry per le versioni dei modelli, quindi schedulano le esecuzioni dei pipeline tramite Amazon EventBridge.

EventBridge avvia ogni run programmata. SageMaker Pipelines prepara i dati di input da S3, esegue il preprocessing e SageMaker Batch Transform, quindi memorizza i risultati in S3. Gli ingegneri ML possono monitorare lo stato dei passi e i log di CloudWatch per verificare il corretto funzionamento.

Prerequisiti per l'implementazione

Prima di iniziare è necessario disporre di:

    • Un modello costruito e valutato in SageMaker Canvas, insieme al flusso di preprocessing Data Wrangler, file CSV per l’inferenza e un bucket S3 per lo storage.
    • Un ruolo di esecuzione SageMaker e un ruolo EventBridge con permessi per avviare il pipeline.
    • Un ambiente Python con Boto3 e SageMaker Python SDK 2.x installati.
    • Il codice di riferimento disponibile nel repository GitHub dedicato.

Implementazione tecnica: passi fondamentali

1. Esecuzione del flusso di preprocessing di Canvas con SageMaker Processing

Il flusso creato con Data Wrangler registra sorgenti dati e passaggi di trasformazione. Per l'implementazione di riferimento, si esporta il flusso su S3 usando SageMaker Processing, quindi si recuperano le impostazioni del job e il file .flow utilizzato.

Nelle impostazioni di esportazione si disattiva “Auto job configuration” e si seleziona “SageMaker Processing”. Dopo l’avvio, si aprono i dettagli del job nella console SageMaker AI e si annotano:

    • URI dell’immagine del container.
    • URI S3 dell’input denominato flow.
    • Ruolo di esecuzione.
    • Impostazioni di output.

Questi valori configurano il passo del pipeline che esegue il file .flow. Il ruolo di esecuzione deve poter leggere i dati da S3, scrivere i risultati e accedere all’immagine del container. Il tipo e il numero di istanze dipendono dal volume di dati da processare.

2. Gestione delle differenze tra input di training e di inferenza

Una differenza critica è la colonna target, presente nei dati di training ma assente nei dati di inferenza. Il flusso di training può includere trasformazioni che si aspettano tale colonna.

Per risolvere, si aggiunge un passo PrepareInput prima del preprocessing: se la colonna target è mancante, viene inserita con un valore placeholder. Dopo il preprocessing, un passo DropTargetColumn rimuove la colonna placeholder, garantendo che il modello riceva lo schema corretto.

Controlli di qualità e validazione

Durante il trasferimento è fondamentale verificare:

    • Posizione di input: controllare il S3 URI referenziato nel file .flow. Caricare i dati in un percorso diverso non aggiorna automaticamente il riferimento.
    • Immagine del container: utilizzare l’immagine del job di Processing creato durante l’esportazione e fissare una versione per riprodurre le trasformazioni validate.
    • ID di output: rispettare esattamente il formato {nodeid}.{outputname} presente nella configurazione esportata.
    • Valori di trasformazione appresi: conservare parametri di scaling, encoding, ecc., evitando di ricalcolarli per ogni batch di inferenza.
    • Validazione dei risultati: confrontare colonne, tipi di dato e valori trasformati prodotti da Canvas e da Processing per lo stesso input.

Alcuni file .flow includono metadati di esecuzione, ad esempio internalmetadata.dwjob.container_uri. È consigliabile verificare le impostazioni effettive del job di Processing invece di presumere la presenza di tali campi. Se il workflow viene spostato in un’altra regione AWS, occorre confermare la disponibilità dell’immagine del container.

Isolamento degli input per esecuzioni concorrenti

Il riferimento separa output intermedi e finali sotto runs/<execution-id>/. Il passo PrepareInput scrive i dati in un percorso S3 fisso indicato nel file .flow. Per evitare sovrapposizioni, è consigliabile aggiungere un passo di preparazione che aggiorni l’URI di origine in una copia del file .flow. Definire un parametro del pipeline non sostituisce automaticamente l’URI all’interno del file.

Conclusioni e prossimi passi

GS Caltex ha dimostrato che è possibile integrare SageMaker Canvas e SageMaker Pipelines in un workflow MLOps completo, riducendo drasticamente i tempi di deployment e i costi di inferenza. La chiave del successo è l’automazione del passaggio di consegna, il riuso dei flussi di preprocessing validati e la gestione centralizzata delle versioni modello nel Model Registry.

Nel prossimo articolo verranno approfonditi i dettagli della costruzione del pipeline, la gestione delle versioni modello e le best practice per il monitoraggio continuo delle inferenze batch.