Patryk Pilarski - Ciemna strona Data Science

Cześć, z tej strony Łukasz Kobyliński. Witamy w kolejnym odcinku podcastu Stacja IT. Dzisiaj porozmawiamy o ciemnych stronach data science. Pojęcie to pojawiało się już wielokrotnie w naszym podcaście, mówiliśmy o jego plusach i minusach, o tym, dlaczego to jest fajne, czy warto zostać data scientistą, a dzisiaj spojrzymy na nie od strony negatywnej, czyli przyjrzymy się temu, co w data science może denerwować. A z nami jest osoba, która chce pomarudzić na data science, czyli Patryk Pilarski.

Cześć, Patryk!

Cześć. Tak, jestem oficjalną „marudą”.

Powiedz, jak to się stało, że zostałeś taką „marudą” w kontekście pracy, którą wykonujesz.

Właściwie to przebranżowiłem się, zanim jeszcze skończyłem się uczyć. Moje doświadczenia zawsze były związane z danymi – z data science. Zawsze miałem wyobrażenie tego, jak IT czy też później data science wygląda, a było to oczywiście wyobrażenie człowieka z zewnątrz. I rzeczywistość okazała się nie do końca taka sama jak wyobrażenia na temat tego, jak ludzie z zewnątrz myślą o tych zagadnieniach. Te dysonanse to są rzeczy, na które można – i czemu by nie – pomarudzić.

A co robisz na co dzień, gdzie pracujesz?

Obecnie pracuję w firmie jako data inżynier, do tego jestem trenerem Sages, można mnie spotkać na różnych zajęciach, eventach, jak również na studiach podyplomowych na Politechnice Warszawskiej, gdzie prowadzę zajęcia m.in. ze Sparka. Moje wcześniejsze stanowiska zawsze w nazwie miały „data science”.

Czy data scientist, data engineer to ciekawe zajęcia czy zdarzają się tam gorsze dni, a jeśli tak, to na czym polegają?

Generalnie są to bardzo ciekawe zajęcia. Gdyby takie nie były, to zmieniłbym swoją działkę już jakiś czas temu. Generalnie zarówno data science, jak i data engineer – inżynieria danych, są to zdecydowanie ciekawe działki. Jeśli ktoś lubi problemy, a ja je lubię – takie, które jestem w stanie zrozumieć – to są to działki, które dają spore pole do popisu. Mój shift z data science w kierunku inżynierii danych wiąże się z tym, że właściwie zawsze najwięcej zabawy dawało mi paplanie się w danych. Wyliczanie w kółko średnich i odchyleń statystycznych jest jak najbardziej wartościowe, ale zamarzyło mi się nieco bardziej ustrukturyzowane podejście do danych i skoncentrowanie się na tym, jak dostarczyć je do analizy, szczególnie że zajmowałem się tym również na poprzednich stanowiskach, tylko niejako bardziej obok zajęć stricte związanych z analizą i analizą predykcyjną danych.

Jak to porównujesz? Wiele osób skarży się, że zatrudniają się jako data scientist, jako człowiek do analizy danych, od modelowania, a tak naprawdę robią coś innego, przewalają dane z lewej na prawą – dla ciebie to też jest fun, ale czy to faktycznie jest tak, że większość tego data science to przewalanie danych, do czego trzeba się po prostu przyzwyczaić?

Myślę, że tego typu problem wynika z tego, że data science to base word, które nic nie znaczy. To jest tak szerokie pojęcie, właściwie każdy, kto kiedykolwiek dotknął danych, może powiedzieć, że zajmuje się data science. Brakuje mi trochę nadania ram temu pojęciu. Co prawda zdarzają się próby podzielenia tej działki na data scientistów, MLN inżynierów, analityków, data inżynierów, architektów danych, dałoby się z tego wydzielić jeszcze całą rzeszę innych ról, aczkolwiek trzeba osiągnąć pewien poziom dojrzałości organizacyjnej, żeby takie role wydzielić. W większości sytuacji, gdy widzimy jakieś ogłoszenia, poprzez które poszukuje się pracowników, to mówią one szeroko, że szukany jest ktoś na stanowisko data science. I wiąże się to z pewnym problemem, a mianowicie takim, że jednak wiele osób, które zaczyna z data science, myśli, że będzie budowało modele. Ale ja się trochę śmieję, że część ludzi myśli, że data science równa się tak naprawdę model science, ale ta „data” w nazwie jest jednak, jak dla mnie, słowem kluczowym. Więc owszem, w wielu sytuacjach ludzie później kończą na tym, że przewalają te dane z lewa na prawo, w bardziej odtwarzalny i poprawny sposób czy też bardziej ad hocowo.

