Uczenie maszynowe, czyli machine learning jest nieodłącznym, krytycznym elementem każdego przedsiębiorstwa w branży finansowej. Niestety jest często realizowane w sposób daleki od optymalnego, ale dzięki temu jest to miejsce, w którym możemy coś poprawić!
Data scientist, czyli analityk, który przygotowuje materiał do podejmowania decyzji, najczęściej w swojej trudnej pracy nie tylko musi rozwiązać problemy biznesowe, ale co chwilę napotyka na przeszkody technologiczne. Wynika to z długu technologicznego w zakresie architektur IT niedostosowanych do pracy w standardach MLOps. Termin ten zawiera zarówno Continuous Integration, Continuous Delivery, jak i Continuous Training systemów uczenia maszynowego (z dużą analogią do powszechnego już podejścia DevOps stosowanego do procesów wytwarzania oprogramowania).
Systemy nazywane machine learning są wykorzystywane do rozwiązywania trudnych i złożonych rzeczywistych problemów, np. szacowania ryzyka czy analiz sprzedaży. W wielu organizacjach praca analityka odbywa się na osobistym laptopie, a analityk z konieczności jest jednocześnie programistą, integratorem i w ogóle informatyczną złotą rączką od sklejania danych z różnych źródeł. Musi to robić sam, aby jego eksperymentalne modele liczące miały zasilanie danymi na tyle dobrymi, żeby można było ocenić przydatność opracowywanych formuł statystycznych. Na lokalnym sprzęcie powstają więc małe data marty, zaczynają działać procesy ETL pomiędzy licznymi plikami CSV czy xls, pojawiają się kolejne linie kodu w Pythonie.
Są to działania niezbędne i mozolne, ale niedające same w sobie żadnej wartości. To tylko zapewnienie strumienia danych, na których możemy rozpocząć symulacje biznesowe. Kiedy (po kolejnych tygodniach) nasz model osiągnie zadowalającą dojrzałość w zakresie otrzymywanych wyników, musimy to wszystko przenieść z mikroświata na laptopie na rzeczywiste środowisko produkcyjne firmy.
Kolejny duży projekt IT
Migracja zaawansowanego modelu statystycznego na produkcję i zasilenie bieżącymi danymi całej firmy, tak aby wszystko zadziałało zgodnie z założeniami, okazuje się dużym projektem. Niestety modele matematyczne na nowych zbiorach nie zawsze zachowują się tak, jak było na symulacjach, i trzeba je dalej poprawiać.
Jeżeli powiemy, że opracowywanie nowego modelu trwa inicjalnie ok. dwóch–trzech miesięcy, a potem wdrożenie go również zajmuje podobny czas, to prawdopodobnie dobrze opiszemy rzeczywistość wielu sprawnie zinformatyzowanych przedsiębiorstw. Dodajmy do tego kolejne trzy miesiące dalszego tzw. wygrzewania i upewniania się, że model liczy wciąż poprawnie, zanim potwierdzimy, że jesteśmy spokojni, pewni i mamy założony efekt biznesowy!
Co można usprawnić?
MLOps to proces tworzenia, wdrażania i utrzymania nowego matematycznego modelu prognostycznego w taki sposób, aby było jak najbardziej automatycznie, czyli szybko i tanio. Skracamy cykl od pojawienia się potrzeby biznesowej do wdrożenia produkcyjnego z kilku miesięcy do pojedynczych dni lub docelowo nawet krócej.
Data scientist, który z natury swojej roli jest stale poszukującym eksperymentatorem, zmieniającym parametry i formuły, nie może sam pisać zasilań ani potem uruchamiać produkcyjnie wypracowanego modelu. Zalecana jest separacja tych etapów. W momencie, gdy etap eksperymentowania z modelem jest zakończony i otrzymywane wyniki są zadowalające, proces wdrożenia i uruchomienia produkcyjnego powinien być już w pełni automatyczny.
Gdy projekt wdrożenia produkcyjnego modelu jest krótki, oznacza to, że mocno spada koszt od strony IT. Równocześnie otrzymujemy szybszy efekt biznesowy dla klientów i organizacji oraz umożliwiamy analitykowi rozpoczęcie albo nowego projektu biznesowego z nowym produktem, albo prace koncepcyjne nad dalszą rozbudową modelu (np. dołożeniem kolejnego źródła danych i zależności – co się stanie, gdy powiążemy to wszystko dodatkowo z pogodą czy wskaźnikiem miesięcznej inflacji).
Warto osobiście znać królową
Data scientist, jako bardzo cenna rola w organizacji, nie powinien wręcz tracić czasu na prace związane z instalacją, kodowaniem powiązań, przekształcanie i przepisywanie źródeł danych do pasującego formatu itd. Powinien móc pracować na modelach i pojęciach logicznych, najlepiej w środowisku wirtualnym, przez przeglądarkę, nie wnikając, skąd pod spodem zostaną fizycznie pobrane dane, które wskazał, że są jego zdaniem akurat potrzebne do wyliczeń, jakie chciałby zasymulować i przetestować. Dane do symulacji powinny być od razu rzeczywistymi, pełnymi danymi produkcyjnymi!
Gdy środowisko pracy jest w pełni dojrzałe (co jest możliwe i do czego dążymy), do bycia dobrym analitykiem powinny wystarczyć dwie kluczowe umiejętności: zrozumienie problemów i celów biznesowych oraz znajomość królowej nauk – matematyki.
Architektura i procesy składające się na wdrożenie MLOps umożliwiają docelowo pełne odseparowanie wiedzy i problemów technologicznych i skoncentrowanie się na umiejętnościach analitycznych. Nasuwa się analogia do jazdy samochodem. Nie muszę wiedzieć, jak działa to, co jest pod maską, żeby dojechać tam, gdzie potrzebuję.
Praktyczny skład i katalog
W dużych organizacjach analityków pracujących nad symulacjami jest zwykle kilku. Czasami są oni w różnych działach i zajmują się różnymi produktami. Ponieważ każdy lubi pracować na swoim laptopie i na zbiorach danych, które jemu wydają się najwłaściwsze, wymiana doświadczeń i konkretnych powiązań czy zmiennych nie jest powszechną praktyką.
Od strony upraszczania pracy i współdzielenia się reużywalnymi komponentami zaleca się zorganizowanie tzw. Feature Store – tam będą odkładane i katalogowane opracowane w kolejnych latach przez wszystkich analityków poszczególne działające zmienne. Biblioteka pojedynczych zmiennych lub bardziej zaawansowanych modeli stanowi duży krok w przyspieszeniu procesów analitycznych.
Wisienką na tym torcie jest AutoML
Model matematyczny to zaawansowane formuły matematyczne, które przeliczają otrzymywane dane. Obrazowo możemy przyjąć, że nasza „maszynka do liczenia” ma z boku pokrętła sterujące (np. który strumień danych zdławić, a który trochę podkręcić i zobaczmy, jakie zależności otrzymamy). Zmieńmy pokrętło nr 14 o wartość 1/10 i co otrzymujemy? Takich pokręteł jest i może być bardzo dużo. Każde ma wiele położeń, a kombinacje i zależności pomiędzy nimi są aż piękne w swojej różnorodności. Ten etap eksperymentowania pochłania duży czas pracy analityka.
Potrafimy już jednak postawić cyfrowego robota, który tymi pokrętłami kręci, testuje je i tylko powiadamia człowieka o znalezieniu ciekawych, trafnych kombinacji ustawień. Taka automatyzacja mozolnego testowania modeli bardzo przyspiesza ten proces i od razu odciąża analityka z monotonnej, powtarzalnej pracy. Może on np. zająć się w tym czasie dodawaniem kolejnych pokręteł i zależności.
Przyszłość jest teraz
Nie każdy problem da się oprogramować i matematycznie rozwiązać. Jednym ze skutecznych podejść jest szybkie zbudowanie dużej ilości teoretycznych założeń, a następnie jak najszybsze odrzucenie wszystkich, które nigdy nie będą do wyliczenia lub bardzo trudno będzie to poprawnie zrobić. Im szybciej wychwycimy te modele, które rzeczywiście pokażą zależności, tym szybciej zadowolimy klientów i przyniesiemy profit naszej organizacji.
Koncepcja MLOps jest dla firm, które mają wiele modeli o dużej zmienności w czasie. Jest największą korzyścią tam, gdzie powstają kilka razy w roku nowe usługi, nowe produkty, gdzie w trybie tygodniowym, dziennym czy godzinowym musimy znać odpowiedzi na pytania, co się opłaca, do kogo i za ile? Jak najlepiej zrobić upsell? Jak wykorzystać aktywność klientów w sieci i zmniejszyć churn? Czy analizując, jakie kwoty klient ustawiał na naszym portalu, zanim poprosił o kontakt lub ofertę na polisę, możemy lepiej wnioskować o jego sytuacji i pewności swoich finansów?
To analityk stawia takie pytania, nazywa problemy i udziela na nie odpowiedzi odpowiednio dobranymi modelami. Powinien robić tylko dwie rzeczy. Musi zrozumieć i opisać matematycznie zagadnienie biznesowe oraz wybrać i przygotować zmienne, które na nie wpływają. Pozostałe etapy po prostu mają być w pełni zautomatyzowane.
Zautomatyzowany proces pozwala osiągnąć korzyści na trzech płaszczyznach: istotnie zmniejsza koszty, pozwala na pozbycie się długu technologicznego infrastruktury IT, który obchodzimy pracami projektowymi i dewelopersko-administracyjnymi, oraz umożliwia obsługę nagłych, krótkotrwałych i wysoce zmiennych okazji biznesowych.
Tomasz Jakuczun
dyrektor rozwoju w Primaris
Od ponad 20 lat realizuje projekty IT w największych instytucjach finansowych.
