Z tego odcinka dowiesz się:

1. AutoML – lepszy niż człowiek? Omówienie kontekstu, w którym AutoML może przewyższać człowieka, i jakie są jego ograniczenia.
2. Rola człowieka w procesie Machine Learning. Zrozumienie, które elementy procesu ML wymagają ludzkiej kreatywności i intuicji, a które mogą być zautomatyzowane.
3. Etapy procesu Machine Learning. Wyjaśnienie poszczególnych kroków w ML: od postawienia celu, przez przygotowanie danych, modelowanie, aż po wdrożenie.
4. Tryby pracy AutoML w MLJAR. Przedstawienie różnych trybów pracy MLJAR, takich jak „Compete”, „Perform”, „Explain” i „Optuna”, i jak każdy z nich spełnia inne potrzeby użytkowników.
5. Przyszłość AutoML. Dyskusja na temat przyszłości AutoML, jakie nowe możliwości przyniesie i jak może się rozwijać.
6. Znaczenie AutoML dla różnych ról. Omówienie, jak AutoML może być użyteczny dla różnych ról w firmach, od product ownerów, przez ML engineerów, po DevOpsów.
7. Przykłady zastosowań AutoML. Konkretny przykład użycia MLJAR w praktyce, pokazujący jak AutoML może przyspieszyć procesy i zwiększyć efektywność pracy z danymi.

Jednym z coraz częściej poruszanych tematów w obszarze AI jest AutoML, który według wielu działa lepiej niż człowiek. To stwierdzenie jest poniekąd prawdziwe, ale jest także bardzo mylące – w szczególności dla osób, które nie do końca rozumieją kontekst. To wszystko zależy od tego, kto to mówi i w jakim kontekście. Dzisiaj spróbujemy postawić kropkę nad i, aby uspójnić i ustrukturyzować Twoją wiedzę w tym temacie. 

Moim gościem w tej rozmowie jest Piotr Płoński, twórca MLJAR – popularnego na całym świecie i rozwijającego się w Polsce narzędzia AutoML.

Sam znam tylko jedno narzędzie AutoML z ogólnoświatową popularnością, które rozwija się w Polsce. Osobiście już od dawna obserwuję Piotrka i jego działalność chociażby z tego powodu, że w AutoML używa takie algorytmy jak XGBoost. Mało tego, używa też CatBoost, o którym mam wrażenie, że w Polsce prawie nikt nie mówi. A szkoda, bo w tych bibliotekach jest bardzo duży i praktyczny potencjał.

Sam wdrażam je na produkcję i obserwuję bardzo dobre wyniki. Też uczę o tych bibliotekach na Data Science kurs w ramach DataWorkshop. Na kursie często pojawia się pytanie: „Czy da się przygotować prosty, jednoznaczny algorytm postępowania, jak być efektywnym?”. Taka prosta recepta rozpisana krok po kroku.

Zwykle odpowiadam, że jeżeli da się w taki sposób przygotować algorytm, jak postępować konkretnie w tym przypadku, to po co jest potrzebny człowiek? Tak naprawdę robot potrafi znacznie szybciej, sprawniej, wcisnąć tzw. „czerwony guzik”. 

Są jednak pewne obszary w procesie machine learning, data science, które są niedeterministyczne i powodują, że człowiek jest bardzo potrzebny. Tam właśnie jest potrzebna twórcza energia, umiejętność kombinowania i łączenia przeróżnych rzeczy naraz, m.in. dlatego staram się tłumaczyć na moim kursie te obszary, które są twórcze, kreatywne albo chociaż mniej powtarzalne. Te obszary są właśnie dla ludzi. 

Dzisiaj postaramy się odpowiedzieć na pytanie: czy da się zautomatyzować 100% procesu data science przy pomocy AutoML? Czy zawód data scientist to już nie jest zawód przyszłości, a raczej przeszłości (bo da się już to wszystko zautomatyzować)? 

Cześć Piotrek. Opowiedz, kim jesteś, czym się zajmujesz, gdzie mieszkasz?

Cześć. Czym się zajmuję? Teraz pracuję nad narzędziem do automatycznego machine learningu, które nazywa się MLJAR. Większość czasu spędzam na programowaniu, pisaniu kodu do pakietu, do automatycznego machine learningu, ale oprócz programowania zajmuję się też rzeczami związanymi z prowadzeniem firmy, czyli sprzedażą, marketingiem. Trochę robię researchu, bo część algorytmów do AutoML trzeba wymyślić samemu. Mieszkam w Łapach w województwie podlaskim.

Pewnie fajnie się oddycha…  

Co ostatnio ciekawego przeczytałeś i dlaczego to polecić? Masz interesującą lekturę pod ręką?

Tak. Ostatnio czytałem „Karpie Bijem” Pilipiuka. Nie jest to związane z machine learningiem, z programowaniem ani z data science, tylko to jest taka fabularna książka (fantasy). Chyba czasem dobrze oderwać się od tego, co się robi zawodowo i po prostu się zrelaksować i nie cisnąć. 

Podobno wtedy najlepiej wyciskamy, bo podświadomość czy tam inne procesy się uruchamiają i robią za nas całą robotę. Potem mamy tylko gotowe rozwiązania. Widziałem badania na ten temat. 

Piotrek, powiedz trochę więcej o swoim doświadczeniu. Jest ono bogate, ale konkretnie pytam o doświadczenie z obszaru uczenia maszynowego. Z pewnością nie o wszystkich rzeczach możesz mówić, ale przynajmniej częściowo opowiedz o swojej ścieżce.

Zacząłem się interesować machine Learningiem na studiach magisterskich. Studiowałem na Politechnice Warszawskiej, na inżynierii biomedycznej. Moim promotorem był profesor Zaręba i wtedy zacząłem się interesować sieciami neuronowymi. Akurat zakład, w którym robiłem pracę magisterską, brał udział w wielu różnych eksperymentach fizycznych, w których potrzebny był machine learning, np. do rozróżniania cząstek. Jakoś tak się naturalnie wkręciłem w ten temat.

Na początku budowałem algorytmy do machine learningu od podstaw sam. Bardzo mi brakowało narzędzia, gdzie te algorytmy już by były zaimplementowane i tak stopniowo zacząłem poznawać R. Potem z R przesiadłem się na Pythona. Znalazłem bibliotekę Scikit-learn i wkręciłem się w to. 

Po studiach magisterskich zacząłem doktorat (też na Politechnice Warszawskiej). Na doktoracie również używałem machine learningu do analizowania danych z eksperymentów fizycznych, ale też do analizy obrazów z obrazowania medycznego. Brałem udział w ciekawym projekcie, gdzie dostępne były zdjęcia dzieci z dysleksją. To były zdjęcia mózgu uzyskane za pomocą rezonansu magnetycznego. Projekt polegał na zbadaniu, czy można za pomocą skanu z rezonansu magnetycznego sklasyfikować, czy dziecko ma dysleksję. Bardzo ciekawy projekt. 

Używałem też machine learningu do analizy danych bioinformatycznych. W tym obszarze bawiłem się danymi, które opisywały różne szczepy wirusa grypy i budowałem klastry (drzewa filogenetyczne) z tych wirusów. Gdy zacząłem doktorat, to jeszcze równolegle podjąłem pracę w firmie Netezza, która robiła hurtownie danych. Po kilku miesiącach od mojego dołączenia do firmy, została ona przejęta przez IBM i tym sposobem wylądowałem w IBM’ie. Tam pracowałem najpierw nad oprogramowaniem do monitorowania tego warehouse, a potem nad oprogramowaniem do budowania modeli w hurtowni danych. 

Potem zmieniłem pracę i pracowałem w firmie iQor. To jest duża firma, która świadczy różne usługi innym firmom i przede wszystkim świadczy usługę call center. Pracowałem bardzo dużo z danymi z call center, z nagraniami rozmów i budowaliśmy system do automatycznego przeszukiwania rozmów, żeby znaleźć jakieś słowa kluczowe. 

W sumie trochę tych projektów było różnych, akademickich i przemysłowych i wszystkie miały tę jedną wspólną część, że jak już te dane były zebrane, to trzeba było zbudować model. Zacząłem pragnąć, żeby mieć takie narzędzie, gdzie po prostu te dane mogę wrzucić, wcisnąć przycisk START, poczekać kilka godzin i mieć sprawdzonych kilka modeli, z których wybrać najlepszy. Tak chyba się zrodziła potrzeba zbudowania MLJAR’a.

Jak ja to zacząłem budować, to był rok 2016. Jeszcze wtedy o AutoML nie było za dużo w Internecie, nie było serwisów do AutoML. Może były jakieś pakiety, ale one nie działały za dobrze. Tak się chyba zrodziła potrzeba budowania MLJAR.

Machine Learning krok po kroku

Zanim przejdziemy do tego tematu, warto zdefiniować, na czym polega proces machine learning z lotu ptaka. Jakie procesy lub poszczególne etapy przechodzimy, aby przejść z punktu A do punktu Z, gdzie punkt A to nie ma nic, a punkt Z to działa i zarabia pieniądze? Spróbujmy wymienić kamienie milowe, a później porozmawiamy, czy da się to zautomatyzować i co dokładnie się da. 

Czasem ludzie się kłócą o to, czy AutoML działa, czy nie. Dla mnie jest to trochę dziwne, bo nie wiadomo, o co się kłócą. Machine learning sam w sobie nie jest kropką. To jest cały proces, który się składa z wielu czynności i pewne da się zautomatyzować, a pewne nie. Spróbujmy najpierw opisać te czynności, które mamy w klasycznym uczeniu maszynowym, a potem porozmawiamy, co z tego da się zautomatyzować już dzisiaj, a co być może jutro. 

Tak, tu się zgadzam. Niestety nie wszystko da się zautomatyzować. Na pewno nie da się zautomatyzować tego pierwszego kroku, czyli rozpoznania, szukania problemu i postawienia go w taki sposób, żeby był rozwiązywalny przez machine learning.

Mam kontakt z wieloma ludźmi, którzy używają mojego oprogramowania i nawet się spotykałem z takimi użytkownikami, którzy do mnie pisali maila pytając, czy za pomocą automatycznego machine learningu można przewidywać, jakie liczby będą wylosowane w lotto. Przecież mamy liczby historyczne, które np. zostały wylosowane wczoraj, przedwczoraj i na podstawie machine learningu można przewidywać, jakie liczby będą wylosowane dzisiaj albo jutro. 

Trzeba tym ludziom tłumaczyć, że zdarzenia są niezależne i nie da się tego zrobić uczeniem maszynowym, choćby nie wiem, jaki ten AutoML był. Żadnym machine learningiem się tego nie da zrobić. Mi się wydaje, że często w firmach to jest bardzo duży problem, żeby rozpoznać, gdzie ten machine learning można zastosować, żeby zarabiać albo oszczędzać pieniądze. Wydaje mi się, że jedynym sposobem, żeby tutaj poprawić działanie, jest edukacja – kursy, szkolenia, czytanie jak inni wprowadzali uczenie maszynowe w swoich firmach. Masz jakiś pomysł, jakby to można było polepszyć?

A propos kursu to na pewno tak, bo sam akurat prowadzę i uczę. To jest bardzo fajna uwaga, że zanim się użyje narzędzia, które wszystko zautomatyzuje, warto zdobyć pewne fundamenty, które pozwolą lepiej to interpretować. 

Wrócę jeszcze do mojego pytania. Chciałem, żeby wybrzmiały punkty związane z procesem machine learning. Pierwszy już mamy, czyli postawienie celu. Chodzi o to, żeby zdefiniować dany problem, określić miary sukcesu i jego interpretację, zakres tolerancji błędu i źródło danych, itd. Ciężko wyobrazić sobie automatyzację tego kroku. 

Drugi krok jest wprost związany z danymi, czyli praca z nimi. Zaczynając od integracji danych (czyli mamy wiele źródeł, trzeba jakoś to połączyć), czyszczenia danych na wielu różnych płaszczyznach. Czasem to czyszczenie polega na tym, że usuwamy spację, inny razem pojawiają się różne wyzwania w danych. Na przykład pamiętam, jak zbierałem ogłoszenia na temat nieruchomości w Polsce, to np. były takie informacje, że mieszkanie było malutkie (30m2), ale miało 4 łazienki.