Myślę, że z takiej sytuacji się jednak nie wybrnie przez dłuższy czas, dopóki ta działka nie okrzepnie, nie wydzielą się role. Role pewnie można spotkać, ale w firmach, które zajmują się danymi, analizą przez długi czas. Kiedy trafiamy do firmy, której chcą wprowadzić do oferty coś z data science, dodać coś do swojego produktu, to szukają data scientisty, ale tak naprawdę szukają tego full stacka, człowieka, który ogarnie te wszystkie pozycje, a to się jednak wiąże z tym, że tak naprawdę budowanie modeli to bardzo mała cząstka zajęć niezbędnych do tego, żeby móc mówić o jakimkolwiek modelu. Więc nie dziwi mnie fakt, że ludzie, startując na pozycji data scientist, kończą na taplaniu się w danych. Dla kogoś, kogo to nie bawi, będzie to przykre wydarzenie, aczkolwiek myślę, że komuś takiemu jak ja, dla kogo dane i myślenie o tym, jak je przenieść z punktu a do punktu b, jak je przekształcić w sposób odpowiedni, żeby to jeszcze było sprytne i wydajne, daje to fun, bo to jest świetna zabawa.

Czyli krótko mówiąc, twierdzisz, że to wynika z rozminięcia oczekiwań z rzeczywistością. W sytuacji, w której rynek nie jest jeszcze tak dojrzały, jak rynek programistyczny, gdzie ten podział na role jest może silniejszy, chociaż nadal full stack developer to istotna rola, w wielu miejscach takie osoby są potrzebne. Skoro tobie to taplanie w danych się podoba, to powiedz, jak znaleźć w tym fun, jakie elementy tu istniejące mogą wciągnąć i jakie problemy warto rozwiązywać?

Lubię wyzwania, które są chociaż w jakimś stopniu zdefiniowane. Na przykład mam za zadanie przekształcić dane w taki a taki sposób i przenieść w to i to miejsce. Więc mam ogólny obraz tego, co jest do zrobienia, ale żeby to osiągnąć, jest tyle różnych sposobów i narzędzi oferujących wiele fajnych rzeczy, z których człowiek może dowiedzieć się naprawdę sporo. Jednak wydaje mi się, że żeby móc się w tym świecie dobrze bawić, trzeba mieć dość szeroką wiedzę, tak żeby choć się orientować. Na przykład potrzebuję coś zrobić, więc narzędzia, na które powinienem popatrzeć, są takie i takie, i później skoncentrować się na tych najbardziej odpowiednich. To jest taka część eksploracyjna. Ja lubię się uczyć, więc posiadanie czegoś, co mnie nakierowuje w taki czy inny sposób na to, czego jeszcze nie wiem, czego mógłbym się nauczyć, jest dla mnie fajną sprawą.

Pracując z danymi na dalszych etapach, natrafiamy na wiele wyzwań programistycznych. Więc jeśli ktoś – a mam nadzieję, że wszyscy – stara się napisać kod jak najlepiej, to wchodzimy tutaj w jakieś zagadnienia typu software craftsmanship czy inne, próbę robienia swojej roboty w jak najlepszy sposób. Więc OK, mamy narzędzie, wiemy jakie jest do niego API, ale teraz potrzebujemy od nowa napisać skrypt czy bardziej poważny kod, który wykorzysta to API i wykona zadane zadanie. I to jest kolejna rzecz: człowiek musi założyć kapelusz developera, software developera i myśleć, w jaki sposób to zrobi, żeby było dobrze. I generalnie to jest później na wielu różnych poziomach: OK, muszę przenieść te dane, ale wypadałoby zastanowić się, do czego one będą potrzebne. Pierwotny plan polegający na tym, że dane mają wyglądać tak a tak nie jest perfekcyjny, ponieważ będą wykorzystywane do tego i tego, co może wiązać się z tym, że ten kształt nie będzie idealny. Więc na wielu różnych płaszczyznach znajdzie się tu punkty zaczepienia, nad którymi można pochylić się, zastanowić, spróbować rozwiązać, a jak człowiekowi udaje się coś rozwiązać, to zawsze daje mu to satysfakcję.

