Wprowadzenie

Vladimir: Cześć Piotrek, powiedz trochę więcej o sobie, czym się zajmujesz, gdzie mieszkasz?

Piotr: Cześć, ja się nazywam Piotr Rybak, mieszkam w Warszawie i zajmuję się szeroko pojętym rozumieniem języka, tak zwanym Natural Language Processing (NLP). W tym się specjalizuję, ale też zajmuję się przy okazji całym nurtem uczenia maszynowego, trochę wizją komputerową, kiedyś też analizami sygnałów – bardzo różnymi rzeczami. Co się trafiało, tym też się zajmowałem.

Natomiast główny mój fokus to jest właśnie rozumienie języka, przetwarzanie języka, budowanie tak naprawdę produktów, które wykorzystują w jakiś sposób ten komponent uczenia maszynowego, żeby rozumieć język.

Ciekawa książka

Vladimir: Właśnie, o tym dzisiaj porozmawiamy. Masz bardzo fajne doświadczenie, takie bardzo praktyczne, takie sobie najbardziej lubię. Ale tak na rozgrzewkę, powiedz, jaką fajną książkę ostatnio przeczytałeś i dlaczego warto ją przeczytać?

Piotr: To jest bardzo problematyczne pytanie. Szczerze, nie wiem. Chyba od wielu lat nie czytam już książek. Jakoś mam wrażenie, że książki przestały być dobrym medium, jeżeli chodzi o naukę, o przekazywanie wiedzy.

Kiedyś rzeczywiście dużo czytałem – bardzo dużo beletrystyki, potem też jakichś podręczników i tak dalej. Ale w sumie mam wrażenie, że w tej chwili cała branża rozwija się na tyle szybko i to zarówno, jeżeli chodzi o jakieś uczenie maszynowe, ale nie wiem – budowanie produktów czy cokolwiek innego, startupów – to się wszystko rozwija na tyle szybko, że najwięcej informacji jest na Twitterze, na Discordach. Gdzieś ludzie napiszą jakiś losowy komentarz i tam jest wiedza. I to trzeba śledzić. Tego na przykład czytam na bieżąco. Polecam przykładowo Hacker News –

Polecam przykładowo Hacker News – to taka super stronka z newsami startupowymi, która ma niesamowite komentarze. Są tam najbardziej znane osoby na świecie, znani startupowcy. Jeżeli jest pytanie o MongoDB i ktoś narzeka, że coś w MongoDB jest beznadziejne, to nagle komentarz pisze twórca MongoDB i odpisuje merytorycznie, że jednak nie masz racji, bo to jest tak i tak. Mam wrażenie, że tam jest aktualnie najwięcej wiedzy i to należy czytać.

Vladimir: Czyli to, co mówisz, to informacja teraz szybko się starzeje, a a propos Hacker News – to też ciekawostka, że ta stronka wygląda jak coś takiego starszego, ale faktycznie zawiera najbardziej świeże rzeczy, plus ta merytoryczność, o której wspomniałeś, tam jest.

Dobrze, słuchaj, to zanurzajmy się w tematy dzisiejszego odcinka. Masz dużo doświadczenia z NLP, w szczególności w tzw. zadaniach zdanie-odpowiedź, czyli question answering. Zwykle jest tak, że ktoś, kto siedzi w tym bardzo długo, zapomina, jak to jest czegoś nie wiedzieć, i mówiąc niby prostymi słowami do kogoś innego, to nie zawsze jest takie oczywiste. I chciałbym, żeby osoba, która w tych tematach nie siedziała, po dzisiejszej naszej rozmowie zrozumiała wiele, a również osoby, które w tym temacie siedzą, też usłyszały przydatne informacje.

Piotr: Jest to dość trudne zadanie, ale myślę, że dam radę.

Czym jest question answering?

Vladimir: Zacznijmy od początku, jeżeli chodzi o właśnie question answering. O co chodzi z tym zagadnieniem, jak możesz to wyjaśnić tak po ludzku, dlaczego to zagadnienie może być pomocne, wartościowe np. dla biznesu?

Piotr: Jeżeli chodzi o question answering, to jest to bardzo, bardzo szeroka dziedzina przetwarzania i rozumienia języka naturalnego. I możemy sobie wyobrazić, dlaczego jest szeroka, podam kilka przykładów.

Oczywiście możemy się spytać, kiedy była bitwa pod Grunwaldem?

Vladimir: To sobie wyobrażamy jako standardowe odpowiadanie na pytanie. Była wtedy i wtedy. Ale ktoś może zadać pytanie, jak będzie po angielsku „biznes myśli”? Niby to jest question answering, ale tak naprawdę to jest tłumaczenie maszynowe.

Ktoś może zapytać, ile to jest 2+2. Niby to jest question answering, niby ktoś sformułował to jako pytanie, ale tak naprawdę to nie jest pytanie, to jest użycie kalkulatora.

I jakby sam question answering zajmuje się właśnie bardzo, bardzo wieloma rzeczami, bardzo wieloma typami. Ja się zajmuję, w szczególności tutaj podczas tej rozmowy, chyba skupiłem się na takim dosyć ograniczonym rozumieniu question answeringu jako wyszukiwaniu odpowiedzi.

Question answering jako lepszy search

Piotr: Znaczy, założyłbym, że mamy jakąś bazę wiedzy, np. dokumenty w firmie, i teraz mamy użytkownika, który chce się czegoś dowiedzieć, ale zamiast przeszukiwać te dokumenty ręcznie, chciałby zadać pytanie: ile dni urlopu przysługuje pracownikowi, który pracuje tutaj od roku?

To jest konkretna informacja, która najprawdopodobniej jest w jakichś dokumentach kadrowych, HR-owych, tylko zamiast szukać tych informacji ręcznie, ja bym chciał tę informację, tę odpowiedź znaleźć.

I w tym sensie odpowiadanie na pytania to jest tak naprawdę taki trochę lepszy search, trochę lepsza wyszukiwarka. Bo nie tylko znajdujemy dokumenty, w których ta odpowiedź jest, czy jakiś paragraf, w którym ta odpowiedź się znajduje. To jest pierwszy krok, ale drugi krok to jest jeszcze wyciągnięcie tej odpowiedzi i przedstawienie jej w jakiejś takiej bardziej naturalnej formie, czyli po prostu podanie informacji: 20 dni albo 26 dni, zamiast zdania, że tutaj jest dokument.

Przydatność question answeringu

Piotr: Czemu to jest przydatne? To jest analogicznie przydatne, jak Google jest przydatny. Mamy mnóstwo informacji, potrzebujemy informacji. W tym samym sensie po prostu każdy biznes żyje na informacjach w dzisiejszym świecie i tych informacji szuka podczas codziennej pracy.

Co chwilę tak naprawdę zadajemy sobie jakieś pytania, czy jako programiści – jakie argumenty ma dana funkcja, czy jak coś zrobić. Wtedy używamy często tego Google’a, wyszukujemy, znajdujemy taką stronkę Stack Overflow, gdzie ktoś już zadał to pytanie i patrzymy, jaka jest odpowiedź.

Ale oczywiście w każdej innej branży jest dokładnie to samo i niektóre te informacje są publicznie dostępne, jak właśnie w Google, a niektóre oczywiście są zamknięte w ramach naszych organizacji, w ramach naszych firm, bo mamy jakieś procedury, standardy i informacje wewnątrzfirmowe. Też musimy dobrze wyszukiwać te informacje i prezentować je, czy to naszym pracownikom, klientom, czy użytkownikom strony internetowej.

Stack Overflow a ChatGPT

Vladimir: Powiedziałeś, że to jest taka wyszukiwarka, tylko lepsza. Myślę, że Stack Overflow może nam się teraz przydać jako przykład.

Wcześniej, jak ktoś potrzebował napisać kod i coś mu nie działało albo chciał coś nowego stworzyć, to wpisywał zapytanie do Google, trafiał zwykle na Stack Overflow, patrzył na rozwiązania, kopiował, wklejał, coś zmieniał i tak to działało. Był nawet taki żart – Stack Overflow Driven Development.

Natomiast kiedy pojawił się ChatGPT, Stack Overflow zaczął być rzadziej używany.

Zresztą, jak teraz nagrywamy, to już jest oficjalny news – ChatGPT, czyli OpenAI, zaczyna formalnie współpracować ze Stack Overflow. Wcześniej były tylko pogłoski, że parsują sobie te dane, a teraz to już formalna współpraca. Pojawiały się nawet śmieszne propozycje nazw, jak GPT Overflow, ale oficjalnie nazywa się to Overflow AI.

Idea polega na tym, że teraz już nie musisz najpierw szukać w Google, analizować semantycznie wyników, tylko od razu wpisujesz, co chcesz i dostajesz odpowiedź. Wszystko sprowadza się do tego, że jako ludzie szybciej uzyskujemy potrzebne informacje.

Ograniczenia ChatGPT

Vladimir: Chociaż trzeba przyznać, że nie zawsze to działa. Wczoraj miałem wyzwanie z Kubernetesem, bo po kolejnej aktualizacji rozsypały mi się rzeczy. Kopiowałem błędy wszędzie – do Bardy, ChatGPT, Perplexity, Llamy – coś podpowiadały, ale ostatecznie musiałem sam pogrzebać głębiej w logach i rozwiązać problem. Choć czasem faktycznie pomaga.

Podsumowując, teraz mamy mniej kroków i zwykle, choć nie zawsze, dostajemy precyzyjną odpowiedź na swoje pytania, prawda?

Piotr: Tak, to jest założenie. Znaczy założenie jest takie, że odpowiedź gdzieś jest, przynajmniej w tym rozumieniu question answeringu, którym ja się zajmuję i który dla mnie jest obecnie najbardziej rozwiązaną częścią tego zagadnienia.

Chodzi o to, że gdzieś w bazie dokumentów jest odpowiedź i chcemy ją wyciągnąć w dobrej formie. W przypadku tego błędu z Kubernetesem, być może nikt nigdy nie rozwiązał tego problemu, w sensie nie ma tej informacji w żadnym dokumencie – nikt nie zadał tego pytania na Stack Overflow, nie ma tego w dokumentacji ani w zgłoszeniach na GitHubie. Więc to jest coś, co jest nierozwiązywalne w takim standardowym question answeringu.

Prawdopodobnie obecnie w ogóle nie jest to sensownie rozwiązywalne. Można liczyć, że kolejna wersja ChatGPT przeanalizuje kod źródłowy Kubernetes i wymyśli, z czego może wynikać błąd, ale jeszcze nie jesteśmy na tym etapie.

To, co działa dobrze, to znalezienie informacji, która już gdzieś jest i być może przetworzenie jej w bardziej zrozumiały sposób, tak żeby łatwiej nam było to przeczytać.

Vladimir: Masz rację, bo to była świeża aktualizacja, więc dopiero te błędy zaczęły się pojawiać i ludzie próbują to rozwiązać i gdzieś zgłosić. Dopiero później informacja będzie gdzieś zarejestrowana.

Paradoks odpowiedzialności za rozwiązywanie problemów

Vladimir: Tylko problem polega na tym, że ty jako osoba, która jesteś odpowiedzialna za to, musisz to rozwiązać. Więc to jest taki trochę paradoksalny stan, gdzie nadal człowiek nie ma wymówki, że nie ma jeszcze informacji, jak to rozwiązać, tylko musi coś sobie z tym zrobić.

Piotr: Jak o tym pomyślimy, to takie sytuacje nie zdarzają się aż tak często. Raczej to, co widzimy, jak mamy kanał supportowy w firmie i komuś nie działa, nie ma dostępu do jakiejś usługi. Rzadko kiedy jest sytuacja, w której on jest akurat tą pierwszą osobą w firmie, która ma ten problem.

To raczej jest tak, że już 50 innych osób napisało, że ma z tym problem i tylko człowiek z tego wsparcia IT musi po raz kolejny, 50. raz napisać „trzeba założyć ticket tutaj i tutaj”. Tak samo tutaj z tym błędem Kubernetesa, pewnie kolejne 50 osób już nie musi tego rozwiązywać samemu, tylko wystarczy, że znajdzie już to pierwsze rozwiązanie.

Rozwiązywanie powtarzających się problemów dzięki technologii

Vladimir: Właśnie, teraz dochodzimy do wniosku nr 1.

Osoba decyzyjna, osoba, która buduje takie systemy, już wie co najmniej jedną rzecz – że jeżeli chcemy rozwiązać problem, który regularnie się powtarza, to obecnie technologie pozwalają robić to całkiem dobrze.

Za chwilę też o tym porozmawiamy jak, ale mówimy, co jest możliwe.

Open domain vs closed domain w question answering

Vladimir: I teraz połączmy to z takim stwierdzeniem jak open domain, bo często pojawia się właśnie question answering w kontekście open domain albo closed domain. Gdzie jest ta definicja i jaka jest granica? Czy teraz, mówiąc o takiej wewnętrznej wyszukiwarce w firmie, to jest open domain czy to już nie do końca? Jak to definiujesz dla siebie?

Piotr: To jest trudne pytanie. Wydaje mi się, że tak jak wiele prób postawienia granicy, to zależy. Dla mnie to jest raczej kwestia historyczna względem tego, jak kiedyś się rozwiązywało systemy question answering.

To było raczej tak, że mamy jakiś dokument i zadajemy do tego dokumentu pytanie. To bym nazwał taki closed domain, to się teraz raczej nazywa reading comprehension, a open domain to jest na zasadzie, że mamy tę bazę wiedzy bardzo, bardzo dużą. Na tyle dużą, że możemy rzucić tam, w cudzysłowie, dowolne dokumenty, dowolnie dużo dokumentów, ale mamy tę bazę wiedzy.

Teraz możemy zadawać dowolne pytania o tę bazę wiedzy i w tym sensie jest to open domain. Oczywiście, też założenie jest takie, że to jest rzeczywiście open domain w znaczeniu, że to mogą być dokumenty czy to prawnicze, czy jakieś lekarskie, czy techniczne i tak dalej.

I to ma trochę znaczenie, ale raczej powiedziałbym, że rozróżnienie jest takie, czy mamy dużo tych dokumentów, czy to jest jeden dokument.

Vladimir: Dobrze. Spróbujmy teraz zrobić taki punkt odniesienia na temat technicznych możliwości, jeżeli chodzi właśnie o „open„, „nie open„, question answering, czyli pytania, odpowiedzi.

Skuteczność systemów AI w zadaniach question answering

Vladimir: Czyli nawet uprośćmy sobie zdanie, załóżmy, że mówimy o angielskim, za chwilę też porozmawiamy o języku polskim. Gdzie jesteśmy teraz? Są różne benchmarki, ale chciałbym, żebyśmy to jakoś oszacowali bardziej tak po ludzku. Załóżmy, że jest ocena od 0 do 10 – 0 totalnie nie umiemy, 10 idealnie trafiamy zawsze w to, co trzeba. Załóżmy, że tych dokumentów jest nieskończenie wiele i znajdujemy dokładnie to, co trzeba, prosto, idealnie. Gdzie jesteśmy teraz? Przynajmniej może subiektywnie, to jest trochę, ale spróbujmy to oszacować, żeby osoba, która nie zna tych benchmarków po nazwach, była w stanie odnieść, co w tej chwili już jest możliwe.

Piotr: Ja bym powiedział, że to jest 9, 9,5. Jest to w miarę rozwiązany problem, a przynajmniej rozwiązany w sensie użytkowym. Też pomyślmy o tym, że jeżeli system ma, powiedzmy, skuteczność 90%, czyli odpowiada na 90% pytań, to to wciąż jest bardzo użyteczny system. W sensie bardzo fajnie coś takiego wdrożyć, nie odpowiemy na wszystkie pytania i w każdym systemie, który jest oparty o uczenie maszynowe, nigdy nie będziemy mieli 100% skuteczności, ale powyżej jakiejś skuteczności ten system już jest użyteczny.

Oczywiście ta proporcja jest różna w zależności od tego, co robimy. Jeżeli gramy w ruletkę i chcemy przewidywać, czy będzie czerwone czy czarne, to nawet jak mamy 55% skuteczności, to już możemy się wzbogacić i wygrywać miliony w kasynie. Ale jakby to było 55% skuteczności w wyszukiwaniu jakiejś informacji, to pewnie nie byłoby to bardzo wysokim wynikiem.

Ja bym powiedział, że to w tej chwili raczej są rzędu właśnie 80-90-90 parę procent. Trochę zależy od tego, jak skomplikowane są te pytania. Trochę zależy, jak bardzo różne są pytania od dokumentów. Znaczy, jeżeli pytanie jest bardzo skomplikowane i ma bardzo dużo szumów i śmieciowych informacji, które nie są istotne, a dokumenty wyglądają zupełnie inaczej, no to wtedy wiadomo, że ten model, jakiś model, system będzie miał trudność, żeby znaleźć dobre dokumenty, żeby generować dobrą odpowiedź. Im prostsze, czystsze, takie sensowniejsze są pytania i im lepszej jakości są dokumenty, to czasami to działa praktycznie zawsze i zawsze dostajemy dobrą odpowiedź.

Użyteczność systemów AI vs ludzie

Vladimir: A fajnie to rozdzieliłeś, bo ja cię zapytałem właśnie o ocenę i to jest blisko idealne, czyli bardzo blisko dziesiątki jesteśmy, ale też fajnie to rozdzieliłeś, że jest jeszcze druga miara – użyteczność. I właściwie, jeżeli chodzi o użyteczność, to jak nie mamy takiej wyszukiwarki wewnętrznej, powiedzmy w większym atelier, no to mamy ludzi. I taka Zuzia albo Jacek to też nie zawsze odpowiada na wszystkie pytania, ale nadal zwykle pytamy kogoś, więc pod tym względem i tak ten problem istnieje, czyli nie mając tych narzędzi też nie mamy zwykle, jeżeli to jest w miarę większa firma, jakieś skomplikowane procedury, rzeczy itd., to zwykle też nie ma pojedynczej osoby, która wie wszystko.

Piotr: Co ciekawe, też istnieje takie routery, że jest ta osoba, która wie, kto może wiedzieć i to też jest taka ciekawa rzecz, którą można stosować technologicznie, że masz takie routery i przekierowujesz się do pojedynczych takich modeli, agentów, jakkolwiek tam je nazwać, a oni się skupiają na którejś tam działce, na przykład ten na HR, ten na marketingu, ten tam jeszcze na urlopach itd.

