Lezioni apprese dalla costruzione della piattaforma ML di Mailchimp

Lezioni apprese dalla creazione della piattaforma ML di Mailchimp

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

In questo episodio, Mikiko Bazeley condivide le sue esperienze nella costruzione della piattaforma ML di Mailchimp.

Puoi vederlo su YouTube:

O ascoltarlo come podcast su:

Ma se preferisci una versione scritta, eccola qui!

In questo episodio, imparerai di:

1 La piattaforma ML presso Mailchimp e i casi d’uso di generative AI
2 Problemi di generative AI presso Mailchimp e monitoraggio dei feedback
3 Avvicinarsi al business come ingegnere MLOps
4 Storie di successo delle capacità della piattaforma ML presso Mailchimp
5 Percorsi promettenti presso Mailchimp

Chi è Mikiko Bazeley

Aurimas: Ciao a tutti e benvenuti al Machine Learning Platform Podcast. Oggi, sono il tuo presentatore, Aurimas, e insieme a me c’è un co-presentatore, Piotr Niedźwiedź, che è un co-fondatore e il CEO di neptune.ai.

Oggi con noi nell’episodio c’è la nostra ospite, Mikiko Bazeley. Mikiko è una figura molto conosciuta nella comunità dei dati. Attualmente è responsabile di MLOps presso FeatureForm, uno store virtuale di funzionalità. Prima di ciò, ha costruito piattaforme di machine learning presso MailChimp.

Piacere di averti qui, Miki. Ci racconti qualcosa di te?

Mikiko Bazeley: Hai sicuramente colto tutti i dettagli correttamente. Ho iniziato a lavorare per FeatureForm lo scorso ottobre, e prima di ciò ho lavorato alla squadra di piattaforma ML di Mailchimp. Ero lì prima e dopo l’enorme acquisizione di 14 miliardi di dollari (o qualcosa del genere) da parte di Intuit – quindi ero lì durante il passaggio di consegne. Piuttosto divertente, caotico a volte.

Ma prima di quello, ho trascorso diversi anni lavorando come analista di dati, scienziato dei dati e persino in un ruolo strano di ingegnere dati per MLOps/ML platform per alcune startup iniziali, dove cercavo di sviluppare le loro piattaforme per il machine learning e ho capito che in realtà è molto difficile quando sei una startup di cinque persone – molti insegnamenti appresi lì.

Quindi dico onestamente alle persone di aver passato gli ultimi otto anni lavorando sia nell’ambito dei dati che dell’ML, in pratica – un modo elegante per dire “saltando da un lavoro all’altro”.

Come passare dall’analisi dei dati all’ingegneria MLOps

Piotr: Miki, sei stato uno scienziato dei dati, giusto? E successivamente, un ingegnere MLOps. So che non sei un grande fan dei titoli; preferisci parlare di ciò che effettivamente sai fare. Ma direi che ciò che fai non è una combinazione comune.

Come sei riuscito a passare da un ruolo più analitico, scientifico, a uno più orientato all’ingegneria?

Mikiko Bazeley: Molte persone rimangono sorprese nel sapere che non ho studiato informatica durante l’università. Infatti, ho cominciato a imparare Python solo circa un anno prima di fare la transizione verso un ruolo di scienziato dei dati.

Quando ero all’università, ho studiato antropologia ed economia. Ero molto interessato al modo in cui le persone lavorano perché, ad essere sincero, non capivo come le persone lavorassero. Quindi quella sembrava l’area di studio logica.

Ero sempre affascinato dal modo in cui le persone prendevano decisioni, soprattutto in un gruppo. Ad esempio, quali sono le norme culturali o sociali che accettiamo senza troppo pensiero? Quando ho terminato l’università, il mio primo lavoro è stato lavorare come receptionist in un salone di bellezza.

In quel momento, non avevo alcuna competenza di programmazione.

Credo di aver seguito solo una lezione in R per la biostatistica, che ho superato a malapena. Non per mancanza di intelligenza o ambizione, ma soprattutto perché non capivo la strada da seguire, non capivo il processo di come fare quella tipo di transizione.

La mia prima transizione è stata verso le operazioni di crescita e lo “sales hacking” – a quell’epoca in Silicon Valley si chiamava growth hacking. E poi, ho sviluppato una strategia per fare queste transizioni. Quindi sono riuscita a passare dal growth hacking all’analisi dei dati, poi dall’analisi dei dati alla scienza dei dati e infine dalla scienza dei dati all’ingegneria MLOps.

Credo che gli ingredienti chiave per fare quella transizione da scienziata dei dati a ingegnere MLOps fossero:

Avere un autentico desiderio per il tipo di problemi che voglio risolvere e su cui lavorare. Questo è sempre stato il focus della mia carriera – “Qual è il problema su cui voglio lavorare oggi?” e “Pensi che sarà interessante tra uno o due anni?”

La seconda parte è stata molto interessante perché c’è stato un anno in cui ho avuto quattro lavori. Lavoravo come scienziata dei dati, facevo da mentore in due boot camp e lavoravo su una startup tecnologica nel settore immobiliare nei weekend.

Alla fine ho deciso di lavorare a tempo pieno durante la pandemia, ed è stata un’esperienza di apprendimento fantastica, ma finanziariamente potrebbe non essere stata la soluzione migliore per essere retribuita con quote di partecipazione. Ma va bene così, a volte devi seguire un po’ la tua passione. Devi seguire i tuoi interessi.

Piotr: Per quanto riguarda le decisioni, nel mio contesto, ricordo quando ero ancora uno studente. Ho iniziato dall’ambito tecnico, il mio primo lavoro è stato uno stage a Google come ingegnere del software.

Sono polacco, e ricordo quando ho ricevuto un’offerta da Google per entrare come ingegnere del software regolare. Il salario mensile era più di quanto spendessi in un anno. Era due o tre volte di più.

Era molto allettante seguire dove c’era più denaro in quel momento. Vedo molte persone nel campo, specialmente all’inizio della loro carriera, che pensano più a breve termine. Il concetto di guardare alcuni passi, alcuni anni avanti, penso che sia qualcosa che le persone stanno ignorando, e credo che alla fine possa portare a risultati migliori.

Mi chiedo sempre quando c’è una decisione del genere: “Cosa succederebbe se dopo un anno fosse un fallimento e non fossi felice? Posso tornare indietro e scegliere l’altra opzione?” E di solito la risposta è “sì, puoi”.

So che decisioni del genere sono impegnative, ma penso che tu abbia fatto la scelta giusta e dovresti seguire la tua passione. Pensa a dove questa passione ti sta guidando.

Risorse che possono aiutare a colmare il divario tecnico

Aurimas: Ho anche un background molto simile. Sono passato dall’analisi dei dati alla scienza dei dati, poi all’apprendimento automatico, poi all’ingegneria dei dati e infine a MLOps.

Per me è stato un percorso un po’ più lungo perché ho anche avuto esperienze nell’ingegneria dei dati, nell’ingegneria del cloud e nell’ingegneria del DevOps.

Tu sei passato direttamente dalla scienza dei dati, se ho capito bene. Come hai superato quel divario tecnico, che chiamerei un abisso tecnico, necessario per diventare un ingegnere MLOps?

Mikiko Bazeley: Sì, assolutamente. Questo faceva parte del lavoro presso la startup immobiliare in fase iniziale. Qualcosa di cui sono molto appassionata sono i boot camp. Quando mi sono laureata, avevo un GPA molto basso – molto, molto basso.

Non so come si facciano i voti in Europa, ma negli Stati Uniti, ad esempio, di solito è su una scala da 4.0, e io avevo un 2.4, che è considerato molto, molto basso secondo la maggior parte degli standard statunitensi. Quindi non ho avuto l’opportunità di frequentare un programma di laurea specialistica o magistrale.

È stato molto interessante perché a quel punto avevo circa sei anni di esperienza lavorando con leader di livello C per aziende come Autodesk, Teladoc e altre aziende che sono o molto conosciute a livello globale, o almeno molto conosciute negli Stati Uniti.

Membri del top management mi dicevano: “Ehi, ti scriviamo noi le lettere di presentazione per farti accedere a programmi di laurea”.

E i programmi post-laurea erano come “Mi dispiace, no! Devi tornare all’università per ricalcolare la tua media ponderata”. E io sono come “Ho già passato i 20 anni. La conoscenza è costosa, non farò mai una cosa del genere”.

Quindi sono una grande fan dei boot camp.

Ciò che mi ha aiutato sia nella transizione al ruolo di data scientist che nel ruolo di MLOps engineer è stata una combinazione di boot camp, e quando stavo passando al ruolo di MLOps engineer, ho anche seguito questo workshop molto conosciuto chiamato Full Stack Deep Learning. È tenuto da Dimitri e Josh Tobin, che poi hanno fondato Gantry. Mi è piaciuto molto.

Credo che a volte le persone entrino nei boot camp pensando che questo gli garantisca un lavoro, ma in realtà non funziona così. È solo una forma di apprendimento strutturato e accelerato.

Ciò che mi ha aiutato in entrambe queste transizioni è stato investire sul mio rapporto con il mentore. Ad esempio, quando mi sono inizialmente trasferita dall’analisi dei dati alla scienza dei dati, il mio mentore di allora era Rajiv Shah, che ora è sviluppatore di supporto presso Hugging Face.

Sono stata mentore nei boot camp da allora, in un paio di occasioni. Molte volte, gli studenti si limitano a chiedere “Oh, perché non mi aiuti a valutare il mio progetto? Come sono i miei codici?”

E questo non è un modo efficace per sfruttare al massimo un mentore del settore, specialmente quando hanno credenziali come quelle di Rajiv Shah.

Nel corso di full-stack deep learning, c’erano degli assistenti che erano assolutamente eccezionali. Quello che facevo era mostrargli il mio progetto per la valutazione. Ma ad esempio, quando mi sono trasferita nel ruolo di data scientist, ho chiesto a Rajiv Shah:

Come posso interpretare i modelli se il marketing, se il mio CMO mi chiede di creare una previsione e predirre i risultati?
Come metto in produzione questo modello?
Come ottenere supporto per questi progetti di scienza dei dati?
Come sfruttare le competenze che ho già?

E tutto ciò l’ho abbinato alle competenze tecniche che stavo sviluppando.

Ho fatto la stessa cosa nel ruolo di piattaforma ML. Avrei chiesto:

