Uczenie maszynowe w twojej firmie – mity

Współcześni ludzie usiłują tworzyć innowacje w sytuacji komfortu, bezpieczeństwa, przewidywalności, zamiast pogodzić się z tym, że potrzeba jest prawdziwą  matką wynalazku. To zdanie pada także w książce Taleba “Antykruchość”. Bardzo przydatna lektura, zwłaszcza teraz.

Czy dotarła do Ciebie ankieta z odpowiedziami na pytanie, kto wprowadził innowację i optymalizację procesów w Twojej firmie? CEO, CTO czy może COVID?

No właśnie… Wciąż nie wiadomo do końca, co się wydarzyło i jakie będą tego skutki. Natomiast pewne jest to, że obecna sytuacja zmusiła firmy do optymalizacji procesów lub wręcz zmiany na nowe. Wybór został ograniczony, inne potrzeby stały się wiodące. 

Przez ostatnie miesiące wiele firm musiało nauczyć się pracować inaczej: co najmniej wymagało się od nich pracy zdalnie, nie wspominając o innych regulacjach i koniecznej optymalizacji. 

Oczywiście są pewne trudności, ale też pojawia się zrozumienie po obu stronach, że to może być ciekawa i docelowo  wartościowa alternatywa. Ze strony pracodawcy to  mogą być dość duże oszczędności, jak też i elastyczność. Natomiast po stronie pracownika – mniej marnowania czasu i nerwów na dojazdy (jednak w dużych miastach to może być poświęcenie nawet godziny czy kilka godzin dziennie na dojazd), mniej gadania z kolegami i koleżankami, jak również elastyczność (mieszkając w górach można pracować dla firmy z Warszawy czy jakiejkolwiek innej).

Chociaż praca zdania ma szereg swoich minusów, to jednak ma też sporo zalet. Innowacja, optymalizacja procesów, to przecież są tematy, które każda firma “przerabia” w tej czy innej formie. To nie jest coś nowego, w sensie mówienia o tym, natomiast są powody, dlaczego to się nie dzieje. Tych powodów pewnie  jest wiele, ale spróbujmy dzisiaj ten temat ugryźć i podzielić się przemyśleniami w tej sprawie.

Postawmy pytanie w taki sposób: co sprawia, że wiele firm jest mało efektywnych? 

Odpowiadając warto zrobić krok wstecz i zdefiniować, czym jest efektywność. To jest dość trudne, bo w zależności od skali firmy i innych kontekstów należy definiować to pojęcie  inaczej. Podam Ci taki przykład. Czy jest możliwe prowadzenie dużej firmy bez biurokracji? Myślę, że jak zapytasz większość prezesów (sam to robiłem), to odpowiedź będzie brzmieć: nie.

Biurokracja jest konieczna, aby utrzymać ten olbrzymy mechanizm. Oczywiście większość z nich powie to raczej w prywatnej rozmowie, ale to już szczegół dotyczący wydobywania faktów. Chociaż są nieliczne przykłady, które pokazują,  że może być inaczej, ale to nadal pozostaje wyjątkiem od reguły. 

Warto zawęzić grupę, aby dokładniej omówić temat. Dlatego w tym odcinku skupię się przede wszystkim na firmach, którym już pomogliśmy lub obecnie wspieramy w ramach DataWorkshop. Są to tak zwane – MŚP (małe-średnie przedsiębiorstwa) oraz startupy.

Zgodnie z definicją obrót roczny takich firm do 50 mln EUR. Ta wiedza również może być przydatna dla większych firm, ale należy ją opakować w kilka kolejnych warstw, które są konieczne w dużych firmach. Mam na myśli to, że w większych firmach zawsze jest więcej dodatkowych kroków (spowodowane biurokracją lub pewnymi zjawiskami psychologicznymi, socjologicznymi, które występują u większych organizacjach).

Zacznijmy od tego, że osoby decyzyjne wielu firm obecnie przeżywają pewien szok, który pojawił się wraz ze wspomnianą wcześniej sytuacją. To zadziałało jak triger i bardzo silny argument na to,  że wprowadzenie zmian jest konieczne. Niestety w pośpiechu brakuje czasu na wnikliwe zrozumienie pewnych aspektów, stąd też pojawia się szereg mitów.

