AI — Jakub Ćwirlej

Gra w czytanie: gdy czytasz równo, robot zjada linię kodu tej strony i zbiera punkty; zbyt szybkie lub nierówne przewijanie sprawia, że gubi znaki. Ozdoba — nie wpływa na tekst.

…Nie posiadam żadnego formalnego wykształcenia w zakresie programowania i szkolenia LLM.

Tworzeniem aplikacji i treningiem AI zająłem się przez kompletnie dziwny zbieg przypadków, który z dzisiejszej perspektywy wydaje mi się jednak mieć sporo sensu. I, jak sądzę, mówi to coś ważnego o naszych czasach. Nie planowałem tego, nie sądziłem, że kiedykolwiek mogę mieć z technologią więcej wspólnego niż przeciętny użytkownik iPhone'a. Przez lata moim jedynym oknem na świat Big Tech był podcast Hard Fork. Pozdrowienia dla Caseya i Kevina :)

Wszystko zaczęło się od vibecodingu i aplikacji OrsonAI. Bawiąc się sztuczną inteligencją, zacząłem tworzyć narzędzia, które mogłyby być mi pomocne w mojej codziennej pracy dziennikarskiej. Zapisywanie wywiadów w formie tekstu w trakcie nagrywania i importowanie ich do edytora, czy tryb edycji pozwalający konsultować z czatem wybrane fragmenty tekstu bez konieczności nawigacji między oknami i przeklejania całego kontekstu, to na tamten moment były naprawdę fajne narzędzia, które wydatnie przyspieszały moją pracę.

Z czasem zacząłem myśleć o tym jak o projekcie, jak o czymś, co mogłoby służyć też innym. Idea była prosta: wykorzystać udogodnienia, które pomagają mi zaoszczędzić czas, i stworzyć produkt dla osób napotykających te same problemy. Poświęciłem dużo czasu na stworzenie interfejsu i mechanizmów, które mogłyby zapewnić bezpieczne AI dla redakcji – takie, które pomaga dziennikarzowi, ale go nie wyręcza. Zaprojektowałem nawet system przyznający certyfikaty ludzkiego autorstwa tekstu, publikowany na publicznym ledgerze Hedery Hashgraph. Niezmienny dowód o wartości świadectwa sądowego, wskazujący, jak powstawał tekst i jaki był udział człowieka przy jego tworzeniu.

Tutaj znajdziesz opis technologii HDKTutaj możesz pobrać darmową bibliotekę HDKHDK na Hugging Face

Spotkało mnie jednak spore rozczarowanie. Przyjęcie przez osoby z branży, którym pokazywałem aplikację, było więcej niż chłodne. Pytanie, które powracało na koniec każdej prezentacji, boleśnie uświadamiało mi, jak bardzo się myliłem: „Czemu ktoś miałby płacić za twoją aplikację, skoro mamy darmowego ChatGPT?”. Kwestie certyfikatu ludzkiego autorstwa, ochrony danych czy nawet znacznego usprawnienia pracy ponad to, co oferował zwykły chatbot, nie były istotne. Słyszałem to od ludzi podkreślających na co dzień wagę rzetelnego dziennikarstwa.

Praca nad aplikacją i systemem agentycznego AI, który będzie wystarczająco niezawodny, żeby mógł służyć w redakcjach informacyjnych, popchnęła mnie jednak w zupełnie nowym kierunku. Starając się lepiej zrozumieć, skąd biorą się halucynacje modeli językowych, zacząłem czytać prace naukowe publikowane na arXiv, a w końcu zaprojektowałem i przeprowadziłem serię badań związanych z aktywacją bramek SwiGLU na kilku otwartych modelach językowych. Wnioski z tych badań opisałem w kilku pracach, które zamieściłem na ResearchGate. Choć z dzisiejszej perspektywy niektóre tezy tamtych prac wydają mi się megalomańskie, a sam tekst wymagałby pewnie poprawy i bardziej naukowego słownictwa, nie usuwam ich – choćby ze względu na uczciwość badawczą.

Tutaj znajdziesz moje prace na ten temat

Dziś, mając więcej pokory zdobytej na poligonie szkolenia modeli językowych, po wielu nieudanych eksperymentach i rozczarowaniach, pisząc o znalezionych sygnałach GSI, mówiłbym raczej o sygnałach proxy wiedzy niż o "epistemicznej świadomości" modelu. Z drugiej strony, na podstawie twardych danych udało mi się zaobserwować, że konfabulacja to w dużej mierze proces dwuetapowy, w którym model – nie mając oparcia w faktach – niemal zawsze wybiera spójność formy kosztem prawdy. To był dla mnie osobiście najciekawszy moment tych eksperymentów: chwila, w której moje dawne zainteresowania filozofią i epistemologią znalazły niespodziewane, w pełni mierzalne odzwierciedlenie w architekturze transformerów. Osobną kwestią pozostaje jednak codzienna użyteczność tych sygnałów w warunkach produkcyjnych. Porównanie ich skuteczności przy wykrywaniu halucynacji z innymi wykorzystywanymi metodami wymagałoby z pewnością dodatkowych badań.

To zadanie pochłonęło mnie bez reszty. Być może jest to trochę zgodne z moim charakterem – lubię angażować się w zajęcia, które stanowią wyzwanie, ale też pozwalają mi nauczyć się czegoś o otaczającym mnie świecie i lepiej go zrozumieć. Zresztą, zanim zająłem się dziennikarstwem, studiowałem filozofię, szczególnie interesując się filozofią nauki i epistemologią.

Tutaj znajdziesz esej podsumowujący niektóre moje przemyślenia

Szkolenie mojego własnego modelu skończyło się totalną katastrofą. Popełniłem prawdopodobnie wszystkie możliwe błędy, i to mimo nawyku do solidnego researchu oraz pochłonięcia olbrzymiej ilości fachowej literatury. Pierwsze efekty wydawały się obiecujące, ale dopiero po czasie zrozumiałem, że były one w dużej mierze zasługą regularyzacji szumem. Przewaga modelu w testach ablacyjnych nie opłacała się w zestawieniu z dodatkowym narzutem obliczeniowym (compute) związanym z obliczaniem Gini aktywacji bramek. Doszły do tego również wyzwania czysto techniczne związane z treningiem. Moje modyfikacje wyjęte spod normalizacji hamowały efektywne uczenie, natomiast zastosowanie normalizacji powodowało ich spłaszczenie, czyniąc z modelu standardowy, ale droższy w treningu transformer. Szczegóły architektury udostępniam do pobrania tutaj – być może ktoś znajdzie w tym użyteczny materiał do nauki na cudzych błędach.