Cosa non mi sta insegnando attualmente questo corso che dovrei imparare?
Come posso sviluppare il mio portfolio di lavori?
Come colmare queste lacune?

Credo di aver sviluppato le competenze attraverso una combinazione di cose.

È necessario avere un curriculum strutturato, ma è anche necessario avere progetti con cui lavorare, anche se sono progetti sandbox, in modo da poter affrontare molti dei problemi nello sviluppo dei sistemi di ML.

La ricerca di mentori nei boot camp

Piotr: Quando parli di mentori, li hai trovati durante i boot camp o hai avuto modi diversi per trovarli? Come funziona?

Mikiko Bazeley: Con la maggior parte dei boot camp, alla fine si tratta di scegliere quello giusto, onestamente. Per me,

ho scelto Springboard per la mia transizione alla data science, e poi li ho usati anche un po’ durante la transizione al ruolo di MLOps, ma mi sono affidata maggiormente al corso Full Stack Deep Learning – e anche a tanto studio e lavoro in autonomia.

Non ho completato quello di Springboard per MLOps, perché a quel punto avevo già ricevuto un paio di offerte di lavoro per quattro o cinque diverse aziende, per il ruolo di MLOps engineer.

Trovare un lavoro dopo un boot camp e presenza sui social media

Piotr: Ed è stato grazie al boot camp? Perché hai detto che molti usano i boot camp per trovare lavoro. Come ha funzionato nel tuo caso?

Mikiko Bazeley: Il boot camp non mi ha messo in contatto con i responsabili delle assunzioni. Quello che ho fatto è, ed è qui che entra in gioco la costruzione di una presenza pubblica.

Sicuramente non penso di essere un influencer. Per prima cosa, non ho un pubblico così ampio. Quello che cerco di fare, molto simile a quello che molte persone stanno facendo nel podcast in questo momento, è condividere le mie esperienze di apprendimento con gli altri. Cerco di prendere le mie esperienze e presentarle come “Ok, sì, queste cose possono accadere, ma così è come puoi affrontarle”.

Penso che costruire in pubblico e condividere quell’apprendimento sia stato fondamentale per ottenere un lavoro. Ne vedo così tanti di questi cercatori di lavoro, specialmente nel settore MLOps o nel settore degli ingegneri di machine learning.

Li vedo tutto il tempo con un titolo del genere: “data science, machine learning, Java, Python, SQL o blockchain, computer vision”.

Sono due cose. Primo, non stanno trattando il loro profilo LinkedIn come una pagina di destinazione del sito web. Ma alla fine della giornata, è proprio quello che è, giusto? Tratta bene la tua pagina di destinazione e potresti effettivamente trattenere i visitatori, simile a un sito web o a un prodotto SaaS.

Ma cosa più importante, non stanno effettivamente facendo ciò che è importante fare con i social network, ovvero devi effettivamente interagire con le persone. Devi condividere con le persone. Devi produrre le tue esperienze di apprendimento.

Quindi mentre frequentavo i boot camp, era quello che facevo essenzialmente. Mentre imparavo e lavoravo su progetti, combinavo ciò con le mie esperienze e lo condividevo pubblicamente.

Cercavo di essere davvero – non voglio dire autentico, è un termine un po’ abusato – ma c’è il detto, “Le persone interessanti sono interessate”. Devi essere interessato ai problemi, alle persone e alle soluzioni che ti circondano. Le persone possono connettersi con quel tipo di atteggiamento. Se stai solo fingendo come fanno molte persone che utilizzano Chat GPT e Gen AI – fingendolo senza sostanza – le persone non possono connettersi.

Devi avere quel vero interesse e devi avere qualcosa con cui accompagnarlo. Ecco come ho fatto. Penso che la maggior parte delle persone non lo faccia.

Piotr: C’è un altro fattore che è necessario. Sto lottando con questo quando si tratta di condividere. Sto imparando cose diverse, ma una volta che le imparo, sembrano ovvie, e poi mi vergogno un po’ perché potrebbero sembrare troppo ovvie. E poi penso: aspettiamo qualcosa di più sofisticato da condividere. E quello non arriva mai.

Mikiko Bazeley: La sindrome dell’impostore.

Piotr: Già. Devo liberarmene.

Mikiko Bazeley: Aurimas, senti mai di esserti liberato della sindrome dell’impostore?

Aurimas: No, mai.

Mikiko Bazeley: Nemmeno io. Trovo solo il modo di evitarla.

Aurimas: Tutto ciò che pubblico, penso che non sia necessariamente degno del tempo delle altre persone, ma sembra che lo sia.

Mikiko Bazeley: È quasi come se dovessi solo organizzare le cose per superare la tua natura peggiore. Tutte le tue insicurezze, devi ingannarti come una buona dieta e allenamento.

Cos’è FeatureForm e quali sono gli altri tipi di store di funzionalità

Aurimas: Parliamo un po’ del tuo lavoro attuale, Miki. Sei il Responsabile di MLOps presso FeatureForm. Un tempo ho avuto l’occasione di parlare con il CEO di FeatureForm e mi ha lasciato una buona impressione sul prodotto.

Cos’è FeatureForm? In cosa differisce FeatureForm dagli altri attori presenti oggi sul mercato del feature store?

Mikiko Bazeley: Penso che dipenda dalla comprensione dei diversi tipi di store di funzionalità presenti e persino dalla comprensione del motivo per cui un store di funzionalità virtuale sia forse un nome terribile per quello che FeatureForm rappresenta come categoria; non è molto descrittivo.

Ci sono tre tipi di store di funzionalità. Interessante, corrispondono approssimativamente alle fasi di MLOps e riflettono come si sono sviluppati paradigmi diversi.

I tre tipi sono:

1 Letterale
2 Fisico
3 Virtuale

La maggior parte delle persone comprende intuitivamente i feature store letterali. Un feature store letterale è letteralmente solo uno store di funzionalità. Conserva le funzionalità (inclusi definizioni e valori) e le serve. Questo è praticamente tutto ciò che fa. È quasi come una soluzione di archiviazione dati molto specializzata.

Ad esempio, Feast. Feast è un vero e proprio store di funzionalità. È una opzione molto leggera che puoi implementare facilmente, il che significa che il rischio di implementazione è basso. In pratica, non ci sono trasformazioni, orchestrazioni o calcoli in corso

Piotr: Miki, se mi permetti, perché è leggero? Ho capito che uno store di funzionalità letterale memorizza funzionalità. In pratica, sostituisce il tuo spazio di archiviazione, giusto?

Mikiko Bazeley: Quando dico leggero, intendo che è simile all’implementazione di Postgres. Tecnicamente, non è molto leggero. Ma se lo confrontiamo con uno store di funzionalità fisico e li posizioniamo su uno spettro, lo è.

Uno store di funzionalità fisico ha tutto:

Memorizza funzionalità,
Offre funzionalità,
Orchestrare funzionalità,
Effettua le trasformazioni.

In questo senso, uno store di funzionalità fisico è pesante in termini di implementazione, manutenzione e amministrazione.

Piotr: Sullo spettro, lo store di funzionalità fisico è il più pesante?

E nel caso di uno store di funzionalità letterale, le trasformazioni vengono implementate altrove e poi salvate?

Mikiko Bazeley: Sì.

Aurimas: E lo store di funzionalità stesso è solo una libreria, che essenzialmente compie azioni sull’archiviazione. Corretto?

Mikiko Bazeley: Sì, in gran parte è così. Feast, ad esempio, è una libreria. Viene fornita con diversi fornitori, quindi hai una scelta.

Aurimas: Puoi configurarlo con S3, DynamoDB o Redis, ad esempio. La pesantezza, immagino, deriva dal fatto che è solo una sottile libreria sopra questa archiviazione e devi gestire l’archiviazione tu stesso.

Mikiko Bazeley: Esattamente.

Piotr: Quindi non c’è un backend? Non c’è un componente che memorizza i metadati su questo store di funzionalità?

Mikiko Bazeley: Nel caso dello store di funzionalità letterale, fa solo da registro per le funzionalità e i metadati. In realtà, non fa nulla di pesante come le trasformazioni o l’orchestrazione.

Piotr: Allora cos’è uno store di funzionalità virtuale? Capisco gli store di funzionalità fisici, questo è abbastanza chiaro per me, ma sono curioso di sapere cos’è uno store di funzionalità virtuale.

Mikiko Bazeley: Sì, quindi nel paradigma dello store di funzionalità virtuale, cerchiamo di prendere il meglio dei due mondi.

Ci sono casi d’uso per i diversi tipi di store di funzionalità. Gli store di funzionalità fisici sono nati da aziende come Uber, Twitter, Airbnb, ecc. Stavano risolvendo problemi complessi legati all’elaborazione di enormi quantità di dati in modo continuo.

Le sfide degli store di funzionalità fisici sono che sei praticamente bloccato al tuo fornitore o al fornitore che scelgono. Non puoi effettivamente cambiarlo. Ad esempio, se volessi utilizzare Cassandra o Redis come il tuo “store di inferenze” o “store online”, non puoi farlo con uno store di funzionalità fisico. Di solito, prendi semplicemente i provider che ti vengono dati. È quasi come una soluzione specializzata di elaborazione e archiviazione dati.

Con lo store di funzionalità virtuale, cerchiamo di avere la flessibilità di uno store di funzionalità letterale in cui puoi sostituire i fornitori. Ad esempio, puoi utilizzare BigQuery,

AWS o Azure. E se vuoi utilizzare diversi store di inferenze, hai questa opzione.

Ciò che fanno gli store di funzionalità virtuali è concentrarsi sui veri problemi che gli store di funzionalità sono destinati a risolvere, ovvero non solo versioning, documentazione e gestione dei metadati, e non solo servizi, ma anche orchestrazione delle trasformazioni.

Ad esempio, da FeatureForm facciamo questo perché siamo nativi di Kubernetes. Supponiamo che i data scientist, per la maggior parte, non vogliano scrivere trasformazioni altrove. Supponiamo che vogliano fare le cose che normalmente farebbero, con Python, SQL e PySpark, con i data frame.

Vogliono solo essere in grado di, ad esempio, avvolgere le loro funzionalità in un decoratore o scriverle come una classe se lo desiderano. Non dovrebbero preoccuparsi dell’infrastruttura. Non dovrebbero fornire tutte queste configurazioni fantasiose e dover capire quale sia il percorso verso la produzione: cerchiamo di rendere tutto il più semplice e snello possibile.

