Lejce dla sztucznej inteligencji, czyli uczenie maszynowe w praktyce

Nauka, dane i biznes

Nauka o danych (ang. data science), jako coś więcej niż „zwykła” statystyczna analiza danych, to wbrew pozorom wcale nie nowa gałąź informatyki. Pierwsze rozwiązania, zwłaszcza algorytmy oraz metody zostały opracowane w latach 50. i 60. ubiegłego wieku (https://en.wikipedia.org/wiki/Timeline_of_machine_learning). Niemniej, z powodu względnie małego poziomu informatyzacji procesów produkcyjnych (również tzw. biznesowych), powodującego małą dostępność danych w formie cyfrowej oraz względnie małą moc obliczeniową stosowanych maszyn liczących nie zdobyły one szczególniej uwagi oraz nie znalazły zastosowań praktycznych. W wyniku takiego stanu rzeczy nastąpił długi (jak na informatykę), bo trwający ponad dekadę, okres uśpienia tej tematyki w kontekście komercyjnych rozwiązań informatycznych.

Wielki powrót tego zjawiska rozpoczął się w latach 80. i 90. ubiegłego wieku, razem z pierwszymi próbami tworzenia oprogramowania wspierającego tzw. uczenie maszynowe (ang. machine learning) w zastosowaniach komercyjnych, na przykład predykcje wskaźników ekonomicznych oparte o dane historyczne itp. Należy też zwrócić uwagę, że w latach 70. nastąpił konieczny do popularyzacji tych rozwiązań istotny wzrost poziomu komputeryzacji, w szczególności biznesu.

Analyticum sapiens

„Data Science” to, jak powiedzieliby rzymianie, „Nihil novi sub sole.” Oprócz tego, że jest to bardzo modny w tym sezonie „brzęczyk” (ang. buzzword) wywołujący dreszcz podniecenia u pracowników działów analitycznych, na przykład na wieść, że w firmie pojawił się „Janek Kowalski — nowy Data Scientist”.

Co do samej wyróżniającej tę dziedzinę terminologii byłbym ostrożny, bo tak naprawdę rzeczony „Data Scientist” to tylko odrobinę mądrzejszy stary dobry analityk danych, który stale uaktualnia swoją wiedzę i zestaw narzędzi, którymi się posługuje. Od teraz więc, w miejsce „naukowca od danych” będę stosował określenie: „mądry analityk danych”.

Owszem, żeby rozwinąć zawodowe skrzydła i awansować na „mądrego analityka danych”, zwykły analityk danych powinien powiększyć repertuar stosowanych narzędzi analitycznych (mowa o technikach „liczenia”). Są do tego wspaniałe, przystępnie napisane materiały dostępne w Internecie — płatne (z gwarancją) i bezpłatne, jak również kursy „on-line”. Tak naprawdę wystarczy zacząć od różnych „bryków”, które pomogą zweryfikować nasze możliwości w zakresie „poszerzonej” analityki i podjąć decyzję, co dalej.

Częstą praktyką jest zatrudnianie „naukowców od danych” z zewnątrz organizacji, zamiast ustawicznego kształcenia zaufanej i doświadczonej w danej dziedzinie biznesu kadry analitycznej.

Ludzie ci dysponują co prawda dużą wiedzą merytoryczną z zakresu teorii nowoczesnych metod analitycznych i technologii, ale często nie posiadają odpowiedniej wiedzy dotyczącej kontekstu analizy. Moim zdaniem to błąd. W miarę możliwości lepiej dokształcać sprawdzoną kadrę analityczną (no chyba, że Ona — ta kadra — tego nie chce), a sprawy technologii zostawić specjalistom od inżynierii — tzw. „integratorom” lub działom architektury korporacyjnej.

Różne potrzeby, różne narzędzia, różne ograniczenia

W zależności od sposobu stosowania technik uczenia maszynowego można wyróżnić trzy podstawowe rodzaje stosowanych narzędzi, które pokrótce opisałem w poniższych akapitach.

Po pierwsze, można by rzec model „pierwotny”, analiza w trybie „off-line”, stosowana głównie w celu wypracowania jakiegoś złożonego modelu analitycznego rozwiązującego dziedzinowy problem. W tym przypadku, najczęściej stosowane są zintegrowane środowiska analityczne takie jak RapidMiner, KNIME, IBM SPSS itp., które w chwili obecnej „wyposażone” są w przeróżne dodatki udostępniające metody uczenia maszynowego. Narzędzia są najczęściej stosowane w środowisku komputera „osobistego” analityka, znacznie rzadziej jako zintegrowane środowisko analityczne do pracy grupowej (chociaż większość tego typu rozwiązań daje możliwość pracy „na serwerze”). Ten model pracy najczęściej oznacza korzystanie z danych półprzetworzonych, z hurtowni danych, baz statystycznych itp. i nadaje się głównie do wyznaczania pewnych strategii analitycznych, rzadko kiedy wyniki takiej pracy są integrowane jako gotowe rozwiązania w kolejnym opisanym przypadku użycia uczenia maszynowego.

Bardziej wysublimowanym sposobem zastosowania technik uczenia maszynowego jest ich wykorzystanie operacyjne. Mianowicie użycie różnych mniej lub bardziej zaawansowanych algorytmów uczenia nadzorowanego (a czasami i nienadzorowanego) do realizacji pewnych szczególnych, mocno zinformatyzowanych fragmentów procesów biznesowych, szczególnie związanych z podejmowaniem decyzji w zakresie redukcji ryzyka. Za przykład może posłużyć system wydawania decyzji kredytowych, w którym tzw. „ocena” (ang. scoring) wiarygodności klienta jest realizowana m.in. na podstawie automatycznego przyporządkowania go do pewnych grup na podstawie zestawu jego inherentnych cech, a może ich być nawet dobrze ponad 1000 (wliczając cechy opisujące np. dotychczasową historię kredytową itp.). Tego typu modele najczęściej są dostarczane w postaci gotowych systemów realizujących to zadanie, np. Experian Scorex. Ale są także budowane wewnętrznie przez organizację — wszystko zależy w tym przypadku od specyfiki „łańcucha wartości” i realizujących go procesów.

Powyższe metody mają szereg ograniczeń związanych (w pierwszym przypadku) z dostępnością, powtarzalnością i ponownym użyciem wypracowanych modeli lub (w drugim przypadku) z ich wszechstronnością (rozwiązania dziedzinowe). Jednocześnie, jak już wspomniałem, oba przypadki zastosowania uczenia maszynowego, czy w ogólności modelowania analitycznego, są od siebie mocno zależne.

Z pomocą może przyjść rozwiązanie, które łączy łatwość implementacji analiz oraz zdolność do integracji z innymi rozwiązaniami informatycznymi. Powstaje pytanie, czy w ogólne istnieje coś takiego, czy ktoś, w jednym rozwiązaniu, jest w stanie zapewnić szybkość działania i zdolność integracji systemowej złożonych produktów baz danych oraz lekkiego środowiska analitycznego, w którym możemy swobodnie eksperymentować z danymi i metodami. Odpowiedź brzmi: „tak, ale…” A teraz na poważnie … takim rozwiązaniem może z powodzeniem być Splunk Enterprise stosowany razem z rozszerzeniem (również marki Splunk) Machine Learning Toolkit (MLT).

Cóż to takiego ten Splunk MLT

W oryginale opis brzmi tak:

„The Splunk Machine Learning Toolkit helps you apply a variety of machine-learning techniques and methods, such as classification (predicting a yay or nay), regression, anomaly detection, and outlier detection against your data.”

W wolnym, uproszczonym tłumaczeniu:

„MLT pomoże ci zastosować różne techniki i metody uczenia maszynowego, takie jak klasyfikacja, regresja, wykrywanie anomalii i odchyleń względem twoich danych.”

A ja, jako tzw. „splunkowiec”, mogę tylko dodać, że Splunk w tym opisie jest wyjątkowo skromny. Tak naprawdę wykorzystanie pewnych cech tego rozwiązania (Splunk + MLT), notabene opartego na bibliotekach wspierających programowanie uczenia maszynowego języka Python, pozwala na tworzenie zaawansowanych analiz wszelkiego rodzaju danych. Splunk zwyczajowo kojarzony jest z analizą danych technicznych, tj. dzienników systemowych, metryk itp., może jednak z powodzeniem być stosowany jako zaawansowana baza danych o wszelkiego rodzaju zdarzeniach biznesowych, ze szczególnym uwzględnieniem ich następstwa czasowego (Splunk jest przecież zaawansowaną implementacją tzw. bazy danych szeregów czasowych, ang. time-series database). Co daje mu nawet pewną przewagę nad systemami analitycznymi opartymi na wszechstronnym, ale statycznym z natury modelu relacyjnym (kto tworzy hurtownie danych z wymiarami czasu, ten wie, o czym mowa).

Splunk MLT jest wygodnym narzędziem modelowania analitycznego, wplecionym w język zapytań systemu Splunk — Search Processing Language (SPL). Język SPL został stworzony specjalnie do realizowania często niezwykle złożonych analiz danych, w modelu „potoku”, w sposób podobny to tego, który większość zna z procesów ETL stosowanych w systemach hurtowni. Zasadniczą różnicą jest jednak to, że pozwala on zadawać pytania i przetwarzać dane w sposób interaktywny (konwersacyjny wręcz), taki jaki znamy ze środowisk SQL. I prawdopodobnie tutaj jest największa korzyść z korzystania z systemu Splunk, środowisko daje niespotykane połączenie uniwersalności analitycznej znanej z zaawansowanych systemów dziedzinowych (BI, raportowanie) z łatwością dostępu do informacji znanego z tzw. baz danych OLTP (on-line transaction processing) lub hurtowni danych, a na dodatek mamy do dyspozycji szereg poleceń stosujących techniki uczenia maszynowego.

Praktyka ML — od struktury do wniosków

W trakcie pracy analitycznej, również tej związanej z uczeniem maszynowym, można wyróżnić kilka charakterystycznych etapów:

• analiza struktury i relacji danych;
• analiza znaczenia danych i zawartych w nich informacji;
• przygotowanie schematu lub modelu analizy (najczęściej drogą eksperymentu lub z doświadczenia), najczęściej względem jakieś hipotezy;
• zastosowanie modelu: zestawienia syntetyczne, wizualizacja i interpretacja uzyskanych wyników.

W przypadku tradycyjnego podejścia, każdy z tych etapów wymaga najczęściej specjalizowanych narzędzi. Na przykład etap wstępnego przetwarzania danych, z racji ich „pochodzenia” baz relacyjnych jest realizowany na bazie dokumentacji schematów oraz ewentualnej ich transformacji przy pomocy technik ETL (ang. extract, transform, load). Dopiero tak przetworzone, często „spłaszczone”, dane nadają się do zastosowania w szeroko pojętej analityce, w tym przygotowaniu modeli statystycznych, ML itd.

Tak jest (było) w przypadku źródeł relacyjnych. Trochę inaczej sytuacja wygląda w przypadku danych bardziej zróżnicowanych strukturalnie, tzw. „dużych danych” (ang. Big Data), do których śmiało można zaliczyć wszelkiego rodzaju zapisy, rejestry związane z przebiegiem procesów, dodatkowo cechą szczególną takich informacji jest komponent czasu, który często jest wykorzystywany jako istotny czynnik (np. analiza prawdopodobieństwa następstwa zdarzeń w procesie, tzw. clickstream itp.).

W przypadku danych o dużym zróżnicowaniu tradycyjne techniki przestają być efektywne, trzeba tu narzędzia zorientowanego na ten rodzaj informacji. Takim rozwiązaniem jest między innymi system Splunk Enterprise, z podejściem „schema on the fly” i różnymi innymi cechami, które predestynują go analiz dużych ilości danych mocno zróżnicowanych. Dzięki temu jest to system, a w zasadzie platforma systemowa, doskonała do zastosowania na polu uczenia maszynowego działającego na „dużych danych”.

Zwróćmy uwagę, że instalując na platformie Splunk dodatkowe komponenty w postaci Python for Scientific Computing i Machine Learning Toolkit uzyskujemy w pełni funkcjonalne środowisko analityczne, które pozwala nam wykonywać strukturalizację (ekstrakcję) oraz dowolne przekształcenia danych przy pomocy języka SPL, a dodatkowo posiada pełny (praktycznie) wachlarz powszechnie stosowanych algorytmów ML, z możliwością implementacji własnych rozwiązań w postaci kolejnych elementów języka SPL. Dodatkowo system Splunk charakteryzuje się dojrzałym i intuicyjnym interfejsem graficznym (wizualizacji danych). Daje to praktycznie nieograniczone możliwości budowania specjalizowanych (dziedzinowych), współdzielonych (praca zespołowa) środowisk analitycznych.

Przykład zastosowania MLT

Przyjrzyjmy się możliwościom Splunk MLT z bliska na przykładzie danych dotyczących handlu nieruchomościami.

Na wstępie, zanim zaczniemy praktyczną przygodę, dodam, że zupełnie nie znam się na rynku nieruchomości, więc jest to egzemplifikacja przypadku „mądrego” analityka działającego z całkiem nowym zagadnieniem. Dane, które wykorzystałem, są dostępne jako dane przykładowe w Splunk MLT.

Sam eksperyment jest oczywiście uproszczeniem prawdziwego procesu treningu ML, ale może dać ogląd na specyfikę pracy w tej dziedzinie analizy danych.

Co do samych technik uczenia maszynowego, nie ma niestety miejsca w tym artykule na szczegóły, ale osobom technicznym i analitykom, jako wstęp do technik ML, z czystym sumieniem mogę polecić stronę dr. Jasona Brownlee: https://machinelearningmastery.com

Eksperyment czas zacząć

Pozyskaliśmy próbę 506 lokalizacji sprzedaży nieruchomości wraz z danymi statystycznymi takimi jak mediana uzyskanej przy sprzedaży wartości; jak i skąd, jak otrzymaliśmy z tego dane to temat na inny artykuł. Lokalizacje nieruchomości opisane są 12 cechami, poniżej próba zestawu danych dla kilku lokalizacji.

Celem eksperymentu jest przygotowanie modelu ML, który najlepiej zrealizuje predykcję mediany wartości domu przy zadanych parametrach

Po pierwsze, z dalszej analizy i parametryzacji modelu ML wykluczamy lokalizacje o największym wskaźniku przestępczości. Robimy to metodą odcięcia centylowego według wskazanej cechy, dokładnie interesują mnie tylko lokalizacje ze wskaźnikiem poniżej 75 centyla dla danego obszaru (land_zone). Można tak przygotować próbę statystyczną, odpowiednio stosując język SPL.

<dane źródłowe> | eventstats perc75(crime_rate) as cutoff_crime_rate by
land_zone | where crime_rate < cutoff_crime_rate | …

Proste, prawda? Można powiedzieć, że składnia polecenia jest banalnie prosta i intuicyjna. Operator strumienia „|” ma tu dokładnie takie samo zastosowanie, jak ten ze środowisk powłok POSIX.

Gdybyśmy dysponowali dużym zbiorem danych, Splunk MLT daje nam dodatkowe polecenie sample, które moglibyśmy wykorzystać do pseudolosowego generowania próby statystycznej — tutaj tego nie wykorzystamy, ponieważ zbiór danych, którymi dysponujemy jest i tak mały. Ale mogłoby wyglądać to tak:

<dane źródłowe> | sample ratio=0.1 | eventstats perc75(crime_rate) as
cutoff_crime_rate by land_zone | where crime_rate < cutoff_crime_rate | …

Następnie, kiedy mamy już przygotowaną podstawę zbioru danych dla naszego eksperymentu uczenia maszynowego, możemy przystąpić do kolejnego etapu przygotowania uczenia nadzorowanego: selekcji interesujących cech (więcej możesz przeczytać tutaj:
https://machinelearningmastery.com/an-introduction-to-feature-selection/)

Poniżej przedstawiono, jak realizujemy dwa pierwsze etapy w kreatorze eksperymentu ML w Splunk MLT.

Mamy do dyspozycji szereg algorytmów przetworzenia wstępnego. Ja wybrałem, zgodnie z wcześniejszym opisem, FieldSelector, czyli algorytm, który ze wskazanego zestawu cech (potocznie pól), wskaże mi te najbardziej oddziałujące na cechę, której eksperyment ma dotyczyć, tzw. celu (median_house_value). Dodatkowo, mamy możliwość wybrania trybu traktowania celu, np. czy ma być traktowany jako wartość numeryczna, czy kardynalna (grupowanie) oraz algorytm samej selekcji (wybieramy K-best, u mnie dawał najlepsze efekty).

Jak widać, już tutaj mamy pole do eksperymentowania z różnymi parametrami przetwarzania danych. Lecz dzięki łatwemu interfejsowi, prostocie konfiguracji możemy to robić bez zbędnego oczekiwania (np. na kompilację) modyfikować cały proces. To duża zaleta środowiska Splunk.

Następnie, gdy mamy już przygotowaną wstępną parametryzację, możemy przejść do właściwej części eksperymentu. W niej zajmiemy się doborem optymalnego algorytmu ML, co czasem nie jest zadaniem trywialnym.

Do wyboru mamy szereg predefiniowanych algorytmów, najczęściej stosowane w praktycznym uczeniu maszynowym. My, w ramach eksperymentu tworzenia modelu predykcyjnego, zajmiemy się dwoma, dość popularnymi w zastosowaniu: regresją liniową oraz algorytmem drzewa decyzji.

Na pierwszy ognień idzie algorytm regresji liniowej. W polu „Field to predict” wskazujemy cechę celu predykcji (median_house_value). W polu „Fields to use for prediction” wskazujemy pola, które mają być uwzględnione w modelu predykcyjnym. Warto również wskazać parametr wskazujący na stosunek podziału zbioru danych na uczące i weryfikujące. Dane uczące będą wykorzystane do strojenia modelu, a weryfikujące do sprawdzenia jego skuteczności na zasadzie sprawdzenia współczynnika determinacji (R2) oraz błędów predykcji (RMSE).

Po wprowadzeniu parametrów startujemy proces uczenia (przycisk „Fit”).

Poniżej przedstawiono wyniki w formie graficznej, zaprezentowanej w aplikacji po wykonaniu zadania.

W pierwszej sekcji widać dane wejściowe oraz wynik predykcji wraz z określonym błędem (różnicą). W następnej „Actual vs. Predicted …” pokazano różnice, błędy w przewidywaniu wykonanym przez algorytm predykcyjny.

W ostatniej sekcji pokazano współczynnik determinacji oraz odchylenia dla wybranej metody ML. Są one wykorzystywanie w przypadku praktycznego doboru metody jako wartości porównawcze.

W tym miejscu głównym zadaniem jest dobranie metody o najmniejszym „względnym” błędzie, tj. o współczynniku determinacji jak najbliższym wartości 1. W poprzednim przypadku, dla zadanych parametrów, uzyskaliśmy wartość 0.5441. Sprawdźmy więc, jak zachowa się kolejna metoda ML, mianowicie algorytm drzewa decyzji, przy tych samych parametrach wejściowych.

Oto wyniki (te najważniejsze) dla metody drzewa decyzji.

Jak widać na załączonym obrazku, metoda nr 2 poradziła sobie nieco gorzej, a wskazuje na to (zgodnie z definicją) wartość współczynnika determinacji.

Konkluzja

Konkluzja zawiera się w konstrukcji językowej, która zbudowała kanwę całego artykułu.

| inputlookup housing.csv | eventstats perc75(crime_rate) as
cutoff_crime_rate by land_zone | where crime_rate < cutoff_crime_rate

| fit FieldSelector "median_house_value" from "avg_rooms_per_dwelling",
"charles_river_adjacency", "crime_rate", "distance_to_employment_center",
"highway_accessibility_index", "land_zone", "nitric_oxide_concentration",
"property_tax_rate" type=numeric mode=k_best param=3 into
example_housing_FieldSelector_0

| fit LinearRegression fit_intercept=true "median_house_value" from
"fs_*" into "example_housing"

Tak oto, pięcioma poleceniami w jednym zapytaniu SPL, stworzonym w interaktywnym graficznym kreatorze, udomowiliśmy trochę „sztuczną inteligencję” (a przynajmniej jej istotny element) i zbudowaliśmy model przewidujący przybliżone ceny nieruchomości gdzieś w Stanach Zjednoczonych Ameryki Północnej. Zapewne podobny stopień trudności dotyczyłby naszych polskich realiów lub innych zagadnień, z innych dziedzin biznesu.

Zauważmy, że wszystkie etapy analizy (przydałby się jeszcze jakiś kokpit dla agenta nieruchomości) wykonaliśmy w jednym spójnym środowisku analitycznym, bo tak bez obaw można nazwać system Splunk Enterprise.

W podsumowaniu tego prostego eksperymentu należy jeszcze wskazać, że to oczywiście nie wszystko. Teraz ten model („example_housing”) można wykorzystywać do przewidywania cen nieruchomości dla nowych danych (z zestawem cech, które wykorzystaliśmy do budowy modelu). I wykorzystać interfejs API systemu Splunk Enterprise do zbudowania strony, która na podstawie danych statystycznych okolicy wyznacza orientacyjne ceny nieruchomości. Ale to już temat na zupełnie inny artykuł.

Z pozdrowieniem „splunkowca”
— Happy Splunking!