Planowanie projektów Machine Learningowych

Dziś chciałbym przedstawić Ci proces planowania projektów Machine Learning. Taki jaki stosujemy w mojej firmie COGITA. Jeśli jesteś zaangażowany projekty ML – czy to jako analityk, czy jako Data Scientist, to z pewnością albo bierzesz udział w tym procesie, albo w bliski sposób korzystasz z jego efektów. Dlatego zostań do końca tego artykułu, a na pewno znajdziesz coś dla siebie.

Zwinny styl projektów ML zamiast szczegółowego projektowania

Przede wszystkim w planowaniu prac ML pamiętaj o filozofii agile – zwinnej pracy nad projektem. W jej świetle, celem procesu planowania ma być wstępny szkic i zarys głównych faz, a nie szczegółowy plan wszystkich etapów. Natomiast decyzje co do szczegółów powinny być zawsze podejmowane na bieżąco, np. pod koniec dwutygodniowych sprintów.

Zazwyczaj jednak musisz dość sztywno określić zakres czasu, jaki jest planowany na projekt. Co wtedy?

Istnieje kilka sposobów, jak sobie z tym poradzić. Po pierwsze warto mieć pod ręką dostęp do historycznych projektów Twoich lub Twojego zespołu. Podchodząc wtedy do nowego projektu, możesz szybko znaleźć projekty o podobnym procesie skomplikowania lub z podobnej dziedziny i zobaczyć, ile czasu one zajęły.

Drugim sposobem jest określenie limitu czasu, ale nieokreślanie zakładanych metryk (tak jak w tym blogu pisałem o ograniczaniu zakresu przy ustalonym czasie). Bardzo trudno przewidzieć, ile czasu będziesz potrzebować na uzyskanie np. 90% skuteczności modelu. Ale dość łatwo zaplanować, że poświęcisz X czasu na pierwszy trening i Y czasu na poprawki mające uzyskać jak najwyższą jakość.

Trzecim sposobem jest wycena tylko etapu Proof-of-Concept i podanie np. widełek czasu na etap budowy pełnego algorytmu. Etap PoC umożliwi Ci wstępną analizę danych i uruchomienie pierwszych modeli. Będziesz wiedział, od jakiego poziomu zaczynasz i jak daleko Ci brakuje do pożądanego efektu (pamiętaj o rozpoczynaniu od benchmarków).

Zacznij od “Dlaczego?”

Kiedy rozpoczynasz projekt Machine Learning, ważne jest, aby najpierw zrozumieć problem, który próbujesz rozwiązać. Warto zadać sobie proste pytania: Co ma robić docelowy model? Na jaką potrzebę odpowiada? Czy będzie to całkowita automatyzacja jakiejś funkcji, częściowa, a może model będzie tylko dawał rekomendacje, a ostateczne decyzje będzie podejmował człowiek?

Zastanów się, jaka będzie przewaga tego rozwiązania nad tym, co jest teraz. Dlaczego została podjęta decyzja o zastosowaniu Machine Learningu w tym problemie?

Gdy będziesz zawsze miał w pamięci efekt końcowy, łatwiej Ci będzie podejmować decyzje oraz planować prace.

Zbierz dokładne wymagania

Pomyśl teraz o użytkownikach Twojego modelu. Mogą nimi być osoby z innego działu Twojej firmy, pracownicy Twojego klienta (np. banku, sklepu, szpitala itp.) albo pojedyncze osoby korzystające np. z Twojej aplikacji wykorzystującej ML. 

Zapytaj ich, dlaczego to, czego używają teraz, nie jest wystarczające. Jak wyobrażają sobie docelowe rozwiązanie? Skonsultuj formę interakcji z modelem, kształt interfejsu użytkownika itp.

Postaraj się zebrać wszystkie wymagania dotyczące modelu – jaka skuteczność będzie idealna, a jaka akceptowalna? Jak długi czas czekania na odpowiedź modelu jest akceptowalny?

Następnie zbadaj ograniczenia – czy w każdej sytuacji te osoby będą chciały używać Twojego modelu? Zwróć uwagę na kwestie zaufania do modelu – model będzie podejmował decyzje o przyznaniu kredytu lub nie, to zapewne poza odpowiedzią TAK / NIE, użytkownik będzie wymagał uzasadnienia decyzji. Zapytaj, jakiego rodzaju uzasadnienie będzie wystarczające.

Nasza intuicja i szybka walidacja hipotez

Projektując dowolne rozwiązanie Machine Learning, opierasz się – świadomie lub nie – na swojej intuicji dotyczącej danych, funkcjonowania świata oraz możliwości algorytmów. Po pierwsze warto, aby ta intuicja powstawała na możliwie szerokim zakresie informacji. Dlatego ja zawsze przed zaplanowaniem prac pytam o próbkę danych, na których mają być trenowane modele, a także staram się porozmawiać z docelowymi użytkownikami modelu, aby zrozumieć ich doświadczenia, potrzeby i wymagania. Robię też research dotyczący aktualnych podejść do podobnych problemów oraz wykorzystywanych algorytmów. Szerzej te działania opisałem tutaj.

