10 właściwych pytań przy wdrażaniu uczenia maszynowego

Już od roku jestem w 100% “na swoim”. Zazwyczaj gdy poznaję nową osobę, trzeba jakoś się przedstawić. W zależności od kontekstu robię to inaczej, np. mogę powiedzieć, że jestem ojcem lub podróżnikiem. Natomiast w miejscach gdzie chodzi o technologię zwykle mówię, że pomagam firmom wdrażać uczenie maszynowe we właściwy sposób. Ta pierwsza część pewnie brzmi dość standardowo, natomiast na czym polega ten “właściwy sposób”? O tym będzie dzisiejszy artykuł. Przedstawię Ci 10 pytań, które zadaję zaczynając współpracę z firmą, co umożliwia zwiększyć prawdopodobieństwo sukcesu wdrażania projektu.

Zanim zacznę przedstawię, jak się znalazłem tu i teraz. Przez dłuższy czas pracowałem na etacie dla wielu różnych firm – bardzo małych, małych, średnich i nawet w jednej z największych na świecie. W każdej z nich była różna kultura: klasyczne rodzinne, startupy czy korporacje. Dokładnie to samo dotyczy technologii, których mogłem nauczyć się i użyć. Miałem okazję zrealizować swoje ambicje w wielu obszarach, ale również popełniać błędy, z których z bólem, ale ostatecznie z przyjemnością wyciągałem wnioski. Dzięki tej różnorodności, teraz jest mi znacznie łatwiej łączyć kropki i rozumieć konteksty różnych firm.

Już ponad pięć lat temu dowiedziałem się, czym jest uczenie maszynowe i wtedy aktywnie zacząłem interesować się tym tematem, następnie zdobywać praktyczne doświadczenie na realnych projektach. Miałem szczęście, że mogłem poznać pewne obszary, które często ciężko zgłębić np.: projektowanie architektury tak zwanej BigData od zera, czyli takiej która potrafi kolekcjonować właściwe dane i odpowiednio je przetwarzać. Oczywiście projektowałem to wspólnie z zespołem. Uczestniczyłem w dyskusjach, widziałem dwie poprzednie (nieudane) wersje architektury, rozumiałem dlaczego i co dokładnie było źle zrobione. Miałem okazję również implementować kawałek nowej architektury (czyli pisać kod), dzięki czemu jeszcze lepiej zrozumieć, jak to działa od środka ze wszystkim szczegółami. Mimo tego, że już minęło trochę czasu, to nadal pamiętam wszystkie szczegóły, bo jest to więcej niż zwykła informacja. To jest to, co cenię najbardziej. Bo na slajdach prezentacji znacznie łatwiej rzeczy spinają się w całość, niż w praktyce.

Ostatni rok był dla mnie bardzo intensywny. Prowadzę podcasty, co zajmuje swoją drogą dość dużo czasu, ale czuję, że to ma sens (i dzięki Ci za to uczucie). Organizuję także autorskie kursy online (praktyczne uczenie maszynowe od podstaw, praktyczne prognozy szeregów czasowych), DataWorkshop Tour (szkolenie na żywo raz na rok, kolejne będzie 30-31 maja 2019) czy konferencję DWCC.

Poza tym jest także sporo inicjatyw, które mogą być mniej widoczne publiczne, a dają mi wiele satysfakcji. Wśród takich przedsięwzięć jest m.in. prowadzenie szkoleń i warsztatów na żywo dla firm na temat uczenia maszynowego. Odbywa się to z różnym podejściem, nie tylko ściśle technicznym. Organizuję je zazwyczaj dla dużych firm typu Oracle, ale nie tylko, jest wiele startupów, które chętnie wdrażają uczenie maszynowe w swojej pracy.

Z jednej strony jest ten obszar edukacyjny, w którym chętnie przekazuję wiedzę, co daje mi poczucie sensowności tego, co robię. Z drugiej zaś mam potrzebę tworzenia, bycia blisko realnych problemów i wyzwań. W ostatnim artykule kilka raz wspominałem o kilku pytaniach, które zadaję rozpoczynając współpracę z firmami wdrażając poprawnie uczenie maszynowe. Pojawiły się później pytania o mój system pracy, stąd pojawił się ten tekst. Jeśli zdecydujesz się wdrażać model uczenia maszynowego, skorzystaj z tego jako swoistej checklisty. Lepiej uczyć się na cudzych błędach unikając tym samym własnych – taniej to kosztuje i powoduje mniej stresu 🙂

Zaczynamy!

Pytanie 1: Jaki problem chcesz rozwiązać?

Pytanie jest fundamentalne i pewnie w każdym poradniku można je znaleźć, ale jednak to pytanie faktycznie jest ważne. Tak się składa, że kiedy mówi się o tak zwanej sztucznej inteligencji, to dość często spodziewa się magii. Po prostu przyjdzie magiczny człowiek, z magicznym kapeluszem, z którego wyskoczy królik, czyli rozwiązanie, które nagle przyniesie miliony. Oczywiście teraz specjalnie trochę koloryzuję, bo wprost mało kto się do tego przyznaje, ale jak zastanowisz się trochę dłużej to faktycznie masz takie wrażenie, że właśnie tego oczekuje się od uczenia maszynowego.

Cel musi być konkretny, bo inaczej ciężko jest go osiągnąć.

Warto przyznać, że zdefiniowanie celu jest trudnym zadaniem i czym bardziej się nad tym zastanawiasz, to rozumiesz, że w poprzednia wersja celu jest mniej udana i chodzi tak naprawdę o coś innego.

