Moje spostrzeżenia po 3 latach pracy w branży ML
W tym wpisie chciałem podzielić się z Tobą moimi przemyśleniami, które mam nadzieje pozwolą Ci zwiększyć efektywność Twojej pracy oraz czerpać z niej większą przyjemność.
Jest to wiedza, którą musiałem nabyć, ucząc się na własnych błędach… a życie toczy się dalej i uczę się nadal. Zapraszam do czytania i mam nadzieję, że znajdziesz tu coś dla siebie.
Wybierz świadomie miejsce pracy
W dzisiejszych czasach pozycje Data Scientist oraz Machine Learning Engineer nie mają jednoznacznych definicji, a te często się ze sobą mieszają.
W zależności od firmy możesz trafić przykładowo do zespołu:
- Business Intelligence, gdzie głównym zadaniem będzie analiza danych i dostarczanie odpowiedzi na pytania biznesowe — z mniejszym naciskiem na jakość pisanego kodu oraz większym na interpretowalność metody. Mogą pojawić się częste prezentacje biznesowe, a Twoja praca prawdopodobnie rzadko będzie sięgać poza raport w Jupyter Notebooku czy innej platformie.
- Software Engineering, gdzie Twoim zadaniem będzie dostarczenie funkcjonalności do produktu, z którego będą korzystać użytkownicy. Wszystkie pryncypia tworzenia oprogramowania, takie jak: testy, code review, praca w scrumie, częste dema przedstawiające postępy pracy, umiejętność wdrożenia własnych rozwiązań end-to-end, będą jak najbardziej wymagane. Należy jednak nie zapominać o sztuce tworzenia sprawnego modelu, jak i również o wygodzie korzystania z produktu przez użytkownika. Warto przygotować się również też na to, że nie będziesz używać Machine Learningu zbyt często, aby nie komplikować produktu lub ograniczać się do prostszych modeli, takich jak chociażby KNN, Modele Regresji, może XGBoost itp. Ukończony produkt może dać Ci namacalny dowód Twojej pracy, co jest bardzo satysfakcjonujące.
- R&D, w którym Twoją odpowiedzialnością będzie szukanie i testowanie nowych rozwiązań, które mogłyby zostać użyte przez firmę w celu rozwiązania jej aktualnych problemów lub usprawnienia tego, co już działa. Dużo czasu spędzisz przeglądając intensywnie matematyczne publikacje naukowe. Będzie możliwość wypróbowania nowoczesnych rozwiązań z wielu dziedzin. Jednak przygotuj się na to, że większość Twoich pomysłów pozostanie w laboratorium.
Drugim aspektem wyboru pracy jest typ firmy, w której możesz pracować:
- Jest bardziej prawdopodobne, że większa firma będzie dodatkowo posiadać więcej różnego typu danych. Tym samym będzie więcej okazji do robienia Machine Learningu poprzez przenoszenie się pomiędzy projektami. Nawet jeżeli jakiś projekt nie wypali, co w projektach powiązanych z Machine Learningiem często ma miejsce, prawdopodobnie szybko znajdzie się dla Ciebie inne zadanie. Z drugiej strony, wiele zadań będzie przychodzić odgórnie i będziesz mieć mniejszy wpływ na własną pracę.
- Mniejsza firma jest większym wyzwaniem pod kątem umiejętności jakie będziesz potrzebować, aby wykonać swoje zadania. W małej firmie zwykle brakuje rąk do pracy i nie ma specjalisty na każdą okazję. Wiele rzeczy będziesz robić samodzielnie, ale bardzo dużo się przy tym nauczysz. Istnieje ryzyko, że taka firma będzie miała mniej danych, albo tylko jeden typ danych, co jest dla Ciebie zagrożeniem. Jeżeli projekt z ML-owy nie wypali (np. z powodu niemożności uzyskania oczekiwanego efektu z dostępnych danych), to dużo czasu musi minąć zanim coś się w tej kwestii zmieni. Spadną na Ciebie inne obowiązki i nie do końca mogą być tym, co Cię interesuje.
- Jeżeli zależy Ci na tym, aby robić dużo Machine Learningu oraz dotykać wielu dziedzin, to warto się zastanowić nad firmą, która zajmuje się consultingiem. Będziesz mieć okazje spojrzeć na różne dane od wielu klientów i pracować z różnymi ludźmi. Spadnie na Ciebie odpowiedzialność komunikacji z klientem i analizy jego sytuacji. Oczywiście nie będziesz w tym sam/a. Jeżeli, czegoś nie będzie się dało rozwiązać z powodu problemów z danymi, to zawsze możesz zacząć kolejny projekt. No właśnie — o ile będzie kolejny projekt, bo te na drzewach nie rosną.
Nie musisz wiedzieć wszystkiego
Aby pracować z projektami wykorzystującymi Machine Learning, nie musisz znać każdego algorytmu na wylot. Branża bardzo prężnie się rozwija i opanowanie wszystkiego nie jest fizycznie możliwe. Dołączając do pewnej firmy, dość prawdopodobnym jest, że jej dane będą umożliwiać Ci dotknięcie tylko kilku poddziedzin Machine Learningu. Projekty mogą ciągnąć się latami i ciężko będzie aktualizować wiedzę przykładowo z przetwarzania języka naturalnego lub obrazów, jeżeli Twoja praca nie będzie dotyczyć tych tematów na co dzień. Bardzo szybko zapomnisz o wielu szczegółach. Jeżeli te umiejętności faktycznie będą Ci potrzebne, to rozumiejąc na poziomie ogólnym jak działa Machine Learning czy Deep Learning, nadal będziesz w stanie użyć nowoczesnych rozwiązań — douczając się w biegu. Dlatego, jeżeli planujesz się rozwijać, warto przeznaczyć swój czas wolny na naukę czegoś, co przyda się praktycznie w każdej pracy: umiejętności prezentacji, SQL-a, podstaw frontendu, Spark, AWS/Google Cloud, Docker, Flask/FastAPI itp.
Jesteś tu po to by zaspokajać potrzeby firmy, nie po to by robić Machine Learning
Problemy jakie próbuje rozwiązać firma, często mogą być rozwiązane na wiele sposobów. Twoim zadaniem jest rozwiązanie problemu z zachowaniem balansu zysków i strat. Zadania, które nie przynoszą firmie wielkich zysków, powinny zostać wykonane jak najszybciej i po najniższej linii oporu. Czas zainwestowany w rozwiązanie to nie tylko pieniądze, jakie pracodawca płaci pracownikowi, ale blokada potencjału pracownika, która uniemożliwia mu wykonywanie innego wartościowego zadania. Należy pamiętać też o tym, że rozwiązania, które wdrażamy, powinny być proste w utrzymaniu i dostosowane do tego, aby inni pracownicy nie tracili zbyt dużo czasu wchodząc w interakcje z naszą pracą. Dlatego warto dbać o czystość i udokumentowanie kodu. Machine Learning jest technologią, która zwykle wymaga zebrania odpowiedniej ilości danych treningowych oraz testowych, przeanalizowania ich, czasu na zbudowanie rozwiązania, zadbania o reprodukowalność wyników jak również i zbudowania odpowiedniej infrastruktury, która musi być monitorowana i utrzymywana. Nie jest to technologia, którą każdy programista jest w stanie od razu zrozumieć i zmodyfikować, dlatego po wdrożeniu takiego modelu, ograniczona liczba pracowników jest w stanie zareagować na potencjalną awarię takiego rozwiązania. Zdarza się, że zwykłe użycie warunku if, może już dawać lepsze wyniki niż rzut monetą. Nawet jeżeli istnieje lepsze rozwiązanie niż warunek if, zawsze musimy sobie zadać pytanie, czy zysk ze wzrostu wydajności jest wart wzrostu skomplikowania systemu czy też dodatkowej pracy na stworzenie i utrzymanie go. Idąc tą logiką, powinniśmy się cieszyć jeżeli jesteśmy w stanie generować wartość bez potrzeby użycia Machine Learningu oraz szukać alternatywnych metod, aby go zastąpić.
Poświęć czas na dokładne zrozumienie potrzeby Twojego klienta/pracodawcy
W każdej firmie, w jakiej miałem okazje pracować, komunikacja pomiędzy zespołem deweloperskim a biznesowym była pełna wyzwań. Najwięcej problemów wynikało z niezrozumienia potrzeb obu stron i braku dialogu. Trzeba sobie uświadomić, że biznes nie rozumie procesów zachodzących w zespole deweloperskim, w związku z tym nie powinno się każdej prośby biznesowej brać dosłownie. Kiedyś zostałem poproszony o użycie jednego z firmowych modeli do wygenerowania liczb na danych z całego roku. Taki proces wymagałby uruchomienia wielu maszyn na AWS-ie, dodatkowo trwałby długo i byłby dość kosztowny. Po rozmowie z osobą z biznesu okazało się, że liczby były potrzebne do wykazania trendu w danych. Do takiego zadania nie były więc potrzebne dokładne obliczenia, wystarczyło wziąć losowo wybrane 10% danych z każdego miesiąca, żeby zaspokoić potrzebę biznesową, a jednocześnie oszczędzić mój czas i pieniądze firmy. Dlatego, kiedy dostaniesz nowe zadanie, zanim zaczniesz je wykonywać lub angażować dodatkowe osoby w ten temat, zadaj sobie kilka pytań i upewnij się, że rozumiesz, jaki efekt ta osoba chce uzyskać oraz w jaki sposób Twoje rozwiązanie mogłoby być użyte.
Możesz mieć wpływ na to, czym się zajmujesz w pracy
Swego czasu wpadłem w niebezpieczne myślenie, że nie wolno wybrzydzać i trzeba robić wszystko o co mnie proszą, nawet jeżeli nie ma to nic wspólnego z moją pozycją w pracy — w końcu ktoś to musi zrobić, a firma tego potrzebuje. Efektem takiej postawy było to, że ludzie przyzwyczaili się, że można mi podrzucić dziwne i nietypowe zadania, które nie wiadomo było komu powierzyć. Przykładowo nadzorowanie pracy freelancerów zbierających dane na potrzeby testów jednego z naszych systemów. Praca pochłaniała dużo czasu, a jednocześnie była mało rozwijająca. Kolejnym powodem otrzymania takiego zadania było to, że w danej chwili robiłem dużo mniejszych zadań i nie brałem odpowiedzialności za żaden większy projekt. Nauczyło mnie to, że jeżeli nie wezmę sprawy w swoje ręce i nie będę próbował wychodzić z inicjatywami zmian lub rozpoczęcia nowego projektu, to nie będę mógł odmówić przydzielania mi mniej ciekawych zdań. Ogólnie mówienie „nie” może kojarzyć się z czymś negatywnym, dlatego warto jest zadbać o to, by robić w danej chwili zadania wartościowe dla firmy. Staraj się podkreślać wartość i wagę płynącą ze swoich aktualnych zadań albo próbuj mieć w zanadrzu pomysły, które można zaproponować swojemu pracodawcy w zamian za próbę odmowy mniej ciekawego zadania. Stwórz potrzebę, uświadamiając go o wartościach płynących z realizacji Twoich pomysłów, tym samym zachęcając go do powierzania Ci ciekawszej i bardziej satysfakcjonującej pracy.
Zawsze zaczynaj od planu działania
Wiele razy zdarzało mi się zacząć pisać kod, znając jedynie spodziewany efekt końcowy, nie zastanawiając się wcześniej nad projektem całego rozwiązania. W rezultacie często musiałem wracać do napisanych już komponentów mojego systemu, modyfikować je w biegu, a w najgorszym wypadku całkowicie je wymieniać, ze względu na niekompatybilność z innym systemem, którego poprzednio nie wziąłem pod uwagę. Problem został rozwiązany w chwili, gdy zacząłem pokrótce opisywać swój pomysł w design docu. Czas potrzebny na stworzenie takiego szkicu był dużo mniejszy niż późniejsze żonglowanie kodem i naciąganie napisanych już fragmentów kodu, tak aby na siłę połączyły się z nieprzewidzianymi zmianami. Ponadto stworzony dokument mogłem udostępnić w firmie i otagować ludzi odpowiedzialnych za systemy, do których miałem się łączyć. Często powstająca burza mózgów i komentarze w dokumencie czyniły projekt wydajniejszym i prostszym. W skrajnych przypadkach dochodziło nawet do sytuacji, w których okazywało się, że komponent, który planowałem budować nie jest w ogóle potrzebny. Kolejną zaletą design doca w kontekście Machine Learningu jest to, że ciężko jest przekonać innych członków zespołu, by rozpocząć prace nad nowym modelem. Nigdy nie zaczynaj pracy nad modelem, jeżeli nie masz pomysłu w jaki sposób możesz go testować. Bez przedstawienia solidnego eksperymentu, który udowodni, że wpływ modelu na cały firmę będzie mierzalny, zdarzało się, że moje propozycje były odrzucane, a przecież każdemu z nas zależy na tym, żeby robić to, co go interesuje.
Zwracaj uwagę na to, czy problem który rozwiązujesz, da się zautomatyzować
Kiedy piszesz kod, to używasz funkcji po to, żeby uniknąć powielania tych samych fragmentów kodu. To samo myślenie można przenosić na coraz wyższy poziom, a wartość, którą zyskujesz rośnie z każdym poziomem. Jeżeli w kilku projektach powtarzasz ten sam kod, to może warto napisać swój własny toolbox funkcji, który dodatkowo będzie zoptymalizowany i przetestowany. Jeżeli Twój przełożony lub zespół biznesowy, w kółko powierza Ci podobne zadania, to może warto napisać skrypt, który będzie przyjmował różne argumenty i uruchamiać go kiedy w razie zaistniałej potrzeby. Od tego miejsca jesteś tylko o krok od stworzenia mikroserwisu, który będzie uruchamiał się cyklicznie albo działał bez przerwy i zwracał wyniki w czasie rzeczywistym, a tym samym odpowiadał na pytania biznesowe praktycznie bez opóźnienia. Zamienienie snipetu kodu w skrypt, nie jest wcale takie czasochłonne, dlatego warto budować rozwiązania, które łatwo użyć ponownie. Automatyzacja jest kluczem do tego, by oszczędzić Twój czas oraz pieniądze firmy.
Nie próbuj rozwiązać skomplikowanego problemu za jednym razem, uprość zadanie a następnie iteratywnie komplikuj zadanie, testując to co już zostało stworzone
Próba użycia skomplikowanego modelu na samym starcie pracy jest strzałem w ciemno. Nawet jeżeli zadziała, skończysz błądząc po omacku dookoła swojego rozwiązania, ponieważ nie zbudowałeś wcześniej zrozumienia problemu i danych. Polecam uprościć problem, usuwając z niego bardziej skomplikowane przypadki, tak aby był zrozumiały dla człowieka. Dopiero wtedy spróbuj zbudować prosty model i zobacz, z jakimi przypadkami sobie radzi, a z jakimi nie. Spróbuj rozwiązać uproszczony problem, a dopiero potem dorzucać bardziej skomplikowane przypadki. Zadbaj też o prędkość swoich iteracji. Stwórz mały zbiór danych do developmentu, na którym będziesz mógł uruchomić cały pipeline i sprawdź jego poprawność od strony programistycznej oraz merytorycznej w kilka sekund. Jeżeli wszystko zadziała, możesz użyć więcej danych. Zastanów się, czy na pewno musisz korzystać ze wszystkich danych. Jeżeli jest ich bardzo dużo, musisz wziąć też pod uwagę złożoność obliczeniową kodu oraz zasoby maszyny, do jakiej masz dostęp, w przeciwnym wypadku, po uruchomieniu kodu na całości danych, mogą wystąpić problemy z zasobami. Jeżeli Twój kod działa zbyt długo, profiluj go linijka po linijce. Jedna linijka napisana na szybko potrafi stanowić 90% czasu całej operacji i można ją przepisać w taki sposób, aby kod był optymalniejszy. Możesz też spróbować użyć paralelizacji — podzielić dane na chunki i przetworzyć je w wątkach, a następnie złączyć w całość. Wiele innych dobrych praktyk znajdziesz w Rules of Machine Learning od Google.
Bierz odpowiedzialność za swoją pracę
Błąd, jaki zdarzyło mi się parę razy popełnić, to niedokończenie powierzonej mi analizy danych. Spędziłem dużą ilość czasu na przetwarzaniu, zrozumieniu i wizualizacji danych. Opisałem wykresy, napisałem komentarze, dodałem notatkę i wydawało mi się, że praca jest skończona. Przecież wszystko jest szczegółowo przedstawione, więc każdy zainteresowany może z tego skorzystać, prawda? Z czasem przekonałem się, że takie podejście nie jest w pełni poprawne. Wynikiem analizy nie jest wykres czy liczba, ale wniosek często prowadzący do podjęcia jakieś decyzji. Ktoś powierzając Ci przeanalizowanie problemu, będzie oczekiwał, że przyjdziesz do niego z odpowiedziami. To Ty jesteś osobą, która spędziła najwięcej czasu analizując te dane, więc to Ty wiesz najlepiej jaką decyzje podjąć. Jest to mało prawdopodobne, że inni zrozumieją w pełni Twoją kilku dniową pracę oraz proces myślowy w parę minut. Jeżeli masz wątpliwości co do swoich wyników, powiedz o tym lub opisz to, ale spróbuj chociaż zasugerować rozwiązanie. Nie czekaj też na dodatkowe wytyczne, dowiedz się co jest potrzebne i doprowadź temat od początku do końca.
Nie podawaj liczb, które mogą się zmienić
Byłem świadkiem wielu problemów w komunikacji pomiędzy biznesem a zespołem developerskim. Szczególnie w nowych firmach, które nie do końca rozumieją różnice pomiędzy tworzeniem rozwiązań opartych o Machine Learning a zwykłym developmentem. W takim wypadku, firma może oczekiwać, że ukończenie przez Ciebie dobrego modelu to tylko kwestia czasu, w rzeczywistości Twoja praca ma charakter R&D i ciężko jest dokładnie oszacować końcowy efekt Twojej pracy. Wtedy mogą pojawiać się pytania o to, jak długo jeszcze zajmie Ci Twoja praca. Najgorszym co możesz zrobić w takiej kwestii, to ulec presji i odpowiadać na pytania w formie sugerującej, że „nie dużo Ci już zostało”, „zaraz skończysz”, „prawie działa”. Nie powinieneś też mówić o tym, jakiej metryki spodziewasz się na swoim modelu, zanim go nie skończysz i nie sprawdzisz czy metryka modelu odzwierciedla zmianę w biznesie. Nie chcesz znaleźć się w sytuacji, w której biznes zawierzy Ci na słowo i zacznie obiecywać coś klientowi albo uruchomi reklamę produktu. Potem możesz doświadczyć wielu nieprzyjemności i rozczarowań. Pamiętaj, że to Ty jesteś ekspertem w tej kwestii i staraj się edukować swoją firmę, aby ułatwić sobie pracę i oszczędzić przyszłych frustracji.
Umiejętności miękkie są często dużo ważniejsze niż twarde
Nawet najlepszy model się nie obroni sam. Prezentując wyniki do biznesu, staraj się mówić prostym i zrozumiałym językiem, unikając słownictwa specjalistycznego. Detale i przygody zachowaj dla zespołu technicznego. Zespół biznesowy najbardziej interesuje to, czy wyniki modelu są wiarygodne oraz jaką dają im wartość. Nie zmuszaj słuchaczy do samodzielnej interpretacji wyników modelu — unikaj podawania suchych liczb i wykresów. Mów o tym, co może się zmienić po użyciu modelu, np. „będziemy w stanie zautomatyzować część pracy obsługi klienta”, „zyskamy metodę na wyłapywanie oszustów” itp. Najlepszą formą prezentacji jest forma interaktywna, w której samodzielnie pokazujesz jak model działa, zwraca predykcje i zachowuje się w różnych sytuacjach. Możesz opowiedzieć historie na danych biznesowych Twojej firmy. Bardzo efektywnym działaniem jest stworzenie prostego frontendu, np. za pomocą aplikacji we Flasku i zahostowanie go w celach poglądowych. Nie wstydź się białej strony i tabelek HTML-owych — to naprawdę wystarczy.
