
Questo post del blog è una versione aggiornata di parte di un discorso alla conferenza che ho tenuto su GOTO Amsterdam l'anno scorso. Il discorso è disponibile anche per guarda online.
In qualità di Product Manager di Machine Learning, sono affascinato dall'intersezione tra Machine Learning e Product Management, in particolare quando si tratta di creare soluzioni che forniscano valore e un impatto positivo sul prodotto, sull'azienda e sugli utenti. Tuttavia, riuscire a fornire questo valore e questo impatto positivo non è un lavoro facile. Uno dei motivi principali di questa complessità è il fatto che, nelle iniziative di Machine Learning sviluppate per i prodotti digitali, si intersecano due fonti di incertezza.
Dal punto di vista della gestione del prodotto, il campo è incerto per definizione. È difficile sapere l’impatto che una soluzione avrà sul prodotto, come gli utenti reagiranno e se migliorerà o meno i parametri del prodotto e del business… Dover lavorare con questa incertezza è ciò che rende i Product Manager potenzialmente diversi da altri ruoli come Project Manager o Product Owner. Strategia di prodotto, scoperta del prodotto, dimensionamento delle opportunità, definizione delle priorità, sperimentazione agile e rapida sono alcune strategie per superare questa incertezza.
Anche il campo del Machine Learning ha un forte legame con l’incertezza. Mi piace sempre dire “Con i modelli predittivi, l’obiettivo è prevedere cose che non sai essere prevedibili”. Ciò si traduce in progetti difficili da definire e gestire, nell’impossibilità di impegnarsi in anticipo per un risultato finale di qualità (buone prestazioni del modello) e in molte iniziative che rimangono per sempre come POC offline. Definire bene il problema da risolvere, l’analisi e l’esplorazione iniziale dei dati, iniziare in piccolo ed essere vicini al prodotto e al business, sono azioni che possono aiutare ad affrontare l’incertezza del ML nei progetti.
Mitigare questo rischio di incertezza fin dall’inizio è fondamentale per sviluppare iniziative che finiscano per fornire valore al prodotto, all’azienda e agli utenti. In questo post del blog approfondirò le mie 3 principali lezioni apprese quando ho avviato iniziative di prodotti ML per gestire questa incertezza fin dall'inizio. Questi apprendimenti si basano principalmente sulla mia esperienza, prima come Data Scientist e ora come Product Manager ML, e sono utili per aumentare la probabilità che una soluzione ML raggiunga la produzione e abbia un impatto positivo. Preparati a esplorare:
- Inizia con il problema e definisci come verranno utilizzate le previsioni fin dall'inizio.
- Inizia in piccolo e mantienilo piccolo se puoi.
- Dati, dati e dati: qualità, volume e storico.
Devo ammettere che l'ho imparato nel modo più duro. Sono stato coinvolto in progetti in cui, una volta sviluppato il modello e stabilito che le prestazioni della previsione erano “sufficientemente buone”, le previsioni del modello non erano realmente utilizzabili per nessun caso d'uso specifico o non erano utili per risolvere eventuali problemi.
Ci sono molte ragioni per cui ciò può accadere, ma quelle che ho riscontrato più frequentemente sono:
- Iniziative orientate alla soluzione: già prima che GenAI, Machine Learning e modelli predittivi fossero soluzioni “cool”, e per questo alcune iniziative sono partite dalla soluzione ML: “proviamo a prevedere il tasso di abbandono” (utenti o clienti che abbandonano un’azienda), “proviamo a prevedere i segmenti di utenti”… L’attuale campagna pubblicitaria GenAI ha peggiorato questa tendenza, esercitando pressioni sulle aziende affinché integrino le soluzioni GenAI “ovunque” si adattino.
- Mancanza di progettazione end-to-end della soluzione: in pochissimi casi, il modello predittivo è una soluzione autonoma. Di solito, però, i modelli e le loro previsioni sono integrati in un sistema più grande per risolvere un caso d’uso specifico o abilitare una nuova funzionalità. Se questa soluzione end-to-end non viene definita fin dall’inizio, può succedere che il modello, una volta già implementato, si riveli inutile.
Per avviare un'iniziativa di machine learning con il piede giusto, è fondamentale: iniziare con il problema buono da risolvere. Questo è fondamentale nella gestione del prodotto e viene regolarmente rafforzato dai leader di prodotto Marty Cagan E Melissa Perry. Include la scoperta del prodotto (attraverso interviste agli utenti, ricerche di mercato, analisi dei dati…) e il dimensionamento e la definizione delle priorità delle opportunità (tenendo conto di dati quantitativi e qualitativi).
Una volta identificate le opportunità, il il secondo passo è esplorare le possibili soluzioni per il problema, che dovrebbe includere tecniche di Machine Learning e GenAI, se possono aiutare a risolvere il problema.
Se si deciderà di sperimentare una soluzione che preveda l'utilizzo di modelli predittivi, il il terzo passo sarebbe quello di definire e progettare end-to-end della soluzione o del sistema. In questo modo, possiamo garantire i requisiti su come utilizzare le previsioni da parte del sistema, influenzare la progettazione e l'implementazione del pezzo predittivo (cosa prevedere, dati da utilizzare, tempo reale vs batch, controlli di fattibilità tecnica…).
Tuttavia vorrei aggiungere che potrebbe esserci una notevole eccezione in questo argomento. Partire dalle soluzioni GenAI, anziché dal problema, può avere senso se questa tecnologia finirà per rivoluzionare davvero il tuo settore o il mondo come lo conosciamo. Ci sono molte discussioni a riguardo, ma direi che non è ancora chiaro se ciò accadrà o meno. Finora abbiamo assistito a questa rivoluzione in settori molto specifici (assistenza clienti, marketing, design…) e legati all'efficienza delle persone nello svolgimento di determinati compiti (codificazione, scrittura, creazione…). Per la maggior parte delle aziende, tuttavia, a meno che non venga considerato lavoro di ricerca e sviluppo, fornire valore a breve/medio termine dovrebbe comunque significare concentrarsi sui problemi e considerare GenAI come qualsiasi altra potenziale soluzione ad essi.
Anche le esperienze difficili portano a questo apprendimento. Quelle esperienze avevano in comune un grande progetto ML definito a cascata. Il tipo di progetto che durerà 6 mesi e seguirà il ciclo di vita del ML fase per fase.
Cosa potrebbe andare storto, vero? Permettimi di ricordarti la mia citazione precedente “Con i modelli predittivi, l’obiettivo è prevedere cose che non sai essere prevedibili”! In una situazione come questa, può succedere che arrivi al quinto mese del progetto e durante la valutazione del modello ti rendi conto che non è possibile che il modello sia in grado di prevedere tutto ciò di cui ha bisogno con una qualità sufficientemente buona. O peggio, arrivi al sesto mese, con un super modello messo in produzione, e ti accorgi che non apporta alcun valore.
Questo rischio si combina con le incertezze relative al prodotto e rende obbligatorio evitare, se possibile, grandi iniziative a cascata. Questo non è qualcosa di nuovo o correlato solo alle iniziative ML, quindi c'è molto che possiamo imparare dallo sviluppo software tradizionale, Agile, Lean e altre metodologie e mentalità. Iniziando in piccolo, convalidando le ipotesi in modo rapido e continuo e sperimentando e scalando in modo iterativo, possiamo mitigare efficacemente questo rischio, adattarci alle informazioni ed essere più efficienti in termini di costi.
Sebbene questi principi siano ben consolidati nello sviluppo tradizionale di software e prodotti, la loro applicazione alle iniziative di machine learning è un po’ più complessa, poiché non è facile definire “piccolo” un modello e un’implementazione di machine learning. Esistono, tuttavia, alcuni approcci che possono aiutare a iniziare in piccolo le iniziative di machine learning.
Approcci basati su regolesemplificare un modello predittivo attraverso un albero decisionale. In questo modo, le “previsioni” possono essere facilmente implementate come “istruzioni if-else” in produzione come parte della funzionalità o del sistema, senza la necessità di implementare un modello.
Prove di concetto (POC), come un modo per convalidare offline la fattibilità predittiva della soluzione ML e suggerire il potenziale (o meno) del passaggio predittivo una volta in produzione.
Prodotti minimi vitali (MVP), per concentrarsi innanzitutto su caratteristiche, funzionalità o segmenti di utenti essenziali ed espandere la soluzione solo se il valore è stato dimostrato. Per un modello ML ciò può significare, ad esempio, solo le funzionalità di input prioritarie più semplici o la previsione solo per un segmento di punti dati.
Acquista invece di costruire, sfruttare le soluzioni o le piattaforme ML esistenti per contribuire a ridurre i tempi di sviluppo e i costi iniziali. Solo quando si dimostrerà utile e i costi aumenteranno troppo, potrebbe essere il momento giusto per decidere di sviluppare internamente la soluzione ML.
Utilizzando GenAI come MVP, per alcuni casi d'uso (soprattutto se coinvolgono testo o immagini), le API genAI possono essere utilizzate come primo approccio per risolvere la fase di previsione del sistema. Attività come la classificazione del testo, l'analisi del sentiment o il rilevamento delle immagini, in cui i modelli GenAI forniscono risultati impressionanti. Una volta convalidato il valore e se i costi aumentano troppo, il team può decidere di costruire internamente uno specifico modello ML “tradizionale”.
Si noti che utilizzare modelli GenAI per la classificazione di immagini o testo, sebbene possibile e veloce, significa utilizzare un modello troppo grande e complesso (costoso, mancanza di controllo, allucinazioni…) per qualcosa che potrebbe essere previsto con uno molto più semplice e controllabile. Un'analogia divertente sarebbe l'idea di consegnare una pizza con un camion: è fattibile, ma perché non usare semplicemente la bicicletta?
I dati sono il problema ricorrente che i data scientist e i team di machine learning incontrano quando avviano iniziative di machine learning. Quante volte sei rimasto sorpreso da dati con duplicati, errori, lotti mancanti, valori strani… E quanto sono diversi dai set di dati giocattolo che trovi nei corsi online!
Può anche succedere che i dati di cui hai bisogno semplicemente non ci siano: il tracciamento dell'evento specifico non è mai stato implementato, la raccolta e gli ETL corretti sono stati implementati di recente… Ho sperimentato come questo si traduca nel dover aspettare alcuni mesi per poter avviare un progetto con dati storici e di volume sufficienti.
Tutto ciò si riferisce al detto “Immondizia dentro, spazzatura fuori”: I modelli ML sono validi quanto lo sono i dati su cui sono addestrati. Molte volte, le soluzioni hanno un potenziale maggiore per essere migliorate migliorando i dati piuttosto che migliorando i modelli (IA incentrata sui dati). I dati devono essere sufficienti in termini di volume, storici (i dati generati nel corso degli anni possono apportare più valore rispetto allo stesso volume generato in una sola settimana) e di qualità. Per raggiungere questo obiettivo, la governance, la raccolta, la pulizia e la preelaborazione dei dati sono fondamentali.
Dal IA etica Da questo punto di vista, i dati sono anche una fonte primaria di pregiudizi e discriminazioni, quindi riconoscerlo e agire per mitigare questi rischi è fondamentale. Considerando i principi di governance dei dati, privacy e conformità normativa (ad es GDPR), è fondamentale anche per garantire un uso responsabile dei dati (soprattutto quando si tratta di dati personali).
Con Modelli GenAI questo è fondamentale: enormi volumi di dati sono già utilizzati per addestrarli. Quando utilizziamo questi tipi di modelli, potremmo non aver bisogno di dati sul volume e sulla qualità per l'addestramento, ma potremmo averne bisogno per la messa a punto (vedi Buoni dati = buona GenAI), o per costruire i suggerimenti (nutrimento del contesto, apprendimento a breve termine, recupero di generazione aumentata… — Ho spiegato tutti questi concetti in un messaggio precedente!).
È importante notare che utilizzando questi modelli stiamo perdendo il controllo dei dati utilizzati per addestrarli e possiamo soffrire della mancanza di qualità o tipo di dati utilizzati lì: ci sono molti esempi noti di bias e discriminazione nei risultati di GenAI che possono avere un impatto negativo sulla nostra soluzione. Un buon esempio è stato l'articolo di Bloomberg su come “In che modo ChatGPT è lo strumento ideale per un reclutatore: i test dimostrano che esistono pregiudizi razziali”. Classifiche LLM che verificano i pregiudiziO LLM appositamente formati per evitare questi pregiudizi può essere utile in questo senso.
Abbiamo iniziato questo post sul blog discutendo di ciò che rende le iniziative di prodotti ML particolarmente complicate: la combinazione dell'incertezza relativa allo sviluppo di soluzioni nei prodotti digitali, con l'incertezza relativa al tentativo di prevedere le cose attraverso l'uso di modelli ML.
È confortante sapere che sono disponibili misure e strategie attuabili per mitigare questi rischi. Ma forse le migliori riguardano proprio far partire le iniziative con il piede giusto! Per fare ciò, può davvero essere utile iniziare con il problema giusto e una progettazione end-to-end della soluzione, ridurre l’ambito iniziale e dare priorità alla qualità dei dati, al volume e all’accuratezza storica.
Spero che questo post sia stato utile e che ti aiuti a mettere alla prova il modo in cui inizi a lavorare in future nuove iniziative relative ai prodotti ML!
Fonte: towardsdatascience.com