71/99 – Wielka siła w małych modelach, Michał Furmankiewicz

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
No wiesz co, to skoro już ten odcinek możemy zatytułować „Sztuczna inteligencja i anegdota” albo „Małe modele językowe i anegdota”, to ja na przykład kupiłem sobie buty, które lubię, kupiłem ich pięć lat temu trzy pary, żeby nie musieć szukać. Problem tylko taki jest, Michał, ostrzegam cię, gdybyś chciał robić to samo. Jeżeli kupujesz buty pięć lat wcześniej, to bardzo prawdopodobne, że po pięciu latach, nawet jak założysz nowe buty, to okaże się, że podeszwa się odkleiła, więc musiałem, akurat byłem poza Warszawą, musiałem skleić sobie te buty.

Michał
A myślałem, że powiesz, że one przestaną być modne, co chyba dla ciebie nie jest jakimś kryterium. Nie, to akurat o tym w ogóle nie myślałem. Anyway, ostatni wątek, który jest niezwykle ciekawy, ale nie mam dobrych doświadczeń tutaj, jeszcze pewnie prace trwają albo po prostu nie jestem zaktualizowany. Widzisz, wszystkie systemy Lidar, Radar, które są na samochodach autonomicznych, one działają na zasadzie rozpoznawania obiektów, ale to rozpoznawanie obiektów czasem nie jest idealne. Jest dużo prac, które zmierzają do tego, żeby wykorzystywać architekturę transformerów, paradoksalnie, do tego, żeby w bardzo krótkim czasie generować potencjalnie opis tego, co widzi kamera samochodu w trakcie poruszania się, i na tej podstawie podejmować decyzję, czy to jest paczka po chipsach, upadnięty karton, który stanął na drodze takiemu samochodowi, na drodze temu pojazdowi. No i co z tym zrobić? Nie chcę mówić więcej, bo tutaj jakby można sobie… Generalnie są prace, które…

Karol
A, czyli „opisz mi, co widzę”.

Michał
Tak, tylko wiesz, pamiętajmy, że ten model w samochodzie będzie musiał działać w ułamkach sekund i będzie musiał jeszcze działać w warunkach specyficznych, reagować na specyficzne rzeczy.

Karol
Ale to zobacz, że to jest ta… Przepraszam, bo ja teraz, wiesz, staram się przetwarzać to, co mi tłumaczysz. To jest trochę ta analogia jak z projektowaniem 3D, tak? Czyli język projektowania i tego, co widzisz na ekranie w postaci modelu 3D jest zamieniany na słowa i na opis.

Michał
I tutaj oczywiście pierwsze koncepcje są takie, że dalej to będzie obraz zamieniany, który możemy zinterpretować tekstowo i wykryć, czy dany element występuje na obrazie, ale dużo ciekawszym pomysłem jest to, czy możemy wygenerować nasz właściwy, jakiś specyficzny język, właściwy tylko dla tych sytuacji, i w tym języku, używając architektury transformera, przewidywać kolejne tokeny.

Karol
Pytanie z ciekawości, a czy w tej technologii pojazdów autonomicznych, popraw mnie, czy moje myślenie jest w dobrym kierunku, to masz tak: masz tę technologię radaru, czyli masz obraz z technologii radaru, potem masz ten opis, czyli masz obraz połączony z przestrzenią, bo lidar, radar ci mówi, co jest bliżej, co jest dalej, czyli tworzysz sobie nie tylko obraz, ale też falę radiową, uderzasz i możesz powiedzieć odległość od obiektu i kreujesz sobie jego kształt, więc wiesz, że to jest kula, długa, krótka czy cokolwiek innego, i potem to przekładasz na tekst.

Michał
Nie, tego się nie robi, bez tych modeli systemy lidar, radar sobie świetnie działają. To jest bardziej kwestia, czy jesteśmy w stanie wesprzeć to, co widzimy też kamerami na takich trasach samochodów, do tego, żeby wesprzeć omijanie przeszkód, omijanie sytuacji nietypowych, wykrywanie sytuacji nietypowych, więc to jest bardziej w tę stronę. Czyli to nie jest zastępowanie tego, co jest, to jest wspomaganie tego, co jest, jeszcze dodatkowym zachowaniem, tak, no dokładnie. Więc to jest jakby taka koncepcja, natomiast mówię, nie wiem, jak daleko te prace poszły do przodu, czy w ogóle poszły do przodu, bo wiem, że nad tymi rzeczami ludzie pracują na świecie. Natomiast no widać, że ta autonomiczność samochodu w pewnych obszarach się, można powiedzieć, udaje, finansowo może to się jeszcze nie spina, ale myślę, że compelling event jest gdzie indziej. To niekoniecznie musi być w samochodach osobowych.