Już wcześniej przygotowałem odcinek “10 mitów o sztucznej inteligencji”, dzisiaj rozszerzę tę listę i dodam kolejne przykłady.

Mit 11: Wolimy klasyczne programowanie, bo jest mniej ryzykowne niż projekty uczenia maszynowego 

Projekty uczenia maszynowego (lub tak zwanej sztucznej inteligencji) są projektami R&D (badawczo-rozwojowe), czyli de facto  są obarczone dużym ryzykiem. 

Zwykle to jest prawda. Natomiast ostatnio “wychwytuję” źle interpretowane fakty, które są traktowane jako pewna szkodliwa wymówka. 

Jest słynne podejścia, które mówi, aby działać tak, by jak najszybciej popełnić błędy (tak zwane fail fast). Są ludzie, którzy  wykorzystują to we własnych celach jako wymówkę. To znaczy ich intencją jest coś innego niż uczenie się, aby osiągnąć postawiony cel poprzez popełniane błędy (ich motywacja może być jakakolwiek, np. zwykłe lenistwo).

Natomiast to podejście – popełnianie błędów jak najszybciej, ma sens wtedy, kiedy popełniając błędy wyciągamy szybko wnioski i w wyniku tego jesteśmy o krok bliżej do celu za każdym razem, za każdym popełnionym błędem. Dopiero wtedy uczymy się i możemy zrobić z tego wartość. 

Jeszcze raz to powtórzę – popełnianie błędów samo w sobie jest mało wartościowe, to ma sens wtedy, kiedy naszą intencją jest poznawanie pewnych spraw, o których wiemy mało, a chcemy dowiedzieć się więcej i dzięki temu efektywniej osiągnąć cel.

Mam podobne skojarzenie z tym, jak słyszę, że projekty ML/AI są projektami podwyższonego ryzyka, więc „lepiej kontynuować próbę rozwiązań klasycznym podejściem programistycznym”. 

Zrobię krok w bok i przypomnę, a właściwie powiem wprost, że stosowanie ML nie zawsze jest dobrym narzędziem, ale tam, gdzie ML może przynieść więcej korzyści niż klasyczne programowanie szkoda byłoby je odrzucać, twierdząc, że inne projekty IT są mniej ryzykowne.

Porozważajmy nad tym jeszcze trochę…

Tak się składa, że prawie trzy lata (zabrakło chyba miesiąca czy dwóch), pracowałem jako architekt w dużej firmie i jeszcze miałem okazję projektować wiele innych rozwiązań po drodze.  Dlatego wiem jak bardzo, tak zwany “projekt IT” jest również obarczony dużym ryzykiem.

Przypomina się mi klasyczne podejście, kiedy “biedni” biznes analitycy próbują zrozumieć założenia projektu pisząc bardzo długie dokumenty (czasem to było kilkaset stron) i następnie wyzwaniem staje się zrozumienie tych dokumentów a nie projektu 😉 

Jak ktoś doświadczył podobnych sytuacji (jak analiza kilkuset stron z założenia o projekcie), to pewnie teraz uśmiecha się, bo wie, że zwykle ciężko jest zaplanować i przepisać na papier założenia projektu z większym wyprzedzeniem, tym bardziej jeśli mamy do czynienia z trudniejszymi projektami.

Czas wiele weryfikuje i wprowadza ciągłe zmiany. W terminologii wspominanego na początku Taleba, przygotowanie takiej dokumentacji jest klasycznym “kruchym” podejściem, które ostatecznie bardzo łatwo może wywrócić do góry nogami nawet duże firmy i kompletnie nie jest odpore na zmienności, których nie brakuje w prawdziwym życiu.

Dlatego, wtedy jak mówię, że zamiast próbować udawać, że wiemy jaka jest rzeczywistość, lepiej jest wchodzić w interakcję z rzeczywistością wykonując małe kroki relatywnie małym kosztem. Wtedy słyszę jako kontrargument: „nie, nie możemy tak pracować, bo musimy z góry wszystko zaplanować, więc lepiej będziemy kontynuować klasyczne programowanie„.

Wtedy w mojej głowie pojawia się taka myśl:

