Przez ostatnie około pół roku pracowałem nad stworzeniem systemu do zwalczania oszustw (fraudulent activity, fraud, itp.) bez jakiejkolwiek początkowej infrastruktury do tego. Dzisiejsze pomysły, które znaleźliśmy i wdrożyliśmy w naszym systemie, pomagają nam wykrywać wiele działań oszukańczych i je analizować. W tym artykule chciałbym opowiedzieć o zasadach, którymi się kierowaliśmy, oraz o tym, co zrobiliśmy, aby osiągnąć obecny stan naszego systemu, nie zagłębiając się w część techniczną.
Zasady naszego systemu
Kiedy słyszysz takie terminy, jak „automatic” i „fraud”, prawdopodobnie zaczynasz myśleć o uczeniu maszynowym, Apache Spark, Hadoop, Python, Airflow i innych technologiach z ekosystemu Apache Foundation oraz obszaru Data Science. Sądzę, że istnieje jeden aspekt korzystania z tych narzędzi, który zazwyczaj nie jest wspomniany: wymagają one określonych warunków w twoim systemie korporacyjnym, zanim zaczniesz z nich korzystać. Krótko mówiąc, potrzebujesz korporacyjnej platformy danych, która obejmuje jezioro danych i hurtownię danych. Ale co, jeśli nie masz takiej platformy, a mimo to musisz rozwijać tę praktykę? Następujące zasady, o których mówię poniżej, pomogły nam osiągnąć moment, w którym możemy skupić się na doskonaleniu naszych pomysłów, a nie na poszukiwaniu działających rozwiązań. Niemniej jednak, to nie jest „płaskowyż” projektu. W planie pozostało jeszcze wiele rzeczy z perspektywy technologicznej i produktowej.
Zasada 1: wartość dla biznesu na pierwszym miejscu
Na czoło wszystkich naszych działań postawiliśmy „wartość dla biznesu”. Generalnie każda system automatycznej analizy należy do grupy złożonych systemów o wysokim poziomie automatyzacji i skomplikowaniu technicznym. Stworzenie gotowego rozwiązania zajmie mnóstwo czasu, jeśli zbudujesz je od podstaw. Postanowiliśmy priorytetowo traktować wartość biznesu, a na drugim miejscu – zakończenie technologiczne. W rzeczywistości oznacza to, że nie przyjmujemy zaawansowanych technologii jako dogmatu. Wybieramy technologię, która w danym momencie najlepiej dla nas działa. W miarę upływu czasu może się okazać, że będziemy musieli na nowo wdrożyć niektóre moduły. To kompromis, który przyjęliśmy.
Zasada 2: Wzmocniona inteligencja człowieka (augmented intelligence)
Założę się, że większość ludzi, którzy nie są głęboko zaangażowani w rozwój rozwiązań uczenia maszynowego, może pomyśleć, że celem jest zastąpienie ludzi. W rzeczywistości rozwiązania uczenia maszynowego są dalekie od doskonałości, a zastąpienie ludzi możliwe jest tylko w określonych obszarach. Od samego początku zrezygnowaliśmy z tego pomysłu z kilku powodów: nierównowaga w danych o działalności oszukańczej i niemożność dostarczenia wyczerpującej listy cech dla modeli uczenia maszynowego. W przeciwieństwie do tego, wybraliśmy wariant z rozszerzonymi możliwościami intelektualnymi. To alternatywna koncepcja sztucznej inteligencji, która koncentruje się na wspomagającej roli AI, podkreślając fakt, że technologie kognitywne mają na celu poprawę ludzkiego intelektu, a nie jego zastąpienie. [1]
Biorąc to pod uwagę, stworzenie kompleksowego rozwiązania uczenia maszynowego od podstaw wymagałoby ogromnych wysiłków, które opóźniłyby wytwarzanie wartości dla naszej firmy. Postanowiliśmy zbudować system z iteracyjnym wzrostem aspektu uczenia maszynowego pod kierunkiem naszych ekspertów w dziedzinie. Trudnością w opracowaniu takiego systemu jest to, że musi on dostarczać naszym analitykom przypadki nie tylko z perspektywy, czy jest to działalność oszukańcza, czy nie. Ogólnie rzecz biorąc, każda anomalia w zachowaniu klientów to podejrzany przypadek, który specjaliści muszą zbadać i jakoś zareagować. Tylko niektóre z tych zarejestrowanych przypadków można naprawdę zakwalifikować jako oszustwo.
Zasada 3: platforma analityki rozległych danych
Najtrudniejszą częścią naszego systemu jest kompleksowa kontrola procesu roboczego. Analitycy i programiści muszą mieć łatwy dostęp do zestawów danych z przeszłych okresów ze wszystkimi metrykami, które były używane do analizy. Ponadto platforma danych powinna zapewniać prosty sposób uzupełnienia istniejącego zestawu wskaźników nowymi. Procesy, które tworzymy, a które nie są jedynie procesami programowymi, muszą umożliwiać łatwe przeliczanie wcześniejszych okresów, dodawanie nowych metryk i zmiany prognoz danych. Moglibyśmy to osiągnąć, gromadząc wszystkie dane generowane przez nasz system produkcyjny. W takim przypadku dane stopniowo stałyby się obciążeniem. Musielibyśmy przechowywać rosnącą ilość danych, których nie używamy, i je chronić. W tym scenariuszu z czasem dane stają się coraz mniej istotne, ale wciąż wymagają naszego wysiłku w zarządzaniu nimi. Gromadzenie danych (data hoarding) nie miało dla nas sensu, dlatego zdecydowaliśmy się na inne podejście. Postanowiliśmy zorganizować magazyny danych w czasie rzeczywistym wokół docelowych bytów, które chcemy klasyfikować, i przechowywać tylko te dane, które umożliwiają weryfikację najnowszych i aktualnych okresów. Złożoność tych działań polega na tym, że nasz system jest niejednorodny, z wieloma magazynami danych i modułami programowymi, które wymagają starannego planowania dla spójnej pracy.
Koncepcje konstrukcyjne naszego systemu
Mamy cztery główne komponenty w naszym systemie: system przyjmowania (ingestion system), obliczeniowy (computational), analiza (BI analysis) i system śledzenia (tracking system). Służą one konkretnym, izolowanym celom, a my utrzymujemy je w izolacji, stosując określone podejścia w rozwoju.
Projekt oparty na kontraktach
Przede wszystkim ustaliliśmy, że komponenty powinny polegać wyłącznie na określonych strukturach danych (kontraktach), które są między nimi przekazywane. Umożliwia to łatwą integrację oraz brak narzucania konkretnej struktury (i porządku) komponentów. Na przykład w niektórych przypadkach pozwala to na bezpośrednią integrację systemu przyjmowania z systemem śledzenia powiadomień. W takim przypadku będzie to zrealizowane zgodnie z uzgodnionym kontraktem na powiadomienia. Oznacza to, że oba komponenty będą zintegrowane przy użyciu kontraktu, który może być wykorzystany przez każdy inny komponent. Nie dodamy dodatkowego kontraktu na przekazywanie powiadomień do systemu śledzenia z systemu wejściowego. Takie podejście wymaga zastosowania z góry określonej minimalnej liczby kontraktów i upraszcza system oraz komunikację. W istocie stosujemy podejście nazywane „Projektowaniem z Kontraktem jako Pierwszym” i stosujemy je do kontraktów przesyłania danych. [2]
Streaming wszędzie
Zarządzanie stanem w systemie nieuchronnie prowadzi do złożoności jego realizacji. W ogólnym przypadku stan powinien być dostępny z dowolnego komponentu, być spójny i dostarczać najbardziej aktualną wartość dla wszystkich komponentów, a także powinien być wiarygodny z poprawnymi wartościami. Ponadto, wywołania do trwałego magazynu w celu uzyskania ostatniego stanu zwiększą liczbę operacji wejścia-wyjścia i złożoność algorytmów stosowanych w naszych rzeczywistych potokach. Z tego powodu postanowiliśmy w miarę możliwości całkowicie wyeliminować przechowywanie stanu z naszego systemu. Podejście to wymaga dołączenia wszystkich niezbędnych danych do przesyłanej paczki danych (wiadomości). Na przykład, jeśli musimy obliczyć całkowitą liczbę pewnych obserwacji (liczbę operacji lub przypadków o określonych cechach), obliczamy ją w pamięci i generujemy strumień takich wartości. Zależne moduły będą korzystać z partycjonowania (partition) i pakowania (batch) w celu podziału strumienia na jednostki i operowania najnowszymi wartościami. To podejście wyeliminowało potrzebę posiadania trwałego storage’a dla takich danych. Nasz system wykorzystuje Kafkę jako brokera wiadomości, i można ją używać jako bazy danych z KSQL. [3] Jednak jej użycie silnie związałoby nasze rozwiązanie z Kafką, i postanowiliśmy jej nie używać. Nasze wybrane podejście pozwala na zastąpienie Kafki innym brokerem wiadomości bez poważnych wewnętrznych zmian w systemie.
Koncept ten nie oznacza, że nie korzystamy z magazynów dyskowych i baz danych. Aby sprawdzić i przeanalizować wydajność systemu, musimy przechowywać na dysku znaczną część danych, które reprezentują różne wskaźniki i stany. Ważnym punktem tutaj jest to, że algorytmy czasu rzeczywistego nie zależą od takich danych. W większości przypadków wykorzystujemy zapisane dane do analizy offline, debugowania i śledzenia konkretnych przypadków oraz wyników, które generuje system.
Problemy naszego systemu
Są pewne problemy, które rozwiązaliśmy do pewnego stopnia, ale wymagają one bardziej przemyślanych rozwiązań. Chciałem je teraz tylko wspomnieć, ponieważ każdy punkt zasługuje na osobny artykuł.
- Wciąż musimy określić procesy i polityki, które przyczyniają się do gromadzenia znaczących i aktualnych danych do naszej automatycznej analizy, wykrywania i badania danych.
- Wdrożenie wyników analizy przez ludzi w proces automatycznego dostosowania systemu do jego aktualizacji na podstawie najnowszych danych. To nie tylko aktualizacja naszego modelu, ale także aktualizacja procesów i poprawa zrozumienia naszych danych.
- Znalezienie równowagi między deterministycznym podejściem IF-ELSE a ML. Ktoś powiedział: „ML to narzędzie dla zdesperowanych”. Oznacza to, że będziesz chciał używać ML, gdy już nie wiesz, jak zoptymalizować i poprawić swoje algorytmy. Z drugiej strony, podejście deterministyczne nie pozwala na wykrywanie anomalii, które nie były przewidziane.
- Potrzebujemy prostego sposobu na weryfikację naszych hipotez lub korelacji między metrykami w danych.
- System powinien mieć kilka poziomów prawdziwie pozytywnych wyników. Przypadki oszustw to tylko część wszystkich przypadków, które można uznać za pozytywne dla systemu. Na przykład analitycy chcą otrzymywać wszystkie podejrzane przypadki do weryfikacji, a tylko niewielka część z nich to oszustwa. System powinien skutecznie dostarczać analitykom wszystkie przypadki, niezależnie od tego, czy są to prawdziwe oszustwa, czy tylko podejrzane zachowanie.
- Platforma danych powinna pozwalać na uzyskiwanie zbiorów danych za przeszłe okresy z obliczeniami, tworzonymi i obliczanymi na bieżąco.
- Proste i automatyczne wdrożenie dowolnego z komponentów systemu w co najmniej trzech różnych środowiskach: produkcyjnym, eksperymentalnym (beta) oraz dla deweloperów.
- I na koniec, ale nie mniej ważne. Musimy stworzyć rozbudowaną platformę do testowania wydajności, na której będziemy mogli analizować nasze modele. [4]
Linki
Źródło: habr.com
