Dzisiaj porozmawiamy o metrykach sukcesu w projektach uczenia maszynowego.

Temat jest dosyć “gruby”, a więc nie oczekuj proszę, że znajdziesz tutaj odpowiedzi na wszystkie pytania… W zasadzie to nikt ich nie zna i zawsze można coś poprawiać i interpretować inaczej. Na tym polega rozwój i dlatego idziemy do przodu, ale aby w ogóle ruszyć z miejsca, szczególnie jeśli chodzi o projekt ML, to chcę dziś porozmawiać z Tobą na jeden z ważniejszych tematów  w uczeniu maszynowym, temat od którego wszystko się zaczyna lub powinno zacząć, bo wciąż niestety zdarza się, że jest traktowany dosyć pobieżnie. 

Postaram się odpowiedzieć w tym odcinku na takie pytania:

1. Co to są metryki sukcesu i dlaczego są podstępne?

2. Dlaczego biznesowe metryki sukcesu są takie ważne w projektach ML?

3. Jak biznesowe metryki sukcesu wpływają na techniczne?

4. Jakie pytania warto zadać rozmawiając o metrykach?

5. O częstych błędach popełnianych na tym etapie i ich wpływie na cały projekt?

Jestem człowiekiem, który zdecydowanie woli działać niż rozmawiać, ale jest taki moment w projekcie ML, zadaję pytania, słucham i rozmawiam. Czasem słyszę – “Dobra, to co działamy? Budujemy już ten model?”  A wtedy bardzo często nie ma odpowiedzi na najważniejsze pytanie: ale co właściwie chcemy osiągnąć? Jaki jest nasz punkt B? I jak rozpoznamy (w sposób jednoznaczny), że go osiągnęliśmy?

I pierwsza myśl, która przychodzi do głowy – więcej sprzedawać, lepiej identyfikować klientów, lepiej wynajdować usterki. Jeśli operujemy takimi słowami, to z pewnością to nie brzmi jak metryka sukcesu dla ML… To stąd chce się zadać pytanie, co brzmi w takim razie jak metryka? 

W sumie na to pytanie najlepiej odpowiedzieć od końca. Co powinno się stać, aby zauważyliśmy, że jest sukces (lub go nie ma)? Na co dokładnie będziemy patrzeć? I tu pojawia się szereg pomysłów, np. zwiększy się sprzedaż. Dobrze, ale kolejne pytanie w porównaniu z czym? Czyli wdrażamy model, mierzymy jaka jest sprzedaż i z czym porównujemy? Bo nie możemy porównać tak łatwo z którymś odcinkiem wstecz, bo tam był inny kontekst. Nawet jak uwzględnimy sezonowość i np. porównamy dokładnie rok wstecz, to nadal może być dość losowe porównania.