Udało mi się tak w jednej firmie wpaść w cykl, że spytałem osoby A, jak coś zrobić, zostałem przekierowany do osoby B, osoba B przekierowała mnie do osoby C, osoba C do osoby A i tak naprawdę już ciężko było powiedzieć, co z tym zrobić.

Natomiast co do tej skuteczności ludzi, to też jest coś, co jest w pewnym sensie niesamowite. Czy nie wiem, na ile się zmieniła percepcja ostatnio, ale jeszcze parę lat temu było oczekiwanie takie, że ludzie są bezbłędni, a to uczenie maszynowe czy ta AI, sztuczna inteligencja, no to ona popełnia błędy, ona się myli, ona jest głupia i jest generalnie gorsza od ludzi.

I to naprawdę powodowało duże problemy w rozmowie z klientami, bo robiliśmy badania na zasadzie, trzeba było, nie wiem, klasyfikować teksty, powiedzmy, czy tekst jest z jakiejś tematyki. I wcześniej to robili ludzie, a teraz my to automatyzowaliśmy, robiąc model uczenia maszynowego. I ten model miał skuteczność 80%. No i wtedy klienci mówili: „Nie, no tragedia, 80%, o Panie, to w ogóle nas nie satysfakcjonuje, my nie jesteśmy w stanie przeżyć 20% błędów”. Tak, no tak, ale my daliśmy te same przypadki testowe wam, w sensie waszym pracownikom i oni mieli skuteczność 75%. „Nie, ale to co innego, nie, nie, nie, my nie możemy przeżyć 20% błędów”.

Błędy ludzi vs błędy maszyn

Piotr: Coś w tym jest. Nie wiem, w sensie to nie jest bardzo głupie podejście, bo rzeczywiście ludzie mylą się inaczej niż maszyny. Maszyny często się mylą w dużo głupszy sposób, więc te błędy są inne i być może te błędy są jakby bardziej problematyczne. Natomiast wciąż jest takie przekonanie, że człowiek jest stuprocentowo skuteczny i maszyna też musi być stuprocentowo skuteczna, w szczególności żeby była użyteczna.

A to zupełnie nie jest prawda. Jeżeli nawet mamy taki system do odpowiadania na pytania, który odpowiada tylko w połowie przypadków poprawnie, to to też jest super. Jeżeli wcześniej zajmowało nam na przykład godzinę, żeby znaleźć jakiś akt prawny, który opisuje jakąś sytuację prawną, no i teraz w połowie przypadków ten czas z godziny spada do 5 sekund, to wciąż oszczędzamy mnóstwo czasu. Może tylko w połowie przypadków, ale wciąż oszczędzamy mnóstwo czasu, bo każda ta rozwiązana sprawa to jest godzina do przodu.

Vladimir: Chciałem rzec coś innego, ale jak powiedziałeś, że maszyny się mylą w bardziej głupi sposób, aż się prosi, żeby jakiś leaderboard stworzyć i porównać, kto potrafi się mylić bardziej głupio – maszyny czy ludzie, bo ludzie też czasem robią różne głupie rzeczy.

Piotr: Ludzie, na przykład, jak się mylą, to często się mylą dlatego, że są rozkojarzeni. W sensie raczej nie popełniają głupich pomyłek tak po prostu, w jakiś taki jeden konkretny sposób, tylko na przykład nie chce im się, to klikną coś losowo i też tego typu błędy bardzo łatwo wychwycić.

A jak model się myli, to często się myli w głupi, ale nieoczywisty sposób, taki, że nie jesteśmy w stanie tego łatwo wykryć.

Jak posadzimy dwóch ludzi i każemy im anotować czy patrzeć na ten sam przykład, to nawet jeżeli jedna z tych osób się pomyli, to bardzo łatwo jest wykryć, że się pomyliła. Jak wytrenujemy dwa modele, to już nie jest aż takie oczywiste, że modele będą zazwyczaj w ten sam sposób skrzywione, przynajmniej w podobny sposób skrzywione, i to już wtedy nie jest oczywiste, żeby to naprawić.

Vladimir: O anotacjach gdzieś jeszcze porozmawiamy, temat pewnie rzeka, ale w tym przypadku na pewno Cię podpytam. Ale żeby skończyć tę myśl, którą zacząłem – powiedziałem tak: jaka jest ocena obecnych rozwiązań?

Powiedziałeś, że blisko dziesiątki. A teraz cofniemy się w czasie, powiedzmy 10 lat temu, może 15. I to samo pytanie, czyli jaka była wtedy dostępność rozwiązań, jeśli chodzi o ten problem question answering, od 0 do 10? Jak to oceniałbyś teraz?

Piotr: Powiedziałbym, że było dużo gorzej. Znaczy, trochę rewolucyjnych rzeczy się zmieniło i to jakby w dwóch krokach. Może delikatnie rozbiję, w jaki sposób się w ogóle tego typu systemy buduje.

Dwa kroki w budowaniu systemów question answering

Zazwyczaj składa się to z dwóch kroków. Pierwsza to jest wyszukiwarka, czyli mamy dużo dokumentów, mamy pytanie i chcemy znaleźć dokumenty, które odpowiadają na to pytanie. To jest pierwszy krok – wyszukiwanie dokumentów.

A drugie to, jak już mamy ten dokument, to jak znaleźć odpowiedź w tym dokumencie. I w obu częściach zdarzyła się tak naprawdę rewolucja, przy czym, powiedziałbym, większa rewolucja jest w tej drugiej części, w wyciąganiu informacji z dokumentu.

Tutaj w szczególności modele generatywne, takie jak large language models, czyli LLM, na przykład GPT itd., to jest coś, co zdecydowanie podniosło skuteczność tego typu systemów.

Ale w wyszukiwarkach też się trochę rzeczy zadziało. W szczególności przeszliśmy z używania takich klasycznych wyszukiwarek opartych o słowa kluczowe do wyszukiwarek właśnie opartych o sieci neuronowe. I to było, jest dla mnie cały czas zaskakujące, bo to się wydarzyło dopiero niedawno. To są ostatnie, nie wiem, 2-3 lata.

Mimo że ludzie próbowali już od dawna używać sieci neuronowych do tego, żeby wyszukiwać, to okazuje się, że te wyszukiwarki oparte o słowa kluczowe są po prostu bardzo, bardzo dobre. I one bardzo dobrze działają. Jeżeli dodamy jeszcze jakieś triki na zasadzie lematyzacji tych słów – w języku polskim jest to istotne.

Lematyzacja, czyli sprowadzenie do takiej formy podstawowej, do bezokolicznika czy do mianownika w przypadku rzeczowników. W przypadku języka polskiego jest to problematyczne, dla angielskiego nie ma to dużego znaczenia, bo tam nie ma aż takiej deklinacji.

Tak, jeżeli dodamy jakieś, nie wiem, predefiniowane listy synonimów, to tak naprawdę taka wyszukiwarka oparta o słowa kluczowe działa bardzo dobrze. I w tym sensie te systemy nadal były użyteczne już te 5, 10, 15 lat temu. Google powstał ile, 20 lat temu

Czym jest LLM?

Vladimir: Dobra, i teraz ta druga część, jeżeli chodzi o poprawę, to między innymi tam pojawi się LLM, tak zwany large language model. Nie będziemy za bardzo się skupiać na definicji, co to jest, ale chciałbym też podpytać, czym dla Ciebie jest LLM i kiedy to jest duży.

Piotr: To może dwa słowa powiem, czym jest LLM, żeby uprościć dyskusję. LLM, czyli large language model, składa się z dwóch części. Language model to jest takie bardzo proste zadanie uczenia maszynowego, gdzie mamy jakiś tekst i chcemy przewidzieć, jakie będzie kolejne słowo w tym tekście. I to jest super zadanie, bo z jednej strony mamy bardzo dużo danych do uczenia. Wystarczy ściągnąć cały internet, wziąć wszystkie możliwe książki na świecie i mamy przygotowane dane, żeby trenować taki model. Po prostu czytamy sobie i przewidujemy kolejne słowo.

A z drugiej strony jest to fajne zadanie, bo to jest takie zadanie, trochę jak właśnie question answering, które enkapsuluje wszystkie inne zadania. Jeżeli mamy zadanie klasyfikacji wydźwięku tweetów, czy tweet jest pozytywny, czy negatywny, to możemy dać tę treść tweeta, a potem napisać „ten tweet jest” i liczymy, że language model nam powie: pozytywny, negatywny, bo musi przewidzieć kolejne słowo. Jakie będzie najbardziej prawdopodobne kolejne słowo? Albo pozytywny, negatywny i która z tych słów raczej ta prawidłowa. Czy question answering też możemy rozwiązać za pomocą language modelingu.

Kiedy model językowy staje się „duży”?

Piotr: Ludzie to robili od lat i zajmowali się tym od lat, i to zawsze było w jakiś tam sposób użyteczne. Natomiast faktycznie zaczęło być super użyteczne od kiedy dodaliśmy to pierwsze „L”, czyli large. To znaczy, ludzie zauważyli, głównie tak naprawdę OpenAI zauważyło, że jeżeli będziemy skalować te modele językowe, czyli te sieci neuronowe, które właśnie przewidują to kolejne słowo, jeżeli będziemy je robić coraz większe i coraz większe, i coraz większe, to te modele będą działać coraz lepiej, coraz lepiej i coraz lepiej.

I to się wydaje banalny wniosek. No wiadomo, jak będzie większe, to będzie lepsze, ale to nie jest oczywisty wniosek. Znaczy, raczej zazwyczaj było tak, że jeżeli mieliśmy więcej danych, no to wiadomo, że model był lepszy, ale w którymś momencie ta skuteczność się wypłaszczała, już nie warto było mieć więcej danych. Albo jeżeli zwiększaliśmy model, to ok, no było lepiej, ale do pewnego momentu, potem już nie było

Skalowanie modeli językowych i ilości danych

Vladimir: Okazało się, że jeśli będziemy skalować obie te rzeczy na raz, czyli wielkość modelu i ilość danych, a obie rzeczy możemy skalować – wielkość modelu, po prostu musimy mieć więcej kart graficznych, więcej GPU, na których trenujemy ten model, no i danych też mamy bardzo dużo, bo możemy brać po prostu strony internetowe, książki itd. I w pewnym sensie mamy tych danych nieograniczenie wiele, chociaż okazuje się, że już dochodzimy do tej granicy.

To okazuje się, że jeżeli będziemy to tak skalować, to się nie wypłaszcza. Znaczy wiadomo, że za każdym razem musimy dawać na przykład 10 razy więcej danych i 10 razy większy model, ale wtedy mamy zawsze stały przyrost skuteczności. No i od pewnego momentu te modele po prostu zaczęły działać bardzo, bardzo dobrze i rzeczywiście zaczęły działać w ten sposób, w jaki zawsze ludzie teoretycznie myśleli, że by było fajnie, gdyby te modele językowe działały.

Piotr: Czyli właśnie ten przykład z tweetami, że po prostu dajemy tweet i się pytamy, jaki jest sens tego tweeta. No i to było takie machanie rękami, że to powinno działać, ale od pewnego momentu okazało się, że to faktycznie działa. No i to było w jakimś sensie niesamowite, znaczy mnie to osobiście zaskoczyło, że to faktycznie może tak działać.

Prompt engineering

No i wtedy też pojawił się cały ten nurt promptingu, tak, prompt engineeringu, no bo skoro to w ten sposób działa, no to teraz może ma znaczenie, jaką napiszemy tę początkową sekwencję i włożymy do modelu językowego. Czy najpierw damy treść tweeta, a potem napiszemy: sklasyfikuj ten tweet to…, czy najpierw napiszemy: sklasyfikuj tweet i coś dalej, i tak dalej.

I okazało się, że w tych początkowych modelach językowych ma to bardzo duże znaczenie, bo on jedyne, czego się uczył, to właśnie przewidywać kolejne słowo.

Taki znany przykład jest na przykład ze streszczeniem. Jak się czyta dużo Reddita na przykład, to często posty są pisane w ten sposób, że jest napisany post, a potem tl;dr, czyli „too long; didn’t read”. Ludzie pisali kilkuzdaniowe streszczenie, o co chodzi w tym poście.

I okazało się, że skoro model przeczytał bardzo dużo tego typu tekstów, no to wiedział, że po słówku tl;dr ma napisać streszczenie. Więc jak wzięliśmy taki początkowy language model, GPT-2 czy GPT-3, i daliśmy mu jakiś tekst, a potem daliśmy tl;dr, to on fenomenalnie potrafił generować streszczenie.

No i teraz to jest przydatne, bo te modele są po prostu bardzo zdolne, mają bardzo dużo umiejętności, bardzo dobrze rozumieją tekst i w szczególności nie wymagają bardzo dużo danych treningowych.

Często nie potrzebują w ogóle danych treningowych, tylko wymagają dobrze napisanego promptu, żeby już rozwiązywać jakieś konkretne zadania. Jednym, oczywiście bardzo specyficznym zadaniem, jest właśnie wyciąganie odpowiedzi z dokumentów czy synteza informacji z dokumentów, żeby odpowiedzieć na pytanie.

Vladimir: Bardzo mi się podoba, jeżeli chodzi o ten duży model, że zwrócono uwagę, iż nie chodzi tylko o rozmiar architektury czy liczbę parametrów. Zwykle osoby, które są poza tematem, mierzą się, kto ma tych 13 miliardów parametrów, kto 7 itd. Ale ważne jest też to, że dotyczy to danych. W obecnych czasach, jak już udało się znaleźć pewien poziom, to teraz jest taka walka – co jeżeli zmniejszamy rozmiar modelu, a bardziej pracujemy na jakości i ilości danych, próbując osiągnąć tę samą rzecz.

Widać, że dane w tej chwili odgrywają ważną rolę. Był taki moment, pewna iluzja, że wystarczy wrzucić cokolwiek, bo mamy duży model i on sobie jakoś tam poradzi. Jednak po raz kolejny odbiło się to o tę iluzję i znów wraca się do tego, że jakość danych ma sens. Ilość i jakość w tym przypadku odgrywają ważną rolę.

Znaczenie danych w trenowaniu modeli

Piotr: To znaczy, koniec końców, to czego się ten model uczy, to po prostu tych danych. Im więcej tych danych damy, tym więcej informacji się nauczy. Nawet niekoniecznie lepszej jakości, bo bardzo ciężko zdefiniować, co znaczy lepszej jakości dane, ale takich danych, których chcemy, żeby model się nauczył.

Tego się nauczy. Jeżeli damy mu teksty, które są pełne teorii spiskowych i nieprawdziwych faktów, jakichś fake newsów, to model się fenomenalnie tego nauczy, tylko to będzie dla nas mało użyteczne, jeżeli chcemy, żeby odpowiadał prawdziwie na pytania. Ale nie jest powiedziane, że to są wysokiej jakości dane, jeżeli zawierają prawdziwe informacje.

Jeżeli chcemy pisać fake newsy, powiedzmy, że jesteśmy jakąś agencją propagandową i chcemy pisać fałszywe informacje, to akurat tego typu danych chcemy. Chcemy mieć dane z fake newsami i chcemy, żeby on generował nieprawdziwe informacje. Wtedy dla nas wysokiej jakości dane to są te dane, które właśnie zawierają fałszywe informacje.

Vladimir: A w tym przypadku bardziej poszedłeś w kierunku biasu, że może być w ten sposób pisane albo w inny, a ja też, mówiąc o jakości, myślę przede wszystkim, że te dane w ogóle mają sens jako takie.

To znaczy, możesz sobie pozbierać jakieś paskudztwa w internetach, różne rzeczy i tam jest mnóstwo śmieci, które – nawet nie chodzi o to, że to jest prawda czy nieprawda – tylko po prostu to są totalne śmiecie. I trenowanie na takich śmieciach nie daje dużych wartości, bo tam nawet nie ma dobrych zdań, po prostu jakiś spam, niespam, nie wiadomo co.

Problem generowanych tekstów w internecie

Piotr: To w ogóle jest problem, że dużo tekstów w internecie jest generowanych przez jakieś proste modele, w szczególności teraz przy powszechności modeli językowych. Ale też historycznie ludzie tak pisali na potrzeby SEO, czyli optymalizacji wyszukiwarek internetowych, optymalizacji Google’a.

Pisali jakieś fejkowe, automatyczne artykuły na blogach, byle tylko miały odpowiednie słowa kluczowe, żeby Google ich indeksował. Teraz, jeżeli weźmiemy w tym przypadku słabej jakości teksty i nauczymy model, żeby tak generował tekst, to tak będzie generował tekst. Czy to będzie dla nas użyteczne? Zazwyczaj nie, bo chcę mieć taki czysty, ładny, powiedzmy wysokiej jakości, w znaczeniu poprawny gramatycznie.

Reprezentacja dokumentów w wyszukiwarce

Vladimir: Słuchaj, Piotrek, bardzo lubisz klocki LEGO, o tym też dzisiaj porozmawiamy, bo to jest wprost przełożenie, ale teraz chciałem zostać nadal w NLP, ale chciałem, żeby właśnie u słuchaczy była taka fajna analogia, że jak próbujemy rozwiązać konkretny problem, a teraz chciałbym, żebyśmy to zrobili, żeby było zrozumiałe, że ten system, który powstanie, to de facto są klocki LEGO, czyli pewne rzeczy, pewne warstwy, je można wymieniać na różne.

I też te decyzje są o coś, czyli jak zmieniamy A na B, to jest coś lepsze albo coś gorsze i musimy sobie wybrać. I chciałbym, żeby to wybrzmiało, że ten system jako tako to nie jest taka jedna duża bryła, tylko to są pewne warstwy i te warstwy można sobie tak konfigurować na różne sposoby. I też tam język może być inny, też jakby dany wycinek mógł być różny, więc próbujemy zdefiniować zadanie w taki sposób.

Załóżmy, że mamy firmę. Ta firma jest powiedzmy troszkę większa, tysiąc pracowników plus więcej, więc różne materiały tam gdzieś się nagromadziły, i PDF-y, i prezentacje, jakieś tam wewnętrzne serwisy o urlopach i innych i chcielibyśmy zbudować wyszukiwarkę, o której rozmawialiśmy, żeby ten przykład już sobie pociągnąć dalej. I teraz oczekiwanie mnie jako użytkownika jest następujące, że ja mam jakąś stronkę, wchodzę tam, jakiś URL i pytam sobie właśnie takie rzeczy, jak sobie zgłosić urlop, albo ile dni urlopu mi przysługuje.