Nie zrozumiałem, o co chodzi, ale pewnie o 4m2 w tej łazience – taką hipotezę miałem, bo 4 łazienki na takie malutkie mieszkanie to jednak za dużo. Ciężko to wychwycić automatycznie. Pojawia się także temat uspójniania danych, ale tutaj mamy feature engineering i np. feature selection czyli tworzenie nowych cech i wybieranie tych, które faktycznie warto zostawić z tych tysięcy, dziesiątek tysięcy cech. 

Chciałbym, żebyś się wypowiedział o tych krokach: co według Ciebie da się fajnie zautomatyzować, co jeszcze nie?

Trzeci krok to jest modelowanie – wybór różnych algorytmów, trenowanie ich, dobór parametrów czyli hyperparameter optimization. 

Czwarty krok, który często pomija świat akademicki, ale dla biznesu jest bardzo konieczny, właściwie najważniejszy – to jest wdrożenie. Wdrożenie w sensie produktowym, że mamy założony monitoring, alerty, sprawdzanie czy dane nam się nie zmieniają, sprawdzanie jak to było wczoraj, jak jest dzisiaj, czy model się nie postarzał, bo z czasem się degraduje. Plus tutaj różne benchmarki, powtarzalność eksperymentu albo np. testy – spróbujmy włączyć wczorajszy model zamiast dzisiejszego lub na odwrót i porównajmy efekty, a do tego GUI, API, żeby móc się zintegrować produktowo.

Wymieniłem cztery kroki i teraz porozmawiajmy z punktu widzenia AutoML: które z tych rzeczy już udało się zautomatyzować, które próbujemy zautomatyzować, a które są jeszcze bardzo ciężkie do automatyzacji?

Które procesy w Machine Learning można automatyzować?

Ok. Postawienie celu i szukanie problemów machine learningowych to powiedzieliśmy, że jest ciężko zautomatyzować, chociaż tak się chwilę zastanowiłem i można myśleć o takich branżowych AutoML. Jak mówiłeś o nieruchomościach, to można myśleć o takim branżowym AutoML np. do przewidywania, szacowania ceny tych nieruchomości. Wtedy masz branżowy AutoML, który ma zdefiniowane machine learningowe zadania, które jest w stanie rozwiązywać i wtedy nie musisz tego problemu szukać, bo on już jest zdefiniowany.

Tak samo jeśli chodzi o przygotowanie danych, to zazwyczaj to wszystko trzeba zrobić ręcznie. Mógłby jednak istnieć jakiś serwis branżowy, np. do human resources, gdzie dane w różnych firmach zajmujących się HRami, wyglądają podobnie, bo napływają jakieś CV, a Ty chciałbyś automatycznie oceniać kandydatów. Wszędzie dostawałbyś jakiegoś PDFa albo Worda i z tego byś chciał wyciągać cechy.

Sądzę, że taki branżowy AutoML, gdzie z góry zdefiniowane są źródła danych, jest możliwy. Niemniej na dzień dzisiejszy w 95% przygotowanie danych to jest praca ręczna, bo te dane trzeba wiedzieć, z czego się potrzebuje, trzeba wiedzieć, gdzie ich szukać, jak je z różnych źródeł łączyć. Ciężko uogólnić i zrobić jedną metodę do przygotowania danych.

Jeszcze z takich moich przemyśleń na temat przygotowania danych to wydaje mi się, że dobrze zaczynać projekt machine learningowy od najprostszego zbioru czyli zbioru, który łatwo będzie uzyskać, który niekoniecznie będzie ogromny. Nawet kilkaset próbek czasem wystarczy, żeby zacząć budować prosty model machine learningowy – jakieś drzewo decyzyjne.

Na początku, jakbym zaczynał taki projekt machine learningowy, to wcale bym nie szalał z feature engineeringiem, chyba, że jest konieczny bądź pracujemy z tekstem i musimy wyciągnąć jakieś cechy. Z feature selection – gdybym zaczynał projekt machine learningowy i bym startował w tej dziedzinie, to też bym się wstrzymał i feature selection bym sobie zostawił na kolejną iterację.

Ja mam bardzo iteracyjny sposób podchodzenia do tego typu projektów. Staram się zacząć z bardzo prostym modelem i sprawdzić, czy w tych danych jest jakiś sygnał, czy jestem w stanie coś zamodelować. Przygotowanie danych też bym traktował iteracyjnie. 

Jak te dane są przygotowane, to trenowanie modelu, czyli wybór modelu i hiperparametrów, da się według mnie bardzo dobrze zautomatyzować. Często słyszę opinie, że to jest taki krok, który mało zajmuje czasu, 80% czasu to jest przygotowanie danych, a 20% to jest modelowanie i że może nie warto automatyzować tego kroku, bo on i tak jest mały.

Jeśli jednak te 20% potrzebnego czasu na projekt to realnie wychodzą 2-3 dni to warto to zautomatyzować. To jest spora oszczędność, bo możemy np. zaoszczędzić 2 dni czyjejś pracy. Jeżeli ten ktoś musi budować model raz w miesiącu czy raz na 2 tygodnie, to przez rok uzbiera się tych godzin i można realnie sobie policzyć, ile zyskamy, używając AutoML.

Jeżeli chodzi o wdrożenie, to wydaje mi się, że tutaj to już jest taki software engineering solidny i nie ma co kombinować. Trzeba używać porządnego oprogramowania do wdrażania modeli albo używać jakiegoś serwera, trzymać model na tym serwerze i odpytywać go po jakimś API albo trzymać model lokalnie i co jakiś czas liczyć predykcję. Moim zdaniem wdrożenie to już jest software’owy problem i tutaj nie ma jakiejś magii.

Jeśli chodzi zaś o przygotowanie danych i trenowanie modelu to tutaj często jest research. Wiele rzeczy jest niepewnych, niespodziewanych. Miałem np. takiego klienta, dla którego pomagałem budować system machine learningowy do handlowania energią elektryczną w Stanach Zjednoczonych.

Rynek energii elektrycznej tam jest taki, że można wirtualnie zamawiać, kupować albo sprzedawać prąd w wybranej godzinie i dane odnośnie zużycia, przewidywanej produkcji prądu są publicznie dostępne, więc jeżeli człowiek ma wystarczająco dużo pieniędzy, żeby wykupić sobie licencję do handlu tą energią elektryczną, to może brać udział w tym markecie. Najczęstszym problemem, jaki tam spotykaliśmy, było opóźnienie dostawcy, opóźnione predykcje, ile prądu będzie wytworzone na następny dzień, a akurat model tego używał.

Przez to nie mogliśmy policzyć swoich predykcji, bo czekaliśmy cały czas na predykcje zewnętrznego serwisu. Dużo jest też czynników zewnętrznych, na które nie zawsze możemy być przygotowani w trakcie budowania tego naszego systemu machine learningowego i dopiero jak już go wdrożymy i zaczynamy używać, to wychodzą niespodzianki.

Poruszyłeś kilka ciekawych rzeczy, ale zacznę od tego 80-20, że bardzo duży procent czasu data scientist spędza na przygotowaniu danych, a jedynie 20% na modelowaniu. Funkcjonuje też druga wersja tego powiedzenia, że 80% to przygotowanie danych, a 20% to narzekanie, że musiało się przygotować te dane. Akurat AutoML tu fajnie się wpisuje, bo specjalista musi mieć czas na to narzekanie. 

Komu AutoML może pomóc?

Fajnie powiedziałeś a dylemacie, że np. jeżeli część twórcza to zaledwie 20%, to może nie warto ją automatyzować, a potem dodałeś, że może jednak warto, bo pojawia się oszczędność czasu. To jest ciekawy wątek. Poruszmy go, bo punkt widzenia zależy od punktu siedzenia, prawda? Ustalmy role, które w ogóle mogą brać udział w tej grze. Ja w tej chwili wymienię 4:

1. Product owner, biznes, który nadaje priorytety.

2. ML, AI, DS (Data Science) inżynier czyli wykonawca.

3. DevOps, MLOps – ostatnio popularne hasła.

4. Świat akademicki – badacze, researcherzy.

Swoją drogą, jak zacząłeś pisać MLJAR i opisywałeś swoją ścieżkę, to według mnie byłeś w tej drugiej roli czyli ML, AI, DS engineer czyli osoba, która to wykonuje. 

Jak myślisz, jakie metryki sukcesu są u każdej z tych ról i na ile ta osoba widzi AutoML, w szczególności MLJAR w swoim życiu? Każda z tych ról ma zupełnie inne bolączki.

Tak, chociaż załóżmy, że weźmiemy pierwsze trzy. Product owner, machine learning engineer i MLOps. Powiedzmy, że to są 3 różne osoby, które pracują w tej samej firmie. Tak naprawdę to wszystkie te 3 osoby mają jeden cel, bo chciałyby, żeby projekt był sukcesem i żeby system machine learningowy zadziałał.

Ta metryka dla tych osób powinna być jedna i ta sama, a z kolei pewnie tą najważniejszą metryką dla product ownera będą pieniądze zarobione albo zaoszczędzone. Idealnie by było, gdyby zawsze można było wyliczyć, ile jesteśmy w stanie zarobić albo zaoszczędzić używając machine learningu, a ile tracimy nie używając go.

Wyliczając te pieniądze, machine learning engineer zazwyczaj jest zły, bo musi robić grube oszacowania, które czasem wydają się śmieszne, bo jak jedną liczbę się oszacuje, drugą liczbę się oszacuje „pi razy oko”, to ten wynik końcowy może być śmieszny, bo np. może być tak, że poprawimy o 1% działanie jakiegoś systemu i już wychodzą miliony.

Product owner na pewno będzie zadowolony, gdy pokażemy mu, że możemy zaoszczędzić miliony. Zatem wydaje mi się, że dla product ownera to będą zaoszczędzone albo zarobione pieniądze. 

Machine learning engineer będzie musiał wyliczyć te pieniądze, podać jakąś liczbę – będzie zmuszony do tego. On pewnie będzie się cieszył, gdy zbuduje fajny model i ten model naprawdę wyciśnie dobre efekty. Wydaje mi się, że dla niego wskaźnikiem będzie standardowa metryka, której będzie używał do budowania modelu. Załóżmy, że uzyska bardzo niskie log loss albo pole pod krzywą ROC będzie duże. Sądzę, że to będzie satysfakcjonujące. 

Jeśli chodzi o DevOpsa, to on też będzie musiał się podporządkować pod product ownera. Także będzie musiał wskazać liczbę, mówiącą, ile ta jego praca będzie warta. Myślę, że dla DevOpsa taką metryką sukcesu będzie to, ile predykcji jest w stanie policzyć np. dziennie i ile tych predykcji będzie policzonych z krótkim czasem oczekiwania, ile będzie błędów, ile czasu serwer będzie dostępny online.

Dodam jeszcze, że ML engineer ma sporą presję od product ownera, ciasne deadline’y. Właściwie od czego zacząłeś. Powiedziałeś, jak Ci przyszedł do głowy pomysł na MLJAR. Chciałeś po prostu szybko eksperymentować i nie chciałeś rzeczy powtarzające się wykonywać wiele razy, bo są inne, które są nie powtarzające i chcesz tam skupić swoją uwagę.

Taki ML engineer myślę, że będzie też zadowolony z tego powodu, że ma maszynkę do przeliczania, gdzie można coś wrzucić i już pierwsze wyniki na pewno ma, a potem ewentualnie sobie to podkręca. DevOps myślę, że będzie też zadowolony, jeżeli chodzi o stabilność wdrażania pod tym względem, że on będzie w jakiś sposób ufać, wierzyć, że element, kiedy wrzuci na produkcję, nie popsuje niczego, a więc będzie chciał mieć jakąś kontrolę nad tym, co się tam dzieje.

Jaką wartość przynosi AutoML?

ML Lab na Uniwersytecie w Freiburg prowadzi stronę AutoMl.org, którą pewnie bardzo dobrze znasz. Oni ciekawie definiują, czym jest AutoML. Ta przystawka “Auto” mówi, że to jest automatyzacja ML. Podają trzy gałęzie tego, dlaczego i komu to może się przydać:

1. Zwiększyć dostępność ML dla osób, które nie znają ML.

To trochę brzmi jako taki product owner business, czyli masz DRAG&DROP, że tam wrzucasz plik *csv albo dane z bazy SQL, wciskasz „zrób to” i dostajesz gotowe dashboardy. 

2. Usprawnić efektywność.

Myślę, że w tym przypadku oni zwracają się w kierunku ML engineerów, żeby byli bardziej efektywni.

3. Przyspieszyć badanie, czyli projekty R&D.