Karol
Michał, wróciłem właśnie z Chin i to, co już się sprawdza, widziałem: autonomicznych kurierów. Wózki takie, które jeszcze są pakowane przez ludzi, ale tu chodzi o przemysł i o rozwożenie paczek, dużych palet w sposób autonomiczny, już poza fabryką nawet. Jeździłem też autobusem autonomicznym. Fakt faktem na razie niewielkim, po zamkniętym terenie, czyli on nie jest jeszcze wypuszczony na ulice miasta, ale to już, cholera, działa.

Michał
Oczywiście cała branża transportowa by oddała bardzo wiele, żeby ciężarówki autonomiczne jeździły. Są koncepcje, oczywiście one nie są skomercjalizowane. Jest wiele też kwestii prawnych, kwestii odpowiedzialności. W to nie wchodzimy, bo ja się na tym nie znam, więc nie chcę o tym w ogóle dyskutować i rozstrzygać. Natomiast na pewno też w Chinach widziałeś, co prawda one nie są autonomiczne, czyli koparki sterowane od wielu setek kilometrów.

Karol
Nie, tego nie widziałem, nawet o tym nie słyszałem, ale nie dziwi mnie to, jak o tym mówisz.

Michał
To widać, tak jak się szkoli operatorów dronów, którzy przecież są w danym miejscu bardzo daleko od tego obiektu, od tego drona, tak jak są zdalni operatorzy koparek. Czy to głęboko w ziemi, czy to też głęboko na ziemi, którzy potrafią przez kilka godzin obsługiwać koparkę w jednym miejscu, a parę godzin później obsługiwać koparkę, która jest setki kilometrów w innym miejscu, i to się dzieje. Oczywiście jest wiele wyzwań związanych z widocznością, etc. Natomiast na koniec dnia pewnie byśmy chcieli, żeby to był w jakimś sensie też robot, bo to będzie dużo bardziej bezpieczne dla nas. Więc tutaj pewnie też pole jest, nie wiem, czy koniecznie akurat dla naszych modeli, o których rozmawiamy, bo tu odbiegliśmy bardzo mocno od tego tematu, niemniej jednak na pewno…

Karol
Wspominałeś jeszcze, jak przygotowaliśmy się do tego odcinka, czyli mamy te trzy branże poprzednie, zdrowie.

Michał
Tak, zdrowie. Taki bardzo prosty case, który się może wydać aż za prosty, żeby w ogóle o nim dyskutować, ale myślę, że trochę żyjąc w Polsce nie widzimy tego problemu. Wyobraź sobie służbę zdrowia amerykańską albo służbę zdrowia azjatycką. W obu przypadkach masz osoby, które niekoniecznie się urodziły i znają natywnie dany język. Na przykład w Singapurze bardzo wielu lekarzy to są lekarze, którzy mówią po angielsku z różną naleciałością. Natomiast bardzo często panie pielęgniarki czy personel wspomagający niekoniecznie jest personelem, który mówi po angielsku dobrze. No i masz klienta, pacjenta, który może mówić w różnym języku, niekoniecznie będzie to angielski.

Karol
I niekoniecznie rozumie język, w którym komunikują się między sobą lekarz a pielęgniarka.

