Case Study: Automatyzacja klasyfikacji transakcji finansowych poprzez machine learning na chmurze AWS
Projekt jednego z naszych klientów z sektora finansowego obejmował wdrożenie w pełni konfigurowalnego narzędzia do zarządzania procesami sprzedażowymi i oferowania produktów bankowych. Częścią rozbudowanego systemu jest możliwość automatycznego przypisywania kategorii operacjom wpływu na konta bankowe klientów, dzięki wykorzystaniu modelu machine learning umieszczonego w chmurze. W poniższym tekście pokazujemy krok po kroku, jak stworzyliśmy tego typu rozwiązanie i jakie usługi AWS wykorzystaliśmy w tym celu.
Modele machine learning są coraz częściej wykorzystywane do automatycznego przypisywania kategorii operacjom wpływów w sektorze bankowym. Wykorzystują algorytmy klasyfikacji, które są w stanie nauczyć się z dużych zbiorów danych, jakie kategorie przypisane są do różnych rodzajów transakcji. Po odpowiednim wytrenowaniu model może być stosowany do automatycznego przypisywania kategorii do nowych transakcji.
W zależności od dokładności i precyzji klasyfikacji, modele uczenia maszynowego mogą być wykorzystywane do usprawnienia procesu kategoryzacji operacji wpływów w sektorze bankowym, co pozwala na oszczędność czasu i zasobów. Jednakże w przypadku, gdy model jest źle nauczony lub bazuje na niedostatecznie reprezentatywnym zbiorze danych, może prowadzić do błędów w kategoryzacji.
W dalszej części tekstu mówimy w zarysie działające rozwiązanie, które dostarczyliśmy naszemu klientowi z sektora bankowego. Wspomnimy o problemach, z jakimi trzeba się zmierzyć, aby system mógł realizować swoje zadania sprawnie, w możliwie krótkim czasie i bez narażania klienta na dodatkowe koszty związane z wykorzystywanymi usługami AWS.
Jakie były założenia i cel tworzonego rozwiązania?
Głównym celem, jaki został postawiony przed wdrożonym systemem, było w pełni automatyczne przypisywanie kategorii operacjom wpływu na konta bankowe klientów z wykorzystaniem technologii bazującej na uczeniu maszynowym (machine learning).
Kategoria właściwa dla danej operacji miała być „odgadywana” na podstawie pól opisujących indywidualnie każdy z przelewów, takich jak: tytuł, nazwa nadawcy czy kwota. Dopuszczona została również możliwość posiłkowania się danymi z innych transakcji wpływów na to samo konto bankowe. To umożliwiło wykorzystanie podczas kategoryzacji różnorakich wskaźników historycznych, odnoszących się zarówno do przetwarzanej w danym momencie transakcji, jak i całego konta.
Założeniem w pierwszym etapie projektu był podział wpływów na 9 odrębnych kategorii, wśród których znalazły się m.in. wynagrodzenia, premie i różnego rodzaju świadczenia ZUS. Jednocześnie miała zostać zapewniona możliwość łatwego rozszerzenia listy tych kategorii w przyszłości.
Model uczony maszynowo
Przypisywanie kategorii powinno odbywać się w trybie wsadowym: na wejściu dostarczany jest zestaw danych o operacjach na pewnym zbiorze kont bankowych w określonym przedziale czasu, a system ma za zadanie oznakować każdy rekord odpowiednią kategorią, w kolejnym kroku zwracając uzupełniony w ten sposób zbiór danych. Cały ten proces powinien być możliwy do uruchomienia przez obsługę Banku i przebiegać w pełni automatycznie.
Ponieważ – w myśl założeń – rdzeniem decyzyjnym systemu miał być uczony maszynowo model, dodatkowym aspektem projektu było wypracowanie praktycznego procesu trenowania tegoż modelu. Trening miał odbywać się w oparciu o dostarczone przez Bank dane w postaci historii operacji wpływów na konta klientów z już przypisanymi tym operacjom kategoriami. Zależało nam, aby zaoferować klientowi możliwość łatwego trenowania modelu we własnym zakresie.
Dlaczego akurat chmura AWS?
Jednym z założeń projektu było również to, że rozwiązanie będzie działać w środowisku chmurowym. Wybór padł na Amazon Web Services. Za AWS przemawiała m.in. dostępność usługi dedykowanej uczeniu maszynowemu (Amazon SageMaker), jak również obecność narzędzi ETL-owych, użytecznych przy wstępnym przetwarzaniu danych w dużej ilości.
Ze względu na usytuowanie rozwiązania poza infrastrukturą Banku, jedną z kluczowych kwestii stało się bezpieczeństwo przetwarzanych danych. Nie trzeba wyjaśniać, jak bardzo wrażliwe są dane na temat aktywności klientów banku na ich kontach i jak wiele możliwości nadużyć może stworzyć ewentualny wyciek. Dlatego fundamentalną kwestią było właściwe zabezpieczenie danych, przede wszystkim na etapie obustronnego transferu pomiędzy środowiskiem chmurowym a systemami Banku oraz wewnątrz samego AWS-a (in-rest oraz in-transit).
Kolejnymi wymogami, o których warto w tym miejscu wspomnieć były: możliwość łatwego deployowania całości rozwiązania na zadanym koncie AWS-owym, zapewnienie bezpieczeństwa jego obsługi poprzez odpowiedni dobór polityk i uprawnień, a także zadbanie o możliwość audytu systemu.
Zarys architektury rozwiązania
W ujęciu funkcjonalnym system składa się z dwóch komponentów: procesu przypisującego kategorie operacjom bankowym z wykorzystaniem modelu Machine Learning oraz procesu trenującego nowy model w oparciu o wcześniej skategoryzowane dane.
Z logicznego punktu widzenia poszczególne procesy obejmują następujące kroki.
1. Proces kategoryzacji
- Wstępne przefiltrowanie i normalizacja rekordów operacji;
- Przekształcenie danych rekord po rekordzie do postaci liczbowej, oczekiwanej przez model ML (preprocessing);
- Przeprowadzenie inferencji (kategoryzacji) przez model na przetworzonych danych;
- Przetworzenie wyniku pracy modelu;
- Przyłączenie uzyskanych kategorii do oryginalnego zbioru danych, z zachowaniem odfiltrowanych na początku rekordów.
2. Proces treningu modelu
- Wstępne przefiltrowanie i normalizacja rekordów operacji ze zbioru treningowego;
- Zbudowanie słownika na bazie pól tekstowych przy rekordach operacji;
- Przekształcenie danych w taki sam sposób jak w przypadku kategoryzacji, ale z uwzględnieniem już przypisanych kategorii;
- Podział przetworzonych danych na podzbiory: trenujący, walidacyjny oraz testowy;
- Przeprowadzenie treningu modelu z użyciem przetworzonych danych;
- Zarejestrowanie modelu i umożliwienie korzystania z niego w ramach procesu kategoryzacji.
Co ważne, konieczne było takie zaprojektowanie każdego z tych procesów, aby po pierwsze możliwe było w ich obrębie wywoływanie różnych usług AWS, a po drugie, mogły one działać długotrwale, nie generując kosztów związanych z samą orkiestracją.
Wykorzystanie możliwości AWS Step Functions
Odpowiedzią na nasze wymagania okazała się usługa AWS Step Functions. Centralną koncepcją dla tej usługi jest maszyna stanów, którą można rozumieć jako graf. Każdy jej węzeł opisuje jakąś akcję realizowaną przez wywoływaną w tym celu usługę w AWS, a krawędzie definiują następstwo tych akcji. Przy wywoływaniu każda akcja otrzymuje na wejściu niewielki obiekt zwany stanem, a na wyjściu generuje nowy obiekt stanu, który zostaje przekazany do akcji wykonywanej w następnej kolejności. Taka filozofia działania pozwala na realizację długotrwałych procesów przy minimalnym zaangażowaniu zasobów potrzebnych do obsługi samego procesu.
Dodatkową zaletą Step Functions okazała się przyjazność obsługi maszyn stanów z poziomu konsoli AWS. W szczególności chodzi tu o monitoring działającego procesu (bardzo pomocna prezentacja maszyny w formie grafu), ale też o wgląd w historię jego uruchomień.
Opisane czynniki spowodowały, że usługa AWS Step Functions stała się naturalnym wyborem i oba wspomniane procesy – kategoryzacji i treningu – zostały zaimplementowane jako maszyny stanów. Dzięki temu uruchomienie wybranego procesu sprowadza się do odpalenia odpowiedniej maszyny oraz podaniu jej na wejściu zestawu parametrów.
AWS Step Functions a orkiestracja
Minusem jest fakt, że jako narzędzie służące do orkiestracji, Step Functions potrafi dostarczyć jedynie szkielet, w którym osadzane są poszczególne kroki składające się na całość procesu. Wykonanie jakiejkolwiek konkretnej czynności – nawet najprostszej – nie jest możliwe bez odwołania się do dedykowanej usługi AWS. Dlatego usługi wykorzystane w opisywanym rozwiązaniu opisujemy poniżej.
Składowanie danych: Amazon S3
Pierwszym aspektem, o który należało się zatroszczyć, był sposób składowania danych. Ze względu na duży wolumen, format wymiany (CSV) oraz konieczność łatwego dostępu z poziomu różnych usług AWS-owych, wybór padł na Simple Storage Service, czyli S3. Do korzyści płynących z używania S3 – poza prostotą i uniwersalnością – należy doliczyć niskie koszty oraz łatwość zabezpieczenia danych za pomocą kluczy szyfrujących (usługa KMS).
Główny bucket S3 jest miejscem, gdzie trafiają wszystkie dane przechodzące przez system – wejściowe (dostarczane przez klienta), robocze oraz wyjściowe. Położenie tych danych wewnątrz bucketa można określić, podając odpowiednie parametry przy wywoływaniu danego procesu. W S3 zapisywane są również skrypty i inne zasoby konieczne do wykonania poszczególnych procesów.
Przetwarzanie danych: AWS Glue
Jak zostało wcześniej wspomniane, danymi dostarczanymi na wejściu jest historia operacji bankowych w formacie CSV. Każdy wiersz pliku opisuje pojedynczą transakcję wpływu na konto bankowe, zawierając pola takie jak: unikalny identyfikator operacji, dane zleceniodawcy, dane beneficjenta, tytuł przelewu, kwota transakcji itd. Pojedynczy zestaw danych składa się z wielu plików CSV i obejmuje kompletną historię operacji dla określonego zbioru kont bankowych w danym okresie (np. 6 miesięcy). Brak przy tym założeń dotyczących sposobu rozmieszczenia rekordów operacji w poszczególnych plikach CSV czy też ich posortowania.
Ogólnie rzecz biorąc, mamy zatem do czynienia z danym tabelarycznymi o dobrze określonej strukturze i w dużym wolumenie, zawartymi w plikach CSV. Do szybkiego i rozproszonego, a przy tym wygodnego przetwarzania danych tego rodzaju bardzo dobrze nadaje się Apache Spark. Dostępny jest w środowisku AWS m.in. w ramach usługi o nazwie AWS Glue, której zdecydowaliśmy się użyć.
Czym jest AWS Glue?
AWS Glue to dość rozbudowany zbiór narzędzi wspomagających procesy ETL-owe na danych o dużym wolumenie, umożliwiający podpinanie się pod rozmaite źródła danych. Na potrzeby omawianego systemu wybrane zostały jedynie dwie funkcjonalności Glue: zadania przetwarzania danych (Glue jobs) oraz katalog (Glue Data Catalog).
Zadania AWS Glue
Zadania Glue są de facto programami wykonywanymi w środowisku Spark (w naszym przypadku: PySpark), przy czym jest to środowisko automatycznie zarządzane w celu zapewnienia maksymalnej skalowalności. Wbudowane biblioteki dostarczają narzędzia wspomagające ten cel. Dodatkowo Glue umożliwia łatwy, dwukierunkowy dostęp do danych w źródłach specyficznych dla AWS-a, co w omawianym przypadku miało znaczenie ze względu na składowanie wszystkich danych w S3.
W formie zadań Glue zostały zaimplementowane wszystkie kroki związane z przetwarzaniem danych, wchodzące w skład procesów kategoryzacji i treningu:
- Odfiltrowanie danych, ich normalizacja i skatalogowanie;
- Zbudowanie plików słowników;
- Transformacja danych do postaci oczekiwanej przez model;
- Przetworzenie wyniku kategoryzacji;
- Przygotowanie końcowego zbioru danych (z kategoriami);
- Podział danych treningowych na podzbiory.
Każde z tych zadań odczytuje dane wejściowe z S3, dokonuje ich przetworzenia (lub agregacji), by w końcu zapisać uzyskany wynik w odrębnym folderze S3. W przypadku kroku katalogującego, dany wynik trafia do S3 za pośrednictwem Glue Data Catalog.
Pewnym wyzwaniem było przygotowanie zadań w taki sposób, aby można było je łatwo wywoływać lokalnie, wewnątrz deweloperskiego obrazu Glue dostarczanego przez Amazon. Możliwość odpalania zadań lokalnie otworzyła drogę do prostego (i bezkosztowego) testowania ich kodu, a także lokalnego preprocessingu danych podczas prac nad architekturą modelu.
Model ML: Amazon SageMaker
Centralnym elementem rozwiązania jest model machine learning, odpowiedzialny za przypisywanie kategorii operacjom wpływów. Można powiedzieć, że pozostałe części systemu są dla niego jedynie opakowaniem, zapewniającym „komunikację ze światem”. Kroki angażujące model są kluczowe dla obu procesów dostarczanych przez system.
Tworzenie modelu i jego wykorzystanie – a więc to, co składa się na machine learningowy aspekt rozwiązania – zostały zrealizowane przy wsparciu AWS-owej usługi SageMaker.
W naszym rozumieniu model to zarejestrowana w SageMakerze instancja modelu inferencyjnego, na którą składają się przede wszystkim adres obrazu Dockera ze środowiskiem uruchomieniowym (jeden z gotowych obrazów udostępnianych przez AWS) oraz odnośnik do zlokalizowanego w S3 pliku z zapisanym i wytrenowanym modelem. Plik ten zawiera zarówno parametry wyuczone podczas treningu, jak i wykonywalny kod, który SageMaker – na potrzeby inferencji – uruchamia wewnątrz zadanego obrazu dockerowego.
Kategoryzacja modelu
Przeprowadzenie kategoryzacji sprowadza się do uruchomienia w SageMakerze zadania przetwarzania wsadowego (Batch Transform Job) z nazwą modelu jako parametrem. Wśród parametrów znajdują się też ścieżka do katalogu z danymi operacji w S3 oraz ścieżka, pod którą ma być zapisany wynik. Zadanie to jest uruchamiane z poziomu maszyny Step Functions, odpowiedzialnej za przypisywanie kategorii.
Trening modelu
Trening modelu również polega na uruchomieniu w SageMakerze odpowiedniego zadania. Odpowiedzialna jest za to druga z maszyn Step Functions i jest to tym razem zadanie treningowe (Training Job). Lista parametrów jest tutaj nieco dłuższa niż w przypadku inferencji, obejmując m.in. hiperparametry modelu, ścieżki do poszczególnych podzbiorów zbioru danych treningowych (trening, walidacja, test), odnośnik do skryptu trenującego oraz adres obrazu Dockera uruchamiającego skrypt.
Trening kończy się zapisem danych wynikowych w odpowiednim miejscu w S3 i zarejestrowaniem nowej instancji modelu w SageMakerze. Wśród plików zapisywanych w S3 znajdują się nie tylko dane modelu, ale również pliki dające wgląd w przebieg treningu i skuteczność modelu, uzyskaną na poszczególnych podzbiorach.
Skrypt trenujący
„Sercem” zadania treningowego w SageMakerze jest skrypt trenujący. Odpowiada on za zbudowanie modelu, jego iteracyjny trening i zapis wygenerowanego kodu modelu wraz z wyuczonymi parametrami. Opcjonalnie może być również przeprowadzony test modelu na podzbiorze danych wydzielonych ze zbioru treningowego. Wyniki testu są zapisywane i trafiają ostatecznie do S3, aby można się było z nimi zapoznać. Podczas treningu i testowania do logów CloudWatch zapisywane są również metryki, dające wgląd „na żywo” w zmieniającą się skuteczność modelu. Najistotniejsze są tu dwie wielkości: dokładność (accuracy), czyli skuteczność „procentowa”, oraz wartość funkcji straty (loss), czyli uśredniona miara wielkości błędów czynionych przez model (im bliżej 0, tym lepiej). Dla każdego z trzech podzbiorów publikowana jest para takich metryk.
Aby tak wytrenowany model użyty został przy kategoryzowaniu operacji, wystarczy wskazać go za pomocą odpowiedniego parametru podczas wywoływania procesu kategoryzacji.
W projekcie dostarczona została także możliwość dotrenowania istniejącego modelu nową porcją danych. W takim przypadku skrypt trenujący wczytuje uprzednio zapisany model, po czym przeprowadza trening w standardowy sposób. Pliki dotrenowanego modelu zapisywane są oddzielnie w S3, a w SageMakerze rejestrowana jest nowa instancja modelu inferencyjnego.
Wspomaganie procesów: AWS Lambda
Step Functions, jako narzędzie służące jedynie orkiestracji, nie oferuje same z siebie możliwości implementacji rozbudowanej logiki, wychodzącej poza warunkowe wykonywanie wybranych gałęzi grafu i proste transformacje stanu. Nie jest możliwe choćby dodawanie do stanu nowych pól, nie mówiąc już np. o operowaniu na plikach w S3. Realizacja tego rodzaju działań wymaga więc wpięcia w maszynę stanów takiej usługi AWS, która daje możliwość wykonania dowolnego kodu. Dobrze do tego celu nadaje się AWS Lambda, czyli usługa umożliwiająca wykonywanie predefiniowanych, krótko działających funkcji w środowisku bezserwerowym (serverless).
Funkcje Lambda zostały wykorzystane do następujących czynności, realizowanych w nieco różny sposób w obrębie każdego z dwóch procesów:
- Walidacja parametrów wejściowych i przygotowanie początkowego stanu maszyny Step Functions;
- Przygotowanie plików roboczych w S3;
- Czyszczenie danych roboczych – w S3 i Glue Data Catalogu – po udanym zakończeniu procesu.
Dodatkowo, w przypadku procesu treningowego, funkcja Lambda używana jest do zebrania plików powstałych podczas treningu do wspólnego katalogu wynikowego.
Monitoring rozwiązania: AWS Config i AWS CloudTrail
Do kontroli bezpieczeństwa rozwiązania użyto dwóch usług:
1. AWS Config
Usługa pozwalająca na przeskanowanie konfiguracji użytych usług zgodnie z wybranymi regułami bezpieczeństwa w Config. Raport z usługi pozwala na szybką analizę w zakresie tego, czy występują jakieś problemy oraz czy usługi są poprawnie skonfigurowane.
Przykładowo: jedna z reguł AWS Config pozwala na sprawdzenie, czy wszystkie buckety S3 mają włączone domyślne szyfrowanie danych oraz czy wymuszają bezpieczną wymianę danych pomiędzy S3 a innymi usługami. Warto wykonywać okresowe kontrole poprawności konfiguracji usług, gdyż w czasie życia aplikacji konfiguracja usług AWS może się zmieniać (np. podczas deploymentu kolejnych wersji aplikacji).
2. AWS CloudTrail
Jest to druga usługa do kontroli bezpieczeństwa w opisywanym rozwiązaniu. AWS CloudTrail zbiera informacje o wszelkich zmianach w konfiguracji usług, wywoływania API usług oraz udanych i nieudanych prób uwierzytelniania i autoryzacji.
Podczas konfiguracji należy wybrać zestaw zdarzeń, które chcemy monitorować, ponieważ w trakcie działania naszego rozwiązania usługa ta zbiera informacje właśnie o zdarzeniach. Dzięki nim możemy dowiedzieć się, kto zmienił konfiguracje usługi, jeżeli ta przestała działać albo nie działa tak, jak zakładaliśmy. Możemy także dowiedzieć się, kto próbował logować się do naszych usług albo kto pobierał dane z S3.
Powyższe dwie proste usługi zapewniają, że działająca aplikacja jest bezpieczna, a zdarzenia wewnątrz niej są monitorowane.
Preprocessing danych
Co do zasady, modele machine learning potrafią operować jedynie na danych liczbowych. Dlatego, aby przeprowadzenie kategoryzacji było w ogóle możliwe, konieczne jest przetransformowanie każdego rekordu operacji na ciąg liczb (wektor), w którym zakodowane będzie możliwie dużo informacji potencjalnie istotnych dla wyboru właściwej kategorii. O ile w przypadku pól takich jak kwota czy data transakcji zamiana ich wartości na liczby nie jest problemem, to kiedy mamy do czynienia z polami tekstowymi – takimi jak tytuł przelewu czy nazwa jego nadawcy – sprawa staje się bardziej złożona. Jak bowiem zaszyć w wektorze liczbowym informację o wystąpieniu w tekście pewnego słowa o kluczowym znaczeniu, mając na uwadze, że słowo to może pojawiać się w różnych formach fleksyjnych oraz różnym kontekście?
Natural Language Processing w machine learning
Jest to podstawowy problem, z którym trzeba się zmierzyć podczas implementacji rozwiązania machine learning w dziedzinie przetwarzania języka naturalnego (Natural Language Processing, czyli NLP). Z pomocą przychodzą tutaj różne techniki wektoryzacji tekstu. W omawianym przypadku skuteczne okazało się relatywnie proste rozwiązanie, oparte na detekcji najczęściej występujących słów (z uwzględnieniem kategorii) i oznaczaniu faktu ich wystąpienia poprzez wpisanie wartości niezerowej na ustalonych pozycjach w wektorze. Na etapie budowania słowników, napotkane wyrazy są oczywiście przetwarzane, m.in. w celu zneutralizowania różnych form tego samego słowa.
Zwektoryzowane wartości pól tekstowych to najistotniejsza, ale nie jedyna część wektora operacji. Został do niego włączony również szereg dodatkowych pól, charakteryzujących w formie liczbowej zarówno samą transakcję przelewu, jak i konto beneficjenta. W przypadku tego ostatniego wzięto pod uwagę szeroko rozumianą charakterystykę wpływów na dane konto. Na uwagę zasługują odnoszące się do analizowanej operacji wskaźniki historyczne, które potrafią dać informację m.in. o tym, w jakim stopniu przelew jest powtarzalny (np. wynagrodzenie w tej samej kwocie, wpływające co miesiąc).
Przetworzenie danych na potrzeby modelu okazało się najbardziej zasobochłonnym krokiem w obu procesach. Czas potrzebny na jego ukończenie udało się skrócić stosując zrównoleglenie na poziomie zadań Glue. Konieczne były też liczne optymalizacje w kodzie. Niebagatelne znaczenie miała tutaj specyfika generowanych danych: rekordy z bardzo dużą liczbą pól (kilka tysięcy).
Architektura i implementacja modelu
Do implementacji modelu posłużyła nam biblioteka TensorFlow z API Keras. Wybór ten motywowany był zarówno wcześniejszą znajomością tego narzędzia i wygodą jego obsługi, jak i również faktem, że SageMaker oferuje szereg dedykowanych pod uczenie maszynowe gotowych obrazów Dockera, wykorzystujących tę właśnie bibliotekę (w wariantach pod CPU i GPU).
Sam model oparty został o architekturę wielowarstwowej sieci neuronowej typu feed-forward. Na wejście trafiają rekordy operacji przełożone do postaci wektorów liczbowych, na wyjściu model zwraca wektor o rozmiarze odpowiadającym liczbie kategorii, którego poszczególne wartości można rozumieć jako współczynniki przynależności do kolejnych kategorii.
Ponieważ na wejście trafiają wektory tzw. rozrzedzone (ang. sparse), z dużą ilością wartości zerowych, rolą pierwszych warstw modelu jest kompresja wektora wejściowego do akceptowalnego rozmiaru (kilkaset wartości). Układ dalszych warstw został zaprojektowany w ten sposób, aby model był w stanie optymalnie wyłapać zależności mogące przekładać się na przynależność danej operacji do konkretnej kategorii.
Przetestowanych zostało kilkanaście różnych wariantów architektury modelu, co pozwoliło wyłonić architekturę charakteryzującą się wysoką skutecznością, a przy tym względnie prostą (mniejsze ryzyko „przeuczenia” modelu, objawiającego się spadkiem jego skuteczności na realnych zbiorach danych). Model w wybranej architekturze został zaimplementowany wewnątrz opisanego wcześniej skryptu treningowego.
Jakość uzyskanego modelu machine learning
Produkcyjny model – a dokładniej jego pierwsza iteracja – wytrenowany został na zbiorze danych obejmującym operacje na 100 tys. kont bankowych z okresu 15 miesięcy, pomniejszonym o „komisyjnie” wydzielony zbiór testowy stanowiący ok. 10% transakcji z końcowych 12 miesięcy całkowitego okresu. Łączna liczba rekordów użytych do treningu wynosiła w przybliżeniu 6,5 miliona.
Uzyskano skuteczność w granicach od 98.9% do 99.2% na zbiorze testowym, przy czym warto tutaj wspomnieć, że duża część błędów modelu wiązała się z faktem „detekcji” przez ten model nieprawidłowości w kategoriach przypisanych operacjom w zbiorze treningowym dostarczonym przez klienta.
Deployment rozwiązania
Do szybkiego, zautomatyzowanego instalowania i aktualizacji rozwiązania machine learning na kilku różnych kontach AWS posłużyło stworzone przez HashiCorp narzędzie TerraForm, będące alternatywą dla oferowanej przez Amazon usługi CloudFormation. Infrastruktura rozwiązania została rozpisana w postaci plików konfiguracyjnych, zawierających deklaracje wszystkich niezbędnych komponentów AWS w specyficznym dla TerraForma języku. Skonfigurowane zostały również pliki, które powinny znaleźć się w S3, aby rozwiązanie mogło zadziałać (takie jak np. skrypty zadań Glue). Wartości takie jak identyfikator docelowego konta czy region odczytywane są ze zmiennych, co umożliwia łatwy deployment na dowolnym koncie AWS, o ile tylko posiadane uprawnienia na to pozwalają.
Sam deployment sprowadza się do wywołania prostego polecenia, dostarczanego przez TerraForm, które synchronizuje stan zadanego konta AWS z zawartością plików konfiguracyjnych oraz przechowywanych lokalnie zasobów (spakowanych funkcji Lambda, plików wgrywanych do S3 i innych).
Przeczytaj więcej
Przeczytaj więcej na ten temat