“ale w sumie to niewiele zmienia, bo w klasycznym programowaniu też warto do tego podchodzić w taki sposób, czyli zakładać, że nie jesteśmy w stanie wszystkie zaplanować i być gotowym na zmiany”.

Nic nowego teraz nie odkryję, ale zwrócę uwagę, na to, że właśnie z konieczności dostosowania się do zmienności i ze świadomości nieprzewidywalności pewnych spraw do IT zaczęły wkraczać różne metodologie, które zmieniają podejście narażone na duże ryzyko niepowodzenia na to bardziej elastyczne np. Agile: Scrum, Kanban itd, aby móc w jakiś sposób zacząć zarządzać zmiennością w projektach.

Teraz dochodzimy do sedna. Klasyczne projekty IT również są obarczone dość dużym ryzykiem, bo również zawierają pewne czynniki, które są zmienne w czasie. To myślenie o ryzyku niewiele różni się od projektów ML. To, że pojawiają się dokumenty (np. stworzone przez biznes analityków) wcale nie rozwiązuje tego problemu, jedynie przykrywa go, czyniąc bardziej niebezpiecznym.

Czasem to jest zwyczajnie próba stworzenia poczucia, że mając gruby dokument wiemy wszytsko i wydaje się nam, że kontrolujemy naszą rzeczywistość, która prędzej czy później i tak nas zaskoczy. 

Nigdy nie kontrolowaliśmy otoczenia w 100% i nigdy nie będziemy w stanie tego kontrolować. Jedynie możemy próbować je lepiej poznać w tym momencie i odpowiednio zareagować.

Czas, którego potrzebujemy, aby dopasować się do kontekstu jest kluczowy. Widać to dobrze w czasie kryzysu. Im mniej czasu potrzebujesz, aby poznać reguły gry i się do nich dopasować, tym zwiększasz prawdopodobieństwo, że co najmniej przetrwasz, a może nawet wyjdziesz zwycięsko z trudnej sytuacji.

Podsumujemy rozważania wokół omawianego mitu.

Owszem projekty ML zawierają pewne czynniki ryzyka i rządzą się nieco innymi zasadami rozwoju niż klasyczne projekty IT. Natomiast warto też przyznać, że klasyczne projekty IT wcale nie są tak bezpieczne (jak czasem to może się wydawać). Tylko tak się złożyło, że w projektach ML wyraziściej podkreśla się ryzyko.

Dlatego powinniśmy mysleć raczej w kategoriach, jaką potencjalną wartość może wygenerować to czy inne rozwiązanie, jakie ma ryzyko i co możemy zrobić, aby to ryzyko minimalizować.

Mit 12: Projekty ML mogą skończyć się fiaskiem i to “słabo sprzedaje się” dla ludzi biznesu

Już w poprzednim punkcie uświadomiliśmy sobie, że klasyczne programowanie również zawiera sporo wyzwań i też może skończyć się źle. Popatrzmy teraz na ten wątek z drugiej strony.

Firma decyduje się zainwestować w innowacyjne podejście. Rozpoczyna proces przygotowania do ML lub nawet już trenuje pierwsze modele i okazuje się, że mamy porażkę…

Spróbujmy zdefiniować ten przypadek bardziej precyzyjnie, odpowiedzieć na pytanie, co to oznacza w praktyce, czym jest porażka?  Być może jest tym, że nie udało się wdrożyć modelu uczenia maszynowego na produkcję i tym samym przynieść jednoznacznie korzyści biznesowe. 

Tylko warto pamiętać, że aby taki model wytrenować i wdrożyć, trzeba wykonać kilka ważnych kroków przed rozpoczęciem samego procesu trenowania, np. lepiej sobie uświadomić, gdzie jesteśmy teraz. To nie jest tak łatwe, jak się wydaje. Następnie bardziej precyzyjnie zdefiniować cel. To jest jeszcze trudniejsze. Za chwilę rozwinę także ten wątek.

W ramach spółki DataWorkshop proponujemy zacząć od prostego kroku. Czasem ten etap nazywamy prototypem. Chodzi o sprawdzanie potencjału, czyli zbadanie realnych możliwości i ograniczeń firmy.