Michał
W Stanach problem jest jeszcze czasami bardziej skomplikowany. Ja nie znam się bardzo dobrze na amerykańskim systemie ochrony zdrowia, ale on jest kilkuetapowy, czego my nie widzimy. Więc ty jako osoba chora zgłaszasz się najpierw do swojego ubezpieczyciela, który wskazuje ci pośrednika, który realizuje twoją opiekę medyczną, i to ten pośrednik umawia cię z daną placówką medyczną, czyli z daną przychodnią bądź z danym szpitalem, w zależności od tego, z kim mają podpisaną jaką umowę. Pamiętaj, że tam jest system prywatny, który jest bardzo nieefektywny, bo jak zobaczymy kraje, które najwięcej inwestują w służbę zdrowia w Europie, to my inwestujemy kilka procent, max chyba siedem to są te kraje najbogatsze, które w Europie inwestują. Amerykanie, tak bardzo efektywni, inwestują prawie piętnaście procent publicznych pieniędzy w służbę zdrowia, mimo że ona jest prywatną służbą zdrowia, więc to jest niesamowite, można te dane sprawdzić. Piętnaście albo trzynaście, jeden z najmniej efektywnych systemów służby zdrowia. Ale teraz do problemu. Mieszkasz na Florydzie, jesteś Amerykaninem, który jednak urodził się i lepiej zna język hiszpański. No więc dzwonisz i próbujesz wyjaśnić, że cię boli kolano. Odbiera telefon osoba, która może pochodzić z dowolnego zakątka na świecie i jej język angielski nie musi być bardzo wysoki. I ona dzwoni teraz do placówki medycznej, w której odbiera kolejna osoba personelu pomocniczego, która wcale po angielsku nie musi mówić idealnie. A potem jest jeszcze lekarz, który próbuje to wszystko, co zebraliśmy, zrozumieć, który nawet jeśli nie jest Amerykaninem, to już jednak jego poziom językowy i zrozumienia angielskiego być może jest wyższy, chociaż też nie jest to gwarancja, prawda? No więc gdzie się pojawia problem? Problem się pojawia w opisie tego, co mi jest, w opisie tego, co powinniśmy zrobić, żeby zbadać, co ci jest, w opisie tego, co powinniśmy ci zarekomendować. Problem wydaje się niewielki, no bo chodzi o tę translację na tych wszystkich warstwach, ale pojawiały się koncepcje i pojawiają się koncepcje, w których chcemy mieć właśnie model, który potrafi przetłumaczyć jednych na drugich, mówiąc brutalnie. Nagra rozmowę, zapisze, co na tej rozmowie zostało powiedziane, być może wykryje, że rozmowa odbywała się w dwóch językach, bo ktoś mówi po angielsku, ale wstawia hiszpańskie słowa albo inne słowa w innym języku. Ta transkrypcja zostanie przez ten model poprawiona, przetworzona i trafi do tego lekarza w innej formie. W drugą stronę, kiedy już nasz pacjent z tego szpitala wyjdzie, na podstawie wszystkich notatek, które zbudował lekarz, które napisała pielęgniarka, które być może też są w różnej formie, zrobimy check-out, czyli wypisanie naszego pacjenta, właśnie używając modelu, który te wszystkie informacje, które w tych różnych źródłach danych będziemy mieli, zbierze i wystawi. To już niekoniecznie być może potrzebujemy dedykowanego modelu, ale na pewno modelu, który chcemy lekko doszkolić właśnie dla tych dziwnych wszystkich przypadków, o których mówimy. To taki case. W Singapurze jest taka jedna implementacja, na pewno wiem, że w Stanach, właśnie w tych stanach, w których większość mieszkańców to są mieszkańcy hiszpańskojęzyczni albo używają innych języków, takie próby też są, są firmy, które się tym absolutnie zajmują i pośredniczą w tym procesie.

Karol
Także tak na koniec. Czyli nie dość tego, że specjalizacja, a jak jeżeli chodzi o koszty versus efektywność?

Michał
To jest pewnie trudny temat do zbadania, dlatego że potrzebujemy większej próbki i dłuższego czasu, żeby ocenić. Natomiast dzisiaj ważna informacja chyba jest taka. Koszty przeszkalania takich modeli znacząco spadły i będą spadać dalej. Oczywiście przy tych różnych modelach ten czas jest różny, ale pewnie mówimy od miesiąca do trzech przy tej pierwszej próbie stworzenia jakiegoś tam dopasowanego modelu, no ale może trochę dłużej. No i pewnie mówimy o tym, że co pół roku, rok, może co kwartał, może tak co sezon w tej modzie, będziemy go doszkalać, będziemy go przetwarzać.

Karol
To może w inną stronę. Czy bez podawania nazw jakichś, czy masz w głowie, czy znasz jakiś przypadek, w którym mógłbyś powiedzieć: mały model, jaka branża, jakie koszty, jakie zwroty?

Michał
Możemy na pewno powiedzieć o jednym takim przypadku, a mianowicie o przypadku właśnie tym modowym. Koszt wytworzenia samego modelu to są, tak jak powiedziałem, dziesiątki tysięcy dolarów, mówimy o 20-30 tysiącach dolarów, żeby model wytworzyć, więc to nie są gigantyczne środki. Oczywiście potem musimy go przeszkalać. Ilość wywołań takiego modelu: mówimy o 12 do 15 milionów wywołań modelu miesięcznie, ale to jest dopiero początek, absolutnie. Koszty wywołań nie są duże, dlatego że skoro rozliczamy się w milionach tokenów najczęściej, to mówimy o tym, że stoi za tym kilka maszyn z kartami graficznymi, tak na koniec dnia, w chmurze. Dosłownie kilka, możemy policzyć, ile tego jest. I teraz tak, ROI, bo na pewno chcesz zapytać o ROI.

Karol
Dlaczego pytałem o to, Michał? Bo wiesz, wszyscy mówimy o tym, dobra, więcej, szybciej, sprawniej, a ja mówię, dobra, ale to pamiętajmy, dodawajmy do tego metrykę.

Michał
Tutaj nie zawsze „szybciej, lepiej, sprawniej”, akurat w tym case wcale nie musi być istotne. Już powiem ci, dlaczego. Bo tutaj chodzi o to, że nie mieliśmy tej możliwości wcześniej. Czyli my nie mieliśmy takiej możliwości, że trochę model jest naszym prywatnym asystentem modowym, a żeby utrzymać…