Z Twojej perspektywy gdzie najbardziej AutoML się przyda i jacy użytkownicy będą go używać? Warto się odnieść też do tego, co jest napisane na stronie AutoML.org, bo to jest w pewnym sensie dość kluczowe źródło informacji o AutoML.

Tak jak powiedziałeś, tych grup docelowych dla AutoML jest kilka. Ten product owner to ludzie, którzy bardzo mogą skorzystać z AutoML’a. Miałem przykład klienta, który wymyślił sobie, że będzie budował aplikację monitorującą graczy e-sportowych w trakcie grania w grę. Jeżeli dany gracz zacznie słabiej grać, to będzie mu się wyświetlał komunikat, żeby przestał grać na ranking, żeby w nim nie spadł.

Klient, który to sobie wymyślił, trochę programował, ale na machine learningu nie znał się w ogóle. Wiedział, że taka dziedzina istnieje, wiedział, że chce wykorzystać uczenie maszynowe w swojej aplikacji, zgłosił się do nas i za pomocą MLJARa zbudował algorytm, który pobierał dane opisujące zachowanie danego gracza w grze, np. jak szybko klika i na podstawie tego wyznaczał mu score, czy jego performance w trakcie grania jest jeszcze wysoki, czy już spada.

Klient wyznał nam, że gdyby nie AutoML, to on by w ogóle nie ruszył z tym, bo nie miał w tej dziedzinie takiej wiedzy, która by pozwalała na stworzenie modelu machine learningowego od zera. Przez to, że był AutoML i stworzył system, który zbiera te dane, a następnie te dane przygotował, to on sobie przeciągnął dane na AutoML, system wyszukał mu algorytm, który na tych danych testowych super działał i on mógł dalej rozwijać swoją aplikację. Czyli AutoML dla takich ludzi biznesowych otwiera nowe możliwości. To nie będzie dla nich jedynie ułatwienie, tylko są w stanie budować nowe rzeczy dzięki AutoML. 

Jeśli chodzi o zaawansowanych data scientists, to AutoML może im przyspieszyć pracę. Ja często traktuję AutoML jako taki algorytm, którego nie muszę tuningować, czyli jak mam już te dane przygotowane, to po prostu wrzucam je na AutoML, ustawiam czas trenowania np. na 8 godzin i wiem, że ten model będzie super. Wiem, że będzie mi bardzo ciężko zrobić lepszy model ręcznie. Bardzo wiele miałem wiadomości od osób, które używały MLJARa w różnych konkursach machine learningowych, np. na Kaggle. 

Także dla takich doświadczonych machine learningowców uważam, że AutoML to świetny baseline. Bardzo szybko mogą zrobić dobry model, ale też AutoML może być jednym z algorytmów w palecie finalnych rozwiązań. Też często się widzi takie pytania na różnych forach: czy AutoML pozbawi machine kearning engineerów pracy? Mi się wydaje, że to jest straszne nieporozumienie, bo to tak jakby się pytać, czy młotek pozbawi stolarza pracy? AutoML to jest tylko narzędzie.

To nie jest rozwiązanie, które całkowicie zastąpi tego człowieka, który używa narzędzia. To jest tylko narzędzie, nie ma co się tego narzędzia bać, tylko trzeba go używać, bo dzięki temu możemy tworzyć lepsze modele i możemy je tworzyć szybciej. Nie ma co się bać AutoML’a, jeżeli jest się takim zaawansowanym machine learningowcem. 

Jeśli chodzi o świat akademicki, to często jest tak wśród badaczy, że oni bardzo dużo wiedzą o machine learningu, znają bardzo dobrze teorię, wiedzą, jakie są algorytmy, ale gorzej u nich jest z programowaniem. Jeśli trzeba coś już zakodować, to jest ciężko. Dla takich badaczy, researcherów to też AutoML jest narzędziem, które pozwala robić rzeczy, których nie umieliby, nie mogliby zrobić, bo nie mają takiej wiedzy programistycznej. Nie oszukujmy się, żeby budować modele machine learningowe, trzeba umieć kodować w jakimś stopniu.

W pierwszej grupe wyróżniły się dwie podgrupy czyli grupa biznesowa, która nie ma wiedzy o ML i w programowaniu oraz grupa, która programować umie, ale nie ma wiedzy o uczeniu maszynowym. W tym przypadku te braki fajnie można uzupełnić poprzez taką platformę. Po prostu umiesz coś zakodować, przygotować dane, bardzo dobrze poukładać te wszystkie rzeczy, a potem to wrzucasz do maszynki, która to przemieli. 

Już kilkanaście razy pojawiło się hasło MLJAR – porozmawiajmy teraz o tym dokładniej. Mówi się, że istnieje klasyczne uczenie maszynowe i nieklasyczne, czyli deep learning. Dla mnie klasyczny machine learning to praca z danymi strukturyzowanymi czyli tabele, kolumny, wiersze. Nieustrukturyzowane dane to są obrazki, dźwięki, tekst (choć tekst jest czasem na pograniczu). Z tego co wiem, MLJAR zajmuje się właśnie danymi ustrukturyzowanymi. Proszę powiedz, jaki jest kontekst, czy to jest decyzja zależąca od czegoś, czy tak się po prostu złożyło? 

Tych danych ustrukturyzowanych w firmach wydaje mi się, że jest więcej niż danych nieustrukturyzowanych. Większość danych siedzi w jakichś bazach danych, w tabelkach. W większości po prostu pracuje się w tych danych ustrukturyzowanych i dlatego ja też z takimi danymi najczęściej pracowałem.

Może dlatego ten problem zaatakowałem jako pierwszy. Po drugie może on jest trochę prostszy niż deep learning. W deep learningu, żeby zbudować dobry model, to naprawdę trzeba dużo różnych architektur sprawdzić, potrzeba dużo czasu na trenowanie modeli, jest bardzo dużo hiperparametrów. Wydaje mi się, że deep learning też jest trudniejszy niż taki klasyczny machine learning. Jest taka dziedzina, która się zajmuje badaniem algorytmów do szukania optymalnych architektur dla sieci neuronowych tj. NAS (Neural Architecture Search) i w sumie te badania są prowadzone. Nie ma jednego takiego złotego algorytmu, który pozwoliłby na znalezienie optymalnej architektury dla sieci neuronowej w rozsądnym czasie przy użyciu rozsądnej mocy obliczeniowej. Może dlatego na początku zająłem się klasycznym machine learningiem.

Mam w planach dodanie deep learningu do MLJARa, tylko nie chciałbym szukać architektur sieci neuronowych od nowa. Raczej myślałem o transfer learningu czyli o braniu sieci neuronowej, która już jest nauczona np. przygotowana do klasyfikowania obrazów i douczaniu tej sieci na danych klienta. Wtedy wydaje mi się, że ten deep learning można by było dostarczyć ludziom w prostej postaci i nie wymagałoby to wtedy bardzo dużych mocy obliczeniowych. 

Z takich ciekawostek mogę powiedzieć, że jest rozwiązanie Google dostępne w Google Cloud do budowania modeli machine learningowych czyli AutoML Google’a, który działa na danych strukturalnych. W tym rozwiązaniu Google równolegle używa 96 serwerów do szukania tej optymalnej architektury. 96 serwerów chodzi jednocześnie, żeby znaleźć optymalny algorytm, więc moim zdaniem to jest bardzo duża moc obliczeniowa.

Bardzo nieefektywne to jest, bo prawie 100 komputerów chodzi jednocześnie to jest to ogromna moc obliczeniowa, gdzie możemy wziąć XGBoosta na jednym komputerze i w 95% przypadków ten wynik będzie porównywalny albo lepszy. Także deep learning automatyczny nie jest jeszcze efektywny. Mam nadzieję, że w przyszłości będzie.

Efektywność AutoML

Porozmawiajmy o efektywności AutoML. Mówiłeś m.in. NAS – poszukiwanie sieci przy pomocy sieci. Tam ciekawe liczby się pojawiły. W którymś z rozwiązań one się liczyły na 500 GPU przez 4 dni, więc całkiem ciekawy mają apetyt chłopaki w Google. Wracając do naszego podwórka, wspomniałeś, że jak wrzucasz coś do MLJAR na 8 godzin, to potem jesteś prawie pewny, że jest OK.

Spróbujmy sobie zdefiniować, co to znaczy pracować z AutoML tak, żeby wybrzmiały namacalne liczby. Nie mówimy teraz o skali Google tylko raczej coś mniejszego, ale fajnie żeby był jakiś przykład – np. bierzemy problem, w pierwszym kroku definiujemy same dane, później przygotowujemy je czyli czyścimy, integrujemy, łączymy itd. Później dane mamy przygotowane i teraz fajnie, by wybrzmiał jakiś konkretny przykład, ile mamy tam wierszy, np. milion albo 100 tys. wierszy i wrzucając taki zbiór do MLJARa, włączamy na X godzin i czego możemy się spodziewać?

O, ciężko. To jest tak jak z szacowaniem, ile zarobimy na machine learningu w firmie. Ale spróbujmy. Weźmy np. marketing. Chcemy robić lead scoring w marketingu, czyli mamy kontakt do jakiegoś klienta i chcemy stwierdzić, czy ten kontakt to gorący lead czy zimny. W przypadku lead scoringu z mojego doświadczenia powiedzmy, jak mamy 50-100 próbek, to można budować prosty model machine learningowy.

Przy czym jak tych próbek jest bardzo mało, to ja bym się nie pchał w bardzo skomplikowane, złożone modele, Ensemble złożonego ze 100 modeli, bo to na pewno będzie overfit. Raczej starałbym się budować prosty model czyli np. jakieś drzewko decyzyjne – w AutoML bym ustawił uczenie na 5 albo 10 minut i AutoML sobie poradzi. Długością uczenia AutoML’a można kontrolować złożoność tego końcowego modelu, bo jeżeli powiemy do AutoML’a, że ma się uczyć przez 3 minuty, to on nie będzie miał czasu nabudować wielu modeli, a jak powiemy, że ma się uczyć przez 8 godzin, to tych modeli będą setki.

Wtedy końcowy model to pewnie będzie Ensemble czyli uśredniona (z wagami) odpowiedź zbiorowa z tych wszystkich modeli i wtedy będzie on złożony. Podsumowując, jeżeli tych próbek by było kilkadziesiąt, kilkaset, to ustawiłbym AutoML’a na uczenie w minutach (kilka, kilkanaście minut). Jeżeli by tych próbek było w tysiącach, to już bym AutoML’a ustawił na godzinę uczenia. Wtedy ten model powinien nie być za prosty, ale też nie być za bardzo złożony. Kilka tysięcy próbek to np. przewidywanie cen nieruchomości.

A jeżeli np. mamy dane finansowe i chcemy przewidywać, jaki będzie następny ruch na giełdzie i tych danych mamy kilkaset tysięcy (kilkaset tysięcy wierszy i parę tysięcy kolumn), to wtedy bym puścił AutoML’a co najmniej na 8 godzin (może nawet na 24 albo 48 godzin).

Rozumiem, że to wszystko zależy, ale chciałem, żeby też było zrozumiałe, że pewne rzeczy potrzebują trochę czasu, aby się rozpędzić. To nawet nie chodzi tylko o AutoML, bo nawet jak samego XGBoosta albo CatBoosta uruchomimy na większe próbki danych, to też trwa i to jest sam proces uczenia. AutoML jeszcze próbuje wiele różnych iteracji tam uruchomić pod spodem. 

Następna generacja AutoML

Jakie są tryby pracy MLJAR? W szczególności jeżeli chodzi o kolejny rozwój postępów w tej dziedzinie. Na blogu wspominasz o następnej generacji AutoML, więc prosiłbym Cię, abyś tutaj trochę rozwinął, jakie są tryby pracy i dokąd to dąży.

Na początku narzędzia do AutoML robiły w zasadzie dwie rzeczy, czyli brały jakiś algorytm i dobierały do niego hiperparametry. Z takich narzędzi można wymienić bibliotekę TPOT albo AutoWeka. Jak pisałem pierwszą wersję mojego AutoML, to też on robił w zasadzie te dwie rzeczy: wybierał algorytm i tuningował go, dobierał hiperparametry.

