Approcci di test per i modelli Amazon SageMaker ML

Questo post è stato scritto insieme a Tobias Wenzel, Software Engineering Manager per la piattaforma Intuit Machine Learning.

Apprezziamo tutti l'importanza di un modello di apprendimento automatico (ML) affidabile e di alta qualità quando si utilizza la guida autonoma o si interagisce con Alexa, ad esempio. I modelli ML svolgono un ruolo importante anche in modi meno ovvi: vengono utilizzati da applicazioni aziendali, assistenza sanitaria, istituzioni finanziarie, amazon.com, TurboTax e altro ancora.

Poiché le applicazioni abilitate al ML diventano fondamentali per molte aziende, i modelli devono seguire lo stesso vigore e la stessa disciplina delle applicazioni software. Un aspetto importante di MLOps è fornire una nuova versione del modello ML precedentemente sviluppato in produzione utilizzando pratiche DevOps consolidate come test, controllo delle versioni, distribuzione continua e monitoraggio.

Ci sono diversi prescrittivo linee guida su MLOps e questo post offre una panoramica del processo che puoi seguire e quali strumenti utilizzare per i test. Questo si basa su collaborazioni tra Intuit e AWS. Abbiamo lavorato insieme per attuare le raccomandazioni spiegate in questo post nella pratica e su larga scala. L'obiettivo di Intuit di diventare un Piattaforma per esperti basata sull'intelligenza artificiale dipende fortemente da una strategia di aumento della velocità di sviluppo del modello iniziale e dal test di nuove versioni.

Requisiti

Le seguenti sono le aree principali da considerare durante la distribuzione di nuove versioni del modello:

1. Prestazioni di precisione del modello – È importante tenere traccia delle metriche di valutazione del modello come accuratezza, precisione e richiamo e garantire che le metriche oggettive rimangano relativamente le stesse o migliorino con una nuova versione del modello. Nella maggior parte dei casi, la distribuzione di una nuova versione del modello non ha senso se l'esperienza degli utenti finali non migliora.
2. Testare la qualità dei dati – I dati in ambienti non di produzione, siano essi simulati o copie temporizzate, dovrebbero essere rappresentativi dei dati che il modello riceverà una volta distribuito completamente, in termini di volume o distribuzione. In caso contrario, i processi di test non saranno rappresentativi e il modello potrebbe comportarsi in modo diverso in produzione.
3. Importanza e parità delle caratteristiche – L'importanza delle funzionalità nella versione più recente del modello dovrebbe essere paragonata al modello precedente, sebbene potrebbero essere introdotte nuove funzionalità. Questo per garantire che il modello non diventi distorto.
4. Test dei processi aziendali – È importante che una nuova versione di un modello possa soddisfare gli obiettivi aziendali richiesti entro parametri accettabili. Ad esempio, una delle metriche aziendali può essere che la latenza end-to-end per qualsiasi servizio non deve essere superiore a 100 millisecondi oppure il costo per ospitare e riqualificare un particolare modello non può essere superiore a $ 10,000 all'anno.
5. Costo – Un semplice approccio al test consiste nel replicare l'intero ambiente di produzione come ambiente di test. Questa è una pratica comune nello sviluppo di software. Tuttavia, un tale approccio nel caso dei modelli ML potrebbe non produrre il giusto ROI a seconda delle dimensioni dei dati e potrebbe avere un impatto sul modello in termini di problema aziendale che sta affrontando.
6. Sicurezza – Ci si aspetta spesso che gli ambienti di test contengano dati campione anziché dati reali dei clienti e, di conseguenza, le regole di gestione e conformità dei dati possono essere meno rigide. Proprio come il costo, tuttavia, se duplichi semplicemente l'ambiente di produzione in un ambiente di test, potresti introdurre rischi per la sicurezza e la conformità.
7. Scalabilità del negozio di funzionalità – Se un'organizzazione decide di non creare un archivio delle funzionalità di test separato per motivi di sicurezza o di costo, è necessario eseguire il test del modello nell'archivio delle funzionalità di produzione, il che può causare problemi di scalabilità poiché il traffico viene raddoppiato durante il periodo di test.
8. Prestazioni del modello online – Le valutazioni online differiscono dalle valutazioni offline e possono essere importanti in alcuni casi, come i modelli di raccomandazione, perché misurano la soddisfazione degli utenti in tempo reale piuttosto che la soddisfazione percepita. È difficile simulare modelli di traffico reali in modalità non di produzione a causa della stagionalità o di altri comportamenti degli utenti, quindi le prestazioni del modello online possono essere eseguite solo in produzione.
9. Prestazioni operative – Man mano che i modelli diventano più grandi e vengono sempre più distribuiti in modo decentralizzato su hardware diverso, è importante testare il modello per le prestazioni operative desiderate come latenza, tasso di errore e altro.

La maggior parte dei team ML ha un approccio su più fronti al test dei modelli. Nelle sezioni seguenti, forniamo modi per affrontare queste sfide durante le varie fasi di test.

Test del modello offline