Einstein kiedyś powiedział: “Jeśli miałbym godzinę na rozwiązanie problemu to spędziłbym 55 minut myśląc o problemie, a następnie poświęciłbym 5 minut na jego rozwiązanie.” Podobnie jest w projektach uczenia maszynowego, tylko wprowadziłbym pewną adaptacje. Poprzez iteracji weryfikacji hipotez, po to, żeby zdefiniować cel… i na to faktycznie może zejść trochę czasu.

Przykłady źle zdefiniowanych celów:

1. Wdrożyć uczenie maszynowe i na tym zarobić
2. Poprawić proces X przy pomocy uczenia maszynowego
3. Wdrożyć uczenie maszynowe, bo konkurencja już ma

Przykład zdefiniowania celu, który brzmi już lepiej: zwiększyć konwersję od 2% do 2,5% dzięki lepszej rekomendacji produktów (obecny silnik opiera się na manualnych regułach).

Zwrócę uwagę, że zdefiniowanie celów jest przypadkiem, w którym bardzo istotny jest kontekst, to co ma sens dla jednej firmy, może być bez znaczenia dla innej. Na przykład dla jednej firmy poprawienie konwersji o 1% jest bardzo wartościowe, dla innej natomiast to będzie zdecydowanie za mało.

Pomyśl o uczeniu maszynowym, jak o narzędziu do optymalizacji. Z jednej strony to dobrze, bo dzięki temu potrafi robić rzeczy lepiej (bo wykrywa mniej oczywiste relacje w danych), natomiast to też ma drugą stronę medalu. Często oznacza to, że jak źle zdefiniujesz cel, to osiągając go nie odniesiesz sukcesu i uznasz, że w rzeczywistości chodziło o coś innego. Wyobraźmy sobie, że udało się zbudować idealny model i wynik jest pozytywny. Czy właśnie o to chodziło? Sztuką jest wyczuć słabe miejsca i wskazać, co może pójść źle. Wówczas zazwyczaj okazuje się, że cel był źle postawiony.

Przykład z życia wzięty. Jest firma ubezpieczeniowa, która chce efektywniej walczyć z oszustwami (“fraud detection”) i ma dużo danych historycznych, nawet ma odpowiedzi w danych (czyli flagi) kto jest oszustem. Celem było zastosowanie do tego uczenia maszynowego. Cel brzmi na pierwszy rzut oko dość konkretnie, prawda? Mamy dużo danych (ponad milion zgłoszeń odszkodowań), wiemy, które z tych zgłoszeń były oszustwem, trzeba teraz zastosować uczenie maszynowe, żeby to wykrywać automatycznie. Co może pójść nie tak? Jeszcze rozwinę ten wątek, kiedy będę mówić o lepszym rozumieniu danych, które posiadasz.

W kolejnych pytaniach pokażę, że co jakiś czas będziemy wracać do tego punktu, bo jest kluczowe i od niego zależy sukces całości.

Pytanie 2: Dlaczego chcesz rozwiązać ten problem, co więcej przy pomocy uczenia maszynowego?

Jak już wiemy lub wydaje nam się, że wiemy, jaki problem chcemy rozwiązać, pojawia się pytanie, dlaczego chcemy ten problem rozwiązać i to przy pomocy uczenia maszynowego? Być może jest jakiś inny problem, bardziej fundamentalny do rozwiązania, niż ten który został wybrany?

Spróbuję rozwinąć wątek od innej strony. Człowiek co jakiś czas popełnia błędy, to z góry należy przyjąć i zaakceptować. Pytanie tylko jak często i jak poważne są skutki tych błędów. Stąd można wyciągnąć wniosek, że procesy biznesowe, które mamy w firmie, mogą być błędne. Dość częsty powód, dla którego jakiś proces nadal istnieje, to to, że “przecież zawsze tak robiliśmy”. Faktycznie taki proces może istnieć przez dłuższy czas, chociaż jest błędny, ale wszyscy do tego przyzwyczaili się.

Mając błędny proces próba zautomatyzowania go brzmi jak słaba strategia. To oznacza, że wtedy można będzie popełniać błędy jeszcze szybciej i na większą skalę. Celem firmy jest coś innego niż marnowanie pieniędzy w szybszym czasie, dlatego pojawia się pytanie o zasadność rozwiązania danego problemu w szczególności z zastosowaniem uczenia maszynowego.

Kolejny przykład z życia wzięty. Wyobraź sobie firmę X, która zajmuje się promowaniem produktów firmy Y. Firma X poprosiła mnie o zoptymalizowanie tego procesu dla firmy Y. Zacząłem go badać zadając pytanie o konkretny powód zajmowania się tym szczególnym problemem i oczywiście zawsze proszę o sprawdzenie tego na faktycznych danych. Zwykle jest to dużym wyzwaniem, ale mocno naciskałem i okazało się, że jest kilka istotnych uwag do tego procesu, nie był on w pełni satysfakcjonujący. Co mogło pójść nie tak?

Promowana firma to sieć sklepów. Wyobraźmy sobie miasto, np. Kraków czy Warszawę, w których jest 5, 10 czy 15 takich sklepów, do których przychodzą klienci i kupują. Oczywiście jeśli klientów nie ma, to jest to bardzo złe bo firma nie zarabia, natomiast jeśli przyjdzie ich za dużo, to też niedobrze, ponieważ firma Y straci na jakości i długofalowo zacznie tracić (bo jakość produktu będzie gorsza, czyli nie będzie spełniona obietnica dla klienta). Koniecznym było znalezienie złotego środka.