Z czasem się rozwijał i np. chciałem używać AutoML’a nie tylko po to, żeby wycisnąć maksa z danych, ale chciałem go użyć, żeby zbudować model, który będzie szybki do liczenia predykcji. Musi być dokładny, ale też szybki. Przez to, że jest to dodatkowe ograniczenie, że ten model musi być szybki, to nie mogę zbudować zbiorowego np. klasyfikatora, który ma w sobie 100 modeli, tylko ten model to powinien być jeden algorytm albo jakiś mały ensemble, np. zbudowany z pięciu modeli.

Takie ograniczenie, że model musi być szybki, jest często potrzebne, gdy chcemy umieścić ten model na serwerze, bo chcemy wysłać próbkę na serwer, a ten policzy nam predykcję i zwróci wynik. Jeżeli ten model będzie np. liczył jedną predykcję przez 15 minut, to będziemy potrzebowali bardzo dużą maszynę, żeby liczyć taką predykcję. Jak będziemy potrzebowali bardzo dużą maszynę, to automatycznie będzie nas to bardzo dużo kosztowało. A jeżeli np. pójdziemy na taki kompromis, że użyjemy modelu, który jest np. 1% słabszy w accuracy, ale 10-20 razy szybszy i liczy predykcję w milisekundach to zaoszczędzimy bardzo dużo na serwerach, na tym modelu, trzymając go w produkcji. To był jeden z takich problemów. 

Miałem użytkownika, który budował model machine learningowy do wyznaczania cen nieruchomości w Kolumbii. On się zgłosił do MLJAR’a i mówi: „słuchaj, wszystko fajnie, modele są naprawdę dobre, ale za długo liczą tę predykcję. My byśmy chcieli, żeby one były szybsze”. Wtedy dodałem nowy tryb pracy w MLJAR, który pozwala ograniczyć czas potrzebny do policzenia predykcji. 

Jeden tryb pracy w AutoML nazywa się „Compete” i on daje najlepszy performance i nie zwraca uwagi na to, jak długo się liczą predykcje, tylko jego priorytetem jest to, żeby finalny wynik był jak najlepszy. 

Drugi tryb pracy to jest „Perform” i polega na tym, że szukany, finalny model jest bardzo dokładny, ale liczy predykcję w określonym czasie. 

Trzeci tryb pracy to jest „Explain”. Jest to taki tryb, który wyjaśnia dane za pomocą machine learningu i nie jest on nastawiony na to, żeby uzyskać jak najlepsze wyniki, tylko jest raczej ustawiony na to, żeby jak najwięcej powiedzieć Ci o Twoich danych. W tym trybie np. jest liczony feature importance dla każdego modelu, który potem może być zestawiony i użytkownik może zobaczyć, które cechy są istotne. Liczone są explanations za pomocą pakietu SHAP. Wizualizowane są np. drzewa decyzyjne. Ten trzeci tryb wyjaśnia dane za pomocą modeli machine learningowych. 

Niedawno dodałem czwarty tryb pracy w MLJAR – „Optuna”, który używa frameworku Optuna to optymalizacji hiperparametrów. W tym trybie finalny model jest bardzo mocno stuningowany pod względem hiperparametrów, które są dobierane za pomocą frameworku Optuna. Jak tryb „Compete” szuka dobrych modeli i działa z określonym budżetem czasu i przestrzega tego budżetu na liczenie, to jeżeli mu powiemy, żeby liczył 8 godzin, to on będzie liczył 8 godzin. Tak w trybie „Optuna”budżet czasu nie jest przestrzegany tak sztywno. Najważniejszy jest po prostu wysoko stuningowany model. 

Przez to, że to są różne tryby pracy AutoML’a, to każdy człowiek szuka czegoś innego. Jeżeli jestem MLOps’em to chciałbym model, który jest szybki. Jeżeli jestem researcherem, to prawdopodobnie bym chciał jak najwięcej wyjaśnień moich danych. Te tryby wyszły tak samoczynnie, bo każdy szuka czegoś innego. Ktoś chce bardzo dokładny model, inny chce szybki model, a jeszcze inny chce po prostu informacje o danych – stąd te tryby. Mi się wydaje, że to będzie właśnie w tym kierunku szło, że AutoML będzie wielozadaniowy. To nie będzie tak, że: „zbuduj tylko model, nic więcej, żeby Cię nie obchodziło”, tylko on będzie się starał jak najwięcej powiedzieć o danych, jak najwięcej wyjaśnić. 

Powróżmy trochę o przyszłości, ale może też da się to zrobić w miarę bazując na faktach. Czego możemy się spodziewać w najbliższych 5, 10, 15 latach w kierunku AutoML? Możesz się odnieść wprost do MLJAR’a. 

Pierwsza wersja MLJAR’a była dostępna przez przeglądarkę. To jest taki płatny serwis. Ja go zbudowałem w 2017 r., działa do dziś. Jak zbudowałem ten serwis, to powiem Ci, że byłem zawiedziony. Byłem smutny, bo doszło do mnie, że ja tylko rozwiązuję jeden jakiś tam wybrany problem budowania tego modelu, a tak naprawdę to tych problemów przy budowaniu systemu, który wykorzystuje machine learning, jest bardzo dużo. Te dane trzeba znaleźć, złączyć, wyczyścić. Zacząłem wtedy szukać pomysłów, co tu zrobić dalej.

Powiem Ci, że tak z 3 lata utknąłem i nie wiedziałem, co dalej dodać do AutoML, żeby był uniwersalny, pozwalał jak najwięcej problemów rozwiązywać. Wydaje mi się, że w tym momencie chciałbym iść w kierunku nie tylko AutoML’a, ale takiej ogólnej platformy do robienia data science, która nie wymagałaby specjalistycznej wiedzy, umiejętności programowania, ale pozwalałaby manipulować danymi, łączyć dane z różnych źródeł, a potem używać AutoML’a do budowania modeli machine learningowych i wykonywania jakichś analiz.

Są takie narzędzia wizualne jak np. RapidMiner, gdzie można z bloczków budować data flow do analizy danych. Tylko chciałbym połączyć takiego RapidMinera z Jupyter Notebook, czyli żeby te bloczki to były tak naprawdę kawałki kodu. Także jeśli chodzi o MLJAR, to chciałbym iść w kierunku ogólnej platformy do data science.

Jeśli chodzi zaś o kierunki rozwoju dla AutoML tak ogólnie, to mam nadzieję, że pojawią się algorytmy do efektywnego, szybkiego, taniego szukania wydajnych architektur dla sieci neuronowych i że każdy będzie mógł stworzyć swoją własną sieć do swojego zadania. To by było duże osiągnięcie.

I nie potrzebuje do tego 500 GPU na przykład.

Tak. Rozwiązania np. Google –  jeżeli to potrzebuje 100 serwerów, to użytkownik za te 100 serwerów musi zapłacić. A 100 serwerów kosztuje 100 razy więcej niż jeden. 

Prosta matematyka, zgadza się.

Dzięki wielki za rozmowę i podzielenie się swoim doświadczeniem. AutoML będzie gryźć swoją niszę, jeżeli chodzi o cały proces i część rzeczy robi po prostu dobrze i na ten moment można to wykorzystywać. Różne role z tego mogą skorzystać, więc fajnie by też ludzie, którzy pełnią dane role wiedzieli o tym, bo to jest wygodne i korzystne. Trzymam kciuki, aby udało Ci się rozwinąć w szerszym kierunku, taka data science platform. 

Dzięki jeszcze raz i do usłyszenia.

Ja również dziękuję.

Jak już skończyliśmy nagrywać, porozmawialiśmy jeszcze z Piotrkiem o innych tematach. Piotrek ma sporo różnych pomysłów, co tu można jeszcze usprawnić, jak można jeszcze podziałać. Bardzo ciekawe to jest. Fajnie się rozmawia z ludźmi, którzy mają energię do życia, chcą działać i wdrażać to w praktyce, więc życzę Piotrkowi, aby wszystko mu się udało. 

Mam nadzieję, że udało nam się w tej rozmowie wyjaśnić temat AutoML. Podsumowując, mówiliśmy o tym, że standardowy proces machine learning składa się z poszczególnych kroków. 

Pierwszy krok

Postawienie celu i ten krok jest najtrudniejszy, jeżeli chodzi o automatyzację. Nie da się go zautomatyzować, przynajmniej w tym momencie. Chyba, że to będzie transfer wiedzy, tzn. mamy rozwiązany konkretny problem i możemy w jakiś sposób próbować skopiować ten problem w inny. Z drugiej strony – mamy zbiór danych A i zbiór danych B i są one w miarę podobne, to możemy nałożyć jakąś heurystykę i próbować to połączyć. Ale to jest z dużą gwiazdką. Ten pierwszy krok jest bardzo mocno ludzki.

Drugi krok

Przygotowanie danych do trenowania. Tutaj jest częściowa możliwość automatyzacji, ale nadal jest bardzo dużo czynności jak czyszczenie danych, łączenie ich, praca z danymi, ich analiza. Wychodzą na tym etapie różne problemy np. takie z myleniem jednostek – wskazanie wieku osoby jako 150 lat, czy przytoczony przeze mnie przykład 4 łazienek w 30-metrowym mieszkaniu. Bardzo potrzebne jest krytyczne myślenie człowieka i jak na razie takie podejście automatyczne tutaj nie za wiele może dać.

Z drugiej strony mamy feature engineering albo feature selection. Częściowo to już można zautomatyzować, a mianowicie taką bardzo prostą rzecz, kiedy kombinujemy cechy w sposób powtarzalny, np. jak mamy jakieś numeryczne cechy to możemy na nich wykonywać różne matematyczne działania i to możemy robić automatycznie. Nadal jednak pozostaje cały obszar, którego nie da się zautomatyzować, bo tu jest potrzebny spryt ludzki. Zresztą pokazuję na kursie, jak np. przerabialiśmy związane z tematem chociażby prognozowanie cen nieruchomości albo prognozowanie cen samochodu.





To są rzeczy, które da się zautomatyzować, ale są takie, które wprost polegają na tym, aby w tych danych pogrzebać i wyciągnąć wniosek. Ten problem ciężko uogólnić nie dlatego, że model nie potrafi np. popatrzeć na mapę, tylko konkretnie w tym przypadku trzeba popatrzeć na mapę, a konkretnie w innym przypadku trzeba popatrzeć na coś innego. Innymi słowy to jest tak, że zawsze powiązanie, co zrobić z daną informacją może być inne. Przez to ciężko się uogólnia. 

Trzeci krok w ML to jest modelowanie czyli w tym przypadku różne algorytmy, modele, dobór parametrów. To jest akurat ta przestrzeń, w której faktycznie już wiele się automatyzuje np. jeżeli chodzi o hiperparametry czy dobór takich zewnętrznych parametrów, które wpływają na to, jak model działa. Np. ustawiamy jedne parametry, potem następne i na ich skutek model zwraca inne wyniki.

Takie zewnętrzne parametry nazywają się właśnie hiperparametrami. Tu akurat myślę, że blisko 100% jest zautomatyzowane i to jest dobrze. Człowiek może nie marnować swojego czasu. A jeżeli chodzi o wybór modelu, to tak naprawdę każdy w miarę zaawansowany programista zna pętle for. Zwykłe iterowanie tych modeli, to jest też automatyczne podejście. Tylko w przypadku AutoML jest trochę więcej różnych rzeczy dołożonych, więc to jest nieco wzbogacona pętla for. Konkretnie ten trzeci krok – trenowanie modelu faktycznie w tej chwili wybrzmiewa jako krok, który da się mocno zautomatyzować. 

Jeżeli chodzi zaś o wdrażanie, to tutaj różnie bywa. Z jednej strony nadal mamy przestrzeń, w której brakuje pewnych narzędzi. Z drugiej tych narzędzi powstaje coraz więcej i są pewne podejścia, które umożliwiają to wdrażać coraz lepiej. Osobiście powiem jako osoba, która wdraża modele, że nadal czuję, że ten czwarty krok czyli wdrażanie jest dość mocno nieustabilizowany.


Na przecięciu software engineering i ML engineering są różne luki. Zresztą jak poszukasz informacji o startupach, które powstają w ostatnim czasie związanych z ML, to możesz sobie zobaczyć, jak dużo startupów powstaje właśnie w temacie deployment. Kiedyś ktoś mnie zapytał czy to faktycznie jest tak duży problem? Tak, problem jest aż tak duży. Tylko ja zapytałem inaczej – czy te startupy rozwiążą te problemy? Też jestem ciekaw. Więc tutaj też w tej chwili automatyzacja jeszcze nie jest aż tak bardzo zrobiona. 