L’idea è che si unisca alla squadra un nuovo data scientist…

Tutti hanno vissuto questa esperienza: si arriva in una nuova azienda e si spendono praticamente i primi tre mesi cercando documentazione su Confluence. Si leggono i canali di Slack delle persone per capire esattamente cosa hanno fatto con questo progetto di previsione e churn.

Si cerca dati da utilizzare. Si scopre che le query sono rotte e si pensa: “Dio, cosa stavano pensando con queste?”

Poi arriva un responsabile e dice: “Ah, a proposito, i numeri sono sbagliati. Mi hai dato questi numeri e sono cambiati.” E tu dici: “Mamma mia! Ora ho bisogno di tracciabilità. Oh Dio, devo fare il tracking.”

La parte che fa davvero male a molte aziende al momento è la regolamentazione. Ogni azienda che fa affari in Europa deve rispettare il GDPR, questo è importante. Ma molte aziende mediche negli Stati Uniti, ad esempio, sono soggette all’HIPAA, che riguarda aziende mediche e di salute. Quindi, per molte di loro, gli avvocati sono molto coinvolti nel processo di ML. Molte persone non se ne rendono conto.

Nel settore aziendale, gli avvocati sono quelli che, ad esempio, quando si trovano di fronte a una causa legale o esce una nuova regolamentazione, devono dire: “Ok, posso tracciare quali funzionalità vengono utilizzate e quali modelli?” Quindi, sono queste tipologie di flussi di lavoro che stiamo cercando di risolvere con il paradigma del virtual feature store.

Si tratta di assicurarsi che quando un data scientist sta facendo l’engineering delle caratteristiche, che è la parte più pesante e intensiva del processo di data science, non debba andare in tutti questi posti diversi e imparare nuovi linguaggi quando l’engineering delle caratteristiche è già così difficile.

Il virtual feature store nell’ambito di un’architettura più ampia

Piotr: Quindi Miki, osservandolo da due punti di vista. Dal punto di vista di un amministratore. Diciamo che stiamo per implementare un virtual feature store come parte del nostro stack tecnologico, ho bisogno di uno storage, come S3 o BigQuery. Avrei bisogno dell’infrastruttura per eseguire calcoli. Potrebbe essere un cluster gestito da Kubernetes o qualcos’altro. E poi, il virtual feature store è un’astrazione su storage e componente di calcolo.

Mikiko Bazeley: Sì, infatti abbiamo tenuto un talk a Data Council. Abbiamo pubblicato quello che chiamiamo una “mappa di mercato”, ma non è del tutto corretto. Abbiamo pubblicato un diagramma di come pensiamo che lo stack di ML, l’architettura, dovrebbe essere.

La nostra visione è che hai calcolo e storage, che sono solo cose che ogni team utilizza. Questi non rappresentano ciò che chiamiamo strato zero, strato uno. Non sono necessariamente preoccupazioni dell’ML perché hai bisogno di calcolo e storage per eseguire un sito di e-commerce. Quindi, useremo un sito di e-commerce come esempio.

Lo strato sopra quello è dove hai i provider o, per molte persone – se sei un data scientist da solo, ad esempio – forse hai solo bisogno di accesso alle GPU per i modelli di machine learning. Forse preferisci usare Spark e hai altri provider di servizio a quel livello. Qui è dove iniziamo a vedere un po’ di differenziazione per i problemi di ML.

Inoltre, potresti avere Kubernetes sotto, giusto? Perché potrebbe essere coinvolto anche nell’orchestrazione per l’intera azienda. Quindi, il virtual feature store va sopra Spark, Inray, Databricks, ad esempio.

Ora, sopra tutto questo, che stiamo vedendo adesso nello spazio delle aziende di medie dimensioni, ci sono molte persone che hanno pubblicato descrizioni incredibili dei loro sistemi di ML. Ad esempio, Shopify ha pubblicato un post sul blog su Merlin. Ci sono anche altre aziende, penso che DoorDash abbia pubblicato anche qualche cosa davvero interessante.

Ma ora, le persone stanno anche iniziando a guardare ciò che chiamiamo questi framework unificati MLOps. Qui hai il tuo ZenML, e alcuni altri che sono in quella parte superiore. Il virtual feature store si inserirebbe tra il tuo framework unificato MLOps e i tuoi fornitori come Databricks, Spark, e tutto quello. Sotto ci sarebbe Kubernetes e Ray.

Virtual feature store dal punto di vista dell’utente finale

Piotr: Tutto questo era dal punto di vista architettonico. E per quanto riguarda il punto di vista dell’utente finale? Presumo che per quanto riguarda gli utenti finali del feature store, almeno una delle persone sarà un data scientist. Come interagirà un data scientist con il virtual feature store?

Mikiko Bazeley: Idealmente, l’interazione sarebbe, non voglio dire che sarebbe minima. Ma lo useresti nella misura in cui useresti Git. Il nostro principio è renderlo davvero facile per le persone fare la cosa giusta.

Qualcosa che ho imparato quando ero a Mailchimp dall’ingegnere di staff e capo tecnico per il mio team era fare assunzioni positive – che penso sia solo un principio guida tanto bello. Penso che molte volte ci sia questa strana antagonia tra gli ingegneri ML/MLOps, gli ingegneri software e i data scientist, dove è come dire: “Oh, i data scientist sono terribili a programmare. Sono persone terribili. Che orribili sono?”

Poi i data scientist guardano gli ingegneri DevOps o gli ingegneri di piattaforma andando: “Perché crei costantemente astrazioni davvero cattive e API che perdono tanto che ci rendono così difficile fare semplicemente il nostro lavoro?” La maggior parte dei data scientist semplicemente non si interessa all’infrastruttura.

E se si preoccupano dell’infrastruttura, sono solo ingegneri MLOps in formazione. Sono di fronte a un nuovo viaggio.

Ogni ingegnere MLOps può raccontare una storia del tipo: “Oh Dio, stavo cercando di debuggare o risolvere un pipeline,” o “Oh Dio, avevo un notebook Jupyter o un modello pickled e la mia azienda non aveva l’infrastruttura di deploy.” Penso che questa sia la storia di origine di ogni ingegnere MLOps con il mantello.

Per quanto riguarda l’interazione, idealmente, i data scientist non dovrebbero dover configurare l’infrastruttura come un cluster Spark. Quello di cui hanno bisogno è solo le informazioni sulle credenziali, che dovrebbero essere, non voglio dire facile da ottenere, ma se è davvero difficile per loro ottenerle dai loro ingegneri di piattaforma, allora è forse un segno di problemi di comunicazione più profondi.

Ma tutto ciò di cui hanno bisogno è ottenere le informazioni sulle credenziali e inserirle in un file di configurazione. A quel punto, usiamo il termine “registering” a FeatureForm, ma in pratica è per lo più attraverso i decoratori. Devono solo etichettare cose come “Ehi, per la cronaca, stiamo usando queste fonti di dati. Stiamo creando queste feature. Stiamo creando questi dataset di addestramento.”. Poiché offriamo la versioning e diciamo che le feature sono un’entità immutabile di primo livello o cittadina, forniscono anche una versione e non devono mai preoccuparsi di sovrascrivere feature o avere feature con lo stesso nome.

Supponiamo tu abbia due data scientist che lavorano su un problema.

Stanno facendo una previsione del valore a vita del cliente per il nostro esempio di e-commerce. E forse è “spesa effettuata nei primi tre mesi del percorso del cliente” o quale campagna hanno scelto. Se due data scientist lavorano sulla stessa logica e entrambi inviano, fintanto che le versioni hanno nomi diversi, entrambe saranno registrate su quella feature.

Ciò ci consente anche di fornire il monitoraggio e la tracciatura. Aiutiamo a materializzare le trasformazioni, ma non archiviamo effettivamente i dati per le feature.

Versionamento di dataset e feature

Piotr: Miki, una domanda perché hai usato il termine “decoratore”. L’unico decoratore che mi viene in mente è un decoratore Python. Stiamo parlando di Python qui?

Mikiko Bazeley: Sì!

Piotr: Hai anche detto che possiamo versionare le feature, ma per quanto riguarda quello, concettualmente un dataset è un insieme di campioni, giusto? E un campione è composto da molte feature. Ciò mi porta a chiedere se si versionano anche i dataset con un feature store?

Mikiko Bazeley: Sì!

Piotr: Quindi qual è il legante tra le funzionalità versionate? Come possiamo rappresentare i set di dati?

Mikiko Bazeley: Non versioniamo i set di dati. Versioniamo le fonti, che includono anche le funzionalità, con la comprensione che puoi utilizzare le funzionalità come fonti per altri modelli.

Potresti utilizzare FeatureForm con uno strumento come DVC. Questo è venuto fuori più volte. Non siamo realmente interessati alla versione dei set di dati completi. Ad esempio, per le fonti, possiamo prendere tabelle o file. Se le persone apportano modifica a quella fonte o a quella tabella o a quel file, possono segnalarlo come una variante. E noi terremo traccia di quelle modifiche. Ma questo non è davvero l’obiettivo.

Vogliamo focalizzarci di più sul lato della progettazione delle funzionalità. E quindi, ciò che facciamo è versionare le definizioni. Ogni funzionalità è composta da due componenti. Sono i valori e la definizione. Poiché creiamo queste funzioni pure con FeatureForm, l’idea è che se hai lo stesso input e lo fai passare attraverso le definizioni che abbiamo memorizzato per te, allora lo trasformeremo e idealmente dovresti ottenere lo stesso output.

Aurimas: Se colleghi una pipeline di apprendimento automatico dopo un feature store e recuperi un set di dati, è già un insieme di funzionalità pre-calcolate che hai salvato nel tuo feature store. Per questo, probabilmente avresti bisogno di fornire un elenco di ID di entità, proprio come tutti gli altri feature store richiedono di fare, corretto? Quindi versioneresti questa lista di ID di entità più la logica di calcolo, in modo che la funzionalità versionata più la fonte sia un chunk riproducibile.

Faresti in questo modo, o ci sono altri modi di affrontare la situazione?

Mikiko Bazeley: Lasciami ripetere la domanda:

In sostanza, stai chiedendo se possiamo riprodurre risultati esatti? E come facciamo?

Aurimas: Per una sessione di training, sì.