Proponujemy rozpoczynać ten krok bez większych założeń teoretycznych i zobowiązań po obu stronach (koszt tego działania jest relatywnie niski). Wynikiem tego kroku jest odpowiedzenie na pytanie, czy ML nadaje się do rozwiązania tego problemu, jaki jest potencjał efektywnego wdrożenia modelu uczenia maszynowego w tym kontekście. Jeśli okazuje się, że tego potencjału nie ma, to pojawia się odpowiedź dlaczego i co można ewentualnie naprawić. Nierzadko udaje się odkryć inny obszar, który można naprawić, o którym firma wcześniej nie myślała mimo tego, że np. ucieka w tym miejscu sporo pieniędzy lub czasu.

Dlaczego podchodzimy do tego w ten sposób? Życie nauczyło, że zawsze jest wiele wymiarów, kiedy na słowach rozmawiamy o czymś, ale w praktyce jest zupełenie inaczej. Na przykład zwykle zarząd jest pewny, że firma ma dane i jest ich dużo, ale jak zaczynamy je sprawdzać, okazuje się, że nie jest tak kolorowo. Nie chodzi oczywiście jedynie o dane czy infrastrukturę.

Często wychodzą na jaw także zupełnie inny problemy np. te dotyczące współpracy z zespołem i to, że ludzie wykonując pewne czynności totalnie nie rozumieją, co robią, dlaczego to robią itd.

Podsumujmy ten punkt.

To prawda, że wdrożenie modelu ML na produkcję, może nie udać się za pierwszym czy drugim razem. Natomiast zrozumienie, dlaczego się nie udało, jest ogromną wartością samą w sobie i pomaga rozwiązać problemy (czasem jest to dług techniczny) lub inne, które są. Zamiatanie ich pod dywan wcześniej czy później źle skończy się.

Warto zwrócić uwagę na to, jak zbiera się doświadczenie. To jest  kwestia podejścia i robienia małych kroków, aby pewne błędy popełniać jak najszybciej, aby koszt tych błędów był  jak najmniejszy.  Należy gryźć „słonia” po kawałku.

Też warto dodać, że bardzo mało jest firm w Polsce, które np. tworzą samochody autonomiczne lub próbują wysłać rakietę na Marsa. Większość firm ma zupełnie inne wyzwania, takie bardziej przyziemne, ludzkie, o mniejszm stopniu skomplikowania technologicznego. Wdrażanie uczenia maszynowego może być dobrą okazją, aby “posprzątać na podwórku” i wprowadzić efektywniejsze procesy w swojej firmie.

Mit 13 – mamy dane, więc już możemy trenować modele – zróbmy to jak najszybciej

Posiadanie bazy danych to warunek konieczny, aby zaczać projekt z uczeniem maszynowym w roli głównej, ale niewystarczający. Równie dobrze możemy odpalić losowy generator i zapisać wynik do bazy danych, ale czy to ma wartość? No właśnie…

Dobra kultura pracy z danymi to pewna umiejętność, dzięki której minimalizuje się zniekształcenie rzeczywistości poprzez dane. Teraz pomijam aspekty bezpieczeństwa i prawne, które są bardzo ważne, ale to wykracza poza ten wątek. Skupmy się bardziej na aspektach technicznych, bo jeśli technicznie robimy to źle, to wtedy nie będzie wartości dodanej.

To, co my staramy się robić w ramach aktywności DataWorkshop, to ciągle weryfikować dane, które mamy. Warto próbować dojść do tych samych wyników na różne sposoby. Podam Ci prosty schemat, który w praktyce zwykle bywa nieco bardziej skomplikowany, ale chodzi o zrozumienie myśli.

1. Obliczamy sumę poszczególnych kolumn i następnie znajdujemy sumę całości.
   
   
2. Obliczamy sumę wszystkich wierszy, a następnie znajdujemy sumę całości.
   
   
3. Porównujemy liczbę 1 z liczbą 2 (powinny być identyczne).
   
   
   

To jest klasyczne podejście `double-check`. Kiedy na wszelki wypadek sprawdzamy coć „jeszcze raz”. Najlepiej, aby ktoś to zrobił niezależnie od nas. Swoją drogą, przy okazji pojawia się tutaj ciekawostka. Pracując z projektami R&D czasem opłaca się “dublować”, ale to nie jest synonim marnowaniu czasu. To jest przykład, kiedy robiąc to samo razem, ale niezależnie, można osiągnąć więcej niż robiąc to w pojedynkę. Wymieniając się pomysłami można osiągnąć znacznie więcej niż rozwijając w głowie jeden pomysł.

