Role i kompetencje w projekcie Machine Learning
W ostatnich 2 odcinkach serii podcastu Biznes Myśli: “Machine Learning – od pomysłu do wdrożenia” rozmawialiśmy o pomysłach i filtrach, które warto na nie nałożyć, aby uniknąć popularnych pułapek oraz o metrykach sukcesu w projektach uczenia maszynowego. Od tego zwykle się zaczyna. Jak to już masz mniej więcej określone, to pojawia się pytania: ale kogo właściwie potrzebuję, aby mój pomysł wdrożyć w życie i aby te metryki sukcesu się spełniły. Albo z drugiej strony, jeśli jesteś osobą, która nie szuka specjalistów, a chce być specjalistą w tym obszarze, to jak się wyspecjalizować, aby rzeczywiście umieć rozwiązywać problemy w praktyce, a nie tylko na prezentacjach, bo to większość potrafi, ale biznes szybko i brutalnie to weryfikuje.
Właśnie dlatego w tym odcinku porozmawiamy sobie o rolach i kompetencjach w projektach z uczeniem maszynowym w roli głównej. Temat zwykle zamyka się na “Data Scientist” lub “ML Engineer”, ale jednak na tym nie kończą się kompetencje potrzebne, aby projekt z sukcesem zacząć, przeprowadzić i co najważniejsze zakończyć. Poza tym te, jeśli patrzysz jedynie na nazwę stanowisk to też też bywa to „tricky” i często rozjeżdża się z rzeczywistością. Dlatego trochę skomplikujemy temat, ale z korzyścią dla Ciebie 😉
Od razu powiem, że nie dostaniesz gotowego przepisu na sukces, bo takich nie ma. Nie będę Ci mówił to zadziała lepiej, a to gorzej, bo nie znam kontekstu Twojej organizacji. Nie chcę też poruszać tego tematu od strony HR, bo to nie moja bajka. Jestem praktykiem i zajmuje się wydobywaniem z danych wartości biznesowej i akurat tak się składa, że uczenie maszynowe w tym świetnie pomaga, jeśli zrobi się to właściwie i zwróci uwagę na kilka krytycznych elementów. I właśnie o tym chcę Ci opowiedzieć przez pryzmat mojego doświadczenia. A Ty mam nadzieję, że przepuścisz to co powiem przez swoje doświadczenie i swój kontekst i wyciągniesz z tego to, co Tobie jest w stanie pomóc lub połączysz kropki jeszcze inaczej.
Dlatego porozmawiamy o tym:
1. Kogo potrzebujesz w projekcie ML, aby iść do przodu – wprowadzenie
2. Kto łączy DS / ML z biznesem?
3. Jakie kompetencje są potrzebne, aby wystartować?
4. Czego potrzebujesz, aby rozpędzić się z ML w Twojej firmie?
Nie traktuj tych odpowiedzi jako niezaprzeczalnego źródła prawdy. Bazuję na swoim doświadczeniu i przypadkach, które poznałem. A jak wiesz jest sporo wyjątków w życiu, dlatego lepiej wszystko, co słyszysz przepuszczać także przez swoje doświadczenie i swój kontekst 🙂
Długo zastanawiałem się, jak podejść do omawiania tego tematu. Można zacząć wyjaśniać, kto czym się zajmuje po kolei i stworzyć podręcznikową iluzję – być może wszystko będzie zrozumiałe, ale nie odzwierciedla rzeczywistości.
Data Scientist, Data Science Manager, Machine Learning Engineer, AI specialist i mógłbym tutaj wymieniać jeszcze kilka lub kilkanaście nazw, które są tylko nazwami stanowisk i nie warto się do nich aż tak mocno przywiązywać, bo co prawda pomagają w nawigacji i szukaniu osób z branży, ale trzeba mieć na uwadze, że tutaj nie ma żadnego standardu i ciężko po samej nazwie stanowiska poznać, kto czym się dokładnie zajmuje i w jakim zakresie. A więc przejdźmy do tego co może Ci się realnie przydać, podzielmy sobie role w projekcie na 5 podstawowych kategorii, które są moim zdaniem ważne 🙂
1. Biznesowe
2. Role dot. danych i modelowania
3. Operacyjne – > twarde
4. Operacyjne -> miękkie
5. Łącznik (może brzmieć tajemniczo, ale wyjaśnię, o co chodzi)
Zaczniemy klasycznie jak na ten podcast,czyli od biznesu 😉 Jeśli zakładasz, że chcesz, aby Twój projekt się udał w ML musisz zdefiniować, co chcesz osiągnąć i aktywnie brać udział w tym projekcie powtarzając regularnie biznesową metrykę sukcesu. Warto doprecyzować, że rola biznesowa w ML to nie tylko odpytywanie i definiowanie metryki, ale też sumienna analiza procesów i tego, co się dzieje, jak mamy już tę upragnioną predykcję modelu, na co wpływa, jak dokładnie ją wykorzystujemy i jak mierzymy naszą skuteczność.
Przykład:
Chcesz mieć model, który będzie prognozował skłonność do zakupu mieszkania i załóżmy, że co tydzień widzisz top. 100 klientów, którzy są według modelu bardziej skłonni do zakupu niż inni i celem zespołu wsparcia jest zadzwonić do tych osób i z nimi porozmawiać, aby zaproponować im ofertę zakupu mieszkania. Wartość tworzy się tutaj wtedy, kiedy nie musisz dzwonić do 1000 osób, a wiesz, że bardziej opłaca się dzwonić do 100.
No i wracasz z informacją model działa słabo, tylko 1 osoba ze 100 kupiła. No i tutaj rodzą się pytania, a czy zespół wsparcia dzwoni do wszystkich z taką samą ofertą, a czy mają ten sam scenariusz rozmowy? A czy te osoby na pewno nie chcą kupić, np. za tydzień czy za miesiąc? Jak mierzyć efektywność zespołu wsparcia? No właśnie, mówię Ci o tym, dlatego, że nie uczenie maszynowe to proces, model nie sprzedaje i nie kupuje 😉 ale może podpowiadać trafniej lub mniej trafnie, ale aby to ocenić musimy mieć wypracowany i mierzalny proces biznesowy też i osoby zaangażowane w ten proces muszą mieć swój czynny udział w projekcie, bo potem dochodzi do sytuacji, że dla zespołu technicznego tak to nazwijmy wszystko działa, a dla biznesowego nic nie działa.
Umiejętność analizy danych i modelowania w ML jest podstawową rolą i często w praktyce wykonuje to jedna osoba, choć to zależy też od organizacji jak ma poukładany proces. Zwykle w mniejszych organizacjach zarówno eksplorowaniem danych i wyciąganiem z nich wzorców w odpowiedzi na konkretny problem biznesowy, jak i użyciem tych danych do modelowania zajmuje się jedna osoba. I bardzo polecam taką kompletną wiedzę posiadać, zresztą sam uczę w ramach mojego kursu Data Science & Machine Learning w praktyce takiego podejścia.
Natomiast warto mieć świadomość, że w większych organizacjach te role mogą być rozdzielone i to jest ważna informacja, bo to oznacza co najmniej to, że trzeba zadbać o sprawną współpracę pomiędzy tymi rolami i tutaj właśnie pojawiają się tak zwanego project managera, ale co ważne ta osoba musi rozumieć specyfikę i wzywania projektu ML, bo jeśli próbuje taki projekt włączyć w ramki klasycznego IT, to skończy się to źle. O tym dowiesz się jeszcze więcej w ramach tej serii, ale na ten moment zapamiętaj, że taka rola jest ważna, bo blokerów będzie dużo, fajnie jak ktoś umie skutecznie tym zarządzać i ułatwiać współpracę i postęp w projekcie. . Przydadzą się tutaj też dobre umiejętności komunikacyjne.
Wyróżniłem też role operacyjne, ale można powiedzieć “twarde”, czyli to wszystko co jest związane głównie z danymi i dostarczeniem ich, ale też tutaj przy wdrożeniu muszą być zaangażowane osoby, które sprawią, że wynik predykcji dotrze w czytelny sposób do właściwych osób i w odpowiednim czasie. Mało tego też po wdrożeniu pojawia się tutaj ważna rola MLOps, czyli upewnienie się, że model działa nie tylko w dniu wdrożeniu, ale w każdym kolejnym dniu.
To ogarnięcie monitoringu i testów na różnych poziomach, bo trzeba zdawać sobie sprawę, że życie to rzeka, wszystko płynie, wszystko zmienia się. Zmieniają się preferencje, zachowania lub zdarzenia zewnętrzne. Tym bardziej teraz, kiedy to działa już globalnie. Dlatego, aby nasz model był anty-kruchy, czyli odporny na zmienność, musimy zapewnić mechanizm, który będzie tym zarządzał. W skrócie MLOps, to jest słowo, które warto zapamiętać, mówiąc o praktycznym ML. Swoja drogą, MLOps to jest taka rozszerzona wersja DevOps, która z kolei jest rozszerzoną wersją system admina. O MLOps jeszcze będzie w tym cyklu.
No ok, na ten moment nie było chyba większych zaskoczeń, prawda? Ale pojawia się ważne, a nawet krytyczne pytanie:
Kto łączy DS / ML z biznesem?
Tak samo jak w klasycznym IT, tak i w ML czy DS nic się nie uda, jak będziemy myśleć tylko o technologii, a nie o biznesie. To oczywiste, natomiast mniej oczywiste już jest to, jak tym zarządzać w projektach ML / DS. To jest krytyczny element sukcesu projektu, a jest o tyle bardziej skomplikowany niż w klasycznym IT, że jest więcej miejsc, gdzie można się potknąć i rozjechać na komunikacji, jeśli nie dopytuje się wyjątkowo szczegółowo i nie patrzy na właściwe liczby.
Wiesz już w poprzedniego odcinka o metrykach, że są różne – osoby techniczne zwykle patrzą na jedne bardziej, osoby z biznesu mają swoje. I często każdy w projekcie ma świadomość tych różnych metryk, to już trudniej z pełnym ich zrozumieniem. I to nie działa w taki sposób, że zatrudnimy wyjątkowo biznesowego Data Scientist, który dogada się z biznesem.To jest za mało, aby wpłynąć na biznes. Dlaczego tak jest?
Bo faktem jest, że Data Science nigdy nie dogada się z biznesem w pełni!
Brzmi zaskakujące? No też jak analizowałem sprawy i jak doszedłem do tego wniosku byłem również zaskoczony. Sukcesem będzie, jak będą patrzeć na te same metryki i liczby, ale wciąż ich interpretacja będzie z dużym prawdopodobieństwem inna, ponieważ każdy ma inną perspektywę i doświadczenie i ciężko to zmienić. Właśnie dlatego na popularności zyskuje hasło i nazwa roli, którą promował swego czasu m.in. Facebook – Decision Scientist, czyli osoba, która ma głębokie rozumienie i doświadczenie z DS / ML, ale metryką sukcesu w tej roli jest na ile technologia, modele itp. wpłynęły na skuteczne decyzje i wyniki biznesowe.
Chciałbym, aby ten temat został w Twojej głowie jako ważny. Z mojego doświadczenia to jest krytyczny element. Tutaj nie trzeba przywiązywać się do samej nazwy Decision Scientist, ale chodzi o rolę i jej wpływ na cały projekt ML. Dlaczego o tym mówię z takim przekonaniem? Ponieważ jako DataWorkshop pokrywamy tę rolę w firmach, z którymi współpracujemy, a pomagamy także firmom, gdzie są już modele na produkcji, ale cały proces nie działa tak, jak biznes by tego oczekiwał. Temat komunikacji pomiędzy DS a biznesem jest złożony i wymaga osobnego podejścia.
Są na to dowody i pokażę Ci to na konkretnych przykładach w następnym odcinku, bo temat zdecydowanie wymaga osobnego odcinka, aby go dobrze ująć i pomóc Ci zarządzać efektywną komunikacją i budowaniem mostu pomiędzy DS / ML a biznesem. Teraz tylko zwracam Twoją uwagę, że takie kompetencje są bardzo ważne, jeśli nie chcesz mieć jednego z 9 na 10 nieudanych projektów.
Jakie kompetencje są potrzebne, aby wystartować?
Jak już jesteśmy przy udanych i nieudanych projektach, to chcę zwrócić Twoją uwagę, że definicja “udany” i “nieudany” jest też zależna od kontekstu i doskonale to zrozumiesz przechodząc całą tę serię podcastu.
Natomiast nie zmienia to faktu, że “udany” musi nieść zawsze jakąś namacalną wartość i pomagać podejmować kolejne decyzje, które pozytywnie wpływają na biznes. I tutaj też ważnym momentem jest start, który z jednej strony jest obarczony większym ryzykiem, którym trudniej zarządzać, ale już na etapie startu powinien być fokus biznesowy. No chyba że mówimy o firmie, która ma dedykowany budżet na research, a dopiero potem zastanawia się, co z tym zrobić, ale to inna historia.
Upraszczając, mówiąc o projektach, gdzie „corem technologicznym” są dane i uczenie maszynowe myślę o co najmniej 2 scenariuszach, w których mogą być firmy. Pierwszy – Data Science i ML już jest w firmie i tam jest kilka różnych stadiów, możliwych kolejnych scenariuszy, jak ten ML się wykorzystuje i czy rzeczywiście spełnia swoją rolę, ale o tym póki co nie mówmy. I jest inny scenariusz, kiedy firma nie zrobiła z ML jeszcze nic i tutaj też jest oczywiście cała paleta pod-scenariuszy jeśli chodzi o stopień zaawansowania organizacji jeśli dane, automatyzacje itd.
Natomiast skupmy się na ten moment na uproszczonym kontekście, ale jednak ważnym, aby przede wszystkim wyróżnić te 2 opcje:
- 1. Firma – robimy już ML
- 2. Jeszcze nie robimy, ale chcemy
Dlaczego tak to dzielę? Często jest tak, że firma, która nie zrobiła nic jeszcze z ML zadaje sobie inne pytania i ma inne obawy niż te firmy, które już coś próbowały (i pewnie wiele razy oparzyły się) lub robią to na większych czy mniejszych obrotach. I to nie chodzi tylko o pytania, ale też o inne potrzeby. Dodatkowo wchodzi w grę większy stopień niepewności, bo nie wiadomo jeszcze co to jest ten ML i czy pomysł, który mam jest sensowny.
Generalnie pytania i wyzwania są inne w obu przypadkach. Jedno z nich może brzmieć : od czego zacząć i jakie kompetencje są potrzebne na start?
Czy musimy mieć od razu dedykowany zespół full time, aby zacząć?
Od razu odpowiem, że nie musisz 🙂 Najpierw przekonaj się, czy to, co robisz ma sens.
Kiedyś współpracowałem z firmą, która była zainteresowana uczeniem maszynowym, choć w ich przypadku ta współpraca polegała raczej na sprawdzeniu, czy ich pomysł jest w ogóle sensowny i pod kątem ml i biznesowo. Dodam, że z danymi było bardzo krucho – nie dość, że było ich mało, to jeszcze nie wiedzieliśmy, czy na cokolwiek się przydadzą. Firma była dosyć mała, ale chciała szybko się rozwijać i inwestować, no i w pewnym momencie dostaliśmy prośbę o rekomendację dot. złożonej hurtowni danych z przemyślaną w cudzysłowie architekturą.
No i pytanie brzmiało, czy to nam pomoże z danymi pod ML? Zgadzam się, że to są tematy ważne, ale problem pojawia się wtedy, kiedy pewne kroki wykonują się nie po kolei. Tak samo jest z ML i budowaniem zespołu.
Sama technologia, bez rozumienia biznesu nie załatwi sprawy, nawet jeśli mówimy o starcie, to warto, aby ten start był sensowny. Warto zdefiniować sobie, co to znaczy “start” czy też “początek”, bo nie dla każdego jest taki sam. Wiem, że powtarzanie “to zależy” może frustrować, bo każdy cieszy się, jak pojawiają się proste instrukcje, ale z drugiej strony nie zwracanie uwagi na kontekst i filtrowanie wszystkiego przez to może skończyć się niefajnie. A więc bazując na moim doświadczeniu czuję obowiązek wręcz wspominania zawsze o tym kontekście, aby o nim nie zapominać i pokazywać Ci przynajmniej kilka opcji, a decyzja, która jest najlepsza na dany moment dla Ciebie należy już do Ciebie 🙂
Wytrenowanie jakiegoś modelu nie jest wyzwaniem, problem tylko w tym, że nie ma sensu trenować “jakiegoś” modelu, tylko taki, który rozwiązuje Twój problem. A to oznacza, że jak planujesz start to zadaj sobie pytanie, co chcesz osiągnąć. Bo jeśli chcesz tylko odpowiedzieć na pytanie, czy da się wytrenować model ML z pomocą Twoich danych, który będzie miał sensowne metryki sukcesu techniczne, to potrzebujesz 1 osoby, która potrafi analizować dane i umie przeprowadzić serię eksperymentów w ML i wybrać model, który daje sensowny wynik.
Natomiast jeśli chcesz odpowiedzieć na pytanie biznesowe, czy model ML może mi pomóc i w jakim stopniu osiągnąć cel X, np. zaoszczędzić y na produkcji danej części i jakie muszą być spełnione warunki, aby to mogło się udać…
To musisz mieć świadomość, że tego model nie załatwi i z dużym prawdopodobieństwem nie odpowie na to pytanie osoba, która ma podejście tylko techniczne (np. Data Scientist). I to nie jest wada, to jest fakt. Jeśli jesteś już na etapie, że zależy Ci na starcie w scenariuszu 2, czyli wykorzystaniu ML w biznesie, a nie tylko w eksperymentach, to musisz wyjść poza kompetencje tylko techniczne. I to nie jest kwestia bycia juniorem, medium czy seniorem w danej dziedzinie ani kwestia tytułów zawodowych, a raczej o to, że są zwykle osoby, które większość życia zajmowały się tylko technologiom, a nie biznesem widzą te same rzeczy inaczej niż biznes i odwrotnie i nie ma co oczekiwać, że to się zmieni, jeśli dokładnie wszystko wyjaśnimy, bo to nie chodzi tylko o sposób komunikacji.
I tutaj pojawia się pytanie:
Czy mogę wystartować z ML nie mając wszystkich kompetencji wewnątrz firmy?
Tak, możesz i nawet warto, bo to oszczędza Twój czas i pieniądze, jeśli znajdziesz właściwego partnera.
Właściwy partner na początek to też taki, który nie zbuduje Ci model, bo to możesz zrobić samodzielnie po moim kursie, ale taki, który właśnie podpowie Ci co zrobić, aby w przypadku Twojego biznesu ten model miał jakąkolwiek wartość.
Zwracam uwagę na to NIE po to, aby powiedzieć Ci, że “tylko DataWorkshop jest w stanie Ci pomóc” (chociaż być może to też jest prawda), bo tego nie wiem, zanim się nie poznamy. Też dodam, że nie wchodzimy też we wszystkie projekty, które do nas wpadają i nie udajemy, że jesteśmy w stanie pomóc każdemu. Musi być pewne dopasowanie i zrozumienie jeśli chodzi o dostarczoną wartość. Dzięki temu dopasowaniu, każdy zyskuje, bo dostarczamy wartość. Natomiast zwracam Twoją uwagę na to, że sam model nie jest odpowiedzią na Twój problem, tutaj chodzi o co najmniej o proces 🙂 i zwracaj na to uwagę jeśli budujesz zespół lub szukasz partnera z zewnątrz.
Czego potrzebujesz, aby rozpędzić się z ML w Twojej firmie?
No dobrze, ale co się zmienia po starcie, jak już mamy pierwszy model na produkcji, dostajemy wynik, widać, że ten wynik na coś wpływa i wiemy na co dokładnie z jakim skutkiem. Co dalej?
Na pewno nie można tego zostawić samemu sobie i z jednej strony trzeba utrzymywać model, czyli re-trenować regularnie (co ile to zależy od tego, jak szybko model degraduje w Twoim wypadku), ale i zapewniać regularny napływ aktualnych danych i zarządzać w tym w czasie – tutaj pojawia się rola MLops także, o której już wspominałem.Poza tym jeśli to biznesowo się opłaca, to warto też dalej ulepszać model.
Kiedyś dostałem pytanie w ramach jednego z projektów, ile osób potrzeba, aby uruchomić np. 10 równoległych projektów ML. No i znów to odpowiedź może brzmieć “to zależy”, ale pewne jest, że nie każde skalowanie wymaga wprost przełożenia na proporcjonalnie większą ilość zaangażowanych osób. Bo zobacz, w uczeniu maszynowym najtrudniejszy moim zdaniem jest proces i wypracowanie np. Pewnego know how dla danej firmy, jakie mamy dane (to nie zawsze jest takie oczywiste), jak nimi zarządzać w kontekście ML, na jakie metryki patrzymy, jak porównujemy, który model jest lepszy od drugiego, jak weryfikujemy skuteczność modelu.
W zasadzie np. każdy z tych 10 przykładowych projektów może być inny, ale to co najtrudniejsze to wypracowanie właśnie procesu i zrozumienie w danym kontekście biznesowym na co mamy wpływ i na co w jaki sposób wpływamy. Jeśli to załapiemy, mamy tak zwany core, to różnicowanie pewnych elementów jest znacznie prostsze i nie wymaga aż tyle czasu, co stawanie na nogi pewnych podwalin. Na tym fundamencie może potem wyrosnąć wiele domków, mało tego, jak są już tory, ciężej jest wykoleić się, również mniej doświadczonym zespołem. W uczeniu maszynowym w ogóle jest tak, że na początek trzeba włożyć dużo energii, aby wypracować pierwszą deltę wartości, ale potem można coraz szybciej się rozpędzać i skalować.
Myśląc o kompetencjach i rolach w swojej firmie warto zastanowić się, do czego się dąży, bo sam ML może być:
- jako core biznesu
- wspierać biznes w jakimś wycinku / rozwiązywaniu konkretnego problemu
- może być w tak zwanym “laboratorium AI”, to zwykle nieco większe firmy wydzielają takie przestrzenie na eksplorowanie nowych możliwości bez większego ponoszenia ryzyka, że coś może pójść nie tak, bo to przecież laboratorium.
Drugi wymiar, który warto wziąć pod uwagę, to wielkość firmy:
Jeśli Twoja firma jest mała, to pewnie oczekujesz mniejszą ilość ludzi, ale wielozadaniowych, którzy są wykonawcami i liderami jednocześnie, w większych organizacjach z kolei jest więcej kropek do połączenia i dosłownie ludzi, a więc potrzebne są dodatkowe role, które spajają wszystko – łącznicy.
To bardziej pytanie nie tyle o wielkość, ale o kulturę organizacji w tym kulturę pracy z danymi. Jest to powiązane w pewien sposób z wielkością.
No i 3 wymiar, najważniejszy to, co chcesz osiągnąć na dany moment.
A więc zadanie dla Ciebie brzmi tak, aby określić swoją firmę w tych 3 wymiarach i spróbować odpowiedzieć na pytanie, której roli brakuje mi, aby osiągnąć cel.
Napisz proszę do mnie na hello@dataworkshop.eu, porozmawiamy o tym i koniecznie daj znać, czy ten odcinek był dla Ciebie wartościowy.