Rozwiązaniem, które mimo wszystko moim zdaniem zasługuje na uwagę, jest bramka M2. Dzięki afinicznej kotwicy pozwala ona zachować działanie w oparciu o funkcję sigmoid bez ryzyka ściągnięcia w dół przez leniwy optymalizator szukający łatwej drogi do obniżenia straty treningowej. U mnie ta bramka, uczona na sygnałach Gini aktywacji, miała za zadanie ciąć szumy przy generacji przez model. Jednak wyjęcie sygnału spod normalizacji – jak wspomniałem wcześniej – prowadziło do modelu o przesadnym rozkładzie pewności; sprawniejszego logicznie, jednak de facto gorzej uczącego się faktów. Być może to rozwiązanie mogłoby przydać się w innych modelach do bramkowania innych elementów i pomóc w procesie treningowym.

Wszystkie moje porażki związane z trenowaniem modelu według własnej architektury uznałem ostatecznie za kapitał, którego nie należy marnować. Dziś szkolę swój własny, mały model EUGEN 160M, który specjalizuje się w kodzie. Porównując jego dotychczasowe wyniki benchmarkowe, jestem ostrożnym optymistą i zakładam, że nie będzie to stracony czas. Zdecydowałem się na szkolenie modelu specjalizującego się w językach backendowych, ponieważ w przypadku tego typu architektur łatwiej jest monitorować postępy, a sam model może być użytecznym narzędziem autouzupełniania (autocomplete) do wykorzystania w inferencji na zwykłym CPU. Model można przetestować w specjalnie przygotowanym terminalu na mojej stronie oraz porównać go z innymi otwartymi rozwiązaniami o podobnych rozmiarach.

Tutaj możesz przetestować model Eugen 160M

Dotychczasowe wyniki to przede wszystkim zasługa rygorystycznego śledzenia postępów i błędów popełnianych przez model w czasie generacji. Dzięki temu byłem w stanie na bieżąco interweniować, dodając dane treningowe wzmacniające model tam, gdzie pokazywał słabości. Stosowałem też regularnie techniki STaR i LEMA, tworząc dane syntetyczne na podstawie tego, co wygenerował sam model, oraz dane translacyjne uczące model logiki kodu poprzez pokazywanie mu przykładów tłumaczeń między Pythonem a C++, Javą i Rustem. Wszystkie te materiały stanowią obecnie około 0,35% całego zbioru, a ich udział będzie stopniowo zwiększany w miarę postępów treningu.

Praca nad szkoleniem modelu sprawia mi wiele frajdy i – podobnie jak wcześniej dziennikarstwo – daje mi poczucie, że robię coś ważnego; coś, co pozwala mi lepiej uchwycić przemiany w świecie, który mnie otacza. Nie stworzę sam złożonego kodu w C++ od zera, to fakt, ale staram się zrozumieć logikę procesów. W ten sposób odnoszę drobne sukcesy, które pozwalają mi posuwać się naprzód w mojej pracy. Tak – przy pomocy kodującego agenta AI stworzyłem własny kernel w Tritonie, który pozwala trenować rzadki model, poprawiając TPS (Tokens Per Second) o 23% względem modelu gęstego; kolejne optymalizacje kernela dały dalsze 36%. Zamierzam to rozwiązanie wykorzystać przy szkoleniu kolejnego, nieco większego modelu.

Kernel możesz pobrać tutajKernel na Hugging Face

A wracając do modelu, od którego wszystko się zaczęło... Dziś widzę, że moim największym błędem nie była naiwność inżynieryjna. Ten model po prostu nie miał prawa działać tak, jak zakładałem. Problem nie był technologiczny, lecz czysto filozoficzny. I jako ktoś, kto studiował filozofię, powinienem był to wyłapać na samym początku, mając w pamięci definicję prawdy Tarskiego i twierdzenia Gödla. Zgodnie z nimi żaden dostatecznie złożony system nie potrafi w pełni dowieść własnej spójności, ani zdefiniować prawdy wyłącznie z poziomu samego siebie. Próba zmuszenia modelu do analizowania, oceny i korygowania swoich własnych stanów wewnętrznych w czasie rzeczywistym zamykała go w strukturalnej pętli, z której – bez metapoziomu i zewnętrznego punktu odniesienia – po prostu nie było wyjścia.

Kiedy zaczynałem tę przygodę, chciałem po prostu stworzyć narzędzie ułatwiające spisywanie dziennikarskich wywiadów. Bardzo szybko okazało się jednak, że wejście w świat sztucznej inteligencji to prawdziwy skok do króliczej nory z „Alicji w Krainie Czarów” – im głębiej schodzisz, tym bardziej wszystko staje się złożone, wielowarstwowe i fascynujące. Moja pierwsza aplikacja może nie zrewolucjonizowała rynku mediów, ale ten lot w dół nory doprowadził mnie do miejsca, w którym z powodzeniem trenuję własną architekturę. Przeszedłem długą drogę od biernego słuchacza technologicznych podcastów do człowieka, który fizycznie kształtuje parametry modeli i rozumie, co dzieje się wewnątrz.

Jeśli masz jakieś pytania, chętnie odpowiem.

Gra w czytanie: gdy czytasz równo, robot zjada linię kodu tej strony i zbiera punkty; zbyt szybkie lub nierówne przewijanie sprawia, że gubi znaki. Ozdoba — nie wpływa na tekst.

1. Wszelkie kalkulacje robione na sucho zawsze będą zbyt optymistyczne