Czy uważasz, że w tej inżynierii danych większą rolę odgrywa wykorzystanie odpowiednich narzędzi, wyszukiwanie ich? Przynajmniej mi się to kojarzy z tym, że jak robimy to modelowanie, to bardzie myślimy, jak dopasować algorytm do problemu. W inżynierii danych to jest częściej kwestia odpowiedniego wykorzystania narzędzi, dobrego ich poznania, co rodzi fun, żeby poznać coś, co usprawnia tę pracę i pozwala zrealizować ją bardzo szybko.

Ja bym powiedział, że dużą częścią modelowania jest znajomość narzędzia. Bądźmy szczerzy, wiele problemów ML-owych jest dość klasycznych, jasnych. Musimy w trochę inny sposób przygotować dane, lecz w wielu sytuacjach nie ma co wymyślać koła na nowo, trzy linijki, scikit learn, liniowa regresja i heja. Więc znajomość API, czyli znajomość narzędzia, też jest wystarczająca. Przy inżynierii danych jednak ta znajomość narzędzi jest bardziej wyeksponowana, ponieważ przeniesienie danych z punktu a do punktu b albo przetworzenie ich w taki a taki sposób można wykonać na wiele sposobów. I wiele z nich będzie wątpliwa, nieskalowalna i wolna. Więc trzeba się tu orientować, jakie mamy opcje, żeby wybrać tę mającą sens i niewymagającą np. przepisania jej jeszcze raz, bo po tygodniu dostaliśmy dwa razy tyle danych.

Wiąże się to też z data science i z modelowaniem. Tam niestety to nie jest tak wyeksponowane, że: OK, pandas jest fajny, ale jest gdzieś jakiś jego limit, więc może trzeba by było pomyśleć o tym, że moje dane nie zmieszczą mi się całe w ramie, że może potrzebuję jakiegoś generatora, który stopniowo będzie przekazywał dane do trenowania modelu. Takie rzeczy też trzeba uwzględniać i to jest jedna z rzeczy, na którą można pomarudzić. Nie jest to szczególnie częste, żeby ludzie, budując model, od razu myśleli o wyzwaniach przyszłości i o wyzwaniach sukcesu.

Dotknęliśmy jednej ciemnej strony data science, czyli tego, że oczekiwania osób, które starają się o pracę w tym obszarze, często rozmijają się z rzeczywistością, bo ludzie ci robią coś innego niż się spodziewałi. Powiedz, co jeszcze cię denerwuje w data science?

Denerwuje to mocne słowo, aż tak mocno tego nie doświadczam. Powiedziałbym bardziej, co mnie smuci i irytuje. Generalnie jest to działka, która mnie interesuje, więc chciałbym, żeby była perfekcyjna, idealna. Natomiast nie jestem wielkim fanem przeświadczenia, że model to najważniejsza rzecz na świecie. Często ludzie podchodzą do problemu, w ogóle nie zastanawiając się nad tym, czy model jest potrzebny. Bądźmy szczerzy, w wielu sytuacjach wystarczy odrobina kodu i nieco bardziej złożonej logiki, i jesteśmy w domu. Więc ludzie często zaczynają od modelu, co wg mnie i nie tylko mnie nie jest szczególnie dobrym pomysłem. Można zrobić tu delikatną analogię do tego, że jak w pewnym momencie na świecie pojawił się rentgen, w Ameryce tak bardzo byli nim zachwyceni, że aż używali go przy sprzedaży butów. Mówili ci: „Zrobimy ci zdjęcie rentgenowskie stopy, żeby dopasować perfekcyjnie twoje buty”. Teraz wiemy, że nie jest to szczególnie dobry pomysł. Znajdujemy się w podobnym położeniu, tym razem z AI, z mashine learningiem. Próbujemy wcisnąć go wszędzie, czy ma to sens czy niekoniecznie.