Dotarliśmy teraz do ważnego pojęcia, które nazywam “losowym porównaniem”. Co to oznacza? To oznacza, że istnieje milion rzeczy, które możemy porównywać, ale większość z nich niewiele nam coś daje oprócz tego, że porównamy coś z czymś i jest spora szansa, że wyciągniemy złe wnioski (chociaż może przez przypadek wyciągniemy też dobre wnioski, ale w takiej sytuacji  też nie ma się  co cieszyć z tego powodu – bo będziemy działać w złudzeniu, że wiemy co robimy.

I co teraz robić? No właśnie, mam nadzieje, że już trochę czujesz, że temat wcale nie jest taki trywialny, spróbujmy ugryźć tego słonia po kawałku.

Co to są metryki sukcesu i dlaczego są podstępne?

Co to znaczy metryka sukcesu

Metryka sukcesu to miara, którą śledzimy, aby wiedzieć, czy to co robimy ma sens, czy nasza strategia działania się sprawdza i czy dalej warto iść w tym kierunku. Brzmi pięknie i wydaje się to prosta rzecz, ale tak naprawdę kryje się tutaj dużo pułapek nawet nie wchodząc jeszcze na poziom ML.
Jeśli chodzi o takie podstawowe pytania, które warto sobie zadać, to czy mierzymy właściwe rzeczy i jeśli tak, to czy mierzymy je właściwie  
W skrócie, metryka sukcesu jest po to, abyśmy  nie przegapili  sukcesu, ale też nie pomylili go z porażką.

Podstępność tego tematu polega też na tym, że czasem mierzymy pewne rzeczy, które wydają się ważne i są mierzone we właściwy sposób, ale de facto nic nie robimy z tym, bo np. nie mamy wpływu na zmianę procesu lub nie chcemy go zmieniać z innych powodów. I znajdujemy się w takiej ciekawej sytuacji, kiedy mamy wiedzę, że np. coś działa niezgodnie z naszymi oczekiwaniami, ale brak możliwych ruchów do wykonania, trudność zmian tej sytuacji itp. Takie sytuacje raczej zdarzają się w większych organizacjach, gdzie mamy pewne ugruntowane procesy, których zmiana wymaga znacznie więcej czasu niż np. w startupie, gdzie jest to decyzja jednej, dwóch osób. Dlaczego o tym mówię?

Właśnie po to, aby uczulić Cię jak ważnym i wielowymiarowym tematem są metryki sukcesu.
Fakt że są to już dobrze, ale jeśli decydujemy się inwestować pieniądze i czas w rozwój ML, to zdecydowanie ten temat wymaga przemyślenia przede wszystkim pod kątem biznesowym, a dopiero potem technicznym, bo jak się za chwilę dowiesz modele ML też mają swoje metryki sukcesu, które dobieramy dopiero wtedy, kiedy zrozumiemy te biznesowe, a nie odwrotnie.

Jak interpretować te słowa w kontekście modelu ML

No właśnie, co właściwie oznacza metryka sukcesu w kontekście projektu ML?

Budując model uczenia maszynowego też musimy narzucić mu pewne ramy i dokładnie określić, czego od niego oczekujemy sugerując się naszą potrzebą biznesową. Metryki sukcesu w ML są różne w zależności od wyzwania i celu biznesowego. 

Podam Ci od razu przykład. Załóżmy, że mamy dwa modele, każdy z nich prognozuje to samo – odejście klientów (czyli tak zwany churn prediction). Jak to jest większa firma, to taki model jest uruchomiony dla tysiąca czy nawet miliona klientów, czyli dokładnie tyle oszacowań robi model. I teraz to, co chcemy zrobić, to zdecydować, który model radzi sobie lepiej.

W praktyce to oznacza, że jeśli mamy tysiące prognoz z modelu 1 i tyle samo z modelu 2, to chcemy jakoś skompresować te wartości do pojedynczej wartości. Dlaczego pojedynczej?, Bo wtedy człowiek może je łatwiej porównywać, bo porównać dwie grupy, które mają miliony czy nawet tysiące jest trudniejsze, niż porównać dwie pojedyncze wartości. Tylko coś za coś, w tym przypadku tracimy mnóstwo szczegółów, ale dostajemy łatwą możliwość porównać modele.

Metryka modelu ML, czasem jest nazywana też techniczną metryką. Inaczej mówiąc jest to to sposób przekształcania wszystkich prognozowanych wartości do pojedynczej wartości. Np. model prognozuje ceny nieruchomości, jedna z technicznych metryk, którą możemy zastosować to `mae`. W praktyce ta metryka robi kilka prostych kroków: 

• Dla każdej nieruchomości mamy parę: prawidłowa odpowiedź oraz prognozowana odpowiedź (np. 500 tys oraz 550 tys. )
• Znajdujemy różnicę w prognozie, w tym przypadku 500 tys. – 550 tys. i mamy -50 tys. czyli model prognozował o 50 tys. więcej
• Pozbywamy się znaku minusa (o ile on jest), chodzi o to, że w tej metryce jest wszystko jedno w którą stronę się pomyliłeś (czy o 50 za dużo, czy o 50 za mało)
• Tak robimy dla każdej pary. Np. jak mamy 10k nieruchomości, to dostajemy 10k błędnych oszacowań
• Na koniec dla wszystkich tych błędów znajdujemy wartość średnią.

To jest przykład,  jak liczy się metryka modelu ML, tak jak już wspomniałem czasem nazywamy ją jako techniczna. Chociaż dla sprawiedliwości dodam, że istnieją co najmniej dwa rodzaje metryk technicznych, ta o której wspomniałem jest prostsza. Pomijając różne szczegóły techniczne, różnica polega na tym, że prostszą metrykę możemy użyć tylko wtedy, kiedy model daje nam finalny wynik.

Natomiast samo trenowanie modelu to jest iteracja i podczas tej iteracji jest też potrzebna metryka sukcesu, która na bieżąco koryguje nauczanie modelu (i zwykle wtedy chodzi o tę wewnętrzną metrykę techniczną). Możesz o tym pomyśleć tak. Jak uczeń chodzi do szkoły, to ma regularnie na bieżąco sprawdziany  i np. raz na rok egzamin. 

To właśnie taka jest relacja między tymi dwoma metrykami technicznymi – sprawdzającymi jak działa sam model. 

Ważne jest to, że już wybrzmiało, że mamy “pośredników”. Na górze tej hierarchii jest metryka biznesowa, następnie metryka techniczna  (zewnętrzna) i następnie metryka techniczna (wewnętrzna), która wprost wpływa na model. Pewnie już czujesz jakie są wyzwania, aby na trzecim poziomie robić to, na czym zależy na pierwszym. Jeśli zgubimy ten kontekst, co często lubią robić osoby techniczne, bo tak jest łatwiej, to szansa, że coś pójdzie nie tak, jest coraz większa.

W DataWorkshop mamy twardą zasadę, nigdy nie stawiamy metrykę sukcesu techniczną na piedestał, bo to nigdy nie było celem, tylko krokiem przejściowym. To jest ważne i ta reguła była wypracowana z czasem, pewnie docenisz je lepiej, kiedy popełnisz swoje błędy.

Dobry model a sukces projektu to dwie różne rzeczy 

Być może kojarzysz takie podejście, kiedy mówi się w taki sposób:

1. Naszym  celem jest  osiągnąć coś dla przykładu wstawię tutaj literkę “A”

2. B pomaga nam przybliżyć się do A

3. Naszym celem jest osiągnąć B 

No właśnie, to jest taki przeskok, na który często można trafić w praktyce i to myślenie jest pułapką. 

Jak domyślasz się dla ML tym punktem B jest techniczna metryka sukcesu (lub metryka modelu), ale z punktu widzenia biznesowego to A jest celem. Inaczej mówiąc, celem końcowym nie jest osiągnąć model z dokładnością 80% według przyjętej metryki MLowej, bo w sumie z punktu widzenia  biznesu nie wiadomo co to właściwie oznacza.

To stąd przychodzi inna ważna myśl do głowy. Jeśli, zespół ML/DS za dużo martwi się metryką techniczną i zapomina o metrykach biznesowych (lub w ogóle jej nie ma), to oznacza, że coś poszło źle.

Dodam, że niestety to jest częsty scenariusz i w pewnym sensie naturalny, grunt aby to zauważać i  reagować.  Tak jak już wspomniałem, sam często włączam się w różne role i dość regularnie łapię się na tym, że  będąc w roli technicznej wpadam w stan skupienia całkowitego nad metryką techniczną, ale przełączając się w rolę lidera projektu i spojrzenie bardziej biznesowe trzeba zobaczyć kontekst metryki szerzej niż tylko ta techniczna.

Też jest pewna ważna myśl. To już wybrzmiało wcześniej, ale powtórzę – czasem metryka techniczna może wyglądać “tak sobie”, ale z punktu widzenia biznesu, to już daje wartość dodaną lub odwrotnie  (niestety częsty przypadek), techniczna metryka wygląda dobrze, ale to nie daje wartości dodanej biznesu.

Tu pojawia się pytanie, po co tak dużo metryk: biznesowe, techniczne? Czy nie da się po prostu mieć jedną prostą metrykę sukcesu? No też chciałbym, aby to było tak proste, ale zwykle tak nie jest. Bo świat techniczny i świat biznesu dość mocno różnią się pomiędzy sobą. W świecie technicznym jest więcej matematyki i algorytmów, w świecie biznesowym – pieniędzy.

Dodam nawet więcej, z punktu widzenia technicznego świat biznesu nie jest logiczny, bo tam jest dużo nieracjonalnych rzeczy (np. dużo psychologii i innych spraw, które ciężko wyrazić matematycznie). Dlatego tak ważne jest jak najszybciej zbudować most pomiędzy tymi światami, bo inaczej szansa na sukces jest minimalna.

Podam Ci jeszcze mniej oczywisty przykład. Kiedy świat techniczny rozjeżdża się ze światem biznesu. Czasem jest tak, że metryka techniczna jest słaba, ale w tym jest wartość biznesowa, ale czasem bywa jeszcze ciekawej (przykład z życia). Metryka techniczna wyszła trochę gorsza, czy to oznacza, że jest źle? Bo wystarczy zrobić proste ćwiczenia i zapytać, co tak naprawdę teraz mierzymy i czy biznes patrzy podobnie?

Przejdźmy do przykładów, aby lepiej zrozumieć zagadnienie metryk sukcesu w ML w praktyce. 

Opowiem Ci kilka  przykładów z mojego doświadczenia i  z DataWorkshop, gdzie pomagamy naszym partnerom wyciągać wartość z danych. Nie mogę wprost podawać danych i szczegółów, ale przykłady będą na tyle soczyste, że bez problemu pobudzą Twoją wyobraźnię i mam nadzieję pomogą Ci lepiej zbadać kontekst Twoich projektów. 

Podzieliłem przykłady na branże, aby łatwiej było Ci identyfikować rodzaje wyzwań i problemów, ale nie musisz się ich pilnować. Czasem przykład z branży logistycznej jest bardzo bliski temu z e-commerce

Przykład 1 – logistyka i wypłacalność firm

Wyobraź sobie, że musisz odpowiedzieć na pytanie:  czy warto zacząć współpracę z firmą x mimo iż spełnia podstawowe warunki – ma towar do przewiezienia i szuka zleceniodawcy, a Ty masz firmę logistyczną. Stoisz przed dylematem, podjąć się tego zlecenia czy nie. Skąd w ogóle takie pytanie?

Skąd ten dylemat? Dlaczego nie wykonuje się wszystkich zleceń? W sumie na to pytanie może być wiele odpowiedzi.  W przypadku z mojego doświadczenia chodziło o wymiar finansowy. Co to oznacza?

• Czy firma A faktycznie zapłaci firmie B?
• Czy firma A jest zaufaną firmą? Chodzi o to, że jak znajduje się np. na tak zwanej czarnej liście  dla urzędu skarbowego, to może nieść ryzyko niewypłacalności i przy okazji powodować inne problemy.
  
  

Nas (z punktu widzenia modelu ML) jednak najbardziej interesowało w kontekście tego projektu, czy firma zapłaci. Tylko znów pojawia się pytania, co to oznacza w praktyce “czy zapłaci”? Jak to możemy jednoznacznie zdefiniować? Popatrzmy na to z perspektywy osi czasu.

Porozważajmy…. Kiedy uznajemy, że dana firma jest wypłacalna, a współpraca udana? 
Jakie mamy opcje? 

• zapłaci przed wykonaniem pracy (zaliczka 100%)
• zrobi zaliczkę przed, ale nie zapłaci resztę po
• zapłaci tuż po wykonaniu zlecenia (w ten sam dzień)
• zapłaci tydzień po wykonaniu zlecenia
• zapłaci miesiąc po wykonaniu zlecenia
• zapłaci więcej niż miesiąc po wykonaniu zlecenia
• zapłaci częściowa i różne kombinacje czasowe

Po zrozumieniu, że definicja wypłacalności,  stało się  zrozumiałe, że nie mamy jednoznacznej odpowiedzi na te pytania, a definicja “firmy, która płaci” wcale nie jest taka trywialna. Skoro nie mamy danych wprost “czy zapłaci” lub te dane nie są tak jednoznaczne, to też nie możemy wytrenować modelu i tego zmierzyć. 

Naturalnie pojawia się pytanie, co dalej?  W takiej sytuacji zwykle chcemy  trochę zmniejszyć złożoność problemu, ale aby wynik też był wartościowy i przybliża nas do głównego celu. Pytanie było takie, jeśli prognozujemy czy firma zbankrutuje, czy to już nie rozwiąże częściowo nasz problem? Bo firma, która bankrutuje nie ma pieniędzy (i to dlatego bankrutuje), więc brzmi, że nie zapłaci. Co ważne dane o bankructwie firmy można znaleźć w zewnętrznych źródłach danych. To oznacza z kolei, że już możemy to policzyć.

Kolejna ważna rzecz z punktu widzenia  metryki biznesowej. Każdy model będzie się mylić, więc od razu trzeba zrozumieć, że  są koszty błędu dwóch rodzajów: sytuacja, kiedy przegapimy firmę  “bankrutującą” i zadajemy sobie pytanie,  na ile to nas boli lub w drugą stronę, kiedy “za dużo” firm wg modelu zbankrutuje, a w rzeczywistości na dany moment mają się dobrze.

Wtedy mamy taką sytuację, że firma B odmówi we współpracy z firmą A mimo iż może ona zapłacić.  Od razu podpowiem, że najlepiej na to pytanie odpowiedzieć przeliczając to i kalkulując na różnych przykładach. Wtedy to znacznie bardziej przemawia biznesowo. Jakie są możliwe scenariusze: w sumie trzy najważniejsze:

1. Pierwszy błąd jest zdecydowanie gorszy, niż drugi. 
2. Błędy bolą podobnie, więc nie możemy uznać, że któryś jest gorszy.
3. Drugi błąd jest zdecydowanie gorszy, niż pierwszy (odwrotna sytuacja do 1). 

Oczywiście na tym nie skończyła się przygoda. Pojawiły się kolejne wyzwanie, które udało się wykryć robiąc prosty prototyp od, ale to już inna historia, na którą jeszcze będzie czas. 

Jak widzisz, startujemy z pewną abstrakcją, która wydaje się konkretem, czyli “czy firma zapłaci”. Swoją drogą, to jest prawie standard, że nawet tam gdzie mamy niby konkret, potem i tak robimy jedną czy więcej iteracji, aby upewnić się, czy jest spójność i jednoznaczność.

Też pewnie już widzisz, że z góry zakładamy, że każdy model będzie się mylić, pytanie tylko jak bardzo nas to zaboli? Który błąd zaboli mniej? To znów kolejny argument, dlaczego tak ważne jest dobrać właściwą metrykę sukcesu. To jest jak kompas, a my podróżnikami we mgle.

Przykład 2 – optymalizacja procesu produkcji w przemyśle

Być może też pracujesz w dużym przedsiębiorstwie, które coś produkują. Jeśli tak to wiesz, że optymalizacja procesów i redukcja odpadów produkcyjnych, to zagadnienia, które mocno się takim firmom opłacają. A jeśli są dane, to i możliwa jest optymalizacja z pomocą ML w wielu wypadkach. 

Tylko jak znaleźć ten proces, ten etap który, gdzie uczenie maszynowe może pomóc? Inaczej mówić trzeba znaleźć nisko wiszące owoce, od tego zwykle najbardziej opłaca się zaczynać ML.

1. Zaczyna się prosto i skomplikowane zarazem  – od zadawania pytań.
   
   To, co my robimy w takich sytuacjach, to  organizujemy na początku szereg spotkań z kluczowymi osobami np. tymi, które najlepiej znają produkcję i wyzwania z jakimi się mierzy zarówno na poziomie wykonawczym, jak i biznesowym (często różne osoby). W ciągu 2-3 dni po takiej serii wywiadów możemy wychwycić już naprawdę fajne ciekawostki i niespójności, które mocno rzutują na kolejne kroki projektu.
   A więc wartość rodzi się już na samym starcie.
   
2. Kolejny krok to wspólnie wybrać proces, którym chcemy się zająć, bo są tam nisko wiszące owoce, czyli stosunkowo niewielkie usprawnienia są w stanie przynieść spore pieniądze dla firmy.  

W tym przykładzie z branży przemysłu to była redukcja odpadów czy też zmniejszenie ilości produkowania wadliwych części i produktów,  zresztą to jest dosyć popularny przypadek, bo tam firmy tracą zwykle dużo pieniędzy i zwykle da się sporo poprawić.

Ok, mamy już swój wzrok skierowany nie na całą firmę, a wybrany problem i proces, brzmi lepiej, ale wciąż trzeba znaleźć odpowiedzi na wiele pytań i to właśnie w kontekście metryk sukcesu, czyli doprecyzować, co właściwie oznacza sukces w takim wypadku, a co będzie porażką.

Co to oznacza w praktyce zmniejszanie wadliwych części? W jakim okresie czasie?
np. jak na jedną część w rok będzie mniej, czy to już sukces?  

Wskazówka: w tym i każdym innym przypadku tego typu fajnie móc znaleźć taką metrykę biznesową, aby dało się to wprost przeliczyć na pieniądze, np. wiadomo,  ile kosztuje produkcja  np. 1 części, czyli wiemy ile firma straci produkując ją wadliwą. Liczymy, ile sztuk produkujemy średnio wadliwych nic nie zmieniając i o ile odratowanych walczymy, aby wysiłek włożony w optymalizację się zwrócił. I tutaj można by skończyć, ale dalej w sumie mamy wiele niewiadomych. 

Jakie dodatkowe pytania warto zadać? 

1. Czy mamy wpływ na to, by zmniejszyć liczbę wadliwych części?
   
   Tu już nie ma łatwych odpowiedzi, bo np. posiłkując się przykładem, który jest mi bliski, z którym pracowałem, część materiałów, z których dany produkt jest produkowany są dostarczane z zewnątrz i faktycznie nie zawsze mamy wpływ na to, aby to naprawić, jeśli akurat tam jest problem.  Odnotujmy to jako kolejny fakt na ten moment naszej historii.
   
   
2. Czym tak naprawdę jest produkowany produkt? 
   
   Czy to jest “coś pojedynczego” czy składa się z mniejszych innych części. Często, a przynajmniej z mojego doświadczenia, a widziałem to na własne oczy, taki produkt składa się z kilku lub kilkunastu innych części tzw. półproduktów. 

I tu dochodzimy do fajnego punktu…

Zobacz, cel biznesowy to zmniejszyć ilość wadliwych produktów w ostatecznym rozrachunki – to też trudniejszy przypadek, bo nie zawsze mamy wpływ na wszystkie czynniki, które to powodują.

Nawet, jak model wykryje, że coś jest nie tak, to co dalej? Gdzie tu jest wartość dodana dla biznesu?

Ale nawet w tym przypadku jest, tylko trzeba ją zauważyć i zdefiniować.

Przykład – aby powstała kompletna część, wędruje ona przez linię produkcyjną i przechodzi przez różne etapy, gdzie za każdym razem dokonuje się pewna zmiana, która przybliża nas do finalnego produktu. Takie przejście zajmuje czas, jak się domyślasz także tutaj czas = pieniądz. 

Załóżmy, że jednym z powodów wady produktów może być wada materiału użytego do jego produkcji. O co teraz walczymy? O to, aby wykryć to najwcześniej jak się da – oszczędzić czas, inne materiały, energię na produkcję czegoś, co będzie wadliwe, tylko zwykle dowiadujemy się za późno, że coś poszło nie tak.

Zwykle w takich fabrykach walczymy o minuty lub nawet sekundy, które źle wykorzystane powodują dalsze opóźnienia.  Marnujemy czas na produkcję wadliwej części i nie produkujemy w tym czasie też tej prawidłowej = podwójna starta można powiedzieć.

Najczęściej popełniane błędy

1. Brak metryki sukcesu biznesowej.
   
2. Metryka biznesowa jest zbyt abstrakcyjna, np. nie mierzy pieniędzy lub chociażby czas
3. Metryka techniczna jest oderwana od metryki biznesowej.
   
4. Zespół zbyt dużo skupia się na metrykach technicznych i mówią, zbyt złożonym językiem do biznesu, zamiast tego, aby lepiej zrozumieć jaki problem biznesów chcą rozwiązać.
   
5. Każda metryka techniczna, to jest pewne przybliżenia, nie można jej ufać na 100%, bo tracimy tam szczególiki (podobnie jak tracimy szczególiki patrząc na wartość średnią), warto robić dodatkowe testy i sprawdzać co w rzeczywistości uzyskaliśmy.
   
6. Brak zarządzania ryzykiem, czyli pominięcia tego, że każdy model myli się, ale ten błąd może kosztować różnie i warto to rozważyć z perspektywy biznesowej i zacząć tym zarządzać świadomie.
   
7. Paraliż przed startem, skoro metryka jest dość trudna, to nie wiem jak zacząć. To źle, zacznij od czegoś i zrób kilka iteracji do przodu i wtedy będzie łatwiej skorygować metrykę, bo lepiej poznasz wycinek rzeczywistości, w której się obracasz. Innymi słowami, małymi krokami do przodu, na początek stawiasz pierwszy krok i prawdopodobnie wybierzesz gorszą metrykę, przynajmniej już zaczniesz iść do przodu. Ważne aby tylko nie zapomnieć skorygować tę metrykę, jak już zgromadzisz większe rozumienie.

Podsumowanie

1. Wybranie właściwej metryki jest trudnym procesem! Mało tego, zwykle nie da się to zrobić dobrze za pierwszym razem, bo jest zbyt dużo niepewności dookoła i rzeczywistość i tak nas zaskoczy.

2. Tylko to wcale nie oznacza, że trzeba wpaść w tak zwany paraliż decyzyjny i przez lata teoretycznie wybierać tę metrykę. Wręcz przeciwnie. Trzeba wybrać na początek w miarę prostą, która brzmi sensownie i przeprowadzić jak najszybciej eksperyment od początku do końca, aby lepiej zrozumieć jakie są ograniczenia, jakie są wady wybranej metryki (i dlaczego) i co możemy zrobić, aby to usprawnić. Wybrać kolejną metrykę i iść do przodu.

3.  Ważne jest to, aby na danej iteracji była jedna główna metryka, nie można skakać lub przybliżać, bo inaczej nie wiadomo co z czym porównywać. Też warto mieć kilka, tak zwanych spadochronów zapasowych, czyli metryki wspomagające wykrywać anomalii. Te pomocnicze metryki, są po to, aby mieć większą pewność, czy to co robimy nadal ma sens.

Zadanie dla Ciebie

Czas na ćwiczenia. Wymyśl gdzie model ML może być pomocny dla Ciebie? Zacznij rozważać jak to będziesz mierzyć? Czy da się tam zmierzyć jednoznacznie? Czy są w tej metryce zawarty pieniędzy? Czy masz wpływ na to co chcesz zoptymalizować?
Podziel się swoim przemyśleniem ze mną :).