Dodatkowo ważnym elementem jest lepsze zrozumienie danych. Kiedy zaczynasz pracować z danymi pojawia się szereg podzbiorów, np. mamy użytkowników zalogowanych i niezalogowanych (i wszystkich razem), czyli trzy możliwe kombinacje. Czym bardziej “zagnieżdżamy” się w podzbiorze, tym większa jest szansa wymieszania kontekstów (na wiele sposobów), np. możemy powiedzieć, że mamy konwersję na poziomie 10%. Super! Tylko brakuje informacji, w którym podzbiorze. 

Podsumujemy dotychczasowe przemyślenia.

Dane są kluczowe, ale niewystarczające, aby przyniosły korzyści „same z siebie”. Nie ma czegoś takiego jak magiczna maszynka uczenia maszynowego, do której przekazuje się dane i sama się domyśli i wypluje „idealny wynik”. Czasem jest poczucie, że powstają rozwiązania automatyczne, tak zwane auto ML, natomiast bardzo ważny jest kontekst. Rozumienie tego kontekstu, to umiejętność interpretowania pewnych zdarzeń i zadawania właściwych pytań(!). 

Ważne, aby także pamiętać o tym, że praca z danymi wymaga skrupulatności jak w aptece. Podwójne sprawdzenie tych samych wyników (na różne sposoby) nie jest marnowaniem czasu, tylko raczej koniecznością, aby uzyskać wiarygodny wynik. To jest umiejętność, którą da się zapoczątkować, jak również i rozwinąć w kulturze firmy.

Mit 14 – mamy zdefiniowany problem do rozwiązania

Ten punkt może zabrzmieć dość kontrowersyjnie i czasem nawet obraźliwe dla osób, które myślą, że mają dobrze zdefiniowany problem. Niemniej ten punkt musi wybrzmieć, bo praktyka pokazuje, jak mało uwagi poświęca się zdefiniowaniu problemu.

W praktyce to dość często oznacza, że problemy definiowane są w taki sposób, który nie ujmuje pełnego kontekstu. Moja strategia jest taka, aby nazywać rzeczy po imieniu i ujawniać problemy. Nie chodzi o to, aby wskazywać palcem, kto popełnia błędy, ale o to, aby dokładnie zdefiniować, gdzie leży problem.

Dosyć często problem, który chcemy rozwiązać jest zbyt ogólnie zdefiniowany i nadal nie jest wiadome, co trzeba zrobić, aby się z nim uporać. W innym przypadku to może być po prostu źle zdefiniowany problem i nawet jeśli będzie rozwiązany dobrze, to nie przyniesie korzyści lub nawet gorzej – wygeneruje jeszcze więcej kłopotów lub kosztów. 

Dlaczego tak się dzieje? Jak zwykle jest wiele przyczyn, ale jedna z najważniejszych jest taka, że często problem zaczyna się definiować bez głębszego zrozumienia i analizy,  gdzie jesteśmy i jakie mamy możliwości na ten moment, aby to zmienić. 

Głębsze rozumienie, gdzie jesteśmy daje nam obraz kolejnych kilku wymiarów. W praktyce to zwykle oznacza zaangażowanie się odpowiednich osób, które potrafią zadawać właściwe pytania lub znajdować odpowiedzi na te pytania. Co oznacza słowo „właściwe”? Upraszczając – np. na podstawie prawdziwych danych, niż na upartym przekonaniu, że “ja wiem najlepiej”.

Przejdźmy do konkretnego przykładu, tym razem z obszaru bankowości. Bank ma dużo klientów i dużo pieniędzy, więc w praktyce to oznacza, że będą oszustwa (niestety, ten świat czasem jest brutalny).

Jak zdefiniujemy problem do rozwiązania?

Pomyśl przez chwilę…. Pewnie przyszło Ci do głowy, że naszym celem jest wytrenować model, który będzie wykrywał osoby,  które oszukują. Fajnie, tylko co to oznacza w praktyce? 

Jest człowiek X, który ma zamiar oszukiwać i co dalej?

Co to oznacza “wykryć”?