Rozumiem, że powiedzenie: „Nasz produkt, nasze rozwiązanie jest oparte na AI”, brzmi lepiej i będzie się lepiej sprzedawało, natomiast może powoli nadchodzi czas, w którym warto byłoby trochę mniej mydlić klientom oczy i skoncentrować się na tym, żeby produkt, który tworzymy, działał poprawnie. Jeśli nie używamy AI, to nie mówmy, że go używamy. I nie twierdźmy, że AI jest narzędziem do wszystkiego, bo nie jest. Można się spotkać z przykładami, w których ludzie próbują wykorzystać AI do czegoś, z czym klasyczne metody radziły sobie już od dawna. Ludzie próbują wrzucić deep learning zupełnie wszędzie. Rozumiem to pod kątem akademickim – researchu, ale kiedy ktoś wrzuca na produkcję próbę rozwiązania problemu komiwojażera opartą na deep learningu, gdzie research mówi, że właściwie nie umywa się do klasycznych metod, to uważam to za nieszczególnie szczęśliwy pomysł. Więc to jest podejście, w którym model jest celem samym w sobie, a nie drogą prowadzącą do celu.

To może wynikać z hajpu na finansowanie tych wszystkich startupów i firm, które mają na swoim szyldzie napisane, że robią sztuczną inteligencję. W internecie pojawił się ostatnio mem, który głosi, że „robimy sztuczną inteligencję”, a w środku jest tam seria IF-ów. Więc można faktycznie wpychać te modele mashinelearningowe w każde rozwiązanie, nawet jeśli to jest bez sensu – będą gorzej działać niż ta seria IF-ów czy jakiś tam znany od dawna algorytm.

Często nie tyle potrzebny jest data scientist, co IFS developer. Więc to jest jedna z rzeczy. Kolejna to to, że ludzie zajmujący się data science myślą, że zajmują się model science, czyli wciąż to przesuwanie tego modelu na pierwsze miejsce. Nie jest to prawda. Ja rozumiem, skąd takie podejście może się wywodzić, bo jednak takie modele są ekscytujące, w wielu sytuacjach są widowiskowe: „O, w nowym Paperze pojawił się model, który robi x, y, z”. To brzmi dobrze, człowiek chce odtworzyć coś takiego, plus to są techniczne umiejętności: dane wyglądają tak, przetwórz je w taki i taki sposób, przygotuj sobie model w taki i taki sposób i otrzymasz wynik. Więc to jest coś, co ludzie poznają, ucząc się tego fachu, ucząc się modeli, tego, jak je budować. Nie da się za bardzo w ławkach szkolnych ludziom przekazać, że te wszystkie widowiskowe rzeczy, których nauczyli się o modelach, to nie jest coś, od czego się zaczyna. Zaczyna się najpierw od zrozumienia problemu biznesowego, zważenia kosztów i zysków. Czy podejście, w którym może i bez tego mashine learningu nasze wyniki staną się nieco gorsze, ale ze względu na utrzymanie tego całego narzędzia będziemy w stanie to po prostu zrobić, nie jest lepszą opcją niż zbudowanie narzędzia, które jest nieutrzymywalne w żaden sposób. To przychodzi z czasem. I nie ma zbyt wielu przykładów ani tylu doświadczonych data scientistów, którzy mogą tę wiedzę przekazać nowym osobom. Trudno oczekiwać, żeby była rzesza data scientistów z 50-letnim doświadczeniem, zważywszy na czas, od którego pojęcie to występuje. Ciężko jednak znaleźć takie informacje. Na konferencjach nikt nie mówi o wszystkich informacjach, kiedy firmy, dojrzałe w kwestii przetwarzania danych, zrezygnowały z podejścia opartego o mashine learning, bo kto przyjdzie na wystąpienie, na którym ktoś powie: „O, tutaj mamy 10 przykładów, kiedy nie użyliśmy maschine learningu. Zobaczcie, co używaliśmy zamiast tego”, „Tutaj napisaliśmy if-else’a, a tutaj case when”. Więc nie jest to tak wyeksponowane, przez co zakrzywia percepcję, w której model to rzecz najważniejsza.

To, co mnie osobiście smuci, to nadużywanie notebooków. Notebooki są wspaniałym narzędziem, ale mają swoje limity. Nie możemy pisać całości naszego kodu jako strumień świadomości w jednym, wielkim notebooku i oczekiwać, że to nasz produkt, który dajemy na produkcję i od teraz nasza aplikacja będzie działała, i mamy mashine learning, deep learning, i projekt mamy gotowy. Nie, tak to nie wygląda. Trzeba jednak eksperymentować wygodnie w notebookach, ale gdy przychodzi moment, w którym wydaje się, że natrafiliśmy na coś, co działa, to trzeba jednak to przepisać na kod, który jest utrzymywalny, który działa, dorzucić unit testy, opracować, jak to ma iść na produkcję. 