Artykuł Metryki sukcesu w projektach Machine Learning pochodzi z serwisu Biznes Myśli.

Kończy się rok 2021, witam Cię w 115 odcinku podcastu, który będzie nietypowy.

Jeśli uważnie słuchasz mojego podcastu odcinek po odcinku, to wiesz, że są pytania, które powtarzają się regularnie, niezależnie od tego, czym zajmuje się gość podcastu.

Zawsze pytam o książkę do polecenia i w tym roku regularnie pojawiało się pytanie o przyszłość, czyli co zdaniem gości czeka nas w niedługim czasie w branży Data Science, Machine Learning.

Wiem, że ciężko przewidzieć przyszłość, o ile w ogóle jest to możliwe. Swoją drogą daj znać, czy słuchasz lub czytasz futurologów i jak myślisz, na ile możemy dobrze oszacować, w którym kierunku będą rozwijały się pewne trendy. Tutaj warto zwrócić uwagę na to, że mogą pojawić się niespodziewanie czarne łabędzie i zmienić bieg wydarzeń nieoczekiwanie. Warto o tym pamiętać i zawsze mieć dużo pokory co do różnorakich przewidywań. Zarówno jeśli chodzi o życie, jak i ML.

Kończymy kolejny rok, za chwilę zaczynamy 2022 i zwykle takie przejście skłania do refleksji. Z jednej strony pojawiają się podsumowania, a z drugiej pytania o to co będzie w kolejnym roku i następnych. Dlatego ostatni odcinek w tym roku będzie podsumowaniem i prognozą przyszłości w jednym. Oddam głos ponownie gościom podcastu Biznes Myśli, którzy pojawili się w 2021 roku.  Wrócimy do niektórych wypowiedzi na temat przyszłości w branży ML.

1. Transformery w uczeniu maszynowym – możliwości i ograniczenia

Krzysztof Choromański:

Wydaje mi się, że jesteśmy w ogóle na początku drogi do stworzenia nowej technologii, z której czerpać będzie cała cywilizacja, ponieważ oczywiście takim końcowym efektem, na który wszyscy czekają to jest ta sztuczna inteligencja. Ale jak słyszę często właśnie w mediach, że się mówi, że już mamy tą sztuczną inteligencję to tylko się uśmiecham, ponieważ wiem, jak daleko jesteśmy od tego. Stworzenie maszyny, która uczyłaby się przynajmniej częściowo jak człowiek jest jeszcze cały czas poza naszym zasięgiem.

Więc to wydaje się tak naprawdę największym wyzwaniem i mam nadzieję, że w przeciągu najbliższych X lat – nie wiem czy 20, 50, 100 – uda się zrobić duży postęp. To co jest niesamowitą własnością, którą ludzie posiadają to jest generalizacja, czyli uczenie się na podstawie bardzo małej liczby przykładów i generalizowanie skomplikowanych sytuacji, często sytuacji, w których nie było się wcześniej – na podstawie tej nabytej wiedzy.

Oczywiście algorytmy, z których korzystamy teraz nie mają z tym paradygmatem nic wspólnego. Nawet te Transformersy, o których mówimy z dumą, ponieważ pozwalają rzeczywiście nam zrobić to, czego inne architektury nie były w stanie, korzystają z olbrzymiej ilości danych i wymagają czasu na nauczenie. 

Generalnie wydaje mi się w środowisku naukowym jest zgoda, że potrzebujemy zupełnie nowych idei, żeby trenować te systemy, które miałyby tą sztuczną inteligencję osiągnąć. Że tak naprawdę ten paradygmat głębokich sieci neuronowych, które zarzucamy ogromnymi ilościami danych i trenujemy przez X czasu to jest jakieś lokalne maksimum. Rzeczywiście wiele fajnych rzeczy możemy z tym zrobić, ale nie rozwiązujemy wielu problemów. Nawet w robotyce jest mnóstwo problemów bardzo namacalnych, które mamy teraz, które nie jesteśmy w stanie rozwiązać za pomocą standardowych technik, z których korzystamy dzisiaj.

Co tym nowym paradygmatem miałoby być – nie wiem. Gdybym wiedział to pewnie bym już starał się opublikować i byśmy to jakoś stosowali. Ciężko jest tak przewidzieć też rozwój nauki. To jest super losowa rzecz, jak działa ludzki mózg, że jak wpadamy na odkrycia. Teoria odkryć naukowych – nie mamy dobrej teorii odkryć naukowych stety albo niestety. Natomiast wydaje się, że jest potrzebna zmiana myślenia na temat takich standardowych technik, które teraz uważamy za klasyczne z punktu widzenia maszynowego uczenia, ale nie są efektywne, jeśli chodzi o ilość danych, które muszą być przetworzone. 

Więc to jest wyzwanie. To jest oczywiście też moje marzenie, żeby w jakiejś mierze kontrybuować do tej nowej rewolucji, która moim zdaniem musi się wydarzyć, żebyśmy przeszli od problemów, gdzie maszynowe uczenie jest wykorzystywane, ale jest wykorzystywane ostrożnie do sytuacji, gdzie możemy w pełni zaufać algorytmom maszynowego uczenia w podejmowaniu skomplikowanych decyzji, które byłyby podejmowane na podstawie właśnie ekstrapolacji, tej informacji, przypadków do sytuacji, w których algorytm nigdy wcześniej się nie znalazł. Nie wiemy jak to robić dobrze i to jest Święty Graal wszystkich, którzy zajmują się teraz maszynowym uczeniem.

2. Dobre praktyki i sztuka nazywania rzeczy w Machine Learning

Marcin Możejko:

To jest bardzo dobre pytanie. Wspominałem, że wydaje mi się, że najbliższe 5 czy 10 lat może się różnić od tych obecnych. To już wydaje mi się powoli widać, chociażby w tym roku pierwszy raz mieliśmy mniejszą ilość aplikacji niż w zeszłym roku czyli pojawiły się pierwsze objawy saturacji też trzeciego świata, najbardziej dynamicznego. Więc mam wrażenie i po cichu liczę też na to, że możliwe, że zmienią się priorytety tego researchu. Wydaje mi się, że  takie kolejne kroki milowe będą związane z takimi rzeczami, które teraz są mniej eksploatowane.

Nie wiem czy przewiduję, na pewno bardzo chętnie bym widział z tej takiej perspektywy, np. stworzenie nawet nie kolejnych modeli rozwiązujących kolejne problemy, tylko np. modeli generatywnych (już teraz powstają tzw. work models czyli modele, w których przewidujemy zachowanie środowiska albo rzeczywistości).

Przewiduję, że jeśli faktycznie ten świat najbardziej bujnego rozwoju spowolni i przyjdzie świat refleksji to wydaje mi się, że takim jednym z bardziej kluczowych rzeczy będzie stworzenie takich modeli, które będą dosyć dobrze odwzorowywać pewne rzeczywistości. Przez pewne rzeczywistości myślę, że np. stworzenie modelu, który może nawet w jakimś ograniczonym stopniu, ale będzie mógł wnioskować w sposób zrozumiały dla człowieka i np. w oparciu o to generować obrazy albo teksty potencjalnie nowe.

Wydaje mi się, że na początku to pewnie będzie w ograniczonym stopniu, ponieważ system symboli, nazw często jest dla nas bardzo nieczytelny. Ale liczę na to, że w ciągu 5 lat się uda tak to zrobić, żeby stworzyć takie modele rzeczywistości w jakiś taki sposób, który będzie korzystał ze sztucznej inteligencji. To jest taki kamień milowy w ogólnym rozwoju.

Natomiast to na co bardzo liczę to to się aktualnie już toczy, ale wydaje mi się, że jest taki trochę problem z transferem do danych medycznych, też obrazowych. Np. wydaje mi się, że ten przełam tam następuje, jest coraz szybszy, ale nie jest na pewno aż tak widoczny i tak bujny jak w zdjęciowej wizji komputerowej. Więc liczę na to, że te modele dojadą do tego poziomu, szczególnie, że takie modelowanie obrazowe pójdzie znacznie do przodu.

Trzeci taki kamień milowy to wspominaliśmy o tych systemach. Podejrzewam, że rzeczy związane z ryzykiem, niepewnością, dopuszczeniem, że jednak sztuczna inteligencja może się mylić i zapytaniem jej, kiedy się faktycznie myli i stworzenie technologii, która daje na to faktycznie rozsądną odpowiedź będzie kolejnym kamieniem. To są takie moje 3 przewidywania.”

3.Wyceń swoje mieszkanie z pomocą Machine Learning

Filip Finfando:

Patrząc na tempo, ostatnie 5 czy 10 lat temu to możemy się spodziewać pewnie wszystkiego. Myślę, że zespoły takie Machine Learning, związane z danymi zostaną z nami w firmach. Nie jako takie trochę wydzielone z takiego typowego zespołu IT czy zajmującego się software developmentem. Mam takie wrażenie, że nie wszyscy specjaliści IT chcą lub potrafią się zajmować tymi rzeczami. Chociaż mają te umiejętności to jakoś tak nie czują tego. Nawet jeśli projekt taki MAILowy jest bardzo dobrze zdefiniowany to zawsze nie do końca wiadomo jaki ten rezultat będzie, trzeba trochę pogrzebać, zawsze coś wypadnie. Więc jest dużo niepewności i wymaga to raczej osobnych zespołów.

Myślę, że też podobnie jak kiedyś, był jeden informatyk w IT, który podłączył drukarkę i zainstalował Windowsa i zrobił stronę internetową. Tak myślę, że w Machine Learningu też jest ta postępująca specjalizacja. Już nie mamy tylko Data Scientist, tylko mamy Machine Learning Engineer, mamy osoby Deep Learning Engineer, NLP Engineer. Widać, że każdy ma swoją działkę i myślę, że raczej ta specjalizacja będzie postępować.

Na pewno, tak patrząc po swojej pracy to myślę, że będzie więcej narzędzi do pilnowania danych, do przetwarzania, sprawdzania jakości. Widać, że teraz dużo takich startupów powstaje, które mają wspierać takie ML owe procesy czy przygotowania danych czy też w ogóle samych modeli. To wszyscy powtarzają, że większość pracy jest przygotowaniem tych danych. Myślę, że to wciąż jest prawda i dużo wysiłków będzie w tym obszarze podejmowanych.

4. Machine Learning & Cyber Security

Mirosław Mamczur:

Jak sobie o tym myślę czy tak jak mi się wydaję, bo widzę, że świat się zmienia to ja bym powiedział, że w ciągu najbliższych 5 czy 10 lat to ML staje się dostępne dla przeciętnych ludzi, zwykłego przedsiębiorcy, mniejszych firm. Teraz przede wszystkim z ML korzystają większe firmy, korporacje, które stać na to.

Natomiast mi się wydaje, że to pójdzie w takim kierunku, że te wszystkie modele, które są tworzone, analizy, wykrywanie anomalii to pójdzie w takim kierunku, że dowolna osoba dostanie jakieś tam proste rzeczy do składania klocków, podepnie swoje dane, automatycznie będzie zbierać te informacje i dawać właśnie takie informacje, np. sprzedawcom, że np. warto byłoby koło mleka postawić jeszcze jajka, bo najczęściej to jest brane. Wydaje mi się, że to w takim kierunku przede wszystkim pójdzie. Nie tylko Data Scientist będą robić czy ludzie od danych, a mam nadzieję, że to pójdzie w takim kierunku, że będzie dostępne bardziej powszechnie dla osób.

A odnośnie cyber security to jak sobie o tym myślę to wydaje mi się, że mogę mieć troszeczkę więcej tutaj obaw i to pewnie z tego powodu, że z tego co kojarzę to w tym momencie jeszcze nie ma ani jednego potwierdzonego ataku jakiegoś oprogramowanie, narzędzia, które ma w sobie zaszytą sztuczną inteligencję.

Natomiast pewnie wraz z rozwojem AI, zastanawiam się czy np. w przyszłości te wszystkie deep fake’i, które będą bardziej dokładne, będzie można obraz podmienić samego siebie i głos, czy to pójdzie w tym kierunku, że jeszcze wzmocnią bardziej te ataki phishingowe i jeszcze łatwiej będzie nakłonić klientów do podania jakiś rzeczy i okradzenia ich. Ale to mam nadzieję, że nauczymy się z tym działać, że coś nam pomoże, może technologia. Mam nadzieję, że to pójdzie w dobrym kierunku mimo wszystko.

5. Product Manager w zespole AI

Aleksandra Możejko:

Moja prognoza jest taka, że na pewno większy nacisk będzie położony na ocenę ryzyka związanego ze sztuczną inteligencją i machine learningiem. Tutaj też te rzeczy, o których mówiłam tj. Fairness i wyjaśnialność modeli. Wydaje mi się, że właśnie takie metody, które pochylają się nad tym, żeby rozwiązania machine learningowe były łatwiej wyjaśnienie, na jakiej podstawie modele podejmują decyzje, żeby nie były stronnicze i żeby jakoś tam te ryzyka szacować i estymować.