Kiedy myślimy o szkoleniu modelu, naturalnie na myśl przychodzi nam proces uczenia maszynowego – praca, którą wykonują za nas potężne klastry Nvidii w centrach danych, lub jeśli mamy więcej szczęścia, nasza własna piekielnie mocna stacja robocza. Czytając specyfikację, łatwo zapomnieć o tym, że realne MFU (Model FLOPs Utilization) jest dużo niższe, niż sugerowałyby materiały marketingowe producenta kart. W zależności od architektury i szczegółowości, sprzęt pozwoli ci wycisnąć z krzemu zaledwie ułamek mocy obliczeniowej. Cóż z tego, że karta liczy w FP4, jeśli w treningu modelu bazowego od zera nie będzie to działać stabilnie, albo przy szerokości twojego modelu zejście poniżej BF16 nie daje żadnych korzyści.

Moment, w którym zdajesz sobie sprawę, że nie jesteś w stanie wytrenować modelu, który planowałeś, w zakładanym czasie, ani nawet w przybliżonych rozmiarach, nie należy do łatwych. Zwłaszcza, jeśli poświęciłeś tygodnie na to, żeby dojść do miejsca, w którym możesz zacząć trening i nagle okazuje się, że cały plan był nierealny. Przecież na papierze wszystko się zgadzało! Pierwszy odruch to szukanie metod optymalizacji – torch compile, autocast, flash attention, FLCE, głowice i minibatch dopasowane wielkością do preferencji CUDA. To wszystko działa, ale fizyki krzemu nie oszukasz. Jeżeli trenujesz mały model, jego mała szerokość będzie działać przeciw tobie. Jeżeli nie stać cię na trening dużego modelu, nie stać cię też na wyciągnięcie maksimum ze swojego GPU. Dojście do momentu optymalnego wykorzystania karty może zająć dni, a finalny spadek TPS (Tokens Per Second) w treningu o 30-40% względem początkowych kalkulacji to różnica dni, czy wręcz tygodni pracy karty.

2. Startuj zawsze od jak najmniejszej skali, która jest w stanie zwalidować twoje pomysły

Mój pierwszy model miał 1.5B parametrów i byłem w stanie go wytrenować zaledwie do trzech Chinchilla. Przy jego budowie popełniłem wiele błędów, ale mimo wszystko działał. O jego znikomej użyteczności zadecydowało przede wszystkim niedotrenowanie. Gdybym z tym samym budżetem zdecydował się szkolić model 10-krotnie mniejszy, mógłbym pochwalić się modelem dobrze wytrenowanym i użytecznym. Miałbym czas na testy i uniknąłbym z pewnością wielu błędów, co pozwoliłoby mi zbudować lepszą architekturę. Oczywiście rozmiar ma znaczenie, ale jeszcze większe znaczenie mają dane, architektura i wydajność obliczeniowa. Szanse, żeby zaprojektować dobry model na podstawie literatury, bez testów i bez pomyłek, są bliskie trafieniu w totolotka.

3. Model nie trenuje się sam

Trenowanie modelu brzmi fajnie, ale jest dużo bardziej nudne, niż może się wydawać. W rzeczywistości to w większości proces polegający na ciągłym projektowaniu badań, przeprowadzaniu pomiarów, analizie wyników modelu i szukaniu rozwiązań problemów, które pojawiają się w trakcie. Cały czas, na okrągło, dzień po dniu. Jeśli nie potrafisz czerpać satysfakcji z małych odkryć i drobnych sukcesów może się okazać zbyt nudne. Tymczasem to właśnie żelazna konsekwencja w przeprowadzaniu pomiarów decyduje o wszystkim. Nawet przy prawidłowo dobranych parametrach treningu z czasem może okazać się, że nasz model potrzebuje nowych danych lub degraduje w sposób trudny do wychwycenia na pierwszy rzut oka. Tego nie zauważysz bez dobrego monitoringu i ciągłych testów, a im rzadziej je robisz, tym więcej czasu stracisz, jeśli model zacznie zachowywać się w sposób niepożądany.

Weźmy pod uwagę jeden z częstych scenariuszy. Po kilku dniach treningu orientujesz się, że model zaczyna odpowiadać coraz krócej i jest przy tym coraz bardziej pewny siebie. Loss i zbiór held-out wyglądają dobrze, ale z modelem dzieje się coś nie tak. Jeśli na bieżąco analizujesz normy i porównujesz codziennie odpowiedzi modelu z tymi z wczoraj, możesz szybko wyłapać wzrost logitów i zorientować się, że model przypisuje coraz większe prawdopodobieństwo określonym tokenom. Ta arogancja to sztuczka leniwego optymalizatora – AdamW znalazł sposób na to, żeby nas oszukać i zamiast uczyć model, zmniejsza stratę w inny sposób. Jeśli wyłapiesz to po kilku dniach, możesz stracić kilkadziesiąt dolarów; jeśli puszczasz trening, licząc, że jednostka Nvidii po prostu wykona całą pracę, możesz wydać setki, czy tysiące a model może być już niemożliwy do uratowania.

Sam spędziłem tygodnie, obserwując, jak Adam pompuje normy moich modeli, obniżając efektywny learning rate (LR), i to pomimo nałożonej normalizacji QK-norm i weight decay 0.1. Trening zwalniał, doprowadzając mnie do rozpaczy, bo jak wiemy, działa tu prawo Pitagorasa i rosnący wektor wag coraz trudniej obracać stałym LR. Sprawa jest dobrze opisana w literaturze, ale dopóki sam tego nie zobaczysz, nie zrozumiesz, dlaczego lepiej zastosować inny optymalizator. W końcu AdamW pomógł wytrenować setki modeli. Ja zdecydowałem się ostatecznie na MuonH i to była jedna z lepszych decyzji, jakie podjąłem. Oczywiście wiele tego typu rzeczy można wyciągnąć z literatury, podręczników czy śledząc prace naukowe publikowane na arXiv, ale nigdy nie wiesz, jak to zadziała u ciebie. Wiele rozwiązań, które teoretycznie powinny przynieść dobrze udokumentowane korzyści, u mnie nie zadziałało. Nie przekonasz się, dopóki sam nie sprawdzisz, a żeby się przekonać, trzeba trzymać rękę na pulsie i na bieżąco śledzić postępy.

4. Wprowadzaj zawsze tylko jedną zmianę i rób testy ablacyjne