Powiem też taką ciekawostkę a propos jednej firmy, z którą współpracowałem. Zanim zacząłem z tą firmą współpracować, wrzucili do AutoML swój problem i polegli. Otrzymany wynik był bardzo słaby. Potem przyszliśmy my, zrobiliśmy kilka magicznych rzeczy jako ludzie, którzy się na tym znają.

Wynik był taki, że my po prostu mocno pogrzebaliśmy w danych. Wykryliśmy różne niespójności, świat zmienia się z czasem, więc informacje, które były kilka lat wstecz już są nieaktualne, ale model traktuje je jako fakty. Uzupełniliśmy te rzeczy. Też tam były różne importy, eksporty, różne cudowne rzeczy, które dzieją się w naszym życiu. To trzeba było jakoś obsłużyć manualnie.

A żeby to zauważyć, to trzeba było po prostu popatrzeć na dane i wyszukać anomalia. To jest taka rzecz, której jesteś pewny. Nie wiesz, co dokładnie będzie źle w danych, ale wiesz od razu, że będzie źle. To jest rzecz, którą człowiek może wychwytywać, o ile ma pewne umiejętności, ale ciężko to jest zautomatyzować.

Wierzę, że AutoML i podejście do automatyzacji będzie się rozwijało z czasem. Zgadzam się, że są takie działki związane z trenowaniem modeli i doborem parametrów, które w tej chwili dość mocno się zautomatyzowały i to będzie się rozszerzało. Może częściowo feature engineering będzie się rozszerzał.

Z drugiej strony uważam, żeby używać efektywnie AutoML, co najmniej warto przerobić pewne fundamenty. Dlatego bardzo gorąco Cię zapraszam na mój kurs online. Dzięki temu najpierw poznasz te podstawy i fundamenty, a później, jak będziesz rozumieć, jak to działa bardziej pod spodem, to będziesz w stanie pewne rzeczy przyspieszyć. Zrobisz to świadomie, bo wiesz, że możesz to zrobić manualnie, tylko chcesz po prostu przyspieszyć. Takie podejście pozwoli Ci uniknąć wielu błędów i będziesz bardziej świadomy tego, co robisz.

Bardzo dziękuję za wspólnie spędzony czas. Czekam na Twoje przemyślenia, informację zwrotną. Na koniec mam taką prośbę – podziel się tym odcinkiem przynajmniej z jedną osobą, dla której może być ta informacja pomocna. 

Posłuchaj 100 odcinka podcastu Biznes Myśli lub przeczytaj artykuł na temat „Zimy AI”. Czy nadejdzie? Czy należy się jej bać? Jakie jest Twoje zdanie na ten temat?

Artykuł AutoML: możliwości i wyzwania pochodzi z serwisu Biznes Myśli.

Sztuczna inteligencja znajduje swoje zastosowanie w wielu dziedzinach. Tym razem poruszę temat robotyzacji. Mój gość, Marek Cygan z Nomagic, opowie o oprogramowaniu przygotowywanym w specjalnym projekcie, a także o możliwościach, jakie niesie wykorzystanie sztucznej inteligencji w tym obszarze.

Cześć Marek. Przedstaw się: kim jesteś, czym się zajmujesz, gdzie mieszkasz.

Cześć. Nazywam się Marek Cygan. Pracuję w firmie Nomagic oraz na Uniwersytecie Warszawskim. Pracuję w Warszawie, natomiast mieszkam również w Toruniu. 

Co fajnego ostatnio przeczytałeś i dlaczego uważasz, że jest to warte polecenia?

To zależy, o jakiego typu książkach mówimy. W zakresie zarządzania zespołem polecam „Radical Candor” autorstwa Kim Scott oraz „What You Do Is Who You Are” Bena Horowitza – związana z prowadzeniem startupów, bardzo polecam. Natomiast jeśli chodzi o książki mniej związane z pracą, to czytałem „Homo deus” Yuval Noah Harari – również polecam.

Dzięki za polecenia, bardzo ciekawe pozycje. Wspomniałeś, że pracujesz w Nomagic. Tak naprawdę zajmujesz się wieloma rzeczami i masz sukcesy w różnych obszarach, ale zacznijmy od Nomagic. Czym się zajmujecie?

W Nomagic zajmujemy się robotyką. Natomiast to nie jest bardzo szeroka robotyka. Interesuje nas aplikowanie najnowszych osiągnięć uczenia maszynowego w robotyce, aby stworzyć usługę, z której będą mogli korzystać nasi klienci. Mówiąc usługę mam na myśli to, że nie budujemy robotów w naszym laboratorium.

Kupujemy roboty i produkujemy dla nich oprogramowanie, które korzysta z metod sztucznej inteligencji, przetwarzania obrazów i różnych innych nowoczesnych technologii. Wdrażamy następnie te roboty u klientów, a one wykonują dla nich konkretne usługi. W tej chwili działamy w segmencie logistycznym. To są duże magazyny przeładunkowe głównie firm z handlu internetowego. 

Wybraliście robotykę i jedno zagadnienie z tego obszaru. Dlaczego akurat robotyka?

W momencie, w którym zaczynaliśmy naszą przygodę (działo się to już ponad 3 lata temu), skontaktował się ze mną Kacper Nowicki. Bardzo chciał założyć startup w Warszawie. Zastanawialiśmy się, jaka mogłaby być dziedzina, w której użyjemy metod uczenia maszynowego. Punktem wyjścia było to, że chcieliśmy użyć najnowszych osiągnięć w dziedzinie uczenia maszynowego tak, żeby mieć komercyjny produkt. Mam tutaj na myśli konkretnie produkt, a nie projekt.

Nie chcieliśmy tworzyć firmy, która zajmowałaby się wykonywaniem konsultacji czy konkretnych projektów pod klientów. Nie pojedyncze przedsięwzięcia, lecz zunifikowany produkt, który można sprzedawać w wielu egzemplarzach. Chcieliśmy zbudować w ten sposób firmę, która ma szansę się rozwijać do bardzo dużych rozmiarów. 

Żeby wybrać rynek, na którym taki produkt może zaistnieć, trzeba wziąć pod uwagę bardzo wiele czynników. Głównym czynnikiem dla nas była konkurencja dużych firm, które mają bardzo wiele danych. Jeśli spojrzymy na zagadnienia, które można wykonywać przy przetwarzaniu obrazu, dźwięku to Google czy Facebook mają ogromne ilości danych.

Uznaliśmy, że bardzo ciężko byłoby nam konkurować z nimi na tym konkretnym rynku. Szczególnie że w momencie, w którym prowadziliśmy nasze rozważania (2016 r. lato), te przełomowe wyniki w uczeniu maszynowym, przetwarzaniu obrazów już się wydarzyły parę lat wcześniej. Była duża szansa, że bylibyśmy spóźnieni próbując zakładać firmę w tej konkretnie dziedzinie.

Tak się zdarzyło, że niezależnie Kacper i ja natknęliśmy się na prace (artykuły naukowe publikowane przez grupę z Google Brain i inne grupy badawcze), które wykorzystywały uczenie maszynowe w robotyce. Obu nas te metody bardzo zainteresowały. Zaczęliśmy się zastanawiać, co można z tym zrobić. 

Na początek, zebraliśmy parę osób, które chciały zreprodukować wyniki jednej z takich prac po to, żeby nauczyć się jak te metody działają i czy jest to coś, co nas interesuje. Zebraliśmy zespół 5-6 osobowy, przy czym to było takie założenie, że każdy z nas będzie się tym zajmował tylko przez 20% swojego czasu. Ja pracowałem wtedy na Uniwersytecie, a Kacper pracował w innej firmie w Berlinie.

Osoby, które do nas dołączyły, też miały albo pracę, albo studia. Posuwaliśmy się dość powoli, ale stabilnie do przodu. Po paru miesiącach takiej pracy uznaliśmy, że jest to dla nas na tyle interesujące, że chcemy się tym zająć na poważnie. W związku z tym, że pracując w tempie odpowiadającym poświęcaniu 20% czasu poruszaliśmy się stosunkowo wolno, to uznaliśmy, że albo robimy to na poważnie, albo wcale.

Wtedy zdecydowaliśmy, że chcemy założyć firmę. To był marzec 2017 r. Ustaliliśmy, że będzie to kwestia około kwartału, aż założymy formalnie spółkę i znajdziemy pierwszych pracowników. Formalnie otworzyliśmy biuro w czerwcu 2017 r. 

Ciekawa przygoda. Nakreślmy aktualną sytuację w obszarze robotyzacji. Jakich metryk się używa i jak mierzy się stopień zautomatyzowania danego społeczeństwa? Jak należy to interpretować?

Standardową miarą używaną do oceny stopnia robotyzacji danego społeczeństwa jest gęstość robotów w przeliczeniu na 10 tys. pracowników. Czyli dla średniej grupy 10 tys. pracowników, ile wśród nich jest robotów? Używając takiej miary za rok 2018 w Polsce robotów było 42.

W poprzednich latach były to odpowiednio mniejsze ilości. Dla porównania, średnia gęstość robotyzacji na świecie, wynosi 99 (czyli ponad dwukrotnie więcej niż w Polsce), dla Europy – 114. To są dane za rok 2018, nie widziałem jeszcze raportów za rok 2019. Jeśli mówimy o tej metryce, to tutaj jest bardzo istotna kwestia, dlatego że w poszczególnych branżach ten stopień zrobotyzowania musi być diametralnie różny.

Prym wiedzie przemysł motoryzacyjny. W Polsce, tak jak gęstość robotów wynosi 42, to w sektorze motoryzacyjnym to już jest 190. Czyli jest ponad pięciokrotnie większa gęstość w tym sektorze. Jest to taki współczynnik, który tak samo stosuje się na świecie, tzn. w sektorze motoryzacyjnym w niektórych krajach ta liczba robotów na 10 tys. pracowników, przekracza nawet 1 tys.

Natomiast jeśli chodzi o gęstość robotyzacji nie tylko w motoryzacji ale ogółem, to nasza liczba w Polsce to jest 42. Tutaj wypadamy słabiej niż inne kraje regionu typu Słowacja, Czechy. Tam te liczby oscylują w okolicach 150. Wynika to też z faktu, że w tym obszarze przemysł motoryzacyjny jest proporcjonalnie dużo większy niż w Polsce (nawet w liczbach bezwzględnych jest większy, a w przeliczeniu na liczbę pracowników, to już jest dużo większy).

Natomiast globalnie liderem robotyzacji jest Singapur, gdzie liczba robotów na 10 tys. pracowników, przekracza 800. Niemcy przekroczyli 300, a średnia dla świata to około 100. 

Temat robotyzacji jest pełen mitów. Jeżeli dołożymy do tego tzw. science-fiction, który się łączy i przecina, ludzie czasem się gubią, nie wiedzą, gdzie jesteśmy teraz i jak to się posuwa. Na przykład, słynny robot od firmy Boston Dynamics, który potrafi robić przeróżne cuda, skakać, biegać i robić obroty w bardzo niestandardowy sposób. Jak to oglądasz, to czujesz, że ten terminator już jest coraz bliżej.

Z drugiej strony istnieje taka inicjatywa zorganizowana przez Darpa – Darpa Robotics Challenge. Na zadaniach w tym projekcie roboty z Boston Dynamics nie wyglądają już tak efektywnie i skutecznie. Tu od razu się przypomina tzw. Paradoks Moraveca, gdzie czynności, które dla człowieka wydają się proste, dla robota nagle okazują się niesamowicie skomplikowane i bardzo trudne w rozwiązaniu.

Człowiek nawet nie jest w stanie sobie uświadomić, dlaczego tak się dzieje, że te inputy, które docierają do nas (w szczególności przez kanały marketingowe), z jednej strony wyglądają tak, że roboty już potrafią robić takie cuda, a z drugiej strony tak naprawdę jest za daleko, żeby stwierdzić, że ten robot już będzie się zachowywać jak terminator, którego wrzucasz na dowolny teren w mieście i będzie wchodzić np. do budynku, szukać odpowiedniego pomieszczenia, otwierać właściwe drzwi. To może być duże wyzwanie.

Dlaczego są tak duże zróżnicowania i gdzie faktycznie jesteśmy teraz?

Główny problem polega na tym, że w świadomości ludzkiej nie mamy zrozumienia, jak trudne obliczeniowo problemy nasz mózg jest w stanie rozwiązywać bardzo szybko – problemy związane głównie z przetwarzaniem tego, co widzimy, planowaniem naszych ruchów, reagowaniem na bodźce.