Będą się coraz mocniej rozwijały i za 5 lat będziemy może na takim etapie, gdzie to wszystko będzie bardziej uregulowane prawnie. Teraz to jest dosyć nowe, jeżeli chodzi o regulacje prawne tych kwestii związanych z podejmowaniem decyzji przez algorytmy. Tutaj mamy np. kwestie z autonomicznymi samochodami, gdzie mamy już od dawna technologie do tego, ale z powodów (nie jestem pewna czy tak jest) związanych z kwestiami, jak takie samochody ubezpieczać, to jeszcze nie jest wdrażane na szeroką skalę.

Jak ja miałabym przewidywać, wydaje mi się, że w ciągu najbliższych 5 lat (może 10) będziemy mieli takie kwestie jak właśnie wyjaśnialność modeli i to, czy modele są fair, uregulowane prawnie. I będą też istniały frameworki – już trochę istnieją, ale wydaje mi się, że to się rozwinie jeszcze bardziej.

A taki drugi obszar, który widzę, to wydaje mi się, że coraz więcej będzie zastosowań sztucznej inteligencji w biznesie i w ogóle na świecie i coraz więcej automatyzacji. Coraz więcej firm będzie też dokonywało transformacji cyfrowej i wykorzystywało rozwiązania, które wspierają, zwiększają automatyzację.

Natomiast taki obszar, który wydaje mi się, że teraz się rozwija i gdzie ja przewiduję, że za 5, 10 lat mogą być dosyć przełomowe zmiany, to jest właśnie wykorzystanie sztucznej inteligencji w medycynie, np. przy generowaniu leków, obrazowaniu medycznym, wykrywaniu różnych chorób i to wydaje mi się, że mogłoby być bardzo z korzyścią dla przyszłego użytkownika, klienta, czyli po prostu każdego z nas.

Tutaj jestem optymistką, bo tak snuję taką bardzo optymistyczną wizję przyszłości, że właśnie wszystkie modele będą wyjaśniane, że to będzie uregulowane prawnie i jeszcze AI będzie nam pomagało szybciej wykrywać choroby. Oczywiście niekoniecznie musi tak być, bo jest też bardzo dużo ryzyk z tym związanych, ale to są takie dwa główne obszary, gdzie ja widzę potencjalnie największy rozwój w ciągu najbliższych 5, 10 lat.

Mam nadzieję, że taka kompilacja inspirujących i motywujących do działania odpowiedzi na pytanie, jaka przyszłość przez Machine Learning pobudzi także Twoją wyobraźnię do rozważań w tym czasie. Podziel się swoimi przemyśleniami. Chętnie posłucham, jakie są Twoje prognozy i futurologiczne rozważania lub marzenia na temat Data Science, Machine Learning czy też szeroko rozumianego rozwoju koncepcji AI.




Czy może zastanawiasz się nad tym, jak będzie rozwijała się Twoja branża lub zawód? Stawiasz takie pytania?





Na koniec dodam jeszcze, że podobnie, jak w zeszłym roku w styczniu 2022 robimy przerwę, wracamy w lutym z nową energią po urlopie i nowymi pomysłami na podcast Biznes Myśli w 2022 roku.




Jeśli masz jakieś potrzeby lub pomysły, w którym kierunku może rozwijać się podcast, aby przynosił jak największą wartość słuchającym, to napisz do mnie koniecznie

Artykuł Przyszłość Machine Learning – prognozy praktyków i ekspertów pochodzi z serwisu Biznes Myśli.

Witam  w kolejnym podcaście Biznes Myśli. Dzisiaj goszczę Marcina Możejko. To jest bardzo ciekawy, pozytywny człowiek. Marcin ma bogate doświadczenie zawodowe –  z jednej strony twarde, wiedza matematyczna, z drugiej strony programistyczne, a z trzeciej strony to wszystko jeszcze łączy Data Science jako  inżynier i próbuje być na krawędzi tych światów, które wcale nie jest tak łatwo połączyć. 

Marcin opowiada, dlaczego to robi i jak to sobie definiuje.




Ostatnio pracował  w TCL – chińska firma, która ma oddział w Warszawie. Akurat odszedł stamtąd. Dlaczego odszedł i co robi teraz – o tym wszystkim będzie dzisiaj. Ta rozmowa mogłaby być jeszcze dłuższa i myślę, że warto byłoby ją jeszcze kontynuować, bo niektórych wątków  jeszcze w ogóle nie poruszyliśmy z Marcinem, a bardzo by się chciało je poruszyć. Też bardzo jestem ciekawy Twojej opinii, więc zapraszam do wysłuchania i czekam na informację zwrotną.

Dzisiaj będzie gorąco, ale to nie tylko z powodu temperatur za oknem, zapowiada się bardzo ciekawa rozmowa.

Cześć Marcin. Przedstaw się kim jesteś, czym się zajmujesz i gdzie mieszkasz?

Cześć, nazywam się Marcin Możejko. Aktualnie jestem i mieszkam w Warszawie, a zajmuję się Machine Learningiem w bardzo szerokim podejściu, ponieważ mam to szczęście, że w chwili obecnej jestem bardziej w Akademii, ale przez wiele lat pracowałem zarówno w Akademii jak i biznesie, więc można powiedzieć, że byłem zarówno inżynierem jak i researcherem, ale też dosyć mocno zahaczyłem się o biznes. Bardzo dziękuję za zaproszenie i mam nadzieję, że będziemy mogli podzielić się swoimi doświadczeniami w tych tematach.

Właśnie porozmawiamy i o Akademii, o doświadczeniu, o propozycji, którą miałeś i jaka była decyzja. Ale powiedz tak na początek: co ostatnio ciekawego przeczytałeś i  dlaczego warto to przeczytać?

Propozycja, którą bym tutaj polecił to są „Niewidzialne miasta” Italo Calvino. Jest to pozycja literacka bardzo ciekawa. Książka ma bardzo ciekawą formę.  Składa się z 64 krótkich opowieści, które też mają określoną, matematyczną, strukturę. 64  jest związane z szachownicą, w związku z tym są  różne sugestie czytania tej książki. Fabuła opowiada o tym, że Marko Polo wędruje do Chin, tam spotyka Cesarza Chińskiego i opowiada mu o miastach, które odwiedził. Każde z tych 64 opowiadań  jest opowiadaniem o jednym mieście. Bardzo chciałbym gorąco polecić tę książkę, ponieważ ona wbrew pozorom jest bardzo matematyczna. Wydaje mi się, że opowiada o takiej bardzo ciekawej przestrzeni pomiędzy kreatywnością a strukturą. Kreatywność to jest ten wędrowiec, a struktura to jest spotkany cesarz i jest dyskusja pomiędzy tymi dwoma końcami spektrum. Ja byłem zachwycony, więc na pewno gorąco polecam  również inżynierom, wydaje mi się, że każdy wyciągnie z niej coś bardzo ciekawego.

Doświadczenie Machine Learning & Data Science

Bardzo dziękuję za to polecenie. Teraz Marcin opowiedz troszkę więcej o swoim doświadczeniu Data Science, Machine Learning. Jakie projekty miałeś okazję wykonywać do tej pory, w jakich branżach pracowałeś? Wiem, że masz ogromne doświadczenie.

Miałem szczęście zaczynać swoją karierę w czasach, w których inżynierów w Warszawie było bardzo mało. W związku z tym, kiedy było się inżynierem to parało się bardzo dużą ilością projektów z różnych źródeł. Uważam to za olbrzymie szczęście. Zaczynałem w ogóle w PwC firmie konsultingowej, gdzie pracowaliśmy z danymi stricte finansowymi albo klienckimi. Tam pracowaliśmy nad churn’em w banku wówczas, ale też mieliśmy okazję robić anomaly detection na czujnikach.

Pracowaliśmy też dużo w wizji komputerowej dla dronów. Po PwC miałem krótką przerwę w Microsofcie, gdzie pracowaliśmy nad rozpoznawaniem języka naturalnego. Byłem w zespole tłumaczeń i budowałem model, który oceniał ryzyko takich tłumaczeń z pewnym komponentem tłumaczenia decyzji. 

A później przez 2 lata pracowałem jako główny inżynier w konsultingu w Warszawie, firma nazywała się Sigmoidal. Tam też pracowaliśmy nad bardzo dużą ilością projektów, które wchodziły zarówno w wizję komputerową, jak i rozpoznawanie mowy. Przede wszystkim natomiast był to język naturalny, ale też zdarzały się projekty typowo researchowe, nawet z takich fundacyjnych zagadnień Machine Learningu.

Równolegle do tej pracy, w wolnych godzinach też pracowałem akademicko. Miałem absolutorium, ale pisałem magisterkę. Pracowaliśmy właśnie nad projektami związanymi z wykrywaniem raka jelita grubego na zdjęciach. Później też w ramach współpracy z Uniwersytetem pracowaliśmy nad modelami generatywnymi, w których generowaliśmy białka antybakteryjne. Mam jeszcze jedne doświadczenie, ale podejrzewam, że pogadamy o nim później, więc to zostawię na później  

Ostatnia firma, w której pracowałeś – chińska firma TCL, która ma oddział w Warszawie. Co ciekawego tam robiłeś?

Wydaje mi się, że jak wspomniałem wcześniej, że miałem dużo szczęścia w pracy z różnymi projektami to ten projekt był chyba największym szczęściem, który mi się przytrafił. Często jest tak, że w biznesie projekty są bardziej researchowe lub bardziej biznesowe, ten projekt był zarówno płodny biznesowo, jak i płodny badawczo, więc było to olbrzymie szczęście.

A sam projekt dotyczył neural architecture search czyli inteligentnego przeszukiwania architektur. Jednym słowem, tworzyliśmy algorytmy albo sieci neuronowe, które modyfikowały lub tworzyły inne sieci neuronowe. Celem tego projektu było to, że TCL jest firmą, która produkuje bardzo szerokie portfolio urządzeń – od telewizorów przez smartfony, nawet klimatyzatory, kuchenki – wszystko właściwie tam jest.

Każde z tych urządzeń miało jakiś określony chip, każdy z tych chipów miał określony silnik wykonywania inferencji sieci neuronowych, więc naszym zadaniem było stworzenie silnika, który znając to urządzenie, jak i znając ten silnik stworzy taki bardzo szybki algorytm (szczególnie do wizji komputerowej), rozwiązujący zadanie. Jest to problem o tyle ważny, ponieważ kiedy myślimy szczególnie o wizji komputerowej to takim dominującym podejściem jest podejście transfer learningowe czyli, że mam jakiś określony zbiór bazowych architektur, te architektury jakoś tam ubogacamy tak, żeby rozwiązywały nasze zadanie.

Natomiast tych architektur wydaje mi się, jest wciąż stosunkowo mało. W związku z tym, my w pewnym sensie wypełnialiśmy luki pomiędzy tymi architekturami i dzięki temu byliśmy w stanie dotrzeć do większej ilości urządzeń i rozwiązywać większą ilość zadań, co było potwornie satysfakcjonujące.

Tutaj jeszcze tylko wspomnę dla słuchaczy – o AutoML mamy osobny odcinek 101. Tam co prawda było na temat takiego klasycznego uczenia maszynowego, a nie poszukiwania sieci. 

Powiedz jeszcze trochę więcej na temat ciekawych wyzwań, które udało się znaleźć, bo te wyzwanie było całkiem nieintuicyjne. Wymień kilka wyzwań i z czego to wynika, jakie były rozwiązania.

Wydaje mi się, że w chwili obecnej mówimy tutaj o Transfer Learningu, ale taki Transfer Learning jest dwufazowy. W pewnym sensie pierwsza faza jest taka, że ten Transfer polega na tym, że bierzemy konkretną architekturę i ta architektura w pewnym sensie jest wykorzystywana w naszych zastosowaniach, ale jest drugi taki Transfer Learning (nazwijmy to Meta Transfer Learning), który polega na tym, że jest to transfer w pewnym sensie z researchu, badań, Akademii, do biznesu w tym sensie, że to Akademia w pewnym sensie wymyśla problem. Czyli kiedy np. Akademia chce zbudować jakąś konkretną sieć, która zdaniem badaczy jest szybka to wówczas automatycznie to, w związku z tym, że biznes przejmuje te algorytmy od nich to właśnie to jest transferowanie również tego przekonania co do tego, że ta architektura jest szybka. 

W chwili obecnej wydaje mi się, że też z powodu tego, że badanie takie ogólne zajmują się ogólnie postawionymi problemami. Takim dominującym wyznacznikiem tego czy sieć jest szybka to jest liczba operacji wykonywanych w danej sieci. Możemy spojrzeć jak np. każda konwolucja jeśli chodzi o sieci konwolucyjne, wykonuje określoną liczbę operacji dodawania czy mnożeń czy operacji na liczbach zmiennych przecinkowych. To ta liczba właśnie jest takim uniwersalnym wyznacznikiem, czy sieć będzie wykonywana szybko czy wolno. Te sieci, które właśnie w Akademii według tego standardu są optymalizowane, żeby właśnie wykonywać szybko to właśnie te sieci przechodzą później do biznesu. 