Wiąże się to z kolejnym problemem, który mnie nie cieszy, mianowicie wiele osób uważa, że ich jedyną rolą jest zbudowanie modelu. Zbudowałem model, nic więcej mnie nie obchodzi. Produkcja, ale jak to? Przecież ja tu modele przyszedłem budować. Wydaje mi się, że tak to nie może działać w większości organizacji. W organizacjach dojrzałych, w których mamy rozdzielone zadania – w porządku. Najpierw trzeba trafić do takiej organizacji, wtedy możemy tak działać, jeśli tak działa dany zespół. W większości sytuacji takie myślenie jest zgubne, ponieważ powstaje wtedy przepaść. Mamy człowieka lub zespół, którzy zbudowali model, i mamy później biednych programistów, developerów, którym to przyjdzie w jakiś sposób wziąć te notebooki oraz ten gąszcz kodu używającego API, którego nie znają w żaden sposób, i opakować, przerobić w coś, co będzie działało i nadawało się na produkcję. Tę przepaść należałoby jednak wypełnić. W software developmencie pojawiła się jednak ta idea DevOpsów. Myślę, że software development istnieje dłużej niż data science, ale te wzorce powinniśmy zaczerpnąć im wcześniej, tym lepiej. Żeby jednak przejąć ten ownership, żeby właśnie myśleć nie tylko o tym, żeby wyłuskać tu te 110% accuracy, ale żeby to, co robimy, mogło być użyte. Mnie osobiście najbardziej bawią rzeczy, które są używane na koniec. Budowanie modelu dla samego modelu jest fajną zabawą na jakiś czas, ale mnie nie daje to frajdy na tyle, żebym chciał się w to bawić.

Może jest to problem systemu edukacji, bo w związku z takim silnym podziałem na kierunki czy specjalności studiów – albo uczymy się programowania, albo przetwarzania danych – brakuje tych ludzi pośrodku – tych, którzy rozumieliby data science, ale też wiedzieli, jak to wdrażać. Ta luka powoduje, że tak nie bardzo komu jest to robić, dopiero trzeba się tego nauczyć w praktyce.

Tak, z tym że jeśli popatrzymy na różne zestawienia w internecie odnośnie tego, na jakich stanowiskach jakie skillsy są wymagane, to wynika z nich, że te data sciencist powinien jednak umieć to wszystko. Ja rozumiem, że my wszyscy jesteśmy ludźmi, ale tu nie chodzi o to, żeby od razu każdy, kto zajmuje się data science, był developerem z 20-letnim doświadczeniem, znał wszystkie najlepsze praktyki i jeszcze zbudował sobie PyFraME. Chodzi o to, żeby patrzeć na to jakoś bardziej całościowo, że jednak to, co buduję, jest wartościowe, ale jest to część większej całości. Więc mimo że ja się nie znam na tym, jak to powinno być do końca wkomponowane, to może zacznę rozmowę z ludźmi, którym przyjdzie to na koniec wdrożyć, jakie oni widzą opcje, w jaki sposób można ten kod ustrukturyzować, tak żeby było im łatwiej. Takie proste rzeczy. Bo inaczej taki data scientist celuje tylko w budowanie modelu i nigdy nie przejmuje się tym, co dzieje się dalej, w moim odczuciu stając się takim „mózgiem w słoiku” – ma wielkie myśli, tworzy wspaniale rozwiązania, nieużywalne jednak w żaden sposób – to jest dość smutne.

Jako przykład można podać coś, co w dużej mierze się teraz sprawdza, przynajmniej eksperymentalnie, i co jest dosyć szeroko stosowane, to znaczy douczanie tych wielkich modeli służących do analizy obrazów czy do analizy języka naturalnego, które zajmują megabajty, gigabajty. Pytanie: czy w każdym kontekście da się to wykorzystać w praktyce? Jeśli z góry nie pomyślimy o tym, że ma produkcyjnie działać, to może się okazać, że to wszystko, co wytworzyliśmy, jest do wyrzucenia, bo np. nie ma takiej pamięci na telefonie komórkowym.