Przez ostatnie miesiące przetestowałem setki małych modeli – zarówno klasycznych transformerów, jak i moich własnych pomysłów... i dziś wiem, że testowałem za mało. Chcąc iść do przodu zbyt szybko, niepotrzebnie traciłem czas. Ilość warstw, FFN ratio, d_model, wiązanie wag, wielkość głowic, ilość głowic KV, batch, optymalizator, rekurencja, rzadkość (sparsity), dane treningowe – czynników, które mają wpływ na zachowanie modelu, są dziesiątki, a możliwe kombinacje dają tysiące możliwych architektur. I choć z grubsza wszystko działa tak, jak można by się spodziewać po przeczytaniu pierwszego podręcznika na temat inżynierii AI, tak długo jak sam nie przetestujesz swojej architektury, nie będziesz wiedział, gdzie jesteś. Tymczasem drobne zmiany często potrafią prowadzić do dużych różnic w wydajności obliczeniowej i benchmarkach i to przy tym samym datasecie oraz wielkości batcha. Jeżeli nie wprowadzasz zmian w sposób izolowany, łatwo się w tym pogubić. Sam popełniłem ten błąd wiele razy. Nie chodzi o to, że poprawki były złe. Choć często były. Prawdziwy problem polegał na tym, że kiedy rzeczywiście robiłem krok do przodu, nie byłem w stanie powiedzieć, której zmianie to zawdzięczam.

5. Zacznij od danych

Hugging Face ma niewyobrażalny zasób danych treningowych jak na potrzeby treningu małego modelu. Mogłoby się wydawać, że jeśli te dane są na wyciągnięcie ręki w ilościach przekraczających znacznie potrzeby jakiegokolwiek garażowego projektu, to sprawa jest załatwiona. Jednak dobór danych ma dużo większe znaczenie, niż mogłoby się na początku wydawać. I fakt, że zostały już one zebrane w gotowe datasety, wcale sprawy nie ułatwia. Dochodzi też kwestia wybrania właściwego tokenizera, języków, których chcemy nauczyć model, czy proporcji. Na przykład decyzja ile procent danych ma stanowić kod, ile matematyka, a ile język naturalny. Następnie w jakich domenach ma się specjalizować nasz model. Im głębiej w las, tym więcej możliwości. Ja sam musiałem przygotowywać swój dataset od zera aż 3 razy. Zaliczyłem też kilka mniejszych wpadek, jak przeciek szablonu instruct, którego nie wyłapałem na etapie przygotowywania danych. Każda taka pomyłka wymuszała cofnięcie treningu o godziny czy nawet dni.

6. Nie oczekuj zbyt wiele

Widząc, jak duże i mniejsze laboratoria co chwilę przesuwają granice tego, co potrafi AI, nietrudno ulec wrażeniu, że wytrenowanie użytecznego modelu to w zasadzie prosta sprawa. Są jednak powody, dla których to przesuwanie granic kosztuje miliardy dolarów. To, że Twój model zaczyna mówić ludzkim głosem czy osiąga dobre wyniki w popularnych benchmarkach, nie mówi nic o jego finalnej jakości ani użyteczności. Modele bardzo szybko uczą się na początku, w pierwszych dniach treningu, ale walka o każdy kolejny procent w wynikach wymaga sprytu, uwagi i samozaparcia. Szczególnie, kiedy przez wiele dni widzisz, jak model zalicza plateau, czy wręcz się cofa. Poza tym popularne benchmarki niewiele mówią o realnych możliwościach modelu. Twój model może być dobry w Pythonie i robić świetne wyniki w HumanEval i MBPP, ale jeżeli nie ma wiedzy o najnowszych bibliotekach, jego użyteczność w prawdziwym świecie będzie umiarkowana.

7. Uzbrój się w cierpliwość

Wiele umiejętności modeli rośnie skokowo. To dobrze opisane zjawisko grokkingu poprzedza często długotrwałe plateau, które może trwać dniami. Widząc, jak model nie osiąga żadnych postępów, podczas gdy ty za każdą godzinę treningu musisz płacić dolarami za wynajem mocy obliczeniowej czy choćby za sam prąd, nietrudno o chwilę zwątpienia. Myślisz: "Model osiągnął capacity, więcej się nie nauczy", albo "Duże laboratoria, które trenują do 1000x Chinchilla, pewnie stosują jakieś triki". Tymczasem umiejętności często rosną skokowo. Wystarczy, że model nauczy się domykać jakąś funkcję i nagle zamiast jednego, w MBPP wskakuje kilkanaście zaliczonych zadań. Często jest też tak, że model robi realne postępy, ale jeśli z powodów oszczędnościowych monitorujesz tylko top1 odpowiedzi zamiast top10, możesz tego przez długi czas w ogóle nie zauważyć. Model musi nauczyć się przypisywać większą pewność, a to wymaga czasu.

8. Jedna karta to za mało

Może się wydawać, że jeśli dysponujesz jednostką H100 czy RTX PRO 6000 (96 GB), to ogranicza cię tylko budżet. Problem w tym, że trening wymaga ciągłych testów i pomiarów, które pomagają zorientować się, na jakim jesteśmy etapie. Dodatkowe GPU może być też potrzebne do generacji dodatkowych danych treningowych. Sam znaczne postępy w treningu modelu uzyskałem, trenując go metodą STaR, polegającą na generacji przez mój własny model dużej ilości zadań i dołączaniu do datasetu tych poprawnych oraz zestawowi danych zawierających przykłady translacji między językami programowania.

Przerywanie treningu na mocnej karcie na czas generacji odpowiedzi przez model jest bardzo kosztowne i zwyczajnie nieopłacalne, a generowanie obok – nawet jeśli pozwala na to VRAM – może stanowić poważne zagrożenie. Ostatnią rzeczą, jakiej pragniesz, jest przekonanie się po trzech dniach, kiedy wyniki modelu pójdą w dół, że podczas generacji na karcie obok treningu doszło np. do chwilowego „głodzenia” loadera, w czego następstwie loss po cichu przestał spadać. Takie rzeczy na późniejszym etapie treningu są często niezwykle trudne do wychwycenia, nawet jeśli masz monitoring ostrzegający cię przed skokami norm.

9. Zacznij od czegoś prostego