To okazuje się, że generuje wiele problemów bardzo nieintuicyjnych, ponieważ ta sieć dokładnie tyle operacji ile stara nam się uzyskać się uzyskuje, ale okazuje się, że operacja nie jest operacji równa. I tak wiadomo, że na końcu to będzie wykonywane na jakimś konkretnym urządzeniu, konkretnym silniku. 

Powiem tutaj parę ciekawostek. Może zacznę od urządzenia. Np. okazuje się, że w chwili obecnej są bardzo określone przeploty np. w sieciach konwolucyjnych czyli np. kiedy używać większych, a kiedy mniejszych filtrów i to z powodu właśnie takich konkretnych optymalizacji niskopoziomowych. Różne przeploty po prostu dają różne wyniki, gdzie możemy mieć sieć, która wykonuje dokładnie taką samą liczbę operacji, ale z racji powiedzmy gdzie, jak głęboko w sieci, jakie operacje są wykonywane – te sieci będą miały zupełnie różne czasy wykonania. 

Drugą warstwą, o której też wydaje mi się, że mało się mówi jest też warstwa konkretnego silnika. Np. jeśli chodzi o smartfony to możemy właśnie też na różnych urządzeniach wykonywać sieci przy pomocy różnych silników. Takie dwa podstawowe to bardzo popularny w chwili obecnej to TF Lite, który towarzyszy TensorFlow’owi. To jest właśnie taki silnik wykonujący obliczenia w sieciach neuronowych na wielu urządzeniach. Ale też jest np. taki silnik, który nazywa się SNPE i jest związany z chipami Snapdragona.

Okazuje się, że dokładnie dwie takie same sieci, wykonują się w zupełnie różnych czasach albo nawet nie to, że w zupełnie różnych, ale nie ma korelacji pomiędzy czasem wykonania. Wiadomo, że któryś silnik może być silniejszy, drugi wolniejszy. Okazuje się, że pojawia się tam potwornie dużo dziwnych czynników, które wpływają na wykonanie tej sieci. Taka chyba najbardziej ciekawa rzecz jest taka, że są pewne określone liczby filtrów, które każdy silnik preferuje np. TF Lite z naszych doświadczeń preferuje ilości filtrów w konwolucjach, które są podzielne przez 4 czyli np. intuicyjnie przejście z 4 filtrów do 3 filtrów może będzie się wykonywało tyle samo.

W związku z tym kontrintuicyjnie zmniejszenie sieci może wręcz czasem nawet wolniej, bo rzeczy, które się dzieją w silniku sprawiają, że jednak z tych 3 filtrów nagle jakoś robią się 4, w związku z tym dodatkowa operacja też zabiera czas. W związku z tym może dochodzić do takich kontrintuicyjnych sytuacji, że zmniejszenie sieci spowoduje jej zwolnienie. 

Natomiast SNPE jest znacznie ciekawsze. Mianowicie SNPE preferuje ilość filtrów podzielną przez 32 i każda inna ilość filtrów jest źle wspierania. Czasami okazuje się, że zmniejszenie tej sieci albo nawet zwiększenie filtra dosłownie o 1 może totalnie wywrócić czas inferencji do góry nogami. W związku z tym jest tam bardzo duże pole do popisu, bardzo duże pole do optymalizacji. Wiele z tych rzeczy wydaje mi, że wręcz trzeba odkrywać. Jest to taka dodatkowa przestrzeń w optymalizacji modeli, która wydaje mi się być fascynująca, a podejrzewam nie do końca powszechnie  znana.

Powiedz,  czym się skończył ten projekt? Jak się z tym czujesz, kiedy Twój model albo model, którego w jakiś tam sposób dotknąłeś, kręci się na milionach urządzeń?

My właśnie rozwijaliśmy te algorytmy, które miały optymalizować te modele pod kątem różnych urządzeń. Co najmniej jeden model z tego co wiem. Niestety miesiąc temu odszedłem z TCL, więc na 100% wiem na pewno o jednym. Ale właśnie skończyło się to bardzo sprawnie działającym zespołem jak i również silnikiem do przeszukiwania tych architektur, który teraz nadal jest rozwijany i kilkanaście modeli już jest w kolejce do deploy. To uczucie jest potwornie satysfakcjonujące.

Też mieliśmy takie zadanie z poprawianiem zdjęć w galerii więc wydaje mi się, że to na pewno jest mega przyjemne, kiedy po prostu ktoś będzie mógł w wolnej chwili delikatnie poprawić swoje zdjęcie, korzystając z mojego algorytmu. Muszę przyznać, że robi mi się zawsze ciepło na sercu, kiedy o tym myślę. A tutaj mam przynajmniej milion powodów, żeby coś takiego się działo.

Nagrywając ten odcinek, używamy kamery. Właśnie widzę za Twoimi plecami dużo różnych książek. Są książki matematyczne, techniczne. Próbuje tak zrozumieć kim bardziej jesteś – czy chcesz się rozwijać w kierunku matematyka czy inżyniera? Bawiąc się architekturą, wybierając lepszą optymalizację to jest bardziej taka praca inżyniera. Jak się czujesz?

To pytanie, które ja sobie musiałem w końcu  kiedyś zadać osobiście. Zauważyłem, że w różnych miejscach czułem, że nie do końca pasuję. Kiedy  studiowałem matematykę, zaczynałem z takiej bardzo inżynieryjnej strony, natomiast na pewno samo  piękno matematyki, wręcz estetyczne i syntetyczne mnie zachwyciło. Natomiast kiedy bardziej poszedłem w tę stronę, to też czułem, że czegoś mi brakuje – brakowało tej  technicznej strony. 

Zacząłem się nad tym głębiej zastanawiać i doszedłem do wniosku, że można te rzeczy właściwie ze sobą połączyć. Odnalazłem to połączenie. Dużą częścią pracy inżyniera jest umiejętność odpowiedniego nazywania rzeczy i wręcz wydaje mi się, że dobre nazwy, dobre zrozumienie rzeczy, nadanie im takiego sensu przez nazwę, pomaga rozwiązywać wiele problemów. Tak np. kiedy pracowaliśmy bardziej z biznesem, czyli z konkretnymi klientami,  to np. nazywanie było potwornie istotne z perspektywy tego, żeby bardzo można było dokładnie określić problem, czyli zrozumieć, jakie są oczekiwania.

Umiejętność nazywania rzeczy jest kluczowa, żeby znaleźć wspólny język i żeby tak naprawdę wiedzieć, co jest ważne i co tak naprawdę musimy osiągnięcia.

Jeżeli spojrzymy sobie na to z innej strony, istotne jest także zbudowanie (pracując jako inżynier) też w takich biznesowych pipeline’ach to potwornie istotne było odpowiednie pokazywanie kroków, które tam się dzieją. Wówczas od tamtych nazw oczekiwaliśmy pewnie jakiejś separowalności, żeby też one brały pod uwagę urządzenia na jakich  będą się wykonywały, ale też np. fajnie by było, żeby te różne nazwy wiązały się z czymś co potencjalnie później da się radę wykorzystać.

Zauważyłem, że właśnie jeśli się odpowiednio nazywa rzeczy, np. jeśli odpowiednio się powie, że ten komponent służy temu, że jeśli odbiorę ten tekst to ten tekst zwróci mi tę informację, to wówczas te nazwy nam pozwalają osiągnąć po pierwsze znacznie większą czytelność, a po drugie znacznie większą reużywalność. 

Schodząc znowu poziom niżej, te poszczególne komponenty wiadomo, że trzeba zakodować korzystając z konkretnych frameworków, konkretnych języków itd. Podobnie jak mamy umiejętność nazywania w kodzie obiektów, interfejsów, to wiadomo, że to jest potwornie ważne, natomiast taką, wydaje mi się ważniejszą rzeczą, którą może trochę mniej się eksploruje, a którą odkryłem to jest to, że np. bardzo ważna jest separacja poszczególnych nazw od siebie. Mamy zazwyczaj do czynienia z co najmniej dwoma rodzajami nazw czyli takim nazwami naszymi czyli kiedy rozwiązujemy jakiś model oparty o tekst, pewnie mamy jakieś teksty, może czytelników. Pojawia się mnóstwo obiektów, które towarzyszą temu problemowi.

Natomiast wiadomo, że wszystko to trzeba w jakimś tam języku napisać, więc pewnie korzystamy Kerasa, Scikita, TensorFlow itd. Np. zauważyłem, że dobre nazwy są to takie odseparowane nazwy. Takie, które w pewnym sensie pozwalają odseparować te dwa światy, ponieważ kiedy te nazwy są nadmiernie związane ze sobą to zazwyczaj powoduje bardzo dużo problemów w dalszej części.

Jak to się wiąże z tymi książkami? Wydaje mi się, że dobre nazwy są pomieszaniem ponownie dwóch takich sprzecznych światów. Zazwyczaj im prostsze są jakieś i np. w jakimś sensie skracają zapis, tym są przyjemniejsze. Natomiast z drugiej strony wiadomo, że ta estetyka nie do końca wiąże się z użytecznością. Wiadomo, że na koniec dnia te nazwy mają być przede wszystkim użyteczne.

W związku z tym, kiedy ja odkryłem, że zarówno mam problem z tą taką bardziej inżynieryjną częścią i z taką bardziej estetyczną czyli, że nie lubię przebywać w takiej syntetycznej przestrzeni, w której te nazwy są czyste. W tym wypadku przez tę syntetyczną przestrzeń, takie akademickie podejście do programowania obiektowego, które wydaje mi się jest bardzo syntetyczne albo właśnie takie podejścia stricte akademickie do problemów to np. lubię, podobają mi się, ale z drugiej strony wydaje mi się, że często one są oderwane od takiej konkretnej praktyki.

Z kolei w tej praktyce to jest taka ciężka inżynieryjna praca, że ciężko jest podnieść głowę i spojrzeć na to, ponieważ jesteśmy skupieni na dowożeniu konkretnych zadań. Z tym też się nie do końca odnajdywałem, więc właśnie znalazłem sobie taką niszę pomiędzy. Właśnie mając szczęście, żeby pracując zarówno w biznesie jak i w akademii, jak i zarówno projektując jak i rozwiązując zadania, ogromnym szczęściem i radością dla mnie jest to, że udało mi się zaobserwować bardzo wiele złych nazw, dobrych nazw i właśnie w takim estetyczno-praktycznym procesie mogę tworzyć teraz swoje, co jest na pewno dla mnie wielkim szczęściem. 

Słuchając Ciebie aż się chce wykorzystać tę umiejętność  nazywania rzeczy. Wróćmy jeszcze na moment do chińskiej firmy TCL. Jak to się stało, że z jednej strony zrobiłeś bardzo fajny projekt, czuć tę satysfakcję i nawet jak nie widać twarzy to czuć w głosie, że jesteś bardzo dumny z tego, ale z drugiej strony odszedłeś. Spróbujmy to nazwać, co to się stało?

To jest bardzo ciekawe zjawisko. Odszedłem dlatego, że dostałem bardzo dobrą propozycję doktoratu i współpracy z grupą onkologii obliczeniowej na Wydziale MIM w Warszawie. Muszę przyznać, że z powodów osobisto-zawodowych, nie podjąłem doktoratu, chodziło również o rzeczy materialne.

Natomiast przez wiele lat to było moim marzeniem, żeby pójść na ten doktorat, więc teraz ta okazja się przytrafiła, z czego byłem szczęśliwy. Natomiast ten projekt był bardzo interesujący, zadowalający, więc to była na pewno bardzo trudna decyzja. Ale ostatecznie stwierdziłem, że w związku z tym, że są to tematy medyczne i okazja do  zrobienia czegoś dobrego dla  ludzi, którzy zmagają się z chorobami, to stwierdziłem, że jeśli dałoby radę wykorzystać tę radość (nazwijmy to radość nazywania, modelowania również w takim szczytnym celu) to wówczas wydaje mi się, że to przyniosłoby mi znacznie więcej spełnienia.

Natomiast jeśli chodzi o takie nazywanie to właśnie nazwałbym to taką ciężką decyzją, w której wydaje mi się, że takie długofalowe, zewnętrzne motywy wzięły górę.

Czuć, jak mocno rezonuje pomaganie. Myślę, że też to jest to bardzo sensowne, logiczne, aby ten potencjał, który technologia wytwarza wykorzystywać w odpowiednim kontekście. Tutaj wielkie brawa.

Świta AI w Chinach

Ale jeszcze domknę wątek odnośnie chińskiej firmy TCL. Świat Chin jest dość zamknięty i z jednej strony wiadomo, że tam dużo się dzieje. Pracowałeś w firmie, w której miałeś styczność z chińczykami, wyczułeś trochę tą różnicę jak oni myślą, jak oni działają. Powiedz o takich swoich przemyśleniach, czym się różni takie klasyczne podejście europejskie od chińskiego? 

Może zacznę od takiej rzeczy, która może wydawać się  anegdotyczna. Jednak większość firm w Polsce jeśli współpracuje z zagranicą taką dalszą, to są jednak te firmy w Stanach Zjednoczonych. Jest to o tyle ciekawe, że tam jest przesunięcie takie, że kiedy tam jest wcześnie, to tam jest późno. W związku z tym taki klasyczny tryb pracy programisty, który raczej mimo wszystko eksploruje późniejsze godziny jest naturalnie wykorzystywany. Natomiast w tym wypadku różnica jest w drugą stronę. W związku z tym główne godziny takiego przecięcia, które mieliśmy z naszymi współpracownikami z Chin były godziny ranne. W związku z tym no właśnie głównie management zajmował się kontaktem z Chinami. 