Co było do optymalizacji? Skupić się na zapraszaniu klientów, kiedy ich brakuje, ale w taki sposób, żeby nie było ich jednocześnie za dużo. Na początek cel brzmiał dość konkretnie, zaczęliśmy badać to dalej. Poprosiłem o sprawdzenie na wykresach, jak często zdarza się sytuacja deficytu klientów i w jakich sklepach. Następnie posortowaliśmy to według ważności, gdzie za ważność było wzięte głównie kryterium obrotów w danym sklepie. Jak łatwo można było spodziewać się, był klasyczny wzór, że 20% sklepów przynosi 80% dochodu. Tutaj pojawiło się wyzwanie.

Była możliwość promocji per miasto, np. Kraków czy Warszawa. Narzędzie, które było używane umożliwiało promocję w danym mieście (bo reklama leciała na całe miasto). Z tych 20% najlepszych sklepów tak zwany deficyt klientów występował stosunkowo rzadko, czyli tylko mniej popularne sklepy miały największy problem z klientami. Teraz jeśli zaczniemy promować, żeby pomóc małemu sklepowi (wg jego przychodu):

1. wcale nie pomagamy tym lepszym sklepom, czyli tam gdzie są złote jaja, bo już tam klienci są,
2. wydajemy na reklamę (a przecież reklama kosztuje),
3. to może nawet pogorszyć sprawę, bo prawdopodobnie większy strumień ludzi pójdzie do tych lepszych sklepów (a to nie było zaplanowane tam)
4. budżet małego sklepu jest znacznie mniejszy na reklamę, więc ostatecznie koszt reklamy pokrywa duży sklep (dajesz po możliwościach, bierzesz po potrzebie), taki sobie socjalizm lub nawet komunizm 🙂
5. jest brak kontroli tego, co robimy, bo stosowane narzędzie do marketingu było jak armata, gdy była potrzeba strzelania do much.

Dlatego moją propozycją na tamtą chwilę było zatrzymanie się i rozważenie, czy na pewno rozwiązujemy właściwy problem. Czy jest sens ratować te mniejsze sklepy, których było 80%, a generowały jedynie 20% przychodu? Być może były popełnione gdzieś fundamentalne błędy np.: źle dobrana lokalizacja, duża konkurencja, być może po prostu trzeba je zamknąć i skupić się na tych lepszych lub coś zmienić. Oczywiście to należy robić ze zdrowym rozsądkiem, ale to do czego dążę to to, że podpięcie w tym przypadku uczenia maszynowego i oczekiwanie, że nagle przychody firmy wzrosną było nierealnym założeniem.

Pytanie 3: W jaki sposób będziesz mierzyć sukces?

Metryka sukcesu jest ważna i pewnie każdy o tym wie, że trzeba mierzyć, inna sprawa czy faktycznie to robią – wiedzieć to jedno, wprowadzać to w życie to już zupełnie inna historia. W uczeniu maszynowym metryka sukcesu nabiera nieco inne obroty. Pomyśl o tym w ten sposób: uczenie maszynowe udostępnia Ci pewne narzędzia, przy pomocy których możesz znajdować bardziej optymalne rozwiązanie dzięki wykrywaniu mniej oczywistych relacji. Trochę upraszczając możemy to nazwać “agresywnym optymalizatorem”. Istotnym jest, aby sobie uświadomić, że działa to na zasadzie “coś jest za coś”. Jeśli umożliwiamy modelowi agresywnie optymalizować według pewnej metryki sukcesu, to trzeba wziąć pod uwagę, jakie mogą być potencjalne skutki.  

Podam najpierw przykład czegoś zupełnie innego niż uczenie maszynowe. Załóżmy, że stawiasz cel, żeby za 20 lat średnia długość życia mężczyzn wynosiła 85 lat (przy obecnej średniej 74 lat). Jak myślisz, w jaki sposób można agresywnie zoptymalizować ten przypadek? Cytując Stalina “nie ma człowieka, nie ma problemu”. Innymi słowy wszystkie osoby mające 54 lub więcej (na moment wdrożenia tego programu) powinny bać się o swoje życie. Dlaczego? Ten agresywny optymalizator miałby do wyboru dwie opcje: albo zrobić tak, żeby te osoby umarły przed tymi 20 latami (wtedy nie trafią do statystyki, która zaczyna się liczyć za 20 lat), albo umożliwić tym osobom, żeby przeżyły co najmniej do 85 roku życia, czyli 31 lat od tego momentu (to czego pewnie spodziewaliśmy osiągnąć stawiając ten cel). Co jest łatwiejsze? No właśnie i na tym polega trudność zdefiniowania odpowiedniej metryki sukcesu przy agresywnej optymalizacji, bo nie oczekujemy tak dziwnych rozwiązań.

Przykład z życia wzięty. Prognozowanie sprzedaży. Jak najlepiej to mierzyć? Można posłużyć się procentami, gdzie średni błąd wynosi ok. 20% lub wartościami, gdzie z kolei średni błąd to 100 000. Każda z tych metryk ma wadę. Procenty są fajne, bo da się je łatwiej interpretować, ale w przypadku niskich kwot zaczynamy optymalizować mało istotne rzeczy. W procentach możemy widzieć ponad 20% różnicę, ale realna kwota jest nieznacząca dla firmy.

Mówiąc o metryce sukcesu warto wprost zaznaczyć dwie rzeczy. Są metryki sukcesu biznesowe oraz techniczne. Techniczne dla biznesu są mniej istotne, natomiast ważnym jest uświadomić osobie technicznej, że istnieje biznesowa metryka sukcesu i jak pokazuje doświadczenie, najlepiej żeby ta metryka mierzyła pieniądze. Brzmi dość oczywiście, ale ciężej jest w praktyce. Przykładowo automatyzujemy proces, na skutek czego oszczędzamy 20h pracy pewnego pracownika lub zespołu. Możemy pomnożyć ten czas przez stawkę i otrzymujemy pieniądze, ale są one wirtualne. W praktyce ten człowiek czy zespół nadal będzie pracował w firmie i dostawał pensję, więc koszty w firmie pozostaną te same. Może jednak pracownik w tym czasie robić coś innego.