Nasz mózg metodą ewolucji został dostosowany i jest bardzo efektywny pod tym względem. Robi na nas wrażenie, jak komputer potrafi mnożyć liczby, które mają miliony czy miliardy cyfr, natomiast nie potrafimy zrozumieć, jak to jest, że przez długi czas komputer nie był w stanie rozpoznać, czy na zdjęciu jest kot czy pies.

Tego typu problemy potrafimy niezawodnie rozwiązywać dopiero od kilku lat. Jeśli chodzi o roboty, to tutaj takim przykładem jest robot Atlas z firmy Boston Dynamics. Ten robot potrafi wykonać np. salto do tyłu i się nie wywrócić, co wygląda bardzo efektownie. W momencie, w którym ten robot ma wykonać jakieś zadanie, w którym ma się odnaleźć w środowisku i wykonać jakąś konkretną akcję (doprowadzić do jakiegoś określonego rezultatu), to sprawa wygląda dużo trudniej. 

Robot musi umieć odnaleźć się w środowisku, którego nie zna. Właśnie ta umiejętność odnajdywania się i działania w zmiennym środowisku jest bardzo trudne. Jest to ciężkie do zrozumienia. Związane jest to z tym, że sposób, w jakim komputer przetwarza obrazy, polega na przetwarzaniu wszystkich pikseli danego obrazu.

To, jak te piksele kodują dany obraz, bardzo się zmienia w zależności od oświetlenia, ustawienia. Niezwykle trudno jest opracować metody, które potrafią rozpoznawać obiekty niezawodnie w bardzo różnorodnych warunkach. 

Przez wiele lat dominowały ręczne metody przetwarzania obrazów. Można o tym myśleć jak o różnych filtrach, które stosuje się w programach do cyfrowej obróbki zdjęć. W ostatnich latach tę dziedzinę zdominowały metody opierające się na trenowaniu modeli. Oznacza to, że zbieramy dane np. kilka milionów zdjęć i wiemy, co na każdym z nich się znajduje.

Czy na tym zdjęciu jest kot, pies czy jakiś inny obiekt. Dla każdego zdjęcia, musimy zapisać sobie tę informację. Potem konstruujemy sieć neuronową, tj. taki matematyczny obiekt, który ma w sobie masę parametrów. O takiej sieci neuronowej można myśleć jako o ciągu wykonywanych operacji na tych obrazach. Tak jak mamy różne efekty w programach do obróbki zdjęć, np. wykrywanie krawędzi, przyciemnianie, rozmazywanie.

Okazuje się, że jeśli złożymy ze sobą odpowiednio dużo tego typu transformacji i użyjemy w nich odpowiednich parametrów, to na końcu będziemy w stanie uzyskać odpowiedź, czy na danym zdjęciu jest kot, pies czy inny obiekt. Natomiast znalezienie tych parametrów jest bardzo trudne, bo w sieci neuronowej potrafi ich być od kilku milionów do kilku miliardów. 

Żeby poprawnie ustawić te wszystkie parametry w sposób automatyczny (ręcznie jest to niemożliwe do zrobienia) metodami optymalizacji (które za pomocą algorytmów komputerowych poprawiają te parametry z każdym krokiem uczenia naszej sieci), musimy dysponować odpowiednią mocą obliczeniową i odpowiednio dużymi zbiorami danych.

Dopiero od kilku lat te trzy rzeczy jednocześnie są dostępne, czyli odpowiednio duża moc obliczeniowa, odpowiednio duże zbiory danych, odpowiednie algorytmy i modele matematyczne, które są w stanie te problemy rozwiązywać. Połączenie tych trzech składników pozwala rozwiązywać problemy przetwarzania obrazów. Natomiast jeżeli chodzi o samego robota, to robotyka to dużo więcej niż przetwarzanie obrazu. 

Jak wchodzimy do pokoju i chcemy np. napić się kawy, to nie jest tak, że wchodzimy do pokoju, oglądamy cały pokój, lokalizujemy, gdzie jest czajnik, kubek, po czym zamykamy oczy i idziemy w ciemno w to miejsce nie reagując na bodźce. Robotyka bardzo długo w ten sposób działała, że w momencie pojawienia się odpowiednich metod przetwarzania obrazów, robot zbierał obrazy z otoczenia, próbował wymodelować całe otaczające go środowisko, po czym planował swoje akcje.

To tak jakbyśmy weszli do pokoju, rozejrzeli się dookoła i zaplanowali sobie, że musimy zrobić 5 kroków do przodu, obrót w prawo, dwa kroki do przodu, otworzyć górną szafkę, wyciągnąć kubek. Ten robot robi to często z zamkniętymi oczami i nie kontroluje tego, czy znajduje się w miejscu, w którym myślał, że będzie się znajdował. Nie kontroluje tego, czy środowisko się zmieniło albo czy w pierwotnej ocenie sytuacji pojawił się błąd.

Dopiero w ostatnich 2 latach pojawiły się artykuły o robotach sterowanych w tzw. układzie zamkniętym, czyli takim gdzie reagujemy z odpowiednią częstotliwością – np. 10 razy na sekundę uaktualniamy nasz plan w zależności od tego, co widzimy dookoła. 

Jest jeszcze jeden duży, nierozwiązany problem – w jaki sposób poradzić sobie ze zmysłem dotyku? Jest to kolejny zmysł ludzki, którego nie umiemy jeszcze wykorzystać w robotach. Umiemy wykryć, że nastąpił kontakt z otoczeniem, natomiast bardzo trudno jest w sposób elastyczny dostosować się do otoczenia na podstawie doświadczanego kontaktu z otoczeniem. Szczególnie jeśli przedmioty, z którymi mamy do czynienia, są miękkie i potrafią się deformować. 

Wracając do początku firma Darpa ogłosiła konkurs Darpa Robotics Challenge, który trwał między 2012 r., a 2015 r. W ostatnim roku trwania tego konkursu zadaniem była ewakuacja z budynku. Robot miał wejść do budynku, co wiązało się z otwarciem drzwi, zlokalizowaniem zaworu, zamknięciem zaworu, wejściem po schodach i wyjściem z budynku.

Żaden robot nie był w stanie wykonać w pełni tego zadania. W Internecie możemy obejrzeć różne nagrania, w których te roboty w fascynujący sposób się wywracają. To jest ten sam robot – Atlas z firmy Boston Dynamics. Ten sam, który wcześniej potrafił wykonywać akrobatyczne sztuczki, nie potrafił wykonać prostego zadania, jakim było otwarcie drzwi. Pomimo tego że w ostatnich latach widzimy tutaj postępy, moim zdaniem nie zobaczymy robotów w życiu codziennym w ciągu najbliższych kilku lat, gdyż te roboty najpierw będą się pojawić w takim segmencie jak logistyka.

W magazynach gdzie trzeba przetwarzać różne paczki albo pakować zamówienia w magazynach sklepów internetowych, gdzie zakres produktów jest bardzo szeroki sięgający nawet 100 tys. różnych produktów lub jak w przypadku największych magazynach Amazona – 1 mln produktów. Mówiąc o różnych produktach mam na myśli milion różnych kodów kreskowych. 

Ta różnorodność to jest coś, co powodowało, że robotów w logistyce było dużo mniej niż np. w sferze motoryzacyjnej. W sektorze motoryzacyjnym w momencie, w którym jest zbudowana linia budująca samochody, roboty będą budować dokładnie takie same samochody przez cały dzień i całą noc (nawet przez kilka lat z rzędu). Tutaj to środowisko się w ogóle nie zmienia. Roboty wykonują cały czas te same zadania.

Oczywiście robi to wrażenie, bo potrafią podnosić bardzo duże ciężary. Często muszą być zsynchronizowane ze sobą, czyli jest kilka robotów spawających dany fragment. Jak się na to patrzy, to robi to duże wrażenie, ale cały wysiłek był w synchronizowaniu tych robotów i ręcznym ustawieniu różnych parametrów, bo ten robot nie jest w stanie dostosować się do żadnych zmian w tym środowisku.

W momencie, w którym ktoś chciałby tego robota przesunąć nawet o 5 cm, to dużą część pracy trzeba wykonać od nowa, tak żeby wszystkie je zsynchronizować i ustawić. 

My w ramach Nomagic, wdrażamy nasze roboty w sektorze logistycznym (głównie w magazynach handlu internetowego) i na tym się skupiamy. Naszym celem jest wdrożenie 1 tys. robotów w ciągu 5 lat. Jest to bardzo ambitny cel, ale wierzę, że będziemy w stanie tego dokonać. 

Kolejnym obszarem, w którym moim zdaniem możemy zobaczyć roboty już wkrótce, jest bezpieczeństwo, monitorowanie przestrzeni, ochrona. Będą to roboty, które nie będą w stanie wchodzić w interakcje ze swoim otoczeniem (lub interakcja będzie bardzo ograniczona).

Będą to takie maszyny, które będą poruszać się po otoczeniu, skanować je w poszukiwaniu nieoczekiwanych zmian. W momencie, w którym te nieoczekiwane zdarzenia będą miały miejsce, będzie wzywany człowiek i to człowiek będzie reagował na te zdarzenia, gdyż ludzie bardzo dobrze reagują w nowych sytuacjach, a roboty niestety jeszcze nie. 

Bardzo ciekawa analogia z zamkniętymi oczami odnośnie do tego, jak działa robot. To faktycznie umożliwia znacznie lepiej zrozumieć, gdzie są wyzwania. Czasem jak ludzie wchodzą do pokoju, też zamykają oczy, jak idą po kawę. Różnie to się kończy i może być wyzwaniem, w szczególności jeśli środowisko zmienia się w czasie, np. ktoś otwiera szafkę. Ale to daje też do myślenia, na czym polega ta różnica. 

Powiedziałeś, że macie bardzo ambitne plany wdrożyć 1 tys. robotów w ciągu 5 lat. Czy już macie przynajmniej jednego robota wdrożonego?

Tak, dokonaliśmy już naszych pierwszych wdrożeń. Mogę powiedzieć, że naszym pierwszym klientem była francuska firma CDISCOUNT, tj. największa firma handlu internetowego we Francji obok Amazona. Jest to konkurent Amazona działający lokalnie na rynku francuskim. To był nasz pierwszy klient, z którym współpracowaliśmy już od lutego 2018 r. Nasz pierwszy robot był zainstalowany na jesieni 2018 r.

Od tamtego czasu robot obsługiwał już prawdziwe zamówienia i pakował produkty dla klientów. Natomiast przez pierwszych kilka miesięcy robot był pod obserwacją, czyli cały czas jeden z naszych pracowników był obok tego robota i monitorował co robi, zbierał informacje, tak abyśmy mogli poprawić jego działanie. Weszliśmy w taki tryb produkcyjny, w którym ten robot wykonuje swoje działania w zadowalający sposób (kwiecień 2019 r.). To jest ten moment, kiedy moim zdaniem możemy mówić o pierwszym wdrożeniu.

Rozmawiamy teraz z kolejnymi klientami, ale nie mogę się podzielić szczegółami. Mogę powiedzieć, że koncentrujemy się na rynku europejskim – niemieckim, francuskim i sąsiednich regionach. W Polsce na wdrożenia jest jeszcze za wcześnie głównie z ekonomicznego punktu widzenia, tzn. koszty pracy w wymienionych krajach są dużo wyższe niż w Polsce. To powoduje, że opłacalność wdrożenia w tych krajach jest dużo wyższe niż w Polsce, więc skupiamy się w tej chwili tylko i wyłącznie na rynkach zagranicznych. 

Bardzo ciekawe. Pierwszy wdrożenie już działa. Jak natomiast wyglądał proces pracy przed jego pojawieniem się? Jeżeli jesteś w stanie wymienić liczby, to będzie jeszcze bardziej namacalne, czyli ile osób tam było zaangażowanych? Co dokładnie te osoby robiły? Jaka była ich wydajność w jednostce czasu (np. w ciągu doby, tygodnia)? Czy masz takie liczby?

Nie mogę wszystkiego dokładnie powiedzieć, ale mogę podzielić się informacjami na temat pierwszego wdrożonego robota. Tutaj nasz klient też jawnie prezentował nasze rozwiązania na konferencji, więc mogę o tym opowiedzieć (w tym o różnych liczbach, związanych z tym robotem). O kolejnych wdrożeniach niestety już nie będę mógł mówić. Wracając do naszego pierwszego wdrożenia dla firmy CDISCOUNT, jest to taka firma, w której na platformie internetowej klienci dokonują zamówień i potem te produkty są wysyłane pocztą czy kurierem do domów tychże klientów.