Jak pracowałem w korporacji to dla mnie było dużym wyzwaniem znaleźć system aby zgłosić np. adres do bazy danych (lub odczytać go stamtąd). Bo właściwe były rzeczy takie prawdziwe do rozwiązania, na których warto było skupiać się i biurokratyczne. I dla mnie faktycznie znalezienie procedury, w jaki sposób ja mogę zgłosić jakiś tam dostęp do bazy danych, albo uzyskać ten dostęp do bazy danych, było super skomplikowane.

I osobiście byłbym mega zadowolony, żeby zapytać powiedzmy: „Proszę, jaki jest adres do bazy + i tam jakiś kontekst”, i on mi od razu zwracał, to ja byłbym bardzo szczęśliwy. Więc takie mam zadanie, ja teraz chciałbym, abyśmy przeszli krok po kroku i rozdzielili to na pierwsze takie warstwy poszczególne i też było zrozumiałe, jakie decyzje powinniśmy podjąć w poszczególnych warstwach. Co myślisz o tym?

Piotr: Teraz skupię się na klockach, ale dam disclaimer na początek, że pierwszą rzeczą, którą w ogóle absolutnie w każdym projekcie, a w szczególności w takim projekcie uczenia maszynowego, to chcemy zdefiniować, co właściwie chcemy zrobić i określić sobie cel. Ten cel powinien być jakoś mierzalny.

Takie wiadomo, że tutaj na potrzeby dyskusji pomachamy rękami, powiemy, że chcemy odpowiadać na takie pytania, tak jak powiedziałeś. Natomiast koniec końców zazwyczaj chcemy zacząć od analizy biznesowej – jakiego typu pytania chcemy odpowiadać, jaki zakres, jakie skomplikowanie, kto ma na nie odpowiadać, znaczy kto ma zadawać te pytania.

Często przygotowanie jakiegoś zbioru testowego, który idealnie, jeżeli reprezentuje dobrze te docelowe pytania i tak dalej, to jest absolutny must have na samym początku. O tym możemy jeszcze potem porozmawiać dalej w kontekście jak się buduje dobre zbiory testowe, jak się anotuje dane itd. Ale załóżmy, że to mamy i teraz już faktycznie budujemy konkretne rozwiązanie.

Ja bym powiedział, że kroków jest kilka i rzeczywiście są to takie klocki, które w miarę łatwo jesteśmy w stanie składać i wymieniać. Pierwszym takim dużym klockiem jest po prostu wyszukiwarka.

Wybór dokumentów do bazy wiedzy

Wyszukiwarka składa się z kilku elementów. Najpierw musimy podjąć decyzję jakie dokumenty w ogóle chcemy wciągać do naszej bazy wiedzy. To już jest taka decyzja mocno biznesowa, na jakie pytania chcemy odpowiadać, w związku z tym wciągamy jakieś konkretne dokumenty.

Często te dokumenty są bardzo różne, to mogą być albo jakieś wewnętrzne strony internetowe, może to być jakaś dokumentacja w Confluence czy czymś innym, mogą to być dokumenty takie wordowe czy w Google Docs czy coś takiego.

Tutaj raczej musimy po prostu zdefiniować, na podstawie czego chcemy odpowiadać i jak. Tu też jest trochę trikowych decyzji, na przykład mogą być problemy z uprawnieniami, z dostępem do informacji. Niektórzy pracownicy powinni mieć dostęp do jakiejś informacji, a niektórzy nie.

Jeżeli na przykład mamy dokumenty w Google Docs, to w oczywisty sposób nie możemy wziąć po prostu wszystkich dokumentów w Google Docs całej naszej korporacji, bo tam będą jakieś mniej lub bardziej tajne rzeczy, gdzie konkretne zespoły nie powinny mieć do tego dostępu. Więc jak w ogóle filtrować te dokumenty, skąd brać te dokumenty itd.

To jest taki może mały klocek, ale część polegająca na tym, że musimy te dokumenty, to źródło danych, wybrać.

Reprezentacja dokumentów

Jak mamy już te dokumenty, to pierwszy taki realny klocek to jest to, jak chcemy te dokumenty reprezentować.

Możemy albo je reprezentować i używać wyszukiwarki właśnie takiej klasycznej, opartej o słowa kluczowe. Wtedy jest to względnie proste – bierzemy dokument i wrzucamy cały, reprezentujemy jako słowa kluczowe, czyli dzielimy po prostu na słowa. Być może musimy podjąć tę decyzję, czy chcemy lematyzować te dokumenty, czy nie, ale w końcu jest to względnie proste, gdzie nie ma tutaj dużo decyzji.

Większy problem jest, kiedy chcemy używać tych bardziej współczesnych metod wyszukiwania, czyli tzw. embeddingów albo semantic search, albo ma wiele różnych nazw, ale chodzi o to, żeby reprezentować dokumenty jako jakiś wektor i generujemy ten wektor za pomocą sieci neuronowej, czyli modelu uczenia maszynowego.

Tutaj okazuje się, że ma bardzo duże znaczenie, jak ten dokument podzielimy na kawałki. Możemy oczywiście wziąć cały dokument i wrzucić do takiej sieci neuronowej, i dostać jakiś wektor, ale możemy też ten dokument podzielić na paragrafy i każdy paragraf wrzucić. Możemy też podzielić na zdania i wrzucić każde zdanie, i mieć tak tysiąc wektorów z jednego dokumentu.

Możemy zrobić bardziej trikowe rzeczy, np. użyć LLM-a, żeby napisał nam streszczenie tego dokumentu, czyli co w tym dokumencie jest, i zareprezentować, zaembedować tylko to streszczenie i wrzucić do bazy danych.

Podział dokumentów na fragmenty

Vladimir: Tutaj to są decyzje, które nie powodują dodatkowych problemów technicznych. Często są po prostu gotowe biblioteki, które to robią i każda z tych metod jest równie prosta, i każdą możemy bezpośrednio użyć. Natomiast jest to decyzja trudna produktowo, bo nie jest oczywiste, która z nich jest najlepsza i która w której sytuacji się sprawdzi.

Może podam dwa przykłady na to. Jeden przykład – załóżmy, że mamy system do odpowiadania na pytania o grach planszowych. Czyli chcemy zadać pytanie, nie wiem, czy mogę się ruszyć tym pionkiem tutaj albo o co chodzi w tej karcie, gram w jakąś grę karcianą.

I to jest sytuacja, w której tak naprawdę nie musimy robić wyszukiwania, bo jeżeli jesteśmy w kontekście danej gry planszowej, to źródłem prawdy do tej gry planszowej jest instrukcja tej gry. Instrukcja do gry planszowej zazwyczaj ma najwyżej kilka stron i to jest dostatecznie mało, żeby kolejny krok, jakiś LLM, był w stanie przeczytać całą instrukcję na raz. Więc tak naprawdę nie musimy robić wyszukiwania.

Ale możemy mieć skrajnie inny przykład – projekt, nad którym pracowałem, gdzie trzeba było odpowiadać na pytania dotyczące hoteli, a dla hoteli mieliśmy opinie. Dla danego hotelu mieliśmy tysiące opinii i tam ludzie pytali, czy woda w basenie jest ciepła.

Reprezentacja dokumentów w bazie danych

No i teraz, jak sobie o tym pomyślimy, to w jaki sposób możemy reprezentować te nasze dokumenty? W znaczeniu – każdy dokument to jest opinia.

Tak możemy całą opinię traktować jako taki jeden tzw. chunk i coś takiego wrzucać do bazy danych, ale w przypadku takich pytań o fakty, o jakieś cechy produktu, usługi, czegokolwiek, przez to jest za dużo.

W tej opinii ludzie wymienią 20 różnych cech. No, że woda była ciepła, ale szkoda, że ta plaża była daleko, a drinki to w ogóle były beznadziejne, ale przynajmniej było czysto w hotelu i tak dalej, i tak dalej.

Nie potrzebujemy kontekstu całej opinii, żeby zrozumieć, że woda była ciepła. Wystarczy, że podzielimy sobie tę całą opinię na takie króciutkie frazy rzeczownikowe – po prostu „woda była ciepła”, na pojedyncze zdania czy nawet mniej i coś takiego będziemy enkodować i wrzucać do bazy danych.

Generalnie, im – nazwijmy to – czystsze, czyli im mniej informacji będzie w tych pojedynczych chunkach, tym lepiej, tym łatwiej będzie je wyszukać. No bo jeżeli widzimy całą opinię, to będziemy mieli tak z 20 różnych informacji.

Trudniej jest wyszukać coś, co ma 20 informacji, versus coś, co ma jedną informację, takie to the point. Więc w zależności od problemu – czasami musimy robić wyszukiwanie, czasem to wyszukiwanie jest proste, właśnie po jakichś metadanych, jaka to jest gra planszowa i tyle, a czasami możemy sobie dzielić bardzo drobno, czasami nie możemy dzielić bardzo drobno.

Tak, jeżeli mamy jakiś akt prawny i chcemy wyszukać akt prawny, no to raczej jeżeli wyszukamy po jakimś drobnym detalu, po jakimś pojedynczym zdaniu, to zgubimy cały kontekst dokumentu i to nic nam nie będzie mówić. Więc w zależności od problemu jakoś musimy dzielić te dokumenty na kawałki.

Jak podzielić dokumenty na fragmenty?

Vladimir: Czekaj, ja cię troszkę przepytam, bo tutaj też chciałem podpytać – powiedziałeś, że „woda ciepła”, a potem ta cała reszta – plaża i tak dalej – będzie niepotrzebna w tym kontekście. Super, brzmi fajnie, tylko jak to podzielić? Bo to nie jest podział per kropka, per spacja, tylko taki bardziej semantyczny sposób, żeby to podzielić. I tutaj na pewno trzeba coś zatrudnić bardziej mądrego niż tylko takie regexpy. I jak to zrobić?

Piotr: Znaczy, te pomysły są dwa albo trzy. Znaczy, ja szczerze mówiąc po prostu dzieliłem, w cudzysłowie, „po kropce”, w sensie dzieliłem po pełnych zdaniach i to było dostatecznie dobre przybliżenie.

Można używać czegoś, co się nazywa parsowanie zależnościowe, to jest taki lingwistyczny termin. Znaczy, można – nie wiem, czy pamiętasz – w podstawówce rysowało się drzewka gramatyczne zdań.

No i coś takiego też można robić automatycznie za pomocą uczenia maszynowego. To było popularne 15-20 lat temu w przetwarzaniu języka naturalnego, ale nadal się to czasami wykorzystuje właśnie po to, żeby automatycznie podzielić to zdanie, że tu są frazy rzeczownikowe i te frazy rzeczownikowe są osobne, a pomiędzy nimi jest koordynacja, czyli a, b i c.

To są trzy osobne komponenty i okazuje się, że względnie łatwo jesteśmy w stanie automatycznie to podzielić na kawałki, więc jakby to jest drugi pomysł, jak można do tego podejść.

A trzeci pomysł to po prostu użycie LLMów znowu, właśnie na etapie takiego preprocesingu, na zasadzie: „Tak, wylistuj mi wszystkie cechy tego hotelu”.

No i on wypisze, jeżeli napiszemy dobry prompt, no to wypisze, że woda jest ciepła, pokój jest czysty i tak dalej. To notabene, to może już uprzedzając i wyprzedzając, w przypadku tego projektu o hotelach to może mieć fundamentalne znaczenie, jeżeli o tym pomyślimy.

Problem z wyszukiwaniem fragmentów

Jeżeli mamy 1000 opinii i 900 osób napisało, że woda jest ciepła, a 100 osób napisało, że woda jest zimna, to chcielibyśmy wiedzieć, że faktycznie 90% osób napisało, że woda jest ciepła.

Ale jeżeli wyszukamy sobie kilka tak najbardziej podobnych zdań w tym przypadku, które opisują ciepłotę wody, no to w szczególności jak ktoś zapyta, czy woda jest ciepła, to semantycznie bardziej podobne będą zdania „woda jest ciepła” niż że „woda jest zimna”.

Jak ktoś zapyta, czy woda jest zimna, to bardziej podobne będą te zdania „woda jest zimna”. No i teraz będzie bardzo duży problem, jeżeli ktoś zapyta, czy woda jest ciepła, znajdziemy powiedzmy 10 zdań, gdzie ludzie piszą, że woda jest ciepła i damy odpowiedź: „Tak, woda jest ciepła”.

Jak ktoś zapyta, czy woda jest zimna, znajdziemy 10 zdań, gdzie ktoś napisał, że woda jest zimna i odpowiemy: „Tak, woda jest zimna”. Widzisz, to jest absurdalne, bo model nam odpowie w zupełnie inny sposób, zależnie od tego, jak zadamy pytanie.

Wybór modelu do tworzenia embeddingów

Piotr: Kolejna ważna decyzja to czym tworzymy te embeddingi. To nie jest oczywisty wybór. Mogliśmy w ogóle ominąć ten krok i używać słów kluczowych, ale zazwyczaj w dzisiejszych czasach chcemy używać metod semantycznych, czyli sieci neuronowych, które przetwarzają teksty w konkretne wektory.

Wybór modelu jest bardzo istotny, bo te modele różnią się jakością. Często ludzie sięgają po popularne rozwiązania, jak np. embeddingi od OpenAI. Ich nowsza, trzecia wersja jest już w porządku, ale poprzednia była po prostu tragiczna, szczególnie dla języka polskiego. Trzecia też nie jest najlepsza, ale wystarczająco dobra.

To było coś prostego w użyciu, ale bardzo słabego. Wyszukiwaliśmy w jakimś sensie podobne teksty do naszego pytania, podobne dokumenty czy chunki, ale one były podobne tylko według OpenAI, a nie według tego, jak my na to patrzymy. Widzieliśmy, że to jest totalnie od czapy.

Wybór modelu wpływa na to, czy rozwiązanie będzie działać, czy nie. Wracając do twojego pytania, co się zmieniło w ciągu ostatnich 10 lat – to zmieniło się bardzo mocno. Jeszcze 5 lat temu, jeśli mieliśmy model do wyszukiwania informacji, potrafił on działać sensownie tylko w jednej domenie.

Jeśli mieliśmy problem wyszukiwania opinii o hotelach i model wytrenowany pod kątem opinii hotelowych, to użycie go dla danych prawniczych skończyłoby się totalną porażką. W danych hotelowych działałby może trochę lepiej niż wyszukiwanie po słowach kluczowych, ale po przejściu do innej domeny, innego typu tekstu, działałby już praktycznie losowo.

Postęp w dziedzinie modeli językowych

Piotr: Tak, bo to, teraz kolejna decyzja to jest, ale właściwie czym embedujemy, tak, czym tworzymy te embeddingi. I to też nie jest oczywista decyzja, tak, w sensie mogliśmy w ogóle ominąć ten krok i używać słów kluczowych, ale zazwyczaj w dzisiejszych czasach chcemy używać takich metod, tak zwanych semantycznych, czyli właśnie sieci neuronowych, które przetwarzają te teksty w konkretne wektory.

No i to jest bardzo nieoczywista decyzja, którego modelu użyjemy. I to jest bardzo ważna decyzja, bo te modele są lepsze albo gorsze. Często ludzie używają jakichś popularnych modeli, na przykład tak, postulant embeddingów od OpenAI i ta nowsza wersja, wersja trzecia, już jest okej, ale ta poprzednia wersja była po prostu tragiczna, przynajmniej dla języka polskiego. Ta trzecia też nie najlepsza, ale good enough może.

To było coś, co jest bardzo proste do użycia, ale ono było bardzo słabe i okej, wyszukiwaliśmy w jakimś sensie podobne teksty do tego naszego pytania, podobne dokumenty, podobne te chunki, ale one były tylko podobne według OpenAI, a nie według nas, jak na to patrzymy, bo widzimy, że to jest totalnie od czapy.

No i tutaj to, jak wybierzemy ten model, właśnie wpływa na to, czy to będzie działać, czy nie. I trochę wracając do tego pytania twojego, co się zmieniło w ciągu ostatnich 10 lat, to to się bardzo mocno zmieniło, w sensie jeszcze 5 lat temu nawet, jeżeli mieliśmy taki model do wyszukiwania informacji, to on potrafił działać tylko i wyłącznie w jednej domenie sensownie, znaczy jak mieliśmy ten problem, powiedzmy, wyszukiwania opinii o hotelach i mieliśmy wytrenowany model pod opinie dla hoteli i byśmy użyli go dla danych prawniczych, to on totalnie by nie działał.

W sensie w tych danych hotelowych on pewnie działałby trochę lepiej niż wyszukiwanie po słowach kluczowych, ale jak byśmy musieli przejść do innej domeny, do innego typu tekstu, to on by już działał praktycznie losowo.

Generowanie syntetycznych danych treningowych

PIotr: I okazało się, że to było bardzo trudne, żeby przeskoczyć to i żeby mieć model, który faktycznie daje uniwersalnie dobre embeddingi. To się udało dosłownie 2-3 lata temu, głównie w ten sposób, że po prostu wzięliśmy bardzo, bardzo dużo danych i wytrenowaliśmy model na wszystkich domenach naraz. W jaki sposób jest to oszustwo? Nadal nie potrafimy generalizować, czyli dobrze działać na nieznanych domenach.

Tak poradziliśmy sobie z tym w ten sposób, że wytrenowaliśmy model na wszystkich możliwych domenach, co jest w pewnym sensie oszustwem, ale dopóki działa praktycznie, to w sumie czemu nie. I rzeczywiście są takie modele, które teraz działają sensownie dla wielu różnych domen, i to dla angielskiego, i też dla polskiego takie modele się pojawiają.

Natomiast wciąż te modele nie są zazwyczaj idealne. One są generyczne, uniwersalne i działają ok, ale jeżeli chcemy mieć naprawdę super dobrą skuteczność, to wciąż bardzo wartościowe jest, żeby wytrenować ten model specjalnie dla siebie, w twojej konkretnej niszy. To daje bardzo duże zyski.

Trenowanie własnego modelu

Piotr: Więc ja zazwyczaj to, co rekomenduję, to w pierwszym kroku użyć takiego modelu uniwersalnego i sprawdzić, jak on będzie działać, sprawdzić na naszym zbiorze testowym, czy on faktycznie zwraca dobre dokumenty, dobre w znaczeniu zawierające odpowiedź. Często zwraca dostatecznie dobre.

Powiedzmy, że zwraca dobry dokument w 90% przypadków i to jest użyteczne, ale czasami dla nas ma znaczenie, czy to będzie 90 czy 95%, czy tak może się zdarzyć, że to jest 60 vs 90%. I wtedy jest inny klocek, kolejny klocek na zasadzie – wytrenujmy swój własny model do tego celu.

