W 28 lutego miałem okazję uczestniczyć w 23-cim spotkaniu grupy Warsaw Data Science. Meetup był podzielony na dwie prezentacje, które miały wspólny motyw przewodni: wykrywanie anomalii. Co ciekawe prezentowały one inne podejścia do podobnego problemu, w zupełnie różnych branżach (bankowość i sprzedaż online), z użyciem różnych technologii.
Po spotkaniu byłem mocno zaskoczony i miałem dwa wnioski płynące z prezentacji:
#1. Często najprostsze rozwiązania działają najlepiej.
#2. Rozwiązania „szyte na miarę” dają świetne wyniki, ale mają kilka dużych minusów.
Jeśli chcesz znać szczegóły, to zapraszam do zapoznania się z moją relacją.
Prezentacja numer 1 – Detekcja Anomalii w real-time czyli prostota najwyższa forma wyrafinowania
Pierwszym prelegentem był Piotr Guzik z Allegro. Tematem prezentacji była walka z anomaliami w największym polskim serwisie aukcyjnym. Jako że w Allegro dane to „obywatel pierwszej kategorii”, to głównym celem zespołu analityków danych było zapobieganie ich utracie.
Przyjęto założenie, że anomalią są wszystkie spadki ruchu (poniżej pewnego poziomu, ale o tym później) na witrynie Allegro. Ruch w danym interwale czasu był zliczany i analizowany z 10 minutowym opóźnieniem. Tak więc real-time to w tym przypadku wynosił 10 min. Czemu akurat tyle i czemu mniej wcale nie oznacza lepiej? Mniejszy interwał nie byłby wystarczająco „wygładzony” i uwzględniałby mniejsze i większe wahania aktywności użytkowników. Skutkiem byłby alarm dzwoniący kilkanaście (ew. kilkaset) razy na dobę. Większy interwał natomiast opóźniłby reakcję pracowników na prawdziwą usterkę, no i przede wszystkim nie moglibyśmy wtedy mówić o systemie „real-time”.
Przed rozpoczęciem projektu Allegro nie posiadało podobnego rozwiązania, dlatego zespół miał dwa wyjścia: zbudować coś od zera lub skorzystać z gotowego rozwiązania. Gotowymi rozwiązaniami były m.in. Twitter Library oraz HTM. Pierwsze z nich było napisane w R (w którym to zespół projektujący nie miał zbyt dużego doświadczenia) i okazało się trudne w implementacji. Drugie wykorzystywało sieci neuronowe i okazało się jeszcze trudniejsze. Zdecydowano się zatem na zbudowanie własnego rozwiązania.
Pierwsza wersja systemu została napisana w R. Po drodze popełniono jednak kilka podstawowych błędów (m.in. przeuczono model, który nie był czyszczony z odstających danych) i w rezultacie mechanizm uznawał wszystko za anomalię. W międzyczasie z zespołu odszedł jedyny Data Scientist znający R, więc nie było nikogo kto mógłby poprawić model.
Druga wersja systemu napisana była od zera w Scali, z użyciem MA (ang. moving average). Jej działanie było relatywnie proste. W oparciu o dane historyczne wyznaczała przedziały ufności. Jeśli ruch w danym interwale czasu wychodził poza przedział, to system informował o wykryciu anomalii. Oczywiście brane były pod uwagę trendy i zdarzenia sezonowe, jak np. święta, dzień dziecka, etc., gdy ruch był wzmożony.
Rozwiązanie zostało ciepło przyjęte i jest implementowane w modelu SAAS w kilku miejscach w Allegro. Tam, gdzie R i inne gotowce okazały się zbyt skomplikowane, sprawdziło się rozwiązanie do bólu proste, które spełnia wymagania użytkowników.
Prezentacja numer 2 – Big data w bankowości: analiza nadużyć w czasie rzeczywistym
Drugim prelegentem był Mariusz Rafało – współzałożyciel firmy Sorgio i wykładowca uczelni wyższych: SGH i Politechniki Warszawskiej. Opowiadał o zastosowaniu architektury Big Data do wykrywania anomalii w bankowości.
Prezentacja rozpoczęła się od porównania dwóch podejść do analizy danych: Batch (składowane) vs Stream (real-time). Pierwsze z nich, to ciągle istniejące w dużych polskich bankach podejście zakładające uprzednie gromadzenie danych w hurtowniach przed ich analizowaniem. Drugie to nieco bardziej nowoczesne analizowanie danych w czasie rzeczywistym i dostarczanie odpowiedzi ad-hoc. Opisywany w prezentacji przypadek oczywiście bazował na drugim podejściu 😊
System był projektowany dla jednego z polskich banków. Jego budowa i optymalizacja bazowała na otrzymanej od banku paczce zanonimizowanych danych. Zawarte w niej były dane klientów banku i ich transakcji: 30 zanonimizowanych zmiennych, 284 tysiące obserwacji. Już na samym początku pojawiła się pierwsza trudność: jedynie 0.17% obserwacji stanowiły fraudy.
By poradzić sobie z nieproporcjonalnym zbiorem użyto metody SMOTE. Jest ona używana przy niezbalansowanych zbiorach. W tym przypadku posłużyła do wytworzenia dodatkowych obserwacji będących fraudami. Dzięki temu utworzony zbiór testowy zawierał ok. 2000 obserwacji (operacje prawidło i fraudy w proporcji 50/50).
Na etapie uczenia i testowania porównywano dwa algorytmy: K-means i drzewo decyzyjne. Ten ostatnio osiągał nieco lepsze wyniki (accuracy: 0.92 vs 0.89) i został zaimplementowany w finalnej wersji modelu. Tutaj może Ci się nasunąć do głowy pytanie: czemu zadowolił ich wynik 0.92, podczas gdy bez problemów można osiągnąć dokładność na poziomie 0.98? Biorąc pod uwagę proporcje obserwacji pozytywnych do negatywnych, wystarczy oznaczyć wszystkie obserwacje jako false/0. Odpowiedź jest prosta: dla banku dużo korzystniejsze są błędy typu pierwszego (false positive) niż drugiego (false negative). Lepszą praktyką jest działalność prewencyjna i blokowanie kilku podejrzanie wyglądających transakcji, które w rzeczywistości są prawidłowe, niż przepuszczanie całego ruchu z fraudami.
W projekcie zastosowano następujące technologie:
- Kafka (do symulacji transakcji bankowych – strumieniowanie danych z pliku tekstowego zawierającego transakcje – 20 transakcji/s).
- Spark.
- Python (logika aplikacji).
- R (implementacji modelu ML).
- Cassandra.
- Kafka (strumień wyjściowy).
- Elastic.
Na koniec autor podzielił się kilkoma przemyśleniami na temat systemu. Do pozytywów bez wątpienia można było zaliczyć szybkość działania i dokładność. Opóźnienia były liczone w milisekundach, a dokładność wyniosła ok. 0.9 na finalnym zbiorze testowym. Minusem natomiast było skomplikowanie systemu, wpływające negatywnie na jego utrzymanie. Nawet najmniejsza zmiana wymagała zmian w kodzie i ponownego uczenia modelu.
Podsumowanie
Dwie prezentacje, wspólny cel i zupełnie różne podejścia, zarówno jeśli chodzi o technologie jak i samo „ugryzienie” problemu. Oby więcej prezentacji pokazujących tak ciekawe podejście i trzymających tak wysoki poziom. Jeśli chciałbyś się zapisać na kolejny meetup (do czego gorąco zachęcam 😊), to możesz to zrobić na stronie: klik.
Dodaj komentarz