Apprendimenti dalla costruzione della piattaforma di ML presso Stitch Fix

Lessons from building the ML platform at Stitch Fix

Questo articolo era originariamente un episodio del podcast ML Platform, uno spettacolo in cui Piotr Niedźwiedź e Aurimas Griciūnas, insieme a professionisti della piattaforma ML, discutono delle scelte di progettazione, delle migliori pratiche, degli stack di strumenti di esempio e delle esperienze del mondo reale di alcuni dei migliori professionisti della piattaforma ML.

In questo episodio, Stefan Krawczyk condivide le sue esperienze nella costruzione della piattaforma ML presso Stitch Fix.

Puoi guardarlo su YouTube:

O ascoltarlo come podcast su:

• Sistemi di intelligenza artificiale Bias scoperti e la convincente ricerca della vera equità
• Il Symbol Tuning di Google è una nuova tecnica di fine-tuning che permette l’apprendimento in contesto nei LLM (Language Model).
• Raccomandazione di prodotti con NMF

• Spotify
• Apple Podcasts

Ma se preferisci una versione scritta, eccola qui!

In questo episodio, imparerai:

• 1
  Problemi risolti dalla piattaforma ML per Stitch Fix
• 2
  Serializzazione dei modelli
• 3
  Pacchettizzazione del modello
• 4
  Gestione delle richieste di funzionalità alla piattaforma
• 5
  La struttura di un team ML end-to-end presso Stitch Fix

Introduzione

Piotr: Ciao a tutti! Siamo Piotr Niedźwiedź e Aurimas Griciūnas di neptune.ai, e state ascoltando il podcast ML Platform.

Oggi abbiamo invitato un ospite davvero unico e interessante, Stefan Krawczyk. Stefan è un ingegnere software, scienziato dei dati e ha esperienza come ingegnere ML. In precedenza, ha gestito la piattaforma dati nella sua azienda e ne è anche il co-creatore del framework open-source Hamilton.

Ho scoperto di recente che sei anche il CEO di DAGWorks.

Stefan: Sì, grazie per avermi invitato. Sono entusiasta di parlare con voi, Piotr e Aurimas.

Cosa è DAGWorks?

Piotr: Hai un background davvero interessante e hai coperto tutti i punti importanti che ci sono al giorno d’oggi.

Puoi dirci qualcosa in più sulla tua attuale impresa, DAGWorks?

Stefan: Certo. Per coloro che non conoscono DAGWorks, D-A-G è l’abbreviazione di Directed Acyclic Graph, ovvero Grafo Diretto Aciclico. È un po’ un omaggio al nostro modo di pensare e al modo in cui cerchiamo di risolvere i problemi.

Vogliamo eliminare il dolore e la sofferenza che le persone provano nel mantenere le pipeline di machine learning in produzione.

Vogliamo permettere a un team di giovani scienziati dei dati di scrivere codice, portarlo in produzione, mantenerlo e, quando se ne vanno, nessuno ha incubi nell’ereditare il loro codice.

In generale, stiamo cercando di rendere le iniziative di machine learning più efficienti dal punto di vista del capitale umano, consentendo ai team di arrivare più facilmente in produzione e mantenere le loro pipeline di modelli, ETL o flussi di lavoro.

In cosa si differenzia DAGWorks dalle altre soluzioni popolari?

Piotr: Il valore a un livello elevato suona fantastico, ma se andiamo più a fondo, ci sono molte cose che accadono intorno alle pipeline e ci sono diversi tipi di problemi.

In cosa si differenzia [la soluzione di] DAGWorks da ciò che è popolare oggi? Ad esempio, prendiamo Airflow, le pipeline di AWS SageMaker. Dove si colloca [DAGWorks]?

Stefan: Buona domanda. Stiamo costruendo su Hamilton, che è un framework open-source per descrivere i flussi di dati.

In termini di dove Hamilton, e dove stiamo iniziando, aiuta a modellare il micro.

Airflow, ad esempio, è un framework di orchestrazione macro. Fondamentalmente si suddivide in grandi task e blocchi, ma l’ingegneria del software che viene eseguita all’interno di quel task è ciò su cui generalmente si lavora e si aggiunge nel tempo, man mano che il machine learning cresce all’interno dell’azienda o si hanno nuove fonti di dati o si vogliono creare nuovi modelli, giusto?

Quello su cui puntiamo innanzitutto è aiutarti a sostituire quel codice Python procedurale con del codice Hamilton che descrivi, di cui posso fornire ulteriori dettagli.

L’idea è aiutarti a permettere a un team di giovani scienziati dei dati di non inciampare negli aspetti di ingegneria del software nel mantenere il codice all’interno dei task macro, come ad esempio Airflow.

In questo momento, Hamilton è molto leggero. Le persone utilizzano Hamilton all’interno di un compito di Airflow. Ci utilizzano all’interno di app FastAPI, Flask, possono utilizzarci all’interno di un notebook.

Potresti quasi pensare a Hamilton come a DBT per le funzioni Python. Fornisce un modo molto opinabile di scrivere Python. A un livello elevato, è il livello superiore.

E poi, stiamo cercando di sfruttare le funzionalità della piattaforma e dell’open-source per poter prendere le definizioni del flusso di dati di Hamilton e aiutarti a generare automaticamente i compiti di Airflow.

Per un giovane data scientist, non importa se stai usando Airflow, Prefect, Dexter. È solo un dettaglio di implementazione. Ciò che usi non ti aiuta a creare modelli migliori. È il veicolo con cui esegui le tue pipeline.

Landscape MLOps nel 2023: Principali Strumenti e Piattaforme

Perché avere un DAG all’interno di un DAG?

Piotr: Questo è codice Python procedurale. Se ho capito correttamente, è una sorta di DAG all’interno del DAG. Ma perché abbiamo bisogno di un altro DAG all’interno di un DAG?

Stefan: Quando stai iterando sui modelli, stai aggiungendo una nuova feature, giusto?

Una nuova feature corrisponde più o meno a una nuova colonna, giusto?

Non aggiungerai un nuovo compito di Airflow solo per calcolare una singola feature a meno che non sia una sorta di feature grande e massiccia che richiede molta memoria. L’iterazione che farai sarà all’interno di quei compiti.

Riguardo alla storia di come abbiamo ideato Hamilton…

Presso Stitch Fix, dove è stato creato Hamilton – la precedente azienda in cui ho lavorato – i data scientist erano responsabili dello sviluppo end-to-end (cioè dal prototipo alla produzione e poi essere disponibili per ciò che hanno portato in produzione).

Il team faceva essenzialmente previsioni su serie temporali, dove ogni mese o ogni paio di settimane dovevano aggiornare il loro modello per aiutare a produrre previsioni per il business.

Il flusso di lavoro macro non cambiava, stavano solo cambiando ciò che era all’interno dei passaggi del compito.

Ma il team era un team molto vecchio. Avevano molto codice; molto codice legacy. Per quanto riguarda la creazione di feature, stavano creando circa mille feature.

Piotr: Mille feature?

Stefan: Sì, intendo, nelle previsioni su serie temporali, è molto facile aggiungere feature ogni mese.

Supponiamo che ci sia una spesa di marketing, o se stai cercando di modellare o simulare qualcosa. Ad esempio, il prossimo mese ci sarà una spesa di marketing, come possiamo simulare la domanda.

Quindi stavano sempre aggiungendo al codice, ma il problema era che non era stato progettato in modo adeguato. Aggiungere nuove cose era molto lento, non avevano fiducia quando aggiungevano o cambiavano qualcosa che qualcosa non si rompesse.

Piuttosto che dover avere un senior software engineer su ogni pull request per dirgli,

“Ehi, decupla le cose,”

“Ehi, avrai problemi con il modo in cui stai scrivendo,”

abbiamo ideato Hamilton, che è un paradigma in cui descrivi tutto come funzioni, dove il nome della funzione corrisponde esattamente a un output – questo perché uno dei problemi era, dato una feature, possiamo mapparla esattamente a una funzione, fare in modo che il nome della funzione corrisponda a quell’output e nei parametri della funzione dichiarare cosa è necessario per calcolarlo.

Quando vai a leggere il codice, è molto chiaro quale sia l’output e quali siano gli input. Hai la docstring della funzione perché con il codice procedurale generalmente in forma di script, non c’è un posto naturale per inserire la documentazione.

Piotr: Oh, puoi metterlo sopra la riga, giusto?

Stefan: Non è… ti trovi a fissare un muro di testo.

È più facile da capire in termini di grokking, semplicemente leggendo le funzioni se vuoi capire il flusso delle cose.

[Con Hamilton] non sei sopraffatto, hai la docstring, una funzione per la documentazione, ma poi tutto è testabile per default – non avevano una buona storia di testing.

Per quanto riguarda la distinzione tra altri framework con Hamilton, la denominazione delle funzioni e gli argomenti di input uniscono insieme un DAG o un grafo di dipendenze.

In altri framework –

Piotr: Quindi fai qualche magia sopra Python, giusto? Per capirlo.

Stefan: Esatto!

Piotr: Come funziona lavorare con esso? Gli IDE lo supportano?

Stefan: Quindi gli IDE? No. È sulla roadmap fornire più plugin, ma fondamentalmente, anziché dover annotare una funzione con un passo e specificare manualmente il flusso di lavoro dai passi, abbreviamo tutto attraverso l’aspetto della denominazione.