L'obiettivo di questa fase di test è convalidare nuove versioni di un modello esistente dal punto di vista dell'accuratezza. Questa operazione dovrebbe essere eseguita in modalità offline per non influire sulle previsioni nel sistema di produzione che forniscono previsioni in tempo reale. Garantendo che il nuovo modello funzioni meglio per le metriche di valutazione applicabili, questo test affronta la sfida 1 (prestazioni di precisione del modello). Inoltre, utilizzando il set di dati corretto, questo test può affrontare le sfide 2 e 3 (testare la qualità dei dati, l'importanza delle funzionalità e la parità), con l'ulteriore vantaggio di affrontare la sfida 5 (costo).

Questa fase viene eseguita nell'ambiente di staging.

Dovresti acquisire il traffico di produzione, che puoi utilizzare per riprodurre nei test retrospettivi offline. È preferibile utilizzare il traffico di produzione passato anziché i dati sintetici. Il Monitor modello Amazon SageMaker funzione di acquisizione dei dati consente di acquisire il traffico di produzione per i modelli ospitati Amazon Sage Maker. Ciò consente agli sviluppatori di modelli di testare i propri modelli con i dati dei giorni lavorativi di punta o di altri eventi significativi. I dati acquisiti vengono quindi riprodotti rispetto alla nuova versione del modello in modo batch utilizzando Trasformazione batch di Sagemaker. Ciò significa che l'esecuzione della trasformazione batch può eseguire test con i dati raccolti nel corso di settimane o mesi in poche ore. Ciò può accelerare notevolmente il processo di valutazione del modello rispetto all'esecuzione affiancata di due o più versioni di un modello in tempo reale e all'invio di richieste di previsione duplicate a ciascun endpoint. Oltre a trovare più rapidamente una versione con prestazioni migliori, questo approccio utilizza anche le risorse di calcolo per un periodo di tempo più breve, riducendo i costi complessivi.

Una sfida con questo approccio al test è che il set di funzionalità cambia da una versione del modello all'altra. In questo scenario, consigliamo di creare un set di funzionalità con un superset di funzionalità per entrambe le versioni in modo che tutte le funzionalità possano essere interrogate contemporaneamente e registrate tramite l'acquisizione dati. Ogni chiamata di previsione può quindi funzionare solo su quelle funzionalità necessarie per la versione corrente del modello.

Come bonus aggiuntivo, integrando Amazon SageMaker Chiarire nel test del modello offline, puoi controllare la nuova versione del modello per la distorsione e anche confrontare l'attribuzione delle funzionalità con la versione precedente del modello. Con le pipeline, puoi orchestrare l'intero flusso di lavoro in modo tale che, dopo l'addestramento, possa essere eseguita una fase di controllo della qualità per eseguire un'analisi delle metriche del modello e dell'importanza delle funzionalità. Queste metriche sono archiviate in Registro dei modelli SageMaker per il confronto nella prossima sessione di formazione.

Integrazione e test delle prestazioni

I test di integrazione sono necessari per convalidare i processi aziendali end-to-end da un punto di vista funzionale e delle prestazioni di runtime. All'interno di questo processo, è necessario testare l'intera pipeline, incluso il recupero e il calcolo delle funzionalità nell'archivio delle funzionalità e l'esecuzione dell'applicazione ML. Questo dovrebbe essere fatto con una varietà di payload diversi per coprire una varietà di scenari e richieste e ottenere una copertura elevata per tutte le possibili esecuzioni di codice. Questo risolve le sfide 4 e 9 (test dei processi aziendali e prestazioni operative) per garantire che nessuno dei processi aziendali venga interrotto con la nuova versione del modello.

Questo test dovrebbe essere eseguito in un ambiente di staging.

Sia i test di integrazione che i test delle prestazioni devono essere implementati dai singoli team utilizzando la loro pipeline MLOps. Per i test di integrazione, consigliamo il metodo collaudato per mantenere un ambiente di pre-produzione funzionalmente equivalente e testare con pochi payload diversi. Il flusso di lavoro di test può essere automatizzato come mostrato in questo laboratorio. Per il test delle prestazioni, puoi usare Raccomandatore di inferenza Amazon SageMaker, che offre un ottimo punto di partenza per determinare quale tipo di istanza e quante di queste istanze utilizzare. Per questo, dovrai utilizzare uno strumento generatore di carico, come i progetti open source perfsizesagemaker ed perfsize che Intuit ha sviluppato. Perfsizesagemaker consente di testare automaticamente le configurazioni degli endpoint del modello con una varietà di requisiti di payload, tempi di risposta e picchi di transazioni al secondo. Genera risultati di test dettagliati che confrontano diverse versioni del modello. Perfsize è lo strumento complementare che prova diverse configurazioni date solo le transazioni di picco al secondo e il tempo di risposta previsto.

A / B testing

In molti casi in cui è richiesta la reazione dell'utente all'output immediato del modello, come le applicazioni di e-commerce, la valutazione funzionale del modello offline non è sufficiente. In questi scenari, è necessario eseguire un test A/B sui modelli in produzione prima di prendere la decisione di aggiornare i modelli. Anche il test A/B ha i suoi rischi perché potrebbe esserci un impatto reale sul cliente. Questo metodo di test funge da convalida finale delle prestazioni ML, un controllo di integrità ingegneristica leggera. Questo metodo affronta anche le sfide 8 e 9 (prestazioni del modello online ed eccellenza operativa).

Il test A/B deve essere eseguito in un ambiente di produzione.

Con SageMaker, puoi eseguire facilmente test A/B sui modelli ML eseguendo più varianti di produzione su un punto finale. Il traffico può essere instradato in incrementi alla nuova versione per ridurre il rischio che un modello che si comporta male potrebbe avere in produzione. Se i risultati del test A/B sembrano buoni, il traffico viene instradato alla nuova versione, assorbendo alla fine il 100% del traffico. Si consiglia di utilizzare i guardrail di distribuzione per la transizione dal modello A al modello B. Per una discussione più completa sull'utilizzo del test A/B Amazon Personalizza modelli come esempio, fare riferimento a Utilizzo del test A / B per misurare l'efficacia dei consigli generati da Amazon Personalize.

Test del modello online

In questo scenario, la nuova versione di un modello è significativamente diversa da quella che già serve il traffico in tempo reale in produzione, quindi l'approccio di test offline non è più adatto a determinare l'efficacia della nuova versione del modello. Il motivo più importante di ciò è una modifica delle funzionalità necessarie per produrre la previsione, in modo che le transazioni registrate in precedenza non possano essere utilizzate per testare il modello. In questo scenario, è consigliabile utilizzare le distribuzioni shadow. Le implementazioni shadow offrono la possibilità di distribuire un'ombra (o sfidante) modello accanto alla produzione (o campione) modello che attualmente fornisce previsioni. Ciò consente di valutare le prestazioni del modello shadow nel traffico di produzione. Le previsioni del modello ombra non vengono fornite all'applicazione richiedente; sono registrati per la valutazione offline. Con l'approccio ombra per i test, affrontiamo le sfide 4, 5, 6 e 7 (test dei processi aziendali, costi, sicurezza e scalabilità del negozio di funzionalità).

Il test del modello online deve essere eseguito in ambienti di staging o di produzione.

Questo metodo per testare le nuove versioni del modello dovrebbe essere utilizzato come ultima risorsa se non è possibile utilizzare tutti gli altri metodi. Lo consigliamo come ultima risorsa perché il duplexing delle chiamate a più modelli genera un carico aggiuntivo su tutti i servizi a valle in produzione, il che può portare a colli di bottiglia delle prestazioni e a un aumento dei costi di produzione. L'impatto più ovvio che questo ha è sul livello di servizio delle funzionalità. Per i casi d'uso che condividono funzionalità da un pool comune di dati fisici, è necessario essere in grado di simulare più casi d'uso che accedono contemporaneamente alla stessa tabella di dati per garantire che non esistano conflitti di risorse prima di passare alla produzione. Ove possibile, evitare query duplicate all'archivio delle funzionalità e riutilizzare le funzionalità necessarie per entrambe le versioni del modello per la seconda inferenza. Negozi di funzionalità basati su Amazon DynamoDB, come quello che Intuit ha costruito, può implementare Acceleratore Amazon DynamoDB(DAX) per memorizzare nella cache ed evitare di raddoppiare l'I/O nel database. Queste e altre opzioni di memorizzazione nella cache possono attenuare la sfida 7 (scalabilità del feature store).

Per affrontare la sfida 5 (costo) e anche 7, proponiamo di utilizzare distribuzioni shadow per campionare il traffico in entrata. Ciò offre ai proprietari dei modelli un altro livello di controllo per ridurre al minimo l'impatto sui sistemi di produzione.

La distribuzione ombra dovrebbe essere integrata in Monitor modello offerte proprio come le normali distribuzioni di produzione al fine di osservare i miglioramenti della versione sfidante.

Conclusione

Questo post illustra gli elementi costitutivi per creare un set completo di processi e strumenti per affrontare varie sfide con il test del modello. Sebbene ogni organizzazione sia unica, questo dovrebbe aiutarti a iniziare e restringere le tue considerazioni quando implementi la tua strategia di test.

---

Circa gli autori

Tobia Wenzel è un Software Engineering Manager per la piattaforma Intuit Machine Learning a Mountain View, California. Ha lavorato sulla piattaforma sin dal suo inizio nel 2016 e ha contribuito a progettarla e costruirla da zero. Nel suo lavoro, si è concentrato sull'eccellenza operativa della piattaforma e portandola con successo attraverso le attività stagionali di Intuit. Inoltre, è appassionato di espandere continuamente la piattaforma con le ultime tecnologie.

Shivanshu Upadhyay è un Principal Solutions Architect nel gruppo AWS Business Development and Strategic Industries. In questo ruolo, aiuta gli utenti più avanzati di AWS a trasformare il proprio settore utilizzando in modo efficace dati e intelligenza artificiale.

Alan Tan è un Senior Product Manager di SageMaker, che guida gli sforzi sull'inferenza di modelli di grandi dimensioni. È appassionato di applicare l'apprendimento automatico all'area dell'analisi. Al di fuori del lavoro, ama la vita all'aria aperta.