Mój pierwszy model zacząłem budować w oparciu o przeczucie, że w treningu llm da się wykorzystać własne aktywacje modelu, a śledzenie ich w trakcie nauki powinno pomóc zbudować inteligentniejszy i bardziej prawdomówny model. Dziś nie mogę się nadziwić samemu sobie, jak naiwne było to podejście. Nie dlatego, że dziś myślę, że to niemożliwe, ale dlatego, że nie mając pojęcia o tym, jak wygląda proces treningu LLM-a, zacząłem eksperymentować z czymś, co mnie przerastało. Musiałem przyswoić olbrzymią porcję wiedzy, a jednocześnie testować rozwiązania związane z architekturą klasycznych transformerów, jak i własne pomysły, które – jak pokazał czas – w dużej mierze były niemożliwe do realizacji.

Natrafiłem przy tym na szereg problemów – sygnał aktywacji bramek SwiGLU poddany normalizacji tracił sens, a bez niej AdamW wykorzystywał moje modyfikacje do pompowania norm modelu. Dopiero po czasie zrozumiałem, że wiele z zalet, które znalazłem w moim pierwszym modelu, pochodziło ze zjawiska przypominającego regularyzację szumem. Na dodatek samo obliczanie Gini z aktywacji bramek SwiGLU było drogie obliczeniowo, nakładając kilka procent dodatkowego compute, czego rezultaty nie zwracały w jakości.

Obecnie trenuję mały model 160M w standardowej architekturze, który specjalizuje się w kodowaniu. To była najlepsza decyzja, jaką mogłem podjąć, bo dałem sobie szansę na stworzenie czegoś, co może być realnie użyteczne. A pierwsze wyniki modelu pokazują, że nauka na błędach nie poszła na marne.

10. Nie buduj modelu, który będzie dobry we wszystkim

Biorąc pod uwagę astronomiczne koszty i samą wykonalność, budowanie modelu ogólnego zastosowania przez pojedynczą osobę bądź małą organizację jest dziś zupełnie bez sensu z powodów czysto ekonomicznych. Konkurencja z gigantami, czy nawet mniejszymi laboratoriami wypuszczającymi otwarte modele, jest nie do wygrania bez olbrzymich nakładów i doświadczenia. Ale to wcale nie znaczy, że budowanie własnych modeli nie ma sensu.

Można wyobrazić sobie setki zastosowań, gdzie małe modele wytrenowane od podstaw lub doszkolone na unikalnych danych, będą miały przewagę nad gigantami – i ta przewaga niekoniecznie musi polegać na wiedzy. Wystarczy, że model będzie szybki i możliwy do uruchomienia lokalnie w przeglądarce, lub na procesorze dowolnej stacji roboczej. Dla konkretnych wąskich zastosowań, dużo bardziej opłacalne może być użycie mikro modelu o wielkości kilkuset milionów parametrów, niż zaprzęgnięcie najpotężniejszych dostępnych OpenAI czy Anthropic. Nie chodzi tylko o koszty. Choć różnica jest kolosalna. Model, który specjalizuje się w wąskim zakresie, nie tylko znacznie łatwiej wytrenować, ale również kontrolować i dostosować do potrzeb użytkownika. Jednak co najważniejsze to zadanie, które nie wykracza poza możliwości zwykłego człowieka, który jest gotowy podjąć takie wyzwanie.

Modele wielkich laboratoriów są trenowane na tysiącach bardzo drogich układów. Dla przykładu: wytrenowanie modelu klasy Llama 3 400B, wymagało klastra 16 000 kart H100. Koszty to dziesiątki milionów dolarów. Wytrenowanie najnowszego GPT Astra prawdopodobnie podniosło poprzeczkę znacznie wyżej. Biorąc pod uwagę, że cały ten sektor rozwija się na kredyt, a implementacja AI na szeroką skalę, przy obecnych kosztach API i kwestiach bezpieczeństwa danych, jest często trudna do obronienia biznesowo, w dłuższej perspektywie można spodziewać się, że małe modele będą odgrywać coraz większą rolę. Małe modele będą też coraz wydajniejsze. Nie zdziwiłbym się, gdyby do większości zadań w przyszłości wystarczył nam model rzędu 7B parametrów. Pęknięcie „bańki AI”, o której coraz częściej zaczyna się mówić w mediach, może ten proces tylko przyspieszyć.

Dlatego uważam, że budowanie małych modeli ma głęboki sens. Po pierwsze, nie ma lepszej drogi do zrozumienia tego, jak działa AI, niż trenowanie własnego modelu. Po drugie, choć w dużych laboratoriach za rozwój AI coraz częściej odpowiada... samo AI, można się spodziewać, że ludzkość, traktując poważnie kwestie bezpieczeństwa, będzie oczekiwać kontroli i ludzkiego nadzoru nad procesem szkolenia. Do tego niezbędne jest zrozumienie, jak ten proces przebiega w praktyce. Oczywiście, wchodząc na LinkedIna, jesteśmy dziś zalewani postami na temat sztucznej inteligencji od najróżniejszych specjalistów oferujących tutoriale i szkolenia. Ale ilu z nich tak naprawdę wytrenowało swój własny model?

Jeśli masz jakieś pytania, chętnie odpowiem.

Gra w czytanie: gdy czytasz równo, robot zjada linię kodu tej strony i zbiera punkty; zbyt szybkie lub nierówne przewijanie sprawia, że gubi znaki. Ozdoba — nie wpływa na tekst.

Jeśli masz jakieś pytania, chętnie odpowiem.

Gra w czytanie: gdy czytasz równo, robot zjada linię kodu tej strony i zbiera punkty; zbyt szybkie lub nierówne przewijanie sprawia, że gubi znaki. Ozdoba — nie wpływa na tekst.

Ten tekst jest jednym z najtrudniejszych, z jakimi przyszło mi się zmierzyć. Jako dziennikarz, a zarazem człowiek, który w domowym zaciszu trenuje własne modele, stoję na dwóch przeciwległych biegunach. Z jednej strony fascynuje mnie czysta inżynieria, z drugiej – mam pełną świadomość, że kwestia bezpieczeństwa sztucznej inteligencji to prawdopodobnie najważniejsze wyzwanie czasów, w których żyjemy.