Quindi è un modo verboso per dire che abbiamo iniziato dal micro perché rallentava il team.

Passando a Hamilton, sono stati quattro volte più efficienti in quel compito mensile solo perché era un modo molto prescritto e semplice per aggiungere o aggiornare qualcosa.

È anche chiaro e facile sapere dove aggiungerlo alla codebase, cosa revisionare, capire gli impatti e quindi come integrarlo con il resto della piattaforma.

Come si misura se gli strumenti aggiungono valore?

Piotr: Come – e penso sia una domanda che sento a volte, specialmente dai team di piattaforme di ML e dai loro leader dove devono giustificare la loro esistenza.

Come hai gestito il team di piattaforma dati ML, come fai? Come sai se la piattaforma che stiamo costruendo, gli strumenti che forniamo ai team di data science o ai team di dati stanno apportando valore?

Stefan: Sì, in effetti, una domanda difficile, senza una risposta semplice.

Se puoi essere guidato dai dati, è il meglio. Ma la parte difficile è che le competenze delle persone differiscono. Quindi, se volessi dire, misurare quanto tempo impiega qualcuno a fare qualcosa, devi tenere conto del suo livello di esperienza, se è senior o junior.

Ma fondamentalmente, se hai abbastanza punti di dati, puoi dire qualcosa in media. Prima ci mettevano questo tempo, ora ci mettono questo tempo, quindi ottieni il rapporto e il valore aggiunto lì, e poi vuoi contare quante volte accade quella cosa. Poi puoi misurare il tempo umano e, quindi, lo stipendio e dire quanto risparmio abbiamo fatto – questo solo guardando le efficienze.

L’altro modo in cui le piattaforme di machine learning aiutano è smettendo gli incendi in produzione. Puoi guardare qual è il costo di un’interruzione e poi lavorare all’indietro tipo, “ehi, se preveniamo queste interruzioni, abbiamo anche fornito questo tipo di valore”.

Piotr: Capito.

Quali sono alcuni casi d’uso di Hamilton?

Aurimas: Forse stiamo tornando indietro di un passo…

Per me, sembra che Hamilton sia principalmente utile per l’ingegneria delle caratteristiche. Ho capito bene? O ci sono altri casi d’uso?

Stefan: Sì, lì sono radici di Hamilton. Se hai bisogno di qualcosa per aiutarti a strutturare il tuo problema di ingegneria delle caratteristiche, Hamilton è ottimo se stai lavorando in Python.

La maggior parte delle persone non ama il loro codice pandas, Hamilton ti aiuta a strutturarlo. Ma con Hamilton, funziona con qualsiasi tipo di oggetto Python.

Oggi la maggior parte delle macchine è abbastanza grande da non aver bisogno subito di Airflow, in tal caso puoi modellare il tuo flusso di lavoro di machine learning end-to-end con Hamilton.

Nel repository, abbiamo alcuni esempi di cosa puoi fare end-to-end. Penso che Hamilton sia un coltellino svizzero. Abbiamo qualcuno di Adobe che lo usa per gestire alcuni lavori di ingegneria delle prompt, ad esempio.

Abbiamo qualcuno che lo usa appositamente per l’ingegneria delle caratteristiche, ma lo usa all’interno di un’app Flask. Abbiamo altre persone che sfruttano il fatto che sia agnostico al tipo di Python e che li aiuta a orchestrare un flusso di dati per generare un oggetto Python.

Molto, molto ampio, ma le sue radici sono l’ingegneria delle caratteristiche, ma sicuramente molto facile da estendere a un modello di machine learning end-to-end leggero. È qui che siamo entusiasti delle estensioni che aggiungeremo all’ecosistema. Ad esempio, come facciamo a rendere facile per qualcuno dire, prendere Neptune e integrarlo?

Piotr: E Stefan, questa parte è interessante perché non me lo aspettavo e voglio verificare.

Aggiungeresti anche passaggi che riguardano l’addestramento di un modello, o riguarda principalmente i dati?

Stefan: No, intendo entrambi.

La cosa bella di Hamilton è che puoi esprimere logicamente il flusso dei dati. Puoi fare sorgente, creazione delle caratteristiche, creazione dell’insieme di addestramento, addestramento del modello, previsione e non hai davvero specificato i limiti del compito.

Con Hamilton, puoi definire logicamente tutto dall’inizio alla fine. In fase di esecuzione, specifichi solo cosa vuoi calcolare – calcola solo il sottoinsieme del DAG che richiedi.

Piotr: Ma cosa succede con il ciclo for dell’addestramento? Ad esempio, diciamo, 1000 iterazioni della discesa del gradiente, come funzionerebbe questo all’interno?

Stefan: Hai opzioni lì…

Vorrei dire che al momento le persone lo inseriscono nel corpo di una funzione – quindi avrai solo una funzione che racchiude quel passaggio di addestramento.

Con Hamilton, sia i principianti che gli esperti lo apprezzano perché hai la piena flessibilità di fare quello che vuoi all’interno della funzione Python. È solo un modo opinato per aiutarti a strutturare il tuo codice.

Perché Hamilton non ha un archivio delle caratteristiche?

Aurimas: Tornando a quella tabella nel tuo repository GitHub, un punto molto interessante che ho notato è che dici che non stai facendo confronti con un archivio delle caratteristiche in alcun modo.

Tuttavia, ho poi riflettuto un po’ più a fondo su questo… L’archivio delle caratteristiche serve per archiviare le caratteristiche, ma ha anche questa definizione delle caratteristiche, come le moderne piattaforme delle caratteristiche hanno anche un livello di calcolo e definizione delle caratteristiche, giusto?

In alcuni casi, non hanno nemmeno bisogno di un archivio delle caratteristiche. Potresti essere a posto semplicemente calcolando le caratteristiche sia durante l’addestramento che durante l’inferenza. Quindi ho pensato, perché Hamilton non potrebbe essere impostato per questo?

Stefan: Hai perfettamente ragione. Lo definisco come un archivio di definizione delle caratteristiche. Fondamentalmente è quello che il team di Stitch Fix ha costruito – solo sul retro di Git.

Hamilton ti costringe a separare le tue funzioni dal contesto in cui viene eseguito. Sei costretto a curare le cose in moduli.

Se vuoi costruire una banca delle caratteristiche di codice che sa come calcolare le cose con Hamilton, sei costretto a farlo – poi puoi condividere e riutilizzare quei tipi di trasformazioni delle caratteristiche in contesti diversi molto facilmente.

Ti costringe a allinearti su nomi, schema e input. Per quanto riguarda gli input di una caratteristica, devono essere denominati correttamente.

Se non hai bisogno di archiviare i dati, puoi usare Hamilton per ricalcolare tutto. Ma se hai bisogno di archiviare i dati per la cache, metti Hamilton davanti a quello in termini di utilizzare il calcolo di Hamilton e potenzialmente spingerlo verso qualcosa come FIST.

Aurimas: Ho anche visto nel sito web, non di Hamilton, ma di DAGWorks, come hai già menzionato, puoi anche addestrare modelli al suo interno nella funzione. Quindi diciamo che addestri un modello all’interno della funzione di Hamilton.

Saresti in grado di estrarre anche in qualche modo quel modello dallo storage in cui l’hai posizionato e quindi servirlo anche come funzione, o questa non è una possibilità?

Stefan: Qui è dove Hamilton è veramente leggero. Non ha opinioni sulla materializzazione. Quindi è qui che intervengono connettori o altre cose per quanto riguarda, ad esempio, dove spingi gli artefatti effettivi.

Questo è un livello leggero. Chiederesti al DAG di Hamilton di calcolare il modello, lo ottieni e quindi nella riga successiva lo salvi o lo spingi nel tuo datastore – potresti anche scrivere una funzione di Hamilton che fa questo.

L’effetto collaterale dell’esecuzione della funzione è spingerla, ma qui stiamo cercando di espandere e fornire ulteriori funzionalità per renderla più facilmente inseribile nel DAG per specificare la costruzione di un modello e quindi nel contesto in cui si desidera eseguirlo si dovrebbe specificare: “Voglio salvare il modello e posizionarlo in Neptune.”

Ecco dove stiamo andando, ma al momento, Hamilton non limita il modo in cui si desidera farlo.

Aurimas: Ma potrebbe estrarre il modello e essere utilizzato nel livello di servizio?

Stefan: Sì. Una delle caratteristiche di Hamilton è che con ogni funzione è possibile sostituire l’implementazione della funzione in base alla configurazione o a un modulo diverso.

Ad esempio, potresti avere due implementazioni della funzione: una che prende un percorso per estrarre il modello da S3, un’altra che si aspetta che il modello o i dati di addestramento vengano passati per adattare un modello.

C’è flessibilità in termini di implementazioni di funzioni e di poterle sostituire. In breve, il framework Hamilton non ha nulla di nativo per questo…

Ma abbiamo flessibilità nel modo di implementarlo.

Aurimas: In pratica, potresti fare tutto il processo, sia l’addestramento che il servizio con Hamilton.

Questo è quello che ho capito.

Stefan: Voglio dire, puoi modellare questo. Sì.

Versionamento dei dati con Hamilton

Piotr: E per quanto riguarda il versionamento dei dati? Come, diciamo, in forma semplificata.

Capisco che Hamilton si concentra più sul codice. Quando versioniamo il codice, versioniamo forse le ricette per le funzionalità, giusto?