Bardzo istotnym jest zrozumieć, gdzie fizycznie pieniędzy przybywa i gdzie ubywa. Tylko wtedy można maksymalizować pierwsze i minimalizować drugie. Jak to zrozumieć to inna sprawa, są na to techniki, np. stosuję event storming. Taka analiza zwykle też lepiej pomaga zrozumieć, czy rozwiązujemy właściwy problem.

Przy metrykach sukcesu warto zadać pomocnicze pytanie. Jaki poziom wg metryki sukcesu trzeba osiągnąć, żeby uznać projekt za:

• Porażkę
• Neutralny wynik (czyli wyszło na to samo)
• Sukces

Lubię jeszcze dodać czwarte kryterium – duży sukces. Ten punkt czasem może być nawet teoretycznym, czyli z góry wiadomo, że go nie osiągniemy, ale pomaga lepiej wyczuć kontekst. Jedna z firm, której pomagam, zdefiniowała to w ten sposób: wzrost konwersji po wdrożeniu modelu (gdzie konwersja nie koniecznie oznacza sprzedaż, ale nie mogę mówić o szczegółach):

• Porażka: wzrost mniej niż 0,3%
• Neutralny wynik: wzrost na 0,3%
• Sukces: wzrost na 1%
• Duży sukces: ponad 1%

W tym przypadku jest już zrozumiałe, że trzeba będzie walczyć o jeden procent i to jest bardzo dużo dla tej firmy. Wszystko jest uzależnione od danego przypadku – w niektórych organizacjach walka o 10% może być mało istotna.

Pytanie 4: Jak dokładnie prognozowanie będzie wpływać na biznes?

Wyobraźmy sobie, że mamy idealny model (czyli taki, który nie myli się, co jest bardzo trudne lub wręcz niemożliwe  do osiągnięcia w całym świecie). Na jakie decyzje i w jakim stopniu będzie wpływała prognoza z tego modelu?

To jest ważne pytanie, żeby wyczuć:

1. Czy naprawdę na skutek tej decyzji powstaje wartość dodana i jak duża?
2. Jak duże jest ryzyko w przypadku, jeśli model podejmuje złą decyzję?

W firmie odpowiedzialnej za wysyłkę maili jedny z dużych wyzwań jest wykrywanie złych maili i nie wysyłanie ich na zewnątrz. Czym jest zły mail? To już jest trudne do zdefiniowania, na początek weźmiemy łatwiejszy przypadek. Wykrywanie tak zwanych “phishingów”, czyli maili które chcą się podszyć pod kogoś innego (np. znany brand, bank itp.) po to, żeby zdobyć coś od Ciebie (namiary na kartę kredytową, hasło lub coś innego wartościowego z punktu widzenia tego złodzieja). W tym przypadku po wspólnych dyskusjach stało się jasne, że koszt przegapienia takiego phishingu jest bardzo wysoki.

Przy czym chodzi o coś więcej niż potencjalna kara pieniężna, bardziej o problemy związane z brandem, bo to zwykle dość głośno rozchodzi się po internecie. Dlatego trzeba zrobić wszystko, żeby zatrzymać takie maile, nawet jeśli decyzja będzie błędna. To oznacza, że jeśli mail był dobry, ale model uznał go za phishing, to jest akceptowalne. Dlaczego tak? Bo ostatecznie to działa (przynajmniej na razie) w ten sposób, że decyzje ostateczną podejmuje człowiek. Model tylko zatrzymuje możliwość wysłania tego maila bez sprawdzenia manualnego. Jeśli to był fałszywy alarm, to jest akceptowalne. Taki błąd jest policzalny (np. 10-15 min pracy jednej osoby), natomiast błąd w drugą stronę jest znacznie bardziej kosztowny. Ustalenie tego z biznesem jest ważne. Bo ostatecznie rozwiązując ten sam problem, można osiągnąć różne wyniki.

Podam Ci jeszcze jeden przykład, dlaczego warto lepiej zrozumieć ten punkt. W jaki sposób można maksymalizować wartość dodaną? Można rozwiązywać problem, który występuje bardzo rzadko, ale jest bardzo wartościowy lub w drugą stronę, malutki problem, ale na bardzo dużą skalę. Ważne, aby nie rozwiązywać małych problemów, które występują rzadko, bo wtedy ciężko z tego akumulować wartość dodaną.

Pytanie 5: Komu zależy na tym rozwiązaniu?

To pytanie obejmuje kilka obszarów. Należy określić, kto skorzysta na rozwiązaniu danego problemu, komu na tym najbardziej zależy. Ta osoba będzie sojusznikiem, który stanie się kluczowy we wdrażaniu projektu. Każda firma ma swoje opory wewnętrzne, procedury czy inne priorytety. Musi być ktoś wewnątrz firmy, komu naprawdę zależy na tym rozwiązaniu (bo to jest jego/jej odpowiedzialność) i też to rozwiązanie fascynuje tę osobę (to jest najlepszy przypadek, kiedy motywacja jest po prostu naturalna, czyli człowiek odpowiedzialny za innowację, faktycznie interesuje się nimi, a nie tylko swoją pensją).

Firma, jako organizacja to jest zbiór dość złożonych i nawet chaotycznych procesów, w który są zaangażowani ludzie. Próba zmiany czegokolwiek zawsze wywołuje napięcie, bo ludzie po prostu nie lubią zmian. Czym starsza jest osoba, tym mniej jest podatna na zmiany (nie chodzi o wiek tylko o sposób myślenia, bo są tacy, którzy już po 20 roku życia nic nie chcą modyfikować). Trzeba to zaakceptować i wziąć pod uwagę, w czasie wdrożania rozwiązania.