To, co się dzieje pomiędzy momentem zamówienia na stronie internetowej, a momentem, w którym paczka opuszcza magazyn, to kompletowanie zamówienia. Ono odbywa się w trzech fazach. Najpierw dany produkt musi zostać znaleziony na półce w magazynie, czyli jest osoba, która porusza się po tym magazynie (albo na piechotę, albo korzystając z jakiegoś wózka), zbiera produkty z półek i odkłada je do zbiorczego koszyka, w którym są produkty z bardzo wielu zamówień.

Potem taki koszyk trafia na kolejne stanowisko, gdzie produkty są sortowane. Koszyk wygląda mniej więcej tak, jak koszyki w supermarketach (z siatki metalowej) i jest w nim dość duży bałagan, gdyż te produkty są wkładane do nich bezpośrednio z półek. Kolejny etap to wyjmowanie tych produktów z koszyka i wkładanie do pudełek, które w trzecim etapie są automatycznie pakowane, oklejane i wysyłane do klientów. Zautomatyzowaliśmy etap drugi.

W momencie w którym do naszego stanowiska doprowadzony zostanie koszyk z produktami, robot będzie te produkty po kolei wyjmował, skanował ich kody kreskowe (aby zidentyfikować dany produkt i zamawiającego), pakował do kartonowego pudełka, które następnie będzie odkładane na taśmociąg. Tym taśmociągiem produkt jest dostarczany dalej do części, która już była wcześniej zautomatyzowana (czyli zamykanie pudełka, oklejanie), a następnie wędruje do firmy kurierskiej, która rozwozi te zamówienia.

Jeśli chodzi o to, jaka jest wydajność systemu, to tutaj mierzy się to liczbą przedmiotów, które ten system jest w stanie przetwarzać na godzinę. Przy czym ten parametr, bardzo mocno zależy od tego, co dokładnie robot ma robić. W tym przypadku koszyk, z którego produkty są wyjmowane jest duży (objętość ok. 1m3). Tutaj człowiek nawet nie pracuje zbyt szybko, bo trzeba produkty kolejno wyjmować, skanować kody kreskowe i odkładać do pudełka.

Takim punktem wyjścia była liczba między 200 a 250 przedmiotów na godzinę. Był to cel postawiony przez naszego klienta, a my go zrealizowaliśmy. Im szybciej robot pracuje, tym lepszą wydajność uzyskujemy i jest to zysk klienta w stosunku do tego, jakby na tym stanowisku pracował człowiek (mamy bardziej wydajne stanowisko). 

Tutaj też pojawia się oczywiście kwestia pomyłek. Jest bardzo istotnym, czy robot będzie wykonywał mniej czy więcej pomyłek niż człowiek. Jednym z problemów jest to, że trudno jest zmierzyć, ile dokładnie człowiek tych błędów popełnia. W tego typu magazynach znana jest globalna liczba pomyłek, tzn. ile przedmiotów zostaje zgubionych na całym etapie pakowania. Trudno jest o liczby dotyczące poszczególnego stanowiska, gdyż w tym celu musiałby być bardzo skrupulatny monitoring każdej części systemu, co często bywa nieopłacalne. 

My przekonujemy, że nasz system działa na poziomie tak dobrym jak człowiek. Mamy tutaj różne metody monitorowania, czy nasz system popełnił błąd. Jednym z takich błędów, których należy się bardzo wystrzegać, jest spakowanie dwóch przedmiotów zamiast jednego. Przedmioty potrafią się skleić ze sobą, jeden mniejszy potrafi się ukryć w drugim.

Nie zawsze są to prostopadłościenne opakowania, czasami są różne zabawki albo karty podarunkowe, elektronika i tutaj różne rzeczy mogą się ze sobą złączyć. Szczególnie jeśli mówimy o wydarzeniach, które mają miejsce raz na 1/1000 lub 1/10000 przypadków. Radzenie sobie i obsługa tego typu rzadkich przypadków jest największym wyzwaniem w całym naszym przedsięwzięciu.

Nawet jeśli nasz system będzie popełniał błąd 1/1000 razy (co wydaje się dość rzadko), to jeśli ten błąd powoduje, że np. robot byłby w stanie zniszczyć jakiś przedmiot (np. telefon komórkowy, który miał zostać wysłany do klienta) to szkody, które się pojawiają raz na 1 tys. powtórzeń, kompletnie niwelują całą pracę, którą robot wcześniej wykonał. Tutaj jest bardzo ważna obsługa rzadkich sytuacji. 

Kiedy kupowałem sobie MacBooka jakiś czas temu (w Polsce) to zamiast jednego, przyszły do mnie dwa. Ja akurat zwróciłem nadprogramowy, ale sklep nawet się nie zorientował. Musiałem pisać do nich e-maile i wytłumaczyć, że jestem wdzięczny za ich prezent, ale prawdopodobnie nie są świadomi tego, że wysłali mi dwa zamiast jednego.

Bardzo ciekawa sytuacja. Z naszego doświadczenia wynika, że raz na 1 tys. zdarzeń, tego typu rzecz może mieć miejsce. Jeśli jesteśmy w stanie to zdarzenie odpowiednio wcześnie wykryć, to można zapobiec wysłaniu tych przedmiotów do klienta. Można sobie wyobrazić, że strata tego typu produktu może być druzgocąca.

Z punktu widzenia technicznego to, czym się zajmujecie, brzmi w miarę prosto. Trochę upraszczając jest to taki computer vision: wystarczy zamontować kamerkę, rozpoznać obiekt, złapać go, przenieść w odpowiednie miejsce i do tego dochodzi ewentualnie samo uczenie computer vision. Czyli samo uczenie nadzorowane, a jeżeli to nie wystarczy, to ewentualnie możemy wziąć uczenie ze wzmocnieniem. Jednak jeżeli mówimy o takich praktycznych zastosowaniach a nie tylko prostych prototypach, to sprawa w życiu realnym jest znacznie bardziej skomplikowana. Dlaczego tak jest? Jak sobie z tym radzić? 

Nie mogę ujawniać wszystkich naszych sekretów, natomiast zarówno uczenie nadzorowane i uczenie ze wzmocnieniem to są metody, które stosuje się w robotyce obecnie. Bardzo istotnym komponentem jest radzenie sobie z rzadkimi sytuacjami, wykrywaniem anomalii. Kolejnym wyzwaniem jest to, aby robot poruszał się odpowiednio szybko, tak żeby dostosował swoje ruchy do przynoszonych przedmiotów.

Inaczej powinniśmy przenosić ciężki przedmiot, a inaczej lekki. Inaczej przedmiot, który łatwo może się otworzyć albo wygiąć, a inaczej sztywny przedmiot. Dostosowanie się do tych bardzo różnorodnych warunków i wykrywanie sytuacji bardzo rzadkich to są dwie kategorie, które powodują, że całe to przedsięwzięcie jest bardzo trudne. Jest to powód, dla którego tych robotów wcześniej nie było, a pojawiają się dopiero, jak wdrażamy je w halach magazynów. 

W firmie CDISCOUNT nasz pierwszy robot miał być we wszystkich jej magazynach. Wcześniej nie było tam żadnego robota, co wiąże się zwykle z różnymi wyzwaniami również wynikającymi z tego, że klient jest nieprzygotowany. Nie wie, jak wygląda praca z robotami, jak z nimi postępować, czego można się po nich spodziewać, jak wygląda ich konserwacja okresowa.

W momencie, w którym my wprowadzamy pierwszego robota do danego przedsiębiorstwa, to tę pracę musimy wykonać. Tutaj też jest praca w dziedzinie edukacji – to jest jeden aspekt. Drugim aspektem jest wytłumaczenie klientowi, że w optymalnym scenariuszu nie bierzemy stanowiska, w którym aktualnie pracuje człowiek i montujemy tam robota, tylko trzeba przemyśleć architekturę całego magazynu albo kawałka linii, gdzie dana osoba pracuje po to, żeby dostosować ten kawałek magazynu do zalet robotów. 

Roboty mają inne zalety niż ludzie i żeby w pełni wykorzystać ich potencjał, trzeba te linie produkcyjne i magazynowe projektować w troszkę inny sposób. Roboty są bardzo precyzyjne, potrafią podnosić ciężkie rzeczy. Ludzie nie są ani precyzyjni, ani nie potrafią podnosić bardzo ciężkich przedmiotów. Bardzo dobrze za to sobie radzą w sytuacjach, w których nasze środowisko się zmienia – roboty już nie. Także tutaj wymagane jest odpowiednie dostosowanie stanowiska pracy do tego, aby robot mógł tam optymalnie zostać wykorzystany. 

Pracujesz na Uniwersytecie Warszawskim. Jak trudno było zmienić sposób myślenia, który miałeś będąc tylko w środowisku akademickim i teraz będąc w środowisku biznesowym, startupowym? Czy to był trudny proces, czy przeszedł bardzo naturalnie? Jak to było w Twoim przypadku?

W firmie Nomagic pracuję na stanowisku CTO, czyli zajmuję się głównie technologią. Nie zajmuję się bezpośrednio definiowaniem produktu, natomiast jako jedna z osób, które zakładały firmę, oczywiście cały czas również nad tym myślę. W momencie, w którym zakładaliśmy firmę z Kacprem Nowickim, doskonale wiedzieliśmy, że żaden z nas nie ma doświadczenia w strategii budowania produktu. Znaleźliśmy trzeciego wspólnika, który razem z nami założył firmę Nomagic – Tristan d’Orgeval. Przeprowadził się do nas z Francji z całą rodziną i razem z nami rozpoczął tę przygodę.

Tristan jest tą osobą, która ma największe doświadczenie produktowe i ja od niego się bardzo dużo nauczyłem w tych ostatnich latach. W związku tym, że zajmuję się głównie stroną technologiczną, to ta zmiana nie była zbyt trudna. Natomiast oczywiście te różnice pomiędzy środowiskiem akademickim, a środowiskiem startupowym są duże. Główna różnica polega na zmienności i umiejętności nieustannego dostosowania się do tego, co się dzieje.

Startup nie jest firmą, która ma jasno zdefiniowaną przyszłość. Ta przyszłość (szczególnie w początkowym okresie) cały czas podlega nieustannym zmianom. Plany dotyczące jej trzeba ciągle uaktualniać, zmieniać, dostosowywać na podstawie bieżących informacji i nowych odkryć. 

To jest zupełnie inne środowisko pracy niż uniwersytet, gdzie prowadzi się badania, wytycza się plan badawczy, który można sobie wyznaczyć nawet na parę lat do przodu, a potem go realizować. W startupie to jest oczywiście nie do pomyślenia. To tempo zmian jest główną różnicą pomiędzy środowiskiem akademickim i startupem. Drugi aspekt, który można by powiedzieć, że z mojego punktu widzenia był nawet ważniejszy – ja prowadzę badania podstawowe.

Są to badania, które mają na celu zrozumienie świata, wyjaśnienie różnych zjawisk, poprawienie różnych algorytmów. Natomiast wszystko jest w dziedzinie badań podstawowych, czyli rozwiązywania abstrakcyjnych problemów, które mają posunąć naukę i nasze rozumienie świata do przodu, ale bez aspektu komercyjnego. Badania podstawowe mają to do siebie, że one nawet nie powinny mieć bezpośredniego przełożenia komercyjnego. Startup to dokładna odwrotność.

Pierwszym, wręcz jedynym celem jest zbudowanie produktu, który będzie miał znaczenie komercyjne. Tak żeby ten produkt dostarczał wartość dla klientów i żeby w oparciu o niego można było zbudować firmę. Tutaj musiałem zmienić swój sposób myślenia, czyli nie tylko zastanawiać się jak wyjaśnić zjawiska, które występują dookoła, ale jak wykorzystać metody naukowe do zbudowania produktu, który będzie miał realną wartość dla klienta.

Jakie najciekawsze, najtrudniejsze lekcje wyciągnąłeś po kilku latach pracy w Nomagic? Jak te sytuacje wpływają na to, czy nadal jesteś Markiem takim, jakim byłeś? Jak się odnajdujesz, identyfikujesz w życiu po tych lekcjach?