Avendo questo, di cosa hai bisogno per dire, “sì, abbiamo dataset con versioni?”

Stefan: Sì, hai ragione. Con Hamilton, descrivi i tuoi dati per codificarli. Se li archivi in Git o hai un modo strutturato per versionare i tuoi pacchetti Python, puoi tornare indietro in qualsiasi momento e capire l’esatta genealogia del calcolo.

Ma dove risiedono i dati di origine e qual è l’output, in termini di versionamento del dataset, dipende da te (ad esempio, la tua fedeltà a ciò che desideri archiviare e catturare).

Se usassi Hamilton per creare un qualche tipo di dataset o trasformare un dataset, archivieresti quel dataset da qualche parte. Se archiviassi il Git SHA e la configurazione che hai usato per istanziare il DAG di Hamilton, e li archiviassi con quell’artefatto, potresti sempre tornare indietro nel tempo per ricrearlo, a condizione che i dati di origine siano ancora disponibili.

Questo è ciò che abbiamo costruito nella piattaforma di Stitch Fix, Hamilton, abbiamo questi hook, o almeno la possibilità di integrarli. Ora, questo fa parte della piattaforma DAGWorks.

Cerchiamo di fornire precisamente un mezzo per archiviare e catturare quei metadati aggiuntivi per te, in modo che tu non debba costruire quel componente in modo che poi possiamo collegarlo ad altri sistemi che potresti avere.

A seconda delle dimensioni, potresti avere un catalogo dei dati. Puoi anche archiviare ed emettere informazioni di lineage aperte, ecc. con quello.

Certamente, cerchiamo idee o stack precoci con cui integrarci, ma per il resto, non siamo di parte. Dove possiamo aiutare con il versionamento del dataset è non solo versionare i dati, ma se sono descritti in Hamilton, puoi ricomputarli esattamente perché conosci il percorso del codice che è stato utilizzato per trasformare le cose.

Quando hai deciso che Hamilton doveva essere creato?

Aurimas: Forse tornando un po’ a quello che hai fatto in Stitch Fix e a Hamilton stesso.

Quando hai deciso che Hamilton doveva essere creato?

Stefan: Nel 2019.

Abbiamo reso Hamilton open source solo 18 mesi fa. Non è una nuova libreria, è stata utilizzata in Stitch Fix per oltre tre anni.

La parte interessante per Stitch Fix è che era un’organizzazione di data science con oltre 100 data scientist con varie discipline di modellazione che facevano varie cose per l’azienda.

Facevo parte del team di piattaforma che si occupava di ingegneria per la data science. Il mandato del mio team era semplificare la produzione di modelli per i team.

Pensavamo, “come possiamo abbassare la soglia dell’ingegneria del software?”

La risposta è stata fornire loro le astrazioni degli strumenti e le API in modo tale che non fossero costretti a essere bravi ingegneri del software – le migliori pratiche di MLOps sono praticamente fornite gratuitamente.

C’era un team che stava lottando e il manager è venuto da noi per parlare. Era tipo, “Questo codice è terribile, abbiamo bisogno di aiuto, puoi proporre qualcosa? Voglio dare priorità alla documentazione e ai test e se puoi migliorare il nostro flusso di lavoro, sarebbe fantastico”, che sono essenzialmente i requisiti, giusto?

Da Stitch Fix, stavamo pensando a “qual è l’esperienza utente finale o l’API definitiva dal punto di vista dell’interazione tra la piattaforma e lo scienziato dei dati?”

Credo che le funzioni Python non siano un’interfaccia orientata agli oggetti che qualcuno deve implementare – dammi solo una funzione e c’è abbastanza metaprogrammazione che puoi fare con Python per ispezionare la funzione e conoscerne la struttura, conoscere gli input e gli output, hai le annotazioni di tipo, eccetera.

Quindi, un punto in più per il lavoro da casa il mercoledì. Stitch Fix aveva un giorno senza riunioni, ho messo da parte un’intera giornata per pensare a questo problema.

Ero tipo, “come posso assicurarmi che tutto sia testabile, friendly alla documentazione e che il DAG e il flusso di lavoro siano di per sé esplicativi e facili da descrivere?”

In tal caso, ho prototipato Hamilton e l’ho portato al team. Il mio attuale co-fondatore, ex collega di Stich Fix, Elijah, ha anche proposto una seconda implementazione, che era simile a un approccio di tipo DAG.

Al team è piaciuta la mia implementazione, ma fondamentalmente la premessa di rendere tutto testabile a livello unitario, friendly alla documentazione e avere una buona storia di testing di integrazione.

Con il codice di data science, è molto facile aggiungere molto codice agli stessi script e cresce e cresce e cresce. Con Hamilton, è molto facile. Non devi calcolare tutto per testare qualcosa – questo faceva parte del pensiero di costruire un DAG in modo che Hamilton sappia solo percorrere i percorsi necessari per le cose che vuoi calcolare.

Ma questa è approssimativamente la storia dell’origine.

Ho migrato il team e li ho inseriti. Le pull request finiscono per essere più veloci. Al team piace molto. Sono molto fedeli. Amano il paradigma perché ha sicuramente semplificato la loro vita rispetto a prima.

Utilizzare Hamilton per Deep Learning e dati tabulari

Piotr: In precedenza hai detto che hai lavorato su oltre 1000 caratteristiche create manualmente, giusto?

Diresti che Hamilton è più utile nel contesto dei dati tabulari o può essere utilizzato anche per dati di tipo deep learning in cui hai molte caratteristiche ma non sviluppate manualmente?

Stefan: Sicuramente. Le radici e i punti di forza di Hamilton provengono dal cercare di gestire e creare dati tabulari per l’input di un modello.

Il team di Stich Fix gestisce oltre 4000 trasformazioni di caratteristiche con Hamilton. E voglio dire –

Piotr: Per un solo modello?

Stefan: Per tutti i modelli che creano, collettivamente nello stesso codice, hanno 4000 trasformazioni di caratteristiche che possono aggiungere e gestire, e non rallenta loro.

Per quanto riguarda gli altri tipi, direi “sì”. Hamilton sta sostanzialmente sostituendo parte dell’ingegneria del software che fai. Dipende molto da quello che devi fare per unire un flusso di dati da trasformare per il tuo caso d’uso di deep learning.

Alcune persone hanno detto, “oh, Hamilton assomiglia un po’ a LangChain.” Non ho guardato LangChain, che so essere qualcosa che le persone stanno usando per unire grandi modelli. Quindi, non sono ancora sicuro esattamente dove pensano che sia la somiglianza, ma altrimenti, se hai del codice procedurale che stai usando con encoder, probabilmente c’è un modo in cui puoi trascriverlo e usarlo con Hamilton.

Una delle caratteristiche di Hamilton è che ha un controllo di runtime di qualità dei dati molto leggero. Se controllare l’output di una funzione è importante per te, abbiamo un modo estensibile per farlo.

Se stai usando dati tabulari, c’è Pandera. È una libreria popolare per descrivere lo schema – abbiamo il supporto per quello. Altrimenti, abbiamo un modo flessibile in cui, se stai usando altri tipi di oggetti o tensori o qualcosa del genere, abbiamo la possibilità di estendere per garantire che il tensore soddisfi determinati standard che ti aspetti.

Piotr: Vorresti anche calcolare alcune statistiche su una colonna o su un insieme di colonne, diciamo, utilizzando Hamilton come framework per testare i set di dati?

Non sto parlando di verificare un valore specifico in una colonna, ma piuttosto della distribuzione statistica dei tuoi dati.

Stefan: La bellezza di tutto ciò che sono funzioni Python e che il framework di Hamilton le esegue è che abbiamo flessibilità rispetto all’output di una funzione, che si rivela essere un dataframe.

Sì, potremmo inserire qualcosa nel framework che prenda le statistiche di riepilogo e le restituisca. Sicuramente, è qualcosa con cui stiamo sperimentando.

Piotr: Quando si tratta di una combinazione di colonne, ad esempio, diciamo che si desidera calcolare alcune correlazioni statistiche tra tre colonne, come si adatta a questo paradigma di rappresentazione di una colonna?

Stefan: Dipende se vuoi che sia una trasformazione effettiva.

Potresti semplicemente scrivere una funzione che prenda l’input o l’output di quel dataframe e nel corpo della funzione lo faccia – in pratica, puoi farlo manualmente.

Dipende davvero se vuoi che sia se lo stai facendo da una prospettiva di piattaforma e vuoi consentire ai data scientist di catturare automaticamente varie cose, allora io proporrei di adottare un approccio di piattaforma cercando di aggiungere un decorator che avvolge la funzione e quindi può descrivere e fare l’ispezione che si desidera.

Perché hai reso Hamilton open-source?

Piotr: Torno alla storia di Hamilton che è iniziata a Stitch Fix. Qual è stata la motivazione per renderlo open-source?

È una cosa curiosa per me perché sono stato in alcune aziende e ci sono sempre alcune librerie e progetti interni che piacevano, ma sì, non è così semplice e non ogni progetto è il candidato giusto per diventare open e essere veramente utilizzato.

Non sto parlando di aggiungere un file di licenza e rendere il repository pubblico, ma sto parlando di renderlo vivo e veramente aperto.