Porozmawiajmy teraz o tym od strony pozytywnej. Co możemy zrobić, żeby takich problemów z przeniesieniem tych prac eksperymentalnych na produkcję było mniej? Mówisz, że to powinni robić jednak data scientiści, to jest też oczywiście rolą edukacji oraz jakiegoś podziału ról. Ale jak to można poukładać od strony organizacyjnej, żeby nie zderzyć się z tego typu problemem, że robimy projekt, którego nie da się wytworzyć?

Generalnie trzeba budować tę świadomość, że jeśli człowiek widzi ogłoszenie data scientist w firmie, która buduje dopiero zespół, który nie ma być w zamierzeniu czymś wielkim, nastoosobowym zespołem, to trzeba przyjąć, że taka osoba jednak będzie musiała się zajmować tak naprawdę wszystkim, co jest jak najbardziej wspaniałą rzeczą, z tym że powoduje to, iż rozkład tego czasu, w którym pracujemy nad naszym wspaniałym, najlepszym modelem, okaże się zdecydowanie mniejszy, niż pierwotnie zakładaliśmy, co organizacyjnie można zrobić, jeśli mamy już programistów, a z reguły są to mądrzy ludzie, więc można by ich w dość prosty sposób nauczyć podstaw. Nie mówię tutaj o budowaniu customowych sieci, ale o tym, w jaki sposób działa regresja, drzewa i pokazać im API. Jak programista developer dostanie dokumentację, to sobie już z tym poradzi, wprowadzi ich trochę. I wtedy bez zatrudniania dedykowanego data scientisty można zacząć próbować: OK, coś tutaj spróbujemy, to może zadziała. Jeśli coś zadziała i faktycznie okaże się, że coś w tych naszych danych jest, coś z tego powinno dać się wyłuskać, tylko nie do końca wiemy jak, bo jednak tą regresją daleko nie ujedziemy, to wtedy OK. Więc mamy takie a takie rzeczy, potrzebujemy człowieka, który zapełni nam tę lukę. I wtedy znowu – specyfikacja wymagań. To będzie oczywiście trudne dla firmy, która dopiero zaczyna data science, ale mamy już wtedy tych ludzi, którzy popracowali trochę z naszymi danymi, więc chociaż oni podczas rozmowy będą w stanie uświadomić człowieka, który stara się o daną pozycję, że „OK, oczekujemy czegoś takiego i takiego, jasne, możesz wprowadzić swoje pomysły, rozszerzyć to czy owo, ale generalnie sytuacja wygląda tak. I czy to jest dla ciebie w porządku czy też nie?”. Czy to jest realistyczne? Nie mam pojęcia, ale to by było wg mnie całkiem sensowne.

Mnie dość mocno zaskakuje, jak czasem na jakichś szkoleniach czy wydarzeniach ludzie się pytają: „Czy ja w ogóle mam szansę, czy w ogóle jest sens, żebym w ogóle zainteresował się data science, jak ja pracuję jako programista?”, ja stwierdzam: „Człowieku, takich ludzi nam potrzeba”, takich, którzy przypilnują ci tej części developerskiej – inżynierskiej. OK, dobra, utworzyliśmy świetny model, ale ten kod to śmietnik, trzeba to poprawić. Gdyby przynajmniej w każdym zespole była co najmniej jedna taka osoba, taki „policjant inżynierski”, to myślę, że świat byłby lepszy.

W kontekście tego, co powiedziałeś o kopaniu dołków pod sobą i eliminowaniu miejsc pracy dla data scientistów, to mam jeszcze jedno pytanie: czy masz jakieś przemyślenia na temat tych podejść automatycznych do uczenia maszynowego i w ogóle rozwoju tej działki, w której właśnie pozornie ten data scientist już nie jest potrzebny? Bo tutaj system sam się uczy, wybiera jakieś tam metody, dostosowuje do danych, daje nam jakiś wytrenowany model. Czy czujesz za plecami presję, że za chwilę zostaniesz wyeliminowany przez maszyny?

