Nawet przy doskonałym stosie narzędzi MLOps zespoły wciąż mają trudności z dostarczaniem produktów ML. Więc jeśli narzędzia nie są jedynym elementem układanki, co to pozostawia? W moim ostatnim poście twierdzę, że pozostałe elementy to kultura i proces.

Przyjrzyjmy się bliżej procesowi MLOps — w szczególności niektórym podstawowym elementom, które większość zespołów myli . Jak wygląda udany proces MLOps i jak poszczególni praktycy ML mogą pomóc w zbudowaniu tego procesu?

TL;DR

• Zacznij od produktu, a nie od modelu
• Analizuj dane w produkcji , a nie w swoim magazynie
• Zacznij prosto — z danymi i modelami
• Współpracuj z inżynierami

Zacznij od produktu ML

Być może najważniejszą praktyką, która umożliwia udane projekty ML, jest zaprojektowanie produktu , a nie modelu . Jedną z największych pułapek, jakie widziałem w dziesiątkach firm, jest przekazywanie „projektów” zespołom ds. danych zamiast angażowania ich w fazę projektowania produktu.

Aby zbudować udany produkt ML, w jego projektowanie muszą być zaangażowani trzej interesariusze:

• PM / Interesariusz biznesowy : Jak wygląda sukces?
• Osoba ML : Co jest (prawdopodobnie) możliwe dzięki ML?
• Inżynier Produktu : Co jest wykonalne i jakie są ograniczenia?

Kilka przykładów słabo wyrównanych zespołów:

• Osoba ML optymalizuje dokładność modelu (zamiast wyników biznesowych!)
• Rozpoczęte projekty, których rozwiązanie może być niemożliwe przy użyciu uczenia maszynowego
• Model nie spełnia ograniczeń wydajności w produkcji
• Funkcje są trudne lub niemożliwe do obliczenia w środowisku produkcyjnym

• Osoba zajmująca się ML rozumie kompromisy między dokładnością a czasem wprowadzenia produktu na rynek
• Monitorowanie zbudowane w dniu zerowym w celu zapewnienia spójnego pomiaru wyników biznesowych
• Inżynier pomaga osobie ML zrozumieć krajobraz danych produkcyjnych
• Modelowe umowy SLA są jasno określone i mierzone

Jest to przykład „dobrego wyrównania” w ostatniej sekcji, ale zasługuje na osobną sekcję. Prawie wszyscy konstruktorzy ML, których widziałem, rozpoczynają swoje projekty ML od przeglądu dostępnych danych. Problem? Zwykle badają dane, które są dostępne do szkolenia , a nie dane, które będą dostępne w środowisku produkcyjnym.

Niektórzy mogą zapytać — czy wszystkie dane dostępne do szkolenia nie powinny być dostępne w systemie produkcyjnym?

W większości przypadków odpowiedź brzmi „ tak ”, ale z kilkoma gwiazdkami. Jak szybko te dane są dostępne? Jak świeże są te dane? Ile wstępnego przetwarzania należy wykonać na danych produkcyjnych, aby można je było zużywać? Kto jest właścicielem tych danych?

Tak wiele projektów ML utknęło w martwym punkcie z powodu problemów z danymi produkcyjnymi. Wielokrotnie widziałem, że istnieje ogromny rozdźwięk między osobą zajmującą się ML a inżynierem produktu. Przykład dwóch nieszkodliwych funkcji o diametralnie różnych wymaganiach:

• Domowy kod pocztowy użytkownika : prawdopodobnie prosty w użyciu w produkcji. Zapytanie do bazy danych.
• Średnia lokalizacja użytkownika w ciągu ostatnich pięciu minut : prawdopodobnie PITA! Dane o lokalizacji użytkownika znajdują się w strumieniu Kafka? Jak świeże musi być? Agregacje strumieniowe są trudne! Prawdopodobnie problemy z przekrzywieniem treningu / serwowania!

Zacznij prosto

Prawdopodobnie najczęstsza rada ML, ale to dobra rada. Zacznij od prostego rozwiązania.

Mój dodatek — większość ludzi powie ci, żebyś zaczął od prostego modelu , ale równie ważne jest, aby zacząć od prostych danych! Aby odtworzyć powyższy przykład:

• Średnia lokalizacja użytkownika w ciągu ostatnich pięciu minut: trudno
• Ostatnia lokalizacja użytkownika: prawdopodobnie znacznie łatwiejsza!

Prawdopodobnie bierzesz tę transakcję za każdym razem. Zawsze możesz zbudować V2 z bardziej wyrafinowaną funkcją, a tworzenie stopniowych ulepszeń będzie znacznie łatwiejsze niż wysyłanie czegoś skomplikowanego za pierwszym razem.

Współpracuj z inżynierami

Szanse są takie, że jeśli jesteś naukowcem zajmującym się danymi, nie wszystkie z powyższych pytań są oczywiste. Kiedy ostatnio zajmowałem się budowaniem modeli ML, nie miałem pojęcia, czym jest przesyłanie strumieniowe danych (nie mówiąc już o tym, jak o tym myśleć).

Rozwiązaniem jest zaprzyjaźnienie się z inżynierami i współpraca z nimi podczas opracowywania modelu ML. Budowanie jakiegokolwiek projektu oprogramowania nie może odbywać się w silosie, a uczenie maszynowe w silosie jest jeszcze gorsze. Inżynierowie mogą pomóc w określeniu „jakie dane są dostępne”, „o jakich ograniczeniach powinienem wiedzieć”, „jakie umowy SLA są wykonalne” i nie tylko.

Współpracuj z inżynierem wcześnie i często. Zbudujesz projekty znacznie szybciej.

Wniosek

Te kroki nie przedstawiają kompleksowego obrazu procesu MLOps — istnieje wiele ruchomych elementów, które prowadzą do sukcesu (przeglądy kodu, CI/CD, monitorowanie itp.). To jest punkt wyjścia. Jak wspomniano powyżej, większość błędów ML, które widziałem, to problemy z wyrównaniem. Te wytyczne dotyczące procesu mają przede wszystkim pomóc w dostosowaniu zespołu do sukcesu.

Potrzebujesz mocnych podstaw, aby zbudować wyjątkową praktykę MLOps.

David Hershey jest inwestorem w Unusual Ventures , gdzie inwestuje w uczenie maszynowe i infrastrukturę danych. David rozpoczął karierę w firmie Ford Motor Company, gdzie założył zespół ds. infrastruktury ML. Ostatnio pracował w Tecton i Determined AI , pomagając zespołom MLOps we wdrażaniu tych technologii. Jeśli budujesz firmę zajmującą się danymi lub infrastrukturą uczenia maszynowego, skontaktuj się z Davidem na LinkedIn .