Stefan: Sì. Il mio team aveva una visione in termini di costruire o comprare, stavamo guardando un po’ in tutto lo stack e vedevamo che abbiamo creato Hamilton nel 2019 e stavamo vedendo cose molto simili che venivano pubblicate come open-source – abbiamo pensato, “hey, penso che abbiamo un angolo unico”. Degli altri strumenti che avevamo, Hamilton era il più facile da rendere open-source.

Per chi lo sa, Stitch Fix era molto attento al branding. Se vuoi conoscere alcune storie interessanti su tecniche e cose del genere, puoi cercare il blog Multithreaded di Stitch Fix.

C’era un team di branding tecnologico di cui facevo parte, che cercava di produrre contenuti di qualità. Ciò aiutava il brand di Stitch Fix, che aiutava nelle assunzioni.

In termini di motivazioni, questa è la prospettiva del branding; stabilire un alto standard di qualità e portare cose che appaiono bene per il brand.

E proprio così, dalla nostra prospettiva e dal punto di vista del nostro team, Hamilton era il più facile da rendere open-source tra le cose che facevamo, e poi penso che fosse più interessante.

Abbiamo costruito cose come pipeline di modelli basate su configurazione, simili a MLflow, ma voglio dire che non è così unico. Hamilton è anche un angolo più unico su un problema specifico. E quindi in entrambi i casi, era come dire, “sì, penso che questa sia una buona opportunità di branding”.

E poi, in termini di superficie della libreria, è abbastanza piccola. Non hai bisogno di molte dipendenze, il che la rende fattibile da mantenere da un punto di vista open-source.

I requisiti erano anche relativamente bassi, dal momento che hai solo bisogno di Python 3.6 – ora che 3.6 è sunset, ora è 3.7, e funziona perfettamente.

Da quella prospettiva, penso che avesse un buon punto di equilibrio, probabilmente non sarebbe stato necessario aggiungere troppe cose per aumentare l’adozione, renderlo utilizzabile dalla comunità, ma anche l’aspetto della manutenzione era relativamente piccolo.

L’ultima parte era un po’ sconosciuta; “quanto tempo avremmo trascorso cercando di costruire una comunità?” Non potevo sempre dedicare più tempo a questo, ma questa è un po’ la storia di come l’abbiamo reso open-source.

Ho appena trascorso un buon paio di mesi cercando di scrivere un post sul blog per il lancio, ci ho impiegato un po’ di tempo, ma è sempre un buon modo per mettere giù i pensieri e articolare le idee in modo chiaro.

Lanciare un prodotto open-source

Piotr: Come è stato il lancio in termini di adozione da parte degli utenti esterni? Puoi condividere con noi come lo hai promosso? Ha funzionato fin dal primo giorno o ci ha messo un po’ di tempo per diventare più popolare?

Stefan: Fortunatamente, Stitch Fix aveva un blog con un numero ragionevole di lettori. Ho abbinato quello con il mio blog, e in pochi mesi ho ottenuto un paio di centinaia di stelle. Abbiamo una community su Slack a cui puoi unirti.

Non ho un punto di riferimento per dire quanto è andato bene rispetto ad altro, ma le persone lo stanno adottando anche al di fuori di Stitch Fix. Il Governo Digitale del Regno Unito sta utilizzando Hamilton per un flusso di feedback nazionale.

C’è una persona che lo sta usando internamente presso IBM per uno strumento di ricerca interna di piccole dimensioni. Il problema con l’open-source è che non sai chi ti sta utilizzando in produzione, poiché la telemetria e altre cose sono difficili. Le persone sono arrivate, hanno creato problemi, hanno fatto domande, il che ci ha dato più energia per essere presenti e aiutare.

Piotr: E per quanto riguarda il primo pull request, il primo pull request utile proveniente da utenti esterni?

Stefan: Abbiamo avuto la fortuna che un ragazzo di nome James Lamb si è unito al progetto. Ha partecipato a diversi progetti open-source e ci ha aiutato con la documentazione e la struttura del repository.

In pratica, ha fatto un lavoro di pulizia e reso più facile per un collaboratore esterno eseguire i nostri test e cose del genere. Voglio dire, è stato un lavoro duro, ma estremamente prezioso a lungo termine, perché ci ha dato un feedback del tipo: “Ehi, questo template per il pull request è troppo lungo. Come possiamo abbreviarlo?” – “Spaventi i contributori.”

Ci ha dato alcuni buoni consigli e ci ha aiutato a impostare meglio la struttura. È l’igiene del repository che permette agli altri di contribuire più facilmente.

Le sfide più grandi di Stitch Fix

Aurimas: Sì, quindi forse torniamo un po’ al lavoro che hai svolto presso Stitch Fix. Hai detto che Hamilton è stato il più facile da rendere open-source, giusto? Se ho capito bene, hai lavorato su molte altre cose oltre a quello, non solo sul flusso di lavoro.

Puoi spiegare un po’ quali erano i problemi più grandi di Stitch Fix e come hai cercato di risolverli come piattaforma?

Stefan: Sì, potresti pensare, torna indietro di sei anni, giusto? Non c’erano molte cose open-source disponibili. Da Stitch Fix, se gli scienziati dei dati dovevano creare un’API per il modello, dovevano occuparsi di avviare la propria immagine su EC2 che eseguisse un’app Flask che integrasse le cose.

Abbiamo iniziato aiutando dal punto di vista della produzione, stabilizzando e migliorando le pratiche. Abbiamo aiutato una squadra che ha reso più facile distribuire backend su FastAPI, in cui gli scienziati dei dati dovevano solo scrivere funzioni Python come punto di integrazione.

Questo ha contribuito a stabilizzare e standardizzare tutti i microservizi di backend perché la piattaforma ora gestiva il vero e proprio servizio web.

Piotr: Quindi stai fornendo loro un’interfaccia Lambda?

Stefan: Potresti dire un po’ più pesante. In pratica, abbiamo reso loro facile fornire un requirements.txt, una base con immagine Docker e diciamo il repository Git dove risiedeva il codice, e poter creare un contenitore Docker con il servizio web, con il codice costruito e successivamente distribuirlo su AWS in modo piuttosto semplice.

Aurimas: Forse sto sentendo dei repository di template? O li hai chiamati in modo diverso qui?

Stefan: Non erano template veri e propri, ma c’erano solo alcune cose che le persone dovevano fare per creare un microservizio e distribuirlo. Una volta fatto ciò, abbiamo esaminato le varie parti del flusso di lavoro.

Uno dei problemi era la serializzazione del modello e “come sai quale versione di un modello sta girando in produzione?” Quindi abbiamo sviluppato un piccolo progetto chiamato “model envelope”, dove l’idea era fare di più, un po’ come la metafora di una busta, puoi metterci dentro le cose.

Per esempio, puoi inserire il modello, ma puoi anche inserire molti metadati e informazioni extra su di esso. Il problema della serializzazione del modello è che hai bisogno di dipendenze Python abbastanza esatte, altrimenti puoi incorrere in problemi di serializzazione.

Se ricarichi i modelli al volo, puoi incontrare problemi se qualcuno ha caricato un modello difettoso o se non è facile tornare indietro. Uno dei modi in cui le cose funzionano in Stitch Fix – o come funzionavano – era che se veniva rilevato un nuovo modello, veniva semplicemente ricaricato automaticamente.

Ma questo era un po ‘una sfida dal punto di vista operativo per tornare indietro o testare le cose prima. Con l’astrazione dell’involucro del modello, l’idea era quella di salvare il modello e poi fornire una qualche configurazione e un’interfaccia utente, e quindi potremmo fornire un nuovo modello, distribuire automaticamente un nuovo servizio, dove ogni build del modello era un nuovo contenitore Docker, quindi ogni servizio era immutabile.

E ciò forniva costrutti migliori per spingere qualcosa in produzione, facilitando il rollback, quindi abbiamo semplicemente cambiato il contenitore. Se volessi debuggare qualcosa, potevi semplicemente estrarre quel contenitore e confrontarlo con qualcosa che stava girando in produzione.

Questo ci ha anche permesso di inserire un tipo di pipeline CI/CD senza doverla inserire nelle pipeline dei modelli perché i framework comuni hanno, alla fine della pipeline di modelli di apprendimento automatico di qualcuno, controlli CI/CD per qualificare un modello.

In qualche modo abbiamo astratto quella parte e l’abbiamo resa qualcosa che le persone potevano aggiungere dopo aver creato una pipeline di modelli. In questo modo era più facile apportare modifiche e aggiornamenti, e quindi la pipeline del modello non avrebbe dovuto essere modificata se, ad esempio, c’era un bug e si voleva creare un nuovo test o qualcosa del genere.

E quindi è più o meno così. L’involucro del modello era il suo nome. Aiutava gli utenti a costruire un modello e metterlo in produzione in meno di un’ora.

Avevamo anche l’equivalente per il lato batch. Di solito, se si vuole creare un modello e quindi eseguirlo in un batch da qualche parte, si dovrebbe scrivere il task. Avevamo strumenti per far funzionare un modello in Spark o su un’unità di elaborazione di grandi dimensioni.

Le persone non avrebbero dovuto scrivere quel task di batch per eseguire una previsione di batch. Perché a un certo livello di maturità all’interno di un’azienda, si inizia ad avere team che vogliono riutilizzare i modelli di altri team. In questo caso, eravamo il collegamento tra loro, aiutando a fornire un modo standard per permettere alle persone di prendere il modello di qualcun altro ed eseguirlo in batch senza doverne conoscere molto.

Serializzazione dei modelli nella piattaforma di Stitch Fix