Natomiast te godziny dostępności były też znacznie dłuższe, ponieważ pierwszą rzeczą, którą na pewno warto o Chinach wiedzieć to to, że te godziny pracy są tam znacznie dłuższe. Faktycznie pracuje się do znacznie późniejszych godzin, w związku z tym też automatycznie to przecięcie z godzinami w Polsce było znacznie większe. Często inżynierowie w Chinach pracowali do takich godzin późnowieczornych. 

Co do takich moich obserwacji z ograniczonego kontaktu to taka rzecz, która wydaje mi się wywarła na mnie największe wrażenie, to jest kwestia skali. Nie mówię tego oczywiście w kontekście  ilości  produkowanych rzeczy albo skali rynku, ale też skali całego środowiska i tego, jak rozwija się technologia. Firma, w której pracowałem – TCL  zajmuje się produkcją ekranów i w pewnym momencie wręcz padło stwierdzenie i zachęta ze wszystkich stron, że: „Słuchajcie, wszędzie, gdzie możemy położyć ekran to fajnie byłoby dołożyć do tego jakąś sztuczną inteligencję”.

W związku z tym były to zarówno telefony jak i telewizory, które w naturalny sposób mają ekrany, ale np. jeśli w klimatyzatorze albo jeśli w kuchence możemy wstawić ekran i chip to czemu tam też nie wstawić sztucznej inteligencji. W związku z tym to gdzie to ziarno potencjalnych pomysłów było rozrzucane to było naprawdę imponujące. W sensie skala tych produktów, które były dostępne i w których potencjalnie można było uzyskać wkład była naprawdę imponująca. 

Druga rzecz, która zrobiła na mnie olbrzymie wrażenie to mnogość rozmaitych dostawców. Ten rynek jest zamknięty, ale z drugiej strony jest też bardzo duży. W ramach swojej pracy miałem do czynienia z olbrzymią ilością rozmaitych urządzeń, ale też rozmaitych chipów albo dostawców konkretnych fragmentów oprogramowania albo np. z chipami się wiązały różne silniki. Było to dla mnie zaskoczenie. W sensie mimo wszystko z perspektywy takiego europejskiego konsumenta, który ma dostęp do określonych produktów to zazwyczaj to spektrum jest dosyć szerokie, ale na pewno to było znacznie szersze. Więc to na pewno zwróciło moją uwagę.

Z tym wszystkim się wiąże taka rzecz, że tam się pojawia mnóstwo wątków, więc naprawdę liczba wątków czyli takich eksperymentów, prototypów pracy, która właśnie jest wykonywana w próbach nowych zastosowań, eksploracji nowych technologii jest naprawdę fascynująca – jest olbrzymia. Porównując swoje doświadczenie ze współpracy z rynkiem amerykańskim i europejskim to tam to podejście jest takie bardziej skupione. W sensie, że jest wrażenie, że tych projektów eksploruje się mniej, ale eksploruje się je dłużej. Właściwie to jest bardzo dobre pytanie w sensie jak te rzeczy się ze sobą porównują.

Ciężko mi tutaj podać jakąś konkretną odpowiedź, bo z jednej strony chińskie firmy produkują naprawdę olbrzymią ilość urządzeń, toczy się olbrzymia ilość eksperymentów, ilość doświadczeń zdobywanych przy tych rzeczach jest naprawdę niewiarygodna. Też wydaje mi się, że eksplorowane są znacznie często ciekawsze scenariusze, które często brzmią jak science-fiction i może na pierwszy rzut oka właśnie te prototypy nie wyglądają jakoś zachwycająco, ale no naprawdę każda kolejna iteracja jest lepsza.

Taka rzecz, która mi przychodzi do głowy to z tego co pamiętam Xiaomi ostatnio wypuściło prototyp ładowarki, która stoi w pokoju i ładuje telefon bezprzewodowo bez konieczności kontaktu z telefonem. Skojarzyło mi się to dlatego, że ten prototyp działa. Wydaje mi się, że jest to wczesna faza, więc pojawia się wiele problemów, ale mimo wszystko zostało to przedstawione jako ciekawostka i podejrzewam, że prototyp toczy się dalej. 

Natomiast mam wrażenie, że właśnie to moje doświadczenie z firmami w Europie jest takie, że owszem tam też w pewnym sensie ilość tych eksperymentów się toczy, natomiast jak już jakieś konkretne eksperymenty wchodzą w grę to ilość uwagi, która jest jej poświęcona jest znacznie większa, bo w związku z olbrzymią ilością skalą eksperymentów i ich zakresem, wydaje mi się, że też znacznie łatwiej jest takie eksperymenty ucinać na rynku chińskim. W związku z tym, też ten czas poświęcony na to jest znacznie krótszy.

Wydaje mi się, że kolejne lata, na pewno obserwacja tego jak te różnice do takich produktów doprowadzą będzie potwornie interesująca. To były takie moje najbardziej poruszające obserwacje.

Każdy z nas, nawet jeżeli ma styczność z tym rynkiem,  to jest zawsze taki wycinek, bo skala jest przeolbrzymia i w ogóle spróbować to jakoś usystematyzować co tam się dzieje i dokąd to prowadzi to pewnie nie jest takie łatwe, ale jest takie satysfakcjonujące. Jest taki żywy organizm, który w tej chwili mocno się rozpędza.

To jest taki być może już nastolatek, a już za chwilę będzie bardziej dorosły i czym to się skończy, jak to będzie dalej się rozwijać to pewnie rozmowa na znacznie dłuższą rozmowę, można się nad tym zastanawiać porządnie dokąd to wszystko dąży. 

Dobre praktyki w Machine Learning

Zmienię teraz temat. Porozmawiajmy o dobrych praktykach, w szczególności w ML, biznesie, więc powiedz proszę, czym dla Ciebie są dobre praktyki w ML i może najlepiej właśnie w takich punktach, konkretach jakbyś mógł wymienić.

To jest bardzo dobre pytanie, też dlatego, że jest bardzo szerokie. Wydaje mi się, że jest  ich wiele w ML, więc może podam jakieś konkretne przykłady w jaki sposób ten ML może się różnić i co uważam w tym jest dobrą praktyką. Wydaje mi się, że taką jedną linią podziału jest to, jaki jest oczekiwany czas ile to nasze rozwiązanie machine learningowe ma żyć.

Wówczas wydaje mi się, że taki prototyp albo taki krótki projekt, wiadomo, że wówczas te projekty są znacznie prostsze, ponieważ jest zdefiniowany dosyć prosty i konkretny cel do osiągnięcia, więc wówczas te projekty toczą się stosunkowo prosto i wydaje mi się, że też, kiedy uczymy się Machine Learningu lub kiedy wchodzimy w Machine Learning, to mamy styczność z takimi projektami, które mają krótki cykl życia. Natomiast wydaje mi się, że znacznie ciekawsze są takie projekty, które mają taki znacznie dłuższy cykl życia i tutaj wydaje mi się, że konieczność tych dobrych praktyk automatycznie jest większa.

W punktach pierwsza rzecz, która wydaje mi się bardzo dobrą praktyką to jest bardzo dokładne zdefiniowanie tego, co chcemy uzyskać. Czyli np. taką konkretną, bardzo dobrą praktyką jest po prostu nawet zrobienie takiego nazwijmy to mechanicznego Turka, którym my udajemy ten algorytm i po prostu ustalenie kontraktu i przeeksplorowanie bardzo konkretnych odpowiedzi na pytania na jakie klienci chcą uzyskać odpowiedzi, wydaje się to być oczywiste, natomiast naprawdę bardzo często może doprowadzać do ciekawych wniosków.

Bardzo często wychodzi mnóstwo różnic w terminologii, w oczekiwaniach. Takim chyba najbardziej klasycznym przykładem to było to, że w jednym momencie, podczas takiej jednej rozmowy klient, który był bardzo przekonany do tego co chce, właściwie totalnie przedefiniował zadanie.  Miał to być jakiś problem klasyfikacji, okazało się, że   to jest problem klasteringu tak naprawdę. Tych klas miało być 6, wyszło jest ich ponad 10 razy więcej. Okazało się, że skuteczność wcale nie jest taka istotna, żeby powiedzmy te klastry wydawały mu się najbardziej interesujące, wcale nie były takie ważne, a ważne było to, żeby te klastry, które są największe, a właśnie najmniej interesujące, żeby łatwiej odfiltrowywać.

Więc taką na pewno dobrą praktyką jest właśnie rozpisanie i poczucie tego co chcemy osiągnąć. Więc to jeśli chodzi o taką praktykę biznesową.

Taka praktyka niżej poziomowa, którą ja na pewno bardzo gorąco polecam to moje doświadczenie podpowiada mi, żeby bardzo mocno separować takie rzeczy, które są bardzo niskopoziomowo w języku programowania, w którym piszemy od takiej logiki biznesowej. Takie konkretne uwagi to jest tak, że np. bardzo często, kiedy chcemy np. napisać pipeline, w którym konkretne obiekty biznesowe są przekształcane w inne obiekty biznesowe, wydaje mi się, że bardzo trzeba tam unikać obiektów niskopoziomowych, bo to doprowadza do naprawdę olbrzymiego chaosu itd.

Zarówno z takiej perspektywy po prostu czystości tego rozwiązania, ale przede wszystkim modyfikacji czyli przyszłych rozszerzeń albo przyszłych dopasowań do tego. Czyli na pewno bardzo bym doradzał taką totalną separację od tych metryk.

Trzecia praktyka, która wydaje mi się też stosunkowo prosto, aczkolwiek bardzo często może unikać w rozwoju takich algorytmów machine learningowych to jest właśnie w jaki sposób walidować te modele.

Wydaje mi się, że to też trochę dotyczy tego punktu pierwszego, ale wydaje mi się, że przynajmniej taką praktyką, którą ja stosuję przynajmniej w części walidacji modeli biznesowych jest zastanowienie się jak będzie wyglądała pierwsza porcja danych, które ten model dostanie czyli, że w pewnym sensie definicja tego czyli np. czy to będą dane, które ten model będzie dostawał jednego dnia, czy to będą jakieś nowe dane, które po prostu przylecą z jakiegoś serwisu o danej godzinie itd.

Wydaje mi się, że takie wymyślenie sobie jak będzie wyglądał pierwszy dzień albo pierwszy taki atomowy, jednostka czasu użycia tego modelu, niewiarygodnie ułatwia zdefiniowanie tego w jaki sposób ten model należy walidować. Walidacja przebiega w ten sposób, że z części naszych danych po prostu wycinamy sobie taki fragment, który ewidentnie będzie zachowywał się w taki sam sposób i to ustawia nam zarówno strategię tej walidacji, jak i to co tak naprawdę będzie do tego algorytmu wchodzić.

Natomiast taką ostatnią cechą, też związaną z tym nazywaniem rzeczy to wydaje mi się, że właśnie w rozwijaniu takich długofalowych projektów to jest właśnie pamiętanie o takiej w sumie bardziej programistycznej zasadzie czyli pamiętanie o zasadzie otwarty-zamknięty czyli, że dobry kod powinien być otwarty na rozszerzenia, natomiast zamknięty na modyfikację.

Wydaje mi się, że szczególnie w wypadku Machine Learningów, w którym jednak często te modele to są obiekty nie do końca zrozumiałe co robią, często ciężko nam zrozumieć jak one działają. Potwornie jest ważne przygotowanie tego rozwiązania, żeby w pewnym sensie potencjalne zmiany albo rozszerzenia nie wpływały na to co się działo w naszym projekcie dotychczas. W związku z tym, że często jakby te modele wprowadzają bardzo dużo losowości do tego całego naszego pipeline to w momencie, w którym będziemy musieli kontrolować na ile to jest kwestia problemu czy modelu, a na ile to jest kwestia naszych zmian jest bardzo  trudne.

W związku z tym, taką konkretną rzeczą, którą  bym proponował, to właściwie sprowadza się do takich dobrych praktyk programistycznych jak odpowiednie ponazywanie rzeczy. Zasada otwarty-zamknięty najczęściej dzieje się wtedy, kiedy mamy jakąś czynność, która jest nienazwana i która jest w cyklu tego całego kodu, wykonuje się gdzieś. Wówczas, kiedy będziemy chcieli ją zmienić to jeśli mamy czysto napisany kod to jest wówczas podmiana pewnego interfejsu. Jeśli nazwiemy tę czynność i umieścimy odpowiedni interfejs, który ją wykonuje to wówczas podmiana tego polega na tym, że możemy po prostu wstawić tam nowy element i tworzy się nowa rzecz. W tym sensie jesteśmy otwarci na rozszerzenie. Natomiast jeśli ją zmienimy to moje najgorsze doświadczenie machine learningowe jest takie, że takie jakieś delikatne zmiany w jednym takim miejscu powodują niewiarygodne zmiany w innym.

Podsumowując wydaje mi się, że niewiele mówiłem w sumie o samych modelach, głównie mówiłem o programowaniu. Wydaje mi się, że taką na pewno dobrą praktykę jest też, żeby to wszystko łączyło się (mówię o długofalowych projektach).