Karol
Dobra, okej. To ja cały czas będę do tego dążył. Proszę bardzo. Słuchaj, super, fancy thing.

Michał
Tak, to jest fancy thing, to jest fancy thing, absolutnie.

Karol
To pytanie, czy jest na przykład dowód na to, że to zwiększyło sprzedaż w określonym segmencie?

Michał
To spowodowało, że nie utraciliśmy tej sprzedaży, czyli to jest w drugą stronę. Czyli my mówimy tak: te marki, które najszybciej będą pokazywały ci spersonalizowany sposób ubierania, wygrają tym, że klienci będą częściej wracali, łatwiej wybierali, jest szybszy time to click, czyli od wymyślenia do zakupu, i właśnie nie pójdą do innej marki. Czyli zobacz, że dzisiaj marka nie walczy tylko tym, że ma najlepsze ciuchy, ale potrafi cię najlepiej, najfajniej ubrać i jeszcze potrafi to zrobić tak, żebyś czuł się indywidualnie zaopiekowany. Akurat w tym przypadku modowym. Natomiast, żebyś usłyszał o realnym case’ie. Mam estymaty, które chcemy osiągnąć, nie wiem, czy już je spełniliśmy. W jednym przypadku nasz cel jest taki, żeby czas przeszkolenia nowej osoby korzystającej z danego oprogramowania do projektowania spadł z 12 miesięcy do 3 miesięcy, bo dzisiaj mówimy, że przeszkolenie takiej osoby trwa 12 miesięcy, chcemy dojść do tego, żeby trwało 3. Tylko żeby sprawdzić, że te 3 nam to trwa, to potrzebujemy pewnie co najmniej 24-36 miesięcy, więc tu jeszcze musimy poczekać na efekt naszych prac. Natomiast takie jest założenie, w tę stronę będziemy do tego dążyli. I teraz dlaczego to jest takie istotne, bo akurat w tym przypadku mówimy o tym, że mamy brak kompetencji rynkowych i te kompetencje nie produkują się tak szybko, jak byśmy chcieli, i wcale niekoniecznie ludzie chcą w tym zawodzie pracować. Czyli znowu my walczymy z utratą, która nam grozi.

Karol
Dziękuję za uwagę. Dobra, to co dalej? Małe modele, tak jak rozmawialiśmy, które będą uruchamiane na telefonach, na małych komputerach?

Michał
Tak, to się już powoli dzieje. Koledzy od Bielika co chwilę pokazują, jak jakiegoś małego Bielika uruchamiają tam na jakimś Androidzie. To oczywiście nie jest szybkie, tych tokenów na sekundę jest pojedyncza ilość, nie jest efektywne, ale to jest tylko kwestia czasu. Już dzisiaj są, zresztą w Chinach, o których wspominałeś, są projekty telefonów, które tam mają jednostki NPU. Apple też tutaj nie śpi, na pewno będzie coś w tym zakresie robił. Google tak samo, patrząc na kolejne Pixele i na Gemmę.

Karol
Dokładnie. Teraz jest tylko pytanie: po co i jak, do czego tego stosować? Jaki jest twój pomysł i jakie widzisz?

Michał
Wiesz co, ja widzę, że w ogóle pojawi się nowa kategoria aplikacji. Takich aplikacji, których dzisiaj nie mamy. W jakimś sensie trochę tę kategorię, czy lubimy to, czy nie, trochę tworzy Copilot na telefonie, czy Microsoftu, czy ChatGPT na telefonie, ale myślę, że to nie jest jeszcze to, o czym mówię. O takim twoim trochę doradcy, o takim twoim trochę partnerze. Tylko teraz tak. Dzisiaj to, co wszystko masz, te wszystkie Copiloty, ChatGPT i inne, takie companions na telefonie, mają jedną wadę. Nie chcą zapisywać informacji o tobie, bo ochrona danych osobowych, bo coś tam. Nie są spersonalizowane. One mogą mówić o wszystkim, o ruchu w Warszawie, o wycenach akcji w Nowym Jorku, o przepisie na buraki, nie wiem na co, przepraszam, skąd mi te buraki przyszły do głowy.

Karol
Bo o kuchni dużo rozmawialiśmy. Bo ja zacząłem o cebuli na początku.

Michał
O cebuli, tak, dlatego te buraki. Ale co by było, gdyby ten companion, ten twój doradca, ten twój asystent był spersonalizowany dla ciebie, dla konkretnej potrzeby? Czy my będziemy chcieli z nim rozmawiać? Brzmi to awkward dzisiaj, mówiąc zupełnie szczerze. Może nie.