Pewnie chodzi o wykrywanie transakcji, które uznajemy za “oszustwa”. Dobrze, już lepiej. Bardziej precyzyjniej, ale nadal mamy szereg pytań, co to oznacza w praktyce.

Czy my wiemy, ile takich transakcji jest? Czy wiemy, jak to sprawdzić? Co powinno się stać, aby móc to sprawdzić?

Oczywiście mamy mieć dostęp do transakcji i uwaga, informację w sposób jednoznaczny stwierdzony, czy ta transakcja jest oszustwem czy nie. Co to oznacza w praktyce, że musimy posiadać jednoznaczny (matematyczny) wzór, który binarne stwierdza, czy ta transakcja jest “oszustwem” czy nie. 

Tutaj zaczynają się ciekawe rzeczy. Czy mamy taki wzór i jeśli mamy, to znów warto sobie zadać moje ulubione pytanie: co oznacza w praktyce? 😉

Są różne możliwości, jakie będą odpowiedzi. Jedna z nich jest taka: “tak mamy”. Mam zespół ludzi, który przypisuje flagę, czy to jest oszustwo czy nie.

Fajnie, tylko nadal nie wiadomo, co oznacza rzeczywiście oznacza: “przypisuje flagę”. W jaki sposób? Co powinno się stać, aby była przypisana flaga “oszustwo” do transakcji X.

Odpowiedź może brzmieć również tak: ” mamy spisanych wiele przypadków i nasz zespół walki z oszustami przeszedł szkolenie, jak należy interpretować takie sytuacje”. To jest ciekawy moment, do którego dotarliśmy, bo w naszym łańcuchu pojawia się subiektywny element, czyli człowiek, który interpretuje sytuację.

Kiedy mamy taką sytuację, warto pamiętać, że nawet ten sam człowiek jedną transakcję może zinterpretować inaczej  w zależności od kontekstu. Niezwykle ważne jest, aby upewnić się, w jaki sposób pojawi się informacja “tak/nie”. Jeśli w ten proces jest zaangażowany człowiek i model będzie się uczył na podstawie tych danych, to w najlepszym wypadku osiągniemy efekt, gdzie będziemy w stanie subiektywnie oceniać sprawę, jak to robili ludzie. Czy to było naszym celem?

Dobra zostawmy na chwilę tę subiektywność, chociaż to też zasługuje na uwagę. Teraz spójrzmy jeszcze inaczej na sprawę, zadając kolejne pytanie: “dlaczego?”.

Jest słynna metoda “5 whys”. Kiedy drążymy do prawdziwej przyczyny. To zacznijmy. 

1. Dlaczego chcemy walczyć z oszustami?
   Bo żyją za nasz koszt!
2. Dlaczego to jest źle?
   Bo jako biznes tracimy.
3. Dlaczego tracimy?
   Bo jako bank ponosimy koszt.
4. Dlaczego ponosimy koszt?
   Bo nam zgłasza o tym klient, że został oszukany
5. Dlaczego to powoduje, że ponosimy koszt?
   Bo mamy wypracowany system pokrycia utraconych środków dla naszych klientów wg pewnych zasad.
   
   
   

Patrząc na te odpowiedzi nasz cel jest inny niż złapanie wszystkich transakcji, które wyglądają jako oszustwa. W tym przypadku zależy nam, na tym, aby przewidzieć takie przypadki, kiedy wiemy, że jak to nastąpi, to użytkownik to zgłosi do nas i zakwalifikuje się do przypadku, kiedy trzeba będzie pokryć koszty.

W tym przypadku od razu mamy jednoznaczną odpowiedź, kiedy to się działo w przeszłości, bo znamy wszystkie przypadki, kiedy były zwroty.

Natomiast tu także pojawiają się trudności.

Zwróć uwagę, że w tym przypadku może pojawić się manipulacja związana z tym, że klient sam może zacząć oszukiwać, że został oszukany itd. Jeśli oczywiście zrozumie mechanizm tego działania i pokrycia kosztów. Kłopotliwa jest także sytuacja, kiedy klient nie zgłosił się po odszkodowanie, bowiem to wcale nie oznacza, że jest zadowolony lub jest mu obojętne to, co się wydarzyło.