Biznes & Akademia – czy mogą współpracować?

Wszystkie punkty, które wymieniłeś są fajne, rezonują bardzo mocno, warto się wsłuchiwać i też pewnie trzeba parę razy się oparzyć, żeby zrozumieć co miałeś na myśli. Powiedziałeś też, że właśnie będziesz robić doktorat w szczytnych celach. Porozmawiajmy też trochę o tym, ale tak trochę z innej strony. Jest sobie świat akademicki i biznes – one dość mocno się różnią od siebie, zupełnie inaczej podchodzą do projektów ML’owych i też jest zupełnie inna dynamika, inne cele wbrew pozorom.

Czy widzisz tu jakąś szansę na efektywną współpracę w polskich warunkach, pomiędzy światem akademickim, a biznesem? Co musi się stać, żeby taka współpraca w ogóle miała miejsce, a jeżeli już ma to co zrobić, aby była efektywna? Być może znasz jakieś konkretne przykłady, kiedy takie współpracy się zaczynają?

Oczywiście tutaj można wymienić NCBR, też zresztą bardzo duże środki w najbliższych latach będą wydane na takie projekty, ale z tego co słyszę to różnie to bywa i zdarza się, że w świecie akademickim pojawia się taki sposób, żeby spełnić pewne warunki formalne niż faktycznie pewne rzeczy wnoszą w taki sposób, że ten projekt raczej zabija się niż się rozwija. Temat jest trudny, być może nawet delikatny, ale chciałbym usłyszeć Twoją perspektywę. Co powinno się stać, aby właśnie te światy zaczęły współpracować, bo ostatecznie myślę, że na tym wszyscy mogą zyskać.

Ja bym trochę to pytanie podzielił i właściwie nawet zaczął od podzielenia jednego z głównych bohaterów tego pytania, czyli tego świata akademickiego. Mi się wydaje, że jeśli chodzi o Machine Learning i świat akademicki, przynajmniej moje doświadczenie podpowiada mi, że są co najmniej 3 takie światy, które wydaje mi się, że warto byłoby rozdzielić i każdemu przyjrzeć się bliżej.

Pierwszy świat –  to jest taki świat, w którym traktujemy świat akademicki jako źródło wiedzy, którą student na etapie licencjackim lub magisterskim dostaje i potem w pewnym sensie możemy spytać się jak ta wiedza, którą on zdobywa w tym czasie, transferuje się na konkretny biznes, czy dany system edukacji generuje kandydatów, którzy później idą do biznesu i właśnie się w tym biznesie odnajdują. Wydaje mi się, że z tej perspektywy to odpowiedź jak to w chwili obecnej wygląda jest bardzo rozmyta.

Z jednej strony wydaje mi się, że (też myślę w kategoriach swojego wydziału MIM) z jednej strony każdy kolejny rocznik składa się naprawdę z świetnych programistów, którzy są szanowani na całym świecie. Są to też ludzie, którzy bardzo szybko adaptują się w biznesie, są bardzo cenione, więc z tej perspektywy wydaje mi się, że to jest na pewno super. Z drugiej zaś strony wydaje mi się, że to jest taka cecha przede wszystkim takiego kształcenia IT. Wydaje mi się, że w wypadku Data Science jest troszkę inaczej. Pierwszym problemem, który się tutaj pojawia jest to, że świat akademicki w ramach tego kształcenia akademickiego w naturalny sposób może robić bardzo ograniczoną liczbę projektów.

Widzę takie dwa największe ograniczenia. Pierwsze ograniczenie to jest po prostu czas. Jak rozmawialiśmy o dobrych praktykach i rozwiązaniach machine learningowych, które mają trwać dłużej to zazwyczaj myślimy o systemach, które mają działać wiele lat. Ze swego doświadczenia wiem, że są systemy, które tam żyją po 7, 10 lat itd. i wiadomo, że ciężko jest w ramach 6-miesięcznego kursu czy rocznej magisterki przygotować się do tego. W związku z tym wydaje mi się, że tego trochę nie przeskoczymy.

Natomiast z tego co wiem, tutaj jest bardzo fajna inicjatywa, która została podjęta – od przyszłego roku na MIM-ie rusza nowy kierunek związany ze sztuczną inteligencją i wydaje mi się, że tam bardzo interesującym rozwiązaniem, które się pojawia jest właśnie konieczność odbycia stażu. Z tego co pamiętam jest teraz na rok. Ja bym to nawet rozszerzył na 2 lata, bo wydaje mi się, że im dłużej ludzie współpracują i im dłużej mają styczność z rzeczą, która żyje znacznie dłużej niż te 3 miesiące albo pół roku, a potem się o niej zapomina, tym lepiej i to na pewno uczy zarówno dobrych praktyk i daje dobre intuicje tego co jest ważne, a co nie.

Drugi problem wydaje mi się być troszkę głębszy, ale jak się nad tym zastanowimy to jednak to co dla mnie osobiście jest strasznie fascynujące i przyjemnie w Machine Learningu jest to, że jednak te dane, ten problem wprowadza bardzo dużo losowości. Często rozwiązanie projektu machine learningowego to jest taka przygoda. Jest część nieprzyjemna, w której trzeba czyścić dane, ale na pewno taka umiejętność reakcji, radzenia sobie z niepewnością, zarówno co do danych jak i do samego problemu, jak i do algorytmu, wydaje mi się, że to wymaga takiej pewnej adaptatywności. Kiedy myślimy sobie o takim kursie akademickim to wydaje mi się, że po prostu na taką niepewność, taki trochę chaos na to przesadnie nie ma miejsca, ponieważ Uczelnia albo kurs to jest dokładnie miejsce, w którym w jakiś tam ustrukturyzowany sposób chcemy przekazać wiedzę.

W związku z tym wstrzyknięcie to w takiej umiejętności, żeby te kursy miały tą niepewność to jest to dosyć trudne. Też wydaje mi się, że jeżeli chodzi o matematykę, informatykę jest sprzeczne z aktualnym modelem nauczania, który raczej wiąże się z tym, że my mamy pewną taką naczelną wiedzę czyli wiedzę na temat danych działów matematyki albo danych technologii informatycznych, danych języków programowania itd. i po prostu chcemy tą wiedzę przekazać. Oczywiście to jest świetny początek do tego, natomiast z perspektywy dalszych kroków to może to robić takie wrażenie, że właśnie ta rzeczywistość jest taka dosyć uporządkowana, przewidywalna, że łatwo te problemy znaleźć.

Tutaj na pewno ciężko jest takiego rozwiązywania problemów w takim dużym chaosie się nauczyć. Liczę na to, że ten nowy program i konieczność odbycia stażu pomoże, natomiast wydaje mi się, że tutaj taka transformacja w kierunku takiego radzenia sobie z chaosem i radzenia sobie z takimi rzeczami, które żyją znacznie dłużej jest ważna. Więc to jest jeśli chodzi o taki punkt przygotowywania nowych pracowników i w jaki sposób to się tworzy.

Druga rzeczywistość akademicka, nazwałbym to taką rzeczywistością akademicką klasyczną. Czyli kiedy mówię o takiej rzeczywistości akademickiej klasycznej to myślę o takim profesorze, doktorancie, post docu, który pracuje nad swoją dziedziną, swoje wyniki publikuje w określonych czasopismach, te czasopisma mają proces review dosyć zaawansowany. Wymaga się właśnie w tej przestrzeni akademickiej wysokiej jakości tego rozumowania, wysokiej jakości eksperymentów.

Ten proces oczywiście często trwa długo i w związku z tym przenikanie tych nowych wieści i nowych nowinek trwa dłużej, co jest w sprzeczności z tym trzecim światem, bo to są dwa zupełnie inne światy. To jest też świat akademicki, który jest najbardziej związany z uczeniem maszynowym czyli te niewiarygodnie bujne środowisko badań w Machine Learningu.

Wydaje mi się, że są dwa zupełnie różne światy i wydaje mi się, że na pewno warto byłoby im się przyjrzeć, żeby zrozumieć w jaki sposób one wpływają i dyskutują z biznesem, bo to jest dosyć fascynujące. Ten drugi świat czyli w chwili obecnej ten najgorętszy świat, który bardziej niż w żurnalach żyje na Twitterze, w których artykuł, który ma tyle cytowań, że jest właściwie kluczowy dla danej dziedziny. To jest naprawdę fascynujący świat. Wydaje mi się, że obydwa światy zarówno w różny sposób dyskutują z biznesem, wpływają na niego i oczywiście w drugą stronę. Więc właśnie ja bym podszedł do tego bardziej holistycznie.

Wydaje mi się, że szczególnie jeśli chodzi o ten trzeci świat czyli ten świat najbardziej bujny to jest taka przestrzeń, która paradoksalnie wpływa w chwili obecnej na biznes znacznie bardziej niż ten drugi. Ja lubię sobie o tym myśleć, że ten aktualny świat, najbardziej bujny, lubię sobie często porównywać do Formuły 1 czyli, że to jest taki mega interesujący, wyżyłowany wyścig, w który są kamery z całego świata skierowane. Wszyscy wiedzą co tam się dzieje, znają kierowców, każdy chce z tego świata motoryzacyjnego coś uszczknąć itd. Wszyscy słyszymy, że co chwile jest jakieś nowe rozwiązanie w nowym bolidzie, nowy algorytm tam został stuningowany o te 3%.

Wszyscy są podekscytowani, wydaje mi się, że jest tam bardzo silna atmosfera i dzięki temu istnieje olbrzymia ilość hype na to, to też generuje olbrzymie zainteresowanie inwestorów, olbrzymie nadzieje i to jest ta pozytywna część tego świata.

Natomiast wydaje mi się, że istnieje też taka nie do końca pozytywna. Tutaj takie problemy, na które wydaje mi się, że bym chciał zwrócić uwagę to korzystając z tej metafory, że jednak biznes potrzebuje bardziej samochodu dla mas, dopasowanego do konkretnego transportu niż obserwowania tego najgorętszego show, w którym to jest. Więc pierwsza rzecz, która jest olbrzymim problemem w tym wszystkim to jest brak przenoszenia wyników z tego toru na taki zwykły ruch drogowy, co wydaje mi się być dosyć oczywiste. Tutaj widzę kilka problemów. Pierwszy problem często jest taki, że słyszymy i ludzie w biznesie słyszą, że sztuczna inteligencja rozwiązała problem X.

Ale właściwie co to oznacza? Czy to oznacza, że istnieje jakiś tor w tej Formule 1, na którym te pojazdy wykręciły faktycznie świetne wyniki, które potencjalnie nawet człowiek nie byłby w stanie wykręcić? Tutaj olbrzymi problem, który się pojawia jest to, że właśnie często ta definicja problemów w naturalny sposób w tym świecie najgorętszym, tam problemy nie istnieją w kategorii takich życiowych problemów tylko istnieją w kategorii konkretnych zbiorów danych i konkretnych wyników, na które trzeba to osiągnąć. To niestety się nie transferuje, ponieważ po pierwsze te problemy życiowe czy biznesowe generują zupełnie często inne dane, znacznie bardziej zaszumione, często w zupełnie innej naturze. To jest pierwsze źródło braku transferowalności.

Drugie źródło, które wydaje mi się być znacznie bardziej subtelne to jest to, że mam wrażenie, że wszyscy te tory znają. Strasznie mnie zafascynowało ostatnie badanie, bo kiedy np. pomyślimy sobie o takim zbiorze jak CIFAR-10 to w chwili obecnej wydaje mi się, że ilość treningów na tym CIFAR, szczególnie z bujnym rozwojem neural architecture search czyli ilość modeli, które były trenowane na tym CIFAR podejrzewam, że przekracza już ilość gwiazd w tej części galaktyki. Ostatnio ktoś spróbował zrobić taki prosty eksperyment, w którym po prostu spróbował stworzył nowe dane do tego CIFAR’a, które będą podobne do istniejących danych, ale będą mimo wszystko nowe.

Okazało się, że te wyniki w pewnym sensie drastycznie spadły czyli ewidentnie za każdym razem ścigamy się na tym torze i w ramach tych wyścigów rywalizacja jest uczciwa, natomiast jeśli ten tor delikatnie zmienimy to wówczas pojawiają się problemy i to też bardzo drastycznie wpływa na biznes, bo ten tor jest zupełnie inny i koniec końców doprowadza to bardzo często do zawiedzionych oczekiwań, co mi się wydaje być największym problemem dlatego, że właśnie ta transferowalność jest trudna.

Drugim problemem, który się tutaj tworzy to jest problem hype. Kiedy pracowałem w Sigmoidalu, braliśmy udział w konkursie. Zostaliśmy zaproszeni razem z innymi zespołami do tego, żeby brać udział w konkursie. Nagrodą w tym konkursie było podpisanie kontraktu, żeby rozwijać technologie dla tego klienta. Jeszcze dodam, że to był jeden z takich najbardziej ryzykownych działów dla tego klienta.