I to też jest coś, co się radykalnie zmieniło w ciągu tych ostatnich paru lat, bo kiedyś, żeby wytrenować taki model, trzeba było mieć dane, no ale żeby mieć dane, to trzeba zatrudnić ludzi, którzy będą anotować dane. To było zaskakująco trudne w znaczeniu, że tych danych, żeby wytrenować taki model do embeddingu, potrzebujemy dosyć dużo, w sensie to są raczej dziesiątki tysięcy takich par – pytanie, dokument.

W związku z tym trzeba jakoś te pary napisać, trzeba albo mieć pytania skądś, na przykład historyczne pytania od użytkowników i dla tych pytań znaleźć dokumenty w naszej bazie danych, albo nie mamy historycznych pytań od użytkowników, więc trzeba sobie jakoś radzić i albo wymyślać te pytania, i potem znajdować dokumenty, albo brać te dokumenty i do nich pisać pytania. No ale dość, że to było bardzo czasochłonne i jakby koniec końców kosztowało dużo pieniędzy i nie zawsze warto było to robić.

To, co się stało niesamowitego w ostatnich czasach przez LLM-y, to że możemy użyć po prostu LLM-ów, żeby te pytania wygenerować automatycznie. Czyli bierzemy sobie nasze dokumenty, które mamy w bazie danych, i pytamy tak ChatGPT: „Wygeneruj mi pięć pytań do tego dokumentu”. I on generuje pytania, a te pytania są zaskakująco sensowne.

Czasem warto coś tam pofiltrować, poczyścić te rzeczy, ale możemy to robić automatycznie. I teraz nagle wygenerowanie dziesięciu tysięcy pytań czy pięćdziesięciu tysięcy pytań to koszt pięćdziesięciu dolarów – absolutnie zerowy w skali jakiejś korporacji.

I mając te pięćdziesiąt tysięcy pytań, jesteśmy w stanie już dotrenować jakiś taki uniwersalny model do embeddingów pod nasze potrzeby, ponieważ jest to dotrenowanie. Dotrenowanie zazwyczaj jest jakby mało zasobochłonne, często zajmuje po prostu godzinę czasu na jednej karcie graficznej i już wtedy ten model jest dużo, dużo lepszy.

Więc też właśnie to, co się zmieniło, to możliwość szybkiego dostosowania tych modeli dzięki temu, że możemy łatwo wygenerować sobie syntetyczne dane treningowe.

Wiadomo, że te dane treningowe nie są super jakości, one będą miały błędy, nie mają tych wszystkich subtelności, które powinny tam być, ale jesteśmy w stanie szybko dojść do sensownego poziomu. A potem, jeżeli nadal chcemy mieć lepszą skuteczność, to już nie uciekniemy od tego, że ktoś musi usiąść, zanotować te dane i stworzyć dane wysokiej jakości.

Embeddingi – konwertowanie tekstu na reprezentację numeryczną

Vladimir: To teraz ja już spróbuję tak podsumować to, co wybrzmiało i idziemy dalej.

Czyli kiedy jesteśmy na etapie embeddingu, czyli chcemy skonwertować nasz tekst w reprezentację numeryczną, to pierwsza rzecz: nie chcemy używać jakiejś znanej nazwy jak OpenAI ot tak domyślnie bez rozważenia, bo zwykle to nie działało w tej poprzedniej wersji. I mimo że GPT jest super, to nie znaczy, że embeddingi też będą super, tym bardziej dla nas, więc to jest do rozważenia.

Druga rzecz to trzeba rozważyć, jak nie to, to co wtedy. I to jest super, że w ogóle te pytania się pojawiają, bo można zacząć wybierać. Warto podpowiedzieć, że są na przykład takie leaderboardy MTEB albo jakieś tam inne, gdzie można sobie wybrać takich fajnych kandydatów, których można byłoby rozważyć.

I też, co fajnie powiedziałaś, że owszem, teraz są bardziej takie ogólne rozwiązania, ale też może tak się zdarzyć, że mamy jakąś bardziej konkretną potrzebę i wtedy może być lepiej, żebyśmy my dotrenowali to do siebie, ale też żeby to było obiektywne, to weźmiemy coś bardziej ogólnego.

Mamy wynik, potem bierzemy coś bardziej konkretnego pod nas, czyli dotrenujemy pod naszą domenę. Też na przykład język polski już sam w sobie jest domeną, bo też te wyrazy itd. już też to komplikują. I wtedy dostajemy rozwiązanie, które będzie de facto lepiej reprezentować te semantyczne zależności, jeżeli chodzi o dane na wejściu, czyli dane w postaci tekstu, i na wyjściu to będą wartości numeryczne.

Dobra, mamy to. Idziemy dalej, co tam dalej nas czeka?

Reranking – ulepszanie wyników wyszukiwania

Piotr: Mamy to. Dobra, to teraz ostatni krok wyszukiwania, bo jak robimy to wyszukiwanie, zazwyczaj znajdujemy dla danego pytania 10, 20 albo 100 najbardziej podobnych dokumentów. Te dokumenty będą rzeczywiście podobne, ale nie będą łapać tych wszystkich subtelności, bo one będą podobne, ale niekoniecznie będą odpowiadały na pytanie.

To z różnych względów technicznych jest trudne do uzyskania, żeby te zwrócone dokumenty były faktycznie świetnej jakości. I teraz dochodzi nam kolejny klocek, czyli tzw. reranking. Znaczy, jak mamy te 100 zwróconych dokumentów, to czy możemy bardziej złożonym, bardziej skomplikowanym, lepszym modelem maszynowym przesortować te dokumenty tak, że jeżeli ten poprawny dokument był na 90. pozycji, to żeby wynieść go na pierwszą pozycję.

Tutaj oczywiście też jest dużo podejść, możemy używać LLMów do tego, zrobić zapytanie do OpenAI, czy ten dokument odpowiada na to pytanie – tak, nie.

Generowanie odpowiedzi

Piotr: Możemy użyć opensource’owych modeli, możemy też trenować swoje modele do tego zadania i to często też pomaga, żeby jeszcze bardziej poprawić te wyniki wyszukiwania. Oczywiście wiąże się to z kosztem finansowym, bo musimy zrobić np. odpytania do OpenAI, ale też kosztem jeżeli chodzi o czas odpowiedzi, bo wkładamy kolejny klocek i on zajmuje jakiś czas. To czasami jest potrzebne, czasami nie. Tak naprawdę znowu, to jest zależne od konkretnego wdrożenia, od konkretnego produktu.

Czasami te wyniki z tego pierwszego wyszukiwania są na tyle dobre, że nie musimy tego poprawiać. A czasami niestety tak nie jest i musimy dołożyć kolejny klocek.

Vladimir: Ja chciałem tylko tak dopowiedzieć, że na początek mamy powiedzmy 100 tysięcy albo 10 tysięcy dokumentów, więc „pierwsze wyszukiwanie” robi takie szybsze, ale mniej precyzyjne wyszukiwanie i z tych 100 tysięcy dostarczy nam np. 100 dokumentów.

Ale żeby faktycznie znaleźć najbardziej trafny dokument, to czasem może nam się opłacać zatrudnić troszkę bardziej skomplikowany mechanizm, co zwykle nam powiększa czas, bo nic nie ma za darmo, no i też jakieś pieniądze prawdopodobnie będą za tym. Ale dzięki temu możemy liczyć na to, że znajdziemy faktycznie bardziej konkretniejsze, też możemy się mylić, ale tak z punktu widzenia tego mechanizmu, bardziej trafny dokument i mamy w ten sposób wybrany ten dokument numer jeden.

Piotr: Dokładnie tak. Zazwyczaj nie dokument numer jeden, tylko wciąż kilka dokumentów, pięć najlepszych dokumentów, kilka najlepszych dokumentów.

Tak i to zakończyliśmy ten etap wyszukiwania i teraz zazwyczaj jest ten etap generowania odpowiedzi i on często, przynajmniej w takim najprostszym wariancie, jest w sumie prosty. Znaczy bierzemy to pytanie, bierzemy te pięć dokumentów i współcześnie po prostu wysyłamy to do OpenAI, do ChatGPT i prosimy o odpowiedź na pytanie. I ChatGPT odpowiada na to bardzo dobrze zazwyczaj. To jest też fajne, bo on wtedy raczej nie halucynuje, co się zdarza później wiadomo, ale raczej korzysta z tych informacji, które były w znalezionych dokumentach, żeby odpowiedzieć na pytanie.

Trenowanie własnych modeli

Piotr: Oczywiście to jest coś, co się tak pojawiło te dwa lata temu razem z popularyzacją ChatGPT. Wcześniej trenowaliśmy też specyficzne modele, które właśnie te informacje, te odpowiedzi wyciągały.

I to albo na takiej zasadzie, jakby początkowo to było, żeby zaznaczyć fragment dokumentu, który zawiera odpowiedź. Czyli jak powiedzmy to pytanie o urlop, ile mam dni urlopu, to gdzieś tam pewnie była rozpiska, że w zależności od stażu to ma się tyle i tyle dni urlopu i wtedy byśmy dostali odpowiedź jako zaznaczony fragment tego oryginalnego dokumentu.

No ale to jest mega ograniczone podejście. Jeżeli sobie pomyślimy o pytaniach typu „tak, nie”, no to nie możemy w dokumencie zaznaczyć „tak, nie”, czyli „czy mam 26 dni urlopu” i możemy zaznaczyć tylko „26 dni urlopu przysługuje osobie, która coś tam coś tam”. Tak, ale nie dostaniemy odpowiedzi „tak”, bo tego „tak” nie ma w dokumencie.

Potem pojawiły się modele właśnie takie generatywne, które były specjalnie trenowane do tego, żeby wziąć pytanie, wziąć te dokumenty i wygenerować faktyczną odpowiedź. Do tego często potrzebowaliśmy przygotować sobie jakieś dane treningowe, zazwyczaj parę, paręnaście, parędziesiąt tysięcy takich przykładów, wytrenować model i mogliśmy go użyć, żeby odpowiadać na pytania. Natomiast te LLM-y obecnie używane są super dlatego, że nie musimy mieć danych treningowych i one działają dostatecznie dobrze.

Oczywiście, jeżeli zależy nam na tym, żeby model odpowiadał w jakimś konkretnym stylu albo żeby po prostu odpowiadał lepiej, to wciąż możemy ten model dotrenować. To też może nie wszyscy wiedzą, ale modele od OpenAI, w sensie Chata GPT, też można w ich interfejsie sobie dotrenować, jeżeli mamy jakieś dane i tak dostosować do naszych potrzeb.

To jest powiedziałbym dziedzinowo proste, wystarczy dać takie pary: pytanie, dokumenty i oczekiwana odpowiedź. Nawet jak przygotujemy 100 takich przykładów, to już ten model będzie działał dużo, dużo lepiej. Wtedy odpytywanie Chata GPT będzie trochę droższe, ale często jakość będzie istotnie lepsza i te odpowiedzi będą bardziej dostosowane do tego, czego oczekujemy.

Natomiast zazwyczaj po prostu korzystamy z Chata GPT, Anthropic czy z jakichś oczywiście innych konkurencyjnych rozwiązań – Gemini, Claude i tak dalej. One wszystkie działają bardzo fajnie.

Wielkość kontekstu w modelach językowych

Vladimir: Jaka jest obecnie typowa wielkość dokumentu, który można przesłać do modelu językowego w jednym zapytaniu? Fajnie byłoby to przedstawić w liczbie stron, aby ludzie mogli to sobie lepiej wyobrazić. I druga kwestia – jakie są dobre praktyki w tym zakresie? Bo nie wszystko co się da, warto robić, prawda?

Piotr: To ważna kwestia, którą poruszyłeś. W standardowym, najprostszym setupie, o którym mówiłem, nawet nie wyciągamy całych dokumentów, tylko tzw. chunki, czyli fragmenty. Zazwyczaj będzie to jedno zdanie, maksymalnie parę zdań. Więc nawet jak wyciągniemy pięć takich chunków, to nie będzie tego dużo – maksymalnie jedna strona tekstu. To jest coś, co bez problemu każdy model językowy przetworzy.

Natomiast rzeczywiście, w zależności od problemu, taki chunk może nie zawierać wszystkich potrzebnych informacji. Czasem potrzebujemy szerszego kontekstu, na przykład całego dokumentu. Tutaj jest kilka różnych trików, które można zastosować.

Jeden standardowy trik polega na tym, że skoro mamy jakiś chunk, ale chcemy mieć większy kontekst, to bierzemy jeszcze dwa chunki poprzedzające ten główny i dwa następujące po nim. Wtedy takie pięć chunków wrzucamy. To daje nam dwadzieścia pięć bazowych chunków, czyli już około pięć stron tekstu. Ale czasami nawet to może być za mało i musimy znać cały dokument.

Sposobów radzenia sobie z dużymi dokumentami jest wiele. Na szczęście w dzisiejszych czasach okno kontekstowe (context window) różnych modeli językowych jest na tyle duże, że nie musimy się tym aż tak bardzo przejmować. To są raczej dziesiątki tysięcy tokenów, a nawet setki tysięcy. Gemini od Google obsługuje nawet milion tokenów. Więc to są absurdalne ilości, których nigdy nie wykorzystamy w takim setupie odpowiadania na pytania. W innych zastosowaniach oczywiście możemy je wykorzystać.

Jednym z rozwiązań jest takie, że jak mieliśmy tych pięć oryginalnych chunków, to tak naprawdę robimy pięć odpytań do modelu językowego. Pytanie plus pierwszy chunk – chcemy dostać odpowiedź, pytanie plus drugi chunk – chcemy dostać odpowiedź, i tak dalej. Wysyłamy więc pięć różnych zapytań i dostajemy pięć różnych odpowiedzi.

Możemy też zrobić dodatkowy krok, że nie tyle generujemy odpowiedź, co wyciągamy istotne informacje. Czyli bierzemy pytanie, pierwszy cały dokument i prosimy model o wyciągnięcie kluczowych informacji z tego dokumentu.

Wyciąganie kluczowych informacji z dokumentów

Zazwyczaj tych kluczowych informacji nie będzie aż tak dużo, żeby odpowiedzieć na pytanie. One będą po prostu rozsiane w różnych miejscach po tym dokumencie. Powtarzamy to pięć razy dla każdego z tych pięciu dokumentów, więc zbieramy koniec końców dosyć małą ilość danych i wrzucamy do finalnego promptu do LLM-a. Wygeneruje on odpowiedź na podstawie tych wyciągniętych cytatów i dzięki temu możemy sobie radzić z tym ograniczonym kontekstem.

To też ma znaczenie o tyle, że jeżeli zrobimy pięć takich odpytań równolegle w tym samym czasie, to będzie to szybsze niż jedno odpytanie z bardzo długim dokumentem.

Vladimir: Wydaje mi się, że w miarę pokryliśmy temat, przynajmniej tak high level, żeby mniej więcej było zrozumiałe, jakie są warstwy i jakie decyzje należy podejmować. Temat rzeka. Ja też nie stawiałem aż tak ambitnego celu, żeby omówić wszystkie szczegóły, bo tego jest wiele.

Triki i detale w budowaniu chatbotów

Piotr: Tak, tego jest bardzo, bardzo dużo i generalnie takich trików – ludzie wymyślają bardzo dużo tych trików i to na każdym z tych etapów. Ja też przedstawiłem taką ścieżkę dosyć podstawową. Mimo że już wchodziliśmy w jakieś detale, to tych detali może być bardzo, bardzo dużo.

Problem jest taki, że wybór tych detali bardzo mocno zależy od konkretnego projektu i nie jest tak, że któreś z tych rozwiązań są dobre. One bywają dobre, ale często bywają złe. Często też na przykład ta sama konstrukcja naszego chatbota czy systemu odpowiadania na pytania wymaga czegoś więcej, jakichś dodatkowych funkcjonalności.

Na przykład, jeżeli mamy asystenta prawniczego i chcemy odpowiadać na pytania prawnicze, to nie jest tak, że jedyne kryterium to czy ten dokument będzie pasujący do pytania, ale też czy będzie aktualny. Tak więc możemy na przykład sortować jeszcze te dokumenty po tym, jak one są aktualne, z którego są roku. Możliwe, że powinniśmy filtrować po jakichś metadanych i tak dalej. Więc tych detali jest jeszcze bardzo, bardzo dużo, ale to jest taki najprostszy możliwy przepływ.

Rozwiązania szyte na miarę

Vladimir: Fajnie, że to wybrzmiało, bo mimo tego, że istnieje ta cała magia, jeżeli chodzi o LLM, który faktycznie zaskoczył wszystkich osób technicznych możliwością porozmawiania i tak dalej, to nadal rozwiązanie jako takie musi być szyte na miarę. Tutaj właśnie zdefiniowanie, co potrzebuje biznes, jaka jest metryka sukcesu, jakie błędy są dopuszczalne, jakie są niedopuszczalne, jaki jest koszt takich błędów. W zależności od tych wszystkich wytycznych pojawia się to finalne rozwiązanie i stąd właśnie musi być ono szyte na miarę, a te warstwy są dość elastyczne w zależności od potrzeb. Bywa różnie.

Kluczowe kompetencje w budowaniu projektów ML

Piotr: Wracając jeszcze raz do tego pytania, co się zmieniło w przeciągu ostatnich 10 lat. W tym sensie nic się w świecie nie zmieniło. Dostaliśmy nowe zabawki, nowe narzędzia, one działają dużo lepiej niż działały kiedyś, ale te kluczowe kompetencje – kiedyś to byli statystycy, potem data scientiści, potem ML inżynierowie, teraz AI inżynierowie – te nazwy stanowisk, nazwa dziedziny się co chwilę zmienia, narzędzia się zmieniają.

Ale te kluczowe kompetencje są dokładnie takie same cały czas i te problemy są też dokładnie takie same. Chcemy wiedzieć, co musimy budować, jak dobrać odpowiednie klocki, żeby zrealizować cele biznesowe, gdzie popełniamy błędy, jaki jest kompromis między skutecznością a kosztami itd.

I jasne, że mamy zupełnie inne klocki do dyspozycji dzisiaj niż 10 lat temu, ale sam proces budowania projektu machine learningowego tak naprawdę nie zmienił się – powiedziałbym, że prawie w ogóle. Może trochę, rzadko już teraz pisze się sieci neuronowe np. od zera w PyTorchu, raczej się wykorzystuje jakieś gotowe klocki, ale nigdy to pisanie sieci neuronowych w PyTorchu, czy wcześniej w TensorFlow, czy w Theano, to nigdy nie było clou problemu.