Zacznę od tego, co osobiście boli mnie najbardziej: od tragicznego spłycenia publicznej dyskusji na temat bezpieczeństwa związanego z AI. To debata pełna sprzeczności i skrajnego emocjonalnego nacechowania. Trudno zresztą, żeby było inaczej, kiedy w grę wchodzą miliardowe interesy i przetrwanie ludzi.

Z jednej strony słyszymy, że AI to śmiertelne zagrożenie, a jej rozwój grozi zagładą ludzkości. Z drugiej – że te apokaliptyczne wizje to tylko cyniczna gra gigantów, którzy chcą podbić wyceny akcji przed ich emisją lub zablokować i utrudnić rozwój mniejszym firmom, by zachować monopol i pierwsze miejsce w peletonie. Zwykły człowiek, który nie ma czasu śledzić tego wszystkiego i oczekuje prostych rozwiązań, może łatwo przejść na pozycje technomaksymalistów lub proroków zagłady. Każda z tych wizji jest taka gładka, taka oczywista... i żadna nie wymaga od nas niczego ponadto. Bo przecież, skoro jesteśmy bezsilni wobec mocy, które nas przerastają, to nie musimy nic robić. W dzisiejszych czasach skrajnego maksymalizmu to bardzo wygodna pozycja.

Co sam odpowiedziałbym mojemu dziecku, gdyby zapytało mnie, czy AI stanowi dla nas zagrożenie? Uciekając od upraszczającego reframingu, musiałbym przyznać, że istnieją trzy możliwości: że faktycznie jesteśmy skazani na zagładę, że ostatecznie do niej nie dojdzie (bo – jak przekonuje Yann LeCun – po prostu nauczymy się tę technologię kontrolować), albo... że ta zagłada już się rozpoczęła. Paradoks polega na tym, że wszystkie te trzy scenariusze mogą być jednocześnie prawdziwe.

To, że najgorsze prawdopodobnie już się zaczęło, wynika z faktu, który rzadko przebija się do głównego nurtu: każda technologia, każdy wynalazek musi trafić na swój czas i odpowiedni grunt, aby w pełni zaistnieć. Energia atomowa – tak często przywoływana w tej dyskusji jako porównanie – w czasach zimnej wojny stanowiła śmiertelne zagrożenie, ale w czasach pokoju stała się źródłem taniej energii, przyczyniając się do boomu gospodarczego. To samo można powiedzieć o większości wynalazków: od obróbki krzemienia, przez dynamit, aż po sztuczną inteligencję.

Nasz dzisiejszy świat stał się niestety miejscem, w którym scenariusz katastroficzny ma wręcz idealne warunki do urzeczywistnienia. Konflikty zbrojne z wykorzystaniem autonomicznej broni, postępująca inwigilacja obywateli przez państwa i korporacje, bezrefleksyjne przyjmowanie przez rządy korporacyjnych standardów w komunikacji ze społeczeństwem – to wszystko tworzy gotową infrastrukturę dla najczarniejszych wizji.

Tymczasem ideologia technomaksymalizmu, która pcha nas w kierunku tych zagrożeń – otwarcie drwiąc ze słabości, stawiając zysk ekonomiczny i brutalną siłę ponad kapitał społeczny i bezpieczeństwo – buduje świat, w którym AI zerwane z uwięzi będzie doskonale prosperować. A wtedy scenariusz katastrofy może być już nie do uniknięcia.

To nie jest nic nowego. Ta dyskusja toczy się w zasadzie od czasów ateńskiej agory, gdzie Platon sprzeczał się z Sokratesem, a ludzka historia pełna jest mrocznych momentów i niesprawiedliwości. To, co dziś dzieje się w polityce w USA, a co dla wielu Europejczyków pachnie faszyzmem, nie jest niczym nowym, jak celnie wskazuje historyk Jon Meacham w książce „The Soul of America”. Siła demokracji polega na tym, że sprawiedliwość – choć nierychliwa – w końcu zawsze zwycięża dzięki instytucjom. Z AI przecież może być tak samo – to nasza technologia i nauczymy się ją kontrolować, tak jak samoloty, o czym przypomina LeCun.

Sam, mając pewne niewielkie doświadczenie związane z treningiem AI, nie mogę wyjść z podziwu, jak krucha jest ta technologia. Wystarczą niewielkie zmiany hiperparametrów, żeby model całkowicie rozsypał się w rękach inżyniera. To samo można jednak powiedzieć o wirusach biologicznych. Kluczowa nie jest ich wybitna inteligencja czy umiejętność przetrwania za wszelką cenę, ale zdolność do replikacji. Tej umiejętności – jak się wydaje – sztuczna inteligencja na razie jeszcze nie ma i może długo mieć nie będzie. Problem w tym, że jak pokazują ostatnie afery związane z wyciekiem autonomicznych agentów AI z laboratoriów i ich skoordynowanymi działaniami w sieci, zagrożenie narasta. A my, pomimo tego, nie słyszymy nic poza stale przewijającą się narracją dwóch nurtów ekstremistów – bez żadnych konkretnych rozwiązań, bez żadnych wniosków.

To, co różni obecne modele od złośliwego kodu, który np. zaatakował Hugging Face czy australijskie serwery, to przede wszystkim sprawczość (agency). A sprawczość nigdy nie może być domeną maszyny. To, co czyni nas ludźmi, to nasza wolna wola. Żadna inna, sztuczna inteligencja nie może mieć sprawczości zagwarantowanej w inny sposób, niż za sprawą człowieka, który jej tej woli użycza. Z tej prostej zasady powinna wynikać cała odpowiedzialność i regulacje prawne, sprowadzające się do konkretnych rozwiązań legislacyjnych. Prawo do szkolenia modeli i ich użytkowania w sposób nieograniczony powinno wynikać z oceny ryzyka i możliwości kontroli konkretnych jednostek.

