Nie ma żadnych wątpliwości – wszystkim nam zdarzają się pomyłki. Dziś przygotowałem listę siedmiu najczęściej popełnianych błędów przez osoby pracujące z danymi.
Na początku dodam niewielkie zastrzeżenie. Do tej pory we wszystkich wpisach na moim blogu starałem się być możliwie obiektywny. Ten jest zupełnie inny. Przygotowana lista, to w 100% mój subiektywny wybór, dlatego proszę, przefiltruj wszystko o czym piszę przez „swoje okulary”.
Wpis ten oczywiście nie wyczerpuje tematu. Przygotowując się do niego, bez większego wysiłku zbudowałem dużo dłuższą listę, składającą się z niemal 30 punktów i spośród nich wybrałem te najistotniejsze.
Nie ukrywam, że chciałbym Cię też nieco sprowokować do przemyśleń, kwestionowania własnych działań i w końcu do dyskusji. Proszę, pamiętaj, że to, co działa u mnie, niekoniecznie musi równie dobrze sprawdzać się u Ciebie. Nie ma gotowej ścieżki, która jest odpowiednia dla każdego, dlatego uważam, że warto dyskutować i dzielić się swoimi przemyśleniami.
1. Przekładanie teorii ponad praktykę.
Czy kiedykolwiek działałeś w ten sposób: „Jeszcze tylko zrobię jeden xyz (za xyz wstawić dowolne: kurs/szkolenie/studia podyplomowe/etc.) i biorę się za wdrażanie wiedzy w praktyce”?
Powyższa sytuacja to syndrom wiecznego studenta. Ktoś nawet powiedział, że nauka jest nową prokrastynacją. Łatwy dostęp do kursów i szkoleń nie ułatwia zadania. Zawsze warto mieć z tyłu głowy, że sama wiedza jest bezużyteczna bez jej praktycznego zastosowania.
Idealnie jest jak najszybciej przekuwać wiedzę w praktykę. Jeśli nie masz możliwości, by w pracy zastosować nowe umiejętności, to zbuduj własny projekt. Po prostu pobierz dowolny zbiór z Kaggle lub UCI, wymyśl problem i spróbuj go rozwiązać.
DATA SCIENCE SUMMIT 2018Już 8 czerwca 2018, w Warszawie odbędzie się największa w Polsce konferencja, której głównym tematem jest Data Science. Organizatorzy przygotowali 7 ścieżek tematycznych, z których jedna odbędzie się z moim udziałem :) O godz. 13:40 w ramach ścieżki "Machine Learning & Miscellaneous DS topics" opowiem o problemie scoringu. Będzie to case study z procesu budowy systemu scoringowego. Podczas prezentacji omówię kolejne etapy projektu, począwszy od analizy potrzeby biznesowej, aż do walidacji i przygotowania finalnego modelu. Ciągle trwają zapisy, a liczba dostępnych miejsc jest ograniczona, dlatego warto się spieszyć. Więcej informacji na temat wydarzenia znajdziesz na jego oficjalnej stronie. Serdecznie zapraszam w imieniu swoim i organizatorów. Do zobaczenia! :)
2. Zaczynanie od praktyki.
To inna skrajność i zupełne przeciwieństwo błędu opisanego w poprzednim punkcie. Rozpoczynanie pracy bez merytorycznych podstaw jest ścieżką donikąd. Prędzej czy później wypływają na wierzch wszystkie niedoskonałości i ewentualne braki wiedzy trzeba wtedy szybko nadrabiać.
Tak jak zaznaczyłem, potrzebny jest odpowiedni balans pomięty teorią i praktyką. Moim zdaniem utrwalanie uprzednio zdobytej wiedzy teoretycznej powinno odbywać się poprzez jej praktyczne zastosowanie. To jest jedyna słuszna kolejność.
3. Zaniedbywanie umiejętności miękkich.
To dosyć powszechny błąd. Niektóre osoby są na tyle pochłonięte technikaliami, że zupełnie zapominają o umiejętnościach miękkich (komunikacja, empatia, proaktywność, umiejętność przejmowania odpowiedzialności, etc.). To przecież dzięki nim lepiej pracujemy zarówno wewnątrz zespołu, jak i na zewnątrz przy kontaktach np. z klientem.
Dla przykładu, w Data Science warto posiąść umiejętność przekładania technicznych elementów na język zrozumiały dla zwykłedo śmiertelnika. Przydaje się ona przy niemal każdym kontakcie z odbiorcami produktu, nad którym pracujemy.
Co również warte podkreślenia, umiejętności miękkie są zawsze w cenie, dlatego uważam je za inwestycję o wysokiej stopie zwrotu.
4. Przecenianie znaczenia narzędzi i języków programowania.
Narzędzia i języki programowania, to tylko… narzędzia. Kiedyś jeden z moich znajomych, osoba posiadająca w swoim portfolio kilkadziesiąt ukończonych projektów, na pytanie „Jakiego języka powinienem się uczyć, by osiągnąć sukces w DS?”, odpowiedział: „Matematyki”.
Nawiązując do poprzednich punktów, podstawy matematyczno – statystyczne niosą ze sobą ogromną wartość, bo są uniwersalne. Nigdy nie wyjdą z mody, nigdy nie ulegną przedawnieniu i nigdy przestaną być wspierane przez dostawcę oprogramowania. Można ich używać niemal w dowolnym narzędziu i języku programowania.
W codziennej pracy przekonuję się, jak ważne są solidne podstawy matematyczne. Mam okazję pracować z osobami, które jednocześnie kończyły studia informatyczne oraz matematyczne i widzę, jak dużą posiadają dzięki temu przewagę w DS. Być może rozwinę kiedyś ten temat 🙂
5. Przekładanie znaczenia technik i algorytmów ponad cel biznesowy.
Głęboko wierzę, że w pracy z danymi chodzi głównie o zadowolenia klienta i na tym też staram się skupiać każdego dnia. Zadowolenie to można osiągnąć poprzez rozwiązywanie bolączek i dostarczanie wartości biznesowej, która z kolei przekłada się na przewagę konkurencyjną.
To czy podczas danego projektu zastosujesz regresję logistyczną, czy głęboką sieć neuronową schodzi na dalszy plan i nie powinno być to celem samym w sobie. Innowacyjne techniki modelowania, biblioteki, narzędzia i algorytmy są fajne, o ile przynoszą realną wartość. Nie przekładaj ich ponad to, co jest głównym celem. Nie warto robić sztuki dla sztuki.
Jeśli chodzi o użycie algorytmu, to w mojej ocenie:
- Wiedza branżowa > algorytm.
- Przygotowanie danych > algorytm.
- Inżynieria zmiennych > algorytm.
- Wielkość próby uczącej > algorytm.
6. Implementacja rozwiązań „od zera”.
Błąd początkujących. Kiedyś tak robiłem (silnik rekomendacji – moja implementacji Fuzzy Theoretic Cosine i Fuzzy Set Theoretic). Poznając nowy algorytm, starałem się go samemu zaimplementować startując od zera. Być może i zyskiwałem dzięki temu dogłębną wiedzę na temat jego działania, ale uważam, że nie dawało mi to wielkiej przewagi nad osobami, które testowały „gotowce”.
Zdecydowanie lepiej jest zainwestować ten czas w praktyczną weryfikację działania różnych algorytmów dla wybranego problemu. Dzięki temu wiesz, który z nich sprawdza się lepiej w danych warunkach oraz jakie są jego mocne i słabe strony.
7. Zbyt szeroka specjalizacja w DS.
Stare przysłowie mówi, że osoba, która goni dwa zające, nie złapie ani jednego. Data Science to dosyć szeroki obszar i potencjalnych zajączków nie brakuje 😉 Niezwykle ciężko być jednocześnie specjalistą np. od credit scoringu i deep learningu. Zupełnie inne algorytmu, różne wyzwania i inne podejście do budowania modeli.
Osoby, które są jeszcze na początku swojej drogi, rzeczywiście powinny eksperymentować i próbować różnych rzeczy. Z czasem warto jednak podjąć decyzję o specjalizacji i zgłębiać wybrany obszar, który nas najbardziej interesuje i najbardziej nam odpowiada.
Podsumowanie
A co Ty o nich myślisz? Czy masz coś do dodania? Jak wygląda Twoja lista? Proszę, podziel się swoimi przemyśleniami w komentarzu 🙂
W moim odczuciu punkt drugi nie jest do końca takim błędem.
Podczas implementacji początkowych algorytmów, deweloper siłą rzeczy będzie zmuszony poszperać w internecie w celu znalezienia różnych informacji. Na początku implementacja nie będzie miała idealnej postaci, ale z czasem będzie nabierała kształtów i może być tak, że osoba szybciej i lepiej się nauczy niż gdyby zaczynała od książek.
Sam jestem bardzo zadowolony z kursów internetowych, choćby „Python for Data Science […]” na Udemy, gdzie część teoretyczna jest momentalnie poparta praktyką, po czym mamy okazję sprawdzić rozwiązanie. Taki kurs uczy głównie praktyki, natomiast gdybym zaczynał od zera, to przyjrzałbym się na początku części matematycznej, gdyż tak jak zostało wspomniane w obecnym wpisie, matematyka w Data Science jest na pierwszym miejscu, jeśli chcemy rozumieć co dzieje się z naszymi modelami, zamiast polegać na czarno skrzynkowym schemacie.
Pod punktem trzecim podpisuję się obiema rękami i nogami. W czasie studiów miałem okazję wykonywać projekty związane z Machine Learning oraz Artificial Neural Networks i gdy dochodziło do prezentacji swoich prac, niektórzy studenci pomimo ciekawych implementacji nie potrafili należycie ubrać wszystkiego w całość podczas prezentacji. Kończyło się to zwykle na tym, że reszta fascynowała się samą ideą, ale nie rozumiała niczego od środka.
Ciekawi mnie punkt szósty, gdyż implementacja od zera potrafi nas dobrze nauczyć zarówno teorii, jak i praktyki. Być może jest to nawet dobra metoda na zaczynanie nauki od zera, po czym można zacząć używać gotowych bibliotek, aby nie marnować czasu, ale też rozumieć co dzieje się pod maską.
Na koniec dodam, że ludzie mimo wszystko uczą się na błędach, tak samo, jak algorytmy uczenia maszynowego. Jest to proces naturalny, który uczy nas czego unikać na przyszłość. Abyśmy otrzymywali jak najwięcej „True Positives”, polecam notowanie najważniejszych wzorów, stronek i tym podobnych w notatniku, najlepiej elektronicznym jak OneNote, aby wszystko mieć zawsze pod ręką zsynchronizowane na wielu urządzeniach. Wiem, co mówię, gdyż przerobiłem już kilka kursów, przejrzałem masę artykułów i nie raz notatki wykonane przez nas samych potrafiły mi przypomnieć obszerne zagadnienie przez krótkie zerknięcie na coś, co wykonało się, choć odrobiną własnego wkładu.
Paweł, dziękuję Ci za komentarz i podzielenie się swoimi spostrzeżeniami! 🙂
Jeśli chodzi o punkt szósty, to osobiście nie jestem zwolennikiem implementacji od zera, choć wiem, że część osób właśnie tak robi. Ja po kilku miesiącach od takiej „implementacji” nie jestem w stanie jej powtórzyć. Może to kwestia indywidualna, ale uważam, że można lepiej zainwestować ten czas 😉
Bardzo podoba mi się Twoje porównanie ML do prawdziwego życia i tego, jak sami się uczymy. Notatniki elektroniczne są czymś w rodzaju rozwinięcia naszej pamięci. Warto się nimi wspierać i sam to praktykuję 🙂
Bardzo ciekawy artykuł!
Pozdrawiam
Dziękuję Natalia za miłe słowa! 🙂