Mikiko Bazeley: OK. Questo riguarda una dichiarazione che ho fatto precedentemente. Non versioniamo il set di dati o l’input di dati. Versioniamo le trasformazioni. Per quanto riguarda la logica effettiva, le persone possono registrare singole funzionalità, ma possono anche unire queste funzionalità insieme a un’etichetta.

Ciò che garantiamo è che qualsiasi cosa tu scriva per le tue funzionalità di sviluppo, la stessa logica esatta sarà replicata per la produzione. E lo facciamo attraverso il nostro client di servizio. Per quanto riguarda la garanzia sull’input, in questo caso come azienda diciamo: “Ehi, ci sono tantissimi strumenti per farlo”.

Questa è fondamentalmente la filosofia del feature store virtuale. Molte delle prime soluzioni di MLOps risolvevano i livelli inferiori, come “Quanto velocemente possiamo farlo?”, “Qual è la capacità?”, “Qual è la latenza?” Noi non facciamo questo. Per noi, pensiamo: “Ci sono così tante ottime opzioni là fuori. Non dobbiamo concentrarci su questo”.

Invece, ci concentriamo sulle parti che ci hanno detto essere davvero difficili. Ad esempio, minimizzare il divario tra addestramento e servizio e, in particolare, minimizzarlo standardizzando la logica che viene utilizzata, in modo che lo scienziato dei dati non debba scrivere il proprio pipeline di addestramento nella pipeline e quindi riscriverlo in Spark, SQL, o qualcos’altro. Non voglio dire che questa sia una garanzia di riproducibilità, ma cerchiamo almeno di dare una mano in questo senso.

Riguardo all’ID di entità: otteniamo l’ID di entità, ad esempio, dal team dell’interfaccia utente come una chiamata API. Finché l’ID di entità è lo stesso della funzionalità o delle funzionalità che stanno chiamando, è la versione corretta e dovrebbero ottenere lo stesso output.

Ecco alcune delle casistiche che le persone ci hanno segnalato. Ad esempio, se vogliono testare diverse logiche, potrebbero:

creare diverse versioni delle funzionalità,
creare diverse versioni dei set di addestramento,
alimentare una versione dei dati a modelli diversi.

Potrebbero fare studi di ablation per vedere quale modello ha funzionato bene e quali funzionalità si sono comportate bene, per poi tornare indietro al modello che ha ottenuto risultati migliori.

Il valore dei feature store

Piotr: Riassumendo, saresti d’accordo sul fatto che ciò che un feature store apporta all’insieme di strumenti di un team di apprendimento automatico è la versione della logica di progettazione delle funzionalità?

Se abbiamo una logica versionata per un determinato insieme di funzionalità che si desidera utilizzare per addestrare il modello e si desidera salvare da qualche parte un puntatore o ai dati sorgente che verranno utilizzati per calcolare funzionalità specifiche, allora ciò che otteniamo è essenzialmente la versione del dataset.

Quindi da un lato hai bisogno dei dati sorgente e devi versionarli in qualche modo, ma devi anche versionare la logica per elaborare i dati grezzi e calcolare le funzionalità.

Mikiko Bazeley: Direi che i tre o quattro punti principali della proposta di valore sono sicuramente la versione della logica. La seconda parte è la documentazione, che è una parte enorme. Penso che tutti abbiano avuto l’esperienza in cui guardano un progetto e non hanno idea del perché qualcuno abbia scelto la logica che ha scelto. Ad esempio, la logica per rappresentare un cliente o il valore di un contratto in un pipeline di vendita.

Quindi versione, documentazione, trasformazione e orchestrazione. Il modo in cui lo diciamo è “scrivi una volta, servilo due volte.” Offriamo questa garanzia. E poi, insieme all’aspetto dell’orchestrazione, ci sono anche cose come la pianificazione. Ma queste sono le tre cose principali:

Versione,
Documentazione,
Minimizzazione della distorsione del servizio di addestramento attraverso le trasformazioni.

Queste sono le tre cose principali che le persone ci chiedono.

Documentazione delle funzionalità in FeatureForm

Piotr: Come funziona la documentazione?

Mikiko Bazeley: Ci sono due tipi di documentazione. C’è, non voglio dire documentazione casuale, ma ci sono la documentazione attraverso il codice e la documentazione assistita.

Ad esempio, la documentazione assistita sono, ad esempio, le docstringhe. Puoi spiegare, “Ehi, questa è la logica della funzione, questo è quello che significano i termini, ecc. Offriamo questo.

Ma poi c’è anche la documentazione attraverso il codice il più possibile. Ad esempio, devi elencare la versione della funzionalità o del set di addestramento, o la sorgente che stai usando. Prova a suddividere anche il tipo di risorsa che viene creata. Almeno per la versione gestita di FeatureForm, offriamo anche governance, controllo degli accessi degli utenti e cose del genere. Offriamo anche la linea di discendenza delle funzionalità. Ad esempio, collegare una funzionalità al modello che viene utilizzato con essa. Cerchiamo di incorporare il più possibile la documentazione attraverso il codice.

Siamo sempre alla ricerca di diversi modi in cui possiamo continuare a espandere le capacità del nostro cruscotto per assistere con la documentazione assistita. Stiamo anche pensando ad altre modalità in cui i diversi membri del ciclo di vita dell’apprendimento automatico o del team di apprendimento automatico – sia quelli ovvi, come l’ingegnere MLOps, gli scienziati dei dati, ma anche le persone non ovvie, come gli avvocati – possono avere visibilità e accesso a quali funzionalità vengono utilizzate e con quali modelli. Questi sono i diversi tipi di documentazione che offriamo.

La piattaforma ML a Mailchimp e i casi d’uso di generative AI

Aurimas: Prima di unirti a FeatureForm come responsabile di MLOps, sei stato un ingegnere delle operazioni di apprendimento automatico presso Mailchimp e hai contribuito a costruire la piattaforma di apprendimento automatico lì, giusto? Quali problemi stavano risolvendo gli scienziati dei dati e gli ingegneri di apprendimento automatico presso Mailchimp?

Mikiko Bazeley: C’erano un paio di cose. Quando mi sono unita a Mailchimp, c’era già un team di piattaforma lì. Era una situazione molto interessante, in cui i MLOps e le preoccupazioni della piattaforma di apprendimento automatico erano approssimativamente divisi tra tre team.

C’era il team in cui ero io, che era molto concentrato su creare strumenti e configurare l’ambiente per lo sviluppo e la formazione degli scienziati dei dati, oltre ad aiutare con il lavoro effettivo di produzione.
C’era un team focalizzato sul servizio dei modelli live.
E c’era un team che era in costante evoluzione. Hanno iniziato facendo integrazioni di dati, e poi sono diventati il team di monitoraggio dell’apprendimento automatico. È più o meno quello che hanno fatto da quando sono andata via.

In generale, in tutti i team, il problema che stavamo cercando di risolvere era: Come possiamo fornire una produzione passiva per gli scienziati dei dati presso Mailchimp, dato tutti i diversi tipi di progetti su cui stavano lavorando.

Ad esempio, Mailchimp è il primo posto in cui ho visto una forte applicazione del valore aziendale per l’intelligenza artificiale generativa. Ogni volta che un’azienda presenta capacità di intelligenza artificiale generativa, il punto di riferimento per me è Mailchimp, solo perché avevano un caso d’uso così forte per essa.

Aurimas: Era la generazione di contenuti?

Mikiko Bazeley: Oh, sì, assolutamente. È utile capire cosa fa Mailchimp per avere un contesto aggiuntivo.

Mailchimp è un’azienda di 20 anni con sede ad Atlanta, in Georgia. Una delle ragioni per cui è stata acquistata per così tanti soldi è perché è anche la più grande… Non voglio dire fornitore. Hanno la più grande lista di email negli Stati Uniti perché hanno iniziato come soluzione di marketing via email. Ma quello che molte persone, penso, non sono consapevoli è che negli ultimi anni hanno compiuto grandi passi per diventare una specie di negozio tutto-in-uno per piccole imprese di dimensioni VoAGI che vogliono fare e-commerce.

C’è ancora il marketing via email. È una parte enorme di ciò che fanno, quindi NLP è molto importante lì, ovviamente. Ma offrono anche cose come la creazione di contenuti per i social media, siti web digitali virtuali per l’e-commerce, ecc. In sostanza hanno cercato di posizionarsi come il CRM front-end per piccole imprese di dimensioni VoAGI. Sono stati acquistati da Intuit per diventare la parte front-end delle operazioni di Intuit nel back-office, come QuickBooks e TurboTax.

Con questo contesto, l’obiettivo di Mailchimp è fornire le cose di marketing. In altre parole, le cose che le piccole imprese familiari devono fare. Mailchimp cerca di rendere più semplice e automatizzato tutto ciò.

Uno dei casi d’uso principali su cui stavano lavorando con l’AI generativa era questo: Immaginiamo che tu sia un proprietario di un’impresa familiare che gestisce un negozio di magliette o candele. Sei il proprietario unico o potresti avere due o tre dipendenti. La tua attività è piuttosto snella. Non hai i soldi per permetterti un designer o una persona di marketing a tempo pieno.

Puoi rivolgerti a Fiverr, ma a volte hai solo bisogno di inviare email per promozioni natalizie.

Anche se è un lavoro di poco valore, se dovessi assumere un appaltatore per farlo, richiederebbe parecchio sforzo e denaro. Una delle cose che Mailchimp offriva attraverso il loro prodotto o servizio di creative studio, mi sono dimenticato il nome esatto, era questa:

Poi Leslie dice: “Ehi, ok, adesso, dammi alcuni modelli

Immaginiamo che Leslie, proprietaria del negozio di candele, voglia inviare quell’email natalizia. Quello che può fare è accedere al creative studio e dire: “Ecco il mio sito web o negozio o quello che è, genera per me una serie di modelli per le email”. La prima cosa che farebbe è generare foto di stock e le palette di colori per la tua email.

Poi Leslie dice: “Ehi, ok, adesso, dammi alcuni modelli per scrivere la mia email natalizia, ma fai attenzione al mio marchio”, quindi considerando il suo tono di voce e il suo stile di comunicazione. Elencerebbe quindi altri tipi di dettagli sul suo negozio. Quindi, ovviamente, genererebbe il testo dell’email. Successivamente, Leslie dice: “Ok, voglio diverse versioni di questa email per poter fare test A/B”. Boom! Lo farebbe…