Piotr: E Stefan, parlando della serializzazione di un modello, hai anche serializzato la pre e post-elaborazione delle caratteristiche in questo modello? Come, dove hai stabilito un confine?

Ad esempio, e secondo, molto collegato, come hai descritto la firma di un modello? Ad esempio, supponiamo che sia un API RESTful, giusto? Come hai fatto questo?

Stefan: Quando qualcuno salvava il modello, doveva fornire un puntatore a un oggetto con il nome della funzione, o fornivano una funzione.

Avremmo usato quella funzione, l’avremmo ispezionata e come parte dell’API di salvataggio del modello, chiedevamo quali fossero i dati di addestramento di input, qual era l’output di esempio? Così potevamo effettivamente testare un po ‘il modello quando lo stavamo salvando per ispezionare un po’ di più l’API. Quindi, se qualcuno avesse passato un dataframe di dati aggiuntivi, avremmo detto: “Ehi, devi fornire alcuni dati di esempio per questo dataframe in modo da poter capire, ispezionare e creare la funzione.”

Da questo, avremmo quindi creato uno schema Pydantic sul lato del servizio web. Quindi, se usi FastAPI, puoi andare alla pagina delle documentazioni e avrai un’interfaccia REST facile da eseguire che ti dirà quali caratteristiche sono necessarie per eseguire questo modello.

Quindi, per quanto riguarda ciò che è stato assemblato in un modello, dipendeva davvero da, dato che stavamo semplicemente, sai, cercando di trattare Python come una scatola nera per quanto riguarda i confini di serializzazione.

Il confine era davvero, sai, sapere cosa c’era nella funzione. Le persone potevano scrivere una funzione che includeva la featurizzazione come primo passo prima di delegare al modello, oppure avevano l’opzione di tenerli separati e in tal caso, al momento della chiamata, dovevano andare prima al feature store per ottenere le caratteristiche corrette che poi sarebbero state passate alla richiesta per calcolare una previsione nel servizio web.

Quindi non abbiamo opinioni definitive su dove fossero i confini, ma era qualcosa a cui stavamo cercando di tornare, per cercare di standardizzare un po’ di più noi stessi, dato che i diversi casi d’uso hanno diversi SLA, hanno diverse esigenze, a volte ha senso unire insieme, a volte è più facile pre-calcolare e non hai bisogno di collegarlo al modello.

Piotr: E l’interfaccia per il data scientist, per costruire un tale modello e serializzare questo modello, era in Python, come se non stessero lasciando Python. È tutto in Python. E mi piace questa idea di fornire, diciamo, input di esempio, output di esempio. È molto, direi, il modo in cui Python fa le cose. Come il testing delle unità, è così che ci assicuriamo che la firma sia mantenuta.

Stefan: Sì, e quindi da quello, in realtà da quell’input e output di esempio, idealmente, era anche il set di addestramento. E quindi è qui che potevamo, sai, pre-calcolare le statistiche di riepilogo, come dicevi. E quindi ogni volta che qualcuno salvava un modello, cercavamo di fornire, sai, cose gratuite.

Non dovevano pensare, sai, all’osservabilità dei dati, ma guarda, se fornivi quei dati, noi acquisivamo informazioni a riguardo. Quindi, se c’era un problema, potevamo avere una traccia di briciole per aiutarti a determinare cosa è cambiato, se era qualcosa riguardo ai dati, o era, guarda, hai incluso una nuova dipendenza Python, giusto?

E questo cambia qualcosa, giusto? E quindi, ad esempio, abbiamo anche ispezionato l’ambiente in cui venivano eseguite le cose. Quindi, potevamo capire cosa c’era a livello di pacchetto.

E quindi, quando abbiamo eseguito la produzione del modello, abbiamo cercato di replicare il più possibile quelle dipendenze per garantire che, almeno da un punto di vista di ingegneria del software, tutto dovesse funzionare come previsto.

Piotr: Quindi sembra che l’impacchettamento del modello, è così che viene chiamato oggi, sia una soluzione. E dove hai conservato quelle buste. Ho capito che avevi una busta strutturata, ma avevi istanze di quelle buste che erano modelli serializzati con metadati. Dove le hai conservate?

Stefan: Sì. Voglio dire, abbastanza basilare, potresti dire S3, quindi le abbiamo conservate in modo strutturato su S3, ma sai, abbiamo abbinato questo a un database che aveva i metadati e il puntatore effettivo. Quindi alcuni metadati andavano al database, così potevi usarli per interrogare.

Avevamo un intero sistema in cui ogni busta, specificavi dei tag. In questo modo, potevi organizzare gerarchicamente o fare query in base alla struttura dei tag che hai incluso con il modello. E quindi era solo un campo nella riga.

C’era un campo che era solo indicato, tipo, hey, qui è dove vive l’artefatto serializzato. E quindi sì, piuttosto semplice, niente di troppo complesso lì.

Come decidere quale funzionalità sviluppare?

Aurimas: Ok, Stefan, quindi sembra che tutto… fosse davvero naturale nel team della piattaforma. Quindi i team dovevano distribuire modelli, giusto? Quindi hai creato il framework della busta, poi i team stavano lottando per definire il codice di sezione in modo efficiente, hai creato Hamilton.

C’è stato qualche caso in cui qualcuno è venuto da te con una proposta folle che doveva essere sviluppata e tu hai detto di no? Come decidi quale funzionalità deve essere sviluppata e quali funzionalità hai respinto?

Stefan: Sì. Ho un articolo sul mio blog su alcune delle mie esperienze nel costruire la piattaforma in Stitch Fix. E quindi, si potrebbe dire che di solito quelle richieste a cui abbiamo detto “no” provenivano da qualcuno che voleva qualcosa di super complesso, ma stavano anche facendo qualcosa di speculativo.

Volevano la possibilità di fare qualcosa, ma non era ancora in produzione, e stava cercando di fare qualcosa di speculativo basato sul miglioramento di qualcosa dove il valore aziendale non era ancora noto.

A meno che non fosse una priorità aziendale e sapevamo che questa era una direzione che doveva essere seguita, avremmo detto, certo, ti aiuteremo un po’ con quello. Altrimenti, avremmo semplicemente detto di no, di solito queste richieste arrivano da persone che pensano di essere abbastanza capaci dal punto di vista dell’ingegneria.

Quindi abbiamo detto: va bene, tu vai a capire come farlo, e se funziona, possiamo discutere di proprietà e di prenderlo. Ad esempio, avevamo un modello di pipeline basato sulla configurazione – potresti pensare a qualche YAML con del codice Python, e in SQL, abbiamo permesso alle persone di descrivere come costruire una pipeline di modelli in quel modo.

Quindi diverso da Hamilton, in modo più macro, e quindi non volevamo supportarlo subito, ma è cresciuto in un modo che altre persone volevano adottarlo, e quindi in termini di complessità di gestirlo, mantenerlo, siamo intervenuti, l’abbiamo rifattorizzato, reso più generale, più ampio, giusto?

Ecco quindi dove vedo un modo ragionevole per determinare se dire sì o no, uno, se non è una priorità aziendale, probabilmente non vale la pena dedicare tempo ad esso e farli dimostrare che funziona, e poi se ha successo, assumendo che hai avuto la conversazione in anticipo, puoi parlare di adozione.

Quindi, non è il tuo fardello. A volte le persone si affezionano. Devi solo essere consapevole del loro attaccamento, se è il loro progetto, sai, come te lo passeranno. È una cosa da considerare.

Ma altrimenti, sto cercando di pensare che alcune persone volevano il supporto di TensorFlow – il supporto specifico di TensorFlow, ma era solo una persona che usava TensorFlow. Erano tipo, “sì, puoi fare cose adesso, sì, possiamo aggiungere alcune cose”, ma per fortuna non abbiamo investito il nostro tempo perché il progetto che hanno provato non ha funzionato e alla fine se ne sono andati.

E quindi, in quel caso, sono contento di non aver investito tempo lì. Quindi, sì, sono felice di approfondire di più.

Piotr: Sembra molto simile al ruolo di product manager.

Stefan: Sì, a Stitch Fix non avevamo product manager. L’organizzazione aveva un program manager. Il mio team era i nostri stessi product manager. Ecco perché ho dedicato parte del mio tempo a cercare di parlare con le persone, i manager, a capire i punti critici, ma anche a capire cosa sarebbe stato prezioso per il business e dove dovremmo dedicare tempo.

Piotr:

Sto gestendo un prodotto presso Neptune, ed è una cosa buona e allo stesso tempo impegnativa che stai lavorando con persone tecnicamente abili, sono ingegneri, sanno programmare, sanno pensare in modo astratto.

Molto spesso, quando senti la prima iterazione nella richiesta di una funzionalità, in realtà è una soluzione. Non senti il problema. Mi piace questo test, e forse altri team delle piattaforme di apprendimento automatico possono imparare da esso. È in produzione?

È qualcosa che funziona, o è qualcosa che pianifichi di spostare in produzione un giorno? Come primo filtro, mi piace questa euristica.

Stefan: Voglio dire, hai riportato alla mente molte cose, tipo, c’è hey, puoi fare questo? Quindi qual è il problema? Sì, in effetti, quella è, quella è la prima cosa che devi imparare a fare ogni volta che qualcuno che sta usando la tua piattaforma chiede è come, qual è il problema effettivo? Potrebbe essere che hanno trovato un martello e vogliono usare quel particolare martello per quel particolare compito.