Jeśli nie masz sojuszników w zespole, którym zależy na wdrożeniu projektu, to od razu zmniejsza się prawdopodobieństwo, że zakończy się to sukcesem, nawet jeśli model już będzie wytrenowany.

Oprócz sojuszników warto zwrócić uwagę na przeciwników, czyli osoby, którym bardzo zależy na odwrotnym (przeszkadzać we wdrożeniu, dość często pasywnym, ale skutecznym sposobem). Te osoby mają różne motywacje, np. dlatego że ego przeszkadza, nie chcą dużych zmian, czują jakieś własne zagrożenie lub cokolwiek innego.

Przykład z mojego życia, kiedy w tej samej firmie była osoba, która bardzo chciała wdrożyć uczenie maszynowe, ale również była inna osoba, kluczowa w tym projekcie, która nie chciała z pewnych powodów tego robić. Ten przykład nauczył mnie, jak ważnym jest znalezienie sojuszników i zbudowanie strategii motywacji osób, których dotknie mniej lub bardziej bezpośrednio wdrożenie tego projektu (w szczególności to dotyczy dużych firm).

jak przerobiłem tę lekcję, to współpracując z inną dużą organizacją już wziąłem to pod uwagę. Wypracowałem znacznie bardziej przemyślaną strategię dotyczącą motywacji ludzi zaangażowanych w projekt, ale okazało się, że nie przewidziałem jeszcze jednej rzeczy. Okazuje się, że sojusznik i przeciwnik może być tą samą osobą. Skończyło się tym, że udało się zbudować prototyp i z jednej strony to był sukces (bo faktycznie była wartość dodana), ale z drugiej strony wdrażając ten model on robił zbyt przezroczysty proces i pewne decyzje wyszłyby na jaw, co z kolei było niekorzystne dla osób decyzyjnych.

Ogarnięcie strategiczne tego punktu, jest bardzo ważne w szczególności dla dużych firm, bo tam polityka jest kluczowym elementem wszystkich procesów.

Pytanie 6: Jakie dane są zbierane?

Dane są ważne – są pokarmem dla modelu. Jest fajne powiedzenie: “jesteś tym co jesz, więc uważaj co jesz!” 🙂 Natomiast w tym przypadku, uważaj na to, co je Twój model.

Wróćmy do przypadku firmy ubezpieczeniowej z pierwszego pytania. Co mogło pójść źle? Zwykle w tej sytuacji stosuję pewną grę intelektualną. Wyobraź sobie, że udało się zbudować idealny model, który nauczył się na podstawie danych i podejmuje dokładnie te same decyzje. Czy to jest, co było planowane? Niby tak, ale… Dalej zadałem pytanie pomocnicze: jaka jest definicja oszustwa i w jaki sposób określa się, które zgłoszenie nim jest? Co to w praktyce oznacza, gdy flaga ustawiona na jedynkę (czyli fraud) w bazie?

Zaczęły wychodzić bardzo ciekawe rzeczy:

1. Firma ma wiele oddziałów i każdy oddział ma osobę lub zespół, który zajmuje się wykrywaniem oszustw.
2. Ten proces jest dość subiektywny i każdy oddział to robi trochę po swojemu.
3. Nawet w tym samym oddziale różne osoby podejmują w inny sposób decyzje, czyli obserwujemy brak spójności.
4. Co ważne ta decyzja tak naprawdę jest sugestią, że to może być oszustwo, ale czy było, to już nie wiadomo.

W tym przypadku mając idealny model maksymalnie to, co możemy osiągnąć to zgadywanie subiektywnych sugestii, że to może być oszustwo. Jak zadałem pytanie, czy tego właśnie firma chce, to sprawiło to pewien dyskomfort, bo cel był jednak inny. To był dobry moment, żeby zastanowić się po raz kolejny, jaki problem rzeczywiście chcemy rozwiązać.

Kolejny przykład. Wyobraź sobie sieć sklepów, która potrzebuje uporządkować proces logistyczny między innymi przewidywanie popytu i zapewniania odpowiedniej ilości produktów w danej lokalizacji. Mamy dane, ile było potrzeba produktów w danym sklepie. To już jest pewien wstęp, ale pojawiają się kolejne pytania:

1. Skąd mamy dane o potrzebnych produktach? Od kierowników poszczególnych sklepów, więc od razu można spodziewać się, że ta decyzja nie będzie spójna w skali globalnej.
2. W informacji zwrotnej wiemy, ile produktów trzeba było zwrócić (czyli nikt nie kupił). Co oznacza zwrot zero? Brzmi jak stan idealny, czyli trafiony przez kierownika. Czy na pewno tak jest? Bo zero może być wtedy, jak faktycznie prognoza była idealna lub również wtedy, jak już na początku dnia było wszystko wyprzedane, następnie w ciągu całego dnia przychodzili klienci, żeby kupić ten produkt zastając puste półki. W tym przypadku nie mamy informacji, ile klientów chciało jeszcze kupić, tylko jest zero, które udaje idealną wartość dodaną.

Były jeszcze inne niespodzianki w tym problemie, ale to, do czego dążę, to pokazać na ile ważne są dane i zrozumienie, co one faktycznie oznaczają (nie tylko to, co nam się wydaje).

