La pila postmoderna

Se ricordate la nostra panoramica del panorama, i team che operano su scala ragionevole sono piccole startup in rapida crescita o team che stanno avviando una pratica di ML in un’azienda grande ma tradizionale (una startup all’interno di un’impresa, se volete): la velocità per chiudere il ciclo di feedback è tutto ciò che vogliono, quindi NoOps è ciò di cui hanno bisogno. In particolare, il nostro approccio al ciclo di vita del ML mette in evidenza l’importanza di non spendere tempo di progettazione iniziale per supportare una scala e una sofisticazione che non sono certamente necessarie al primo giorno (e forse nemmeno al primo giorno).

Rispetto ai tutorial del “mondo dei giocattoli”, il nostro progetto ha il vantaggio di crescere con voi: se avete bisogno di sostituire X con Y al giorno 1000, il resto degli strumenti potrebbe essere ancora in perfetta sintonia tra loro.

Vogliamo concludere la nostra serie evidenziando alcune implicazioni di questo approccio sul modo in cui le organizzazioni lavorano e concepiscono lo sviluppo di dati e ML per i loro prodotti.

– Efficienza al di là degli effettivi. Consideriamo le metriche tradizionali, come l’organico della R&S: un approccio MLOps moderno può mettere in discussione alcuni principi consolidati che ruotano intorno a questo aspetto. Ad esempio, l’adozione di un moderno approccio MLOps significa che i costi delle merci vendute (COGS) possono comprendere un conto AWS più elevato, ma la manodopera diretta coinvolta nella produzione di beni e servizi sarà probabilmente inferiore. Inoltre, ciò significa anche che le metriche tradizionali, come l’organico di R&S o il numero di brevetti depositati, potrebbero dover essere riconsiderate e potrebbero essere necessari parametri di riferimento diversi. Poiché il mondo della tecnologia sta cambiando rapidamente, il nostro approccio alle metriche deve tenerne conto.

– Verticalità flessibile. Il ML sta diventando un componente di prodotto importante per molte aziende (e Coveo è certamente una di queste). La scomoda verità sulla possibilità di incorporare le funzionalità di ML in un prodotto è che gli ingegneri di ML devono essere addestrati al problema aziendale tanto quanto all’ottimizzazione degli iperparametri. Per questo motivo, avere più di 10 data scientist in un’unità orizzontale indipendente potrebbe non essere la strada giusta da percorrere, in quanto li distacca dal campo e rallenta il ciclo di feedback tra dati e decisioni. In alternativa, si potrebbe pensare di inserire i ninja del ML direttamente nelle unità aziendali, in modo che possano apprendere i problemi di business in prima persona. L’unico problema è che se le unità aziendali non sono preparate ad assorbire gli ingegneri di ML, è facile che finiscano per avere un impatto minore di quanto ci si aspetterebbe. L’adozione di pratiche MLOps forti è un modo per rendere la verticalizzazione del team di ML più consapevole, in quanto le business unit possono assorbire i Data Scientist in modo più efficiente. La topologia MLOps a “scala ragionevole” si presenta come una via di mezzo tra verticale e orizzontale – una forma a T, se volete: alcuni componenti orizzontali sono presenti per rendere tutti produttivi e per riutilizzare le conoscenze e le competenze (ad esempio, l’adozione diffusa di Metaflow); ma poi le funzionalità sono sviluppate verticalmente all’interno delle linee di business, tenendo conto della specificità del caso d’uso.

– Trattenere i talenti: stare lontani dall’infrastruttura. Probabilmente la conseguenza più importante di questo approccio è che gli MLOp possono servire come parte della proposta per attrarre e trattenere i talenti critici. Scambiando un maggior numero di calcoli con un minor impegno umano, si otterrà un piccolo e felice team di ML, nettamente migliore di un gruppo più grande e meno focalizzato. La maggior parte dei talenti tecnici è entusiasta di svolgere un lavoro all’avanguardia con i migliori strumenti, concentrandosi su problemi impegnativi e vedendo l’impatto del proprio lavoro nella produzione. Senza la giusta pratica MLOps, i migliori talenti si sentiranno rapidamente frustrati dal fatto di lavorare su attività transazionali e di non vedere il loro lavoro avere un impatto tangibile sul business. Quindi, una spesa AWS forse maggiore è spesso compensata da un tasso di fidelizzazione più elevato e da una maggiore produttività dei ML. Come ha affermato McKinsey in un articolo sul “Grande logorio”, le aziende vogliono i migliori e si tengono i peggiori, e una delle ragioni principali del turnover dei professionisti del ML è il fatto di dedicare una parte considerevole del loro tempo a compiti a basso impatto, come la preparazione dei dati e la manutenzione dell’infrastruttura.

Infine, l’adozione del nostro approccio MLOps avrà un chiaro impatto sulle decisioni strategiche prese dai CFO e li renderà più felici.

È diffusa l’idea che un modo efficiente di gestire la spesa per la R&S comporti la riduzione dei costi infrastrutturali. Ma questo è spesso un modo fuorviante di vedere le cose. Acquistare piuttosto che costruire può portare a stime e previsioni più accurate del COGS, soprattutto per le linee di business meno mature e più sperimentali: proverbialmente, il tempo è davvero denaro, e le infrastrutture possono sembrare molto più economiche se viste alla luce del costo opportunità di una lenta esplorazione. Inoltre, abbiamo spesso riscontrato che i costi effettivi di costruzione e manutenzione delle infrastrutture in una startup sono meno prevedibili nel tempo di quanto la maggior parte delle persone possa pensare. Non solo è estremamente facile sottovalutare lo sforzo totale richiesto nel lungo periodo, ma ogni volta che si crea un team al solo scopo di costruire un’infrastruttura si introduce la quintessenza dell’imprevedibilità del fattore umano.