W ostatnim czasie zalała nas bezprecedensowa fala popularności tematyki Data Science/Machine Learning. Mnóstwo szumu w mediach społecznościowych, tłumy na meetup-ach i konferencjach, popularność profilowanych studiów podyplomowych – to zaledwie kilka jej przejawów. Niewątpliwie rośnie świadomość potęgi metod zaawansowanej analizy danych i korzyści, które wynikają z jej stosowania. Gro organizacji traktuje je priorytetowo, wykorzystując do osiągnięcia przewagi rynkowej (patrz: How companies are using big data and analytics). Narzędzia i metody znane od lat wreszcie doczekały się szerokiego wejścia na rynek. To bardzo dobrze – wszyscy na tym skorzystamy. O ile… wspólnie zadbamy o to, aby wykorzystywać je we właściwy sposób i we właściwym momencie…

Niestety, terminy Data Science/Machine Learning otoczone są wieloma mitami, które przeszkadzają w ich skutecznym wdrożeniu w organizacjach. Poniżej zebrałem kilka strasznych historii, które na swój sposób przerażają i potwierdzają, że mity te żyją i mają się dobrze. W rzeczywistości historii jest więcej, a z intencją utworzenia tego wpisu nosiłem się przez kilka tygodni, starając się uporządkować i wyselekcjonować te najbardziej reprezentatywne.

Technologia ponad wszystko

Historia 1. (prelekcja w ramach konferencji): „Machine Learning to problem programistyczny. Chcesz być prawdziwym analitykiem? Musisz zrozumieć, jak zarządza się kodami i je wersjonuje, musisz mieć konto na GitHubie”.

Machine Learning to NIE konkretna technologia ani określony tryb pracy z nią. To umiejętność sformułowania problemu analitycznego zgodnego z rzeczywistością biznesową, zgromadzenia danych, wykonania analizy i wdrożenia jej. Realizujesz to za pomocą kodu czy gotowych narzędzi? Rozwiązanie komercyjne czy open source? Baza danych, silnik strumieniowy, Hadoop? To Twój wybór – każda ścieżka jest dozwolona, jeśli prowadzi do określonych korzyści biznesowych.

Budowanie fałszywych tautologii, utożsamiających analitykę z konkretną technologią, a rolę analityka z określonym profilem informatycznym (np. zaawansowany programista) to jeden z kardynalnych błędów. Efektywna budowa analitycznej organizacji powinna być skoncentrowana wokół realizacji celów biznesowych, a nie wykorzystania określonych technologii. Zainteresowanym tą tematyką polecam raport EY: Becoming an analytics-driven organization to create value.

Po co rozumieć Biznes?

Historia 2. (fragment rozmowy dwóch analityków): „Ostatnio usłyszałem z biznesu, że powinienem dogłębnie zrozumieć procesy, które analizuję i modeluję. Ale ja nie chcę, mnie interesują algorytmy i programowanie”.

Fascynacja ogólnodostępnymi i szybko rozwijającymi się technologiami powoduje, że wielu ich użytkowników ulega pokusie przesadnego zanurzenia się w zagadnieniach technologicznych czy związanych ze specyfiką algorytmów, jednocześnie lekceważąc wymiar biznesowy.

Zgadzam się w pełni – analityk powinien jak najlepiej znać narzędzie, w którym pracuje, powinien rozumieć, na czym polega regularyzacja w gradient boostingu albo jak dokonać dekompozycji szeregu czasowego. Najważniejsza jednak jest świadomość, jaki problem biznesowy rozwiązuje, jak jego analiza zostanie wykorzystana i np. jakie wiążą się z tym ograniczenia. Bez tego nie skonstruuje poprawnej zmiennej celu, nie określi odpowiedniego wstępnego zestawu predyktorów czy odpowiedniego kryterium sukcesu dla modelu. Przede wszystkim jednak nie stworzy produktu, którego zastosowanie przyniesie biznesowi wymierne korzyści.

Brak ścisłej współpracy ze stroną biznesową prowadzi do powstania „korporacyjnych laboratoriów”, których modus operandi jest badanie i nauka, a nie realne wsparcie procesów podejmowania decyzji. O tym i innych wyzwaniach organizacyjnych we wdrażaniu Data Science ciekawie opowiada artykuł z KDDNuggets.

Machine Learning w każdej lodówce

Historia 3. (prelekcja w ramach konferencji – celem omawianego projektu była jednorazowa estymacja jednej (!) liczby klientów, którzy wykonają określoną czynność w zadanym czasie): „Testowaliśmy metodę A, ale wynik nie zgadzał się z naszą intuicją, potem testowaliśmy więc metody B, C, D… K i w końcu się udało”.

Choć to trudne, postaram się abstrahować od sensowności powoływania projektu analitycznego, którego celem jest jednorazowe określenie, ilu klientów wykona nie występującą wcześniej czynność w zadanym fragmencie czasu. Postaram się również nie odnosić do faktu, że, być może, zapłacono za niczym nieuzasadniony pusty przebieg kilkunastu metod z zakresu analizy przeżycia, prognozy szeregów czasowych czy modeli machine learning.

Skoro jednak strona biznesowa zatwierdzała wyniki analizy, opierając się wyłącznie na swojej intuicji, to może lepiej byłoby niezależnie podpytać o prognozę kilku ekspertów dziedzinowych, a potem uśrednić otrzymane odpowiedzi i przyjąć tą wartość za ostateczną? Tak zwana kolektywna inteligencja potrafi zdziałać cuda.

Machine Learning to nie uniwersalne panaceum na każdą możliwą bolączkę. Zdaję sobie sprawę, że kusi i zaburza nasze myślenie krytyczne, ale czasem naprawdę nie wystarczy: danych, czasu, zasobów albo po prostu szybciej zapytać eksperta…

Powyższy wpis to subiektywny przegląd obserwacji z ostatnich miesięcy. Zachęcam do dzielenia się własnymi doświadczeniami i zapraszam do dyskusji!