Per i progetti ML sono necessari team con membri che dispongono di competenze, competenze e responsabilità. Questi sono i ruoli più comuni trovati nei team ML tipici:
| Ruolo | Conoscenze e competenze | Prodotto principale |
|---|---|---|
| Product manager ML | I product manager ML hanno una profonda comprensione dei punti di forza e dei punti deboli del machine learning e del processo di sviluppo del ML. Allineano i problemi aziendali alle soluzioni ML lavorando direttamente con il team ML, gli utenti finali e altre parti interessate. Creano la vision dei prodotti, definiscono i casi d'uso e i requisiti e pianificano e assegnano priorità ai progetti. |
Documento sui requisiti del prodotto (PRD). Per un esempio di PRD per il rilevamento di anomalie ML, consulta PRD per il rilevamento di anomalie. |
| Responsabile ingegneristico | I manager ingegneristici raggiungono gli obiettivi aziendali definendo, comunicando e raggiungendo le priorità del team. Come i product manager ML, allineano le soluzioni ML ai problemi aziendali. Stabilire aspettative chiare per i membri del team, valutano le prestazioni e forniscono assistenza nella carriera e nello sviluppo professionale. |
Progettare documenti, piani di progetto e valutazioni delle prestazioni. Per un esempio di documento di progettazione ML, vedi go/ml-design-doc-example. |
| Data scientist | I data scientist utilizzano analisi quantitative e statistiche per estrarre insight e valore dai dati. Consentono di identificare e testare le caratteristiche, i prototipi dei modelli e contribuiscono all'interpretabilità dei modelli. | Report e visualizzazioni di dati che rispondono alle domande aziendali attraverso analisi statistiche. |
| ML engineer | Gli ML engineer progettano, creano, eseguono la produzione e gestiscono i modelli ML. Sono ingegneri del software forti con una profonda conoscenza delle tecnologie e delle best practice ML. | Modello di cui è stato eseguito il deployment con una qualità di previsione sufficiente per raggiungere gli obiettivi aziendali. |
| Data engineer | I data engineer creano pipeline di dati per l'archiviazione, l'aggregazione e l'elaborazione di grandi quantità di dati. Sviluppano l'infrastruttura e i sistemi per la raccolta e la trasformazione dei dati non elaborati in formati utili per l'addestramento e la pubblicazione dei modelli. I data engineer sono responsabili dei dati nell'intero processo di sviluppo ML. | Pipeline di dati completamente in produzione con il monitoraggio e gli avvisi necessari. |
| Ingegnere delle operazioni di sviluppo (DevOps) | Gli ingegneri DevOps sviluppano, eseguono il deployment, scalano e monitorano l'infrastruttura di gestione per i modelli di ML. | Un processo automatizzato per la pubblicazione, il monitoraggio, il test e la generazione di avvisi sul comportamento di un modello. |
Per i progetti ML di successo ci sono team con ciascun ruolo ben rappresentato. Nei team più piccoli, i singoli utenti dovranno gestire le responsabilità per più ruoli. In questi casi, strumenti AutoML come Vertex AI possono essere d'aiuto automatizzando le attività di ML, come lo sviluppo, la comprensione e il deployment dei modelli.
Stabilire pratiche di team
Poiché i ruoli, gli strumenti e i framework variano notevolmente nello sviluppo ML, è fondamentale stabilire pratiche comuni tramite un'eccellente documentazione di processo. Ad esempio, un ingegnere potrebbe pensare che ottenere i dati giusti sia sufficiente per iniziare ad addestrare un modello, mentre un ingegnere più responsabile convaliderà la corretta anonimizzazione del set di dati e ne documenterà i metadati e la provenienza. Assicurarsi che gli ingegneri condividano le definizioni comuni dei processi e dei pattern di progettazione riduce la confusione e aumenta la velocità del team.
Documentazione del processo
La documentazione dei processi deve definire gli strumenti, l'infrastruttura e i processi che il team utilizzerà per lo sviluppo ML. La presenza di una buona documentazione di processo aiuta ad allineare i membri nuovi e attuali. Dovrebbero rispondere ai seguenti tipi di domande:
- Come vengono generati i dati per il modello?
- Come esaminiamo, convalidiamo e visualizziamo i dati?
- Come si modifica una funzionalità o un'etichetta di input nei dati di addestramento?
- Come personalizziamo la pipeline di generazione, addestramento e valutazione dei dati?
- Come faccio a modificare l'architettura del modello per adattarsi alle modifiche alle caratteristiche di input o alle etichette?
- Come otteniamo esempi di test?
- Quali metriche verranno utilizzate per valutare la qualità del modello?
- Come lanciamo i nostri modelli in produzione?
- Come facciamo a sapere se c'è qualcosa che non va nel nostro modello?
- Da quali sistemi upstream dipendono dai nostri modelli?
- Come faccio a rendere il mio SQL gestibile e riutilizzabile?
Un documento Google con un elenco di queste domande è disponibile all'indirizzo go/ml-list-of-questions.
Altre potenziali domande
ModelloPosso addestrare modelli su set di dati diversi nella stessa pipeline, ad esempio per l'ottimizzazione?
Come faccio ad aggiungere un nuovo set di dati di test alla mia pipeline?
Come posso verificare la previsione del modello su un esempio creato manualmente?
Come faccio a trovare, esaminare e visualizzare esempi in cui il modello ha commesso errori?
Come faccio a determinare quale funzionalità è stata maggiormente responsabile di una determinata previsione?
Come faccio a capire quali funzionalità hanno il maggiore impatto sulle previsioni all'interno di un determinato campione?
Come faccio a calcolare o tracciare le previsioni dei modelli su un set di dati o un campione scelto?
Come faccio a calcolare metriche standard per le previsioni del mio modello su un set di dati scelto?
Come faccio a sviluppare e calcolare metriche personalizzate?
Come posso confrontare il mio modello con altri modelli offline?
Posso eseguire una meta-analisi per più valutazioni di modelli in un singolo ambiente di sviluppo?
Posso confrontare il modello attuale con quello di 10 mesi fa?
Penso di aver creato un buon modello. Come posso lanciarlo in produzione?
Come faccio a verificare che il mio nuovo modello venga eseguito correttamente in produzione?
Posso visualizzare la cronologia delle valutazioni dei modelli nel tempo?
Come faccio a sapere se qualcosa non va nel modello?
Mi è stata assegnata una pagina/un bug in cui veniva menzionato qualcosa sul modello. Che cosa devo fare?
Come posso personalizzare la pipeline di generazione/addestramento/valutazione dei dati?
Quando e come devo creare una pipeline completamente nuova?
Ho bisogno di SQL per generare alcuni dati. Dove devo inserirlo?
Come funziona la pubblicazione del nostro modello? Esiste un diagramma?
Da quali sistemi upstream dipende il mio modello di cui dovrei essere a conoscenza?
Non riesco a capire. Chi (e come) devo contattare?
Aspetti da considerare
Ciò che costituisce "best practice per il ML" può variare tra aziende, team e privati. Ad esempio, alcuni membri del team potrebbero considerare i Colab sperimentali come principali contenuti da consegnare, mentre altri potrebbero voler lavorare in R. Alcuni potrebbero avere una passione per l'ingegneria del software, altri pensano che il monitoraggio sia l'aspetto più importante, ma qualcun altro è a conoscenza di buone pratiche di produzione delle funzionalità, ma vuole utilizzare Scala. Ognuno ha ragione dal punto di vista personale e, se guidato correttamente, il mix sarà un concentrato di energia. Altrimenti, può essere un disastro.
Stabilire gli strumenti, i processi e l'infrastruttura che il team userà prima di scrivere una riga di codice può fare la differenza tra il fallimento del progetto dopo due anni o il lancio riuscito con un trimestre di anticipo rispetto ai tempi previsti.
Valutazioni del rendimento
A causa dell'ambiguità e dell'incertezza intrinseche nel machine learning, le persone manager devono definire aspettative chiare e definire in anticipo i risultati finali.
Nel determinare le aspettative e i risultati finali, considera come verranno valutati se un progetto o un approccio non ha successo. In altre parole, è importante che le prestazioni di un membro del team non siano direttamente collegate al successo del progetto. Ad esempio, non è raro che i membri del team passino settimane a cercare soluzioni che alla fine non hanno successo. Anche in questi casi, il codice di alta qualità, la documentazione approfondita e una collaborazione efficace devono contribuire positivamente alla loro valutazione.