Myślę, że część firm zorientuje się, że do ich potrzeb nie potrzeba zatrudniać dedykowanych data scientistów. Na rynku można natknąć się na platformy, które oferują self-service machine learningowy, który jest w stanie załatwić te najprostsze przypadki. Takie platformy z reguły oferują wsparcie ze strony data scientistów, czyli jacyś data scientiści nadal tam występują, więc to nie będzie tak, że nagle gatunek wymrze, tylko jakby te najprostsze role najpewniej zniknąć w jakiejś perspektywie czasu. Nie mam danych, żeby przewidzieć tego typu przyszłość, ale wydaje mi się, że owszem, takie najprostsze rzeczy będą outsource’owane właśnie do platform, które się tym zajmą, albo – tak jak powiedziałem – będzie można przerzucić na co bardziej szalonych programistów, bo to nie jest coś nieosiągalnego dla człowieka, który umie matematykę i umie programować. Natomiast czy globalnie data scientiści wymrą? Nie sądzę. Nadal jest pula problemów, która nie jest typowa, a przynajmniej na razie nie jest, ponieważ w pewnym momencie nawet najbardziej niespotykane problemy mogą stać się typowe, aczkolwiek, tak czy inaczej, całe data science kręci się wokół biznesu, biznes jest jednak ludzkim zajęciem, a ludzie wymyślają przeróżne dziwne rzeczy i żeby zupełnie dało się wyeliminować tego typu potrzeby jak właśnie potrzeba człowieka, który popatrzy, wymyśli, podsunie jakiś pomysł, co z tymi danymi można zrobić, zaimplementuje jakiś model i doprowadzi do tego, żeby działało, to myślę, że coś takiego nie zniknie, natomiast zmniejszy się skala firm, które bezpośrednio zatrudniają data scientistów.

Mówiłeś o tych wyzwaniach i o tym aspekcie ludzkim: jak oceniasz inteligencję tych rozwiązań, które budujesz, czyli tych sztucznie inteligentnych, jak bardzo są one mądre i przypominają człowieka?

Nie przypominają człowieka ani trochę, to jest kawałek kodu. Rzeczy, które zdarzyło mi się napisać, jeszcze nie próbowały przejąć nade mną kontroli. Nie twierdzę, że zupełnie nie myślę o przyszłości. Super, że są ludzie trzymający AI w ryzach, dbający o to, żeby to było przemyślane. Aczkolwiek nie jesteśmy na tym poziomie. Tak na dobrą sprawę to chyba do tej pory nawet nie jesteśmy w stanie odtworzyć inteligencji robaka. Więc trochę czasu jeszcze minie. Tak naprawdę jest tu wiele podejść, np. w książce Architects of Intelligence wielu czołowych kontrybutorów do świata AI wypowiadało swoje przewidywania na przyszłość. Część mówiła, że deep learning będzie tym kluczowym aspektem, który pozwoli utworzyć sztuczną inteligencję. Część mówiło, że nie, że to bardziej mieszanina różnych rzeczy. Jedyna spójność zakłada, że żaden z nich nie jest w stanie w sensowny sposób przybliżyć, kiedy coś takiego jak taka ogólna sztuczna inteligencja powstanie. Tego nie jesteśmy w stanie przewidzieć. Człowiek, który stworzył firmę tworzącą Roomby, czyli właściwie najbardziej popularne narzędzia wykorzystujące roboty ze świadomością, twierdził, że „to nawet nie jest tak mądre jak głupi chrząszcz”. Osobiście patrząc na modele, które obecnie mamy, to nie jest szczególnie mądre zwierzę. To tak mądre jak twórca, który to przewidział. Model jest na razie narzędziem, które jest tak użyteczne i dobre, jak zostanie zaaplikowane.

Z tą Roombą jest tak, że koty się z tym zaprzyjaźniają, tak więc jakieś tam bardziej zwierzęce relacje jak między żywymi stworzeniami się tu pojawiają, ale to pewnie tylko przez ciepło.

Tak, ale z drugiej strony już dawno, dawno temu mieliśmy Elizę – bot do psychoanalizy. Ludzie myśleli, że rozmawiają z psychologiem. Więc nie tylko koty są w stanie się pomylić.

Powiedziałeś, że nie boisz się bycia wyeliminowanym przez sztuczną inteligencję. A wszyscy pozostali? Bo też mówi się dużo o tym, że informatyka, a w szczególności sztuczna inteligencja, zabierze nam miejsca pracy. I faktycznie mamy taką usługę jak automatyzacja czy robotyzacja miejsc pracy, więc to się dzieje. Ale czy wg ciebie pozostali pracownicy, niekoniecznie data scientiści, powinni się tego obawiać?