Ad esempio, vogliono fare l’ottimizzazione degli iperparametri. Lo stavano chiedendo, tipo, “puoi farlo in questo modo?” E, guardando la situazione, diciamo, hey, possiamo farlo a un livello leggermente più alto, quindi non dovrai pensarci, non dovremmo ingegnerizzarlo. E quindi, in tal caso, la domanda “qual è il problema effettivo che stai cercando di risolvere?” è una domanda estremamente importante da porre sempre.

E poi puoi anche chiedere, “qual è il valore commerciale?” Quanto è importante questo, eccetera, per sapere realmente come prioritizzare?

Ottenere l’approvazione del team

Piotr: Quindi abbiamo imparato come hai gestito i data scientist che si rivolgevano a te per le funzionalità. Come ha funzionato la seconda parte della comunicazione, come hai incoraggiato o fatto seguire alle persone, ai team ciò che hai sviluppato, ciò che hai proposto loro di fare? Come hai stabilito gli standard nell’organizzazione?

Stefan: Sì, idealmente, con ogni iniziativa che avevamo, trovavamo un caso d’uso specifico, un caso d’uso limitato e una squadra che ne aveva bisogno e che lo avrebbe adottato e usato quando lo sviluppavamo. Non c’è niente di peggio che sviluppare qualcosa e nessuno lo usa. Fa una brutta impressione, i manager chiedono, chi lo sta usando?

• Quindi, si sta garantendo che tu abbia un caso d’uso chiaro e qualcuno che abbia bisogno e voglia collaborare con te. E solo una volta che ciò è riuscito, inizi a pensare ad ampliarlo. Perché, in primo luogo, puoi usarli come caso d’uso e storia. Questo è il luogo ideale dove si hanno riunioni settimanali o bisettimanali. Quindi avevamo quello che chiamavamo “algoritmi”, potrei dire un minuto di pausa, dove essenzialmente potevi alzarti per un paio di minuti e parlare di cose.

• E quindi sì, abbiamo sicuramente dovuto fare l’evangelizzazione degli strumenti di sviluppo internamente perché da Stitch Fix, non erano gli scienziati dei dati a decidere se utilizzare o meno i nostri strumenti, se volevano ingegnerizzare le cose da soli. Quindi abbiamo dovuto sicuramente seguire la strada del prendere questi punti critici da te. Non devi pensarci. Ecco cosa abbiamo costruito. Ecco qualcuno che lo sta usando, e lo sta usando per questo caso d’uso specifico. Penso che quindi la consapevolezza sia una cosa importante, giusto? Devi assicurarti che le persone sappiano della soluzione, che sia un’opzione.
• Documentazione, quindi in realtà avevamo un piccolo strumento che consentiva di scrivere facilmente documenti Sphinx. Quindi era qualcosa che ci siamo assicurati di avere per ogni tipo di modello, altro strumento che abbiamo costruito, Hamilton, avevamo una configurazione di documentazione Sphinx in modo tale che, se le persone volevano, potessimo indirizzarle alla documentazione, cercando di mostrare esempi e cose del genere.

• L’altro è, dalla nostra esperienza, la telemetria che abbiamo inserito. Quindi una cosa interessante della piattaforma è che possiamo inserire quanta telemetria vogliamo. Quindi effettivamente, quando tutti stavano usando qualcosa, e c’era un errore, ricevevamo un avviso Slack. E quindi cercavamo di stare al passo con quello e chiedere loro “cosa state facendo?”.

Magari cercavamo di coinvolgerli per assicurarci che avessero successo nel fare le cose correttamente. Questo non è possibile con il software open-source. Purtroppo, è leggermente invasivo. Ma in ogni caso, la maggior parte delle persone è disposta ad adottare cose solo un paio di volte al trimestre.

Quindi è solo una questione di avere la cosa nel posto giusto, al momento giusto perché loro possano iniziare e superare l’ostacolo, dato che iniziare è la sfida più grande. E quindi, cercare di trovare documentazione, esempi e modi per rendere quel passaggio il più piccolo possibile.

Come hai formato un team per creare la piattaforma?

Aurimas: Ok, quindi sei stato in Stitch Fix fin dall’inizio della piattaforma di apprendimento automatico, o è evoluta fin dall’inizio, giusto?

Stefan: Sì, quindi quando sono arrivato lì, era un team abbastanza piccolo e di base. Negli anni in cui sono stato lì, è cresciuto parecchio.

Aurimas: Sai come è stata creata? Perché è stato deciso che era il momento giusto per avere effettivamente un team di piattaforma?

Stefan: No, non conosco la risposta a questa domanda, ma i due ragazzi che avevano la supervisione, Eric Colson e Jeff Magnusson.

Jeff Magnusson ha un post abbastanza famoso che dice che gli ingegneri non dovrebbero scrivere ETL. Se lo cerchi su Google, vedrai questo post che descrive la filosofia di Stitch Fix, dove volevamo creare scienziati dei dati full stack, in modo che se possono fare tutto da un capo all’altro, possono fare le cose più velocemente e meglio.

Ma con questa tesi, c’è un certo limite di scala che non puoi superare. È difficile assumere tutti quelli che hanno tutte le competenze per fare tutto full stack, sai, data science, giusto? E quindi, in tal caso, è stata davvero la loro visione che diceva “un team di piattaforma per costruire strumenti di leva, giusto?”

Penso che, non so che dati hai, ma la mia conoscenza superficiale sui progetti di machine learning in generale è che c’è un rapporto di un ingegnere per un data scientist di 1:1 o 1:2. Ma da Stitch Fix, il rapporto sicuro, se consideriamo solo l’ingegneria, il team di piattaforma che si concentrava nell’aiutare i flussi di lavoro, giusto?

Il rapporto era più vicino a 1:10. E quindi in termini di leva, come gli ingegneri possono sfruttare ciò che i data scientist possono fare, penso che ci sia un po’ di bisogno di capire cosa fa una piattaforma adesso, e poi devi anche sapere come comunicarlo.

Quindi, dato il tuo precedente quesito, Piotr, su come si misura l’efficacia dei team di piattaforma, nel qual caso, non so quali conversazioni abbiano avuto per ottenere un certo numero di persone, quindi potresti avere bisogno di un po’ di aiuto o almeno di pensare in termini di comunicare che sì, questo team sarà di secondo ordine perché non andremo ad influire direttamente e a produrre una funzionalità, ma se riusciamo a rendere più efficaci ed efficienti le persone che lo fanno, allora sarà un investimento valido.

Aurimas: Quando dici ingegneri e data scientist, intendi che un Machine Learning Engineer è un ingegnere oppure è più un data scientist?

Stefan: Sì, li conto, la distinzione tra un data scientist e un machine learning engineer potresti dire che uno, forse potresti dire che ha una connotazione che fa un po’ più di cose online, giusto?

E quindi hanno bisogno di fare un po’ più di ingegneria. Ma penso che ci sia un divario piuttosto piccolo. Per me, in realtà, la mia speranza è che quando le persone usano Hamilton, li abilitiamo a fare di più, possono effettivamente cambiare il titolo da data scientist a machine learning engineer.

Altrimenti, li inserisco nella categoria dei data scientist a tal proposito. Quindi la progettazione della piattaforma era specificamente di ciò di cui stavo parlando.

Aurimas: Ok. E hai visto qualche evoluzione nella struttura dei team nel corso degli anni in Stitch Fix? Hai cambiato la composizione di questi team di machine learning end-to-end composti da data scientist e ingegneri?

Stefan: Dipendeva molto dal loro problema, perché i team di previsione erano molto di tipo offline. Funzionavano bene, non dovevano sapere, ingegnerizzare nulla di troppo complesso da un punto di vista online.

Ma di più per i team di personalizzazione, dove le SLA e le cose legate al cliente iniziarono a contare, decisero di assumere persone con un po’ più di esperienza in quel campo, poiché aiutavano molto, come noi non stiamo ancora affrontando questo, direi, ma con DAGWorks stiamo cercando di abbassare la soglia di ingegneria del software per costruire e mantenere i flussi di modelli.

Non direi che il sistema di raccomandazione e la produzione di raccomandazioni online siano semplificati, quindi in tal caso, hai ancora bisogno di una solida competenza in ingegneria per assicurarti che nel tempo, se stai gestendo molti microservizi che si parlano tra loro o stai gestendo SLA, hai bisogno di un po’ più di conoscenza in ingegneria per far bene.

Quindi, in tal caso, se posso dire, è stata la divisione che ha cominciato a fondersi. Chiunque si occupi di SLA rivolte al cliente, richiede un po’ più di competenze in ingegneria del software, altrimenti tutti sono in grado di essere ottimi modellatori con competenze inferiori in ingegneria del software.

Aurimas: E per quanto riguarda i ruoli che non sono necessariamente tecnici, li includereste in questi team di ML come project manager o esperti di materia? O sono solo data scientist?

Stefan: Voglio dire, in parte ricadeva sul team di data scientist per trovare un partner, con chi si stanno associando, giusto, e quindi in generale si stavano associando con qualcuno all’interno dell’organizzazione, nel qual caso, si potrebbe dire che collettivamente tra i due stanno gestendo un prodotto, quindi non avevamo ruoli espliciti di product manager.