Oprócz tego, że warto wiedzieć, jakie dane zbieramy, to też warto mieć mechanizm, który zapewnia jakość tego procesu. Pytanie dodatkowe może brzmieć w ten sposób: na podstawie czego możemy być pewni, że proces zbierania danych działa zgodnie z oczekiwaniami przez cały czas? Dodatkowo można zastanowić, w jaki sposób dowiemy się, jeśli coś pójdzie nie tak i czy jesteśmy gotowi na taką informację (jaka będzie reakcja na to zdarzenie)?

Z doświadczenia osoby, która projektowała i implementowała kilka architektur m.in. do zbierania danych, zauważam, że po pewnym czasie zaczynasz się bać monitorować pewne procesy, bo z góry wiesz, że coś na pewno się popsuje. Oczywiście teraz żartuję, bo właśnie o to chodzi, że należy wprowadzać monitoring w różne miejsca na tyle efektywnie, aby wyłapywać te problemy. Na pewno coś będzie się psuło (np. połączenie padło na chwilę). Natomiast bądź pewny/a, że czym lepiej przygotowujesz się na wykrywanie takich błędów, tym bardziej świat może Cię zaskoczyć.

Pytanie 7: Jak często (będzie robione prognozowanie) i ile czasu jest na prognozowanie?

To jest pytanie, które umożliwia lepiej zrozumieć kontekst i może znów odesłać Cię do pierwszego pytania. Jakie są możliwości? Coraz częstsze staje się robienie prognozowania w czasie rzeczywistym i to oczywiście jest potrzeba biznesowa. Na przykład jeśli robimy wykrywanie oszustw w transakcji, to mamy dosłownie sekundę lub mniej do powiedzenia, czy warto przepuszczać tę transakcję czy nie. W tym przypadku to powinno się dziać w czasie rzeczywistym. Podobny przykład dotyczy zarządzania reklamami, gdzie w grę wchodzą dwie platformy DSP (Demand Side Platform) oraz SSP (Supply-side platform). W tym przypadku sekunda to jest zdecydowanie za dużo i trzeba działać znacznie szybciej, np. 100 ms lub jeszcze szybciej.

Natomiast dość często realizacja drogiego rozwiązania w czasie rzeczywistym jest opcjonalna, więc można robić z większym opóźnieniem. Na przykład robić prognozowanie raz dziennie lub nawet jeszcze rzadziej. Dzięki czemu rozwiązanie może być tańsze. To jest tak jak przepuścić 100 osób otwierając bramkę raz lub robić to samo dla każdej osoby na żądanie. Pewnie czujesz, na ile optymalna jest sytuacja grupowania ludzi lub w terminologii BigData dzielenie to na “batche”. Warto tutaj dodać, że architektura w czasie rzeczywistym zwykle jest kolejną warstwą do architektury batchowej, dlatego do tego przychodzi się z czasem w razie potrzeby.

Świat biznesu i techniczny dość często bywają bardzo różne. W jednym świecie pewna zmiana, jest jedynie drobną zmianą, ale w drugim to może kompletnie zaburzyć cały system. Oczywiście architektura powinna być planowana dość elastycznie, ale to ma swoje ograniczenia. Zbyt elastycznie też jest źle.

Przykład z życia. Wyobraź sobie firmę, która dobiera oferty dla swoich klientów, tym samym oszczędza ich czas lub po prostu umożliwia znalezienie tego, co ten klient mógłby przegapić. Klientów i ofert jest dużo. Zapytałem, jak często i dla ilu przypadków mamy robić prognozowanie. Bo jeśli to by było np. co godzinę dla wszystkich, to jest zupełnie coś innego, niż codziennie dla wszystkich czy na żądanie, czyli tylko dla tych, którzy akurat tego dnia tego potrzebują. Z punktu widzenia biznesowego robienie prognozowania na żądanie (czyli ok. 5% klientów dziennie) jest akceptowalne. Dzięki takiej informacji już wiadomo, jak należy to realizować na poziomie architektury.

Pytanie 8: Czy jest zaplanowana współpraca z ekspertem domenowym w tym projekcie (w sposób jawny, nie przy okazji)?

Model uczy się na podstawie danych według metryki sukcesu rozwiązywać podstawiony dla niego problem. Jak już wcześniej było powiedziane, na każdym z tych etapów może być popełniony błąd, to dlatego jest potrzebny człowiek, który regularnie będzie obserwować wyniki i dzielić się swoimi przemyśleniami. W szczególności w tych obszarach, kiedy model robi zupełnie coś innego, niż jest oczekiwane.

Na dzień dzisiejszy dla mnie ten punkt jest na tyle jest ważny, że to brzmi jako element konieczny do współpracy. W praktyce to oznacza, że musi paść deklaracja, że w każdej iteracji będzie uczestniczył ekspert domenowy, który ma na to zaplanowane (jawnie, nie po wieczorach) np. 4 godziny tygodniowo.

Dlaczego to podkreślam? Dość często taka osoba ma niemało obowiązków i ciężko jest się wyrwać na parę godzin do innego projektu. Jednocześnie jest to konieczne, bo taka osoba pomaga lepiej interpretować wyniki i wychwytywać pewne sprzeczności w zdefiniowanym celu, danych czy metrykach.

Możesz o tym punkcie również pomyśleć w ten sposób, że to jest osoba, która patrząc z boku utrudnia modelowi odejście w niepożądaną stronę. Dodatkowo ten człowiek zwykle spędził już sporo czasu w tej firmie i rozumie jej procesy od podszewki, dzięki czemu natychmiastowo może stwierdzić, co jest ważne, a co jedynie szumem. Oczywiście części rzeczy można się domyśleć, ale jednak ważna jest taka informacja zwrotna od osoby, która czuwa nad tymi procesami już od dłuższego czasu.