La ragione per cui penso che questo sia un caso di utilizzo aziendale così forte è perché Mailchimp è il più grande fornitore. Intenzionalmente non dico fornitore di email perché non forniscono le email, sono i –

Piotr: … i mittenti?

Mikiko Bazeley: Sì, sono i più grandi provider sicuri di email per le aziende. Quindi Leslie ha una lista di email che ha già costruito. Può fare un paio di cose. La sua lista di email è segmentata – anche questo è qualcosa che Mailchimp offre. Mailchimp consente agli utenti di creare campagne basate su determinati trigger che possono personalizzare da soli. Offrono una bella interfaccia utente per questo. Quindi, Leslie ha tre liste di email. Ha i grandi spenditori, i VoAGI spenditori e i piccoli spenditori.

Può collegare i diversi modelli di email a queste diverse liste e, in sostanza, ha quella automazione end-to-end direttamente correlata alla sua attività. Per me, questa era una forte proposta di valore aziendale. Molto di questo è dovuto al fatto che Mailchimp ha costruito una “palizzata difensiva” attraverso il prodotto e la loro strategia che hanno sviluppato in 20 anni.

Per loro, le capacità di intelligenza artificiale generativa che offrono sono in linea diretta con la loro mission statement. Non è neanche il prodotto. Il prodotto è “rendiamo la tua vita super facile come proprietario di un’azienda piccola o di dimensioni VoAGI che potrebbe già avere una lista di 10.000 email e interazioni con il proprio sito web e il proprio negozio”. Ora, offrono anche capacità di segmentazione e automazione – di solito devi rivolgerti a Zapier o ad altri fornitori per farlo.

Credo che Mailchimp stia beneficiando enormemente della nuova ondata. Non posso dire lo stesso per molte altre aziende. Vederlo come ingegnere di piattaforme di intelligenza artificiale quando ero lì era molto emozionante perché mi ha esposto molto presto alle sfide di lavorare non solo con pipeline multitransmodelli, che avevamo sicuramente, ma anche con test e validazione dell’intelligenza artificiale generativa o dei LLM.

Ad esempio, se li hai nel tuo sistema o nella tua pipeline di modelli, come li valuti effettivamente? Come li monitori? La cosa più grande che molti team sbagliano è effettivamente il feedback del prodotto dati dei loro modelli.

Le aziende e i team non capiscono davvero come integrare tutto ciò per arricchire ulteriormente le loro iniziative di data science e machine learning e anche i prodotti che sono in grado di offrire.

Piotr: Miki, la conclusione divertente è che i saluti che riceviamo dalle aziende durante le vacanze non solo non sono personalizzati, ma anche il testo non è stato scritto da una persona.

Mikiko Bazeley: Ma sono personalizzati. Sono personalizzati per la tua persona.

Episodio del podcast correlato

Distribuzione di prodotti di intelligenza artificiale conversazionale in produzione con Jason Flaks

Scopri di più

Problemi di intelligenza artificiale generativa in Mailchimp e monitoraggio del feedback

Piotr: È giusto. Comunque, hai detto qualcosa di molto interessante: “Le aziende non sanno come trattare i dati di feedback”, e penso che con i problemi di intelligenza artificiale generativa sia ancora più sfidante perché il feedback è meno strutturato.

Puoi condividere con noi come è stato fatto in Mailchimp? Che tipo di feedback era e cosa hanno fatto i tuoi team? Come ha funzionato?

Mikiko Bazeley: Posso dire che quando me ne sono andata, le iniziative di monitoraggio erano appena iniziate. Di nuovo, è utile capire il contesto con Mailchimp. Sono un’azienda privata di 20 anni che non ha mai ricevuto finanziamenti VC.

Hanno ancora dei data center fisici che affittano e possiedono armadi server. Hanno iniziato solo di recente la transizione verso il cloud – forse meno di otto anni fa o più vicino a sei.

Questa è una grande decisione che forse alcune aziende dovrebbero considerare. Invece di spostare l’intera azienda nel cloud, Mailchimp ha detto: “Per ora, faremo movimentare le iniziative di data science e machine learning emergenti, inclusi tutti i data engineer necessari per supportarle. Manterremo tutti gli altri nel vecchio stack per il momento”.

Poi, hanno iniziato lentamente a migrare shard nel cloud e a valutarlo. Essendo un’azienda privata con una chiara direzione strategica, sono stati in grado di prendere decisioni tecnologiche in termini di anni anziché trimestri – a differenza di alcune aziende tecnologiche.

Cosa significa in termini di feedback? Significa che c’è un feedback generato attraverso i dati del prodotto che viene restituito al prodotto stesso – gran parte di questo era nel vecchio stack centrale.

I data engineer dell’organizzazione di data science/machine learning erano principalmente incaricati di trasferire i dati e copiare i dati dal vecchio stack a GCP, che era dove risiedevamo. Lo stack dei data scientist/machine learning su GCP includeva BigQuery, Spanner, Dataflow e AI Platform Notebooks, che ora è Vertex. Utilizzavamo anche Jenkins, Airflow, Terraform e alcuni altri.

Ma il grande ruolo degli ingegneri dei dati era inviare quei dati al lato della scienza dei dati e dell’apprendimento automatico. Per i ricercatori di dati e gli esperti di apprendimento automatico, c’era una latenza di circa un giorno per i dati.

In quel momento, era molto difficile fare certe cose. Potevamo creare modelli di servizio in tempo reale – che era un pattern molto comune – ma molti modelli dovevano essere addestrati offline. Li abbiamo trasformati in un servizio attivo, esposto il punto di accesso API e così via. Ma c’era una latenza di circa uno o due giorni.

Detto questo, qualcosa su cui stavano lavorando, ad esempio, era… ed è qui che deve avvenire una stretta integrazione con le esigenze dei prodotti.

Un feedback che era stato dato riguardava la creazione di campagne – quello che chiamiamo “costruttore di percorsi”. Molti proprietari di piccole imprese e imprese di medie dimensioni sono il CEO, il CFO, il CMO, fanno tutto da soli. Dicono: “Questo è in realtà complicato. Puoi suggerire come creare campagne per noi?” Questo feedback è arrivato attraverso i prodotti.

Lo scienziato dei dati responsabile di quel progetto ha detto: “Sto costruendo un modello che darà una raccomandazione per i prossimi tre passaggi o le prossime tre azioni che un proprietario può intraprendere per la sua campagna”. Poi abbiamo tutti lavorato con gli ingegneri dei dati per dire: “Ehi, riusciamo a ottenere questi dati?”

Anche qui entra in gioco il reparto legale e dice: “Ci sono restrizioni legali?” E poi sostanzialmente abbiamo ottenuto quei dati nei set di dati che potevano essere utilizzati nei modelli.

Piotr: Questo feedback non riguarda i dati ma più un feedback qualitativo basato sulle esigenze espresse dagli utenti del prodotto, giusto?

Mikiko Bazeley: Ma penso che tu abbia bisogno di entrambe le cose.

Aurimas: Lo hai.

Mikiko Bazeley: Non penso che si possa avere un feedback sui dati senza coinvolgere i team dei prodotti e dell’interfaccia utente. Ad esempio, un luogo molto comune per ottenere un feedback è quando si condivide una raccomandazione, giusto? O ad esempio, gli annunci su Twitter.

Puoi dire “Questo annuncio è rilevante per te?”. È sì o no. Questo rende molto semplice offrire questa opzione nell’interfaccia utente. E penso che molti pensino che l’implementazione di un feedback sui dati sia molto facile. Quando dico “facile”, non intendo che non richieda una forte comprensione del design sperimentale. Ma supponendo che tu abbia quella comprensione, ci sono molti strumenti come i test A/B, le previsioni e i modelli. Quindi, puoi semplicemente scrivere i risultati su una tabella. In realtà non è difficile. Quello che invece è difficile molte volte è ottenere l’adesione dei diversi team di ingegneria, perché sono disposti a implementarlo.

Una volta che hai fatto questo e hai l’esperimento, il sito web e il modello a cui era collegato, la parte dei dati è facile, ma penso che sia difficile ottenere il consenso del prodotto e coinvolgere il team di ingegneria o di business nel vedere il valore strategico nell’arricchire i nostri set di dati.

Ad esempio, quando ero al Data Council la settimana scorsa, c’era un panel sulle intelligenze artificiali generative. Quello che ho capito da quella discussione è che i dati noiosi e l’infrastruttura di machine learning contano molto. E contano ancora di più ora.

Gran parte di questa infrastruttura MLOps non andrà via. Anzi, diventa ancora più importante. La grande discussione era del tipo: “Oh, stiamo finendo con il corpus pubblico di dati su cui addestrarci e perfezionarci”. E cosa intendono è che stiamo finendo con insiemi di dati accademici di alta qualità in inglese da utilizzare nei nostri modelli. Quindi la gente si chiede: “Che cosa succede se finiamo con i set di dati sul web?” E la risposta è che si torna ai dati di prima parte, ai dati che tu, come azienda, possiedi effettivamente e puoi controllare.

È la stessa discussione che è stata fatta quando Google ha detto: “Ehi, elimineremo la possibilità di tracciare dati di terze parti”. Molte persone hanno cominciato ad agitarsi. Se sviluppi quel sistema di raccolta dei feedback e lo allinei con i tuoi sforzi di apprendimento automatico, allora non dovrai preoccuparti. Ma se sei un’azienda che si avvale solo di API di tipo OpenAI, ad esempio, allora dovresti preoccuparti perché non offrirai un valore che nessun altro potrebbe offrire.

Vale lo stesso per l’infrastruttura di Machine Learning, giusto?

Avvicinarsi al business come ingegnere MLOps

Piotr: La base di partenza è appena salita, ma per essere competitivi, per fare qualcosa di più, devi ancora avere qualcosa di proprietario.

Mikiko Bazeley: Esatto, al 100%. Ecco proprio dove penso che gli ingegneri MLOps e i data engineer pensino troppo come ingegneri…

Piotr: Puoi spiegare meglio?

Mikiko Bazeley: Non voglio solo dire che considerano le sfide come questioni tecniche. Molte volte ci sono sfide tecniche. Ma molte volte, ciò di cui hai bisogno è tempo, spazio di manovra e investimenti. Spesso significa allineare la tua conversazione con gli obiettivi strategici dell’azienda.

Credo che molti data engineer e ingegneri MLOps non siano bravi con questo. Penso che i data scientist siano spesso migliori in questo senso.