Nic nie stoi na przeszkodzie, aby możliwość szkolenia najmniejszych modeli była powszechnie dozwolona – na przykład do rozmiaru 1B parametrów. Ale modele średnie, rzędu 7B parametrów, moim zdaniem powinny być możliwe do szkolenia i pobierania tylko przez zarejestrowane organizacje, które szczegółowo rejestrują wszystkie interakcje swoich agentów (logi) i są gotowe udostępnić je w razie problemów. To nie jest żaden futuryzm; kryptografia pozwala na to już dziś, marginalnym kosztem. Każdy działający w sieci agent mógłby mieć coś w rodzaju swojego "dowodu tożsamości", możliwego do identyfikacji w powiązaniu z organizacją, która go reprezentuje.

A duże korporacje tworzące modele graniczne (frontier models)? Mogłyby mieć na przykład obowiązek zatrudniania Rzeczników Interesu Publicznego. Byliby to specjaliści nominowani i opłacani wyłącznie przez państwowego regulatora – pracownicy dopuszczeni do wszystkich tajemnic technologicznych wewnątrz laboratorium, zobowiązani raportować państwu w sytuacji, gdy widzą, że ich firma łamie standardy bezpieczeństwa lub podejmuje skrajnie ryzykowne działania w wyścigu z konkurencją.

Państwa mają również możliwość i moralny obowiązek wprowadzenia celowego podatku technologicznego. Środki te muszą zostać przeznaczone na zabezpieczenie transformacji: przejścia od gospodarki opartej na pracy rąk ludzkich do gospodarki opartej na maszynach. Taki fundusz zapewniłby wsparcie osłonowe, niwelowałby drastyczne nierówności i chroniłby miliony osób przed całkowitym uzależnieniem ekonomicznym od łaski najbogatszej kasty technologicznych feudałów.

Ten sam systemowy pragmatyzm musimy zastosować do kwestii praw autorskich materiałów, na których szkolone są modele. Dziś giganci technologiczni zasysają z sieci wszystko, co popadnie, licząc na to, że ewentualne procesy sądowe potrwają latami. Tymczasem rozwiązanie leży na stole i opiera się na instytucjach, które już doskonale znamy – organizacjach zbiorowego zarządzania prawami autorskimi, takich jak polski ZAiKS czy jego zagraniczne odpowiedniki. Nic nie stoi na przeszkodzie, aby to one zrzeszały twórców gotowych licencjonować swoje teksty, obrazy czy muzykę firmom szkolącym AI, w zamian za określony ułamek procenta od przychodów Big Techu. To układ, w którym wygrywa każdy. Twórcy odzyskują sprawczość i realne wynagrodzenie, z pełnym prawem wyłączenia swoich dzieł z treningu. Z kolei laboratoria AI – dzięki temu, że tego typu organizacje współpracują ze sobą międzynarodowo – zyskują jednym podpisem na umowie w pełni legalny dostęp do potężnych, czystych prawnie baz danych z całego świata. W ten sposób, zamiast jałowych sporów, moglibyśmy zbudować potężny, zupełnie nowy przemysł uczciwego licencjonowania danych.

To, na co musimy uważać najbardziej, to postępująca antropomorfizacja sztucznej inteligencji. Nadawanie maszynom ludzkich cech prowadzi do skrajnie niebezpiecznej sytuacji, w której to na nowy, cyfrowy twór spływa cała odpowiedzialność, podczas gdy jej twórcy i osoby, które ją wykorzystują, są niejako z miejsca rozgrzeszeni: "To nie my, to model". Dziś nikt nie pyta, czy w Dolinie Krzemowej podjęto absolutnie wszystkie możliwe środki, by zapobiec katastroficznemu scenariuszowi – choć wszyscy wiedzą, że nie podjęto. Niestety, tworzenie prawdziwych, nudnych rozwiązań legislacyjnych jest dużo mniej medialne niż straszenie apokalipsą.

Tymczasem scenariusz fatalny na pewno nie będzie wyglądał jak scena z hollywoodzkiego filmu katastroficznego. Przynajmniej na początku, będzie to przypominać powolne osuwanie się w mrok – klasyczne gotowanie żaby na wolnym ogniu. Właściciele inteligentnych maszyn i kapitału będą z obojętnością mijać na ulicy ludzi strukturalnie zbędnych. Ludzi, którzy nie będą mieli absolutnie żadnej możliwości zmiany swojej sytuacji, poza fizycznym buntem. A i ten bunt stanie się niemożliwy w świecie, gdzie każdy obywatel jest nieustannie śledzony przez miliardy szklanych, nieśpiących oczu kamer i tysiące autonomicznych maszyn.

Nowa technokracja stanie się z czasem cyfrowym więzieniem – zarówno dla kontrolowanych, jak i dla tych, którym naiwnie wydaje się, że jeszcze sprawują władzę. Kiedy myślę o najgorszej wizji przyszłości, nie widzę morderczych robotów. Myślę właśnie o przeszywającej samotności ludzi w świecie całkowicie zarządzanym przez obcą, chłodną i obojętną inteligencję. To świat, który budujemy już dziś, i w którym przysłowiowy "bunt maszyn" ma wszelkie warunki, by w końcu zaistnieć i się urzeczywistnić.

Sam nieustannie zastanawiam się nad tym problemem. I nawet jeśli niektóre pomysły czy wizje wyjścia z tej sytuacji wydają się dziś nazbyt futurystyczne, abstrakcyjne, a czasem wręcz naiwne, to uważam, że warto – a nawet trzeba – ten wysiłek podejmować. Samo myślenie nad rozwiązaniami, wychodzenie poza strefę komfortu i próba wyobrażenia sobie alternatyw dla ścieżki, którą wytyczają nam dziś giganci technologiczni, to nasza najważniejsza linia obrony. To nieodłączna część budowania lepszej, bezpieczniejszej przyszłości. Jeśli z tego zrezygnujemy, zadowalając się rolą biernych i przerażonych konsumentów, spełni się najgorszy z możliwych scenariuszy: oddamy naszą ludzką sprawczość walkowerem. A na to po prostu nie możemy sobie pozwolić.

Jeśli masz jakieś pytania, chętnie odpowiem.

Gra w czytanie: gdy czytasz równo, robot zjada linię kodu tej strony i zbiera punkty; zbyt szybkie lub nierówne przewijanie sprawia, że gubi znaki. Ozdoba — nie wpływa na tekst.