Credo che a questa scala, quando Stitch Fix ha cominciato a crescere, la gestione dei progetti era un punto critico, tipo: come possiamo introdurlo, chi lo fa? Quindi dipende molto dalla scala.

Il prodotto è ciò che stai facendo, a cosa si sta toccando, è come se iniziassi a averne bisogno. Ma sì, sicuramente era qualcosa di cui l’organizzazione stava pensando quando ero ancora lì, come strutturare le cose per funzionare in modo più efficiente ed efficace? E, tipo, come disegni esattamente i confini di un team che offre machine learning?

Se stai lavorando con il team di inventario, che gestisce l’inventario in un magazzino, ad esempio, qual è la struttura del team che si sta formando lì, è ancora in fase di definizione, giusto? Quando ero lì, era molto separato. Ma lavoravano insieme, ma avevano diversi responsabili, giusto?

Tipo di rapporto tra di loro, ma hanno lavorato sulla stessa iniziativa. Quindi, funzionava bene quando eravamo piccoli. Dovresti chiedere a qualcuno là adesso riguardo a cosa sta succedendo, ma altrimenti direi che dipende dalla dimensione dell’azienda e dall’importanza dell’iniziativa di machine learning.

Monitoraggio del modello e produzione

Piotr: Volevo chiedere del monitoraggio dei modelli e della produzione, renderli attivi. Perché sembra abbastanza simile allo spazio del software, va bene? I data scientist sono qui con gli ingegneri del software. Il team della piattaforma di machine learning può essere per questo team DevOps.

Cosa ne pensi di coloro che si assicurano che sia attivo e come funzionava?

Stefan: Con l’involucro del modello, abbiamo fornito il rilascio gratuitamente. Ciò significava che i data scientist, si potrebbe dire, erano responsabili solo del modello.

E abbiamo cercato di strutturare le cose in modo che, come dire, i modelli difettosi non dovrebbero arrivare in produzione perché abbiamo una sufficiente validazione CI che, come il modello, si sa, non dovrebbe essere un problema.

E quindi l’unica cosa che si sarebbe rotta in produzione sarebbe stato un cambiamento dell’infrastruttura, in tal caso i data scientist non sono responsabili e capaci di farlo.

Ma altrimenti, sai, se loro lo fossero, quindi era compito nostro, per così dire, responsabilità del mio team.

Credo che eravamo in chiamata per qualcosa come, sai, oltre 50 servizi perché così tanti modelli erano stati rilasciati con noi. E noi eravamo in prima linea. Quindi eravamo in prima linea proprio perché, sai, la maggior parte delle volte, se qualcosa sarebbe andata storta, sarebbe probabilmente stato un problema di infrastruttura.

Noi eravamo il primo punto, ma loro erano anche nella catena di chiamata. In effetti, beh, mi ritiro. Una volta che un qualsiasi modello veniva rilasciato, eravamo entrambi in chiamata, solo per assicurarci che fosse stato rilasciato e che fosse in funzione, ma poi si sarebbe biforcato un po’, come dire, okay, noi avremmo fatto la prima escalation perché se si tratta di infrastruttura, non si può fare nulla, ma altrimenti, devi essere in chiamata perché se il modello sta effettivamente facendo delle previsioni strane, non possiamo risolverlo, in tal caso tu sei la persona che deve fare il debug e diagnosticarlo.

Piotr: Sembra qualcosa legato ai dati, giusto? Deriva dei dati.

Stefan: Sì, deriva dei dati, qualcosa a monte, eccetera. Ecco perché una migliore osservabilità del modello e osservabilità dei dati aiuta. Quindi cercare di catturare e utilizzare quello.

Quindi ci sono molti modi diversi, ma la bella cosa di ciò che avevamo impostato è che eravamo in una buona posizione per poter catturare gli input durante la fase di addestramento, ma poi anche perché controllavamo il servizio web. E cosa c’era all’interno, potevamo effettivamente registrare ed emettere le cose che arrivavano.

Quindi avevamo delle pipeline per costruire e conciliare. Quindi, se vuoi chiedere se c’è una SKU di servizio di addestramento, tu, come data scientist o ingegnere di machine learning, non dovevi costruirlo. Dovevi solo attivare il logging nel tuo servizio.

Poi avevamo come attivare altre configurazioni a valle, ma poi fornivamo un modo per poterlo inviare a una soluzione di osservabilità per confrontare le caratteristiche in produzione rispetto alle caratteristiche di addestramento.

Piotr: Sembra che tu abbia fornito un’interfaccia molto confortevole per i tuoi data scientist.

Stefan: Sì, intendo, questa è l’idea. Voglio dire, a dire il vero, è quello che sto cercando di replicare con DAGWorks, fornire le astrazioni per consentire a chiunque di avere quell’esperienza che abbiamo costruito in Stitch Fix.

Ma sì, i data scientist odiano le migrazioni. E quindi parte della ragione per cui ci siamo concentrati su una cosa di API è quella di poter, se volessimo cambiare le cose dal punto di vista della piattaforma, non dire, hey, data scientist, devi migrare, giusto? E quindi questo faceva anche parte dell’idea di perché ci siamo concentrati così tanto su questi tipi di limiti di API, in modo da poter semplificarci la vita, ma anche la loro.

Piotr: E puoi condividere quanto era grande il team di data scientist e il team della piattaforma di machine learning in termini di numero di persone al momento in cui lavoravi in Stitch Fix?

Stefan: Era, penso, al suo apice, erano come 150, erano data scientist e il team della piattaforma insieme.

Piotr: E il team era 1:10?

Stefan: Quindi avevamo un team della piattaforma, penso che in generale, era come, o 1:4, o 1:5 in totale, perché avevamo un intero team della piattaforma che aiutava con le interfacce utente, un intero team della piattaforma che si concentrava sui microservizi e sull’architettura online, giusto? Quindi non legato al pipeline.

E quindi, sì. E quindi c’era di più, si potrebbe dire, lavoro richiesto dal punto di vista dell’ingegneria per integrare API, machine learning e altre cose nel business. Quindi il rapporto effettivo era 1:4, 1:5, ma questo perché c’era una grande componente del team della piattaforma che aiutava a fare più cose intorno alla costruzione di piattaforme per aiutare ad integrare, debuggare, raccomandazioni di machine learning, eccetera.

Aurimas: Ma quali erano le dimensioni dei team di machine learning? Probabilmente non centinaia di persone in un singolo team, giusto?

Stefan: Erano, sì, è variato un po’, sai, da otto a dieci. Alcuni team erano così grandi, altri erano cinque, giusto?

Quindi davvero, dipendeva molto dalla verticalità e da chi stavano aiutando rispetto al business. Quindi si può pensare a un numero approssimativo di scaglioni di modellazione. Quindi, se, eravamo nel Regno Unito, ci sono distretti nel Regno Unito e negli Stati Uniti, e poi c’erano diverse linee di business. C’erano uomini, donne, bambini, giusto?

Si potrebbe pensare a scienziati dei dati per ognuno, per ogni tipo di combinazione, giusto? Quindi dipendeva davvero da dove era necessario e da dove non lo era, ma tipo, sì, da squadre di tre a squadre di otto-dieci.

Come essere un ingegnere MLOps di valore?

Piotr: C’è molta informazione e contenuti su come diventare data scientist. Ma ce ne sono dieci volte meno su come essere un ingegnere MLOps o un membro del team della piattaforma di machine learning.

Cosa pensi che sia necessario affinché una persona sia un membro di valore di un team della piattaforma di machine learning? E qual è la composizione tipica del team della piattaforma di machine learning? Che tipo di persone devi avere?

Stefan: Credo che sia necessario avere empatia per ciò che le persone stanno cercando di fare. Quindi penso che se hai fatto un po’ di machine learning, un po’ di modellazione, non è come, quindi quando qualcuno dice, quindi quando qualcuno viene da te con una cosa, puoi chiedere: cosa stai cercando di fare?

Hai una comprensione un po’ più alta, tipo, cosa puoi fare? Giusto? E poi aver costruito cose da solo e vissuto i problemi, questo aiuta sicuramente con la nostra empatia. Quindi se sei un ex operatore, sai che è un po’ quello che è stato il mio percorso.

Ho costruito modelli, ho capito che mi piaceva meno costruire i modelli effettivi ma l’infrastruttura intorno ad essi per garantire che le persone possano fare le cose in modo efficace ed efficiente. Quindi sì, avere, direi, le competenze potrebbero essere leggermente cambiate rispetto a sei anni fa ad oggi, solo perché c’è molta più maturità e open-source nel mercato dei fornitori. Quindi, c’è un po’ un meme o un cliché, con MLOps, è VendorOps.

Se stai integrando e portando soluzioni che non stai costruendo internamente, allora devi capire un po’ di più sugli astrazioni e su cosa vuoi controllare rispetto a cosa integrare strettamente.

Empatia, quindi avere un po’ di esperienza e poi le competenze di ingegneria del software che hai costruito cose per creare, nel mio post sul blog, lo inquadro come un’API a due livelli.

Non dovresti mai idealmente esporre direttamente l’API del fornitore. Dovresti sempre avere un involucro

di veneer intorno ad esso in modo da controllare alcuni aspetti. In modo che le persone a cui stai fornendo la piattaforma non debbano prendere decisioni.

Quindi, ad esempio, dove dovrebbe essere archiviato l’artefatto? Come per il file salvato, come dovrebbe essere qualcosa di cui ti occupi tu come piattaforma, anche se potrebbe essere qualcosa che è richiesto dall’API del fornitore per essere fornito, puoi prendere tu quella decisione.