Narzędzia do adnotacji danych

Vladimir: Powiedz kilka rzeczy na temat narzędzi, których używasz w kontekście tekstu, obrazków. Jakie rzeczy są dla ciebie przydatne? Chcielibyśmy, żeby inni też to usłyszeli. No i jak sobie to układasz mentalnie, motywacyjnie, że chce ci się to robić?

Piotr: Jeśli chodzi o narzędzia do adnotacji danych, to jest bardzo trudne pytanie, bo różnie. W swoim życiu napisałem pewnie z 10 różnych narzędzi do adnotacji danych, tak po prostu dla siebie, w zależności od projektu. Często to jest najlepsze rozwiązanie, bo te adnotacje danych bywają na tyle specyficzne, że warto napisać coś swojego.

Mogą to być bardzo proste rzeczy, na przykład Google Sheets, gdzie po prostu robimy sobie arkusz, w jaki sposób go filtrujemy, sortujemy i tam piszemy adnotacje. Klocki Lego anotuję głównie w Jupyter Notebooku. Mam po prostu taką prostą aplikację w Jupyter Notebooku napisaną do adnotacji danych, bo tam robię bardzo dużo filtrowania tego, jakie dokładnie dane chcę zaadnotować. To filtrowanie tak po prostu robię w Pythonie.

Motywacja do żmudnej pracy

Piotr: Mnie zawsze najbardziej napędza zrobienie projektu. Najważniejsze dla mnie jest to, że chcę po prostu zbudować jakiś model, produkt, coś stworzyć. Tak naprawdę, co dokładnie robię, nie ma aż tak dużego znaczenia.

Może adnotacja danych jest nudna, powtarzalna i człowiekowi się nie chce tego robić. Ja też nie jestem w stanie wytrzymać dłużej niż pół godziny czy godzinę, siedząc i adnotując te dane. Po prostu wiem, że jest to konieczne, potrzebne i wartościowe, więc samo to mnie motywuje.

Pisanie kodu też nie zawsze jest super miłe i przyjemne, jest męczące, uciążliwe, trzeba myśleć i też się nie chce. Wyskakują jakieś błędy. W pewnym sensie wolę adnotować dane, bo tam przynajmniej klikam ten klocek, ten klocek, ten klocek i jest to przynajmniej bezstresowe. Więc motywuje mnie efekt końcowy, tak w skrócie.

Natomiast rzeczywiście dzielę sobie też często tę adnotację tak, żeby po prostu robić po trochu. Staram się mieć zawsze gotową jakąś adnotację danych, w sensie jakoś ustawiony proces adnotacji danych. Także jak mam przerwę pomiędzy spotkaniami 15 minut, to mogę sobie otworzyć to narzędzie do adnotacji danych i trochę poklikać. Albo jem obiad i nic mi się innego nie chce robić, to sobie poklikam. Czy jest wieczór i już jestem zmęczony, i nie chce mi się pracować, a trochę sobie poklikam.

Tak jak powiedziałeś, że robię to bardzo regularnie, to też nie do końca prawda. Są takie miesiące dwa, trzy, że na przykład anotuję codziennie dane, a potem mam już tak bardzo dosyć, że przez kolejne dwa miesiące w ogóle na to nie mogę patrzeć.

Vladimir: Trochę mnie uspokajasz, bo to brzmi jak szaleniec już wreszcie.

Piotr: Nie, nie, nie, to znaczy jestem szalony, ale nie aż tak szalony.

Narzędzia do anotacji danych

Piotr: Nie byłbym w stanie tego robić sensownie w jakimś gotowym narzędziu, w szczególności, że to często jest mniej lub bardziej dynamiczne, więc nie mogę wrzucać jakichś batchy. Wygodnie jest mi to anotować w Jupyter Notebooku.

Natomiast z takich narzędzi, z których faktycznie korzystam regularnie, to jest na pewno Label Studio. To jest takie narzędzie open source’owe, bardzo elastyczne, można odpalić lokalnie lub na serwerze w chmurze. Jest to narzędzie w miarę uniwersalne – i do tekstu, i do obrazków, i do bardzo wielu różnych typów danych.

Oni mają w miarę elastyczny system definiowania interfejsu, czyli co chcemy wyświetlać i w jaki sposób. To działa ok. Na pewno nie jest to świetne narzędzie, ale działa dostatecznie dobrze, więc jak jest coś bardziej standardowego, to po prostu używam tego.

Albo jeżeli jest coś, co jest trudne do zaimplementowania samemu, np. rysowanie bounding boxów czy prostokątów, żeby zaznaczyć gdzie klocek Lego znajduje się na zdjęciu, to napisanie czegoś takiego byłoby odrobinę bardziej skomplikowane. Więc warto użyć czegoś gotowego, jak Label Studio.

Jest trochę komercyjnych rozwiązań, które też są spoko, ale one w dużej mierze wszystkie są w miarę podobne, więc czego nie użyjemy, to będzie ok.

UX narzędzia do anotacji

Piotr: Dla mnie ważne jest to, żeby UX rozwiązania był dobry. To narzędzie powinno nam pomagać anotować dane, a nie przeszkadzać. Nie powinniśmy robić 10 kliknięć, żeby zrobić jedną anotację, tylko jedno kliknięcie i już.

Istotniejsze od tego, jakiego używamy narzędzia, jest to, w jaki sposób w ogóle przedstawimy problem anotacji danych. Przykładowo klocki Lego. Jest 80 tysięcy klocków Lego i mam jakieś zdjęcia od użytkowników, które muszę przypisać, jaki klocek jest na danym zdjęciu.

Oczywiście mógłbym to robić naiwnie, na zasadzie mieć zdjęcie i 80 tysięcy klas, i teraz przeglądać te klasy. Ale to byłoby nierealne, bo nie przeskrolowałbym tych 80 tysięcy klas, plus nie znam wszystkich tych klas. Więc wiadomo, że tutaj anotacja musi działać w taki sposób, że mam oryginalne zdjęcie i np. 5 predykcji modelu, co to jest za klocek.

Wtedy wybieram najbardziej prawdopodobny klocek. Muszę mieć też np. link do jakiejś „Wikipedii klockowej” dla każdego z tych polecanych klocków, żebym mógł wejść i poczytać, czy to jest na pewno ten klocek, zobaczyć więcej zdjęć.

Więc to za-setupowanie sobie, jak dokładnie anotujemy dane, wpływa na to, czy robimy to szybko czy wolno i czy robimy to poprawnie czy nie.

Eksperyment z klasyfikacją tekstu

Piotr: Pamiętam, jak jeszcze pracowałem w Allegro, robiliśmy taki eksperyment. Robiliśmy klasyfikację tekstu i albo klasyfikowaliśmy tekst na zasadzie: tu jest tekst i mamy 100 labelek, i wybierz poprawną labelkę, albo: tu jest tekst i wydaje nam się, że to jest ta labelka, i potwierdź albo nie. Powiedz, czy to jest poprawna labelka, czy nie.

Okazało się, że w takim set-upie binarnym, gdzie tylko potwierdzasz tak/nie, uzyskaliśmy dużo szybsze anotacje. Człowiek był w stanie zaanotować dużo więcej danych i te dane były dużo lepszej jakości. Bo człowiek nie musiał w głowie trzymać tych 100 labelek i zastanawiać się, która z nich będzie poprawna.

Tylko widział wiadomość, widział labelkę, widział klasę, mówił: „A, no tak, to pasuje” i ok, i lecimy dalej. I to ma naprawdę bardzo duże znaczenie.

Podsumowanie

Vladimir: Chciałem podsumować to, co usłyszałem. Czyli tak naprawdę anotacja sama w sobie to też wymaga podejścia produktowego. Nie wystarczy tylko pobrać któreś, nawet modne czy płatne, narzędzie, bo to jest jeden z możliwych klocków, który ma tam powstać. Liczy się to, co pojawia się jako wynik, też jaki czas potrzeba spędzić, aby ten wynik osiągnąć.

Ta łatwość musi być jak największa i często może być taka sytuacja, że proste narzędzia, jak arkusz czy coś takiego, nadal wchodzą w grę. Bo czemu nie? Spełniają podstawowe warunki i pomagają dostarczyć to, co jest potrzebne na koniec.

Piotr: Jasne, taki arkusz, jak w Google Docs, jest super do anotacji tekstu. Mamy jakąś wiadomość i chcemy sprawdzić, w jaki sposób anotowałem poprzednie tego typu wiadomości.

Mogę zrobić Ctrl+F i szybko mam znalezione inne podobne wiadomości, i widzę: „A, dobra, anotowałem to w taki sposób”. Jakbym miał jakieś zewnętrzne narzędzie, to pewnie mógłbym się cofnąć z widoku anotacji, przejść do widoku wszystkich tekstów, potem mieć jakieś wyszukiwanie, coś wyszukać, wejść w te wiadomości i zajęłoby mi to dużo więcej czasu.

Czasami nie warto, czasami takie proste narzędzia są po prostu dużo lepsze, dużo szybsze. Na przykład takim innym trikiem, którego często używam do klasyfikacji obrazów, i to w ogóle jest taki absurdalny trik.

Jeżeli mamy klasyfikację obrazków i mamy, nie wiem, kilka klas generalnie, pięć, dziesięć, to jak ja anotuję te dane, to otwieram sobie te wszystkie zdjęcia, wrzucam do jednego katalogu i robię sobie miniaturki tych obrazków. I teraz przelatuję i po prostu z Commandem zaznaczam obrazki jednej klasy, i jak zaznaczę sobie z 50 takich, to po prostu przenoszę do katalogu „klasa pierwsza” i zaczynam od początku tego katalogu.

Zaznaczam tę klasę, tę samą klasę, pewnie jakąś inną, generalnie tę klasę, którą widzę, że jest najpopularniejsza aktualnie, i po prostu klikam, zaznaczam z 50 przypadków i przenoszę do innego katalogu.

I skupiam się mocno na precision, a nie na recall, czyli nie zależy mi, żeby znaleźć wszystkie zdjęcia tej klasy, którą akurat mam w głowie, bo to nie ma znaczenia. Po prostu robię bardzo wiele takich przejść, bardzo dużo takich baczy i to działa niesamowicie szybko.

Artykuł Sztuczna inteligencja zmienia szukanie odpowiedzi pochodzi z serwisu Biznes Myśli.

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.

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

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




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

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

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

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

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

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

Doświadczenie Machine Learning & Data Science

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Świta AI w Chinach

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

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

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

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

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

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

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

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

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

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

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

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

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

Dobre praktyki w Machine Learning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Przyszłość Machine Learning

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

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

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

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

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

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

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

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

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

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


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

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

Z tego odcinka dowiesz się:

1. Transformery i Performer. Dowiesz się, czym są Transformery w Machine Learning i jak Performery optymalizują ich wydajność.
2. Poznasz naukowca z Google Brain Robotics, który pracuje nad zaawansowanymi algorytmami.
3. Praktyczne zastosowania. Zrozumiesz, jak Transformery rewolucjonizują różne dziedziny, od przetwarzania języka naturalnego po bioinformatykę i computer vision.
4. Otrzymasz informacje o autorskich kursach, które pomagają w nauce Transformerów i innych technik uczenia maszynowego.
5. Wyzwania i przyszłość. Poznasz wyzwania związane z Transformerami oraz przyszłość Machine Learning według eksperta.
6. Droga do doktoratu. Dowiesz się, jak decyzja o doktoracie na Columbia University wpłynęła na karierę Krzysztofa i jak przygotować się do podobnej ścieżki.
7. Filozofia nauki. Zainspirujesz się podejściem do nauki jako pasjonującego pojedynku z naturą, pełnego ciekawości i frajdy z odkrywania.

Zaczynamy!

Dzisiejszym gościem jest Krzysztof Choromański, który zrobił doktorat na Uniwersytecie w Kolumbii. Pracuje już od 7 lat w Google Brain Robotics. Jest autorem ciekawych publikacji naukowych. Będziemy dzisiaj rozmawiać o tzw. Performance. Czym jest Performance? To taka wydajna architektura Transformerów (Transformance). Czym są Transformery w Machine Learning? To rozwiązanie, o którym na pewno warto wiedzieć, jeśli chce się zajmować uczeniem maszynowym.  Tę architekturę koniecznie trzeba poznać.

Dlaczego tak mówię? W uczeniu maszynowym istnieje wiele różnych rozwiązań i są grube książki, które opisują je wszystkie,  ale z grubsza rzecz ujmując jest kilka rzeczy, które trzeba poznać. 

Tak się stało, że Transformery wkroczyły w ten ograniczony zasób algorytmów, które moim zdaniem koniecznie trzeba poznać. Owszem, Transformery mają swoje wady jeżeli chodzi o wydajność (potrzebują więcej pamięci lub wolniej się liczą). 

To, o czym dzisiaj właśnie Krzysztof będzie opowiadał, to jest rozwiązanie w konkretnych przypadkach, kiedy mamy troszkę więcej danych czyli to, co podajemy na wejściu (np. duże zdjęcia lub teksty). Jeżeli takie klasyczne Transformery nie działają, to wtedy mogą nam pomóc Performery. 

Ciekawe jest to, że to nadal są Transformery, tylko tak w sposób chirurgiczny zostały wycięte te kawałki, które są bardzo wolne i wstawiono tam bardziej efektywne elementy. W gruncie rzeczy nadal zostały Transformery, tylko zostały lepiej zoptymalizowane. 

Jeżeli chcesz lepiej poznać Transformery, to jest ku temu okazja i to dosyć unikalna. Zapraszam na mój autorski kurs, który został stworzony po to, aby wyjaśnić wszystkie techniki związane z przetwarzaniem języka naturalnego i pracy z tekstem. Sporo miejsca poświęcam tam także właśnie na Transformery, bo działają najlepiej.

Warto wspomnieć, że Transformery były wymyślone w kontekście NLP, ale później udało się to też adaptować do innych dziedzin, np. computer vision, gdzie też robiły rewolucję.

A więc jeśli chcesz poznać, czym są Transformery w praktyce,  to bardzo gorąco Cię zapraszam na mój autorski kurs. Jedynie na co zwrócę uwagę tutaj, to oczywiście mile widziana na tym kursie jest już przynajmniej podstawowa wiedza o tym, czym są sieci neuronowe itd.

Jeśli nie wiesz, czy Twoja wiedza jest wystarczająca, aby poradzić sobie na tym kursie, to zawsze możesz dołączyć i sprawdzić przez dwa tygodnie, a potem “przeskoczyć” do kursu “Praktyczne Uczenie Maszynowe”, który polecam każdemu na początek, podczas którego uczysz się niezbędnych podstaw i strukturyzujesz wiedzę. Potem można iść dalej.

Jeśli czujesz, że musisz przemyśleć sprawę i potrzebujesz wsparcia, to możesz uzyskać indywidualną konsultację telefoniczną. Po prostu napisz do mnie maila, że słuchasz Biznes Myśli i wiesz z odcinka, że jest taka możliwość. Wtedy umówimy się i  porozmawiasz –  ze mną albo z kimś z mojego zespołu. Najważniejsze jest to, żeby wyczuć, jakie masz potrzeby, aby w sposób indywidualny Ci poradzić, więc masz taką unikalną możliwość rozmowy.

Przechodzimy do rozmowy, która jest z jednej strony techniczna, naukowa, ale też zostały  poruszone tematy filozoficzne, za które jestem bardzo wdzięczny Krzysztofowi. To jest rzecz, która mnie osobiście też bardzo kręci. Zresztą cały czas mój umysł jest pobudzany do zadawania sobie różnych pytań koncepcyjnych – jak, dlaczego, czemu tak akurat, a nie inaczej? 

Zapraszam do rozmowy.

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

Dzień dobry. Nazywam się Krzysztof Choromański. Jestem naukowcem w Google Brain Robotics Team w Nowym Jorku, czyli team robotyczny. Poza pracą w Google,  wykładam też w Columbia University. Łączę się tutaj z pięknego New Jersey, w którym pracuję zdalnie w okresie pandemii.

Co ostatnio fajnego przeczytałeś i dlaczego akurat warto to przeczytać? 

W sumie nie ma takiej jednej specjalnej, natomiast jest jedna z pozycji, do której czasami wracam to „Sen o teorii ostatecznej” Stevena Weinberga. Tę książkę wiele lat temu kupił mi ojciec i wracam do niej. Bardzo fajne opowiadanie o dążeniach ludzi do stworzenia teorii wszystkiego. Pokazana jest bardzo fajna perspektywa jednego z czołowych fizyków amerykańskich, zdobywcy Nagrody Nobla. Odpowiedzialnego w dużej mierze za unifikację (przynajmniej częściową) oddziaływań, więc duży krok w kierunku stworzenia tej teorii wszystkiego. Często do tej książki wracam i różne fajne wątki są w niej poruszane, więc polecam wszystkim pasjonatom – bardzo fajna pozycja.

Bardzo dziękuję. Jesteś naukowcem. Już troszkę powiedziałeś, gdzie pracujesz, czym się zajmujesz, ale spróbujmy teraz to zgłębić i zrozumieć  więcej. Opowiedz o swoim doświadczeniu naukowym.

Pracuję w „robotycznym teamie”, natomiast całe doświadczenie naukowe jest szersze. Moja poważna przygoda naukowa zaczęła się w Columbia University, gdzie przyjechałem do Nowego Jorku studiować  teorię grafów, to była abstrakcyjna matematyka, niekoniecznie z zastosowaniami.

Więc nastąpiła fajna transformacja do uczenia maszynowego, czym się zajmuję teraz. Wszystko się bardzo fajnie zaczęło od teorii grafów. Potem w którymś momencie, już po zakończeniu doktoratu, wybrałem  maszynowe uczenie jako  kierunek, który wydawał się w 2013 r., kiedy kończyłem doktorat, bardzo perspektywiczny. Natomiast teraz rzeczywiście ta rewolucja jest już na dobre i ciężko sobie wyobrazić współczesną informatykę bez maszynowego uczenia. 