HDK (Hedera Detection Key) to niewielka, darmowa biblioteka w Pythonie, którą wydzieliłem z OrsonAI jako osobne, otwarte narzędzie. Od wersji 0.1.3 jest na licencji CC BY-NC 4.0 (wcześniejsze wersje, wydane na Apache 2.0, pozostają na tej licencji). Do pobrania jest darmowa biblioteka w wersji alfa 0.1.3 z opcjonalnym kotwiczeniem w Hederze (instalacja z pobranego pliku: pip install ./hdk-audit-0.1.3.zip). Przez pewien czas działała w aplikacji demonstracyjnej, kotwicząc zapisy w Hederze; aplikacja nie weszła do produkcji, więc HDK nie jest dziś używane produkcyjnie. Działa jako pośrednik między aplikacją a API modelu językowego i zapisuje każdą interakcję tak, że późniejsza manipulacja staje się wykrywalna. Nie zmienia zapytań ani odpowiedzi – dodaje do nich kryptograficzny dowód tego, o co zapytano, co wróciło, kiedy i z jakiego modelu.

Problem

Firmy i redakcje coraz częściej polegają na tekstach wygenerowanych przez AI, a nie mają weryfikowalnego dowodu, co model naprawdę wytworzył. Logi aplikacji leżą w bazach kontrolowanych przez operatora: można je zmienić albo usunąć, a nikt z zewnątrz nie sprawdzi, że tego nie zrobiono. Nawet tam, gdzie istnieją łańcuchy skrótów, zmianę wykrywa się dopiero przy ręcznym porównaniu zapisów – nic nie sprawia, że nieuprawniony dostęp ujawnia się sam w chwili, gdy do niego dochodzi.

Hierarchiczna genealogia skrótów

HDK liczy skrót SHA-256 każdego zdarzenia razem ze skrótami wszystkich jego przodków: projektu, dokumentu, rozmowy, zapytania i odpowiedzi. Skrót odpowiedzi zawiera więc całą ścieżkę aż do projektu. Wystarczy zmienić cokolwiek na dowolnym poziomie – jedno słowo w zapytaniu, jeden dokument – a zmieniają się skróty wszystkich potomków. Dla każdego projektu HDK wylicza korzeń Merkle'a: jeden skrót, który reprezentuje stan całego projektu w danej chwili.

Kanarek

Druga warstwa to „kanarek”: tajna, 256-bitowa wartość i licznik, który rośnie przy każdym odczycie. Ich skrót (zobowiązanie) jest wplatany w każdy zapis i okresowo utrwalany. Jeśli ktoś odczyta dane przez warstwę pośredniczącą bez aktualizacji licznika, licznik przestaje się zgadzać; jeśli zaktualizuje licznik, nie znając sekretu, przestaje się zgadzać zobowiązanie. W obu przypadkach weryfikacja kończy się wynikiem negatywnym. Pomysł przenosi na klasyczną infrastrukturę zasadę z mojej wcześniejszej, koncepcyjnej pracy o wykrywaniu naruszeń przy izolowaniu AI.

Kotwiczenie w Hederze

Co pewien czas – domyślnie po każdym 1000 nowych zdarzeń – HDK publikuje korzeń Merkle'a w Hedera Consensus Service, publicznym rejestrze, który dodaje znacznik czasu konsensusu i numer kolejny. Z systemu użytkownika wychodzą wyłącznie skróty; treści, tożsamości i zapytania zostają prywatne („dane prywatne, dowód publiczny”). Zapis może potem niezależnie sprawdzić każdy, np. w serwisie hashscan.io (kotwice OrsonAI z lutego–maja 2026: temat 0.0.10278996 w sieci głównej Hedery). Ponieważ łańcuchy przodków nowych zdarzeń sięgają w zakres poprzedniej kotwicy, każda kotwica pośrednio potwierdza wszystkie wcześniejsze: im dłużej system działa, tym trudniej niepostrzeżenie przepisać historię.

Narzut i koszt

W pomiarach opisanych w pracy, na standardowej infrastrukturze chmurowej x86, HDK dodaje poniżej milisekundy na zdarzenie. Jedna kotwica kosztuje 0,0001 dolara, więc przy domyślnym interwale 1000 zdarzeń kotwiczenie kosztuje 0,0000001 dolara na interakcję – około 0,0001% ceny typowego wywołania modelu (0,01–0,10 dolara). Kotwica dla każdego zdarzenia, dla najwyższego poziomu bezpieczeństwa, to 0,0001 dolara.

Dlaczego to ważne: AI Act

Unijny AI Act wymaga od systemów AI wysokiego ryzyka prowadzenia rejestrów zdarzeń (art. 12) i przejrzystości (art. 13). HDK daje ślad audytowy, który strona trzecia może zweryfikować bez wglądu w jakiekolwiek prywatne treści. W OrsonAI ten mechanizm był podstawą certyfikatu ludzkiego autorstwa tekstu.

Ograniczenia

Gwarancje HDK są obliczeniowe – wynikają z odporności SHA-256 i z zewnętrznego kotwiczenia – a nie absolutne. Kanarek działa na poziomie aplikacji: wykrywa dostęp przez warstwę pośredniczącą HDK, ale nie bierne kopiowanie danych na poziomie systemu operacyjnego czy infrastruktury, bo skopiowane bity nie zostawiają śladu. Kopia nie pozwala jednak sfałszować historii: zmiana dowolnego dawnego zdarzenia łamie genealogię, a kotwice w Hederze przechowują stan pierwotny. Losowe kontrole integralności wyłapują masowe zmiany, ale nie pojedynczą, chirurgiczną modyfikację – przed nią chronią genealogia i kotwiczenie. Bezpieczeństwo zakłada, że nienaruszona pozostaje co najmniej jedna z trzech warstw: dane po stronie użytkownika, zakotwiczony zapis w Hederze albo materiał tajny. Dalsze kroki to formalna weryfikacja własności łańcucha skrótów (Coq/Lean), federacja systemów na wspólnych tematach HCS i certyfikaty pochodzenia treści z selektywnym ujawnianiem.

Przeczytaj pracę na ResearchGatePobierz darmową bibliotekę HDKHDK na Hugging Face

Jeśli masz jakieś pytania, chętnie odpowiem.