Questo è il punto in cui dico, se hai vissuto l’esperienza di gestire e mantenere le API dei fornitori, sarai un po’ più bravo la prossima volta. Ma altrimenti, sì.

E se hai anche una formazione in DevOps, o hai costruito cose da distribuire tu stesso, quindi hai lavorato in posti più piccoli, allora puoi anche capire le implicazioni di produzione e gli strumenti disponibili con cui puoi integrare.

Dato che potresti ottenere un modo abbastanza ragionevole con Datadog solo per il rilascio del servizio, giusto?

Ma se vuoi davvero capire cosa c’è all’interno del modello, perché è importante capire l’addestramento, il servizio, giusto? Allora, avendo visto che è stato fatto, avendo un po’ di empatia per capire perché devi farlo, penso che ti porti a prendere decisioni migliori, sai se hai una visione più ampia di come le cose si incastrano da un capo all’altro, la visione macro, penso che allora ti aiuti a prendere decisioni micro migliori.

MLOps è un’estensione di DevOps. Non una diramazione – Il mio pensiero sul documento MLOps come CEO di una startup MLOps

Il percorso futuro per i team delle piattaforme di ML

Piotr: Va bene, ha senso. Stefan, una domanda perché penso che per quanto riguarda gli argomenti che volevamo trattare, stiamo andando piuttosto bene. Stavo guardando l’agenda. C’è qualcosa che dovremmo chiedere, o vorresti parlare?

Stefan: Buona domanda.

Vediamo, sto guardando anche l’agenda. Sì, penso che uno dei miei punti di vista sul futuro, giusto?

Penso che per me Stitch Fix abbia cercato di consentire ai data scientist di fare cose dall’inizio alla fine.

Il modo in cui l’ho interpretato è che se consenti ai professionisti dei dati, in generale, di fare più self-service, più lavoro end-to-end, possono prendere contesti di dominio aziendale e creare qualcosa che si ripete fino in fondo.

Quindi hanno un ciclo di feedback migliore per capire se è utile o meno, piuttosto che il modello più tradizionale in cui le persone sono ancora in questo tipo di modello di passaggio. E quindi, in che caso, c’è un po’ di domanda su chi stai progettando gli strumenti, giusto? Stai cercando di indirizzare gli ingegneri, gli ingegneri di Machine Learning con queste soluzioni?

Significa che il data scientist deve diventare un ingegnere del software per poter utilizzare la tua soluzione per fare self-service? C’è l’altro estremo, che è il low code, no code, ma penso che sia un po’ limitante. La maggior parte di queste soluzioni sono SQL o qualche tipo di DSL personalizzato, che secondo me non si presta bene a prendere conoscenze o apprendere un insieme di competenze e poi applicarlo, andare in un altro lavoro. Non è necessariamente che funziona solo se si utilizza lo stesso strumento, giusto?

E quindi, la mia convinzione qui è che se possiamo semplificare gli strumenti, l’astrazione dell’ingegneria del software che è richiesta, allora possiamo abilitare meglio questo tipo di paradigma self-service che rende anche più facile per i team delle piattaforme gestire le cose e quindi è per questo che dicevo se prendi un fornitore e puoi semplificare l’API, puoi effettivamente renderla più facile da usare per un data scientist, giusto?

Quindi è qui che la mia tesi è che se possiamo abbassare la barriera dell’ingegneria del software per fare più self-service, possiamo fornire più valore perché la stessa persona può ottenere più risultati.

Ma poi anche, se è costruito nel modo giusto, stai anche, qui è dove la tesi con Hamilton e DAGWorks, puoi più facilmente mantenere le cose nel tempo in modo che quando qualcuno se ne va, non ci siano incubi nell’ereditare le cose, che è dove, come a Stitch Fix, abbiamo reso molto facile arrivare alla produzione, ma i team a causa del rapido movimento del business e di altre cose, passavano metà del loro tempo cercando di mantenere a galla i flussi di machine learning.

E quindi qui penso che, sai, e queste sono alcune delle ragioni per cui è stato perché abbiamo anche permesso loro di fare troppo, troppa ingegneria, giusto?

Competenze necessarie per costruire strumenti robusti

Stefan: Sono curioso, cosa ne pensate in termini di chi dovrebbe essere il target finale per il livello di competenza nell’ingegneria del software richiesta per abilitare il self-service, la costruzione di modelli, i flussi di machine learning.

Aurimas: Cosa intendi nello specifico?

Stefan: Intendo, quindi se il self-service è il futuro. Se sì, di quali competenze di self-engineering si ha bisogno?

Aurimas: Per me, almeno come la vedo io nel futuro, il self-service è il futuro, prima di tutto, ma poi non vedo davvero, almeno per esperienza, che ci siano piattaforme al momento con cui gli scienziati dei dati potrebbero lavorare dall’inizio alla fine.

Come ho visto, nella mia esperienza, c’è sempre bisogno di un ingegnere di machine learning che si trova ancora tra gli scienziati dei dati e la piattaforma, sfortunatamente, ma sicuramente dovrebbe esserci l’obiettivo che una persona con le competenze di un attuale scienziato dei dati possa fare tutto dall’inizio alla fine. Questo è ciò in cui credo.

Piotr: Penso che sia una sorta di corsa. Quindi le cose che erano difficili sei anni fa sono facili oggi, ma allo stesso tempo le tecniche sono diventate più complesse.

Come ad esempio abbiamo, ok, oggi abbiamo ottimi modelli fondamentali, encoder. I modelli che stiamo costruendo dipendono sempre di più dagli altri servizi. E questa astrazione non sarà più solo dataset, alcune operazioni di preprocessing, addestramento, post-processing, impacchettamento del modello e quindi un servizio web indipendente, giusto?

Si sta diventando sempre più dipendenti anche da servizi esterni. Quindi penso che l’obiettivo, naturalmente, sia quello di renderlo amichevole al self-service, ma penso che con lo sviluppo delle tecniche e dei metodi in questo settore, sarà una sorta di corsa, risolveremo alcune cose, ma introdurremo un’altra complessità, specialmente quando si cerca di fare qualcosa di all’avanguardia, non si pensa a rendere le cose semplici da usare all’inizio, ma piuttosto si pensa se saremo in grado di farlo, giusto?

Quindi le nuove tecniche di solito non sono così amichevoli e facili da usare. Una volta che diventano più comuni, le rendiamo più facili da usare.

Stefan: Volevo dire, o almeno saltare quello che sta dicendo, che in termini di una delle tecniche che uso per progettare API, sto cercando effettivamente di progettare l’API prima.

Penso che quello che Piotr stava dicendo sia molto facile per un ingegnere. Ho riscontrato questo problema io stesso, cioè partire dal basso. È come se volessi costruire questa capacità e poi voglio mostrare come le persone la utilizzano.

E penso che invertire la situazione e andare, sapete, qual è l’esperienza che voglio che le persone utilizzino o ottengano prima dall’API e poi scendere, sia davvero una esperienza molto illuminante su come si può semplificare ciò che si può fare perché è molto facile partire dal basso e includere tutte queste preoccupazioni perché si vuole consentire a chiunque di fare qualsiasi cosa, come una tendenza naturale di un ingegnere.

Ma quando si vuole semplificare le cose, è davvero necessario porsi la domanda, sapete qual è l’ottanta-venti? Qui entra in gioco l’etica di Python di fornire tutto il necessario, giusto?

Quindi come puoi rendere questo il più facile possibile per il gruppo più ottimale di persone che vogliono usarlo?

Conclusioni

Aurimas: Concordo, concordo, in realtà.

Quindi stiamo quasi finendo il tempo. Quindi forse l’ultima domanda, forse Stefan, vuoi lasciare ai nostri ascoltatori qualche idea, forse vuoi promuovere qualcosa. È il momento giusto per farlo ora.

Stefan: Sì.

Quindi se hai paura di ereditare il lavoro dei tuoi colleghi, o se sei una nuova persona che si unisce alla tua azienda e hai paura dei flussi di lavoro o delle cose che stai ereditando, giusto?

Direi che mi piacerebbe sentire da te. Hamilton, penso, ma è ancora un progetto open-source molto giovane, molto facile. Abbiamo una roadmap che viene plasmata e formata da contributi e opinioni. Quindi se vuoi un modo facile per mantenere e collaborare come team sul tuo flusso di lavoro dei modelli, poiché gli individui costruiscono i modelli, ma le squadre li possiedono.

Penso che richieda un diverso set di competenze e una disciplina diversa per farlo bene. Quindi vieni a dare un’occhiata a Hamilton, dicci cosa ne pensi. E poi dalla piattaforma DAGWorks, siamo ancora nella fase di beta chiusa al momento della registrazione di questo video, ma abbiamo una lista d’attesa e un modulo di accesso anticipato che puoi compilare se sei interessato a provare la piattaforma.

In caso contrario, cerca Hamilton e dacci una stella su GitHub. Fammi sapere la tua esperienza. Ci piacerebbe assicurarci che mentre i tuoi ML ETL o pipeline crescono, i tuoi oneri di manutenzione non lo facciano.

Grazie.

Aurimas: Quindi, grazie per essere qui con noi oggi e per questa bella conversazione. Grazie.

Stefan: Grazie per avermi invitato, Piotr, e Aurimas.