Więc to doświadczenie naukowe obejmuje zarówno czystą matematykę czy abstrakcyjną matematykę, czym zawsze byłem zafascynowany, w zasadzie od najmłodszych lat. Ale też bardzo praktyczne dziedziny takie  jak właśnie maszynowe uczenie czy robotyka, do których paradoksalnie ta abstrakcyjna matematyka jest bardzo przydatna. Jeżeli chce się właśnie pracować nad tymi algorytmami w sposób trochę bardziej systematyczny, kiedy nie zgadujesz co działa, ale starasz się rzeczywiście zrozumieć dlaczego działa, co polecałbym wielu osobom, które pracują właśnie nad maszynowym uczeniem. Podejście właśnie może takie bardzo rygorystyczne, matematyczne. Więc w skrócie tak to moje doświadczenie naukowe wygląda

Wspomniałeś, że zajmowałeś się matematyką, w szczególności grafami, ale później pojawił się ML. Ciekawy jestem, jakie były w głowie pytania, dylematy, być może były jakieś inne opcje do rozwoju? Jak te decyzje wyglądały.

To była trudna decyzja, bo po doktoracie miałem bardzo dobry czas. Był to jeden z najpiękniejszych okresów w moich życiu. Natomiast pytanie było też: co dalej chcę robić? Oczywiście kwestia dalszej pracy w teorii grafów to było coś co mnie zawsze ekscytowało, ale zdawałem sobie też sprawę, patrząc na to co moi znajomi robili, że jest ileś tam dziedzin, które potencjalnie mogą okazać się zdecydowanie ważniejsze, jeśli chodzi właśnie o rozwój technologii i wpływ na to jak żyjemy. Abstrakcyjna teoria grafów nie wpływa na to w taki sposób jak chociażby maszynowe uczenie dziś. 

Więc powiedziałbym, że wybrałem właśnie maszynowe uczenie, zamiast np. „postdoca”, na którym zajmowałbym się teorią grafów, ze względu na to, że po pierwsze było w miarę oczywiste, że maszynowe uczenie zdominuje wiele dziedzin życia, a po drugie (to było też bardzo istotne) zrozumiałem bardzo szybko, że ta elegancka matematyka, o której właśnie Weinberg opowiada w swojej książce, o której wspomniałem na początku i która mnie zawsze pasjonowała od najmłodszych lat, jest bardzo przydatna także w maszynowym uczeniu.

Ale jest więcej metod, które mogą być wykorzystane. Ta teoria grafów, to nad czym pracowałem to było bardziej takie kombinatoryczne podejście, natomiast w maszynowym uczeniu może nie stosuje się teorii grafów w takim sensie, w jakim wykorzystywałem podczas doktoratu, ale stosuje się mnóstwo pięknych matematycznych rzeczy. Jest rachunek prawdopodobieństwa, jest też teoria grafów w trochę innym sensie niż w tym, którym ja się zajmowałem podczas doktoratu.

Jest mnóstwo innych ważnych dziedzin, którymi się zawsze interesowałem jeszcze przed rozpoczęciem doktoratu, więc stwierdziłem, że po prostu także z czysto matematycznego punktu widzenia to będzie ekscytujące. Natomiast tym dodatkowym motywatorem było to, że będę mógł tę teorię sprawdzać w praktyce, nie ma nic piękniejszego niż zobaczyć, że robot działa. 

W tamtym czasie, kiedy wybierałem Google, nie wiedziałem jeszcze o robotycznym team’ie. Natomiast już miałem tę intuicję, że maszynowe uczenie to będzie duża rzecz i tak się stało w ciągu następnych kilku lat.

Google Brain Robotics

Czyli dobra decyzja. Już pracujesz od ponad 7 lat w Google. Obecnie w zespole Google Brain Robotics. Fajnie byłoby, żebyś opowiedział troszkę więcej, czym zajmuje się zespół, jaki jest jego cel, jakie problemy rozwiązujecie i jakie macie osiągnięcia na swoim koncie.

Brain Robotics to jest naturalna konsekwencja tej rewolucji maszynowego uczenia, która dzieje się na naszych oczach, ponieważ następnym konkretnym, naturalnym krokiem po tym wszystkim, co udało się zrobić w maszynowym uczeniu (jesteśmy cały czas, mimo wszystko daleko od stworzenia sztucznej inteligencji) jest zobaczenie, czy roboty, do których stosowało się bardziej takie standardowe metody, mogą korzystać właśnie z tej rewolucji. Czy roboty mogą korzystać z sieci konwolucyjnych, żeby widzieć w jaki sposób zastąpić taką standardową control theory (która była wykorzystywana w robotyce w czasie przed maszynowym uczeniem) nowymi technikami, które okazały się niezwykle efektywne w klasycznym Data Science. 

To jest taka myśl przewodnia tego teamu. Jesteśmy bardzo researchowo zorganizowani. Staramy się bardzo dużo publikować. Dużo rzeczy tak naprawdę dzielić ze środowiskiem naukowym, ponieważ jest to researchowe podejście, więc staramy się właśnie kontaktować z tymi ludźmi, którzy są właśnie na zewnątrz, a też pracują właśnie w robotyce. Oczywiście konferencje są bardzo dobrym miejscem na coś takiego. 

Myśl przewodnia to jest te wszystkie dobre rzeczy, których się nauczyliśmy, te techniki, sieci neuronowe, które okazały się tak istotne w maszynowym uczeniu, jakoś przekuć ten sukces na sukces w robotyce. Więc to jest najważniejszy temat ogólny, natomiast oprócz tego to co wydaje się bardzo istotną rzeczą to to, że mamy fizyczne roboty, więc tych algorytmów, które produkujemy nie musimy testować tylko i wyłącznie w symulatorach, ale możemy na prawdziwych robotach. Oczywiście każdy kto się zajmuje robotyką wie, że tak naprawdę symulator, a prawdziwe urządzenie to są dwie różne rzeczy.

Można mieć algorytm, który dobrze działa na symulatorze, ale przenieść potem to na prawdziwego robota to z reguły jest to trudna rzecz i wymaga dużo wysiłku. Więc mamy możliwości robić to, mamy naszą flotę robotów i dlatego to połączenie podejścia teoretycznego do rozwiązywania trudnych, algorytmicznych problemów jest bardzo praktyczne. Mamy te fizyczne roboty, to jest właśnie taki dobry balans, który mamy w teamie. Tak to wygląda właśnie z lotu ptaka nasza działalność. 

Powiedz jeszcze tak od kuchni, jak wygląda życie naukowca w takim zespole? Jak wygląda przeciętny dzień, jak się definiuje problem, ile na przykład trwa taki sprint?

Różnie to wygląda. Tych projektów jest dużo, a problemów naukowych, nad którymi pracujemy jest sporo, ponieważ team też jest duży. To są ludzie i na Wschodnim Wybrzeżu i na Zachodnim Wybrzeżu. Są też ludzie spoza robotycznego teamu, którzy współpracują z nami w Google. Też właśnie środowisko naukowe poza Google z Uniwersytetów. 

Generalnie dobre fajne projekty trwają przynajmniej kilka miesięcy, ale taki projekt naukowy może trwać bardzo długo. Największym projektem naukowym, w którym siedzimy od powstania teamu to jest właśnie maszynowe uczenie dla robotyki. Natomiast mniejsze projekty to zależy bardzo dużo od tego kto siedzi akurat nad projektem, jak duży jest ten team, który pracuje nad tym konkretnym projektem, ale z reguły to jest przynajmniej ileś miesięcy, ponieważ to jest kwestia wymyślenia algorytmu, z reguły przetestowania na jakimś symulatorze na początku, ale największą frajdą jest jak da się to pokazać na prawdziwym robocie.

To też może trwać. Czasami właśnie największą sztuką jest przenieść te pomysły na prawdziwe urządzenie. Więc projekty mogą trwać od kilku miesięcy do kilku lat, więc duża różnorodność, bo dużo tych problemów też jest. Są problemy związane z manipulation, z robotami, które nawigują w terenie, które się przemieszczają i tak naprawdę różne techniki są wykorzystywane, żeby do tych problemów podejść i to są z reguły projekty, które trwają dłuższy czas. 

Attention Mechanism

Jasne, rozumiem. Teraz porozmawiajmy właśnie o jednej takiej publikacji, której jesteś jednym z głównych autorów: Rethinking Attention with Performance. Ale zanim zaczniemy o tym mówić, zróbmy kilka kroków wstecz, aby każdy kto nas słucha trochę lepiej zrozumiał kontekst. Spróbujmy najpierw przypomnieć czym jest tzw. Attention Mechanism? Dlaczego on akurat jest taki pomocny w uczeniu maszynowym?

Attention Mechanism to jest technika, która jest znana w maszynowym uczeniu od wielu wielu lat. Tak naprawdę, mimo, że Transformersy stały się architekturami, które prawdopodobnie najlepiej by promowały Attention w środowisku ludzi zajmujących się maszynowym uczeniem. Idea jest prosta – to jest próba bezpośredniego modelowania interakcji, związków pomiędzy elementami w jakimś potencjalnie bardzo długim ciągu. Ten ciąg to może właśnie być ciąg słów, tak jak to jest w NLP.

To może być sekwencja pikseli czy patchów. To mogą być frames tak jak to jest w wideo. To jest próba modelowania związków pomiędzy właśnie tymi elementami za pomocą czegoś co się nazywa softmax kernels, który jest po prostu jakąś tam miarą podobieństwa pomiędzy obiektami. Ta miara podobieństwa jest w większości architektur modelowana i uczona za pomocą optymalizacyjnych algorytmów. 

Czyli idea polega na tym, żeby te związki modelować bezpośrednio. Pomysł jest taki, że po pierwsze mnóstwo problemów w maszynowym uczeniu ma taki charakter sekwencyjny czyli można te dane rozpatrywać jako ciągi tych elementów, właśnie z tymi związkami, które pełnią kluczową rolę w zrozumieniu semantyki tych danych. Czyli np. jeżeli ma się zdanie to oczywiście związki między słowami w zdaniu czy w paragrafie czy dłuższym tekście, rozdziale, książce – modelowanie tych związków wydaje się być kluczowe do zrozumienia znaczenia tekstu. To modelowanie można zrobić bezpośrednio za pomocą atencji, więc to jest główna myśl przewodnia to co stoi za tym mechanizmem. 

Jak działają Transformery?

Kolejnym takim tematem są Transformery, które powstały nie tak dawno – w 2018 r. One faktycznie zaczęły robić w pewnym sensie rewolucję, rozpoczęło się od NLP, ale do tego jeszcze dojdziemy. Ale najpierw takie pytanie: jak sobie tłumaczysz bardziej na poziomie intuicji, nie tyle jak to działa, ale dlaczego to działa? Było wiele różnych prób, kombinacji i nie wszystko wystrzeliło, to akurat tak. Dlaczego?

Kluczowym mechanizmem jest mechanizm atencji, o którym właśnie mówiliśmy. Tutaj tak naprawdę intuicją, którą ja mam jest taka, że w przeciwieństwie do wielu innych architektur, które operowały na sekwencjach elementów, na danych, które można było naturalnie interpretować jako uporządkowane ciągi elementów, w przeciwieństwie do wielu innych architektur (np. LSPM) te związki pomiędzy tymi poszczególnymi częściami składowymi – czy to są właśnie te słowa w tekście czy piksele w obrazie – są modelowane bezpośrednio.

Wcześniej przed atencją, Transformersami próbowano w jakiś sposób ominąć to, także dlatego, że jest to dosyć kosztowne, ale także dlatego, że nie byliśmy przygotowani na algorytmy, które wykorzystują atencję. Teraz jest inaczej. Dlatego wcześniejsze podejście polegało na tym, że próbowało się znaczenie tego ciągu skompresować do jakiegoś ukrytego stanu, który miał sumaryzować cały tekst. To jest to co właśnie np. robią LSPM.

Problem polega na tym, że ciężko jest skompresować (nawet jeżeli uczysz się tej kompresji, tak jak to jest w algorytmach maszynowego uczenia) cały tekst czy obraz w ukrytym stanie, który jest w miarę kompaktowy. 

W podejściu atencyjnym, czy właśnie w Transformersach, które atencję wykorzystują pomysł jest zupełnie inny. Zamiast tego pojedynczego, ukrytego stanu, którego ciężko się nauczyć, trzyma się informacje, ukryte stany tych wszystkich elementów części składowych. Na pierwszy rzut oka to się może wydawać bardzo nieefektywne, ponieważ tych części składowych jest dużo, ale okazuje się właśnie, że z rozwojem technologii można było to zrobić bardzo efektywnie, a to co się otrzymuje to jest to ekspresywność tej całej architektury.

To, że możemy znaczenie tych poszczególnych elementów bezpośrednio składować i modelować relacje między nimi bezpośrednio powoduje, że jesteśmy w stanie zrozumieć lepiej semantykę tych danych, więc to jest intuicja. Wielu ludzi pracujących nad atencją i Transformerami ma, natomiast oczywiście intuicja to jest jedna rzecz, natomiast połączenie tego w całość (ponieważ Transformersy to nie jest tylko atencja, ale jest mnóstwo różnych bloków, które razem współgrają ze sobą) jest rzeczą nietrywialną i tak jak generalnie w historii maszynowego uczenia bywało, wiele tych rzeczy to jest jakaś intuicja, ale też dużo różnych prób, podejścia i któraś architektura po prostu nagle zaczyna działać. Ale właśnie intuicja wiąże się z bezpośrednim modelowaniem relacji pomiędzy elementami składowymi. 

Gdzie można wykorzystać Transformery?

Zatem jeszcze jedno pytanie intuicyjne, koncepcyjne. Tak jak już było wspomniane, Transformery powstały w takiej dziedzinie NLP m.in. BERT to była taka bardziej kluczowa architektura. Później okazało się, że da się to adaptować. Najpierw poszło w kierunku computer vision albo może nawet muzyka w tej dziedzinie podziałać. To jest ciekawe. Jak interpretujesz ten fakt? Czy to jest jakieś takie prawo natury, w sensie, że udało się stworzyć pewien mechanizm/architekturę, która łapie pewne zależności w sposób bardziej ogólny? Dlaczego to działa akurat w różnych dziedzinach, które nie były na początek przemyślane, że tam powinny działać, ale akurat też wystrzeliły?

Wydaje mi się, że to jest po prostu jeszcze jeden z wielu przykładów na skuteczność matematyki w opisie otaczającego nas świata. Jeszcze jeden przykład, że metoda, która na początku została wymyślona być może właśnie z zamysłem o konkretnym zastosowaniu okazuje się zdecydowanie bardziej uniwersalna. Tak naprawdę, jak się popatrzy na te inne aplikacje to struktura matematyczna innych problemów, często jest bardzo podobna do tej struktury problemu tego NLP modelowania języka na przykład. Jeżeli się patrzy na zastosowanie w images to już wspomniałem o tym, że te słowa można zastąpić pikselami albo grupami pikseli. Relacje między nimi wydaje się, że powinny mieć kluczowe znaczenie dla zrozumienia semantyki obrazu. Tak jak relacje pomiędzy słowami w zdaniu mają kluczowe znaczenie dla zrozumienia sensu zdania. 

Dlatego te techniki fajnie się transferuje z jednej dziedziny do drugiej i w tym bym upatrywał sukces. Oczywiście to nie jest tak, że Transformer, który się zastosuje w NLP można czasami jeden do jednego od razu zmapować do architektury, która będzie od razu działać w innej dziedzinie. Te rzeczy się adaptuje jakoś. Jakieś tam dodatkowe techniki, które się stosuje, biorąc pod uwagę konkretne zastosowanie, ale rzeczywiście główne algorytmiczne koncepcje pozostają bardzo podobne. W przypadku Transformersów to jest jest właśnie ta atencja, bezpośrednie modelowanie związków pomiędzy tymi częściami składowymi. 

Takim bardzo fajnym przykładem tutaj jest bioinformatyka. To jest przykład, że wydawałoby się, że może ma niewiele wspólnego z takimi klasycznymi zastosowaniami Transformersów, a okazuje się właśnie, że można zastąpić te słowa w zdaniu poprzez aminokwasy w cząstce białka i relacje pomiędzy tymi aminokwasami można modelować w zasadzie bardzo podobnym algorytmem do relacji między słowami w zdaniu. 

To jest jeszcze jeden przykład na uniwersalność matematyki i tego właśnie co Weinberg w swojej książce mówi, że w jakiś sposób tak zmierzamy do tej unifikacji, jest ileś tych idei, które pozwalają upraszczać opis świata. Tutaj taka mała unifikacja też następuje w maszynowym uczeniu, co tylko odzwierciedla jak zbudowany jest świat. Dzięki temu potrafimy tak dużo rzeczy zrobić w nauce, ponieważ byłoby straszne gdybyśmy musieli dla każdego nowego problemu wymyślać nowy algorytm, nową metodę od samego początku. Bardzo nieefektywne, a jakimś cudem okazuje się, że te idee się bardzo fajnie transferuje. To stanowi też o sukcesie nauki. Więc tak patrzę na uniwersalność Transformersów w maszynowym uczeniu. Tak długo jak masz dane o strukturze sekwencyjnej, te architektury się bardzo przydają. 

Transformery same w sobie, jak już dzisiaj powiedziałem, że to była taka rewolucja jeżeli chodzi o NLP, ale też w computer vision. Natomiast wejdźmy teraz bardziej w krytykę, bo każde rozwiązanie ma swoje wady. Jakie problemy mają Transformery i dlaczego powstał Performer?

Powiedziałem, że to co stanowi o sukcesie Transformersów w jakimś sensie jest też najsłabszą stroną. Transformersy zrywają z tradycją opisu właśnie tego złożonego ciągu zależności poprzez bardzo skompresowany stan. Ale oczywiście ceną, którą płaci się za to, że te ukryte stany trzyma się dla tych wszystkich elementów ciągu jest kwestia efektywności. Jeżeli te ciągi są bardzo długie – przynajmniej tysiące elementów albo nawet miliony – to oczywiście modelowanie wszystkich zależności jest po prostu niemożliwe. Jeśli chodzi właśnie o compute time i space.

Po prostu fizycznie nie jest możliwe nawet przy dużych zasobach, na których można trenować te architektury, one mają z reguły przynajmniej miliony i biliony parametrów. Przy tak dużych zasobach po prostu bijemy głową o ścianę, jeżeli chcemy modelować wszystkie zależności w bardzo długich ciągach. 

A wydaje się, że takie długie ciągi naturalnie powstają, jeżeli mówimy o zastosowaniach w maszynowym uczeniu. Jednym przykładem oczywiście jest Vision, piksele w obrazie, w high resolution image to tych pikseli będzie w milionach i modelowanie zależności pomiędzy każdą parą pikseli jest po prostu niemożliwe.