Podam Ci jeszcze jeden argument i wartość dodaną, dlaczego współpraca z ekspertem domenowym jest konieczna w trakcie budowania modelu. Już opisywałem problem z danymi, kiedy mamy pewne informacje, ale w praktyce one oznaczają coś innego, niż się spodziewaliśmy. Chociażby historia z firmy ubezpieczeniowej i oszustw. Spodziewaliśmy, że jak w danych jest informacja o oszustwie, to faktycznie tak jest.

Natomiast okazuje się, że to jest jedynie subiektywna sugestia osoby w pewnym dziale (niekoniecznie spójna z innymi pracownikami, nawet w tym samym zespole). Brzmi jak wyzwanie. Można teoretyzować i narzekać na dane, ale problem warto zacząć rozwiązywać. To, co można spróbować zrobić, to najpierw wdrożyć rozwiązanie, które wykonuje podobne decyzje jak dotychczas, ale w sposób autonomiczny, a następnie czym dalej, tym bardziej odpinać się od sugestii zwracając się do faktycznych oszustw, dzięki feedbackowi wprost od eksperta.

Kolejny przykład w tym obszarze. Kiedyś miałem okazję budować większy katalog produktów. Ludzie manualnie przypisywali kategorie do poszczególnych produktów. Proces zawierał sporo błędów, subiektywizmu i czasem chaotycznych ruchów. Ten katalog zawierał miliony produktów, zatem przejrzenie i uporządkowanie go manualnie było nieopłacalne. Nawet przejrzenie wszystkich możliwych gałęzi było zbyt trudne. Jak sobie poradziłem? Zacząłem trenować model na tym co jest próbując wycisnąć jak najlepszą jakość, czyli najmniejszy błąd. Następnie bardzo ostrożnie z ekspertem analizowaliśmy przypadki, które całkowicie odbiegały od normy. Przykładowo: produkt A według modelu był w gałęzi X, a normalnie w katalogu w gałęzi Y.

Te gałęzie rozchodziły się już na samym początku. Wyobraźmy sobie katalog Ikea, gdzie na pierwszym poziomie są kategorie (gałęzi) takie jak: sofy, oświetlenie czy elektronika domowa. Jak czuć to są rzeczy z dość rozłącznych kategorii, które ciężko pomylić. Stąd była moja motywacja analizować te przypadki manualnie (czyli kiedy model i stan faktycznie mylił się znacząco). W ten sposób udało się wykryć duplikaty gałęzi, gdzie były dwie kategorie, które logicznie były tym samym, ale miały inną nazwę. Dlaczego tak? Bo jeden dział przypisywał produkty w pierwszej gałęzi, drugi dział w innej. Po kilku iteracjach i wspólnym interpretowaniu wyniku z ekspertem domenowym udało się znacznie uspójnić proces podejmowania decyzji o przypisywaniu produktów w konkretne miejsca.

W praktyce to działało tak:

1. Trenuję model, sprawdzam, gdzie bardzo różni się pomiędzy prognozą modelu i stanem faktycznym.
2. Konsultuję z ekspertem, z czego to może wynikać.
3. Naprawiamy błąd ludzki, czyli np. łączymy kategorie.
4. Trenuję jeszcze raz model na naprawionych danych.
5. Znów sprawdzam miejsca, gdzie najbardziej widać rozbieżności.

I tak w kółko.

Należy zaznaczyć, że ekspert domenowy jest człowiekiem, może więc popełniać błędy (te są innym tematem opisanym w wielu książkach), ale trzeba coś z tym zrobić. Jednym z rozwiązań jest testowanie modelu “po cichu” na produkcji. Oznacza to, że dotyka to małej ilości użytkowników lub ten proces jest mniej neurologiczny dla firmy. W końcu to klienci podpowiedzą (jako zbiorcza opinia), jak to należy zrobić. W szczególności ten punkt dotyczy projektów internetowych.

Pytanie 9: Czy możesz zaakceptować porażkę projektu?

To pytanie może wydawać się dość dziwne na pierwszy rzut oka. Firma chce zainwestować w rozwiązanie i zadając sobie to pytanie, odpowiadamy, czy jesteśmy gotowi na to, że te pieniądze pójdą w błoto. Trochę tak jest, ale warto uświadomić sobie lepiej pewne rzeczy.

Do projektów uczenia maszynowego należy podchodzić jak projektów rozwojowo-badawczych(R&D). Narzędzie, którego używamy, czyli modele uczenia maszynowego operują między innymi na prawdopodobieństwie. Ciężko w sposób jednoznaczny, zadeklarować się, że projekt X na pewno się uda. To zależy od wielu czynników, np.: czystość danych, chaotyczność procesów, czy da się to naprawiać w miarę prostymi zabiegami (np. współpraca z ekspertem domenowym).

Uczenie maszynowe może być przydatne w jednej firmie i zupełnie nie poradzić sobie w innej (np. z powodu danych). Sama teoretyczna rozmowa o tym, co robi firma nie wystarczy, żeby to wyczuć. Dlatego staram się podzielić ten proces na pewne kroki. Pierwszym, najbardziej ryzykownym jest moment, kiedy zbiera się informacje o problemie, procesach (jak to się robi to już osobny wątek, który zasługuje na osobny artykuł) np. wykorzystując event storming i następnie buduje się prototyp. Celem prototypu jest wyczucie, jak duży jest potencjał albo go nie ma. W praktyce to oznacza, że to jest punkt decyzyjny, czy warto iść dalej. Zwykle ta faza trwa dość szybko, około 2 tygodni, w skrajnych przypadkach trochę dłużej, więc nawet jeśli dalszy rozwój tego projektu nie ma sensu, to koszt będzie stosunkowo mały.

