Anche con uno stack perfetto di strumenti MLOps, i team hanno ancora difficoltà a fornire prodotti ML. Quindi, se gli strumenti non sono l'unico pezzo del puzzle, cosa rimane? Nel mio ultimo post , sostengo che i pezzi rimanenti sono Cultura e Processo.

Analizziamo il processo MLOps, in particolare alcuni dei pezzi fondamentali che la maggior parte dei team sbaglia . Che aspetto ha un processo MLOps di successo e in che modo i singoli professionisti del machine learning possono aiutare a costruire tale processo?

TL; DR

• Inizia con un prodotto, non un modello
• Esamina i dati in produzione , non nel tuo magazzino
• Inizia in modo semplice, con dati e modelli
• Collabora con gli ingegneri

Inizia con un prodotto ML

Forse la pratica più importante che consente progetti ML di successo è progettare un prodotto , non un modello . Una delle più grandi insidie ​​che ho riscontrato in dozzine di aziende è consegnare i "progetti" ai team di dati, invece di coinvolgerli nella fase di progettazione del prodotto.

Per costruire un prodotto ML di successo, tre parti interessate devono essere coinvolte nella progettazione del prodotto:

• PM / Stakeholder aziendale : Che aspetto ha il successo?
• Persona ML : Cosa è (probabilmente) possibile con ML?
• Ingegnere di prodotto : cosa è fattibile e quali sono i vincoli?

Alcuni esempi di team scarsamente allineati:

• La persona ML ottimizza per l'accuratezza del modello (invece che per i risultati aziendali!)
• Progetti avviati che potrebbero non essere risolvibili con ML
• Il modello non soddisfa i vincoli prestazionali in produzione
• Le funzionalità sono impegnative o impossibili da calcolare in produzione

• La persona ML comprende i compromessi tra accuratezza e time-to-market
• Monitoraggio costruito il giorno zero per garantire che i risultati aziendali siano misurati in modo coerente
• L'ingegnere aiuta la persona ML a comprendere il panorama dei dati di produzione
• Gli SLA modello sono chiaramente definiti e misurati

Questo è un esempio di "buon allineamento" nell'ultima sezione, ma merita una sezione a parte. Quasi tutti i builder ML che ho visto iniziare i loro progetti ML con un sondaggio dei dati disponibili. Il problema? In genere esaminano i dati disponibili per l'addestramento , non i dati che saranno disponibili in produzione.

Qualcuno potrebbe chiedere: tutti i dati disponibili per la formazione non dovrebbero essere disponibili in un sistema di produzione?

La maggior parte delle volte la risposta è sì , ma con un mucchio di asterischi. In quanto tempo sono disponibili i dati? Quanto sono freschi quei dati? Quanta preelaborazione deve essere eseguita sui dati di produzione per renderli consumabili? Chi possiede quei dati?

Così tanti progetti ML si bloccano a causa di problemi con i dati di produzione. Ho visto più e più volte che c'è un'enorme disconnessione tra la persona ML e l'ingegnere del prodotto. Un esempio di due caratteristiche innocue con requisiti radicalmente diversi:

• Il codice postale di casa di un utente : probabilmente semplice da usare nella produzione. Interroga un database.
• La posizione media di un utente negli ultimi cinque minuti : probabilmente un PITA! I dati sulla posizione dell'utente si trovano su un Kafka Stream? Quanto fresco deve essere? Le aggregazioni in streaming sono difficili! Probabilmente problemi di inclinazione di allenamento / servizio!

Inizia semplice

Probabilmente il consiglio ML più comune, ma è un buon consiglio. Inizia con una soluzione semplice.

La mia aggiunta: la maggior parte delle persone ti dirà di iniziare con un modello semplice , ma è altrettanto importante iniziare con dati semplici! Per riprodurre l'esempio sopra:

• Posizione media di un utente negli ultimi cinque minuti: difficile
• La posizione più recente di un utente: probabilmente molto più facile!

Probabilmente prendi quel commercio ogni volta. Puoi sempre creare una V2 con la funzionalità più elaborata e sarà molto più facile creare miglioramenti incrementali piuttosto che spedire qualcosa di complicato la prima volta.

Collabora con gli ingegneri

Le probabilità sono che se sei uno scienziato di dati, non tutte le domande poste sopra sono ovvie a cui rispondere. Quando ho lavorato per l'ultima volta alla creazione di modelli ML, non avevo idea di cosa fossero i dati di streaming (per non parlare di come pensarci).

La soluzione è stringere amicizia con gli ingegneri e lavorare con loro durante lo sviluppo di un modello ML. La creazione di qualsiasi progetto software non può essere eseguita in un silo e il machine learning in un silo è anche peggio. Gli ingegneri possono aiutare con "quali dati sono disponibili", "quali vincoli dovrei conoscere", "quali SLA sono fattibili" e altro ancora.

Lavora con un ingegnere presto e spesso. Costruirai progetti molto più velocemente.

Conclusione

Questi passaggi non sono una visione completa di un processo MLOps: ci sono molti elementi in movimento che portano al successo (revisioni del codice, CI/CD, monitoraggio e così via). Questo è un punto di partenza. Come accennato in precedenza, la maggior parte degli errori di ML che ho riscontrato sono problemi di allineamento. Queste linee guida di processo hanno principalmente lo scopo di aiutarti ad allineare il tuo team per il successo.

Hai bisogno di una solida base per costruire una pratica MLOps eccezionale.

David Hershey è un investitore presso Unusual Ventures , dove investe in machine learning e infrastruttura dati. David ha iniziato la sua carriera presso Ford Motor Company, dove ha avviato il team dell'infrastruttura ML. Di recente, ha lavorato presso Tecton e Determined AI , aiutando i team MLOps ad adottare tali tecnologie. Se stai costruendo un'azienda di infrastrutture di dati o ML, contatta David su LinkedIn .