Karol
Wiesz dlaczego nie? Znaczy, wiesz, my trochę żyjemy, Michał, w bańce też. Ale ja obserwuję coś takiego, że dziecko podchodzi do rodzica i mówi: „tata, a chatbot powiedział”.

Michał
Tak, ale…

Karol
A na targach w Szanghaju robotycznych, wiesz, kto wchodzi za darmo na targi robotyczne? Dzieci? Oczywiście.

Michał
A to ja ci powiem z drugiej strony. Ty mówisz o dzieciach, a ja zwrócę ci uwagę na osoby po drugiej stronie. One na pewno będą gadały.

Karol
Słuchaj, no badania przecież… ludzie samotni w domach starców. Były badania przeprowadzone jeszcze na etapie smart speakerów, Alexy i Google Asystenta, że ludziom żyło się dużo lepiej. To z jednej strony smutne, ale być może, wiesz, odrobina nadziei w tym. Nie czuli się tak samotni, kiedy mieli smart speaker.

Michał
I słuchaj, nie ma w tym nic dziwnego. Oczywiście tutaj trzeba wziąć pod uwagę kontekst społeczny.

Karol
Który, przypominam tylko, był zbudowany całkowicie inaczej, bo tam było uczenie maszynowe.

Michał
Tak, ale też jeszcze myślę, że ty mówisz też o tym, że takie badania pewnie się odbywały oczywiście za kałużą, czyli w Stanach Zjednoczonych, bo tam jest bardzo rozbudowany ten system assisted living, którego my w Polsce tak dobrze nie znamy, chociaż on się też powoli buduje, a w Chinach zupełnie inaczej podchodzi się do współżycia z ludźmi starszymi, można tak to powiedzieć, prawda? To ja ci powiem inny przykład. Moja mama, którą pozdrawiam serdecznie, zaszokowała mnie, powiedziała, że wybrała ten model, nie pamiętam już czego, bo jej Chat GPT odpowiedział. Nie Google. Nie dziwi mnie to zupełnie. Chat GPT. I mama otwiera telekomputer, jak robi przelew, bo musi mieć większe litery ze względu na swój wiek. Ale to jest jej centrum.

Karol
A używa trybu głosowego?

Michał
Tak, tryb głosowy, wiesz, kontakt ze znajomymi, wyprawa do kina, co ona ma kupić, co sobie zamówić w restauracji, jakie są fajne nowe sztuki w teatrze, i ona nie zrezygnuje z tego. Dla niej jest to fajne, bo ona nie musi obsługiwać skomplikowanego interfejsu, tylko sobie gada i sobie siedzi.

Karol
Zresztą się zastanawiam też już…

Michał
Ale jeszcze jeden wątek, bo tutaj znowu zeszliśmy do takiego bardzo prostego companiona, ale zobacz, co by było, gdybyś na przykład miał taką współpracę z tym telefonem. Ja wiem, że się głupio gada do telefonu, ale przecież on mógłby spokojnie zapamiętać twoje maile, może już dzisiaj to zrobić, może sobie zajrzeć w te twoje Teamsy, czy te twoje Google Workspaces, w te twoje dokumenty, w te twoje co tam jeszcze. To jest sparing partner do dyskusji dla mnie, fajnej. On jeszcze trochę nie ogarnia moich technicznych rzeczy, które ja bym chciał, żeby je ogarniał. I powiem szczerze, że te wszystkie modele, te wszystkie narzędzia, tak sobie się spisują, jak ja mam bardzo specyficzne potrzeby. Ale się spisują już powoli. Więc to jest mój partner, sparing partner do dyskusji. I tych sparing partnerów będziesz miał więcej. Będziesz miał takiego, który cię nauczy gry.

Karol
Jeden będzie chciał mieć sparing partnera, inny będzie chciał mieć terapeutę. Powiedz mi, jaki jestem wspaniały.

Michał
Nie rozmawiać o byciu terapeutą, bo to, jak myślę o Responsible AI, to zaczyna się…

Karol
Nie, ja teraz to mówię jak najbardziej poważnie.

Michał
Ja też mówię o tym poważnie. Tylko wiesz, jakby ten koncept mnie i pociąga, i przeraża. Mnie przeraża. Absolutnie. Natomiast pociąga w tym sensie, że ludzie już tak korzystają z tych narzędzi, co pokazywał sam Altman w analizach tego, co oni robią.

Karol
Michał, co pokazuje? Kiedyś ktoś do mnie zadzwonił i powiedział: „Dzięki czatowi GPT wyszedłem z depresji.”.