Czasem po prostu nie chce mu się bawić w zwroty (może ma bolesne doświadczenie w innym banku), może po prostu nie wie, że może się zgłosić. Ostatecznie to może skutkować tym, że zrezygnuje z tego banku, bo poczuje, że bank ma pasywną opiekę (zamiast aktywnej). 

Dodam też, że to jest realny przykład i jest duża szansa, że używasz z usług tego banku.

Mam nadzieje, że udało się przynajmniej częściowo  pokazać, na ile ważne jest zdefiniować precyzyjnie cel i jak ta definicja może ewoluować w czasie.

Teraz zadanie domowe dla Ciebie.  Prowadzisz biznes. Sprzedajesz meble. Dajesz możliwość wykupić gwarancję na 12 lat (przykład z życia). Jako biznes chcesz ponosić jak najmniejszy koszt. Masz możliwość wykorzystać uczenie maszynowe do… No właśnie, do czego? Jaki w tym przypadku jest problem do rozwiązania? Pomyśl na spokojnie i daj znać w komentarzach.

Podobno Einsteina kiedyś powiedział

„Gdybym miał godzinę na rozwiązanie problemu, spędziłbym 55 minut na zastanawianiu się nad problemem i 5 minut na myśleniu o rozwiązaniach”.

Mit 15 – Jeśli mogę rozwiązać problem zwykłym programowaniem (da się opisać algorytm), to uczenie maszynowe jest zbędne

Na początek warto oczywiście powtórzyć, że ML nie musi być używany wszędzie i ze wszelką cenę, ale również nie należy go odrzucać w przedbiegach. Generalnie ta decyzja powinna się opierać na analizie, co bardziej się opłaca. Jechać rowerem, samochodem, czy może nawet czołgiem? 🙂

Ważne pytanie, które sobie tutaj należy zadać jest takie: jak duży koszt pojawia się na skutek błędu algorytmu zaprogramowanego wprost (czyli z góry są podane wszystkie reguły) lub jeśli taki błąd jeszcze nie wystąpił, to jak duży może być?

Następnie należy porównać, o ile lepiej sobie może poradzić algorytm, który został skonstruowany automatyczne, wykorzystując modele ML. Możemy dojść do co najmniej kilka ciekawych wniosków:

• ML radzi sobie lepiej poprzez “złapanie” mniej oczywistych sygnałów znalezionych w danych historycznych.
  
• Model “znajduje” te sygnały niezależnie (czyli np. nie jest  zależny od jednej osoby, która zna się na wymyślonym algorytmie).
  
• Czas potrzebny na adaptację do sytuacji jest zdecydowanie krótszy (np. min/godzin w porównaniu do tygodni/miesięcy)
  
  
  Obecna sytuacja mocno wpłynęła na to, jak zachowują się ludzie, rynek.
  
  Zachowanie przed marcem 2020 znacząco zmieniło się i trzeba dopasować się do nowych warunków, co w klasycznym algorytmie wymaga ponownej iteracji działań i wymyślenia (zmienić/dodać) nowych ścieżek koncepcyjne, a następnie  to oczywiście zaprogramować. Na to jest potrzebny czas.
  
  

Stąd wniosek jest taki, że nawet jeśli są procesy, które da się zaprogramować w klasyczny sposób, ale jednak koszt potencjalnego błędu jest drogi i/lub ta domena jest podatna na zewnętrzne zmiany (np. cała przygoda z wirusem), to wtedy warto spróbować użyć ML. Może się okazać, że to będzie bardziej pragmatyczne podejście.

Podsumujmy jeszcze raz 5 nowych mitów (właściwie od 11 do 15, bo pierwsze 10 już zdefiniowałem w poprzednim odcinku), które pojawiły się w tym odcinku.

Mit 11: Wolimy klasyczne programowanie, bo jest mniej ryzykowne niż projekty uczenia maszynowego 

Ryzyko jest wszędzie i również w klasycznych projektach IT (warto czasem to powiedzieć jeszcze raz na głos), ryzykiem trzeba umieć zarządzać, a nie bać się go i panikować.

Mit 12: Projekty ML mogą skończyć się fiaskiem i to “słabo sprzedaje się” dla ludzi biznesu