Następnie warto spisać założenia (hipotezy), na jakich opiera się nasza intuicja. Celem etapu PoC powinno być jak najszybsze zweryfikowanie tych hipotez. Wstępne prace powinny tak naprawdę odpowiedzieć na dwa pytania: jak daleko myliliśmy się na początku i co powinniśmy zmienić w dalszym planie, aby zrealizować cel.  

Komunikacja: ludzie zastąpieni przez model

Na etapie planowania prac w projekcie musisz uwzględnić aspekt komunikacji. Jeśli tworzysz algorytm dla zewnętrznego klienta, powinieneś uzyskać zapewnienie, że będzie on dostępny by odpowiadać na Twoje wątpliwości i razem z Tobą planować zakres sprintów.

Szczególnie delikatnie trzeba podchodzić do kwestii współpracy z osobami, których praca docelowo ma być zastąpiona przez model AI. Warto zapoznać się z zyskującym na popularności podejściu collaborative AI. W tym modelu chodzi o to, aby ułatwić i przyspieszyć pracę człowieka za pomocą modeli AI, a nie o zastąpienie go. Warto o tym myśleć, projektując rozwiązania AI.

Podziel pracę na etapy

Odpowiedni podział projektu na etapy to taki, w którym każdy etap kończy pewną całość, która najlepiej gdyby od razu dawała wartość użytkownikowi i mogła być wdrożona. Przykładem może być implementacja modelu heurystycznego lub modelu, który działa na podzbiorze danych. Wówczas docelowy odbiorca będzie widział postęp po każdym etapie i będzie gotowy dalej inwestować w projekt. Podam przykład. Jeśli docelowy model ma wyznaczać zdolność kredytową klienta banku, to pierwszym krokiem może być klastrowanie klientów na grupy o podobnej zdolności kredytowej. Kolejnym krokiem może być przewidywanie jakiegoś zakresu wartości. Dopiero finalny model może podawać konkretną wartość.

Drugim aspektem jest przemyślenie, aby koniec dowolnego etapu dawał możliwość wyboru różnych ścieżek. Jest to zgodne z filozofią agile, gdzie nie masz pewności, czy wykonując pierwszy etap, zdecydujesz się również na drugi.

Przykład wyceny czasowej

W mojej firmie stosujemy Clockify do logowania czasu pracy. Dzięki temu jesteśmy w stanie dość precyzyjnie powiedzieć, ile czasu poświęciliśmy na konkretne zadanie. Co więcej, zestawiając ten czas z pierwotnym oszacowaniem, coraz lepiej budujemy swoją intuicję i umiejętność szacowania wielkości projektu. Polecam to podejście każdemu!

Podam rzeczywisty przykład z jednego z projektów z poprzedniej firmy, w którym celem była detekcja produktów oraz odczytywanie ich nazw i cen.

Oto pierwotne oszacowanie:

Planowane zadanieWycena planu w MD
Analiza danych oraz preprocessing10
Algorytm do detekcji produktów40
OCR do odczytywania ceny i nazwy produktu25
Parowanie wykrytych produktów z cenami i nazwami15
Suma90

A oto rzeczywiste zalogowane godziny:

Zrealizowane zadanieZalogowany czas wMD
Analiza danych oraz preprocessing12
Algorytm do detekcji produktów15
OCR11
Bugfixy: zamrożenie podziału train-test-val12.5
Heurystyki wyciągające cenę z boxów OCR oraz łączące boxy OCR z boxami yolo13
Metryki i heurystyki do nazw produktów12
Model NLP wyciagający nazwę produktu z wyniku OCR12
NLP: OCR -> cena + szukanie podzbioru o wysokiej precyzji11
Analiza błędów i pewności całości rozwiązania + quick fixy26
Yolo do detekcji boxów z cenami7
Suma131.5

Widzimy, że projekt zajął ok. 50% więcej niż było szacowane. Detekcja okazała się sporo prostsza, natomiast OCR do odczytywania nazw i cen działał na tyle słabo, że spróbowaliśmy kilku innych podejść (heurystyki i modele NLP). Co więcej, 38.5 MD (prawie 30% czasu!) zajęła analiza poprawności rozwiązania i naprawianie błędów.

Podsumowanie

W artykule przedstawiłem kilka praktyk, jakie stosuję w planowaniu projektów Machine Learningowych. Jeśli nie masz nic przeciwko, proponuję, byś przed rozpoczęciem kolejnego projektu spróbował wprowadzić choć jedną z nich.