Michał
Ale tych przykładów jest bardzo dużo. Natomiast wiesz co, ja nie chciałem o tym mówić w kontekście terapii. Oczywiście doszliśmy do tego, bo jest to naturalne też i ludzie tak z tego korzystają, ale jest wiele bardzo przestrzeni, w której właśnie zbudujesz sobie takiego asystenta. Czy to brzmi dziwnie? Brzmi. Ale 10 lat temu pewnie koncepcja Chata GPT też brzmiała dziwnie i przerażająco, a dzisiaj widać, jak bardzo rośnie liczba użytkowników tego typu rzeczy. Ja ci powiem jeszcze jedną rzecz. Dla mnie to, co stanie się z rynkiem e-commerce, to jest absolutne szaleństwo. Jeżeli moja mama pyta się Chata GPT, a nie Google, a nie Allegro, co chce kupić, to na miejscu platform e-commerce’owych czułbym się lekko zagrożony tym, gdzie będzie mój interfejs zakupowy.

Karol
No i też pytanie jest jedno, naprawdę kolejny odcinek: AI i anegdota. Też się nad tym zastanawiałem, kiedy w modelach zacznie się reklama.

Michał
Znaczy ona, to tak naprawdę wiesz, sam doskonale wiesz, że ona się nie musi zaczynać. Ona może już tam być.

Karol
Wiem, no bo dużo się mówi o treściach SEO, SEM tak przygotowywanych, no ale zobacz, płacę za mój model i chciałbym w założeniu, żeby on był obiektywny. On jest obiektywny na podstawie treści w internecie, które są składnikiem naleciałości całego SEO, SEM. Siłą rzeczy nieobiektywne, prawda?

Michał
I są nieobiektywne. Kurczę, temat. Ale słuchaj, jest taki, mówiliśmy o różnych dziwnych, starych nazwach, jest nowa nazwa pewna, skrót AIBA.

Karol
AIBA, AIBA. Tak, tak jest. O co chodzi?

Michał
A właśnie, właśnie, bo zapomnieliśmy. To nie jest nowy, bo właśnie, to już trzeci raz w Katowicach, 8-10 października, zapraszamy. My chcemy zbudować miejsce, w którym można rozmawiać o tym kontekście, nie lubię tego słowa, AI.

Karol
Dobra, to nie, to Michał, to straight to the point. Bo jest mnóstwo meetupów, spotkań, konferencji, kongresów, będzie za chwilę Kongres Ekonomiczny Sztucznej Inteligencji, potem będzie Sympozjum Sztucznej Inteligencji, a potem będzie 15 innych paneli. Czym się różni wasza impreza i dlaczego warto na nią przyjechać?

Michał
Zapraszamy ludzi z całego świata i to nie jest dowcip, tylko są ludzie zewsząd: ze Stanów, z Azji, z Europy, z różnych części. To jest po pierwsze, różne perspektywy. Perspektywa produktowca, UX-owca, prawnika, inżyniera, data scientisty, więc bardzo różne profile osób. Nie ma jednej technologii dominującej, rozmawiamy o bardzo różnych technologiach na różnych etapach rozwoju, to jest trzecia rzecz. I czwarta rzecz, staramy się pokazywać case’y, jak najwięcej case’ów realnych, udanych i nieudanych.

Karol
To znaczy nie robicie czegoś takiego: „nikt nie może dać wam tyle, ile ja wam mogę obiecać”, tylko pokazujecie…

Michał
I co eksplorują. Co nie znaczy, że wszystko się skomercjalizuje, Karol, bo to też wszyscy myślą dzisiaj o komercjalizacji, bardzo dobrze, ale rozwój też polega na tym, że ileś razy upadasz, żeby przy jednym razie ci się udało. Oczywiście. Próbujemy robić.

Karol
To po poprzedniej AIBAie coś się okazało prawdą, co się nie udało? Masz jakiś taki przykład?

Michał
Tak, oczywiście. Na poprzedniej AIBAie rozmawialiśmy bardzo dużo o tworzeniu tych wszystkich co-pilotów, asystentów, i dopiero wchodził temat agentowy. Mija rok i wszyscy mówią o agentach. Mam wrażenie, że dużo mu się mówi, bardzo mało buduje, jeszcze mało wchodzi do produkcji. Od tamtej pory powstała cała masa technologii i myślę, że żyjemy w bańce, tak jak powiedziałeś, bo powstała cała masa technologii, której bardzo wiele osób jeszcze nie umie używać. I myślę, że jeszcze jedna rzecz się wydarzyła od tamtego czasu. Dalej pewne koncepcje brzmią prosto. Dalej RAG brzmi prosto, dalej Agentic RAG brzmi prosto, i tak dalej. Tylko zrobienie prostego RAG-a jest proste, zrobienie dobrego RAG-a jest trudne. I dzisiaj, ciągle, mija rok i dzisiaj mamy bardzo wiele podejść, koncepcji, prób i tak dalej, i bardzo wiele błądzimy. Czyli wydawało nam się pewnie, że po tym roku będziemy mieli dużo standardów i w zasadzie już ten AI za nas wszystko zrobi. Ciągle bardzo tych standardów nam brakuje, mimo że mamy bardzo dużo wzorców, i ciągle jest to trudne.