Nasza rzeczywistość, w której żyjemy jest dość złożona. Każdy biznes, który istnieje chociaż trochę, zwykle generuje złożone procesy, kiedy ciężko jest powiedzieć, że trzeba naprawić proces A czy B. To są przeplatane decyzje. Próba wprowadzenie ML do projektów może pomóc wejść w interakcję z rzeczywistością i zacząć zadawać pytania, które nie padły wcześniej. I to już wartością dodaną (niż tylko wdrażanie modelu ML na produkcję i przeliczanie tego wprost na pieniądze).

Mówię o tym ze strony praktycznej, jak to się dzieje się u nas, kiedy podejmujemy się współpracy jako DataWorkshop. Taka współpraca zwykle pomaga na wielu poziomach i otwiera oczy lub prowokuje do zadawania pytań wewnątrz zespołu. Wtedy pojawia się zwykle refleksja “hm… czemu o tym nie pomyśleliśmy?”. Odpowiedź jest prosta, są rzeczy, które ciężko wymyślić. Tylko wchodząc w interakcje z „żywym problemem” trochę więcej o nim się dowiadujemy.

Mit 13 – mamy dane, więc już możemy trenować modele – zróbmy to jak najszybciej

Praca z danymi wymaga pewnych umiejętności. Zaczynając od tego, jak technicznie sobie z tym poradzić, tym bardziej wtedy, kiedy jest skala. Kultura pracy z danymi jest ważna i może zająć trochę czasu aby zespół ją wypracował. Między innymi wspomniałem o ważności ciągłej weryfikacji, czy to, co wyliczyliśmy ma sens (np. próba osiągnięcia tego samego wyniku próbując z innej strony).

Wprowadzenie double-check wszędzie gdzie się tylko da. Też zwróciłem uwagę, że pracując z danymi czasem wręcz zachęca się do tego, aby dwie różne osoby wykonywały to samo zadanie, następnie zderzali swoje pomysły, aby powstał finalnie jeszcze lepszy pomysł.

Mit 14 – mamy zdefiniowany problem do rozwiązania

Zdefiniowanie problemu jest kluczowe. Nawet jeśli czasem wydaje się, że problem jest zdefiniowany, warto jeszcze zadać szereg pytań, które sprawdzą, czy faktycznie tak jest. Między innymi wspomniałem o metodzie “5whys”, ale mogą być też inne sposoby. Grunt, aby drążyć temat i nie zapominać o kontekście.

Mit 15 – Jeśli mogę rozwiązać problem zwykłym programowaniem (da się opisać algorytm), to uczenie maszynowe jest zbędne

Klasyczne programowanie ma wiele swoich zalet, ale teraz żyjemy w czasach, kiedy pojawiła się jeszcze jedna, dodatkowa, możliwość. Szkoda byłoby ją ignorować. Warto poznać mocne strony ML i wprowadzać to tam, gdzie rzeczywiście ma sens.

Takie mity udało się poruszyć teraz. Jeśli potrzebujesz pomocy i wsparcia przy wdrażaniu uczenia maszynowego, to zapraszam do kontaktu. Spółka DataWorkshop już ma szereg sukcesów na swoim koncie i chętnie podejmie się kolejnych wyzwań.

Jeśli ciekawi Cię, jak działamy w praktyce, to możesz posłuchać lub przeczytać o jednym z naszych projektów, który trwa i dotyczy tematu branży nieruchomości. Współpracujemy z firmą obido 👇👇👇

---

W kolejnym odcinku już szykuję dla Ciebie dwie historie, aby na przykładzie pokazać, jak wygląda myślenie, kiedy tworzy się projekty ML’owe. Chociaż te historie mogą być trochę zabawne, to zostały przygotowane w taki sposób, aby dało się łatwo z nich wyciagnąć wnioski i wykorzystać wskazówki w biznesie.

O czym będą te historie?

Jedna z nich będzie o tym, jak wykorzystując analityczne podejście, robi się prezent dla żony i porusza się skutecznie w mało znanym terenie.  

Podziel się proszę tym odcinkiem z osobami, którym może się przydać. Proszę poświęć dosłownie 2-3 min na to, aby zadać pytanie, komu to jeszcze może być pomocne i przekaż link.

Make Data Work.

Reshape the Future.

PRACTICAL MACHINE LEARNING