Innym przykładem będzie bioinformatyka. Wspomniałem o białkach. Białka to z reguły kilkaset aminokwasów. Ciąg o długości kilkuset elementów nie jest problemem dla Transformersów, ale przejdźmy teraz od białek do genomiki. Modelujemy transkrypcję genów czyli to mapowanie genów do białek, które powstają. Genom jest bardzo długi, miliardy elementów – nie jest możliwe modelowanie tych wszystkich zależności bezpośrednio za pomocą Transformersów i to jest problem.

No i mamy problem skalowalności dotyczący zdecydowanie dłuższych ciągów. Także uczynienie Transformersów architekturami, z których można korzystać nawet jeżeli nie ma się dużych zasobów obliczeniowych to jest myśl założycielska Performersów.

Przypominam sobie, jak jakiś czas temu uczyłem się – duże O i takie tam różne historie. To było na początek dla mnie bardziej nudne, bo w sumie nie było wiadomo po co to wszystko. A później jak już zaczynasz pracować np. z danymi, tzw. big data to tutaj masz taki wybór, że mniej optymalne rozwiązanie potrafi się liczyć godzinami albo nawet dniami lub tygodniami, a bardziej zoptymalizowane minuty albo nawet sekundy, więc tutaj od razu widać taką wartość dodaną. Ale też jest drugi wymiar, jak pamięć. 

Tutaj fajnie, żeby to jeszcze bardziej wybrzmiało, w szczególności jak mówimy o kartach graficznych. Co prawda Nvidia trochę te rzeczy już naprawia, bo wcześniej to była jeszcze większa bolączka. Mam na myśli to, że karty GPU zwykle mają dość mało tej pamięci dostępnej i ten wyjątek, jeden z najsłynniejszych OOM (Out Of Memory) jest mega męczący.

Tak, zgadza się.

To chciałem, żeby też wybrzmiało, bo w sumie jeżeli chodzi o ten Performance liczenia, że trochę dłużej się liczy to jest problem, ale powiedzmy da się poczekać czasem, a jeżeli mówimy o pamięci to po prostu jest bloker. Jak brakuje pamięci to wszystko się zatrzymuje i nie działa. Więc dlatego to jest aż tak ważne, żeby to uruchomić.

Tak, Out Of Memory to jest koszmar ludzi, którzy próbują zastosować tego typu architektury dla bardzo skomplikowanych problemów, gdzie te ciągi są długie. Taki konkretny przykład z robotyki – atencję, która jest kluczowym elementem Transformersów, próbuje się wykorzystać do kompresji obrazów dla robotów. Czyli mamy robota, który dostaje jako input vision obraz np. z kamery i próbuje ten obraz skompresować, żeby zrozumieć tak naprawdę jakie części tego obrazu są kluczowe dla podejmowania decyzji w określonej chwili.

Można próbować właśnie tę kompresję robić za pomocą atencji. Jest wiele bardzo fajnych prac, które to pokazują. Natomiast tak naprawdę nie jest możliwe modelowanie tych pixel to pixel atencji za pomocą standardowego mechanizmu atencji. Można robić fajne rzeczy z obrazami powiedzmy 100×100, natomiast jeżeli mamy coś rzędu 1024×1024 i chcesz modelować pixel to pixel attention to jest to w zasadzie nie do zrobienia w standardowy sposób.

Poza tym, jeszcze dodatkowy problem związany z pamięcią i z czasem wykonania, nawet jeżeli zakładasz, że w jakiś sposób, jakimś cudem możesz tą skomplikowaną atencję policzyć. Czekasz powiedzmy tydzień czy miesiąc i to się liczy, korzystając z naprawdę bardzo dużych zasobów obliczeniowych, to potem to musisz często gdzieś to wstawić. W robotycznych zastosowaniach wstawiany na robota. To jest też problem, tzn. nawet przy dużych zasobach, koniec końców down screen application, gdzie to ma być zastosowane.

Wstawienie architektury, która ma miliony, biliony parametrów, która zjada kwadratową pamięć i potrzebuje czasu, żeby procesować te dane jest szczególnym problemem w robotyce, gdzie ten inference time musi być bardzo szybki, żeby te decyzje podejmować natychmiast. Oczywiście zasoby też pamięciowe takiego robota są małe. Nie da się olbrzymiej architektury przenieść 1:1 na robota. 

Transformery w Machine Learning

ograniczenia i optymalizacje

Tak jak powiedzieliśmy Performersy przede wszystkim skupiają się na wydajności Transformerów, więc stąd jest też ta nazwa. Natomiast to nie były pierwsze próby, kiedy ludzie próbowali jakoś usprawnić Transformery. Były różne podejścia, ale z różnych powodów to nie wystrzeliło. Jakie miały wady te poprzednie próby naprawy Transformerów i dlaczego akurat Performersom to się udało?

Dużo jest podejść do stworzenia nie tylko efektownych, ale też efektywnych architektur transformerowych.

Rzeczywiście jest cała klasa algorytmów polegających na sparsyfikacji atencji. W jakimś sensie jest to takie najbardziej intuicyjne podejście, tzn. jeżeli nie potrafi modelować wszystkich zależności pomiędzy częściami składowymi to modeluję tylko niektóre z nich.

To, które zależności będą modelowane jest albo kwestią, której algorytm się uczy, albo zakodowaną np. takim najbardziej trywialnym podejściem byłoby po prostu powiedzenie, że jeżeli mamy sekwencję elementów to elementy, które są w jakimś sensie koło siebie w tej sekwencji to relacje między nimi powinny być modelowane. Natomiast elementy, które nie są koło siebie – niekoniecznie.

Czyli np. jeżeli mamy zdanie to słowa, które występują czy jakiś paragraf, tekst, pewnie jakiś związek mają. Słowa, które występują daleko od siebie, mogą mieć lub nie mieć, ale jeżeli nie wiemy jak modelować efektywnie to tego nie róbmy. 

Tego typu podejście sprawdza się w wielu zastosowaniach, natomiast ma oczywiście kluczowe wady, tzn. jest wiele problemów, gdzie te relacje pomiędzy odległymi elementami w ciągu są bardzo istotne. Konkretnym przykładem jest choćby właśnie modelowanie białek. Mamy sekwencję aminokwasów, jeżeli o tym białku się myśli jak o sekwencji to rzeczywiście mamy fajny input dla Transformersa.

Wydaje się, że aminokwasy, które są koło siebie, relacje między nimi są najistotniejsze. Natomiast jeżeli się uzmysłowi sobie, że takie białko może się składać, ma 3d strukturę i aminokwasy, które w tej zwektoryzowanej, sekwencyjnej wersji są daleko od siebie, mogą znaleźć się bardzo blisko od siebie, bo białko się zwija to nagle się okazuje, że właśnie te parę aminokwasów, które są w tej zwiniętej strukturze blisko siebie, a były daleko w tej zwektoryzowanej, odgrywają olbrzymią rolę w zdefiniowaniu kształtu takiego białka. A kształt tego białka, jak wiemy ucząc się od biologów, ma kluczowe znaczenie dla zrozumienia jego funkcjonalności. 

Więc jest mnóstwo problemów. Tutaj podałem przykład z bioinformatyki, gdzie modelowanie tych związków między odległymi elementami jest bardzo istotne. Właśnie jest to trudne do osiągnięcia z tymi metodami, gdzie się sparsyfikuje. Oczywiście można próbować nauczyć się, które z tych odległych relacji modelować, natomiast w praktyce jest to trudne.

Poza tym, dodatkowym problemem jest, że taka architektura, której uczy się w ten sposób, nie może zostać wykorzystana do usprawnienia czy wzmocnienia architektury, którą trenowało się zwykłym algorytmem. Czyli np. jeżeli team X skorzysta z jakiejś architektury i modeluje ten Transformers, trenuje go przez tydzień to nie będzie w stanie zrobić dodatkowego treningu z tą nową Spars Architecture, ponieważ te architektury nie są kompatybilne. To jest właśnie duży problem tego podejścia korzystającego ze sparsyfikacji. 

Oczywiście jest wiele sytuacji, w których ciągi są na tyle krótkie, że to nie jest problem i nawet nie trzeba sparsyfikować. Ale kiedy okazuje się, że trzeba sparsyfikować to zaczynają się schody. Poza tym te wszystkie metody sparsyfikacji, one nie aproksymują tak naprawdę atencji dokładnie – tej standardowej atencji. Raczej zamieniają tę atencję w trochę prostszą atencję, gdzie mnóstwo elementów jest wyzerowanych, mnóstwo relacji się nie modeluje. Oczywiście ta prostsza atencja jest słabsza też w tym sensie, że jakość takiego Transformersa różni się od Transforemersa, który by się trenował w sposób standardowy, ale nie można tak, ze względu computational costs. 

To są tego typu problemy związane z sparsyfikacją. 

Jak czytałem publikację, o której teraz właśnie rozmawiamy to z jednej strony było czuć, że była przygotowana przez naukowców – tam jest dużo różnych matematycznych wzorów. Ale z drugiej strony było bardzo czuć, że to podejście jest takie praktyczne, czyli sam problem, który jest rozwiązywany jest praktyczny i też takie zdania, które można było złapać pokazują sposób myślenia.

Na przykład tam było zaznaczone, że Performer jest w 100% kompatybilny ze zwykłym Transformerem albo np. była taka twarda gwarancja matematyczna, że to rozwiązanie, to prawdopodobieństwo, będzie stabilne. Więc spróbujmy wyjaśnić tak w praktyce, co to oznacza  i dlaczego akurat to było wyróżnione.

Performersy opierają się na bardzo prostej idei. To jest idea dekompozycji tej atencji na części składowe, które są prostsze niż ta standardowa atencja. Czyli jest to próba dekompozycji atencji w taki sposób, że te części składowe połączone znowu razem w jakiś tam aproksymacyjny sposób, dobrze przybliżają tę prawdziwą atencję, ale umożliwiają właśnie zdecydowanie bardziej efektywne policzenie tej atencji.

Prostota tego pomysłu polega na tym, że (do tego odnosimy się jak mówimy o kompatybilności) tak naprawdę jedyna rzecz, którą się zmienia w Performersach to sposób liczenia atencji. Wszystkie pozostałe elementy Transformersów są takie jak w standardowych architekturach albo jakiś tam zmodyfikowanych architekturach. Jednym słowem, można wziąć sobie swój ulubiony Transformer (a teraz tych różnych wersji Transformersów na rynku jest mnóstwo) i w zasadzie jedyną rzecz, którą się robi to się podmienia właśnie sposób liczenia tej atencji na ten moduł, który jest wykorzystywany w Performersach.

Kompatybilność polega właśnie na tym, że bardzo łatwo można to podmienić, a także na tym, że sposób modelowania relacji pomiędzy elementami, pozostaje dokładnie taki sam jak w oryginalnej architekturze. To znaczy w szczególności modelowane są wszystkie relacje, natomiast nie w sposób bezpośredni, tzn. nie materializuje się tego bezpośrednio, nie trzyma się tych wszystkich relacji bezpośrednio w pamięci, natomiast one są tak naprawdę wszystkie modelowane w sposób bardziej kompaktowy za pomocą tej dekompozycji, o której wspomniałem.

Dzięki temu można te architektury czy ten algorytm używać do kontynuowania trenowania architektur, które trenowało się wcześniej innym algorytmem. Po prostu podmieniając tylko sposób, w jaki tę atencję się liczy. Czyli tak naprawdę prostota, fakt, że nie trzeba też wszystkiego budować od początku to wydaje mi się jest kluczowy element. Jest wiele architektur na rynku, ale wiele z tych innych podejść jest dosyć skomplikowanych z praktycznego punktu widzenia.

Natomiast tutaj rzeczywiście mamy bardzo jasne podejście do tego, w jaki sposób modyfikować te architektury – taki bardzo chirurgiczny sposób. Nie zmienia się wszystkiego, zmienia się tylko jeden konkretny element, który pełni kluczową rolę w Transformersach, jeśli chodzi o otrzymanie dobrej jakości modeli.

To jest właśnie ta kompatybilność i my to trenowaliśmy po prostu na wielu różnych problemów, także właśnie z bioinformatyki. Dla nas było istotne, żeby właśnie wymyślić coś, co będzie łatwe do użycia. Będziesz mógł wziąć swoją architekturę, dokonać tej małej modyfikacji i będziesz mieć performance variance tej swojej architektury, z tymi wszystkimi zaletami, które płyną z liniowej zamiast kwadratowej złożoności czasowej i pamięciowej.

A propos gwarancji też może coś dodasz?

Mamy dosyć fajną analizę teoretyczną tego algorytmu, więc okazuje się, że ten nasz sposób przybliżania… chociaż ta atencja, którą liczymy nie jest to dokładnie ta atencja w regularnym Transformersie, ale jej aproksymacja, natomiast ona jest dosyć dokładna i w artykule podajemy liczby, kwantyfikujemy to dosyć dokładnie, jak dokładna ona jest.

Też jest to co nazywamy unbiased czyli tak naprawdę przybliżanie atencji jest algorytmem proabilistycznym, natomiast wartość oczekiwana tej atencji, którą wylicza się tym algorytmem jest dokładnie tym, co chcemy, czyli tą regularną atencją. A błąd czyli wariancja, może być dosyć dokładnie policzona. To jest duża różnica w porównaniu z innym podejściem. To jest tak naprawdę zastąpienie standardowego mechanizmu przez mechanizm aproksymacyjny z bardzo mocnymi gwarancjami teoretycznymi. Tam jest wiele różnych, dodatkowych technik, które pełnią bardzo ważną rolę w osiągnięciu algorytmu, który właśnie dosyć dokładnie aproksymuje tę regularną atencję. W szczególności algorytmy z dziedziny, którą nazwałabym Quasi-Monte Carlo. 

Techniki, które wykorzystywaliśmy wcześniej, w wielu innych problemach, ale matematyka jest uniwersalna i okazało się po raz kolejny, że pełnią istotną rolę także tutaj. Tak więc powiedziałbym, może nie skromnie trochę, że jeśli chodzi o gwarancje teoretyczne tej atencji, którą proponują Performersy to pod względem teoretycznym to jest moim zdaniem jedna z niewielu prac, gdzie jest rzeczywiście wysiłek, żeby zrozumieć też dlaczego ten mechanizm działa, a nie tylko pokazać, że działa. Sądzę, że wiemy dosyć dokładnie, dlaczego działa, częściowo wyjaśniając to ze względu też na limit stron w artykule.

Tutaj dodam oczywiście, że te wszystkie szczegóły matematyczne to jak najbardziej polecam przeczytać publikację, bo tam faktycznie fajnie można spędzić czas czytając różne szczególiki. Ale z drugiej strony jednak chciałbym trochę dopytać o kilka rzeczy, które zresztą wprost chyba nie są tak jednoznacznie powiedziane, bo to jest trochę o czymś innym. Czyli to co już dotychczas było powiedziane to było to, że Transformery same w sobie podbijają rynek, to po prostu działa, ale są tzw. pewne bottlenecki , które są mało wydajne czyli ten mechanizm atencji.

Teraz to co udało się tu stworzyć w sposób chirurgiczny – wymienić ten komponent, który jest za wolny na ten, który nie jest za wolny. To jest taka pełna aproksymacja, ale też jak powiedziałeś to przed chwilą, z punktu widzenia teoretycznego da się udowodnić, że to działa stabilnie, dokładnie i na tym też polega właśnie wartość dodana, jeżeli chodzi o tą pracę naukową.

Natomiast jeżeli chodzi o parametry. Chodzi o znalezienie tzw. kernela, który próbuje to aproksymować. Tam są różne parametry, np. takie h(x), który domyślnie był tam jako 1. Też liczba funkcji f i w albo omega. Tak na poziomie intuicji, najważniejsze wnioski, które udało się wyciągnąć właśnie eksperymentując przy tej publikacji i jak te parametry dobierać?

Aproksymując tę atencję. Tak jak wspomniałem wcześniej, modelowanie atencji to jest po prostu bezpośrednie modelowanie zależności pomiędzy elementami. Do modelowania zależności pomiędzy elementami musimy mieć jakąś definicję podobieństwa między elementami. Jak dwa elementy są związane ze sobą to chcemy mieć jakąś miarę podobieństw. To podobieństwo w maszynowym uczeniu nazywa się kernel.

To jest po prostu fajne słowo dla funkcji, która liczy podobieństwo między elementami. Ale oczywiście w maszynowym uczeniu, tę funkcję podobieństwa się też trenuje. Trenuje się pewne parametry, natomiast jest pewna struktura, której się nie trenuje.  Ta struktura to jest jakby ten szkielet tej funkcji podobieństwa, szkielet kernela. W tradycyjnych Transformersach ten szkielet jest opisywany przez coś co się nazywa softmax kernel. Nie wchodząc w szczegóły jest to taki bardzo fajny szkielet, na którym można budować właśnie te funkcje podobieństwa, natomiast ten szkielet jest niesłychanie efektywny w praktyce. Mówisz o tych różnych funkcjach h itd. – bawiąc się tymi różnymi funkcjami można te szkielety zmieniać.

Czy chcemy te szkielety zmieniać czy nie to jest pytanie. Ten softmax kernel szkielet jest bardzo dobry. On w praktyce działa niesłychanie dobrze i dlatego jednym z dużych wyzwań, które mieliśmy jak pracowaliśmy nad Performersami to mieć pewność, że co prawda możemy udostępnić inne szkielety i cały czas mieć tę liniową atencję zamiast kwadratowej, ale że jesteśmy w stanie korzystać teraz też z tego szkieletu softmax kernel, który okazuje się niezwykle efektywny do modelowania zależności. 

Tak naprawdę, jednym z dużych teoretycznych moim zdaniem fajnych pomysłów w tej pracy to jest efektywny sposób modelowania tego softmax kernel szkieletu. To jest związane właśnie z konkretnym wyborem tego h, tych parametrów o których mówisz. Jak się wczyta w pracę to tam jest powiedziane, że możemy modelować ten softmax kernel szkielet za pomocą losowych Random features, natomiast jest nowy mechanizm, z którego korzystamy tam.

Standardowy mechanizm, który tak naprawdę też zaproponowaliśmy w pracy, ale okazało się, że nie działał dobrze to jest mechanizm, który korzysta z trygonometrycznych funkcji do modelowania tego szkieletu. On w praktyce nie jest stabilny, tzn. właśnie okazuje się, że jak się próbuje trenować Transformersy tym mechanizm, on się cechuje za dużym błędem, za dużą wariancją. Ten nowy mechanizm opiera się na exponential functions do modelowanie właśnie tego szkieletu to są właśnie te parametry, które się wybiera i jest zdecydowanie bardziej stabilny. Tak naprawdę jest pierwszym efektywnym mechanizmem modelowania tego softmax szkieletu w taki sposób, że cała architektura, cały mechanizm atencji jest ciągle liniowy.

