To już 120 odcinek, a dzisiejszym tematem jest „sztuczna inteligencja pod własnym dachem”, czyli trenowanie własnych modeli LLM (takich jak „ChatGPT”) tylko na własną rękę. Brzmi ciekawie? W mojej opinii, LLM to nowoczesna waluta. Tak, aż tak! Posiadanie własnego modelu LLM (przynajmniej na poziomie kraju) daje przewagę konkurencyjną i wpływa na rozwój gospodarki oraz innowacyjności.

W tym odcinku rozmawiam z Markiem Kozłowskim, ekspertem od NLP (pracy z tekstem) i ogólnie machine learning. Marek pracuje w AI Labie w OPI (Ośrodku Przetwarzania Informacji – Państwowym Instytucie Badawczym). Poruszamy wiele tematów, a główną myślą jest trenowanie własnych modeli LLM pod własnym dachem.

O czym rozmawiamy?

• Dlaczego trenowanie własnych modeli LLM jest kluczowe na poziomie kraju (w tym także w Polsce)?
• Jak wygląda proces trenowania modeli LLM? Od pre-trainingu, przez fine-tuning, aż po ewaluację i walidację.
• Wyzwania i możliwości budowy ekosystemu LLM w Polsce. 
• Inicjatywy takie jak konsorcjum PLLuM oraz potencjał rozwoju modeli LLM w Polsce.
• Marek dzieli się swoimi przemyśleniami na temat otwartości modeli, w tym Mistrala i jego zmieniających się warunków dostępności.
• Znaczenie danych kulturowo-historycznych w modelach oraz ich niedobór w dostępnych modelach, takich jak LLama 3 i innych.

Dlaczego warto trenować własne modele LLM?