Karol
A jak wybieracie ludzi, którzy mają tam mówić?

Michał
Mamy otwarte CFP, absolutnie, i w tym roku w tym CFP pojawiła się bardzo duża liczba propozycji właśnie od różnych osób z całego świata. Mamy dwa właściwie CFP, bo mamy i biznesowe, i techniczne, to jest po pierwsze. Po drugie, mamy wewnętrzną taką radę, która ocenia jakość tych sesji. Patrzymy na profil ludzi, na to, jakie mają doświadczenia, i na sesję, którą zaproponowali, staramy się zbalansować role, tematy i nie powtarzać wątków, które są, więc to dobieramy. I jednak staramy się też nie wpływać absolutnie na treść tego, co będzie pokazywane, ale dobierać osoby, które rzeczywiście mają ciekawy case do pokazania, więc jakaś tam walidacja następuje. No tak jak powiedziałem, zależy nam bardzo na różnych perspektywach, więc jest istotna dla mnie perspektywa, kto na jakim rynku pracuje, w jakim obszarze pracuje, u jakiego vendora pracuje, żebyś nie widział tylko jednej perspektywy.

Karol
Czyli fajnie, czyli łączysz i biznes, i technologię pod jednym dachem, bo przypuszczam, że to wzięło się z twojej obserwacji, być może, która jest podobna do mojej, że jedno z drugim trudno się dogaduje.

Michał
To zawsze, ale jedno bez drugiego nie istnieje. A wiesz, jeszcze po trzecie, można mieć bardzo szalone pomysły biznesowe, ale one gdzieś muszą być też osadzone w jakichś technologicznych możliwościach. I w drugą stronę, możemy mieć najciekawsze technologie, ale jak nie umiemy ich zastosować i zbudować dla realnego przypadku biznesowego, to też nic z tego nie będzie.

Karol
Program znasz, czego najbardziej się nie możesz doczekać?

Michał
Wiesz co, ja się znowu nie mogę… Ja bardzo chcę zobaczyć ludzi, którzy budują produkty. Powiem ci dlaczego, bo czym innym jest zbudować projekt wewnątrz organizacji, a czym innym jest zbudować produkt, który dotyka wielu ludzi. Więc chcę zobaczyć, co pokazują koledzy z Monday, co pokażą koledzy i koleżanki z Mety, co pokażą koleżanki i koledzy z Microsoftu, a chcę to zobaczyć i chcę zobaczyć te najfajniejsze, najciekawsze case’y. Tego się nie mogę doczekać, ale myślę, że najwięcej to znowu będzie tak, że konferencja to jest jedno, ale ta interakcja między ludźmi, która się działa w tamtym roku i która była bardzo żywa. Ludzie w tym roku wrócili jako już nie speakerzy, ale uczestnicy, byli speakerami, bo im brakuje właśnie tej wymiany doświadczeń. To jest wartość. Druga rzecz, której się nie mogę doczekać, to są wszelkiego rodzaju właśnie kuluarowe rozmowy w danych obszarach. Będzie dużo UX-owców. Ktoś może pomyśleć, co jest ciekawego w UX w obszarze AI?

Karol
A wiesz, co ja powiedziałem właśnie ostatnio? Nie wiem. Nie wiem, bo wiesz, ja mam takie różne myśli dziwnej treści. Wiesz, ja jestem bardziej obserwatorem niż kimś, kto tworzy. Doszedłem do wniosku, mieliśmy z Marcinem Sawickim rozmowę, że tak samo jak sporo pojawia się haseł, że humaniści będą w cenie, to skoro można tak szybko zakodować, tak szybko stworzyć produkt, to jeszcze bardziej cenny będzie dobry CX i UX. I właśnie umiejętność zadawania pytań, obserwacji i definiowania potrzeby, która jest po drugiej stronie, którą potem przełożysz na język, który zrozumie maszyna.

Michał
No i widzisz, to jest temat, o którym moglibyśmy też znowu porozmawiać, bo UX to jest i wygląd, i doświadczenie, i informacja, gdzie ta maszyna występuje, to jest jakby cały obszar eksperymentów. Dużo badań się w tym zakresie dzieje i myślę, że UX absolutnie nam się zmieni tego, co my dzisiaj…

Karol
Macie sesję dotyczącą UX?