Bardzo cennym doświadczeniem jest zrozumienie tego, jak działa świat biznesu i świat komercyjny. On jest różny od środowiska akademickiego. Bardzo często jest tak, że osoby albo pracują po jednej stronie, albo po drugiej. W momencie, kiedy dwie osoby z różnych światów się spotykają, jest taka naturalna bariera utrudniająca zrozumienie. Będąc po obu stronach rozumiem teraz, jak działają oba światy. Tak przynajmniej mi się wydaje. Dzięki temu rozumiem realia i cele, które mają przed sobą postawione osoby po obu stronach tej niewidzialnej bariery. To było bardzo cenne doświadczenie. 

Drugie doświadczenie to zarządzanie zespołem. Na uniwersytecie pracowałem w zespole, czy mam swój zespół, natomiast prowadzenie takiego zespołu w środowisku uniwersyteckim, a prowadzenie zespołu w firmie to są jednak dwa różne światy. W środowisku akademickim w naturalny sposób, daje się pracownikom więcej swobody, każdy realizuje własne cele.

One oczywiście powinny być spójne z określonym planem badawczym, ale swoboda, jaką każdy dostaje na uniwersytecie, jest dużo większa niż swoboda w firmie, gdzie osoby muszą ze sobą dużo bardziej współpracować. W momencie, w którym pojawiają się problemy, trzeba je bardzo szybko rozwiązywać. Zarządzanie takim zespołem w środowisku komercyjnym jest moim zdaniem dużo trudniejsze niż zarządzanie zespołem w środowisku uniwersyteckim.

Dzięki za podzielenie się wskazówkami, inspiracjami, doświadczeniem. Powiedziałeś na początku naszej rozmowy, że koncentrujecie się głównie na krajach zachodnich, gdzie wdrażanie robotów jest bardziej opłacalne niż w Polsce. Jak myślisz, czy są zmiany w tym kierunku? Czy porównując 2017 i 2020 rok prawdopodobieństwo wystąpienia zapotrzebowania na takie rozwiązania na rynku polskim teraz jest większe? 

Na podstawie moich informacji oceniam, że jeśli mówimy o perspektywie 5 lat, jest bardzo prawdopodobne, że ta opłacalność w Polsce zdecydowanie wzrośnie. Jednym z czynników, który to napędza jest nieustanny wzrost wynagrodzeń. To jest zarówno wzrost średniego wynagrodzenia, jak i minimalnego. Mówi się o tym, że rząd ma takie plany, żeby wynagrodzenie minimalne wynosiło 4 tys. zł na przestrzeni następnych 4 lat Niezależnie od tego, czy stanie się to za 4 lata czy 6, to jest to istotna różnica. W tej chwili minimalne wynagrodzenie w poprzednim roku wynosiło 2350,00 zł. W tym roku 2600,00 zł.

Każda taka zmiana powoduje, że zatrudnienie nowego pracownika jest coraz bardziej kosztowne. W związku z tym zastąpienie pracy ludzkiej na danym stanowisku przez pracę robota jest coraz bardziej opłacalne. Natomiast oprócz czysto ekonomicznego rachunku jest jeszcze drugi aspekt. W niektórych regionach Polski już tak naprawdę zaczyna brakować rąk do pracy. Z demografii bardzo dobrze wiemy, ile osób będzie wchodzić na rynek pracy przez najbliższe 15 lat, bo te wszystkie osoby się już urodziły.

Dokładnie wiemy, ile ich jest. Przepływy pomiędzy krajami nie zmienia się w drastyczny sposób w tej chwili, więc można dość dokładnie przewidzieć, ile osób wejdzie na rynek pracy w następnych latach. Widać, że w niektórych regionach Polski tych osób brakuje już teraz. Więc sytuacja zdecydowanie będzie szła w tę stronę. Liczba osób w wieku produkcyjnym w Polsce będzie spadała w kolejnych latach.

W związku z tym żeby zachować wydajność gospodarki, automatyzacja jest nieunikniona. To jest proces, który w innych krajach np. w Japonii od wielu lat postępuje. Tam starzejące się społeczeństwo od wielu lat coraz bardziej się automatyzowało. Myślę, że w Polsce sytuacja będzie bardzo podobna. 

Odnośnie braku rąk do pracy to też osobiście doświadczyłem takiej rozmowy. Kiedy pomagałem jednej z największych firm energetycznych w konsultacjach z wdrożeniem projektu związanego z uczeniem maszynowym, to m.in. zapytałem, czy celem tego projektu jest zmniejszenie ilości osób, które są zaangażowane teraz w te działania. Odpowiedź była właśnie w drugą stronę.

Wbrew pozorom problem, który w tej chwili mają firmy energetyczne, jest taki, że wiele osób, które teraz tam pracują na poszczególnych szczeblach, to są ludzie w wieku powyżej 50 lat. Nie ma młodych osób, które chciałyby ich zastąpić. Tak naprawdę może się okazać, że za 5, 10, 15 lat nie będzie “chętnych” do pracy w zakresie tego obszaru.

Co więcej zdobyte przez wieloletnich pracowników doświadczenie przepadnie, a ciężko będzie zaczynać wszystko od nowa. Idea była taka, żeby tę wiedzę zacząć już gromadzić teraz i w pewnych miejscach zacząć wprowadzać automatyzację. To rozwiązanie wcale nie jest tańsze, ale chodzi o to, żeby móc dalej funkcjonować. Jeżeli będzie brakować rąk, to są potrzebne mechanizmy, które to uzupełnią. 

Tak, w pełni się zgadzam. To jest bardzo zgodne z moimi obserwacjami.

Jakie są dalsze plany dla Nomagic?

Na koniec 2019 r. zamknęliśmy naszą pierwszą rundę inwestycyjną, która wiązała się z emisją akcji. Wcześniej byliśmy finansowani ze środków założycieli, a potem przez tzw. Aniołów Biznesu. Teraz już mamy inwestycje z funduszy inwestycyjnych typu venture capital.

Jest to inwestycja ponad 8 mln $, więc pozwala nam myśleć o przyszłości w dłuższej perspektywie, gdyż daje nam to 2 lata czasu na rozwój naszej technologii i dopracowanie naszego produktu, tak żeby był gotowy do wdrożeń na różne rynki w dużej skali. Naszym celem jest wdrożenie 1 tys. robotów w ciągu 5 lat i teraz już wiemy, że przez następne 2 lata mamy środki na rozwój naszej technologii.

Nasz zespół w tej chwili liczy 25 pracowników. Będziemy go sukcesywnie powiększać. Stoją przed nami bardzo ciekawe wyzwania. Szukamy osób, które chciałyby dołączyć do naszego zespołu.

Załóżmy, że spotkamy się za 10-15 lat i zapytam Cię, co ciekawego się dzieje w robotyce, w sztucznej inteligencji. Co mi odpowiesz?

Na początku zaznaczę, że to jest wróżenie z fusów, gdyż jeśli spojrzymy do tyłu, co się działo 10 lat temu, to bardzo trudno było przewidzieć to, co dzieje się w tej chwili. Tak samo myślę, że w tej chwili bardzo trudno będzie nam przewidzieć to, co będzie działo się za 10 czy 15 lat. Natomiast myślę, że będziemy świadkami kolejnych odkryć i przełomowych wyników w robotyce i dziedzinie sztucznej inteligencji, które będą prowadzić do coraz to nowszych zastosowań i wdrożeń na rynku komercyjnym. Tak jak przez ostatnią dekadę widzieliśmy, jak bardzo Internet poszerzał swój teren. Ludzie spędzają coraz więcej czasu w świecie cyfrowym. 

Myślę, że kolejny etap to jest to, że te nowe narzędzia i nowe technologie zaczną zastępować świat rzeczywisty. Czyli tak jak wcześniej ten świat wirtualny stał się równoległym światem do świata rzeczywistego, tak teraz te technologie już pozwalają modyfikować i działać w świecie rzeczywistym.

My tutaj właśnie mówimy o procesie automatyzacji stanowisk czy różnych zawodów. Można sobie zadawać pytania o to, które zawody najbardziej się zmienią w następnych latach. Nie będą to tylko i wyłącznie zawody, które wymagają niewykwalifikowanej pracy. Zaryzykowałbym stwierdzenie, że bardziej narażone są zawody, w których wymagane jest szkolenie (czy bardzo długi proces edukacji), ale końcowa specjalizacja jest bardzo wąska.

Przykładem jest diagnostyka obrazowa w medycynie, czyli opisywanie zdjęć z rezonansu magnetycznego czy z tomografii komputerowej. Żeby to umieć dobrze wykonywać, potrzebne są lata szkoleń i doświadczenia. Komputery radzą sobie z tym coraz lepiej i można już powiedzieć, że w niektórych zastosowaniach są na równi z ludźmi z wieloletnim doświadczeniem.

Można się spodziewać, że ten proces będzie jak najbardziej postępował. Takie właśnie zawody, w których ludzie wykonują bardzo wąsko zdefiniowane działania, będą pierwszymi do automatyzacji. 

Jeśli spojrzymy na takie prace czysto manualne to np. naprawa urządzeń będzie czynnością dużo trudniejszą do automatyzacji. Tam znów ta różnorodność zjawisk, która występuje, będzie dużo większa i stopień skomplikowania czysto manualnych operacji jest bardzo duży. Jeśli mówimy o takich zawodach jak opisywanie zdjęć rentgenowskich czy opisywanie zdjęć tomografii komputerowej, to to jest praca z ekranem, którą wykonuje człowiek, ale komputery już w tej chwili radzą sobie z tym równie dobrze.

Można sobie wyobrazić, że takie podstawowe czynności czy w księgowości, czy wśród prawników będą wykonywane przez komputer. Praca ludzka, która w tej chwili jest wykonywana poprzez różnego rodzaju asystentów, będzie zautomatyzowana i komputer będzie nam odpowiadał na pytania, które aktualnie zadajemy współpracownikom. 

Bardzo dziękuję Marek za to, że znalazłeś czas aby podzielić się swoim doświadczeniem, przemyśleniami i rozważaniami. W szczególności w tej branży robotyzacji. Mogliśmy poruszać się w różnych obszarach, bo jesteś aktywny w wielu, ale wydaje się, że w tym momencie Nomagic jest jedną z tych firm w Polsce, która aktywnie się uruchomiły i działają.

Dla mnie inspirujące i ciekawe jest to, że firma buduje się od zera. Osoby z uniwersytetu pomyślały, że mogą coś takiego zrobić i że jest to możliwe. Dla mnie to jest przykład dla innych, że nie ma co się bać i warto działać. Z Twojej strony było kilka ciekawych, bardzo ważnych wskazówek m.in. to, jak zaangażowaliście trzecią osobę, która wzmocniła stronę produktową. Dzięki temu jesteście mocni na każdym polu. To jest przykład do wzorowania i naśladowania. Dzięki wielkie. Do usłyszenia, do zobaczenia.

Dziękuję, do usłyszenia.

W trakcie naszej rozmowy wspomniałem o Paradoksie Moraveca. Mówiłem o nim już kiedyś we wcześniejszych artykułach, ale przypomniałem pewną historię. Młodzi rodzice z 1,2,3-letnimi dziećmi widzą, jak bardzo ciekawy okres jest to okres. Jak zaczynasz obserwować dziecko z boku, to wiele ciekawych wniosków od razu się nasuwa. Osobiście mam to szczęście, że mam dwójkę dzieci i obserwuję, jak ciekawie działa ludzki mózg.

Mimo tego, że ten malutki człowiek ma dopiero roczek, potrafi robić rzeczy, których bardzo skomplikowane algorytmy, mocne komputery, nadal nie są w stanie zrobić. To jest bardzo ciekawa inspiracja. W Paradoksie Moraveca chodzi o to, że my – ludzie często nie doceniamy rzeczy w naszym życiu, które wydają nam się przeciętne, bo powtarzamy je wielokrotnie.

Nie zdajemy sobie sprawy, jak bardzo skomplikowane one są. Z drugiej strony, próbujemy patrzeć na rzeczy, które tak naprawdę nie są nam potrzebne. Tę analogię można też przełożyć na inne obszary, jak często nie doceniamy tego, co mamy – cudze chwalimy, swego nie znamy. Chciałem zostawić Cię z tą myślą, nawet niekoniecznie o robotach, tylko pomyśl przez chwilę, czego nie doceniasz, a tak naprawdę ma największy wpływ na Twoje życie.

Artykuł Sztuczna inteligencja i robotyzacja pochodzi z serwisu Biznes Myśli.