Mój sposób myślenia jest dość specyficzny. Bo ja mogę powiedzieć, że się nie boję, szczególnie że rola data scientisty będzie wyeliminowana, co nie oznacza, że rola, którą w tym momencie czy za X lat będę wykonywał, nie zostanie wyeliminowana. Moje podejście do branży, w której operuję, jest takie, że ja niestety lubię się uczyć, więc tak długo, jak człowiek jest otwarty na nową wiedzę, tak w dłuższej czy krótszej skali sobie poradzi. I podobnie sytuacja wygląda w innych branżach. Dla mnie niesamowite są takie rzeczy, w których firma oferuje możliwość uczestnictwa w kursie X czy Y, i ludzie nie są tym zainteresowani. Gdybym był człowiekiem, który nie jest zainteresowany, wtedy bym się bał o swoją pozycję. Jednak jedyne, co jest stałe, to zmiana, i trzeba antycypować to, że rola, którą w tym momencie wykonuję, czy to kierowcy czy prosta praca biurowa w Excelu, że może przyjść taki moment, kiedy jednak będzie się to dało zupełnie zautomatyzować. Naiwne jest zakładanie, że to nigdy nie nastąpi. Naiwne jest też siedzenie i ignorowanie otaczającego świata. Nie twierdzę, że teraz każdy jeden niech się uczy data science, bo, tak jak mówiłem, część z tych ról zniknie.

Pewnie jestem w uprzywilejowanej pozycji pod względem tego, że robię to, co lubię. Dla mnie rozwijanie się jest formą zabawy. Ale zakładam, że jest wiele rzeczy, w których można się odnajdować, realizować i które mogą w przyszłości otwierać pewne furtki na wypadek, gdyby dana rola zniknęła albo się zmieniła. Bo zakładam, że raczej nastąpi to stopniowo, że trzeba będzie nauczyć się nieco więcej pracować z maszyną, więc strach przed: „O, nie, którym myszkiem się klika”, nie pozwoli w dłuższej perspektywie egzystować na rynku pracy – trzeba wiedzieć, że lewym się strzela. Są rzeczy, których się nie przeskoczy. Praca z maszyną, nie tylko do pisania, ale też z komputerem, jest jedną z kluczowych. I tu właściwie chodzi o to, żeby człowiek, który siedzi prze tym komputerem, nie bał się tego, że „coś mi wyskoczyło, coś się zadziało, więc muszę dzwonić na policję, na straż pożarną”, tylko: „OK, więc to coś wyskoczyło, dostaję jakąś wiadomość, może zatem ją przeczytam, wygooglam”. Bądźmy szczerzy, w Google jest naprawdę ogrom informacji. Może nie rozwiąże problemu, ale na przyszłość coś mi tam zostanie, a nuż kiedyś się przyda. Czytając sygnały, które daje nam komputer, albo próbując ułatwić sobie życie, możemy się rozwijać, ubezpieczać nieco w ten czy inny sposób na przyszłość.

Taka puenta: opanujcie maszyny, bo inaczej one opanują was w przyszłość.

Może trochę. To jest też kwestia tego, że istnieje wiele zawodów zorientowanych na ludzi i w tych obszarach umiejętność obsługi człowieka jest też istotna, również w przyszłości.

Dzięki za to spojrzenie na sytuację w data science i w okolicach. Czy chcesz dodać coś na koniec?

Jeszcze raz na wszelki wypadek powiem, że lubię działkę, w której pracuję. Zdaję sobie sprawę z tego, że w data science jest wielu specjalistów, którzy są w stanie przeskoczyć w tej czy innej kwestii. Smuci mnie to, że ludzie zamykają się na jedną rzecz: będę robił tylko te modele. Według mnie to jest stratą. Jesteś na tyle inteligentnym człowiekiem, żeby wymyślić nowy model, zaimplementować to czy tamto, więc szkoda, żebyś nie ubrudził paluszków, działając wokoło. Zdjął model z piedestału i wstawił tam produkt końcowy tego, czemu to ma służyć. Więc: full stack data science.

OK, szerokie horyzonty – myślę, że to dobra porada. Dzięki jeszcze raz, Patryk, że znalazłeś czas, aby z nami porozmawiać. Do usłyszenia następnym razem.

Dzięki.