Wszyscy ekscytują się mocą wielkich modeli, podczas gdy prawdziwa rewolucja dzieje się w ciszy. Małe, wyspecjalizowane modele AI ratują linie produkcyjne, tłumaczą stary kod i decydują, co kupisz. Zamiast obietnic – ROI już teraz.
Dzisiaj rozmawiam z Michałem Furmankiewiczem nie o tym, co AI może zrobić, ale o tym, co już robi – po cichu.
AI, które schodzi do fabryki
Co się dzieje, gdy taśma produkcyjna staje, a jedyną osobą, która wie, co oznacza seria migających błędów, jest od 20 lat na rybach?
„Chcieliśmy uzyskać to, żeby trochę tak zwany tribal knowledge, czyli wiedzę, którą pracownicy długoterminowi pozyskują u danego klienta, trochę wyjąć z ich głów i przenieść do modeli. Bo ci młodsi pracownicy, którzy do takiej firmy przychodzą, potrzebują kolejnych 20 lat, żeby się tego wszystkiego nauczyć.”
Michał opowiada o małych, wyspecjalizowanych modelach, które uczą się języka maszyn przemysłowych. Zamiast pisać posty na social media, analizują kody błędów i mówią, dlaczego maszyna warta miliony dolarów przestała działać. To nie jest sexy. To jest biznes.
Dług technologiczny: Największy (i najnudniejszy) skarb w IT
Każda duża korporacja siedzi na tykającej bombie – systemach napisanych w COBOL-u, Fortranie czy C. To technologiczny dług, który z każdym rokiem rośnie, bo nikt już nie wiele osób potrafi to obsłużyć. I tu wchodzi AI – nie jako innowator, ale jako najlepszy na świecie tłumacz-archeolog.
Rozmowa schodzi na modele, które potrafią “przepisać” stary, zapomniany kod oparty o dany code-base na nowoczesne języki. I jest to rynek wart miliardy, ukryty pod warstwą korporacyjnego wstydu i dekad zaniedbań. Kto pierwszy to “wyskaluje”, zgarnie całą pulę.
Literat Full Stack – praca przyszłości, o którą nikt nie prosił
Skończył się czas klepaczy kodu i humanistów, którzy boją się technologii. Nadchodzi nowa era, a wraz z nią nowa rola, którą nazwaliśmy „Literatem Full Stack”. Ekspert dziedzinowy, który potrafi tak precyzyjnie opisać problem maszynie, że ta staje się przedłużeniem jego woli.
To człowiek, który z pomocą AI projektuje części do samochodu, a chwilę później tworzy spersonalizowane kolekcje modowe, rozmawiając z modelem językowym. To dowód na to, że w erze AI największą wartość ma nie umiejętność kodowania, ale umiejętność precyzyjnego myślenia i zadawania pytań.
Koniec e-commerce, jaki znamy
Na koniec Michał rzuca bombę: co, jeśli twoja mama zamiast wchodzić na Allegro czy do Google, pyta ChataGPT, co ma kupić? Interfejs z wyszukiwarki przenosi się do konwersacji. To egzystencjalne zagrożenie dla całego rynku e-commerce i reklamy online.
W tym odcinku znajdziesz mapę ukrytych możliwości i cichych rewolucji, które dzieją się tu i teraz. Posłuchaj,a jeśli chcesz wiedzieć, dlaczego przyszłość technologii jest mała, wyspecjalizowana i prawdopodobnie właśnie powstaje w twojej branży – koniecznie odwiedź http://aibaconference.com/ i pojaw się w Katowicach.
—
Masz chwilę? Jeśli podoba Ci się 99 Twarzy AI, zostaw ocenę i recenzję – dzięki temu możemy docierać do jeszcze większej liczby słuchaczy!
Dobrego dnia i niech #AI będzie z Wami wszystkimi!
Transkrypcja rozmowy
Disclaimer. Droga Czytelniczko, Drogi Czytelniku – mała uwaga dotycząca transkrypcji rozmowy. Jak się pewnie domyślasz – transkrypcja została przygotowana z wykorzystaniem magii LLM. Proszę o wyrozumiałość, gdyby pojawiły się w niej niewielkie błędy, literówki, etc. Żeby mieć pewność co do wszystkich wypowiedzi – polecam posłuchać, zamiast czytać. Ukłony.
Karol
Proszę Państwa, Michał Furmankiewicz pyta się właśnie, co będzie miał rysować. Przed nami kartki papieru, komputer. Michał Furmankiewicz w genialnej formie. Człowiek, który nie wiem, czy ma więcej w sobie uśmiechu, czy wiedzy i inteligencji, ale ma jej na tyle dużo, że widzimy się w 99 twarzach. Jesteś trzecią osobą, z którą widzę się po raz drugi. Pierwszy był Konrad Banachewicz. Konrad, jeżeli tego słuchasz, serdecznie cię pozdrawiamy. Druga to była Dota Szymborska, i Konrad z Dotą rozmawiali, a raczej spierali się w sprawie aktu. No i Michał Furmankiewicz. Człowiek wiedza. Wiedza wielka, ale temat mały, ponieważ będziemy rozmawiali o małych modelach.
Michał
No dobra, to mamy kilka rzeczy, więc mamy rzeczoną architekturę, o której sobie rozmawialiśmy. Teraz tak naprawdę nie jest to do końca istotne, czy będziemy mówili o małym, średnim czy dużym modelu. Bardzo wiele tych modeli, o których rozmawiamy, wykorzystuje architekturę transformerów. No więc o tym możemy sobie powiedzieć. Transformery. O samych transformerach nie będziemy specjalnie mówić, dużo o nich powiedziano, więc zostawmy.
Karol
Dla tych, którzy chcieliby poczytać i zrozumieć pracę „Attention Is All You Need” z 2017 roku, polecam to, co zrobiłem ja. Do NotebookLM wrzuciłem tęże pracę i napisałem: „wytłumacz mi tę pracę jak dla zwykłego człowieka”, co bardzo dobrze działa. A potem wygenerowałem podcast, którego sam posłuchałem.
Michał
Okej, no więc mamy rzeczoną architekturę. Musimy mieć zbiory, na których będziemy nasz model trenować. No więc mamy. I teraz tak naprawdę, jak takie zbiory przygotować? Są oczywiście metody pokazujące, jak się je przygotowuje, ale bardzo dużo zależy od tego, jaki model chcemy wytrenować, czego chcemy go nauczyć. Jest kilka praktyk treningowych, ale załóżmy, że użyjemy takiej, która jest bardzo często stosowana. Mamy prompty, na które chcemy, żeby model reagował i mamy odpowiedzi, których ma udzielać. Używając ich, powodujemy przeszkolenie iluś warstw modelu, to też jest kwestia techniki szkoleniowej, i na tej podstawie model może zdobyć, powiedzmy, nową kompetencję albo nowy kontekst dyskusji. Więc mamy same dane. Nie będziemy rozmawiać o tworzeniu modelu od zera, bo nawet Bielik wykorzystał już model istniejący.
Karol
Jeszcze jedna rzecz, jeżeli chodzi o dane, bo mówimy o różnych modelach i w kontekście małych modeli będziemy mówili nie tylko o tych do pracy nad tekstem. W przypadku takiego modelu ogólnego stosowania danymi jest cała treść w internecie. A jakie dane specyficzne moglibyśmy wybrać do różnych małych modeli?
Michał
No właśnie, to jest też ciekawa kwestia. Być może dla tych modeli, o których będziemy sobie rozmawiać dalej, to mogą być dane typu książki, które daną dziedzinę opisują. Na przykład książki, które opisują świat finansów, książki, które opisują świat produkcji. Czyli to są teksty, można powiedzieć, naukowe albo popularnonaukowe, które zawierają specyficzną wiedzę. I teraz oczywiście my musimy skorzystać ze zbiorów, do których mamy prawa, nie możemy tak sobie dowolnie ich użyć. I pewnie musimy się jeszcze zastanowić, czy zależy nam tylko na rozumieniu, czy zależy nam na rozumieniu liczb albo pewnych zjawisk, które występują. Więc te dane mogą być w różnej postaci i będą tutaj wybierane dla naszego szkolenia. No pewnie będziemy chcieli mieć, oprócz tych naszych danych, pewnie będziemy chcieli jeszcze sprawdzić, jak nasz model reaguje po przeszkoleniu. Więc będziemy chcieli mieć zestaw promptów, mówimy ciągle o modelach generatywnych, zestaw promptów, na bazie których będziemy testować sobie jakość naszego modelu. Ale to już po jego przeszkoleniu. No dobra, mamy te dwie rzeczy. I co nam się jeszcze w tym wszystkim przyda? Pewnie jeżeli rozmawiamy w ogóle o modelach, to warto wyjaśnić kilka prostych kwestii. Takich jak to, czym jest token, czym jest okno kontekstowe, o którym zaraz sobie porozmawiamy, no i pewnie jeszcze warto wyjaśnić, czym jest parametr, bo bardzo często się używa do określenia wielkości modeli takiego pojęcia, jak ilość parametrów dla samego modelu.
Karol
Okazuje się, że token to nie litera, a wszyscy myślą, że token to litera.
Michał
Token to nie litera. Notabene, jest wiele prac o tym, jak tokenizować język naturalny. I jest wiele tokenizatorów, które do tego służą. Można znaleźć open source’owe tokenizatory. W zależności od algorytmu, którego użyjemy do tokenizacji języka, na koniec dnia tokenizacja polega na tym, że w grupie tekstu wybieramy ten zlepek czy też tę sekwencję liter, która występuje bardzo, bardzo często. Tą oznaczamy identyfikatorem. Proces jest trochę bardziej skomplikowany. Tutaj polecimy YouTube’a od Andreja Karpathy’ego, który to dokładniej pokazuje. Natomiast na koniec dnia zastępujemy od dwóch do czterech znaków w języku angielskim liczbą, tak efektywnie. Dlaczego to jest istotne? Dlatego, że potem z tego już wiemy, dlaczego na przykład nasze modele nie wiedzą, ile „r” jest w „strawberry”, bo one nie liczą liter, tylko liczą tokeny i przewidują tokeny.
Karol
Oczywiście, ale co warto zaznaczyć, token to nie to samo co sylaba.
Michał
Absolutnie, token to nie to samo co sylaba, bo sylaba jest pojęciem językowym, a token jest, z dużym uproszczeniem, pojęciem bardziej matematycznym niż językowym. Dobra, więc musimy jeszcze rozmawiać o tokenizatorze. To też ciekawe, myślę, że warto wiedzieć, że tokenizatory potrafią działać różnie dla różnych języków i na przykład tokenizatory używane bardzo często przez te duże, amerykańskie modele z polskim językiem radzą sobie w ten sposób, że tych tokenów generują więcej dla danego słowa, bo ta powtarzalność tokenów jest mniejsza. I siłą rzeczy to samo zdanie napisane po polsku a po angielsku, po polsku będzie droższe. I to taki może ciekawy zjawisk. W językach, notabene, dużo rzadziej występujących przy trenowaniu tych dużych modeli, te mniej rozpoznawane języki będą jeszcze droższe właśnie w takim kontekście. No i okno kontekstowe, idziemy przez te wszystkie pojęcia. Okno kontekstowe naturalnie chyba wszyscy będą rozumieli. To po prostu będzie suma tego, co do modelu wysyłacie.
Karol
Przepraszam, jak spotykam się z ludźmi i pada hasło „okno kontekstowe”, to wszystkim wydaje się, że okno kontekstowe to jest to okienko, do którego wpisujemy nasze pytanie. A tak nie jest do końca?
Michał
Tak jest, no bo musimy myśleć o wejściu, czyli o tym, co my wysyłamy do tego modelu. Musimy myśleć o wyjściu, ale są jeszcze co najmniej dwie rzeczy. Jeżeli dokładamy do tego naszego pytania jakiś dodatkowy kontekst z plików… Właśnie, kontekst. Czy mamy system prompt jeszcze jakiś w naszym rozwiązaniu? To system prompt plus to, co wysyłacie, plus cały wasz kontekst, wszystko to zjada wasze tokeny na wejściu. No i siłą rzeczy pomniejsza ilość tokenów, które jesteście w stanie wygenerować na wyjściu. I też warto zobaczyć, że modele najczęściej mają inną wielkość okna na wejściu i inną wielkość okna wyjściowego. To razem właśnie daje to okno kontekstowe.
Karol
Plus jeszcze jedna uwaga, suma wszystkich odpowiedzi też wchodzi nam do okna kontekstowego.
Michał
Tak, czyli jeżeli chcemy zawrzeć w kolejnym pytaniu historię wszystkich tych naszych wywołań, to to też zjada okno kontekstowe. I wcale twierdzenie, że jak weźmiemy sobie model, który ma milionowe, może zjeść milion tokenów na oknie kontekstowym, to wcale niekoniecznie pomaga nam w całej sytuacji.
Karol
Szczególnie że i prompty, i dokumenty, i ilość treści, którą generujemy, zwiększa się cały czas. Zrobiłem ostatnio eksperyment, zapytałem, no bo dużo się mówi o statystycznie wystarczającej długości prompta, żeby on był dobrym promptem. No to mówię, dobra, sprawdzę, jakiej długości mam prompty u siebie. I wyszło mi, że ponad 2000 znaków.
Michał
Okej, to już dużo. Coraz dłuższe. Coraz dłuższe. Dlatego pytanie, czy lepiej budować tak skomplikowany prompt, który budujesz, czy być może lepiej pracować z tym tekstem tak, że generować kilka po sobie następujących mniejszych promptów, które są bardziej specyficzne. Ale to już jest filozoficzna trochę dyskusja, bo pytanie, co chcesz uzyskać. Jeżeli twoja praca jest iteracyjna, to pewnie moje podejście będzie lepsze.
Karol
Masz rację, w przypadku takiego długiego widzę też, że czasami model się gubi i lepiej jest to po prostu zrobić kroczek po kroczku, od ogółu do szczegółu.
Michał
Tak, no właśnie, to jest jakiś tam przykład. Myślę, że druga kwestia jest też taka, że jeżeli w jednym prompcie zawrzesz na przykład pytanie wielokrotnie złożone, to model absolutnie też się bardzo często, bardzo pięknie zgubi. Dlatego jest koncepcja Agentic RAG, dlatego są inne koncepcje, gdzie właśnie takie bardziej skomplikowane pytanie rozbijamy na mniejsze i ten proces powielamy.
Karol
Dygresja, mógłbyś rozwinąć, czym jest Agentic RAG?
Michał
Jak najbardziej. Sam RAG, czyli Retrieval-Augmented Generation, koncepcja, która pojawiła się właściwie od razu po tym, jak wszyscy zajęli się ChatemGPT. W skrócie polega na tym, że chcielibyśmy, żeby model nam udzielił jakiejś odpowiedzi, ale na danych, których nigdy nie widział, najczęściej naszych prywatnych albo danych, które mamy w firmie. No więc koncepcja polega na tym, że my, zanim w ogóle wyślemy cokolwiek do naszego modelu, to szukamy w pytaniu naszego użytkownika danych, które wspierają tę odpowiedź albo są potrzebne do udzielenia tej odpowiedzi w naszej treści, w naszym kontencie. Wyobraźcie sobie, że macie książkę, w tej książce są odpowiedzi na wasze pytania firmowe, no więc najpierw przeszukacie tę książkę.
Karol
Mało tego, wyobraźmy sobie, żeby to lepiej zobrazować, nie tylko książkę, ale nie jesteśmy w firmie, tylko podsumowujemy swoje życie. Mamy swoje własne pamiętniki, listy od przyjaciół, pocztówki, które otrzymaliśmy z różnych miejsc, a więc wiele różnych źródeł dotyczących jednego tematu: naszego życia.
Michał
Okej, proszę bardzo. To jest właśnie kontekst, w którym trzeba teraz wyszukać te chwile, te momenty, te informacje, które właśnie w tej treści występują.
Karol
I teraz mówimy językiem modelu. Możemy zadawać pytania tak, jakbyśmy prowadzili rozmowę na temat ogólny, ale w kontekście tylko i wyłącznie danych dostarczonych przez nas.
Michał
No i właśnie RAG polegał na tym, w dużym uproszczeniu, że szukaliśmy tego dodatkowego kontekstu w tej naszej treści, wybieraliśmy to, co najbardziej pasuje. Do modelu leciał nasz prompt plus informacja, że „tu masz dodatkowy kontekst”, no i to wszystko było odpowiednio sformatowane. I teraz model na podstawie tego starał się wygenerować odpowiedź na bazie tej treści, jeszcze wskazać źródła, etc. No super. Tyle tylko, że takie klasyczne podejście RAG-owe najczęściej sprawdzało się, albo kiedy pytanie było szczegółowe, jednoznaczne, nie było wielokrotnie złożone. I też sprawdzało się najczęściej wtedy, kiedy informacja o danym temacie była w dokumencie skupiona, powiedzmy, w jednym miejscu albo była skupiona w czankach, czyli częściach tekstu, które mogliśmy łatwo wyszukać. Postawmy sobie trochę bardziej zaawansowane w takim razie pytanie. Chcemy zapytać o nasze własne życie, ale na przykład chcemy zapytać o coś bardziej skomplikowanego. Właśnie, czyli na przykład chcemy zadać pytanie wielokrotnie złożone i na nie nie da się odpowiedzieć jednym wycinkiem naszego tekstu. Czyli na przykład, które zdarzenia w naszym życiu wpłynęły na to, że tak fantastycznie posługujemy się, na przykład, pismem albo językiem, albo gramy dobrze w jakąś grę? Tych momentów w życiu może być wiele, więc my musimy ten proces powtórzyć. Stąd koncepcja, żeby po pierwsze jedno zapytanie rozebrać na zapytania mniejsze, wielokrotnie odpytać tego naszego RAG-a, poszukać w nim tych kontekstów, a następnie z tych wielu części razem złożyć odpowiedź. Oczywiście koncepcji implementacyjnych jest co najmniej kilka, natomiast w skrócie rzecz polega na tym, że jesteśmy w stanie rozwiązać dużo bardziej skomplikowane problemy za pomocą Agentic RAG, również w dużym zbiorze danych.
Karol
Dla tych, którzy nie wiedzą, przykładem takiego narzędzia RAG-owego są dwa notebooki. Jeden Microsoftowy, który jest w środowisku Microsoftu już dostępny, albo NotebookLM w środowisku Gemini.
Michał
Tak jest, tam są takie proste RAG-i, które sami możecie sobie absolutnie budować i z nich skorzystać. Proste, ale tak jak rozmawialiśmy, bardzo skuteczne. Jak najbardziej, bardzo skuteczne dlatego, że tam siłą rzeczy twórcy ograniczyli sobie w pewien sposób ilość źródeł, które możemy dołączyć, a mają swój dobrze wymyślony sposób czankowania, czyli dzielenia tych wszystkich tekstów na mniejsze kawałki, i bardzo, wydaje się, dobrze zoptymalizowany sposób wyszukiwania tych kawałków i składania właśnie odpowiedzi w całość. Plus przy okazji w notebooku jednym i w drugim możemy też określić, jakiego typu odpowiedzi chcemy uzyskiwać, więc to jest też bardzo ciekawe.
Karol
Dobra, czyli mamy dane, mamy tokeny, mamy okno kontekstowe zdefiniowane. Teraz parametr.
Michał
Tak, no teraz to pewnie jest jedna z trudniejszych rzeczy, którą trzeba sobie wyjaśnić, ale na koniec dnia to są po prostu, można powiedzieć, zmienne, za pomocą których model interpretuje wejście i generuje wyjście. Więc teoretycznie im więcej tych zmiennych, im więcej tych parametrów, tym treść, która zostanie wygenerowana, może być dużo bardziej wielowariantowa.
Karol
Wiesz, jak ja sobie to tłumaczę? Bo ja lubię analogie i nie jestem człowiekiem technicznym. Dla mnie to jest poszerzanie swojej wyobraźni.
Michał
Okej, okej, ty mówisz o wyobraźni.
Karol
W sensie widzę szerzej. Okej, widzę szerzej. Czyli więcej parametrów… Czy zgodziłbyś się z tym, czy nie? Bo jeżeli się nie zgadzasz, to wyprowadź mnie z błędu.
Michał
Nie, nie, nie. To nie chodzi o to, że się z czymkolwiek nie zgadzam. Z tym, że jeszcze jedna rzecz. Wcale nie musi się okazywać, że w tym dużym modelu wszystkie parametry będą uczestniczyły w odpowiadaniu na twój koncept pytania. Czyli z jednej strony masz rację, bo te parametry sprawiają, że z reguły model potrafi generować odpowiedzi w większej ilości domen, potrafi reagować na różnego rodzaju wejścia, ale nie dla wszystkich typów zapytań model wszystkich tych parametrów będzie używał. Wręcz dokładnie odwrotnie. Więc nie, to nie, że się nie zgadzam, tylko po prostu…
Karol
Czyli z jednej strony poszerzam moją wyobraźnię, a z drugiej mam więcej narzędzi używanych do specyficznych zadań.
Michał
I jeszcze myślę, że jest jedna rzecz: ta wielowariantowość odpowiedzi jest dużo, dużo wyższa, dlatego też przy modelach o większej liczbie parametrów takie zjawisko jak halucynacja będzie występowało statystycznie częściej niż przy modelu mniejszym. Bardziej specyficznym. Tak, bardziej specyficznym. I to jest feature, a nie bug. I tak samo sama halucynacja i na siłę generowanie odpowiedzi przez model dla każdego pytania, nawet jeżeli model z naszego ludzkiego punktu widzenia nic nie wie, jest też cechą, której się modele uczy, a nie za którą się modele karci. Jest zresztą bardzo wiele dobrych dokumentów, które pokazują, że modele są szkolone do tego, żeby w zasadzie na każde pytanie udzielić odpowiedzi.
Karol
Bardzo ciekawą pracę napisał Michał Karpowicz jakiś czas temu, dokładnie w tym temacie.
Michał
Okej. Ostatnio też startup, który powołała była CTO OpenAI, pokazywał, że halucynacja, a może inaczej, że model, któremu zadamy ten sam prompt w krótkich okresach czasu, może ten sam model udzielić dwóch różnych odpowiedzi. I nie wynika to nawet z faktu tego, że włączają się te parametry jak temperatura czy top-p, tylko z tego faktu, że obliczenia na GPU i te wszystkie zaokrąglenia, które wykonujemy, prowadzą do tego, że wybieramy inny kolejny token, stąd odpowiedź jest inna. Więc oni tam pokazują sposób na stabilizację odpowiedzi dla tych samych promptów. Ale tak, wracając do teraz, więc modele z reguły specjalizowane będą zawierały tych parametrów mniej, bo po pierwsze zależy nam na tym, żeby taki model zachował się lepiej w danej domenie, udzielał bardziej specyficznych odpowiedzi, ale też, ostatnia kwestia, żeby łatwiej go było przeszkalać i doszkalać. Bo takie modele z mniejszą ilością parametrów po prostu łatwiej się szkoli.
Karol
Ale znowu, ta ilość parametrów… Skoro te modele, takie jak ChatGPT, Gemini, są tymi modelami General Purpose Technology, czyli do ogólnego użytkowania, no to im więcej tych parametrów, im większa ich przestronność, tym w tym przypadku lepiej.
Michał
Tak, no bo dla użycia takiego, tak jak powiedziałeś, codziennego, my staramy się pokryć jak najwięcej use case’ów, jak najbardziej różnych. I takich właśnie codziennych. A z drugiej strony, właśnie w tym modelu specyficznym nie interesuje nas, czy ten model wie na przykład, jaki jest przepis na jakieś ciasto, a nawet jak wie, to powiedzmy, że wygeneruje jeden taki albo dwa i one nie będą wysokich lotów.
Karol
A my chcemy napisać encyklopedię dań o cebuli.
Michał
No i wtedy też być może… Co więcej, no oczywiście takie modele z reguły generują dużo mniejsze, krótsze, siłą rzeczy, odpowiedzi, nawet jeżeli poszerzymy to pytanie o to, żeby ten kontekst wygenerowany był dużo, dużo większy, co też akurat nam sprzyja, bo my do czegoś zupełnie innego tych modeli chcemy używać. Ostatni element, prompt. No i to jest coś, co pobudza model, bo tak naprawdę na koniec dnia te modele, które najczęściej znamy, zachowują się w takim trybie completion, a więc one tak naprawdę uzupełniają treść, którą my do modelu wrzucimy. Więc nasz prompt to jest tekst, bo to tak naprawdę jest tekst na koniec dnia, do którego model właśnie próbuje dołożyć completion, czyli uzupełnia tę treść. Albo można powiedzieć, że to jest coś, co pobudza model. Trochę jak pytanie od drugiego człowieka, które pobudza nasz mózg do wygenerowania dla nas odpowiedzi.
Karol
Czytałem ostatnio świetny komentarz. Nie dziwcie się, że otrzymujecie głupie odpowiedzi, zadając głupie pytania.
Michał
Albo nie dziwcie się, że uzyskujecie niejasne albo mało sprecyzowane odpowiedzi, zadając bardzo generyczne pytania. I dlatego właśnie te wszystkie konteksty…
Karol
Wiesz co, porównuję to do takiego amerykańskiego „How do you do? I’m fine, thank you.”.
Michał
No tak, to jest rozmowa o niczym, prawda? Poza tym ona jest czysto kulturowa i nie ma nic wspólnego z rzeczywistym sposobem zapytania o to, jak się rzeczywiście czujesz. Amerykanie traktują to tak samo jak „cześć” i „do widzenia”. Dlatego nie próbujcie odpowiedzieć na „how do you do” jakoś inaczej, szczególnie w sklepie, gdzie pracownik sklepu popatrzy na was i będzie lekko zdziwiony, o co wam w ogóle chodzi. Ale też ciekawa rzecz, bo jak już poruszyłeś ten temat promptów, bardzo dużo mówi się o prompt engineeringu, a ciągle mam wrażenie, że ten temat jest tak trochę… ludzie chcą się go uczyć, a z drugiej strony nie chcą się go uczyć.
Karol
Dawaj, z chęcią o promptowaniu zawsze, o każdej porze.
Michał
Bo na przykład narzekamy na to, że narzędzie do generowania kodu nie wygenerowało takiego kodu, narzędzie do wygenerowania tekstu nie wygenerowało takiego tekstu i tak dalej. Bo jesteśmy leniwi. Więc jak już jesteśmy leniwi, to mam propozycję. To weźcie tego swojego prompta, opiszcie w dwóch słowach, co od tego prompta chcecie. Użyjcie modelu, żeby wam wygenerował lepszego prompta. Najlepiej użyć innego modelu niż tego, od którego chcecie się czegoś dowiedzieć. Weźcie tego prompta, wrzućcie do tego waszego modelu. Tę odpowiedź, którą wam wygeneruje, wrzućcie do jeszcze innego i zobaczcie, czy jest ciekawa.
Karol
A potem wiesz co jeszcze robię na przykład? Pytam: „O czym najbardziej oczywistym nie pomyślałem?”.
Michał
To jest też ciekawe pytanie. Natomiast konkludując, ja bardzo dużo ciągle gdzieś tam piszę sobie kodu, nie wiem, czy dla funu, czy w pracy, czy to jest jedno i drugie, połączenie dwóch rzeczy, ale jeżeli ja na przykład w tych wszystkich narzędziach do vibe codingu, czy teraz jest vibe engineering, nie wiem, czy wiesz, Karol. Wiesz, co jest vibe engineering? Niedługo wszyscy będziemy inżynierami.
Karol
Tak, chociaż…
Michał
Zostawmy to.
Karol
W vibe engineering zakładam, że to jest prompt inżynier, który chce zarabiać już więcej, ponieważ koduje.
Michał
Konkludując, jeżeli ja mojemu narzędziu, które generuje mój kod, wyjaśnię, co ja chcę osiągnąć, które elementy mojego organizmu ja chcę zmienić, jak chcę, żeby je zmienił, zaproponuję mu sposób walidacji tych elementów i tak dalej, jestem dużo bardziej zadowolony z mojego efektu.
Karol
To wiesz, jak to się nazywa po polsku? Jak się nazywa? Literat full stack.
Michał
Literat full stack. Tego jeszcze nie znałem. To jest ciekawe. Literat full stack. Nie, vibe engineering… Śmieję się, bo zobacz.
Karol
Skoro mówisz o tym prompt engineeringu, vibe engineeringu, no to schodzi się to ku znajomości mechaniki, wiedzy dotyczącej języków, architektury danych i tego, co chcesz osiągnąć, plus odpowiedniego sformułowania całego zadania.
Michał
I pewnie jeszcze vibe engineering będzie się różnił tym, że ten inżynier jest leniwy w zakresie klepania tego najprostszego kodu, ale doskonale sobie będzie potrafił poradzić.
Karol
A dociekliwy w przypadku uzyskania dobrych wyników.
Michał
Tak, i będzie potrafił sobie poradzić z przekształceniem tego kodu, ze zmianą tego kodu, z dostosowaniem, z ponawianiem tego promptu, żeby osiągnąć efekt, który jest dla niego interesujący. A potem jeszcze będzie miał tę jedną wartość, żeby ten kod przenieść na rozwiązanie produkcyjne, rozwiązanie działające w rzeczywistości.
Karol
Mam znajomego, który właśnie stwierdził ostatnio, że mimo swojego początkowego sceptycyzmu wszedł mocno w temat i on teraz mówi, że widzi, że jest w stanie pracować w tempie, jakie miał kiedyś on i jego siedmioosobowy zespół. On teraz sam, ale dlatego, że ma 20 lat doświadczenia i on prosi, widzi, ale poprawia.
Michał
Absolutnie, absolutnie. I wiesz, poprawiasz, testujesz i co więcej, jest jeszcze jedna rzecz, nie wyłączamy mózgu w tych wszystkich operacjach. Opowiem, przyznam się do swojego dużego błędu, jeśli mogę. Sobota, niedziela, przepraszam, żona po przysłowiowym obiedzie zrobiła sobie 20 minut drzemki, gdzieś tam z psiakami sobie leży, a ja stwierdziłem, mówię: „moja droga, to wiesz co, to ja użyję tej godzinki, w którą będziesz się tak relaksowała, bo o 15:00 mam formułę i tutaj coś lekko poprawię”. I nie przyznaję, że klasycznie multithreading, robiłem coś i patrzyłem w ten kod. Jedno podejście, drugie podejście, trzecie podejście. Fajnie, GitHub Copilot wygenerował mi tego kodu bardzo dużo, dużo debugingu, bo testowałem coś, czego nie rozumiałem tak do końca, jak się zachowuje, więc chciałem właśnie zdebugować tak klasycznie, czyli wypisywałem na ekran, co tam się dzieje. No i mimo dwóch godzin ja widzę, że tego kodu narąbane niesamowicie dużo, tylko efekt ciągle nie ten, a ja nawet nie rozumiem dalej, co się dzieje. To znaczy ten cały debugging tak naprawdę po prostu mi nie działa. No ale wyłączyłem mózg, wyłączyłem mózg, mówię: „dobrze, jedziemy dalej, generujmy”. GitHub Copilot zachował się genialnie. Kodu do debugingu wygenerowanego w tym momencie już naprawdę na tyle dużo, że już zaczynało mi to przeszkadzać. Ja już wiedziałem, że za chwilę to wszystko wytnę, mówiąc obrotnie, w cholerę, bo już mi to przeszkadza, mi jako osobie, która ma to zrozumieć. Natomiast co się wydarzyło? Okazało się, że ten kod w GitHubie pięknie wyglądał. Niestety ta wersja nie deployowała, nie uruchamiała się w Cloudzie na kontenerze, bo po prostu tam był jakiś błąd semantyczny, czego już akurat GitHub w tym momencie nie wykrył. Python, więc nie kompilował, nie sprawdzał tego lokalnie, więc ja tak naprawdę w Cloudzie testowałem wersję sprzed 4 godzin, tu miałem wersję 4 godziny dalej. Przyszła 15:00, chciałem bardzo obejrzeć Formułę 1, ale bardzo się stresowałem, że to mi ciągle nie działa, więc Formuła leciała na jednym komputerze, a ja na drugim dalej z GitHub Copilotem bardzo silnie walczyłem. Dobra, wyłączyłem mózg, powierzyłem wszystko narzędziom, sprawdźmy the basics. Którą wersję ja mam tu, która wersja jest w Cloudzie, co ja w ogóle testuję i tak dalej. I to mnie bardzo dużo właśnie nauczyło, że mimo… Znaczy ja nigdy tego mózgu nie wyłączałem, ale teraz jakoś tak, wiesz, robiłem to jako drugie zadanie, więc… Wiem, że mało seksowna przypowiastka, ale tylko pokazuje jedną rzecz.
Karol
Jak mówisz o tym, to wiesz co ja robię na przykład, Michał? Ja po prostu zaczynam od kartki papieru. Dlatego mam dużo kartek dużych, szarego papieru, i najpierw zaczynam sobie szkicować i zastanawiać się nad tym, co ja w ogóle…
Michał
Ale to ja też. Ja bardzo dużo sobie rysuję sam dla siebie kółek, kwadratów i tak dalej, przepływów, a dopiero potem robię. Natomiast tutaj to był bardziej kod, który nie miał nic wspólnego z logiką ani z funkcjonalnością, to był tylko kod do debugowania tak naprawdę problemu innego, który wykryłem po prostu sobie w tym kodzie. No dobra, mamy prompty, parametry, okno, tokeny, dane, architekturę. No to pewnie jeszcze mamy jakąś tam ewaluację. Mówiliśmy o tym na końcu, że pewnie jeszcze warto sobie na końcu, jak już ten model będziemy budować, to jakąś ewaluację uruchomić i zobaczyć, że dla tych naszych przykładowych promptów, dla których chcemy, żeby ten model odpowiadał specyficznie i odpowiednio jakościowo, chcemy sprawdzić, jaka jest jakość. Czyli porównać wejście, wyjście i na przykład z proponowanym wyjściem, który sami jako ludzie byśmy…
Karol
Ewaluacja jest subiektywnym benchmarkiem.
Michał
On jest subiektywny, ale oparty o pewną prawdę, to znaczy tą prawdą, do której dążymy, jest albo treść, znaczy inaczej, wiedza, którą model ma wygenerować na bazie tych danych szkoleniowych, albo jest specyficzne jego zachowanie na bazie zbioru treningowego. Więc ono nie jest tak do końca subiektywne, bo możemy to policzyć. Możemy policzyć, jak bliska jest odpowiedź modelu z naszą modelową odpowiedzią, albo jak bardzo nasza odpowiedź, która nam wyszła, jest uziemiona, zgroundowana na danych, których użyliśmy do wygenerowania tej odpowiedzi. Więc tutaj mamy jednak pewne matematyczne możliwości. Możemy też oceniać styl. A więc jeżeli zależało nam na konkretnym stylu…
Karol
Ja bardziej ku temu stylowi się tutaj…
Michał
Tak, czyli mamy jakby jakość rozumianą… Wersus to, co my byśmy… Może inaczej. Specjalista, którego próbujemy wesprzeć tym modelem, by odpowiedział. Uziemienie w danych, które dostarczyliśmy naszemu modelowi, no i właśnie ten styl wypowiedzi, który jest zbliżony do tego stylu, do którego się chcieliśmy zbliżyć, to też możemy oceniać sobie, w jakimś sensie matematycznie są do tego mechanizmy.
Karol
To przejdźmy. Skoro mamy zdefiniowany model, to mamy te wielkie modele, których już ilości parametrów nie jesteśmy w stanie policzyć. Albo nie są podawane. Albo nie są podawane, tym bardziej. Opowiedzmy o tym, po co się dzisiaj spotkaliśmy, o małych modelach. I znowu, zacznijmy od definicji, rodzaju, a potem przejdziemy do ich cech.
Michał
Nie wiem, czy jest jedno źródło prawdy, które mówi o tym, jakich definicji używamy, ale w takim powszechnym rozumieniu mówi się bardzo często, że te duże to tam 100 miliardów plus albo 70 miliardów plus, te średnie to gdzieś będą właśnie w okolicach tych 70 miliardów, ale przy tych małych to najczęściej myślimy o tych tam 14-15 miliardów w dół. No i pewnie są modele, które mają i 500 milionów parametrów, takie malutkie. To chyba Google pokazywał taki bardzo mały model swojego czasu. To są takie, które mają 7, 10, 14.
Karol
Który zakładamy, że będzie na Pixelu niedługo dostępny, tak?
Michał
Znaczy tak, to oczywiście, że do tego dążymy. Bo to jest chyba Gemma. To ona miała nawet 250 milionów parametrów. No ale przecież czy Qweny, czy DeepSeeki to są też bardzo małe modele, czyli ta liczba parametrów jest mniejsza, siłą rzeczy model waży mniej, na przykład kilka giga, więc siłą rzeczy łatwiej go umieścić nawet w karcie graficznej, którą macie w laptopie za kilka tysięcy z marketu. 6 tysięcy złotych dzisiaj wystarcza i mamy laptop do gier, który ma 12 giga RAM-u na 590 albo trochę starszej karcie i już taki model spokojnie, całościowo w RAM-ie karty graficznej umieścimy i można się nim fajnie bawić. No dobra, więc to są te klasyfikacje. Duże, średnie, małe. Kropka. No i o tych małych powiedzieliśmy sobie i one bardzo często, te małe, ponieważ są oczywiście modele przeznaczenia ogólnego, to jednak częściej widzimy te małe, które są dopasowane do domeny albo do problemu, który chcemy rozwiązać.
Karol
Super, definiujmy te domeny i dajmy przykład domen, które potrzebują takich małych modeli.
Michał
Domen jest bez liku, ale możemy wymienić domenę biznesową.
Karol
Te, które widziałeś najciekawsze i te, które patrzysz i mówisz, o cholera.
Michał
Dzięki. Nie wiem, czy widziałem aż tyle, żeby powiedzieć, że to są te najciekawsze, bo pewnie zdyskredytuję jakieś inne, ale na przykład są mniejsze modele, które świetnie się nadają do branży finansowej, a więc one rozumieją specyficzny język finansów, rozumieją specyficzne stwierdzenia albo rozumieją formaty na przykład zeznań podatkowych, zeznań inwestycyjnych i tak dalej firm, a więc mogą posłużyć do ekstrakcji tych danych, do zrozumienia tego na przykład standingu finansowego, odpowiedzenia na pytanie, co się z taką spółką dzieje, ale mogą też służyć do tego, żeby lepiej rozumieć rynki inwestycyjne, żeby lepiej rozumieć na przykład zachowanie instrumentów finansowych. Cała rzesza modeli, która na przykład lepiej rozumie aspekty prawne, czy to modele, które rozumieją na przykład specyficzne logi czy też zachowania maszyn produkcyjnych. No bo maszyny produkcyjne tak na koniec dnia też generują kody błędów, tylko one są mało human friendly, że tak się wyrażę. I ktoś może uznać, czy to jest ciekawy…
Karol
To bardzo ciekawy przykład. Możemy to rozwinąć, bo o ile dobrze pamiętam, kiedyś mówiłeś, że pracowałeś nad takim projektem. I odejdźmy od tekstu i przejdźmy do przemysłu.
Michał
Okazuje się, że jeżeli wyobrazicie sobie jakąś fabrykę, ja nie jestem ekspertem w tej dziedzinie, więc przepraszam wszystkich tych ekspertów, którzy będą to słyszeli i się zastanawiali, o czym on mówi. Otóż na linii produkcyjnej pojawiają się urządzenia, które rzeczywiście na przykład produkują opakowania. No i można sobie wyobrazić, że jeżeli mamy 10 największych firm na świecie, które produkują opakowania, to one kupują tę samą linię produkcyjną. Co jest absolutnie błędnym stwierdzeniem. Po pierwsze każda linia jest w zasadzie robiona na zamówienie i oprócz podstawowych elementów są elementy dodatkowe, takie add-ony, które już są produkowane per dana firma produkcyjna. To jest po pierwsze. Po drugie, wiek tych urządzeń to są bardzo często dziesiątki lat. Dziesięć, dwadzieścia, piętnaście. Po trzecie wreszcie, kody błędów zależą od właśnie bardzo specyficznego setupu, który my mamy. I na koniec pojawia się problem: jak ustalić, co było tym pierwotnym błędem, kiedy widzimy szereg kodów błędów na linii produkcyjnej.
Karol
Kiedy nam przestanie lecieć taśma.
Michał
Tak. I teraz okazuje się, że do każdego z tych urządzeń producent wygenerował opasłe tomy kodów błędów, które to pokazują. Tylko że już żaden producent najczęściej nie wygenerował jednego tomu, który mówi, jak złożyć te pięć urządzeń w całość, to to jest właśnie ten root cause analysis. No i tak, był budowany model, który był w stanie zrozumieć szereg kodów błędów, które są z całej linii produkcyjnej zbierane.
Karol
I powiedzieć, że za dwa miesiące wam padnie ten moduł.
Michał
Nie, nie, właśnie to nie było predykcyjne. Był w stanie powiedzieć, że ten kod błędu, który widzicie, wynika z… Czyli on był nauczony po pierwsze identyfikacji tych kodów błędów, a po drugie korelacji tych kodów błędów, które się pojawiają.
Karol
Czyli rozumiem, żeby zbudować taki model, musiałeś mieć całą dokumentację plus do tego dokumentację wcześniej przeanalizowanych błędów na jakiejś linii produkcyjnej i całą historię napraw, tak?
Michał
Nawet już bez historii napraw, bo tu mogliśmy, żeby to zrobić bardziej generycznie. Gdybyśmy historię napraw jeszcze do tego dołączyli, to byśmy mieli sytuację, że w zasadzie miałoby to sens dla jednego klienta. A tutaj firma, która takie maszyny produkuje, powiedziała: „nie, nie. To my nauczymy tych kodów błędów tak bardzo szeroko, spróbujemy je wystandaryzować, pójdziemy do klienta, klient udostępni nam swoją historię napraw, my ją przeindeksujemy i teraz zrobimy sobie RAG-a, o którym żeśmy dzisiaj mówili”. I w momencie, kiedy wystąpi taka sekwencja błędów, model wykryje tę sekwencję błędów, będzie w stanie root cause analysis spadać do dokumentacji.
Karol
Prześlemy mu w paczce wszystkie części, żeby on sobie mógł to naprawić.
Michał
To oczywiście będzie kolejny element, ale wcześniej jeszcze powiążemy to z historią napraw i będziemy wiedzieli, że prawdopodobnie taki kod błędu wystąpił już wcześniej, porównamy sobie te rzeczy, ale modele do tego się akurat dobrze nadają.
Karol
Jakie są wyniki tych eksperymentów?
Michał
Wyniki są takie, że nie mam liczb za tym stojących. Natomiast to, co przede wszystkim chcieliśmy uzyskać, to to, żeby trochę tak zwany tribal knowledge, czyli wiedzę, którą pracownicy długoterminowi pozyskują u danego klienta, trochę wyjąć z ich głów i przenieść do modeli. Bo ci młodsi pracownicy, którzy do takiej firmy przychodzą, potrzebują kolejnych 20 lat, żeby się tego wszystkiego nauczyć, co jest mało efektywne, mało fajne. Ale też nierobialne, jakby długoterminowo to nie jest proces, który jest efektywny. To jest punkt pierwszy, a punkt drugi jest taki, że to już nie jest tylko tribal knowledge, który unika, ucieka, tylko to jest coś, co możemy zwrotnie do tego modelu wprowadzać i go szkolić per klient. Czyli pierwszy etap był taki: zróbmy model, który na klasach urządzeń, które produkujemy, jest w stanie te root cause analysis znajdować. Krok drugi jest taki: klient, który ma dość duży asset, zestaw tych naszych narzędzi, będzie mógł doszkolić wersję specyficzną.
Karol
Fantastyczne to jest, co mówisz, bo zobacz, jak wychodzimy poza sam tekst, kod, tylko dotykamy różnych, różnych branż i do tego jeszcze sprzętu. Zaczynamy mówić językiem maszyny trochę.
Michał
I to jest ten drugi case, który już gdzieś tam kiedyś pokazywałem, czyli na przykład case, gdzie okazuje się, że przy projektowaniu samochodu, ekspresu do kawy czy rakiety, tak na koniec dnia używane są systemy CAD CAM, które posługują się jakimś modelem 3D do zwizualizowania tych elementów, ale pod spodem to jest po prostu jeden wielki zestaw API, czyli takich interfejsów programistycznych, które interfejs graficzny wywołuje. I teraz, o ile my nie potrafimy, znaczy właściwie to potrafimy, ale może tak: o ile dzisiaj w tych scenariuszach my nie tworzymy modeli, które operują na warstwie graficznej, to możemy tworzyć modele, które generują znowu kod, które wywołują te warstwy API i mogą modelować obiekty w systemie CAD-CAM, czyli w takich systemach, które wspierają inżynierię taką projektową.
Karol
Pozdrawiamy serdecznie Kubę Trzynę. To jest człowiek zafascynowany drukiem 3D i ostatnio pokazywał mi właśnie, w jaki sposób projektuje się modele 3D z wykorzystaniem ChataGPT. Ja powiedziałem: „no to w takim razie chciałbym zobaczyć kłódkę w kształcie serca z wypukłymi brzegami”, po czym nagle pojawiły mi się piękne cztery modele kłódki, które można było poprawić, przesunąć i tak dalej.
Michał
No tak, co ciekawe, i to jest może też właśnie jedna taka różnica, o której nie powiedzieliśmy. Przy tych modelach bardzo, bardzo dużych one mają bardzo wiele domen, na których się znają. No właśnie, od generowania tekstu po rozumienie języka na przykład VHDL albo języka, którego się używa w CAD CAM-ach. Podczas gdy te mniejsze modele to będą rozumiały tylko jeden z tych elementów. Ale wracając do naszego przykładu ostatniego, są specyficzne języki używane w przemyśle, które używane są do bardzo specyficznych rzeczy. I te języki najczęściej są jakąś wersją, jakąś inną odmianą języka, który znamy. Czy to będzie Python, czy to będzie C, czy to będzie inny język. Tylko ten język jest na tyle specyficzny, że poza tą wąską domeną zastosowań nikt go nie zna. I nikt go się nigdy nie będzie uczył, chyba że pracuje w tej firmie.
Karol
Albo to jest język sprzed 20 albo 30 lat, który teraz trzeba dostosować do nowych możliwości. Albo umożliwić pracę ludzi, którzy nigdy nie mieli doświadczenia na pracę z tym językiem w połączeniu z nowymi narzędziami.
Michał
Zaraz o tym też pogadamy, bo to jest w ogóle inny, ciekawy problem do rozwiązania. Ale kończąc ten wątek: co by było, gdybyśmy właśnie mieli taki model wspierający, który na pytanie „jak wygenerować w naszym systemie produkt A”, albo „jak go narysować”, albo „jak go przesunąć, zmniejszyć, powiększyć, nie wiem, wykadrować”, generowałby specyficzny kod, który by nam to robił na ekranie trochę za nas? Raz, przyspieszał proces prototypowania, dwa, walidował błędy, które najczęściej występują przy takim projektowaniu, trzy, skracał ścieżkę nauki dla młodych adeptów sztuki, którzy wchodzą na ten rynek i dla nich uczenie się inżynierii projektowania i specyficznego systemu CAD-CAM, plus całej rzeszy takich quality checks, które trzeba sprawdzić przed wypuszczeniem tego projektu, jest niezmiernie trudnym procesem w danej domenie. Czyli jak ty się nauczysz projektować ekspresy do kawy, to wcale nie znaczy, że umiesz już projektować Chevroleta czy Forda, bo to jest inny problem do zrobienia. A to dalej jest CAD-CAM, tylko w zupełnie innej domenie. No i co by było, gdybyśmy mieli model albo modele specyficzne właśnie do takiego zastosowania, bardzo, bardzo wąskiego, a z drugiej strony bardzo trudnego?
Karol
Kurczę, i wchodzi wtedy artysta bądź artystka, humanista, do takiej pracowni wiesz, industrialnej całej, i projektuje piękne rzeczy.
Michał
Znaczy, wiesz, to jest tylko kwestia…
Karol
Albo wpada na pomysły, których nie było wcześniej.
Michał
Tak, to pewnie zaraz dojdziemy do tego, że jak będziesz miał właśnie taką artystkę, artystę i po drugiej stronie partnera dla niej do rozmowy, to z dyskusji tych dwóch pewnie wyjdzie koncept, który właśnie wcześniej nie był trenowany, bo jedno zainspiruje drugie i to drugie to pierwsze, a potem jak już ten koncept wizualizujemy, to ona dość łatwo będzie mogła to przełożyć na projekt fizyczny. Oczywiście w tym miejscu jeszcze nie jesteśmy, ale to jest pewnie tylko kwestia inwestycji, czasu i po prostu prób i nieudanych eksperymentów. Ale wracając do twojego problemu, który ty podałeś, ja uważam, że podniosłeś problem, o którym my nie dyskutujemy tak wcale dużo, czyli stare języki, języki dzisiaj zapomniane. Mówimy nie o językach ludzkich, komunikacyjnych, tylko mówimy o językach programowania albo językach, które tak są silnie związane ze sprzętem i architekturą, że bardzo często nauczenie się języka nie wystarcza, musisz rozumieć architekturę systemu. Notabene, w Stanach w czasie COVID-u bardzo dużo szukano programistów, i teraz nie pamiętam, czy to był Fortran, czy COBOL, a więc języka, w którym napisany jest ciągle Social Security Number amerykański, wokół którego bardzo wiele rzeczy jest skorelowanych. Na przykład jak było skorelowane wydawanie szczepionek. Ale wracając, nie tak dawno, całe dwa lata temu, miałem taką rozmowę z jedną z dużych firm, która produkuje sprzęt sieciowy, która mówi tak: „Michał, my dzisiaj mamy 99% naszego stosu technologicznego opartego o C, które jest jeszcze w standardzie w Berkeley, to jest to z TCP/IP właśnie Unixowy. 90% nowych studentów, których przyjmujemy z amerykańskich uczelni, to są studenci, którzy znają Rusta, to jest najniższy język programowania, jaki oni znają.”
Karol
Którzy mówią „Unix, to jest samochód z Chin?”.
Michał
Nie, nie, to akurat jeszcze nie, ale którzy mówią: „język C, no okej, ale nie pisaliśmy, nie mamy doświadczeń, itd.”. I teraz z jednej strony mamy to wyzwanie niedopasowania kompetencji, ale to zostawmy. Łącznik między pokoleniami trochę. Ale teraz mamy drugie wyzwanie: no jeżeli teraz taki właściciel tej firmy powie, żebym ja był w stanie utrzymywać ten system, to ja muszę go przepisać na Rusta. Teraz, jak ja mam to zrobić dla wszystkich modułów swojego kodu? No teraz oczywiście, że on nie jest w stanie dzisiaj zrobić tego w całości, bo też z perspektywy osób nietechnicznych wydaje się, czym jest przepisanie jednego języka programistycznego na drugi. No i to jest taki prosty problem, to jest jak translacja języka naturalnego. No to nie jest prawda, dlatego że języki programowania mają pewną strukturę, pewną architekturę, pewne zależności i trochę inaczej się tych języków używa. Nie można tego czysto porównywać do tekstu mówionego i pisanego. A więc dużo trudniej napisać jest translator, który tłumaczy język C na język np. Rusta. Dlatego, że pewnych koncepcji, które występują w języku C, nie przeniesiemy na inny język, w którym one nie występują. I tak może być, że pewną rzecz w języku C zrobisz tak, a pewną w języku Python zrobisz tak.
Karol
Czyli trochę tak, jakbyśmy kiedyś posługiwali się językiem tylko słowa, a teraz dodajemy do tego emocje, mowę ciała i różne inne rzeczy. Poszerzamy to o możliwości, których wcześniej nie było.
Michał
Możemy to porównać na przykład do jeszcze innej rzeczy. Nie wiem, czy wiesz, ale w języku hebrajskim, czy może inaczej, w języku, którym na przykład posługują się Izraelczycy, w tym języku jest bardzo mało słów opisujących emocje. Więc bardzo często Izraelczycy mówiący po angielsku brzmią tak, jakby byli niegrzeczni czy też tacy nieokrzesani, to złe słowo, ale właśnie niegrzeczni w swojej wypowiedzi. Takie „rude”. Tak, ale oni nie są niegrzeczni. Oni mogliby powiedzieć, że Amerykanie to bardziej są tacy „sugar-coated”, no bo oni powiedzą „would you like to”, albo coś takiego, gdzie w ich języku takie sformułowania w ogóle nie występują.
Karol
Bo oni się musieli całe życie bronić.
Michał
Więc dla nich to jest czasami trudne. Ja bardzo dużo pracuję z kolegami, koleżankami z tamtego regionu, no więc bardzo często rozmowa z nimi jest troszeczkę inna w swoim wymiarze.
Karol
No teraz przenosząc to na język… Ostatnia anegdota. Swoją drogą, właśnie o Izraelczykach też czytałem kiedyś bardzo ciekawą rzecz i odniesienie do ich historii, że oni nigdy nie mieli dużej ziemi. Musieli mieć swój kapitał i swoją wielkość budować umysłem. Stąd tyle patentów i rozwiązań, które powstały właśnie tam.
Michał
Nie mam takiej wiedzy historycznej, żeby wejść tutaj z tobą w dyskurs, zupełnie szczerze. Myślę, że mam tak podstawową, że aż wstyd. Więc nie będziemy się w to zagłębiać.
Karol
To jest rzecz, którą usłyszałem od jednego gościa, który właśnie mieszkał dużo w tamtym regionie, ale tak, wiesz, historycznie nawet od czasów… tak samo. To jest moja bardzo płytka wiedza, ale jak sobie pomyślisz, no zobacz, to jest kraj, który zawsze walczył o swój teren i tego terenu dużo nie mieli.
Michał
Wracając do naszego pierwotnego punktu, z którego wyszliśmy, rozmawialiśmy o tym, żeby być może mieć taki model, który byłby dobry właśnie w translacji, w zamienianiu jednego języka programowania na drugi, uwzględniając te wszystkie wzorce projektowe, konteksty, które dla każdego języka są naturalne, ale w drugim mogą nie występować. Pewnie, znaczy pewnie, na pewno tutaj też będzie dużo prac prowadzonych i na pewno jako w Microsofcie, znaczy GitHub Copilot, grupa GitHub Copilot na pewno pracuje w tym obszarze. I jak w ogóle myśleć o przepisywaniu kodu, który już mamy. No bo jak się o tym chwilę dłużej pomyśli, to my się tak czasami naśmiewamy z naszych kolegów Amerykanów, jakie to mają stare IT, jakie to mają stare systemy i tak dalej. No ale myślę, że za 15 lat my w Polsce będziemy sobie patrzeć w oczy i też będziemy patrzeć na te swoje systemy i mówili, kurczę, one też już są stare. Nie wszystko będziemy w stanie przenieść na nowe technologie, a dług tylko się powiększa i nie będziemy mieli kim czasami tego przepisywać. Stąd ta koncepcja modeli nie jest taka zupełnie pozbawiona sensu, a co więcej…
Karol
To fascynujące, co w ogóle mówisz, bo z tego się taka teoria wielkiej spuścizny programistycznej tworzy.
Michał
Nie wiem, czy wielkiej spuścizny, ale na pewno wielkiego długu. My o tym myślimy jako o długu technologicznym. No bo dlaczego dług? No bo po pierwsze właśnie masz brak tych kompetencji, brak wsparcia dla tych technologii, ale też ta ścieżka już potem konwersji z tych starych architektur jest po prostu bardzo, bardzo trudna, często wieloletnia, kosztowna, ryzykowna, you name it.
Karol
Bo, popraw mnie, czy dobrze rozumiem, że to chodzi też o to na przykład, że masz cały system oparty o współczesny język programowania, różne rozwiązania takie, wiesz, nazwijmy to sprzęty pracujące sieciowo i tak dalej, które muszą współpracować ze sprzętami, które dalej funkcjonują, ale są sprzętem sprzed 20 albo 30 lat.
Michał
To jest jeszcze pół biedy, bardzo często my jeszcze to umiemy czasami zrobić na poziomie komunikacyjnym, ale potem się okazuje, że te właśnie stare systemy, o których powiedziałeś, te stare sprzęty, na przykład wspierają protokoły, które już są outdated, które są niebezpieczne, nie można ich zabezpieczyć, które nie potrafią zwracać na przykład odpowiedzi w formatach, których byś się dzisiaj spodziewał, jak JSON na przykład, które używają formatów, których nie rozumiemy, trzeba do nich opisać jakieś parsery. Ale może też się okazać, że ta technologia, że już jak chcesz dopisać jakiś kolejny moduł do tego systemu, a musisz często dopisać coś do tego systemu, to się okazuje, że nie jest to możliwe, bo nie masz programistów, którzy piszą w tym języku. Albo się okazuje, że baza danych, którą używa ten system, jest bazą, której się dzisiaj nie stosuje, i nie potrafisz z niej odczytywać danych, albo jest to bardzo trudne, albo żeby zrobić to efektywnie, musisz mieć to doświadczenie w tym obszarze. I nagle okazuje się, że masz system, który jest trudno rozwijalny, trudno utrzymywalny, zaczyna przestawać być bezpieczny, nie jesteś w stanie z nim nic specjalnego zrobić, a obsługuje twoje kluczowe transakcje biznesowe, więc go też nie możesz wyłączyć. No ktoś powie, napiszcie drugi. Napisanie drugiego to duży koszt, przemigrowanie.
Karol
Kolejny przykład jakiś ciekawy. Czyli mamy ten dług technologiczny, mamy przemysł, mamy, kiedyś wspominałeś jeszcze tak, retail i służba zdrowia.
Michał
Tak jest, to weźmy retail, bo to jest chyba też ciekawy case. To akurat nie jest chlubne, co sobie powiemy, ale trzeba sobie to powiedzieć wprost, to znaczy nie jest chlubne dla branży modowej.
Karol
Jezu, nie mów, że będziemy gadali o ciuchach.
Michał
W naszym kręgu klimatycznym mamy cztery pory roku, ale efektywnie branża modowa generuje od 6 do 12 kolekcji modowych.
Karol
Michał, ja tego nie rozumiem, bo jestem człowiekiem, który ma 15 takich samych podkoszulków.
Michał
Ja jak się z tobą spotykam, to pewnie mam ciągle tak samo wyglądającą czarną koszulkę, mimo że takich mam z pięć albo z sześć, ale nieważne. Więc nie, to nie jest nasz target. I teraz nie oskarżamy nikogo o to, że korzysta z modnych rzeczy, po prostu my nie jesteśmy odbiorcą tego typu produktów. Anyway, mamy rzeczonych 12 kolekcji. Te 12 kolekcji to są tysiące produktów per kolekcja, to są dziesiątki tysięcy często tych produktów. Przy dużych markach to jest kilkanaście tysięcy pozycji per kolekcja. Razy dwanaście, mówimy o kilkuset tysiącach produktów, które generujemy. No i teraz dzisiaj już nikogo nie interesuje wyszukanie sukienki na lato 2025, tylko interesuje cię tak zwana emocja, czyli jak ty chciałabyś wyglądać. Więc ty możesz napisać, że chciałabyś wyglądać w sposób następujący, a model językowy mógłby na podstawie informacji o tych wszystkich…
Karol
Widzę, że to nie jest temat, który cię interesuje.
Michał
Nie, brnijmy w to. Nie wiem, czy chcemy brnąć, ale w każdym bądź razie…
Karol
Ale nie, słuchaj, przepraszam Michał. Ja się, wiesz, bo ja ci mówię, jestem człowiekiem, który podchodzi bardzo pragmatycznie do swojej garderoby, ale to mnie fascynuje, co mówisz. Słuchaj, okej, czyli jestem człowiekiem, który niezwykle ceni sobie piękno, strukturę, tkaninę, materiał. Staram się to dopasować do miejsca, mojego nastroju, do tego, w jakim towarzystwie się ubieram, czy idę do opery, czy filharmonii.
Michał
I musisz, Karol, jeszcze uznać ten aspekt, że nie dobieramy tylko spodni, butów, koszulki, ale torebkę, ale kapelusz, ale kurtkę, ale jakiś gadżet. To jest cała magia wokół tego, ale też zapach, na przykład, jak masz pachnieć. Inaczej się pachnie na jesień, a inaczej się pachnie na lato. Widzę, że się śmiejesz. Widzisz, ja musiałem zagłębić trochę tych tajników. Na koniec dnia chodzi o to, że mamy dedykowany model, który rozumie opisy bardzo wielu naszych produktów, ma pewne pomysły czy też umie dobierać produkty do siebie w zależności od właśnie potrzeb. I w ten sposób właśnie masz swojego prywatnego asystenta modowego, który patrzy na ciebie, dobiera ci outfit do tego, jak chcesz wyglądać.
Karol
Ostatnio przeczytałem coś takiego, że coraz droższy będzie smak.
Michał
To jest, będzie wyglądać tak samo, tak, tak, może nie, okej.
Karol
Czyli taki, dobra, czyli taki model jest zbudowany na opisach, na opisach całej kolekcji tych produktów?
Michał
Tylko zobacz, bardzo często go będziemy musieli przeszkalać, bo 12 razy w roku. Bardzo często będziemy chcieli dodawać do niego właśnie te różne szablony, że tak się powiem, generowania tychże kolekcji razem, w jakie chcemy ubierać naszych klientów. No i teraz można powiedzieć, że to jest prosty search. Taka była moja pierwsza myśl. Nie jest to prosty search.
Karol
Powiem ci tak, jak mi powiedziałeś o czymś takim, to ja bym sobie to zrobił katalog, i tak jak ty to opowiadasz, to ja sobie wyobrażam, że do każdej sukienki masz dwustronicowy opis, żeby ten opis potem był wyrafinowany.
Michał
I błąd.
Karol
Nie masz tagu. A ja bym sobie zrobił to na zasadzie tagów, czyli sukienka zwiewna, kwiaty, bawełna, slim, i jest okej.
Michał
I jakby takie tagi mamy. Do tego mamy opisy, które generujemy sobie oczywiście innym modelem.
Karol
Czy w takim razie, skoro opisy generujemy modelem, nie będziemy mieli sytuacji, o której mówi się dużo, że będziemy szkolić kolejne, jeszcze większe modele na treściach, które są przez te modele generowane?
Michał
Tutaj akurat tego problemu nie ma, dlatego że my mówimy, tutaj ta wiedza jednak, którą generujemy, jest specyficzna, czyli my jednak generujemy te opisy bardzo szczegółowe, zwracamy uwagę na pewne rzeczy, na krój, na materiał, tak jak powiedziałeś, na inne aspekty. Na przykład na to, do jakich kolekcji to pasuje, do czego to nie pasuje, więc generujemy więcej, niż widać z czystego obrazu tak naprawdę. A po samych metatagach, po samych metadanych, o których wspomniałeś, tak, da się szukać, tylko zwróć uwagę, ile żółtych sukienek na dany okres może wygenerować dana marka. Żółte, ale z elementami białego, niebieskiego, ramion… Słuchaj, ja się na tym nie znam.
Karol
Wiesz co, ja teraz wzdycham, ale rzeczywiście, uświadomiłem sobie, przy tak dużym wyborze, tak jak powiedziałeś, jest 300 tysięcy elementów w ofercie, to opis może… No tak, bo ja myślę swoimi kategoriami, bo ja myślę, wiesz, podkoszulek granatowy, sweter granatowy, tylko cienki czy gruby.
Michał
Myślę, że nie jesteś dobrym przykładem do tego case’u. A ja też nie. Ja też nie, także notabene kupiłem sobie ostatnio takie same buty, jak mam na sobie, szukam takich samych, po prostu kliknąłem.
Karol