W związku z tym, kiedy pojechaliśmy na ten konkurs, który trwał dwa dni, skupiliśmy się bardzo bardzo mocno na tym, żeby te dane odpowiednio opracować, oczyścić je, znaleźć wszystkie potencjalne ryzyka, które się z tym wiążą. Bardzo mocno skupiliśmy się na tym ryzyku. Ostatecznie nie wygraliśmy tego konkursu, bo wygrał zespół, który te całe dwa dni na infrastrukturze klienckiej stawiał BERTa. Więc po dwóch dniach udało mi się w końcu postawić BERTa. Fakt, że ta nowa technologia była bardzo ważna.

Też wiem z takich rozmów z ludźmi, że szczególnie dla menedżerów też jest bardzo często ważne, żeby móc się pochwalić taką technologią. Mi się wydaje, że to generuje olbrzymi problem, ponieważ jednak te algorytmy na końcu są jakie są i też moje doświadczenie mówi, że często te wyniki  nie transferują się na konkretne problemy, więc na pewno to powoduje rośnięcie bańki, niemożliwych do zaspokojenia oczekiwań. To powoduje bardzo dużo projektów, które po prostu próbuje się rozwiązywać przy pomocy tych bolidów. Po prostu nie wychodzi, co też automatycznie stanowi problem.

Trzeci problem z tym związany to które bolidy albo które rozwiązania są premiowane. Tutaj taki przykład, który mi przychodzi do głowy, który też jest bardzo pouczający – ja pracuję teraz dużo w modelach generatywnych czyli właśnie w rodzinie modeli, w których są GANy, autoenkodery, ostatnio pojawiła się technika dyfuzji. Przyjrzenie się temu jak wygląda rozwój tej dziedziny będzie bardzo pouczające. Kiedy powstaje jakiś nowy algorytm generatywny to okazuje się, że strasznie ciężko taki model generatywny jest zewaluować. To jest faktycznie prawda, ponieważ to co chcemy to w pewnym sensie chcielibyśmy uzyskać.

Model generatywny to jest taki model, który stara się w pewnym sensie zamodelować rozkład danych czyli jeśli mamy jakieś obrazki to chcielibyśmy model, który pozwoli nam wygenerować nowy obrazek bardzo podobny albo np. ocenić czy dany obrazek jest w miarę wiarygodny. Wbrew pozorom to jest bardzo trudne zadanie, ponieważ ciężko jest tak naprawdę zdefiniować co to znaczy jakiś rozsądny obrazek.

W związku z tym, taką dominującą metryką, która jest stosowana w ewaluacji tych modeli jest to czy obrazki, które są generowane przy pomocy tego modelu wyglądają ładnie czyli czy nie są rozmyte, czy mają odpowiednie tekstury itd. Jak się nad tym zastanowimy to częścią ewaluacji tych modeli jest to, żeby kiedy taki artykuł się pojawia, wygenerował obrazki, które będą miłe dla oka. Ja mogę powiedzieć ze swojego doświadczenia, że zajmuję się rozwijaniem jednej z takiej rodziny modeli i zauważyłem, że wiele innych zespołów, które właśnie korzysta z podobnych rzeczy i też czyta artykuły, które powstają w ten sposób, jedno z naszych doświadczeń jest to, że kiedy troszkę oderwaliśmy od tych obrazków i bardzo dokładnie się przyjrzeliśmy tak matematycznie tym modelom, też co one modelują, udało nam się np. uzyskać znacznie lepsze wyniki w wyborze tych modeli tylko dlatego, że troszkę odeszliśmy od tego, że to nie są obrazki i nie optymalizowaliśmy tych obrazków.

Więc mi się wydaje, że to może powodować konkretne problemy, natomiast samo w sobie pokazuje taki problem, że dosyć istotnym czynnikiem w tym środowisku jest to, żeby właśnie to środowisko odbierało algorytmy dobrze. Nie ma takiej konkretnej walidacji również biznesowej, bo ona po prostu jest bardzo trudna do uzyskania, natomiast też ta presja, żeby te algorytmy były interesujące, nowinkowe, na pewno dosyć mocno na to wpływa.

To środowisko z perspektywy biznesu wydaje mi się z jednej strony wpływa pozytywnie, ponieważ rodzi olbrzymie zainteresowanie, pojawiają się tam duże środki, natomiast właśnie  te problemy, o których wspomniałem, dotyczą tego czego ja najbardziej się obawiam czyli takiego rozczarowania i pęknięcia tej bańki. Więc z tej perspektywy to dla mnie rodzi pewną obawę.

Tutaj oczywiście pojawia się ten drugi świat, o którym wspomniałem – klasyczny akademicki, zamkniętego review. W ostatnim czasie pojawiają się jakieś takie delikatne dyskusje pomiędzy tymi światami apropo właśnie tego co to znaczy dobry artykuł itd., więc ta dyskusja jest szalenie ciekawa.

Ja mogę ze swojej strony powiedzieć ciekawą anegdotę, że właśnie też kiedy też w ramach naszych współprac przygotowaliśmy artykuł do journala, w jednym miejscu zastanawialiśmy się dosyć długo czy dana operacja jest uzasadniona matematycznie. To wszystko obracało się w takim frameworku matematycznym, który nazywa się framework wariacyjny, ten framework ma określone założenia.

Tam zrobiliśmy rzecz, która była taka bardzo inżynieryjna, działała, ale ciężko było ją uzasadnić z tej perspektywy wariacyjnej. Zastanawialiśmy się czy to przejdzie przez review, a w tym samym czasie pojawił się artykuł, który zrobił jeszcze bardziej inżynieryjną rzecz, okazało się, że przeszedł przez review, tylko okazało się, że przyniósł naprawdę świetne rezultaty, więc to go obroniło.

Ale to też pokazało mi, że taki klasyczny świat akademicki jest bardzo skupiony na takiej jakości tych rozwiązań, żeby to było też takie spójne, czyste. Pojawia się takie bardzo dobre pytania.. z jednej strony wydaje mi się, że na pewno ta dyskusja pomiędzy tymi światami jest szalenie interesująca, przewiduję coraz większego rozczarowania, ten powrót potencjalnie starych, sprawdzonych metod będzie następował. Moja ocena tego jest taka, że to są dwie skrajności czegoś, co jest bardzo potrzebne.

Właśnie z jednej strony potrzebujemy tego parcia, tego pędu, z drugiej strony potrzebujemy też takiej kontroli, tego żeby te rzeczy były robione w sposób kontrolowany, żeby były też reprodukowalne. Więc po cichu liczę na to, że uda nam się w najbliższym czasie znaleźć bardzo ciekawą syntezę tych światów. Wydaje mi się, że to będzie potwornie ważne z perspektywy biznesu, również dlatego, że na pewno potencjalnie wprowadzenie jakiejś biznesowej walidacji do tego całego procesu będzie dla tego biznesu ważne.

Tak się przedstawia ten mój krajobraz tego środowiska.

Ciekawy był ten przykład z zakrętem, że wystarczy zmienić troszkę zakręt i już benchmark może się rozsypać albo pogorszyć. A w biznesie nie tyle, że zakręt się zmienia, tam rzeka nagle może się pojawić.

To jest też na tyle śmieszne, jak bierzemy sobie np. computer vision i fajnie jak mamy ImageNet, a jeżeli bierzemy sobie zdjęcie  z komórki to tam ciemno, rozmazane i jakość nam zdecydowanie spada, a przede wszystkim takie zdjęcia są w dużej ilości robione. Ale jedna rzecz mnie ciekawi. Pierwszy świat na pewno Ciebie nie dotyczy, bo to już minąłeś, ale drugi i trzeci – to Ty dołączasz teraz do którego świata? Drugiego?

Wydaje mi się, że choćby nawet z oczekiwań doktorskich w chwili obecnej jest to raczej drugi świat, ale wydaje mi się, że z upływem czasu te granice zaczną się znacznie przenikać. Pamiętam jak na MIM’ie parę lat temu podejście do Machine Learningu było bardzo ostrożne, teraz to Machine Learning wchodzi w ramach nowego przedmiotu. Po cichu liczę na to, że wchodzimy w przestrzeń tej fuzji, że jednak się jakoś spotkają te światy. Aczkolwiek na pewno wchodzę z perspektywy tego drugiego świata.

Przyszłość Machine Learning

Dzięki za te wszystkie wypowiedzi. Zbliżamy się do końca. Na koniec pobawmy się trochę w futurologa lub marzyciela i spróbujmy dokonać takiej predykcji co może się wydarzyć za jakiś czas. Wiadomo, że różnie z tym bywa, nie zawsze to jest łatwe, ale wydaje mi się, że jak słuchałem Twoją wypowiedź to rozważać tak o przyszłości lubisz, więc myślę, że to pytanie też będzie takie fajnie trafne: jak myślisz jakie kamienie milowe przekroczymy za 5 czy 10 lat w uczeniu maszynowym i co wtedy będzie osiągalne?

To jest bardzo dobre pytanie. Wspominałem, że wydaje mi się, że najbliższe 5 czy 10 lat może się różnić od tych obecnych. To już wydaje mi się powoli widać, chociażby w tym roku pierwszy raz mieliśmy mniejszą ilość aplikacji niż w zeszłym roku czyli pojawiły się pierwsze objawy saturacji też trzeciego świata, najbardziej dynamicznego. Więc mam wrażenie i po cichu liczę też na to, że możliwe, że zmienią się priorytety tego researchu. Wydaje mi się, że  takie kolejne kroki milowe będą związane z takimi rzeczami, które teraz są mniej eksplorowane.

Nie wiem czy przewiduję, na pewno bardzo chętnie bym widział z tej takiej perspektywy, np. stworzenie nawet nie kolejnych modeli rozwiązujących kolejne problemy, tylko np. modeli generatywnych (już teraz powstają tzw. work models czyli modele, w których przewidujemy zachowanie środowiska albo rzeczywistości).

Przewiduję, że jeśli faktycznie ten świat najbardziej bujnego rozwoju spowolni i przyjdzie świat refleksji to wydaje mi się, że takim jednym z bardziej kluczowych rzeczy będzie stworzenie takich modeli, które będą dosyć dobrze odwzorowywać pewne rzeczywistości. Przez pewne rzeczywistości myślę, że np. stworzenie modelu, który może nawet w jakimś ograniczonym stopniu, ale będzie mógł wnioskować w sposób zrozumiały dla człowieka i np. w oparciu o to generować obrazy albo teksty potencjalnie nowe.

Wydaje mi się, że na początku to pewnie będzie w ograniczonym stopniu, ponieważ system symboli, nazw często jest dla nas bardzo nieczytelny. Ale liczę na to, że w ciągu 5 lat się uda tak to zrobić, żeby stworzyć takie modele rzeczywistości w jakiś taki sposób, który będzie korzystał ze sztucznej inteligencji. To jest taki kamień milowy w ogólnym rozwoju.

Natomiast to na co bardzo liczę to to się aktualnie już toczy, ale wydaje mi się, że jest taki trochę problem z transferem do danych medycznych, też obrazowych. Np. wydaje mi się, że ten przełam tam następuje, jest coraz szybszy, ale nie jest na pewno aż tak widoczny i tak bujny jak w zdjęciowej wizji komputerowej. Więc liczę na to, że te modele dojadą do tego poziomu, szczególnie, że takie modelowanie obrazowe pójdzie znacznie do przodu.

Trzeci taki kamień milowy to wspominaliśmy o tych systemach. Podejrzewam, że rzeczy związane z ryzykiem, niepewnością, dopuszczeniem, że jednak sztuczna inteligencja może się mylić i zapytaniem jej, kiedy się faktycznie myli i stworzenie technologii, która daje na to faktycznie rozsądną odpowiedź będzie kolejnym kamieniem. To są takie moje 3 przewidywania.

Fajnie, akurat nagraliśmy, zapisaliśmy, zobaczymy za 5-10 lat, sprawdzimy, skomentujemy. Brzmi bardzo ciekawie, w szczególności ten temat związany z obrazkami medycyny to temat, który wiem, że Ciebie bardzo mocno interesuje, więc też tam częściowo się przyłożysz, żeby to też się stało w jakimś tam stopniu.

Marcin, dzięki wielkie za rozmowę. Wyszła troszkę dłuższa, ale bardzo ciekawa. Myślę, że wiele ciekawych wątków tu padło. Nie wszystko w sumie zdążyliśmy omówić, ale myślę, że to jest dobra okazja, aby jeszcze raz się spotkać i przedłużyć przy kolejnym nagraniu. Życzę Ci wszystkiego dobrego, z doktoratem i innymi rzeczami, które chcesz zrealizować. Do usłyszenia, do zobaczenia. Cześć.

Dzięki wielkie za zaproszenie i do zobaczenia, cześć.


Dziękuję za wysłuchanie tego odcinka, wspólnie spędzony czas. Mam nadzieję, że również dla Ciebie to było takie pozytywne doświadczenie. Ciekawy jestem, co myślisz właśnie o tym podejściu, rozważaniu o umiejętności nazywania rzeczy, o tych poradach, które wybrzmiały od Marcina. Czy to są takie rzeczy, które chcesz u siebie w jakiś tam sposób zastosować? Podziel się swoimi przemyśleniami. Zawsze chętnie posłucham Twojej opinii. To tyle na dzisiaj, dzięki wielkie, do usłyszenia.

Artykuł Dobre praktyki i sztuka nazywania rzeczy w Machine Learning pochodzi z serwisu Biznes Myśli.

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.