AutoML: możliwości i wyzwania

Z tego odcinka dowiesz się:

AutoML – lepszy niż człowiek? Omówienie kontekstu, w którym AutoML może przewyższać człowieka, i jakie są jego ograniczenia.
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.
Etapy procesu Machine Learning. Wyjaśnienie poszczególnych kroków w ML: od postawienia celu, przez przygotowanie danych, modelowanie, aż po wdrożenie.
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.
Przyszłość AutoML. Dyskusja na temat przyszłości AutoML, jakie nowe możliwości przyniesie i jak może się rozwijać.
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.
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 Scie nce 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ę S cikit-l earn 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?