Michał
Absolutnie, i tutaj będą właśnie, dlatego to mnie bardzo cieszy, bo będą osoby, akurat z Microsoftu tak wyszło, które rzeczywiście pracują nad branżowymi rozwiązaniami w obszarze UX, ale będzie też koleżanka z Uniwersytetu Brytyjskiego, która prowadzi prace naukowe na temat UX właśnie w obszarze AI-owym. Więc tych UX-owców będzie cała grupa z różnych części świata. Ja zastanawiam się też nad wątkiem kulturowym. Wątek kulturowy UX w kontekście AI, bo on wcale nie jest pozbawiony sensu. Ja wiem, że świat dzisiaj jest globalną, amerykańską bańką z dominującym jednym językiem, ale to nie jest prawda. Jak się pojedzie do rzeczonych Chin, czy do krajów arabskich, czy do Indii, czy do Ameryki Południowej, ta kulturowość jest jednak inna i na to trzeba być wrażliwym.

Karol
No ale modele chińskie, jak generują obrazy, to przynoszą ten kontekst swój kulturowy i obrazy na ścianach wyglądają tak, jak byłyby zakorzenione w tamtej kulturze.

Michał
Dokładnie tak, więc to jest też bardzo ciekawe. Na pewno są UX-owcy, drugi taki temat, którego się też podnosi, ale nie tak bardzo. Adopcja, ogromny temat adopcyjny i będą ludzie, którzy zajmują się adopcją na uniwersytetach, w jednostkach publicznych itd. Bo fajnie jest sobie mówić o bardzo fajnych koncepcjach technologicznych. Jeżeli twoi użytkownicy nie potrafią tego użyć, to cała technologia może trafić do kosza. Jest bardzo fajna, jest bardzo nieużyteczna. Jak prowadzić adopcję, jak prowadzić szkolenia, jak budować rozwiązania i słuchać feedbacku użytkowników, jak wprowadzać pętlę zwrotną, czyli słucham feedbacku i poprawiam. Będą sesje na ten temat. Bezpieczeństwo, masz kolejny wątek, bardzo, bardzo duży. I nie chodzi tylko o prompt injection i wszystkie techniki techniczne, znaczy metody techniczne, tylko chodzi o to, jakie realne zagrożenia wynikają z pewnego nieumiejętnego zastosowania technologii, na które dzisiaj nie jesteśmy w ogóle gotowi. Tak, o wielu rozwiązaniach.

Karol
Jedno spotkanie, jedna osoba, jeden gość, na którego czekasz najbardziej?

Michał
Oj, nie, nie będę wymieniał. Na wszystkich czekam. Naprawdę, zupełnie szczerze, bo możesz w to wierzyć, możesz w to nie wierzyć, to jest prawie dwa miesiące pracy samego przeglądania tych wszystkich rzeczy. To jest prawie cały rok pracy, żeby to wszystko zorganizować, pospinać. Poza tym, wiesz, mamy bardzo duży rozstrzał i ja to traktuję jako wartość, a nie jako wadę. Czyli na przykład będzie Peter Kowalczuk, który całe życie spędził, mówiąc szczerze, wydobywając ropę po całym świecie. Ukrainiec, który mieszka dwadzieścia parę lat w Stanach, wykształcony w Stanach i tak dalej, całe życie, że tak powiem, wiercił ropę. Od sześciu czy siedmiu lat zajmuje się tematem technologii, tematem też AI, machine learningu i tak dalej. Co Peter będzie pokazywał? Jak jego spółka pomaga optymalizować pewne procesy wydobywcze i pewne procesy planowania wydobywania materiałów tak jak ropa, a nie tylko, z użyciem tego typu technologii. A bardzo ciekawe rzeczy, na przykład jak analizujesz log, w którym zapisujemy informację o tym, jak wiercisz w danym korytarzu ropę i używasz tych informacji do tego, żeby optymalizować kąt prowadzenia tego odwiertu, żeby nie uszkodzić swojego wiertła, a żeby dokładnie trafić w miejsce, w które chcesz.

Karol

Bo zakładamy, że wiertło kosztuje pewnie kilkadziesiąt tysięcy.

Michał
Samo wiercenie jest procesem, nie chcę powiedzieć krótkim, bo znowu ktoś powie: „Michał, nie znasz się”, ale czas potrzebny do przygotowania się do wiercenia versus wiercenie to są naprawdę inne jednostki czasu, plus tak jak powiedziałeś, koszty są gigantyczne, no i czas, czas tutaj gra ogromną rolę.

Karol
I jakość. Czyli widzimy się, którego?

Michał
Ósmy, dziewiąty i dziesiąty jest dzień dodatkowy, października. Środa, czwartek, piątek.

Karol
Katowice.

Michał
Katowice, Muzeum Śląskie, a więc dobra lokalizacja w Katowicach. Cała konferencja po angielsku. No i co? Od rana do wieczora AI, chmura, nowe technologie.

Karol
Czyli co? Do zobaczenia w Katowicach?

Michał
Do zobaczenia w Katowicach, zapraszamy.

Karol
Widzimy się koniecznie.