Piotr: Perché devono avere a che fare più spesso con l’aspetto commerciale, giusto?

Mikiko Bazeley: Esatto!

Aurimas: E gli sviluppatori non forniscono valore direttamente…

Mikiko Bazeley: È come la salute pubblica, vero? Tutti sottovalutano la salute pubblica finché non ti trovi a morire a causa di un’infezione da acqua. È estremamente importante, ma le persone non sempre riconoscono la sua importanza. Inoltre, la affrontano da una prospettiva “questa è la soluzione tecnica migliore” anziché “questo creerà un immenso valore per l’azienda”. Le aziende si preoccupano solo di due o tre cose:

1 Generare più ricavi o profitti
2 Ridurre i costi o ottimizzarli
3 Una combinazione di entrambi i punti sopra.

Se gli ingegneri MLOps e i data engineer riescono ad allineare i loro sforzi, soprattutto nel costruire un insieme di strumenti per l’apprendimento automatico, una persona del settore commerciale o persino il responsabile dell’ingegneria penserà: “Perché abbiamo bisogno di questo strumento? È solo un’altra cosa che la gente qui non userà”.

La strategia per contrastare ciò è pensare a quali indicatori chiave di prestazione e metriche sono importanti per loro. Mostrare l’impatto su quelle metriche. La parte successiva è offrire un piano di azione e un piano di manutenzione.

Ho osservato che i team di successo delle piattaforme di apprendimento automatico, fanno l’opposto delle storie che si sentono spesso. Molte storie su costruzione di piattaforme di apprendimento automatico si sviluppano così: “Abbiamo creato questa cosa nuova e poi abbiamo introdotto questo strumento per farla funzionare. E la gente l’ha apprezzata e usata”. Questa è solo un’altra versione di “se la costruisci, verranno”, e non è così che funziona.

Devi leggere tra le righe delle storie di molte piattaforme di apprendimento automatico di successo. Quello che hanno fatto è prendere un’area o una fase del processo che era già in movimento ma non era ottimale. Ad esempio, forse avevano già un percorso verso la produzione per il rilascio di modelli di apprendimento automatico, ma funzionava molto male.

Cosa facevano i team era costruire una soluzione parallela molto migliore e poi invitare o incorporare i data scientist in quel percorso. Facevano le cose manualmente associate all’adozione degli utenti: è tutto un “fare cose che non si escalano”, sai. Fare workshop. Aiutarli a far entrare il loro progetto.

Il punto chiave è offrire qualcosa che sia veramente migliore. Quando i data scientist o gli utenti hanno una base di partenza del tipo “Facciamo già questa cosa, ma fa schifo”, e tu offri loro qualcosa di migliore, penso che ci sia un termine chiamato “valore differenziato” o qualcosa del genere: hai essenzialmente una base di utenti di data scientist che possono fare più cose.

Se vai da una persona del settore commerciale o dal tuo CTO e dici: “Sappiamo già che abbiamo 100 data scientist che cercano di lanciare modelli. Ci mettono così tanto tempo. Non solo possiamo ridurre quel tempo a metà, ma possiamo farlo in modo che siano più contenti e non lasceranno l’azienda. E ciò ci porterà ancora più valore perché questi sono gli obiettivi che vogliamo raggiungere. Ci vorranno circa sei mesi per farlo, ma possiamo assicurarci di ridurre a tre mesi”. Poi puoi mostrare quei punti di riferimento e misurazioni, oltre a offrire un piano di manutenzione.

Molte di queste conversazioni non riguardano la supremazia tecnica. Si tratta di come socializzare quell’iniziativa, di come allinearla alle preoccupazioni dei tuoi leader esecutivi e fare il duro lavoro per ottenere l’adozione della piattaforma di apprendimento automatico.

Storie di successo delle capacità della piattaforma di intelligenza artificiale presso Mailchimp

Aurimas: Hai delle storie di successo da Mailchimp? Quali pratiche suggeriresti per comunicare con i team di intelligenza artificiale? Come ottenete il feedback da loro?

Mikiko Bazeley: Sì, assolutamente. Ci sono un paio di cose che abbiamo fatto bene. Inizierò da Autodesk per contestualizzarti.

Quando lavoravo presso Autodesk ricoprivo un ruolo ibrido di scienziato dei dati e analista dei dati. Autodesk è un’azienda orientata al design. Ci fanno seguire molti corsi come il design thinking e impariamo come raccogliere storie degli utenti. Questo è qualcosa che ho imparato anche durante gli studi di antropologia: come creare ciò che chiamano etnografie, ossia, “come ci si avvicina alle persone, si impara sulle loro pratiche, si capisce cosa gli interessa, si parla la loro lingua”.

Quella è stata la prima cosa che ho fatto quando mi sono unita al team. Mi sono resa conto che avevamo tutti questi ticket su Jira. Avevamo tante cose su cui poter lavorare. Il team stava lavorando in tante direzioni diverse, quindi ho pensato, “Ok, innanzitutto, assicuriamoci di avere tutti lo stesso punto di partenza su ciò che è veramente importante”.

Quindi ho fatto un paio di cose. La prima cosa è stata analizzare i ticket che avevamo creato. Sono tornata indietro sulle storie degli utenti, ho parlato con gli scienziati dei dati, ho parlato con le persone del team della piattaforma di intelligenza artificiale, ho creato un processo per raccogliere il feedback. Ognuno di noi doveva valutare o raggruppare il feedback in modo indipendente e poi “dimensionare” gli sforzi. Da lì, abbiamo potuto stabilire una road map grezza o un piano da seguire.

Una delle cose che abbiamo individuato è stata quella dei template. I template erano un po’ confusionari. Inoltre, in quel periodo era stato rilasciato il Mac M1, che aveva causato dei problemi con Docker. La parte dello strumento di template consisteva essenzialmente nel creare un’immagine di Docker e popolarla con le configurazioni in base al tipo di progetto di intelligenza artificiale che stavano svolgendo. Volevamo evitare lo sviluppo locale.

Tutti i nostri scienziati dei dati stavano lavorando nei notebook della nostra piattaforma AI. Dopo di che, dovevano scaricare il lavoro localmente e poi caricarlo su di un’istanza separata di GitHub e così via. Volevamo davvero semplificare questo processo il più possibile e trovare un modo per collegare il notebook della piattaforma AI.

Avresti creato un template all’interno di GCP, che poi avresti potuto caricare su GitHub, il quale avrebbe innescato il CI/CD e in seguito il processo di distribuzione. Quello è stato un progetto a cui ho lavorato. Sembra che abbia aiutato. Ho lavorato sulla V1 di quello, e successivamente altre persone l’hanno sviluppato ulteriormente. Ora, gli scienziati dei dati ideali non devono più passare da quel strano ciclo di push-pull tra remoto e locale durante lo sviluppo.

È stato davvero divertente lavorare su quello perché avevo questa idea degli scienziati dei dati, e anche nel mio lavoro, che si sviluppasse localmente. Ma era un processo un po’ disconnesso. C’è stato qualche altra cosa anche. Ma il continuo andirivieni tra lo sviluppo remoto e quello locale era la cosa principale. È stato un processo difficile anche perché dobbiamo pensare a come collegarlo a Jenkins e a come aggirare la VPC e cose del genere.

Un libro che sto leggendo di recente e che mi piace molto si intitola “Kill It With Fire” di Marianne Bellotti. Parla di come aggiornare sistemi legacy, come modernizzarli senza buttarli via. Questo era il grosso del lavoro che stavo facendo a Mailchimp.

Fino a questo punto della mia carriera, ero abituata a lavorare per startup dove l’iniziativa di intelligenza artificiale era molto nuova e dove dovevi costruire tutto da zero. Non avevo capito che quando si costruisce un servizio o un’attrezzatura di intelligenza artificiale per un’azienda di grandi dimensioni, è molto più difficile. Ci sono molte più limitazioni su cosa si può realmente utilizzare.

Ad esempio, non potevamo utilizzare GitHub Actions a Mailchimp. Sarebbe stato bello, ma non potevamo. Avevamo uno strumento di template esistente e un processo che gli scienziati dei dati stavano già utilizzando. Esisteva, ma era subottimale. Quindi come avremmo potuto ottimizzare un’offerta che fossero disposti ad utilizzare veramente? Siamo stati in grado di imparare molte cose, ma il ritmo in un ambiente aziendale è molto più lento rispetto a quello che si può fare sia in una startup che come consulente. Quindi, questo è l’unico svantaggio. Molte volte il numero di progetti su cui puoi lavorare è circa un terzo di quello che si potrebbe fare altrove, ma è stato molto affascinante.

Articolo correlato

Costruire una piattaforma di apprendimento automatico [Guida definitiva]

Struttura del team presso Mailchimp

Aurimas: Sono molto interessato a sapere se i data scientist erano gli utenti diretti della piattaforma o se c’erano anche ingegneri di apprendimento automatico coinvolti in qualche modo, forse incorporati nelle squadre di prodotto?

Mikiko Bazeley: Ci sono due risposte a questa domanda. Mailchimp aveva una cultura orientata al design e all’ingegneria. Molti dei data scientist che lavoravano lì, specialmente quelli più di successo, avevano esperienza precedente come ingegneri del software. Anche se il processo era un po’ complicato, molte volte riuscivano a trovare modi per lavorare con esso.

Ma negli ultimi due, tre anni, Mailchimp ha iniziato a assumere data scientist che erano più orientati verso il prodotto e il business. Non avevano esperienza come ingegneri del software. Ciò significava che avevano bisogno di un po’ di aiuto. Pertanto, ogni squadra coinvolta in MLOps o nelle iniziative della piattaforma di apprendimento automatico aveva quello che chiamavamo “ingegneri di MLOps incorporati”.

Era una sorta di ruolo simile a quello di un ingegnere di apprendimento automatico, ma non esattamente. Ad esempio, non costruivano i modelli per i data scientist. Avevano il compito di aiutare solo nell’ultimo miglio verso la produzione. Il modo in cui di solito mi piace pensare a un ingegnere di apprendimento automatico è come a un data scientist full-stack. Ciò significa che scrivono le funzionalità e sviluppano i modelli. Avevamo persone che erano lì solo per aiutare i data scientist a portare avanti il loro progetto nel processo, ma non costruivano i modelli.