Tak jak to jest w innych wersjach Performersa, gdzie korzystamy z prostszych szkieletów, gdzie liniowość wychodzi automatycznie z definicji szkieletu. 
Więc tak naprawdę, jeśli chodzi o wybór parametrów to wybranie szkieletu związanego z softmax kernel jest zawsze bardzo dobrym pomysłem. Mamy nowy mechanizm właśnie, który pozwala korzystać z tego szkieletu. Natomiast bardzo często to, co działa w praktyce, jest prostsze i to jest tzw. Performers Value.

W praktyce to jest mechanizm nie losowy, tam nie ma Random Features. W praktyce jest bardzo szybki do policzenia. Jeszcze szybszy niż ten mechanizm losowy. Bardzo często działa naprawdę fajnie, więc tak naprawdę wybór tych parametrów, wybór tego szkieletu, tego kernela, który będzie uczony, ale wybór szkieletu, którego się nie uczy, z którego korzysta się, zależy w dużej mierze od aplikacji.

Jeżeli mamy aplikację, gdzie tak naprawdę zastosowanie standardowego Transformersa jest niemożliwe, ze względu na długość ciągu (właśnie te problemy obliczeniowe) to często właśnie te zastosowanie aproksymacji tego szkieletu softmaxa, korzystającego z Random Features jest bardzo fajnym pomysłem, bo to Ci od razu zmienia problem na liniowy i możesz korzystać z bardzo mocnego kernela. 

W wielu innych zastosowaniach, gdzie liczy się przede wszystkim czas, po prostu chcesz mieć bardzo szybkie trenowanie albo bardzo szybką inferencję. W tym momencie ten ReLu kernel jest bardzo dobrym pomysłem, ponieważ to się po prostu jeszcze szybciej liczy. 

Można też zmieniać z 1 kernel podmieniać na 2 kernel. To jest bardzo fajna rzecz związana z Performersami. Czyli można trenować z jednym kernelem, a potem robić up training albo finetunings. Innym szkieletem – możesz wziąć architekturę, która jest trenowana z jednym szkieletem, jak trenować z innym szkieletem. Właśnie to flexibility to jest coś, co uważam za jedno z najbardziej atrakcyjnych własności Performersów.

Doktorat na Columnia University

Myślę, że tu wyobraźnia została już dość mocno pobudzona, więc temat Performersów na razie zamykamy na dzisiaj. Teraz pozwolę sobie zmienić temat. Robiłeś doktorat na Columbia University. Jak oceniasz tę decyzję z perspektywy czasu? Na ile właśnie ta decyzja pomogła zbudować karierę, którą już masz, gdzie się rozwijasz, zmienić otoczenie? Powiedz, co o tym myślisz.

To było bardzo istotne, ponieważ tak naprawdę otworzyło mnie na wielką naukę. Możliwość pracy z naukowcami, którzy są naprawdę światowymi ekspertami w dziedzinie. W Kolumbii pracowałem nad teorią grafów. Miało to niewiele wspólnego tak naprawdę z maszynowym uczeniem, ale pracowałem nad trudnymi problemami. Wiele z nich cały czas są to otwarte problemy. Z ludźmi, którzy są naprawdę na topie, jeśli chodzi o tego typu rzeczy. Więc jakby jest to zupełnie inne doświadczenie niż to co miałem wcześniej.

W Polsce bardzo dużo nauczyłem się jeśli chodzi o techniki. Te techniki matematyczne, powiedziałbym, że na najwyższym poziomie i to jeszcze przed rozpoczęciem doktoratu, więc byłem w dosyć komfortowej sytuacji, nie musiałem się wielu rzeczy uczyć. Natomiast to jest temat na oddzielną dyskusję na temat inwestycji w naukę w różnych krajach. W Stanach Zjednoczonych rzeczywiście jest takie podejście, że… są oczywiście fundusze na naukę przez duże N.

Ponieważ pracują ludzie z całego świata to się wzajemnie od siebie uczymy i też jest po prostu łatwiej wpaść na coś przełomowego. Więc to miało olbrzymie znaczenie. Mnie otworzyło na taki research, którym zajmuję się już od wielu lat. Natomiast chcę podkreślić, że tak naprawdę gdyby nie lata w Polsce, gdzie nauczyłem się mnóstwo ważnych technik na Uniwersytecie Warszawskim i jeszcze przed Uniwersytetem Warszawskim to wszystko to nie byłoby możliwe.

Natomiast fundusze, które są kierowane na naukę w Stanach są nieporównywalne z innymi krajami i to się widzi nawet jak się zaczyna robić doktorat w Stanach. Więc miało to olbrzymie znaczenie, w jaki sposób ukierunkowało moje myślenie na temat kariery naukowej i chęci pracy nad tymi najtrudniejszymi problemami, rozwiązywania ich.

Więc skoro jest to taka ważna decyzja to spróbujmy teraz podpowiedzieć osobom, które teraz są na takim etapie życiowym, mają dylematy w głowie czy próbować czy nie. Jakie 3-5 trików podpowiesz osobie, która rozważa czy robić doktorat czy nie? Gdzie go robić, jak robić albo jak się np. zaczepić w Stanach Zjednoczonych?

Czy da się to robić zdalnie w tych warunkach, w których teraz jesteśmy? Podpowiedz tak po ludzku, jaka jest najkrótsza możliwa ścieżka, żeby ktoś, kto powiedzmy być może w tej chwili czuje się trochę zagubiony, być może też nie ma pieniędzy, ale ma chęć, motywację do działania, co on może zrobić?

Opcji jest bardzo dużo. Wiele osób nie zna tych opcji i tutaj jest problem. W większości przypadków tak naprawdę (tak było w moim przypadku) za doktorat nie musisz płacić Uczelni – dostajesz stypendium. Oczywiście są wyjątki, czasami może się zdarzyć, że osoba zostaje przyjęta na doktorat, ale właśnie bez tego stypendium co jest dużym problemem. Natomiast w większości przypadków (99,9%) przyjęcie na doktorat na prestiżowej uczelni amerykańskiej wiąże się z otrzymaniem stypendium.

To stypendium pokrywa wszystko – akademik, koszty związane z uczeniem itd. Ja w przeciągu całego doktoratu nie musiałem zapłacić centa z własnej kieszeni za te opłaty, które na pierwszy rzut oka wydają się duże. Są duże, jeżeli chce się płacić samemu, ale oczywiście uczelnie amerykańskie działają w ten sposób, że pomagają. Ponieważ w innym przypadku, większość studentów nie miałoby po prostu możliwości studiowania, gdyby musiała to wszystko opłacać samo. Więc to jest pierwsza rzecz, żeby się nie martwić tak bardzo o te kwestie finansowe, ponieważ jeżeli dostaje się ofertę to z reguły te kwestie finansowe są dosyć dobrze rozwiązane.

Natomiast jeśli chodzi o jakieś inne rady, generalnie uważam, że doktorat na prestiżowej uczelni, czy to jest amerykańska czy jakakolwiek inna to jest bardzo fajna rzecz. Szczególnie w Stanach po doktoracie z przedmiotu ścisłego, technicznego jest mnóstwo opcji. Można zostać na uczelni, kontynuować jako postdoc, myśleć o full time position. Można myśleć o pracy.

To była moja ścieżka, kiedy przeszedłem do Googla. Jest mnóstwo firm, które są zainteresowane osobą, która ma doktorat z dziedziny ścisłej – czy to jest matematyka, informatyka, maszynowe uczenie. To są ważne dziedziny, w które się inwestuje teraz. Więc ja zawsze mówię, że doktorat na tego typu uczelni amerykańskiej czy jakiejkolwiek innej mocnej uczelni na świecie to jest po prostu inwestycja w siebie. Uczelnia pokrywa koszty, ale to nie jest oczywiście czas, kiedy będzie się zarabiało pieniądze to jest to mimo wszystko bardzo fajna inwestycja, która pozwala potem rozważać wiele opcji.

Wiele osób mówi właśnie, że nie potrzebują doktoratu, ponieważ tak naprawdę mogą się nauczyć tych wszystkich rzeczy omijając tą ścieżkę – od razu skacząc do pracy z branży. Często tych propozycji nie ma aż tak atrakcyjnych, jeżeli tego doktoratu się nie ma. Ale poza tym doktorat to jest też kwestia poznania ludzi, którzy potem albo pracują z Tobą, albo spotyka się ich w różnych momentach swojego życia. Często właśnie współpracuje się z innymi teamami i nawiązywanie tych relacji podczas doktoratu jest bardzo ważne.

Tak więc moja rada to jak najbardziej iść na doktorat na prestiżowej uczelni. Taka ostatnia wskazówka, którą chciałbym się podzielić to, żeby nie mieć żadnych obaw, że nie powinienem czy nie powinnam się tym zająć, ponieważ ileś tam osób przede mną siedziało nad tym, próbowało to zrobić i się nie udało. To jest bardziej taka filozoficzna uwaga. Pewność siebie w każdej dziedzinie życia – w sporcie, nauce jest bardzo istotne. Jest istotna właśnie, jeżeli myśli się czy o doktoracie czy o karierze naukowej.

Oczywiście z jednej strony docenić to co inni zrobili jest piekielnie ważne, ale to co zrozumiałem dosyć wcześnie to to, że nie można o tym myśleć za dużo. Nie przeskoczysz tych wyników, jeżeli myślisz, że to jest poza zasięgiem. Nie mieć żadnych sentymentów, jeśli chodzi o to co inni zrobili. Doceniać pracę, szanować ją, szanować wysiłek, ale nigdy nie myśleć, że jest to jakaś przeszkoda, której nie da się przeskoczyć. Tylko w ten sposób można osiągnąć sukces, czy w nauce czy w sporcie. To widzimy tak namacalnie na każdym kroku. Więc to jest generalnie filozoficzna uwaga, ale wydaje się istotna.

Oczywiście te najlepsze uczelnie mają najlepszych studentów z całego świata, ale tak jak mówię, tym studentem może być Pan X czy Pani Y i to tak naprawdę od Ciebie zależy na koniec czy tak będzie czy nie. I oczywiście ciężka praca. To jest jakby wyświechtany termin, ale ileś procent to jest talent, który jest istotny, ale 70% to jest ciężka praca. Jest dużo ludzi utalentowanych, natomiast połączyć to z powtarzalnością, która jest potrzebna jak się robi doktorat czy potem właśnie w nauce. To jest kluczowa rzecz – wtedy ten talent fajnie działa i sukcesy można osiągać. Więc tyle, jeżeli chodzi o kilka takich ogólnych uwag dotyczących kariery naukowej i planowania tego.

Bardzo dziękuję. W szczególności też za te filozoficzne wątki, bo dość mocno to ze mną rezonuje. Słuchając jednego z Twoich wywiadów, fajnie powiedziałeś o studentach, którzy dość często nie wiedzą, że coś jest niemożliwe i dzięki temu mogą być bardziej efektywni, bo nie blokują się. Owszem, czasem popełniają proste błędy, których być może niektórzy nie powinni popełniać, ale przez to, że nie mają za dużo blokad w swojej głowie to po prostu próbują robić rzeczy bardziej odważne. A historia pokazuje, na ile takie podejście pozwalało odkrywać takie rewolucyjne rzeczy.

Jak sobie radzisz z tym? Jak w pewnym momencie już wiesz coraz więcej i wiesz co nie działa, jak sobie radzisz z tym, żeby mieć cały czas otwarte oczy, otwarty umysł i ignorować to pojęcie, że coś się nie da. Po prostu wszystko się da.

Generalnie pasja do nauki. Dla mnie te kwestie naukowe czy matematyka to jest taki piękny pojedynek z matką naturą, wydzierania jej sekretów. To jest taki pojedynek, który nigdy się nie kończy. Ja w ten sposób to traktuje. Uważam, że te prawa głębokie, to do czego docieramy to jest gdzieś zapisane. Jest wiele różnych filozoficznych podejść. Jest takie podejście, że my ludzie tak naprawdę tę tematykę, te prawa stojące za nią w jakiś sposób, sami tworzymy tę naszą wersję. Jest grupa, która uważa, że to jest gdzieś zapisane, a my to odkrywamy.

Więc ja należę do tej drugiej. Rzeczywiście, jeżeli myśli się o tym w kontekście pięknego pojedynku z matką naturą, który jest ciężki i te sekrety się wydziera z trudem to ma się frajdę nawet jeżeli jest problem trudny, nawet jeżeli właśnie się wie, że ileś tam osób wcześniej pracowało nad tym i tego nie zrobiło, bo się wie, że to gdzieś jest. To jest gdzieś ukryte i może Ty będziesz tą pierwszą osobą, która to zobaczy. To jest tego typu podejście. Dziecięca więc ciekawość. To pamiętam miałem od najmłodszych lat dzieciństwa, żeby właśnie odkrywać to co natura stara się szczelnie czasami ukryć. Wtedy jak się na to patrzy w ten sposób to nie myśli się tak naprawdę o tym co Pan X, Y, Z zrobił wcześniej czy czego nie zrobił, tylko myśli się właśnie o tym co ja mogę zrobić i jak wygrać kolejny z pojedynków.

To jest moje podejście. Trochę przez zabawę. Trzeba mieć frajdę z tego co się robi. Jeżeli się człowiek zacznie zastanawiać jak problem jest trudny, jak wiele było różnych innych podejść to na starcie można się poddać.

Fajnym przykładem są te Transformersy. My  się zaczęliśmy zajmować Transformersami niedawno, chyba półtora roku temu. Oczywiście same Transformersy to też jest dosyć nowy temat, natomiast ten mechanizm atencji jest znany od wielu wielu lat. Jest mnóstwo ludzi, którzy siedziało nad Transformersami wcześniej bardzo mocno i próbowało wielu różnych rzeczy. Okazało się, że było takie świeże podejście, gdzie nie myśleliśmy za bardzo kto co zrobił wcześniej, tylko mieliśmy konkretny problem, który matka natura postawiała. Uważaliśmy, że jest jakieś tam rozwiązanie, które możemy odkryć. To było fajne podejście, które doprowadziło do tego, że udało się te Performersy wymyślić.

Więc na każdym kroku, wszystkim polecam, nie zajmujcie się, nie zastanawiajcie się nad wielkimi tego świata, co zrobili, czego nie zrobili, patrzcie na matkę naturę, na własny pojedynek. Tak jak w westernach – Ty versus przyroda, świat otaczający, który kieruje się tymi ukrytymi prawami. Tylko to się liczy. To jest właśnie ta frajda, którą się ma z nauki koniec końców. A reszta – hierarchie, że ktoś coś zrobił, czegoś nie zrobił nie ma żadnego znaczenia.

Bardzo piękne. Zresztą to zdanie – trzeba mieć frajdę – myślę, że to jest takie mocne zdanie, które trzeba przyswoić. Jak po prostu jest coś na siłę to stąd się biorą dość często różne wątpliwości. Jak bawisz się w to co robisz to nie ma obawy, po prostu robisz to co lubisz.

Machine Learning za 5-15 lat

To już tak na koniec, jak w ogóle widzisz rozwój Machine Learning w ciągu 5-15 lat? Jakie kamienie milowe są możliwe? Oczywiście to wszystko zweryfikuje historia i wiem, że wróżenie to nie jest najprostsza rzecz. Ale z drugiej strony bardzo ciekawy jestem takiej Twojej intuicji, być może takich marzeń naukowych?

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ążemy 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. 

Krzysztof, bardzo dziękuję za piękną, fajną, też motywującą rozmowę. Bardzo fajne rzeczy tu wybrzmiały, wartościowe. Wszystko podlinkujemy – publikację, Linkedin, więc zapraszam też do kontaktu z Krzysztofem. Dzięki wielkie i do usłyszenia.

Bardzo dziękuję. Cała przyjemność po mojej stronie. Do usłyszenia.

Ten odcinek troszkę nam się wydłużył, ale mam nadzieję, że było warto. Wiem, że czasem warto robić troszkę krótsze odcinki, ale z drugiej strony jak się rozmawia z człowiekiem i płyną takie różne, ciekawe informacje i jest ta pozytywna energia – bardzo to czuję, jestem taki bardzo zmotywowany, żeby takimi rzeczami z jednej strony się z Tobą podzielić, a z drugiej strony też, żeby pewne klocki u mnie w głowie się poskładały, żeby jeszcze bardziej się nakręcić i zmotywować do działania. Mam nadzieję, że Ci się podobało.

Zapowiadałem, że tutaj mamy cały plan innych odcinków. Bardzo ciekawy jestem Twojej opinii na temat tych naszych eksperymentów, np. zapraszania ludzi ze świata akademickiego, naukowców. Cały czas łączymy to z praktyką. Krzysztof według mnie jest właśnie takim bardzo ciekawym kandydatem, kiedy z jednej strony to jest ewidentnie człowiek ze świata naukowego, ale z drugiej strony rzeczy, które robi, robi tak, żeby rozwiązywać praktyczne problemy. 

Jestem ciekawy Twojej opinii, co myślisz o tym samym podejściu, na ile to Ci odpowiada. Na koniec też mam taką jedną prostą prośbę do Ciebie – jeżeli to co robimy w ramach Biznes Myśli ma sens dla Ciebie to bardzo proszę podziel się przynajmniej z jedną osobą, a może z kilkoma informacją o tym odcinku. Dzięki temu więcej osób się dowie też, że być może zmieni się ich życie albo przynajmniej częściowo się zainspirują.

A z drugiej strony też jest takie poczucie wdzięczności, że to co robimy po prostu ma sens, bo to jest ważne robić rzeczy, które mają sens, bo wiele różnych rzeczy można robić w tym świecie. Wydaje mi się, że znalezienie pewnych takich formuł, które w sposób najbardziej efektywny przekazują pewną wiedzą, inspirację, motywację, dlatego tak eksperymentujemy. Dlatego też Twoja informacja zwrotna jest bardzo potrzebna. 

To tyle na dzisiaj.

Bardzo dziękuję za wspólnie spędzony czas. Życzę Ci wszystkiego dobrego, cześć, na razie, trzymaj się.

Artykuł Transformery w Machine Learning pochodzi z serwisu Biznes Myśli.