• Własne modele to coś więcej niż technologia – to element narodowego ekosystemu AI.
• Dają przewagę konkurencyjną i wpływają na rozwój gospodarki.
• Pozwala na tworzenie rozwiązań dopasowanych do specyficznych potrzeb.
• Zapewnia większą kontrolę nad danymi i prywatnością.
• I coś więcej (warto posłuchać

Dodatkowo dowiesz się o projektach realizowanych w AI Labie w OPI, w tym o systemie antyplagiatowym JSA oraz modelach Qra i MMLW. Poruszamy też kwestię otwartości modeli LLM i podkreślamy, że tworzenie modeli dostępnych dla wszystkich jest kluczowe.

Zapraszam Cię do wysłuchania tego inspirującego odcinka i podzielenia się swoją opinią. Będzie mi również bardzo miło, jeśli polecisz nasz podcast co najmniej jednej osobie – im więcej osób się dowie, tym lepiej!

Spis treści odcinka:

• 00:00:00 – Wprowadzenie
• 00:01:35 – Kim jest Marek Kozłowski?
• 00:03:35 – OPI i AI Lab – co to jest i czym się zajmuje?
• 00:10:40 – Historia deep learningu i NLP w Polsce
• 00:12:40 – Jakie książki Marek ostatnio czytał?
• 00:16:10 – OPI – software house i laboratoria
• 00:20:00 – Projekty zrealizowane przez AI Lab w OPI
• 00:25:00 – Dane i ich znaczenie dla budowy modeli LLM
• 00:30:10 – Definicja modeli LLM
• 00:33:00 – Reprezentacyjne i generatywne modele LLM
• 00:37:00 – OpenAI i Google – historia sukcesu i porażki
• 00:40:00 – Dane jako klucz do sukcesu
• 00:41:35 – Etapy uczenia modeli LLM
• 00:53:00 – Dlaczego warto budować modele LLM pod własnym dachem?
• 00:56:00 – Konsorcjum PLLuM
• 01:06:00 – Ekosystem usług oparty o AI
• 01:14:00 – Racją stanu i przyszłość AI w Polsce
• 01:17:40 – Podsumowanie 

Chcesz dowiedzieć się więcej? Posłuchaj całego odcinka i daj mi znać, co o nim myślisz! Koniecznie poleć odcinek co najmniej jedne osobie. 

Podcast Biznes Myśli znajdziesz na wszystkich platformach podcastowych (Apple, Google, Spotify i innych). Wystarczy wpisać „Biznes Myśli”. Możesz także obejrzeć nas na YouTube, gdzie oprócz głosu nagrywamy również wideo. Czekam na Twoją opinię, czy dodatkowy format na YouTube Ci bardziej odpowiada.

Artykuł Sztuczna inteligencja pod własnym dachem pochodzi z serwisu Biznes Myśli.

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.

Tym razem mam dla Ciebie nieco inny wpis niż zazwyczaj. Jest to pewien eksperyment. Polega on na tym, że Kajetan Duszyński zaprosił mnie do swojego podcastu, a ja pomyślałem, że warto również opublikować to u mnie. 

Dotychczas miałem dwie możliwości: albo głównie ja zadaje pytania, albo prowadzę monolog. Pomyślałem, że fajnie byłoby, żeby ktoś, kto ma trochę inne doświadczenie (programisty), wyciągnął tym razem ze mnie może nieco mniej oczywiste tematy i opinie. Człowiek jest bardzo subiektywny. Dzięki takim eksperymentom będę w stanie wyciągnąć więcej ukrytych warstw. Ciekawy jestem, jak ocenisz tę rozmowę. Koniecznie daj mi znać, jak Ci się podobało.

Ten wpis będzie bardzo przydatny przede wszystkim dla programistów. W szczególności jeżeli mówimy o programistach .NET, C#, bo Kajetan właśnie w tym się specjalizuje. 

Kajetan prowadzi podcast Backend na froncie – polecam zajrzeć, a także odwiedzić jego kanał na YouTube.

Kajetan: Cześć Vladimir. Niezwykle mi miło, że udało nam się spotkać. Pierwszy raz pojawia się pewnego rodzaju współpraca, tzn. Backend na froncie łączy się w pewien sposób (chociaż na jeden odcinek) z Twoim podcastem Biznes Myśli. Mam nadzieję, że wyjdzie z tego bardzo ciekawa rozmowa. Na sam początek bardzo bym Cię poprosił o krótkie przedstawienie się, kim jesteś, skąd pochodzisz i dlaczego się tutaj spotykamy.

Vladimir: Cześć Kajetan. Bardzo mi miło, że mnie zaprosiłeś. Cofnę się trochę w czasie, jeżeli chodzi o przemyślenia związane z C#. Za chwilę wyjaśnię, co mam na myśli. 

Kim jestem? Zajmuję się wieloma rzeczami, więc ciężko jednoznacznie odpowiedzieć na to pytanie, ale myślę, że najlepiej w tej chwili będzie określić to w ten sposób – przedsiębiorca, inżynier uczenia maszynowego, programista. Nadal programista mimo tego, że dużo moich obecnych projektów jest związana ze strategią, planowaniem, tematami biznesowymi. Jestem prezesem spółki DataWorkshop i sporo rzeczy nowych się pojawiło, ale programowanie dla mnie jest w pewnym sensie medytacją.

Nawet wtedy kiedy nie muszę rozwiązywać konkretnego problemu pisząc kod, ale mam jakiś stres albo coś mi nie wychodzi, to i tak siadam, bo kilka godzin programowania jest super sprawą, żeby trochę odpocząć, odnieść swoje pierwsze sukcesy danego dnia, bo to jest też ważne, żeby mieć ustalony plan dnia. Osoba, która robi rzeczy bardziej abstrakcyjne, dość często ma ten problem, że pewne rzeczy się rozpływają, czyli musisz mieć więcej czasu, żeby to wszystko zrealizować. Dlatego proste czynności, mini programy, które od dawna chciałem zrobić, po prostu są mega fajną rzeczą.

Prowadzę spółkę DataWorkshop, która zajmuje się uczeniem maszynowym, ale na różne sposoby. Z jednej strony wdrażamy uczenie maszynowe, pomagamy, wspieramy inne firmy. Na ten moment udało się wdrożyć już ponad 500 modeli, czyli tyle modeli się kręci na produkcji i zarabia na siebie. Ile ich było trenowanych, to już ciężko byłoby zliczyć. Liczy się przede wszystkim wejście na produkcję, bo zwykle do produkcji nie dochodzi, więc tutaj jestem dumny, że udało się aż tyle. 

Druga odnogą jest warstwa edukacyjna. Zrozumiałem w pewnym momencie, że temat uczenia maszynowego sam w sobie jest dość skomplikowany, ale z drugiej strony jak rozumiesz go i chcesz przekazać w inny sposób, to da się to zrobić. Zacząłem to robić najpierw hobbistycznie, tak bardziej dla siebie, miałem taką wewnętrzną potrzebę i okazało się, że to działa i ludzie są zainteresowani.

Robiłem to sobotami, pół roku eksperymentowałem, a potem uznałem, że warto pójść krok dalej i tak uruchomiłem kursy online. W tej chwili już ponad 10 000 osób przeszło przez różne moje inicjatywy. Przy okazji polecam zasubskrybować kanał DataWorkshop.

Trzecia odnoga spółki to lab, eksperymenty wewnętrzne, gdzie robimy fajne rzeczy związane z ML, AI. Teraz robimy kilka, o których za bardzo nikt nie wie, bo to jest eksperyment. Zobaczymy, może kiedyś opowiem o tym więcej. 

Prowadzę także podcast Biznes Myśli. 

K: No właśnie. Ja byłem pierwszy raz bardzo zestresowany i zdenerwowany przed rozmową z Tobą. Przyznam się szczerze, że w poprzednich rozmowach, które prowadziłem, mniej więcej się jakoś tam orientowałem w samym temacie. Natomiast o ML naprawdę nie wiem zbyt dużo.

Ostatni raz z jakimkolwiek ML, z jakąkolwiek siecią neuronową czy czymkolwiek tego typu miałem kontakt wiele lat temu na studiach i też szczerze mówiąc, specjalnie się tym nie przejmowałem, tylko starałem się jak najszybciej zaliczyć przedmiot. Ale sprzedam od razu, że wczoraj przez chwilę rozmawialiśmy przez telefon i mam wrażenie, że już wczoraj gdybyśmy po prostu nagrali naszą rozmowę przez telefon, to już by nam pół podcastu wyszło. To już mnie mocno uspokoiło. 

Dobra, ale w takim razie, żeby cały stres zszedł, żeby dobrze wejść w całą rozmowę, takie szybkie pytanie rozgrzewkowe: powiedz mi jaką ostatnio książkę przeczytałeś albo jaki serial, albo film obejrzałeś? Co mógłbyś polecić?

V: Oglądam zwykle dość mało, ale książki czytam regularnie i aktywnie. Myślę, że w tej chwili nie tyle jakąś techniczną polecę, bo to może nie każdemu się spodoba. Czytałem taką książkę bardziej koncepcyjno-rozwojową.

Ona się nazywa po polsku prawdopodobnie coś w rodzaju “Samuraj bez miecza” czyli taki Samuraj, japoński wojownik, który zwykle ma miecz, a tam właśnie był taki człowiek, który mieszkał w latach tysiąc pięćsetnych w Japonii, który złączył Japonię, a przy tym wszystkim w ogóle nie był wojownikiem w rozumieniu normalnym.

Jego mieczem był jego mózg, intelekt. To była taka bardzo ciekawa historia, chociaż ta ma dwa końce i skończyła się nie tak fajnie. Japonię faktycznie połączył, ale później jego ego zaczęło dawać o sobie znać i on jako zwykły chłopak z małej wsi, stał się prawie cesarzem (formalnie nie mógł nim zostać) i miał całą władzę w Japonii.

Trochę mu w głowie się namieszało i zaczął robić różne dziwne rzeczy. To ciekawe, na ile człowiek może się zmieniać w zależności od swojego otoczenia. Jego ścieżka, jak on to wszystko robił, łączył, jak potrafił zjednać ludzi, łagodzić konflikty itd. to jest bardzo fascynujące. Myślę, że w naszych czasach jest to przydatna lektura. 

K: Szczególnie używanie naszego mózgu, bo z tym różnie bywa, ale zostawmy to. 

Czym jest uczenie maszynowe?

Skoro ludzie czasem mają problem z uczeniem się i z myśleniem to w jakim sensie rozumiemy, czym jest uczenie maszynowe? W jaki sposób możemy uczyć maszyny?

V: Jest taki mem, gdzie stoją komputery na ławkach, na ścianie jest tablica, stoi nauczyciel i uczy. W pewnym sensie to jest prawda, zaraz wyjaśnię dlaczego. Czym jest uczenie maszynowe? W sumie jest wiele różnych definicji i myślę, że dla programisty najlepiej byłoby zdefiniować w taki sposób: jak działa programista, jak myśli programista i w jaki sposób w ogóle powstaje rozwiązanie?

Żeby programista stworzył rozwiązanie, potrzebuje specyfikacji, czyli prawdopodobnie jakiś biznes analityk przygotowuje pewną specyfikację co trzeba zrobić i krok po kroku jest opisane samo rozwiązanie. De facto człowiek manualnie może to wykonywać, tylko zwykle ręcznie to długo trwa, więc próbujemy to przenieść na poziom kodu. Ale samo rozwiązanie jest wiadome, dla programisty to jest dziwne, jak można byłoby zrobić coś, czego nie wiesz. Programista zawsze wie, jak wygląda rozwiązanie. Jedyne co robi, to przenosi, jest w pewnym sensie tłumaczem, który tłumaczy język ludzki na język komputerowy, używając np. C# albo innego języka do programowania.

Jak działa uczenie maszynowe?

Uczenie maszynowe działa nieco inaczej. W naszym przypadku mamy dane, które są na wejściu i na wyjściu. Jako przykład załóżmy, że chcemy napisać algorytm scoringu, który przewiduje, czy ktoś może dostać kredyt. Akurat jak pracowałem z C# to wtedy w firmie, w której pracowałem, takie rozwiązania były tworzone. To działa w taki sposób, że od banku dostawaliśmy specyfikację i tam było dużo if dość skomplikowanych i trzeba było to wszystko manualnie napisać. W uczeniu maszynowym to byłoby tak, że my dostajemy dane, to taka zwykła tabelka, mamy kolumny i wiersze.

W wierszach jest poszczególny klient, a w kolumnach są opisy klientów, np. płeć, wiek, pensja, kraj, dzielnica. Takich opisów może być np. 50-100 albo nawet tysiące – w uczeniu maszynowym to się nazywa cechami. Jest odpowiedź, np. taka, że ten człowiek kredyt spłacił. To, co my robimy, to przekazujemy do naszego modelu takie informacje czyli dane wejściowe.

Potem mówimy, że to jest odpowiedź: ten człowiek spłacił, a ten nie, więc modelu zrób coś z tymi danymi, czyli zbuduj algorytm na podstawie tych danych, których ci dostarczyliśmy, samodzielnie znajdź takie korelacje, które powodują, że my jesteśmy w stanie później w przyszłości odróżnić klienta, który nam spłaci kredyt od tego, który tego nie zrobi. Różnica główna polega na tym, że ten algorytm powstaje automatycznie. To uczenie maszynowe go wymyśla, a nie człowiek go narzuca z góry. 

To ma swoje wady i zalety, ale taka największa zaleta ML to wykrywanie nieoczywistych zależności. Człowiek ma bardzo ograniczone zasoby, jeżeli chodzi o połączenie różnych faktów. Owszem, może brać pod uwagę jednocześnie 5, 7, czasem ktoś mówi, że więcej, ale zwykle mniej. A świat, który nas otacza, jest bardzo skomplikowany, więc my potrzebujemy pewnych narzędzi (podobnie jak mikroskop albo teleskop, gdy badamy kosmos), które potrafią wykonywać pewne czynności szybciej niż człowiek.

Komputer szybciej liczy – nawet nie ma co dyskutować. Tu jest podobnie. Jak zbadamy różne kombinacje o różnych zależnościach, to komputer szybciej znajdzie te zależności, bo po prostu szybciej może przemnażać macierze albo znajdować jakieś tam warunki. 

Podsumowując, uczenie maszynowe to jest sposób znalezienia rozwiązania w automatyczny sposób, wykorzystując dane historyczne, które mają pewien opis plus odpowiedź na pytanie, co wydarzyło się na końcu. Później ten akord możemy zastosować, żeby prognozować coś w przyszłości, ale nie tylko, ponieważ jest jeszcze kilka różnych zastosowań. 

Czy modele ML krzywdzą?

K: Czy w takim modelu w trakcie projektowania to Ty wskazujesz, jaka cecha ma jaką wagę? Na przykład to, że wiek osoby jest ważniejszy w dawaniu pozytywnej opinii dla kredytu niż to, gdzie mieszka? Zacząłem się właśnie zastanawiać, że jeżeli nagle wyjdzie tak, że ktoś mieszkający w szemranej dzielnicy chciałby dostać kredyt i pomimo tego, że ma pieniądze, stabilną sytuację ale po prostu mieszka w takiej dzielnicy, bo w niej się wychował, to nagle może to się wydać lekko niesprawiedliwe.

Oczywiście domyślam się, że przy tych wszystkich historycznych wpisach, będziemy mieli niewielki odsetek, ale czy gdzieś jesteśmy w stanie nad tym zapanować, jak ten model mimo wszystko działa i lekko go korygować?

V: Poruszasz niezwykle ważny temat, bardzo wrażliwy w uczeniu maszynowym. Zwykle to polega na tym, że to się dzieje automatycznie. To dobrze i źle. Dobrze, bo to się dzieje automatycznie, więc tak naprawdę przekazujemy całą moc modelowi, dzięki temu jesteśmy w stanie wykrywać znacznie więcej, bo nie ograniczamy go i to jest dobre. Ale źle, ponieważ pojawiają się różne problemy etyczne, o których wspomniałeś.

To jest problem, który jest bolączką w tej chwili. Faktycznie może być tak, że jest dzielnica, płeć albo inne rzeczy, które mogą być krzywdzące i to faktycznie tak jest. To jest taki temat, który próbujemy rozwiązać na różne sposoby. 

W ogóle wykrywanie, że takie coś jest, też nie jest takie łatwe, bo te bardzo złożone modele są tzw. modelami blackbox. To oznacza, że one działają dobrze albo bardzo dobrze, ale my nie wiemy, jak one działają. To, co teraz przez ostatnie kilka lat stało się bardzo popularnym trendem, to badanie i odkrywanie, podejrzenie, co tam się dzieje w środku tego blackboxa, zrobienie chociaż grey boxa.

Kiedy przynajmniej widzimy, że np. dana cecha wpływa na to i na to, a inna wpływa na jeszcze coś. Jeżeli któraś cecha jest bardziej krzywdząca, to tę cechę się usuwa i to jest najbardziej bezpieczne, co można zrobić. 

K: Ok, właśnie mam wrażenie, że dla takiego typowego programisty, taki machine learning może być nieco trudny do zaakceptowania, bo programiści jednak mimo wszystko lubią mieć panowanie nad wszystkim, lubią wiedzieć, że są bogami tych aplikacji i dokładnie wiedzą, co się dzieje w każdym momencie. Jeśli zaś nie wiedzą, to znaczy, że napisali za mało testów i powinni coś zmienić, zrefaktoryzować.

Proces Machine Learning

Ty z kolei mówisz właśnie, że przy ML właściwie tworzysz coś i potem sam do końca nie wiesz, jak to działa. W związku z tym, jak w ogóle wygląda proces ML’owy, od czego się zaczyna, przez jakie kroki przechodzimy, żeby cały proces zbudować?

V: Zaraz wyjaśnię proces, ale skomentuję jedną rzecz a propos trzymania kontroli. Tutaj jest trzymanie kontroli na innym poziomie. Są takie działki, gdzie jest z jednej strony wyzwanie, z drugiej strony obszar, w którym trzeba uważnie dobierać chociażby cechy, które przekazujemy albo sprawdzać, czy model się nie przeuczył. 

Jak wygląda proces ogólnie? Na początek musimy zrozumieć (podobnie jak w programowaniu) problem biznesowy. To jest chyba jedyna, wspólna część na początek. Drugi krok to zrozumienie danych, bo w tych prawdziwych danych jest dużo śmieci. Jak to zwykle bywa, pewnie każdy programista, który pracował z bazą danych, wie, co tam jest w środku.

Zwykle to nie jest tak, że firma powstała w jeden dzień, tylko jeden człowiek przyszedł, drugi odszedł, jedna tabelka gdzieś tam dodana, druga usunięta, trzecia na pół usunięta, potem ktoś zrobił duplikaty i potem te same dane są trzymane w trzech różnych miejscach, ale każdy się boi to usunąć, bo nie wiadomo, co się stanie itd. W tym wszystkim trzeba się połapać.

Jeżeli tam jest gdzieś takie miejsce, gdzie ludzie wpisują dane z palca, to jest bardzo niebezpieczne miejsce, bo na pewno tam będzie dużo błędów. Jeżeli mamy importy, Excele czy różne inne rzeczy (w większych firmach mają różne, jeszcze śmieszniejsze formaty), to zawsze mogą być różne kłopoty i problemy.

Duplikaty może i są najmniejszym problemem, ale różne anomalia mogą się pojawiać. Trzeba by więc było zbadać te dane i stwierdzić, czy po pierwsze rozumiemy te dane, potrafimy je połączyć, a po drugie czy jakość tych danych jest wystarczająco dobra, bo jeżeli dane są złe, to cała reszta już nie ma sensu. 

Jest takie powiedzenie: ’garbage in, garbage out’, czyli jak wrzucimy śmieci na wejściu, to ML jakikolwiek by on tam zbyt skomplikowany nie był, to nie będzie w stanie wyczarować mądrych rzeczy opierając się na śmieciach.

Przygotowanie danych zajmuje sporo czasu. Umiejętności programowania są tutaj bardzo przydatne, bo trzeba trochę się nagimnastykować, żeby te dane wyciągnąć, połączyć, pogrupować. Jest nawet taki żart, że 60-70% czasu data scientist spędza na czyszczeniu danych, a resztę czasu na narzekaniu, że tyle czasu nad tym spędził. Tak wygląda życie data scientista. 

W teorii tam jeszcze jest kilka innych kroków. Jak już mamy przygotowane dane, to możemy zacząć już trenować model. Jeżeli chodzi o model i algorytm, tu jest mnóstwo różnych koncepcji. Spróbujmy wyjaśnić przynajmniej jedną z wersji, żeby to było bardziej zrozumiałe. 

Algorytm jest jak suchy przepis, czyli poszczególne kroki, które trzeba wykonywać. A model to jest coś, co już wykonaliśmy na podstawie tego algorytmu i mamy pewien stan w pamięci albo na dysku zapisany. Jako przykład: algorytm może być taki, że mamy napisane jakieś dokumentacje listy if’ów, które mamy wykonać. Model to jest kawałek kodu, który wykonał te if’y, przepuścił przez siebie dane i zatrzymał ten stan w pamięci na dysku czy pamięci RAM. 

Algorytmy są różne. Zaczynając od takich bardzo prostych algorytmów: liniowe, drzewa decyzyjne, gradient boostingi albo sieci neuronowe. Proces dobierania algorytmów też w tej chwili już nie jest taki skomplikowany, ale też zajmuje trochę czasu i zazwyczaj jest to zwykła pętla for czyli po prostu iterujesz sobie różne modele i dobierasz taki, który działa najlepiej.

To akurat nie jest duże wyzwanie. Większym jest dobór cech, bo tak jak rozmawialiśmy na początku, jeżeli chodzi o ten przykład ze scoringiem, to jest tak, że możemy wybrać różne cechy (wiek, płeć itd.) i są takie cechy podstawowe, które są dostępne od razu. 

Ale też jest proces feature engineering, który polega na tym, że na podstawie obecnych cech, próbujemy znaleźć nowe. To brzmi nieco zagadkowo. Co to znaczy w praktyce? Mamy pewne dane, ale ten algorytm jest w stanie tylko dosłownie wyłapać to, co jest w tych danych. On nie jest w stanie się domyślić. Na przykład, jeśli prognozujemy ceny nieruchomości i mamy zamiast powierzchni, szerokość i wysokość tego mieszkania/domu.

Teraz algorytm nie będzie w stanie pomnożyć tych dwóch liczb, ale to jest ważne, bo powierzchnia jest jednym z kluczowych parametrów, jeżeli chodzi o prognozowanie. W tym przypadku ML engineer będzie kombinować z tymi cechami w taki sposób, aby stworzyć coś nowego. Tutaj zwykle pojawiają się pytania: czy to w ogóle ma jakikolwiek sens? Bo skoro ta informacja już była w danych, to czy to daje jakąkolwiek wartość dodaną? Jak najbardziej daje i to wynika z ograniczoności algorytmów. One nie potrafią rozumować takim rozumieniem człowieka jako taka prawdziwa inteligencja naturalna. One są dość ograniczone. Większość z nich, np. takie popularne algorytmy drzewa decyzyjne to są takie algorytmy zachłanne.

One próbują wykonywać jeden krok do przodu, najlepszy w tym momencie. Ale jak popatrzysz na całą ścieżkę, to nie jest optymalna ścieżka. Przez to, że ta złożoność jest tam zbyt duża, wykonuje się w taki sposób. Zresztą feature engineering to jest ta najciekawsza, w pewnym sensie też najtrudniejsza część związana z uczeniem maszynowym (przynajmniej klasycznym).

Jak już mamy cechy i model, to jest taka trochę pętla. Jak tworzymy nowe cechy, trenujemy model, potem kolejne cechy, trenujemy model i tak sobie kręcimy. Później jeszcze jest jeden wymiar: dobór parametrów. Model sam w sobie ma pewne zewnętrzne parametry. Załóżmy takie drzewo decyzyjne ma pewną głębokość i parametr podaje się z zewnątrz  – 5 pytań głąb albo 10 pytań w głąb itd. Czym więcej pytań, tym bardziej szczegółowo wchodzimy w detale. To ma swoje wady i zalety, ale na moment to zostawmy.

Już wybraliśmy cechy, wytrenowaliśmy model, dobraliśmy parametry i w tym momencie oczywiście warto też patrzeć na metrykę sukcesu. To jest właśnie kryterium jakości, np. mamy model A i model B. Każdy z tych modeli ma jakiś wynik. Który model jest lepszy? Możemy subiektywnie podchodzić do tego tematu, ale to jest trochę bez sensu. Są formalne metryki, które po prostu porównują wiersz po wierszu, gdzie błąd jest mniejszy. Ten błąd definiujemy na różne sposoby. Błąd może być taki, jeżeli mówimy np. o scoringu, tam załóżmy, że od 0 do 100. Prawidłowa odpowiedź to 100, a nasz model powiedział 90, czyli pomyliliśmy się o 10 w tym przypadku.

W pierwszym wierszu o 10, w drugim wierszu o 20, w trzecim o 5,i znajdujemy wartość średnią i wychodzi nam jakaś pojedyncza liczba określająca błąd w tym modelu. Potem bierzemy drugi model i liczymy w podobny sposób. Metryki są różne, ta liczba też jest różna. Warto też zrozumieć, że metrykę trzeba umieć dobierać. Teraz nie chcę wchodzić w szczegóły, ale idea polega na tym, że kompresujemy wiedzę. Powiedzmy, że mieliśmy milion wierszy, więc mamy milion prognozowań i w tym przypadku to wszystko spłaszczamy do jednej, pojedynczej liczby, która mówi, na ile dobrze ten model działa. Już ten krok podpowiada intuicyjnie, że gdzieś tu tracimy informacje. Mieliśmy tak dużo wierszy, a opisujemy przy pomocy jednej liczby.

W sumie na tym się kończy prototypowanie, ale to niestety jest problem, bo przez dłuższy czas było tak, że (teraz to już trochę się zmienia) powstawały różne prototypy i na tym to się kończyło. Dlaczego to jest dopiero początek? Bo ten model trzeba wdrożyć gdzieś. Po co model, który coś robi, ale nie daje żadnego zysku? To wdrażanie już bardziej przypomina programowanie, bo jest jakiś serwer, gdzieś wrzucamy nasz kawałek logiki, jakoś to się kręci. 

Przy czym jeżeli chodzi o wdrażanie, są różne sposoby. Jednym ze sposobów są mikroserwisy. W szczególności jak to jest napisane w Pythonie, to wtedy ten mikroserwis sobie gada przez REST API, każdy może się z tym zintegrować. 

Drugi sposób to np. przez bazę danych, bo wtedy mamy tak, że raz w nocy odpalamy na wszystkich danych, trenujemy nasz model, potem prognozujemy, a wynik zapisujemy po prostu od razu do bazy. Potem każdy, kto chce, może z tej bazy skorzystać.

Są jeszcze inne rozwiązania, jeżeli chodzi o C#, dzisiaj też trochę o tym porozmawiamy, bo jest całkiem ciekawa biblioteczka do tego. 

K: No właśnie, ale zanim do tego przejdziemy, zanim przejdziemy już do konkretnych rozwiązań… Widzę już w rozmowie, że mocno oddzielasz programistę od data scientista. Zacznijmy od tego, czy w ogóle taki developer np. C#, potrzebuje machine learningu, potrzebuje wiedzy z tego zakresu? 

V: Krótka odpowiedź – TAK. Dlaczego on tego potrzebuje? Chociaż to, że ja oddzielam, to też nie przypadek. To jest tak, że w sumie ja się wyprowadzam ze środowiska programistycznego i są zalety, dlaczego akurat programistom warto pójść w tym kierunku jako data scientist, bo na koniec dnia ten cały kod to jest zwykły kod i te wszystkie problemy, które ma programista, wersjonowanie kodu, dobre nazewnictwo kodu itd. one tu istnieją.

Ludzie, którzy się wyprowadzają bardziej w strony statystyczne albo naukowe, totalnie nie ogarniają tych obszarów i na skutek tego powstają takie śmieci. Jeżeli ktoś myśli, że widział najgorszy kod w swoim życiu, to prawdopodobnie nie widział kodu. Kod powstaje u data scientista, który nie ma takiego doświadczenia programistycznego. Pod tym względem programista ma tutaj ewidentnie przewagę. 

Druga sprawa, że tam jeszcze potrzebne jest trochę inne myślenie, więc dlatego to oddzielam. Sam programista jak wkroczy w ten obszar, będzie się czuł trochę niekomfortowo, bo ma pewne braki w wiedzy. 

Dlaczego akurat to jest potrzebne dla developera, który nawet nie zamierza tam wkraczać? Świat się zmienia szybciej, niż myślisz. Możesz np. funkcjonować w .NET, a okazuje się, że świat otacza się uczeniem maszynowym. W Azure mamy cognitive services, czyli są warstwy związane z ML. To można bardzo łatwo w tej chwili wykorzystać i już zacząć robić przeróżne, trudne rzeczy wykorzystując tylko API.

Później SQL Server, niby baza danych, ale z jakiegoś powodu tam się pojawiają wdrożone komponenty, które umożliwiają uruchomienie uczenia maszynowego wprost na bazie. Tam co prawda jest język albo Python, albo R – domyślne języki data science. Też mamy dość specyficzne biblioteki dostępne, ale są takie najpopularniejsze algorytmy, być może nie zawsze najlepsze, ale takie wystarczająco dobre (biorąc pod uwagę, że to jest baza danych). Teraz to już jest taki standard, SQL Server 2017 i w górę już posiada takie możliwości. Później pojawiają się jakieś biblioteki, które można wprost sobie wciągnąć do C# czy F# i zrobić prosty ML.

Generalnie rzecz biorąc, to całe otoczenie się przygotowuje. Teraz pytanie: dlaczego to się dzieje? Dzieje się to z bardzo prostego powodu – biznes tego potrzebuje. Zresztą po co robimy kod? Z jednej strony każdy programista powie, bo to jest fajne, ciekawe i zresztą sam też tak powiem. Z drugiej strony programista dostaje pensję dlatego, że rozwiązuje konkretne, biznesowe problemy. Jeżeli pojawi się coś, co jeszcze jest w stanie wzmocnić tę wartość dodaną albo konkurencja zaczyna wyciskać inną firmę, bo wprowadza jakieś bardziej konkurencyjne elementy, to druga firma nie ma za bardzo wyboru, też musi nadawać na podobnych falach. 

Uczenie maszynowe jest właśnie takim game changerem czyli narzędziem, który zmienia reguły gry i umożliwia podejmowanie lepszych, sprawniejszych decyzji albo stworzenie lepszego produktu. Wynika to m.in. z tego powodu, że programista sam w sobie musi z góry wszystko przewidzieć. To jest ograniczone samo w sobie, bo mózg nasz ma swoje zalety (np. jeżeli chodzi o abstrahowanie rzeczy), ale jeżeli chodzi o wykrywanie dużych zależności w milionach lub miliardach wierszy, to tutaj się nie wyrabia. Ostatecznie żeby wzmocnić pewne decyzje, to ML tutaj jak najbardziej będzie przydatne. 

Trzeba sobie zdawać sprawę, że to nie chodzi o to, że każdy programista nagle się stanie naukowcem albo researcherem. Chodzi bardziej o to, że te światy zaczną się łączyć. W sumie w pewnym momencie już nie będzie takiej dużej granicy. 

Zadam takie pytania. Osoby, które pracują w C#, to zwykle jest przede wszystkim backend. Tam da się coś robić na frontend, ale raczej egzotyczne rzeczy. Czy jest możliwa praca C#, jak jest baza danych? W tej chwili odpowiedź brzmi prawdopodobnie nie do końca, bo w ten czy inny sposób, baza danych gdzieś tam jest.

Teraz drugie pytanie jest takie: na ile jesteś ekspertem tej bazy danych? Zwykle to jest tak, że zawsze w firmie jest jedna osoba, która jest ninja, wymiata z tej bazy danych i jak trzeba zrobić coś bardziej złożonego, to się idzie do tej osoby. Każda inna osoba po prostu była na szkoleniu z baz danych, coś tam wie, że jest jakiś indeks i zwykle to wystarcza. I to jest mniej więcej podobna analogia. Taka osoba nie musi umieć wszystkiego jeżeli chodzi o ML, nie musi wymyślać takich rozwiązań, ale bardziej używać gotowych komponentów po to, żeby wzmocnić siebie i rozwiązanie, które dostarczy.

K: Teraz faktycznie zaczyna się to wszystko powoli układać, ale też sobie przypomniałem trochę historii o tym, kiedy w ogóle o samym Tobie, o samym Vladimirze usłyszałem. Pamiętam, że słuchałem podcastu bodajże Marka Jankowskiego „Mała Wielka Firma”, gdzie opowiadałeś o chatbotach. Wtedy sobie tak myślałem, że mówisz, że to już się powoli dzieje, że zbliżają się boty i chatboty wspierane przez AI i że nie będziemy wiedzieli, kiedy rozmawiamy z drugim człowiekiem, a kiedy z maszyną. Jeszcze wtedy tak sobie myślałem: chyba nie jesteśmy aż tak blisko tego wszystkiego.

Teraz w aktualnej firmie, w której pracuję, zastanawialiśmy się nad wprowadzeniem na call center voicebota. Jak się okazało, jak się rozmawia z takim voicebotem, to już jest taka technologia niesamowita, że naprawdę osoba, która nie wie, że rozmawia z botem, nie jest w stanie praktycznie zorientować się, że tam po drugiej stronie, to nie siedzi normalny człowiek.

Zaczynam Ci wierzyć, że faktycznie każdy developer powinien tego machine learningu skosztować, bo to faktycznie zaczyna nas otaczać. Zresztą widać też wielki ciąg na rynku. Tak jak jeszcze kilka lat temu ofert pracy dla data scientistów nie było zbyt dużo i osoby, które chciały pójść w data science, miały pewien problem z tym, że chętnie robiły to hobbystycznie, ale nie było do końca z tym pracy. Teraz już widzę, że zdecydowanie więcej tego się pojawia. 

Jednocześnie jestem trochę zaskoczony tym, co mówisz ze względu na to, że zawsze miałem wrażenie, że ten data scientist to po prostu taki troszeczkę inny programista, ale wciąż programista. Czy widzisz coś takiego (i być może to jest też przyszłość), że dla naukowca, osoby, która gdzieś tam pracuje na uniwersytecie, jakiejś akademii, która zajmuje się zawodowo nauką – data scientist to może być zawód przyszłości?

V: W ostatnim odcinku mojego podcastu rozmawiałem z Marcinem Możejko o świecie akademickim. Ten świat jest bardzo niejednolity. Jest jeden bardziej związany ze studiami, które ludzie kończą, robią magistra, ewentualnie doktorat. Drugi to jest taki, który tam po prostu zostaje i to jest taki klasyczny świat, który zwykle my kojarzymy w szczególności w Polsce.

A trzeci to jest w ogóle taki świat, który napędza teraz ML, który nie do końca w pewnym sensie uznaje autorytety albo inaczej definiuje autorytety. Teraz mam na myśli, że normalny świat akademicki działa w taki sposób, że żeby publikacje pojawiły się w czasopiśmie, to trzeba naprawdę się postarać, pokłonić troszkę w różnych miejscach i poczekać pewnie 2-5 lat i dopiero wtedy to się pojawi.

Natomiast ten trzeci świat akademicki, taki buntowniczy, on robi tak, że na Twitterze publikuje link i na tym to się kończy. Potem to cytują inne osoby i okazuje, że to się rozpowszechnia tak gwałtownie. To jest według mnie w porządku w kontekście rozwoju. ML sam w sobie to jest w pewnym sensie też buntownik. Taka dyscyplina polegająca na tym, że próbuje wykorzystywać różne obszary – trochę matematykę, fizykę, statystykę, programowanie czyli takie dziecko wielu rodziców, które nabrało wielu różnych komponentów.

W sposób hakerski połączyło to, co działa, a co nie działo, wyrzuciło. Tam dość często nawet nie ma podstaw naukowych, czyli świat naukowy jest nawet do tyłu. To jest paradoks. Zobacz np. na deep learning. Robi teraz niesamowite wrażenie, zaczynając od deepfake’ów albo te głosy, które tam są generowane, o których wspomniałeś w voicebocie – to jest deep learning. 

Deep learning był rozwijany przede wszystkim przez takich naukowców, inżynierów, bardziej nawet inżynierów niż naukowców czyli osoby, które bardziej eksperymentują niż osoby, które na kartce papieru wyprowadzają różne wzory i na podstawie tego wiedzą, że to zadziała. 

Tutaj może trzeba zrobić krok wstecz, bo sztuczna inteligencja, pojęcie samo w sobie, powiło się dawno temu. Co najmniej w latach 50-tych zeszłego stulecia, ona była już sformalizowana, ale jeszcze wcześniej przedtem, w latach 40-tych już się coś zaczęło pojawiać. Jeszcze w 1840 r. Ada Lovelace to była pierwsza kobieta, która była programistą koncepcyjnym, bo wtedy jeszcze nie było komputerów.

Ona już tam rozważała czy komputery potrafią mieć intelekt. De facto to się zaczęło bardzo dawno temu, ale przez dłuższy czas (w szczególności w zeszłym stuleciu) to było bardziej borykanie się naukowo-teoretyczne i to nie zadziałało. Później się przełączyło to trochę w innym kierunku, m.in. dlatego, że pojawiła się moc obliczeniowa i tutaj zaczęły się bardziej odbywać takie rewolucje, które działają jak dzieci: spróbujmy, połączmy to w ten sposób albo w inny. Taki może przykład namacalny: w deep learning jest funkcja Aktywacja.

Cokolwiek by to nie znaczyło, teraz brzmi groźnie, ale to jest funkcja, która jest potrzebna, w środku uruchamiamy ją wiele razy. Klasyczna funkcja Aktywacja wygląda w dość złożony sposób, jest tam jakiś Tanh hiperboliczny. Okazało się, że wystarczy wziąć bardzo prostą regułę, która działa w taki sposób (jak to myśli zwykle engineer, bo ten Tanh hiperboliczny bardzo ciężki jest też w obliczeniach), że jeżeli wartość jest większa niż zero, to zwracamy tę wartość, jeżeli mniejsza, to zwracamy zera i tyle.

Taka funkcja to zwykle maks zera i ta wartość i okazało się, że to działa. De facto to nie jest w ogóle różniczkowalne, tam nie ma ani jednej, ani drugiej pochodnej. Tam jest mnóstwo kłopotów matematycznych, ale to działa. To powoduje te rewolucje, które teraz obserwujemy. To jest niesamowite. To jest taki miks tego, co się tu dzieje. To nie jest tak, że klasyczny naukowiec to wszystko wymyślił i napędził.

Druga sprawa jest taka, że klasyczni naukowcy próbują nadganiać to i wydawać kolejne publikacje, dlaczego to zadziałało. Ale dość często są wciąż dość mocno do tyłu, kilka lat co najmniej, a kilka lat w ML, deep learning to cała wieczność. 

Podsumowując, naukowcy, którzy tylko pracują na uczelni, dość często sami nie są w temacie, mimo że się wydaje, że lepiej na tych tematach się zna. Dość często naukowcy znają się na teorii, potrafią teoretycznie nieźle się wypowiadać, ale jak powiesz im: zrób voicebota, ale na poziomie takim, że zaimplementuj to na poziomie kodu, to zwykle tego nie zrobią.

K: Totalnie mi się nie składało to, że zestawiliśmy naukowców z buntownikami. Gdzieś mi to już trochę nie grało, także dobrze, że to uściśliliśmy. Właśnie, ale zacząłeś mówić, że o AI zaczęto myśleć już dawno, dawno temu. To mi się znowu trochę nie zgadza z tym, o co chcę zapytać w kolejnej części. Jaka jest różnica pomiędzy ML a AI?

Wszyscy chyba znają ten mem, że ML to jest jakiś tam kod pythonowy, a AI to jest po prostu prezentacja w PowerPoincie. A w 1950 r. chyba jeszcze, jeśli dobrze pamiętam, PowerPointa nie mieliśmy, więc ciężko mówić o jakimkolwiek AI. Jaka jest różnica tak naprawdę? 

AI & ML

V: Zamieszanie się wzięło głównie przez dziennikarzy, przez mainstream. Przez to, że te osoby nie do końca wchodziły w szczegóły, a czasem ktoś też chciał to napędzać, więc pewne pojęcia zaczęły się podmieniać. To, co w tej chwili nazywa się AI, to jest zwykłe uczenie maszynowe albo jeszcze mniejszy podzbiór jako deep learning. AI samo w sobie koncepcyjnie to jest znacznie coś szerszego niż uczenie maszynowe.

ML to jeden z rodzajów implementacji AI, ale to nie jest całość. Sztuczna inteligencja, jak sama fraza wskazuje, to jest jakaś inteligencja, która została stworzona w sposób sztuczny. Uczenie maszynowe to jest to, w jaki sposób maszyna może się zacząć uczyć. Sztuczna inteligencja składa się z wielu różnych wymiarów. W ogóle temat jest bardzo ciekawy, złożony, moglibyśmy o tym troszeczkę porozmawiać. 

Pomyślmy: czym jest inteligencja? To jest temat bardzo skomplikowany, nie jesteśmy w stanie zdefiniować w pełni, czym jest inteligencja. Alan Turing w swoim czasie próbował to zdefiniować. Skoro nie powiemy, czym jest inteligencja, to spróbujmy przynajmniej trochę jak z tą kaczką jest: jeżeli się zachowuje jak kaczka, to prawdopodobnie to jest kaczka.

Stworzono wtedy taki test, gdzie były dwa pokoje, sędzia i miał on stwierdzić, czy w danym pokoju tekst rozmowy na kartkach pisany był przez człowieka czy maszynę. Jeżeli nie był w stanie tego poprawnie oszacować, to test był udany. Ten test Turinga akurat jest dość ograniczony, bo można udawać zawsze osobę bardziej ograniczoną intelektualnie albo dziecko i w ten sposób można go zhackować. 

Pójdźmy jeszcze dalej, jeżeli chodzi o inteligencję. Zobacz, że jak obecnie mówimy o inteligencji, to zwykle myślimy o inteligencji ludzkiej, prawda? Ale przecież to nie jest jedyny rodzaj inteligencji. Jest wiele różnych gatunków, np. inteligencja, którą możemy spotkać w oceanie.

Tam są delfiny albo jakieś inne gatunki, które potrafią robić rzeczy, których ludzie nie potrafią zrobić, np. rozmowy na dłuższych dystansach, kiedy mamy połączenie 1:1 czyli to jest podobnie jakby człowiek był w Krakowie, a drugi w Warszawie i potrafiliby komunikować się bez komórki. My nie potrafimy tak robić, a ryby owszem. Są w wodzie, mają też troszkę inne warunki, ale mniejsza o to. 

Jeżeli są co najmniej dwa rodzaje inteligencji (w tej chwili wymieniłem: ludzka i ta w oceanie), to na pewno jest jeszcze wiele innych rodzajów inteligencji. Teraz ta sztuczna inteligencja, która powstanie (a raczej powstanie w ten czy inny sposób), to nie będzie synonimem tej naszej naturalnej inteligencji, a właściwie ludzkiej inteligencji, tylko to będzie jakiś inny gatunek inteligencji. Do tego też trzeba się przyzwyczaić, że w sumie nie do końca wiadomo, jak to można określić, ale to coś powstaje na naszych oczach.

K: A propos powstawania rzeczy na naszych oczach – jakiś czas temu pojawiło się kilka książek, pewnie kilkanaście na temat tego, że należy się bać przyjścia sztucznej inteligencji, bo roboty nami zawładną, bo się staną inteligentniejsze od nas.

Mam nadzieję, że to nam nie grozi, ale sama sztuczna inteligencja zaczyna się pojawiać również w życiu programistów, bo np. mamy ostatnio bardzo głośną premierę narzędzia GitHub Copilot. Tutaj rozumiem taką sztuczną inteligencję wciąż jako narzędzie, jako coś, co ma wspomóc pracę, a nie zabrać ją programistom. Czy właśnie w takim kierunku myślisz, że to cały czas będzie szło, czy może gdzieś tam się wydarzyć coś niedobrego po drodze?

V: Jak zadajesz to pytanie, od razu w mojej głowie kilka takich gałęzi się pojawia, zastanawiam się, od której strony zacząć. A propos niebezpieczeństwa, w tych książkach zwykle mówi się, że powstanie sztuczna inteligencja i pozabija ludzkość, co też wcale nie jest wykluczone. W tej chwili zagrożenie w sumie jest na innym poziomie. Weźmy przychód, który wymieniliśmy na samym początku przy scoringu kredytu, czy to, że ktoś jest kobietą, czarnoskórym albo mieszka w złej dzielnicy, to może sprawić, że dana osoba nie dostanie kredytu. Na podstawie tego różne rzeczy mogą się dziać. Teraz jeżeli takich mikro decyzji zacznie się łączyć coraz więcej, to nagle się okazuje, że losy ludzi są uzależnione od tego, co jakiś algorytm powie.

To już jest niefajne. Popatrzmy na Chiny, choć to jest dość zamknięty kraj, to mają właśnie taki scoring obywatelski. Jeżeli robisz coś niewłaściwie, to wszystko jest podliczane i w jakiś sposób potem egzekwowane, np. masz ograniczony dostęp do konkretnych miejsc czy przywilejów. To nadal nie jest sztuczna inteligencja, która sama zawładnęła ludzkością, ale algorytmy są w rękach pewnych ludzi, którzy mogą wpływać na innych w ten czy inny sposób. To samo w sobie już jest niezwykle duże zagrożenie, o którym wydaje się, że mówi się znacznie mniej, ale to się dzieje na naszych oczach, np. face detection.

Nie wiem, czy ktoś zdaje sobie z tego sprawę, że nawet jak masz maskę, to już po oczach, a nawet po sposobie chodzenia, da się zidentyfikować osobę i potem mając taką informację można robić różne rzeczy.

W Europie jest RODO, które pod tym względem przynajmniej częściowo chroni, ale w innych krajach to jeszcze bardziej się rozpędza. Nie ma co czekać, że powstanie jakiś terminator, który zawładnie ludzkością. Być może ta ludzkość zniszczy sama siebie jeszcze wcześniej. `

Teraz idąc w kierunku programisty. Pamiętam, jeszcze w roku 2018 miałem wykład i mówiłem o Programiście 2.0. Prowadziłem serię prezentacji. One były dość podobne w różnych lokalizacjach, po każdej takiej prezentacji dostałem feedback, rozważałem nad tym, bo trochę też ewoluowała moja prezentacja. Mówiłem tam o kilku ważnych koncepcjach, czyli programista jako zawód raczej zostanie.

Tutaj raczej nie mówimy o tym, że w 100% zostanie wyeliminowany. Ale będą pewne zmiany i to jest też naturalna rzecz. Zresztą jak ktoś pracuje trochę dłużej, przez 5, 10, 15 lat, to wie, jak ta technologia się zmienia cały czas. Język programowania się zmienia i musisz być na bieżąco, żeby mieć pracę. Pojawia się też trochę inny sposób myślenia. Nie wiem, czy zdajesz sobie sprawę, na jakim silniku działa Internet? 40% Internetu działa na jednym silniku. 

K: Naprawdę? O tym nie wiedziałem.

V: To jest WordPress czyli PHP.

K: No tak, oczywiście. Jak się faktycznie nad tym zastanowić, to zdecydowanie.

V: Dlaczego o tym mówię? Kiedyś mnie ktoś zainspirował w mailu. Napisał do mnie w taki sposób, że ja nie jest programistą, ale potrafi zainstalować WordPress i wyklikać różne pluginy. Potem mi zaskoczyły trybiki – przecież o to chodzi, że ten programista przyszłości to będzie taki trochę WordPress.

W takim sensie, że nawet nie chodzi o to, że będzie technologia PHP czy C#, bo będzie język, który jest w tej chwili, ale te klocki będą po prostu się składać. To bardziej się sprowadzi do tego, że będą jakieś podpowiedzi różnego rodzaju. Wtedy nie było tego autopilota jeszcze, ale już o tym mówiłem, że do tego to dąży. Widać ten trend. Widać, że to w tym kierunku idzie.

Jest taka analogia – podczas kryzysu zwykle bogaci robią się bardziej bogatsi, a biedniejsi biedniejsi, a klasa średnia się zmniejsza. Pomyślmy, że w tym przypadku zmienimy jednostkę z pieniędzy na doświadczenie programisty, bo o tym ostatnio rozważałem dość długo. Osoby bardziej doświadczone będą jeszcze bardziej doświadczone, a te mniej doświadczone będą jeszcze mniej doświadczone, a przeciętni programiści mogą być wyeliminowani z rynku, bo nie będą potrzebni. Takie powtarzalne kawałki kodu będą tworzone automatycznie. 

Ten programista, który w tej chwili jest bardziej doświadczony, kiedyś był też mniej doświadczony, kiedyś był juniorem. Przeszedł proces edukacji, zdobył doświadczenie, tylko wtedy to się opłacało. Opłacało się przede wszystkim pracodawcy, czyli był jakiś biznes, który chciał rozwiązać pewien problem, a do tego był potrzebny programista. Ten człowiek sobie szedł przez tę ścieżkę i się uczył i stał się seniorem.

Z drugiej strony temu człowiekowi zwyczajnie się chciało robić pewne rzeczy. Generalnie nasz mózg jest tak skonstruowany, że jest leniwy, oszczędza energię itd. Nowe pokolenie jeszcze bardziej jest nakręcone na to, żeby oszczędzać energię. W wyniku pojawia się dość ciekawa sytuacja czyli z jednej strony pracodawcy już się nie opłaca męczyć się i płacić duże pieniądze, żeby wyedukować tego człowieka, żeby stał się bardziej doświadczony. Z drugiej strony ten początkujący programista zwykle dość często nawet nie chce, bo można robić jakieś inne rzeczy. Jak masz asystenta, który Ci podpowiada, to będziesz go używać i będziesz takim trochę kierownikiem asystentów. 

To jest dość ciekawa analogia. Nie wiem, dokąd to dąży, bo wcześniej o tym nigdy nie mówiłem, ale ostatnio mnie jakoś tak olśniło, że faktycznie osoby na poziomie middle i w kierunku seniora będą zdobywać jeszcze większe doświadczenie i będą bardzo potrzebni, bo zawsze coś będzie się psuło i trzeba będzie to naprawić.

Ale będzie coraz trudniej stać się seniorem w naszym rozumieniu, bo nie będzie za bardzo środowiska, w którym będziesz w stanie przejść tę ścieżkę. To jest moja hipoteza, zobaczymy, czy to się sprawdzi. Wiele rzeczy się zautomatyzuje, tak jak z tym WordPressem. W tej chwili już nie potrzebujesz kogoś wprost, kto będzie Ci pisać od zera WordPress, bo jak pamiętam, jak ja to robiłem kiedyś dawno temu, to jeszcze była taka potrzeba. Teraz jest taki człowiek, który sobie wyklika takie rzeczy i to działa nawet lepiej. W tym sensie, że tam już są ustandaryzowane rozwiązania, sprawdzone na miliardach różnych stron. 

Podsumowując, czy zawód programisty się wyeliminuje? Myślę, że nie, bo tutaj jest jeszcze mnóstwo rzeczy, które trzeba robić manualnie. Wiele rzeczy natomiast się zautomatyzuje. Trzeba zrozumieć jeszcze jedną ważną analogię. Dlaczego tak się stanie? Z punktu widzenia biznesu to jest tak, że płaci się pieniądze po to, żeby powstało rozwiązanie. Jeżeli pojawia się alternatywa, że można płacić mniej i to też będzie rozwiązanie, to wiadomo, jaka będzie decyzja. Biznes ma zarabiać i szybciej się rozwijać – tyle. To bardzo prosta, logiczna decyzja. Jeżeli jest jakaś alternatywna ścieżka, która umożliwia szybszy rozwój, to w tę stronę będziemy zmierzać.

Wrócę jeszcze do autopilota. Ja z C# pracowałem prawie przez 3 lata. Dla mnie to jest dość dużo, bo jak już coś robię, to zwykle robię na maksa. Przeczytałem mnóstwo książek, więc na tyle na ile mogłem, zanurzyłem się dość głęboko. Dla mnie wtedy dość ciekawym odkryciem był ReSharper, to był rok 2012, wtedy za bardzo nie wiedziałem, żeby były jakieś podpowiadaczki. ReSharper to była mega fajna rzecz, kiedy sobie klikałeś i nagle pojawiało się mnóstwo kodu. Mimo tego że literek jest dużo, to de facto fizycznie wpisywałem dosłownie kilka literek, jakieś tam skróty klawiszowe i to się robiło.

Pod tym względem wydaje mi się, że dla C# deweloperów to nie powinna być aż taka duża nowość, chociaż zgadzam się z tym, że ten autopilot będzie w stanie robić więcej niż tylko podpowiadać ten tzw. dot-driven development. Czyli w tej chwili mamy dot-driven development, można spodziewać się w przyszłości czegoś więcej. Ale też trzeba uważać, bo OpenAI to jest taka firma, która z jednej strony ma dobrych inżynierów, ale z drugiej strony ma też świetnych marketingowców. Trzeba na to uważać, bo niektóre rzeczy, o których oni mówią, to jest raczej to, co ma się stać, nie stan obecny. 

K: Tutaj wracamy do tego, jak dobrze marketing potrafi sprzedać sztuczną inteligencję. Zobaczymy, jak to wychodzi. A propos mojego .NET’owego środowiska, ja już byłem zaskoczony, bo w październiku albo w listopadzie będzie premiera kolejnego .NET. Razem z tym .NET powinno wyjść nowe Visual Studio, które już jest w fazie preview, które już można pobrać.

Ostatnio sobie spróbowałem pobrać u siebie na komputerze, pobawić się troszeczkę. Widać od kilku lat taki trend, że samo Visual Studio chce nadgonić to, co robił ReSharper i ten tzw. intellij code jest coraz lepszy. Ja byłem aż zaskoczony, że w tym najnowszym Visual Studio 2022 zaczynam pisać jakiś kod, zaczynam kolejną linijkę i Visual Studio podpowiada mi, jaka ona powinna być, żeby ten kod zadziałał.

To już dla mnie było dosyć niesamowite, że faktycznie w kilku miejscach to oczywiście ma swoje problemy, bo to nie będzie przewidywało dokładnie tego, co chcemy zrobić, ale myślę, że w wielu przypadkach to może komuś uratować tyłek, bo może przypomnieć o jakiejś konkretnej linijce, którą trzeba wykonać, zanim się wprowadzimy inny kod. Także tutaj też idziemy w dobrą stronę.

Machine Learning dla programistów C# – ML.NET

Przejdźmy już do samego „mięsa” dla mojej społeczności .NET’owej. Zacznijmy od pytania: dlaczego Python? Musimy sobie powiedzieć na samym początku, że Python w Data Science, ML rządzi i nie jest to .NET. Dlaczego Python i czy developer .NET’owy, C# jeżeli chciałby spróbować ML, to musi się tego Pythona nauczyć i musi wdrożyć jakąś aplikację Pythonową w swojej firmie? Czy jeżeli mamy cały stack .NET’owy, to możemy to jakoś miło pożenić? 

V: Zacznę od końca. Jakbyś zadał to pytanie rok, dwa, trzy lata temu, to na pytanie czy musi nauczyć się Pythona, moja odpowiedź brzmiałaby, że zdecydowanie TAK. W tej chwili to wygląda inaczej. Jak to się stało, że Python się wystrzelił i stał się w sumie językiem numer jeden? Znów ten argument jest bardzo prosty – BIZNES. Na czym zależy firmom? Na tym, żeby w krótkim w czasie robić więcej rzeczy. Python jest takim językiem, który to umożliwia, bo za pomocą de facto bardzo mało linii kodu jesteś w stanie osiągać bardzo dużo.

Python ma swoje wady i zalety. Zaleta jest taka, że możesz szybko eksperymentować, szybko uruchamiać. Powstał też spory ekosystem np. taka biblioteka jak scikit-learn, która według mnie jest genialną biblioteką, która całkowicie zmieniła oblicze uczenia maszynowego. Ta genialność polega na tym, że ten kto tworzył, na pewno bardzo fajnie ją przemyślał. Przede wszystkim w kontekście architektury, bo uczenie maszynowe samo w sobie jest przyjemniejsze wtedy, kiedy działa jak klocki lego.

Masz model jeden, wpinasz, potem nie działa, wypinasz, wpinasz drugi i przy tym nie zmieniasz wiele kodu np. jedną linijkę. Myślę, że też pamiętasz, jak trzeba było dawniej zrobić sieci neuronowe, to najpierw to się robiło w C++, więc pisało się 200-500 linii kodu i to był tylko model jeden. Jak chcesz napisać model drugi, to tyle samo musisz napisać. To jest totalnie nieużyteczne, nie da się z tym pracować. W scikit-learn to było tak, że wymiana modelu A na B to jest jedna linijka kodu. Jest taki wspólny interfejs, który ma dwie proste metody fit i predict.

To jest genialnie proste, nie ma ani jednej takiej biblioteki przed scikit-learn, która zrobiłaby to na tyle dobrze. Cały ekosystem zaczął się rozwijać i co z tego, że pojawia jakaś alternatywa do Pythona – język Julia. Ten język ma mniej wad, które ma Python, jeżeli chodzi chociażby o wielowątkowość itd., ale nie ma ekosystemu, czyli biblioteki, zależności. To tam gdzieś się rozwija, ale jednak jak chcesz robić M, to potrzebujesz nie tyle języka, potrzebujesz kilka linii kodu i to zaczyna funkcjonować.

Przez to, że Python to zrobił jako jeden z pierwszych i też umożliwia robienie tego w miarę łatwo i szybko, to się zaczęło rozpędzać. Potem podchwycili większych graczy. Google używa Pythona dość regularnie, dość aktywnie w różnych serwisach. Później Uber, Facebook itd. To się zaczęło rozwijać gwałtownie szybko. 

Pod tym względem Pythona już nie da się wyprzedzić. Pomyślmy teraz, jaka jest natura problemów data science? Mnóstwo powstającego kodu pojawia się raz, uruchamia się raz i jest do wyrzucenia albo ewentualnie do archiwizacji, żeby później można było sprawdzić ten eksperyment. Dlaczego tak jest? W data science dużo się eksperymentuje i większość eksperymentów się nie udaje. To jest normalne, że 20 czy 100 eksperymentów się nie udaje, a 1 tak. W takim podejściu, musisz bardzo szybko generować kod, bardzo szybko eksperymentować i dopiero później te mniejsze kawałki wdrażać. 

Tutaj właśnie jest ten problem niestety z Pythonem, bo ludzie, którzy dużo eksperymentują, piszą ten kod tak bardziej na brudno, przyzwyczają się do tego i potem mniej więcej na tym samym poziomie, ten kod próbują wdrażać i to jest problem, bo takiego kodu nie można wdrażać. Też biznes tego czasem nie rozumie. “Przecież jest jakiś prototyp, więc już można to wdrożyć.”

Gdzieś ta edukacja powinna być uruchamiana i chyba teraz już jest coraz większe zrozumienie. Wydaje mi się, że właśnie ludzie z otoczenia programistów mogą pomóc, a po drugie języki, które są bardziej dostosowane do skali. Jeżeli owszem mamy problem mniejszy, to możemy to wdrożyć w Pythonie. Czasem jednak jeżeli mamy, powiedzmy enterprise, większe projekty, to problem skali może nas tam gdzieś zjeść, chociaż to nie zawsze jest prawda. Czyli nawet w Pythonie też można fajnie się skalować.

Ale jeżeli mówimy o produktach enterprise, które są napisane np. w Javie albo C#, to co miałeś wcześniej do wyboru? Do wyboru miałeś wstawianie mikroserwisu i REST API albo bazy danych, o których mówiłem, że np. do bazy danych się wpisuje wyniki. To czasem działa, ale czasem potrzebujemy coś mieć w czasie rzeczywistym. 

Jeżeli chodzi o Java, to było na tyle łatwiej, że tu jest mnóstwo takich Spark i innych podobnych rzeczy, więc dało się to już integrować, ale w C#, .NET było to znacznie bardziej skomplikowane. Faktycznie wcześniej nie było za bardzo możliwości jak tak zrobić, aby nie powstała kolejna rzecz w stacku. Teraz wybór jest i to, co zrobił dobrze Microsoft, to właśnie pojawiła się biblioteka ML.NET.

Ja o tej bibliotece wiedziałem już jakiś czas temu, bo ona pojawiła się w roku bodajże 2018. Ale jak się odezwałeś to pomyślałem, że to jest dobra okazja, żeby zbadać co się dzieje w świecie C#. Więc to zrobiłem i byłem pozytywnie zaskoczony, że faktycznie to dojrzało do ciekawego poziomu.

Zobacz, jeżeli w tej chwili chcesz zacząć wdrażać uczenie maszynowe w .NET, nie wychodząc ze świata .NET – jest to możliwe. Mało tego, poziom tego rozwiązania naprawdę będzie bardzo wysoki, bo z jednej strony ekosystem też już się pojawił w bibliotece ML.NET. Tam jest mnóstwo algorytmów, nie wszystkie owszem, ale wystarczająco dużo. Są takie algorytmy dla klasyfikacji, regresji itd. Widać, że osoby, które to robiły, myślały bardzo szeroko. Są jeszcze elementy, których brakuje, ale to wynika ze złożoności problemu.

Tyle to trwa bez względu na to, że jesteś Microsoftem. Oni zrobili po prostu rozszerzenie czyli np. jest taka biblioteka LightGBM. To jest w sumie biblioteka Microsoftu, ale bardziej była stworzona do integracji z Pythonem i Arcome. Tam się to integruje od dawna i to działa. Ale nie było dobrej integracji z .NET. Może to dziwić, ale tak to było. Obecnie już ta integracja się pojawiła. LightGBM faktycznie jest bardzo dobrą biblioteką, jedną z najciekawszych jeżeli chodzi o klasyczne uczenie maszynowe. 3 najciekawsze według mnie: XGBoost, CatBoost i LightGBM. 

Jest jeszcze ONNX. Idea polega na tym, że trenujemy model w czymś innym np. TensorFlow, PyTorch czyli zupełnie inne biblioteki, które są oderwane od .NET. One są napisane na innych technologiach, można też trenować na poziomie Pythona. Później to zapisujemy jako plik binarny i możemy odczytać już w .NET i uruchomić.

Działa to w taki sposób, że istnieją formaty przenośne, języki uniwersalne, które potrafią tę wiedzę, którą model wytrenował, przenieść i odpalić na poziomie .NET. To jest niesamowite. W tej chwili ta wiedza, nasze rzeczy, które już powstały na poziomie TensorFlow, PyTorch to są w sumie najważniejsze biblioteki w deep learningu, które mocno konkurują pomiędzy sobą. Dzięki temu to jest fajne dla końcowych użytkowników, bo się coraz więcej rzeczy w krótkim czasie odbywa. Takie najnowsze osiągnięcia można po prostu sobie pobrać i uruchomić.

W tej chwili np. nie ma problemu, żeby robić rozpoznawanie zdjęć, wykrywanie twarzy, obiektów. To oczywiście od dłuższego czasu można było zrobić na Azurze, czyli wysyłasz przez REST API, ale to ma swoje wady, bo musisz przez API coś wysyłać, musisz się dzielić swoimi danymi. Też nie zawsze to się skaluje, jeżeli chodzi o koszty, jak tych obrazów masz nieco więcej. Warto też zaznaczyć, że to jest technologia, która nie jest Twoja, bo nie wiesz, czy jutro Azure tego nie zamknie albo nie zmieni, albo nie podniesie ceny, albo jeszcze coś innego.

Teraz nawet nie chodzi o Azure jako tako, tylko bardziej o provider. Nie masz nad tym kontroli. Wszystko może się wydarzyć, więc zawsze chcesz w pewnym sensie mieć to rozwiązanie gdzieś bliżej siebie. W tej chwili jest to możliwe, przynajmniej częściowo. Możesz odpalić to lokalnie, Twoje dane nigdzie nie wypływają i co najważniejsze to jest w 100% technologii .NET, czyli nie musisz stawiać żadnych mikroserwisów. Też to dość szybko się rozwija. Jak wczoraj patrzyłem, 20 dni temu wyszedł kolejny release 0.6.

Ciekawostka jest taka, że sami .NET’owcy nie potrafią tego docenić, bo z jakiegoś powodu Microsoft tego jeszcze nie promuje. Nie wiem, czy to jest taka strategia. Być może nie ma pieniędzy na marketing. Ale jeżeli chodzi o dojrzałość tego projektu i efektywność, to mogę potwierdzić, że to jest ciekawe i można tego używać. Ja osobiście tego nie używałem na produkcji, bo nie mam w tej chwili .NET. Microsoft sam się chwali, że używa to u siebie na produkcji w Windowsie, Excelu itd. 

Jeszcze jedna rzecz odnośnie biblioteczki. Oni to robili z myślą o skali. Widać, że np. Python ma problem ze skalą. Można to rozwiązywać na różne sposoby, ale mówiąc w skrócie – ma problem. Można coś z tym zrobić, ale domyślnie problem istnieje. Tutaj widać, że biblioteka była przemyślana w taki sposób, aby uruchamiać to na skalę – na miliony, miliardy wierszy, na dużą liczbę danych. To myślę, że w większości projektów w przypadku .NET’owców, którzy pracują właśnie na dużych projektach czyli jakieś banki, instytucje finansowe, to jest świetna wiadomość.

K: Z tym, jak Microsoft w ogóle podchodzi do promowania różnych rzeczy, to mam sam też takie przemyślenie, że ostatnimi czasy Microsoft zdecydowanie promuje weba i samego Clouda, bo widać po prostu, że to im najlepiej wychodzi. To między innymi widać po ankietach na stackoverflow, że ASP.Net Core jest w tej chwili najbardziej uwielbianym frameworkiem webowym, więc faktycznie zaczynają robić to dobrze i myślę, że jak faktycznie sami będą mocno zadowoleni z tych narzędzi ML’owych, to pewnie zaczną też bardziej w to iść.

Tak naprawdę to jest to, co ja nieraz mówiłem, zresztą w ostatnim odcinku mojego podcastu, że sam .NET daje nam olbrzymie możliwości programowania na desktop, urządzenia mobilne, weba i ML. Natomiast aż tak dużo się jeszcze o tym nie mówi ze względu na to, że właśnie machine learning to głównie Python i pewnie tak zostanie. Wciąż ML.NET to będzie nisza, ale tak jak mówisz fajnie, że to może być taka nisza ciekawa dla programistów .NET’owych.

Vladimir, myślę, że na tym możemy jeszcze w tej chwili zakończyć, bo wiem, że moglibyśmy długie godziny jeszcze rozmawiać. Tak naprawdę, jakbyśmy usiedli sobie na spokojnie to 3, 4, 5 odcinków samego podcastu i dla Ciebie, i dla mnie moglibyśmy z tej rozmowy zrobić. Zostawmy sobie coś na przyszłość. 

Powiemy o tym, o czym zaczęliśmy rozmawiać tuż przed nagraniem? 

V: Tak, właśnie na koniec, już podsumowując. Przy okazji wspomnę, że w ML.NET trzeba pisać kod, ale też jest coś takiego jak ML Build. Więc przynajmniej znajdź, co to jest ML Build, będą też w notatkach linki i spróbuj to uruchomić. Wystarczy poklikać i zobaczysz, jak już to działa. Od razu uprzedzę, że w tej chwili jeżeli człowiek rozumie, jak działa machine learning, to wykorzystanie ML.NET jest w porządku, bo rozumiesz, co to oznacza, rozumiesz, jak to się konfiguruje itd.

Natomiast ja w tej chwili ML.NET traktuję raczej jako narzędzie dla osób, które pracują w .NET i chcą to wdrażać bez żadnych kłopotów, a nie do eksperymentowania, bo eksperymentować nadal będzie łatwiej w Pythonie.

Ale najfajniejsze jest to, że w tym przypadku to otwiera większe możliwości, że w tej chwili osoba, która pracuje w .NET, już nie będzie miała takich wymówek albo ograniczeń, że nie będziemy wdrażać Pythona, bo nie ma jak. Nawet jeśli pracujesz jako developer, spróbuj użyć ML i po prostu pokaż swojemu szefowi, że Ty jesteś w stanie dostarczyć więcej wartości. Bo jeżeli pójdziesz do niego i powiesz: użyjmy ML, to on prawdopodobnie powie nie. Ale jeżeli zrobisz sam, trochę tak po godzinach, bo masz dostęp do danych, jakiś taki projekt hobbystyczny, minimalny, to możesz zobaczyć, jak Twoje życie się odmieni.

Nagle wzrośniesz, będziesz pierwszy ML’owcem, data scientistem, dostaniesz podwyżkę itd. Ale też będzie to dla Ciebie bardzo ciekawe, bo się rozwiniesz. 

Zastanawiam się nad takim czymś, żeby dać wsparcie i pomóc deweloperom, programistom poznać uczenie maszynowe. Mają oni swoje zalety, mocne strony czyli potrafią programować, ogarnąć cały komputerowy świat, ale z drugiej strony może im zabraknąć wiedzy ML’owej, żeby to zrozumieć i stosować. Nawet nie tyle, żeby zrozumieć bardzo głęboko, bo nie chodzi o to, żeby wymyślić nowe algorytmy, tylko zrozumieć na tyle, aby umieć to opanować i zacząć to stosować.

To jest podobnie jak kierowca i mechanik. Kierowca nie musi rozumieć w 100% jak działa silnik, ale musi rozumieć, że tam jest kierownica, pedały, trzeba wcisnąć, czasem zahamować. To nie jest aż takie trudne, da się tego nauczyć, ale trzeba przejść ten kurs. 

Pojawił się taki pomysł, jeżeli zbierze się zainteresowana grupka, np. 50 osób, żeby zrobić kolejny webinar albo kolejną inicjatywę, gdzie trochę podpowiem Ci jak Ty jako osoba, która zajmuje się programowaniem np. C# albo w ogóle programowaniem, możesz pójść do przodu.

Ilość informacji w Internecie jest za duża. Tyle tego się leje na nasze biedne mózgi, że człowiek nie będzie w stanie filtrować tego, co istotne. Jeżeli zbierze się taka grupa zainteresowanych np. 50 osób, to mogę zorganizować taki warsztat, webinar, na którym pokażę więcej jak zastosować uczenie maszynowe jako programista. Koniecznie się zapisz.

K: Miejmy nadzieję, że zbierze się jak największa liczba zainteresowanych. Jeszcze w tej chwili nie będziemy mówili o żadnych terminach. Terminy sobie spokojnie dogramy, jak faktycznie zobaczymy, że będzie zainteresowanie. Na pewno tak myślę, że spokojnie możemy powiedzieć, że nie będzie to wcześniej niż we wrześniu, bo też jeszcze cały czas jesteśmy w sezonie urlopowo-wakacyjnym, także dajmy sobie spokojnie trochę czasu.

Natomiast zapraszamy na to, żeby poznać ML. Vladimir jest świetnym specjalistą w tej kwestii, więc na pewno bardzo delikatnie i z czułością wprowadzi w te tematy. Tutaj zgłoś się na warsztat.

Tym samym jeszcze raz chciałem Tobie Vladimir podziękować za to spotkanie. Podziękować za to, że zgodziłeś się ze mną porozmawiać i mnie również wprowadzić w tematy ML’owe. Jak zwykle, ja sam się bardzo dużo nauczyłem, więc domyślam się, że dla naszych czytelników będzie to jeszcze ciekawszy odcinek. W takiej sytuacji do usłyszenia gdzieś kiedyś w Internecie cały czas.

V: Dzięki wielkie za trafne pytania i do usłyszenia. Cześć.

Bardzo jestem ciekawy Twojej opinii co myślisz o takich eksperymentach, żeby co jakiś czas to właśnie ktoś mi zadawał pytania, a ja będę odpowiadał? Niekoniecznie to musi być programista, bo teraz właśnie eksperymentujemy, żeby były różne osoby. Być może kolejną osobą musi być ktoś z biznesu.

Jeżeli według Ciebie taki format ma sens, jest to wartościowe, daj koniecznie znać w wygodny dla Ciebie sposób – albo na pocztę, albo w social media, albo jakkolwiek wolisz dotrzeć np. gołębiami Dzięki temu będziemy wiedzieć, jak się rozwijać dalej. Wydaje mi się, że takie eksperymenty mogą mieć sens, natomiast warto też zrozumieć, w którym kierunku robić większy nacisk i które perspektywy w tej chwili są najciekawsze.

Na koniec mam jedną prośbę, poleć przynajmniej jednej osobie ten odcinek, bo może być to ciekawe i wartościowe dla tej osoby. 

Artykuł Czy developer potrzebuje Machine Learning? pochodzi z serwisu Biznes Myśli.