I nostri utenti principali erano i data scientist, solo loro. Avevamo persone che li aiutavano con cose come rispondere a ticket, domande su Slack e aiutare a dare priorità ai bug. Questo veniva quindi riportato alle persone dell’ambiente ingegneria che si occupavano di risolverlo. Ogni squadra aveva questa combinazione di persone che si concentravano sullo sviluppo di nuove funzionalità e strumenti e persone che dedicavano circa il 50% del loro tempo ad aiutare i data scientist.

Intuit aveva acquisito Mailchimp circa sei mesi prima della mia partenza, e di solito ci vogliono circa sei mesi perché i cambiamenti inizino effettivamente a manifestarsi. Penso che abbiano riorganizzato le squadre in modo tale che molte delle risorse di abilitazione fossero ora in un’unica squadra e gli ingegneri di piattaforma fossero in un’altra squadra. Ma prima, mentre ero lì, ogni squadra aveva una combinazione di entrambe.

Piotr: Quindi non c’era un team centrale per la piattaforma di apprendimento automatico?

Mikiko Bazeley: No. Era essenzialmente suddiviso tra formazione e sviluppo, e quindi erogazione, e quindi monitoraggio e integrazioni.

Aurimas: È comunque un team di piattaforma centrale, ma composto da più squadre snellite. Fanno parte di un team di piattaforma, probabilmente fornendo capacità di piattaforma, come nelle topologie di squadra.

Mikiko Bazeley: Sì, esatto.

Piotr: Condividevano una stack tecnologico e dei processi o ogni squadra di apprendimento automatico con data scientist e supporto aveva il proprio ambito, stack tecnologico e processi. O avevate iniziative per condividere alcune basi, ad esempio, hai menzionato l’uso di modelli utilizzati da diverse squadre.

Mikiko Bazeley: La maggior parte dello stack era condivisa. Penso che il modo di descrivere le squadre nelle organizzazioni secondo le topologie di squadra sia davvero fantastico. È un modo fantastico per descriverlo. Perché c’erano quattro squadre, giusto? Ci sono le squadre snellite, che in questo caso sono data science e prodotto. Ci sono squadre di sottosistemi complessi, come ad esempio la squadra di Terraform o la squadra di Kubernetes. E ci sono l’abilitazione e la piattaforma.

Ogni squadra era una combinazione di piattaforma e abilitazione. Ad esempio, le risorse che condividevamo erano BigQuery, Spanner e Airflow. Ma la differenza è, e penso che questo sia qualcosa che molte squadre di piattaforma effettivamente trascurano: l’obiettivo del team di piattaforma non è sempre quello di possedere un tool specifico, o uno strato specifico dello stack. Molte volte, se sei così grande da avere quelle specializzazioni, l’obiettivo del team di piattaforma è mettere insieme non solo gli strumenti esistenti, ma occasionalmente anche portare nuovi strumenti in un’esperienza unificata per l’utente finale, che per noi erano i data scientist. Anche se condividevamo BigQuery, Airflow e tutte queste grandi cose, altre squadre utilizzavano quelle risorse anche loro. Ma potrebbero non essere interessate, ad esempio, a distribuire modelli di apprendimento automatico in produzione. Potrebbero non essere coinvolte affatto in quell’aspetto.

Cosa abbiamo fatto è stato dire: “Ehi, saremo essenzialmente le vostre guide per consentire l’utilizzo di questi altri strumenti interni. Creeremo e forniremo astrazioni”. Di tanto in tanto, avremmo anche introdotto strumenti che pensavamo fossero necessari. Ad esempio, uno strumento che non veniva utilizzato dal team di produzione era Great Expectations. Non l’hanno effettivamente utilizzato perché è qualcosa che si usa principalmente nello sviluppo e nella formazione, non in produzione.

C’erano anche un paio d’altre cose… Scusa. Non riesco a pensarle tutte di getto, ma c’erano tre o quattro altri strumenti che gli scienziati dei dati dovevano usare nello sviluppo e nella formazione, ma non ne avevano bisogno per la produzione. Abbiamo incorporato quegli strumenti nei percorsi verso la produzione.

Il livello di servizio era un sottile client Python che prendeva i contenitori o le immagini Docker utilizzate per i modelli. Veniva quindi esposto al punto di accesso API in modo che i team all’inizio potessero instradare qualsiasi richiesta per ottenere previsioni dai modelli.

Lo stack di pipelining

Piotr: Hai utilizzato qualche strumento di pipelining? Ad esempio, per consentire il riallenamento automatico o semiautomatico dei modelli. Oppure gli scienziati dei dati facevano semplicemente l’addestramento di un modello, lo impacchettavano in un’immagine Docker e quindi era un po’ ‘chiuso’?

Mikiko Bazeley: Avevamo progetti in varie fasi di automazione. Airflow era uno strumento importante che abbiamo utilizzato. Quello che tutti in azienda hanno usato. L’interazione con Airflow è stata la seguente: Con Airflow, molto spesso è necessario creare il proprio DAG manualmente. Spesso, questo può essere automatizzato, specialmente se si esegue lo stesso tipo di pipeline di apprendimento automatico incorporata nel template cookiecutter. Quindi abbiamo detto: “Quando stai configurando il tuo progetto, attraversi una serie di domande di intervista. Hai bisogno di Airflow? Sì o no?” Se rispondevano “sì”, quella parte sarebbe stata compilata automaticamente con le informazioni pertinenti sul progetto e tutto il resto. E poi avremmo sostituito le credenziali.

Piotr: Come sapevano se ne avevano bisogno o meno?

Mikiko Bazeley: Questa è effettivamente una parte del lavoro di ottimizzazione del template cookiecutter. Quando sono arrivata, gli scienziati dei dati dovevano compilare molte di queste domande. Ho bisogno di Airflow? Ho bisogno di XYZ? E per la maggior parte del tempo, spesso dovevano chiedere agli ingegneri abilitanti “Ehi, cosa dovrei fare?”

A volte c’erano progetti che avevano bisogno di una consulenza di progettazione un po’ più approfondita, come “Possiamo supportare questo modello o questo sistema che stai cercando di costruire con i percorsi esistenti che offriamo?” E poi li aiutavamo a capirlo, così potevano andare avanti e configurare il progetto.

È stato un dolore quando avrebbero impostato il progetto e poi l’avremmo guardato e detto: “No, questo è sbagliato. In realtà devi fare quest’altra cosa.” E avrebbero dovuto ripetere la creazione del progetto. Una cosa che abbiamo fatto come parte dell’ottimizzazione è stato dire: “Scegli semplicemente un modello e noi completeremo tutte le configurazioni per te”. La maggior parte di loro ha potuto capire abbastanza facilmente. Ad esempio: “Sarà un lavoro di previsione a batch in cui devo solo copiare i valori? Sarà un modello di servizio live?” Questi due modelli erano abbastanza facili da capire per loro, quindi potevano procedere dicendo: “Hey, questo è quello che voglio.” Potevano semplicemente utilizzare l’immagine progettata per quel lavoro specifico.

Il processo di creazione del template sarebbe stato eseguito e poi avrebbero potuto completarlo. “Oh, questo è il nome del progetto, yada, yada…” Non dovevano compilare la versione di Python. Sarebbe stata impostata automaticamente alla versione più stabile e aggiornata, ma se avessero avuto bisogno della versione 3.2 e Python fosse a 3.11, avrebbero specificato quella. A parte questo, idealmente, avrebbero dovuto essere in grado di fare il loro lavoro di scrivere le funzionalità e sviluppare i modelli.

Un’altra cosa interessante era che stavamo considerando di offrire loro il supporto nativo di Streamlit. Questo faceva anche parte del processo. Gli scienziati dei dati creavano i modelli iniziali. E poi creavano un’applicazione di Streamlit. Lo mostravano al team di prodotto e il team di prodotto lo utilizzava per prendere decisioni del tipo “sì” o “no” così che gli scienziati dei dati potessero procedere con il progetto.

Più importantemente, se i nuovi membri del team di prodotto desiderassero unirsi e fossero interessati a un modello, cercando di capire come funzionava questo modello o quali capacità offriva. Allora potrebbero andare alla libreria Streamlit o gli scienziati dei dati potrebbero inviargli il link, e potrebbero attraversarlo e vedere rapidamente cosa faceva un modello.

Aurimas: Questo sembra un ambiente UAT, giusto? Test di accettazione dell’utente in pre-produzione.

Piotr: Forse più come “tech stack on demand”? Come specificare quale è il tuo progetto e ottenere il tech stack e la configurazione. Un esempio di come sono stati realizzati progetti simili che avevano la stessa configurazione.

Mikiko Bazeley: Sì, intendo, così dovrebbe essere per gli scienziati dei dati, giusto?

Piotr: Quindi non fornivi solo un tech stack universale per i team di ML di Mailchimp, ma avevano una selezione. Erano in grado di avere un tech stack più personalizzato per progetto.

Dimensione dell’organizzazione di ML in Mailchimp

Aurimas: Quante strade supportavi? Perché so di team il cui unico compito era creare nuovi template di repository quotidianamente per supportare circa 300 casi d’uso.

Piotr: Quanto era grande quel team? E quanti modelli di ML avevi?

Mikiko Bazeley: Il team di scienziati dei dati era composto da 20-25 persone, credo. E in termini dell’aspetto ingegneristico, c’erano sei persone nel mio team, potrebbe esserci stata una squadra di sei persone per il servizio, un’altra squadra di sei persone per le integrazioni e il monitoraggio dei dati. E poi c’era un’altra squadra che era responsabile della piattaforma dei dati. Quindi erano molto vicini all’ingegneria dei dati, giusto?

Avrebbero aiutato a mantenere e possedevano copie dei dati dal vecchio stack di Mailchimp a BigQuery e Spanner. C’erano un paio di altre cose che facevano, ma quella era la più importante. Assicurarsi anche che i dati fossero disponibili per casi d’uso di analisi.

E ci sono persone che utilizzavano quei dati che non erano necessariamente coinvolte negli sforzi di ML. Quella squadra era composta da circa sei otto persone. Quindi in totale, avevamo circa 24 ingegneri per 25 scienziati dei dati, più tutti i prodotti e i professionisti dell’analisi dei dati che utilizzavano i dati.

Aurimas: Ho capito correttamente che avevi 18 persone nei vari team di piattaforma per 25 scienziati dei dati? Hai detto che c’erano sei persone in ogni team.

