Przez ostatnie około sześć miesięcy tworzyłem system do zwalczania oszustw (oszukańczych działań, oszustw itp.) bez żadnej początkowej infrastruktury do tego. Dzisiejsze pomysły, które znaleźliśmy i wdrożyliśmy w naszym systemie, pomagają nam wykrywać i analizować wiele nieuczciwych działań. W tym artykule chciałbym porozmawiać o zasadach, którymi się kierowaliśmy i co zrobiliśmy, aby osiągnąć obecny stan naszego systemu, bez wchodzenia w część techniczną.
Zasady naszego systemu
Kiedy słyszysz terminy takie jak „automatyczny” i „oszustwo”, najprawdopodobniej zaczynasz myśleć o uczeniu maszynowym, Apache Spark, Hadoop, Python, Airflow i innych technologiach z ekosystemu Apache Foundation i dziedziny Data Science. Myślę, że jest jeden aspekt korzystania z tych narzędzi, o którym zwykle się nie wspomina: wymagają one spełnienia pewnych wymagań wstępnych w systemie korporacyjnym, zanim będzie można zacząć z nich korzystać. Krótko mówiąc, potrzebujesz korporacyjnej platformy danych obejmującej jezioro danych i hurtownię. A co jeśli nie masz takiej platformy i nadal potrzebujesz rozwijać tę praktykę? Poniższe zasady, które przedstawię poniżej, pomogły nam osiągnąć punkt, w którym możemy skupić się na ulepszaniu naszych pomysłów, zamiast znajdować taki, który działa. Nie jest to jednak etap plateau projektu. Jest jeszcze wiele rzeczy w planie z technologicznego i produktowego punktu widzenia.
Zasada 1: Na pierwszym miejscu wartość biznesowa
Na pierwszym miejscu wszystkich naszych wysiłków stawiamy „wartość biznesową”. Ogólnie rzecz biorąc, każdy system automatycznej analizy należy do grupy systemów złożonych o wysokim stopniu automatyzacji i złożoności technicznej. Stworzenie kompletnego rozwiązania zajmie dużo czasu, jeśli tworzysz je od zera. Postanowiliśmy na pierwszym miejscu postawić wartość biznesową, a na drugim kompletność technologiczną. W prawdziwym życiu oznacza to, że nie uznajemy zaawansowanej technologii za dogmat. Wybieramy technologię, która w danym momencie jest dla nas najlepsza. Z biegiem czasu może się wydawać, że będziemy musieli ponownie wdrożyć niektóre moduły. To jest kompromis, który zaakceptowaliśmy.
Zasada 2: Rozszerzona inteligencja
Założę się, że większość osób, które nie są głęboko zaangażowane w tworzenie rozwiązań do uczenia maszynowego, może pomyśleć, że celem jest zastąpienie człowieka. W rzeczywistości rozwiązania uczenia maszynowego są dalekie od doskonałości i tylko w niektórych obszarach możliwa jest ich wymiana. Od początku odrzuciliśmy ten pomysł z kilku powodów: niezrównoważonych danych na temat oszukańczej aktywności oraz braku możliwości zapewnienia kompleksowej listy funkcji modeli uczenia maszynowego. My natomiast wybraliśmy opcję wzmocnionej inteligencji. To alternatywna koncepcja sztucznej inteligencji, która skupia się na wspierającej roli AI, podkreślając fakt, że technologie kognitywne mają na celu wzmocnienie ludzkiej inteligencji, a nie jej zastąpienie. [1]
Biorąc to pod uwagę, opracowanie od początku kompletnego rozwiązania do uczenia maszynowego wymagałoby ogromnego wysiłku, co opóźniłoby tworzenie wartości dla naszego biznesu. Pod okiem naszych ekspertów dziedzinowych postanowiliśmy zbudować system z iteracyjnie rozwijającym się aspektem uczenia maszynowego. Wyzwaniem w opracowaniu takiego systemu jest to, że musi on dostarczać naszym analitykom przypadków nie tylko pod kątem tego, czy jest to oszukańcze działanie, czy nie. Ogólnie rzecz biorąc, każda anomalia w zachowaniu klienta jest podejrzanym przypadkiem, który specjaliści muszą zbadać i jakoś zareagować. Tylko ułamek zgłoszonych przypadków można naprawdę sklasyfikować jako oszustwo.
Zasada 3: Bogata platforma analityczna
Najbardziej wymagającą częścią naszego systemu jest kompleksowa weryfikacja przepływu pracy w systemie. Analitycy i programiści powinni łatwo uzyskać zbiory danych historycznych ze wszystkimi metrykami używanymi do analizy. Ponadto platforma danych powinna zapewniać łatwy sposób uzupełniania istniejącego zestawu wskaźników o nowe. Tworzone przez nas procesy, a nie są to tylko procesy programowe, powinny pozwalać na łatwe przeliczenie poprzednich okresów, dodanie nowych metryk i zmianę prognozy danych. Moglibyśmy to osiągnąć gromadząc wszystkie dane generowane przez nasz system produkcyjny. W takim przypadku dane stopniowo staną się uciążliwe. Musielibyśmy przechowywać coraz większą ilość danych, których nie wykorzystujemy, i chronić je. W takim scenariuszu dane z biegiem czasu będą coraz bardziej nieistotne, ale zarządzanie nimi nadal będzie wymagało naszego wysiłku. Dla nas gromadzenie danych nie miało sensu, więc zdecydowaliśmy się przyjąć inne podejście. Postanowiliśmy zorganizować magazyny danych w czasie rzeczywistym wokół docelowych podmiotów, które chcemy sklasyfikować i przechowywać tylko te dane, które pozwalają sprawdzić najnowsze i istotne okresy. Wyzwaniem dla tego wysiłku jest to, że nasz system jest heterogeniczny i zawiera wiele magazynów danych i modułów oprogramowania, które wymagają starannego planowania, aby działać w spójny sposób.
Koncepcje projektowe naszego systemu
Nasz system składa się z czterech głównych komponentów: systemu pozyskiwania, systemu obliczeniowego, analizy BI i systemu śledzenia. Służą konkretnym, izolowanym celom, a my utrzymujemy je w izolacji, stosując określone podejścia projektowe.
Projektowanie oparte na kontrakcie
Przede wszystkim zgodziliśmy się, że komponenty powinny opierać się wyłącznie na określonych strukturach danych (kontraktach), które są między nimi przekazywane. Dzięki temu łatwo jest je zintegrować i nie narzucać określonego składu (i kolejności) komponentów. Na przykład w niektórych przypadkach pozwala nam to bezpośrednio zintegrować układ dolotowy z systemem śledzenia alertów. W takim przypadku zostanie to wykonane zgodnie z uzgodnioną umową alarmową. Oznacza to, że oba komponenty zostaną zintegrowane przy użyciu kontraktu, z którego będzie mógł skorzystać każdy inny komponent. Nie będziemy dopisywać dodatkowej umowy na dodanie alertów do systemu śledzenia z systemu wejściowego. Takie podejście wymaga stosowania określonej z góry minimalnej liczby umów oraz upraszcza system i komunikację. Zasadniczo stosujemy podejście zwane „pierwszym projektem umowy” i stosujemy je do umów dotyczących przesyłania strumieniowego. [2]
Transmisja strumieniowa wszędzie
Zapisywanie i zarządzanie stanem w systemie nieuchronnie doprowadzi do komplikacji w jego implementacji. Ogólnie rzecz biorąc, stan powinien być dostępny z dowolnego komponentu, powinien być spójny i zapewniać najbardziej aktualne wartości dla wszystkich komponentów oraz powinien być niezawodny w przypadku poprawnych wartości. Ponadto wywoływanie pamięci trwałej w celu pobrania najnowszego stanu zwiększy liczbę operacji we/wy i złożoność algorytmów używanych w naszych potokach czasu rzeczywistego. Z tego powodu zdecydowaliśmy się, jeśli to możliwe, całkowicie usunąć pamięć stanu z naszego systemu. Podejście to wymaga, aby w przesyłanym bloku danych (komunikacie) znalazły się wszystkie niezbędne dane. Przykładowo, jeśli potrzebujemy obliczyć całkowitą liczbę jakichś obserwacji (liczbę operacji lub przypadków o określonej charakterystyce), przeliczamy to w pamięci i generujemy strumień takich wartości. Zależne moduły będą używać partycjonowania i przetwarzania wsadowego w celu podzielenia strumienia na jednostki i działania na najnowszych wartościach. Takie podejście wyeliminowało potrzebę posiadania stałego miejsca na dysku dla takich danych. Nasz system wykorzystuje Kafkę jako brokera komunikatów i może służyć jako baza danych z KSQL. [3] Jednak użycie tego rozwiązania spowodowałoby silne powiązanie naszego rozwiązania z Kafką i zdecydowaliśmy się go nie używać. Wybrane przez nas podejście pozwala zastąpić Kafkę innym brokerem komunikatów bez większych wewnętrznych zmian w systemie.
Koncepcja ta nie oznacza, że nie korzystamy z pamięci dyskowej i baz danych. Aby przetestować i przeanalizować wydajność systemu, musimy przechowywać na dysku znaczną ilość danych reprezentujących różne metryki i stany. Ważne jest tutaj to, że algorytmy czasu rzeczywistego nie zależą od takich danych. W większości przypadków używamy przechowywanych danych do analizy offline, debugowania i śledzenia konkretnych przypadków i wyników generowanych przez system.
Problemy naszego systemu
Istnieją pewne problemy, które rozwiązaliśmy w pewnym stopniu, ale wymagają one bardziej przemyślanych rozwiązań. Teraz chciałbym o nich tutaj wspomnieć, ponieważ każdy punkt jest wart osobnego artykułu.
- Nadal musimy zdefiniować procesy i zasady, które wspierają gromadzenie znaczących i istotnych danych na potrzeby naszej zautomatyzowanej analizy, odkrywania i eksploracji danych.
- Włączenie wyników analiz ludzkich w proces automatycznego konfigurowania systemu w celu jego aktualizacji o najnowsze dane. Oznacza to nie tylko aktualizację naszego modelu, ale także aktualizację naszych procesów i lepsze zrozumienie naszych danych.
- Znalezienie równowagi pomiędzy deterministycznym podejściem IF-ELSE i ML. Ktoś powiedział: „ML to narzędzie dla zdesperowanych”. Oznacza to, że będziesz chciał używać ML, gdy nie będziesz już wiedział, jak optymalizować i ulepszać swoje algorytmy. Z drugiej strony podejście deterministyczne nie pozwala na wykrycie anomalii, których nie przewidywano.
- Potrzebujemy prostego sposobu na przetestowanie naszych hipotez lub korelacji między metrykami w danych.
- System musi mieć kilka poziomów prawdziwie pozytywnych wyników. Przypadki nadużyć to tylko ułamek wszystkich przypadków, które można uznać za pozytywne dla systemu. Na przykład analitycy chcą otrzymywać do weryfikacji wszystkie podejrzane przypadki, a tylko niewielka część z nich to oszustwa. System musi sprawnie prezentować analitykom wszystkie przypadki, niezależnie od tego, czy jest to faktyczne oszustwo, czy po prostu podejrzane zachowanie.
- Platforma danych powinna mieć możliwość pobierania zbiorów danych historycznych wraz z obliczeniami generowanymi i obliczanymi na bieżąco.
- Łatwo i automatycznie wdrażaj dowolne komponenty systemu w co najmniej trzech różnych środowiskach: produkcyjnym, eksperymentalnym (beta) i dla programistów.
- Ostatni ale nie mniej ważny. Musimy zbudować bogatą platformę do testów wydajnościowych, na której będziemy mogli analizować nasze modele. [4]
referencje
Źródło: www.habr.com