Teraz dość modnym jest wszędzie dodawać słowo agile. Można próbować go tutaj również dodać, ale esencją jest to, aby zamiast tego, zamiast teoretycznie oceniać ryzyko czy warto robić, zrobić prosty prototyp na rzeczywistych danych i zobaczyć czy to zapowiada się na sukces. Po prototypie następuje decyzja co dalej, np. zamrażamy projekt (jak to chociażby wydarzyło się w jednym z wyżej opisanych przykładów) albo przechodzimy dalej. Tworzenie już bardziej zaawansowanych iteracji nazywam tworzeniem MVP. Takich iteracji później spokojnie może być 3, 4 lub 5 dopóki pojawia się pierwsza sensowna implementacja, którą faktycznie można wdrożyć na produkcję.

Oczywiście warto też podkreślić, że porażka oraz sukces to nie są w tym przypadku słowa przeciwstawne. Tak naprawdę każda porażka może przybliżać do sukcesu. Uświadomienie sobie tego jest kluczowe przy projektach R&D. Chciałbym też podkreślić, że teraz dość często zdarzają się jakieś anomalie, kiedy ludzie próbują hurtowo popełniać błędy, tylko po to, żeby je popełniać. W tym przypadku chodzi o zdrowy rozsądek, R&D wymaga popełnienie błędów po to, żeby ostatecznie wdrożyć innowacji (niż tylko po to, żeby je popełnić). Mam nadzieje, że czuć istotną różnicę.

Pytanie 10: Czy jest zaplanowany budżet na utrzymanie modelu?

Już ostatni punkt, który wydaje się trochę na wyrost, żeby zadawać go na początku, ale jednak jest ważny. To podobnie jak wtedy, gdy chcesz kupić sobie samochód, bardzo drogi, efektowny. Ktoś Ci pomaga go zdobyć, a potem okazuje się, że masz zasobów, aby go utrzymać. Czy w tym przypadku jest sens go kupować?

Projekty uczenia maszynowego należy pielęgnować co najmniej na podobnym poziomie jak projekty software, a tak naprawdę nawet bardziej. Tutaj wchodzą w grę też kluczowe dane. Ich struktura, ilość i inne wymiary będą zmieniać się w czasie i model musi zaadaptować się do tych zmian. Tak zwany dług techniczny w uczeniu maszynowym jest jeszcze bardziej bolesny niż w zwykłym oprogramowaniu. Więcej o tym można poczytać w publikacji przygotowanej przez Google “Ukryty dług techniczny w uczeniu maszynowym”.

Namacalny przykład z mojego życia. Jak ktoś zajmuje się budżetami w firmie, to wie, jak często to jest dość dziwaczny proces. Na przykład, dla mnie było zaskakującym, dlaczego tworzenie projektu to jest jeden budżet, a utrzymywanie go to drugi. Z jednej strony, to jest niby fajna sprawa, żeby tak było. Tylko jak pomyślisz o tym trochę dłużej, nie ma sensu w rozdzielaniu tego. To jest trochę udawanie, że stworzenie tego projektu kosztuje jedynie X, ale potem co roku jakoś będzie samo utrzymywało się bez kosztów. Widziałem na własne oczy paradoksalną sytuację, kiedy projekt był zrobiony, bo udało się zdobyć budżet na stworzenie go, ale nigdy nie był uruchomiony, bo nie było budżetu na utrzymanie.

Prawdopodobnie takie sytuacje mogą wystąpić tylko w dużych firmach, ale jednak zwracam uwagę na to, że jest to możliwe. Jeszcze jest inny aspekt tego problemu, który może wystąpić w mniejszych firmach. Nawet jeśli jest zaplanowany pewien budżet na utrzymanie projektu, czy są także zabezpieczone do tego zasoby ludzkie? Dość często ten biedny zespół, który zrealizował projekt, dodaje go do swojej długiej listy zadań, które trzeba utrzymywać i oczywiście następnie dostaje nowy projekt. Uwaga tego człowieka lub zespołu będzie zbyt podzielona, żeby móc być pewnym, że model będzie działał poprawnie przez dłuższy czas.

Podsumujmy.

Podzieliłem się z Tobą doświadczeniami i pytanie, które zadaję przed napisaniem pierwszej linijki kodu. Warto powiedzieć, że to i tak bardzo zależy od kontekstu, ale spróbowałem te pytania uogólnić na tyle, żeby pasowały do większości projektów. Zazwyczaj zadaję je sam osobiście, ale w przypadku większych projektów powoływany jest zespół dla efektywniejszej pracy.

Wspomniałem, że między innymi stosuję event storming do lepszego zrozumienia biznesu. Co to jest i jak to działa, zasługuje na osobny artykuł, który przygotuję, jeśli jest taka potrzeba.Daj znać, jeśli ten temat Cię interesuje.

Checklista pytań:

Pytanie 1: Jaki problem chcesz rozwiązać?

Pytanie 2: Dlaczego chcesz rozwiązać ten problem, co więcej przy pomocy uczenia maszynowego?

Pytanie 3: W jaki sposób będziesz mierzyć sukces?

Pytanie 4: Jak dokładnie prognozowanie będzie wpływać na biznes?

Pytanie 5: Komu zależy na tym rozwiązaniu?

Pytanie 6: Jakie dane są zbierane?

Pytanie 7: Jak często i ile czasu jest masz na prognozowanie?

Pytanie 8: Czy jest zaplanowana współpraca z ekspertem domenowym w tym projekcie (w sposób jawny, nie przy okazji)?

Pytanie 9: Czy mogą zaakeptować porażkę projektu?

Pytanie 10: Czy jest zaplanowany budżet na utrzymywanie modelu?