Mikiko Bazeley: Il terzo team era distribuito su diversi progetti, il recente era il monitoraggio. Non si erano interessati alle iniziative della piattaforma ML fino a circa tre mesi prima che io lasciassi Mailchimp.

Prima di ciò, stavano lavorando sulle integrazioni dei dati, il che significava che erano molto più allineati agli sforzi dell’analisi e dell’ingegneria; erano totalmente diversi dal lato della scienza dei dati.

Credo che abbiano assunto di recente più scienziati dei dati. Hanno anche assunto più ingegneri di piattaforma. E penso che stiano cercando di allineare Mailchimp più da vicino a Intuit, in particolare a Quickbooks. Stanno anche cercando di sviluppare continuamente ulteriori capacità di ML, che sono molto importanti per la visione strategica a lungo termine di Mailchimp e Intuit.

Piotr: E Miki, ti ricordi quanti modelli di ML avevate in produzione quando lavoravi lì?

Mikiko Bazeley: Penso che il minimo fosse di 25-30. Ma stavano sicuramente creando molti altri. E alcuni di quei modelli erano effettivamente modelli di insieme, pipeline di insieme. Era un quantitativo piuttosto significativo.

La parte più difficile che il mio team stava risolvendo e a cui stavo lavorando era l’attraversamento del baratro tra sperimentazione e produzione. Con molte delle cose su cui abbiamo lavorato mentre ero lì, inclusa l’ottimizzazione del progetto di templating, siamo riusciti a ridurre significativamente lo sforzo per configurare i progetti e l’ambiente di sviluppo.

Non mi sorprenderebbe se abbiano, non voglio dire raddoppiato quel numero, ma almeno aumentato significativamente il numero di modelli in produzione.

Piotr: Ricordi quanto tempo ci voleva di solito per passare dall’idea alla risoluzione di un problema utilizzando il machine learning per avere un modello di machine learning in produzione? Qual era il tempo medio o mediano?

Mikiko Bazeley: Non mi piace l’idea di misurare dall’idea, perché ci sono molte cose che possono accadere sul lato del prodotto. Ma supponendo che tutto sia andato bene dal lato del prodotto e che non abbiano cambiato idea, e supponendo che i data scientist non fossero sovraccarichi, potrebbe comunque richiedere loro alcuni mesi. In gran parte ciò era dovuto a fare cose come convalidare la logica – quello era un grande punto – e ottenere l’approvazione del prodotto.

Piotr: Convalidare la logica? Cosa intendi?

Mikiko Bazeley: Ad esempio, convalidare il set di dati. Con convalida, non intendo la qualità. Intendo l’interpretazione semantica, creando diversi modelli, creando diverse caratteristiche, condividendo quel modello con il team del prodotto e con gli altri data scientist, assicurandoci di avere l’architettura giusta per supportarlo. E poi, ad esempio, cose come assicurarsi che le nostre immagini Docker supportino le GPU se un modello ne avesse bisogno. Richiederebbe almeno un paio di mesi.

Piotr: Ero sul punto di chiedere dei fattori chiave. Cosa ha richiesto più tempo?

Mikiko Bazeley: Inizialmente, abbiamo avuto difficoltà con l’esperienza end-to-end. È stato un po’ difficile lavorare con squadre diverse. Questo era il feedback che avevo raccolto quando sono arrivata lì.

Essenzialmente, i data scientist si sarebbero rivolti al team di sviluppo e ambiente di addestramento, quindi si sarebbero rivolti al team di servizio e distribuzione e avrebbero dovuto lavorare con un team diverso. Un feedback era: “Ehi, dobbiamo superare tutti questi ostacoli diversi e non è un’esperienza super unificata.”

L’altro problema con cui abbiamo lottato era la roadmap strategica. Ad esempio, quando sono arrivata lì, persone diverse stavano lavorando su progetti completamente diversi e a volte non era nemmeno visibile di che progetti si trattasse. A volte, un progetto era meno incentrato sulla “utilità per i data scientist” e più sul “voleva l’ingegnere su quel progetto?” o “Era il suo progetto preferito?” C’erano un sacco di quelli.

Quando me ne sono andata, il lead tecnico lì, Emily Curtin – è fantastica, tra l’altro, ha fatto alcuni ottimi interventi su come abilitare i data scientist con le GPU. Lavorare con lei è stato fantastico. Il mio manager all’epoca, Nadia Morris, che è ancora lì, tra noi tre e il lavoro di altre persone, siamo riusciti a ottenere una migliore allineamento della roadmap per iniziare effettivamente a orientare tutti gli sforzi verso la creazione di un’esperienza più unificata.

Ad esempio, ci sono anche altre pratiche in cui alcuni di questi ingegneri che avevano i loro progetti preferiti, costruivano qualcosa in un periodo di due, tre notti, e poi lo spedivano ai data scientist senza alcun test, senza nulla, e dicevano, “oh sì, data scientist, devi usare questo.”

Piotr: Si chiama passione *ride*

Mikiko Bazeley: È come dire: “Aspetta, perché non hai fatto creare un periodo di testing internamente.” E quindi, sai, ora dobbiamo aiutare i data scientist perché stanno avendo tutti questi problemi con questi strumenti di progetti preferiti.

Potevamo sistemarlo. Potevamo assicurarci che fosse privo di bug. E poi, avremmo potuto impostarlo come un vero e proprio processo di abilitazione in cui creiamo alcuni tutorial o scritti o organizziamo delle ore di ufficio in cui lo mostriamo.

Molte volte, i data scientist lo guardavano e dicevano: “Sì, non lo usiamo, continueremo a fare quello che stiamo facendo perché anche se non è ottimale, almeno non è rotto.”

Post correlato

Ruoli nel team di apprendimento automatico e come collaborano tra loro

Percorsi d’oro a Mailchimp

Aurimas: C’è stato qualche caso in cui qualcosa è stata creata all’interno di un team allineato allo stream che era così buono da decidere di includerlo nella piattaforma come una funzionalità?

Mikiko Bazeley: Questa è una domanda molto interessante. Personalmente, non lo faccio. Non credo, ma molto spesso i data scientist, specialmente quelli senior e molto bravi, provano gli strumenti e poi tornano al team dicendo “Hey, questo sembra davvero interessante”. Penso che sia più o meno quello che è successo quando hanno esaminato WhyLabs, ad esempio.

Ecco come penso sia successo. C’erano anche altre opportunità, ma per lo più stavamo costruendo una piattaforma per rendere la vita di tutti più facile. A volte, questo significava sacrificare un po’ di novità e penso che sia qui che i team delle piattaforme sbagliano a volte.

Spotify ha scritto un articolo sul blog a riguardo, sui golden path, giusto? Hanno un percorso d’oro, un percorso d’argento e un percorso di bronzo o di rame o qualcosa del genere.

Il percorso d’oro è il miglior supportato. “Se hai qualche problema con questo, questo è quello che supportiamo, questo è quello che manterremo. Se hai qualche problema con questo, daremo priorità a quel bug, lo risolveremo”. E funzionerà per l’85% dei casi d’uso, dall’85% al 90%.

Il percorso d’argento include elementi del percorso d’oro, ma ci sono alcune cose che non sono realmente o direttamente supportate, ma su cui siamo consultati e informati. Se pensiamo di poterle integrare nel percorso d’oro, lo faremo, ma devono esserci abbastanza casi d’uso per farlo.

A quel punto, diventa una discussione su “dove spendiamo le risorse di ingegneria?” Per esempio, ci sono alcuni progetti come Creative Studio, giusto? È un progetto super innovativo. È stato anche molto difficile da supportare. Ma MailChimp ha detto: “Hey, dobbiamo offrire questo, dobbiamo usare l’IA generativa per semplificare la nostra offerta di prodotti per i nostri utenti”. A quel punto diventa una discussione su “quanto tempo dei nostri ingegneri possiamo dedicare a lavorare su questo sistema?”

E anche in quei progetti, non c’è poi tanta differenza in termini di supporto infrastrutturale come la gente penserebbe. Soprattutto con l’IA generativa e gli LLM, dove si ottiene il maggior impatto in termini di infrastruttura e operazioni è la latenza, è un fattore enorme. La seconda parte è la privacy dei dati – è un fattore molto, molto importante. E poi c’è la parte di monitoraggio e valutazione. Ma per molte altre cose… A monte, se si ha ciò che serve da parte dei provider giusti, non cambierà significativamente, ad esempio, un sistema di raccomandazioni basato su NLP.

Quindi avevamo un percorso d’oro, ma potevamo avere anche dei percor

Riguardo ad altri ultimi pensieri, so che ci sono molte persone che provano molta ansia ed eccitazione per tutte le nuove cose successe negli ultimi sei mesi. Alcune persone sono preoccupate per il loro lavoro.

Piotr: Intendi modelli di base?

Mikiko Bazeley: Sì, modelli di base, ma c’è molto di più in corso nello spazio del ML (Machine Learning). Il mio consiglio per le persone sarebbe che, innanzitutto, tutta la noiosa infrastruttura di ML e dati e le competenze legate sono più importanti che mai. Quindi è sempre ottimo avere una solida preparazione in modellazione dei dati, programmazione, test e migliori pratiche, che non perderanno mai di valore.

Il secondo consiglio è che io credo che le persone, indipendentemente dal titolo che hanno o che desiderano avere, dovrebbero concentrarsi nel mettere le mani sui progetti, comprendere le aree adiacenti e imparare a parlare il linguaggio del business.

Se devo essere davvero onesto, non sono il migliore ingegnere o scienziato dei dati là fuori. Sono pienamente consapevole dei miei punti deboli e delle mie forze, ma la ragione per cui sono stato in grado di fare così tante svolte nella mia carriera e di ottenere il successo che ho ottenuto è in gran parte dovuto al fatto che cerco di comprendere il settore e i team con cui lavoro, specialmente i centri di ricavo o di profitto, come li chiamano le persone. Questo è estremamente importante. È una competenza. Una competenza relazionale e di conoscenza che le persone dovrebbero acquisire.

E le persone dovrebbero condividere i loro apprendimenti sui social media. Questo ti darà lavori e sponsorizzazioni.

Aurimas: Grazie per i tuoi pensieri e grazie per aver dedicato del tempo a parlare con noi. È stato davvero incredibile. E grazie a tutti coloro che hanno ascoltato. Ci vediamo nell’episodio successivo!

MLOps