Optymalizacja modelu sztucznej inteligencji Gemma 4 12B z wykorzystaniem metody LoRA oraz ustrukturyzowanego wnioskowania łańcuchowego

1. Wstęp

Duże modele językowe (LLM, Large Language Models) są parametrycznymi modelami autoregresyjnymi opartymi na architekturze Transformer [5], których wiedza zakodowana jest w miliardach wyuczonych wag. Początkowa faza niniejszych badań opierała się na modelu Gemma 4 w wersji 4B (4 miliardy parametrów). Empirycznie wykazano, że model ten nie posiadał dostatecznej pojemności (model capacity), aby generować poprawny logicznie kod JavaScript wymagany do tworzenia złożonych aplikacji przeglądarkowych.

Zjawisko to jest analogiczne do próby aproksymacji bardzo złożonej, wielowymiarowej funkcji za pomocą wielomianu zbyt niskiego stopnia – system nie dysponował wystarczającą liczbą parametrów, aby zakodować skomplikowane schematy logiczne. Zbiegło się to w czasie z premierą nowego wariantu: Gemma 4 12B (12 miliardów parametrów). Decyzja o natychmiastowym przejściu na nową, trzykrotnie większą architekturę pozwoliła ominąć limity pojemności, lecz jednocześnie wymusiła przebudowę metodyki uczenia.

2. Podstawy teoretyczne (Przystępne wyjaśnienie)

Przed przejściem do szczegółów technicznych i formalizmów matematycznych, niniejsza sekcja przedstawia kluczowe pojęcia wykorzystane w artykule w sposób przystępny, z zastosowaniem analogii ułatwiających zrozumienie dla czytelnika spoza dziedziny uczenia maszynowego.

2.1. Autoregresyjne modelowanie języka

Współczesne modele językowe, takie jak Gemma 4, są w swojej istocie zaawansowanymi systemami autoregresyjnej predykcji tokenów – funkcjonalnie przypominającymi systemy autouzupełniania tekstu znane z urządzeń mobilnych, lecz operującymi na znacznie większej skali.

Model uczy się na podstawie miliardów tekstów z internetu (książek, artykułów, kodu źródłowego). Jego zadaniem jest przewidzenie, jaki token (fragment słowa lub znaku) powinien pojawić się jako następny na podstawie dotychczasowego kontekstu. Jeśli napiszemy "Stolicą Polski jest...", model na podstawie wyuczonych statystyk przypisze najwyższe prawdopodobieństwo tokenowi "Warszawa". Analogicznie, przy generowaniu kodu HTML model przewiduje sekwencje tokenów (nawiasy, słowa kluczowe JavaScript, deklaracje CSS), które najczęściej współwystępują w podobnych kontekstach programistycznych.

2.2. Pojemność modelu a złożoność zadania

Wielkość modelu określa się w parametrach (oznaczanych literą B – od angielskiego billions, czyli miliardy). Parametry stanowią wyuczone wagi sieci neuronowej – im ich więcej, tym większą wiedzę i bardziej skomplikowane zależności model jest w stanie zakodować.

Początkowo próbowano trenować model w wersji Gemma 4 4B (4 miliardy parametrów). Intuicyjnie można to porównać do próby nauczenia zdolnego, lecz początkującego studenta pisania zaawansowanych gier 3D w JavaScript – proste zadania (np. kalkulator) są wykonalne, ale złożona logika gier wyczerpuje pojemność reprezentacyjną modelu. Przejście na wersję Gemma 4 12B (12 miliardów parametrów) trzykrotnie zwiększyło liczbę wyuczalnych wag, co pozwoliło modelowi zakodować zarówno wiedzę o zaawansowanej trygonometrii, bibliotece Three.js do grafiki 3D, jak i o skomplikowanym zarządzaniu stanem okien w systemie operacyjnym.

2.3. Chain of Thought (CoT) – wnioskowanie krok po kroku

Wyobraź sobie, że ktoś każe Ci rozwiązać w pamięci, w ułamku sekundy, bardzo trudne zadanie matematyczne (np. pomnożyć 473 przez 289) i natychmiast wypowiedzieć na głos sam wynik. Istnieje ogromne prawdopodobieństwo, że się pomylisz. Jeśli jednak dostaniesz kartkę papieru (brudnopis) i rozpiszesz to zadanie krok po kroku (mnożenie pod kreską), bez trudu podasz bezbłędny wynik.

Dokładnie tym dla modelu jest Chain of Thought (CoT – Łańcuch Myśli) ukryty za specjalnymi znacznikami <|channel>thought. Zamiast kazać modelowi natychmiast pisać kod HTML (co często prowadzi do błędów logicznych, zapominania o zamknięciu tagów czy niedziałających zmiennych w JS), model jest zmuszany do „myślenia na głos” w brudnopisie. Najpierw planuje strukturę aplikacji, wypisuje potrzebne zmienne, projektuje wygląd w CSS, a dopiero po upewnieniu się, że plan jest spójny, zaczyna pisać właściwy kod. Brudnopis ten jest niewidoczny dla użytkownika końcowego, ale stanowi klucz do logicznej bezbłędności modelu.

2.4. Metoda LoRA – efektywna adaptacja parametrów

Główna wiedza modelu Gemma 4 12B (nasze 12 miliardów parametrów) to jak olbrzymia biblioteka narodowa zawierająca 12 miliardów grubych ksiąg. Gdybyśmy chcieli nauczyć model nowej specjalizacji (np. specyficznego, nowoczesnego stylu pisania kodu i myślenia w 9 krokach), tradycyjny trening wymagałby przepisania i zmodyfikowania wszystkich 12 miliardów książek od nowa. Wymagałoby to superkomputerów wartych miliony złotych i gigantycznych ilości prądu.

Metoda LoRA (Low-Rank Adaptation) rozwiązuje ten problem. Zamiast modyfikować całą bibliotekę (wagi bazowe modelu), zostawiamy ją całkowicie nienaruszoną (zamrożoną). Zamiast tego wręczamy bibliotekarzowi jeden mały, lekki notatnik (o objętości zaledwie kilkudziesięciu megabajtów). W tym notatniku zapisujemy wyłącznie różnice i nowe reguły – np. „stosuj styl cyberpunkowy”, „zawsze używaj 9 kroków myślenia”, „stosuj dynamiczne okna”. Kiedy zadajesz modelowi pytanie, korzysta on ze swojej ogólnej wiedzy z wielkich ksiąg (model bazowy), ale nakłada na nią specyficzne instrukcje zapisane w podręcznym notatniku (adapterze LoRA). Dzięki temu trening jest niezwykle tani, szybki i można go przeprowadzić na zwykłym, domowym komputerze.

2.5. Zjawisko przeuczenia (Overfitting)

Podczas pierwszych prób (wersja v1.0) model został poddany zbyt agresywnej adaptacji (zbyt wysoka skala LoRA bez regularyzacji dropoutem). W efekcie model uległ przeuczeniu (ang. overfitting) [3].

Można to porównać do ucznia, który wykuł na pamięć konkretne pytania i odpowiedzi z poprzednich egzaminów – na identycznym pytaniu odpowiada idealnie, lecz przy najdrobniejszym odstępstwie generuje zupełnie błędne odpowiedzi. Wersja v1.0 modelu potrafiła wygenerować estetycznie zaawansowany kod, ale przy instrukcjach spoza dystrybucji treningowej generowała niedziałający kod z błędami składniowymi (typos) i pustym ekranem w przeglądarce. Dopiero wprowadzenie kontrolowanego szumu (Dropout) w wersjach v1.2 i v1.3 zmusiło model do ekstrakcji ogólnych reguł programistycznych zamiast memoryzacji konkretnych przykładów.

2.6. Kwantyzacja z uwzględnieniem treningu (QAT)

Model Gemma 4 12B w pełnej precyzji zajmuje na dysku około 24 gigabajtów i wymaga bardzo drogich kart graficznych do uruchomienia. Aby uruchomić go na domowym laptopie, stosuje się kwantyzację – czyli kompresję wag (np. z formatu 16-bitowego do 4-bitowego). To trochę jak zmniejszanie rozmiaru i rozdzielczości zdjęcia, by zajmowało mniej miejsca na dysku.

Zwykła kwantyzacja (Post-Training Quantization) przypomina spakowanie rzeczy do plecaka na siłę po skończeniu pakowania – niektóre delikatne przedmioty (np. precyzyjne tokeny zamykające myślenie) mogą ulec zgnieceniu (zaokrągleniu do zera), przez co model zaczyna „bełkotać” i traci stabilność. W projekcie wykorzystano metodę QAT (Quantization-Aware Training). Uczyliśmy model na wagach, które już w trakcie treningu „wiedziały”, że będą skompresowane. To tak, jakby trenować biegacza do biegu z ciężkim plecakiem od samego początku. Dzięki temu ostateczna kompresja do 4-bitów (format GGUF) nie popsuła zdolności logicznych modelu, pozostawiając go stabilnym i niezwykle szybkim.

3. Metodologia i Architektura Zbioru Danych (Dataset)

Kluczowym aspektem projektu był nie tylko sam wolumen danych, lecz przede wszystkim ich jakość oraz specyficzna struktura. Zamiast budować jednorazowo statyczną bazę, zbiór danych był płynnie powiększany i skrupulatnie udoskonalany wraz z postępami i kolejnymi generacjami modelu. Model uczy się poprzez aproksymację wzorców, dlatego zbiór treningowy musiał w każdej iteracji reprezentować najwyższe standardy inżynierii oprogramowania. Aktualny zbiór danych (STARK-WEB v1.3) charakteryzuje się następującymi parametrami ilościowymi:

• Liczba przykładów: 806
• Łączna liczba tokenów: 12 287 335
• Średnia długość przykładu: 15 244,8 tokenów
• Najdłuższy pojedynczy przykład: 42 341 tokenów

W celu uzyskania wysokiej wierności (ang. fidelity) generowanego kodu, zrezygnowano z uproszczonej metody generowania jednostopniowego (ang. zero-shot generation). Zbiór danych został wytworzony przy użyciu techniki destylacji wiedzy (ang. Knowledge Distillation) [9] z komercyjnego modelu referencyjnego (Gemini 3.5 Flash High), przechodząc przez proces wieloetapowej rafinacji.

Każda z instrukcji (w obecnej iteracji 806) była przetwarzana przez model referencyjny minimum dwukrotnie. Wyjściowy kod był ponownie przesyłany jako kontekst wraz z dedykowanym promptem poprawiającym (ang. critique-and-refine prompt), którego zadaniem było zlokalizowanie i eliminacja błędów semantycznych, optymalizacja struktury oraz poprawa estetyki kodu źródłowego.

Z uwagi na optymalizację kosztów oraz dążenie do pełnej kontroli jakości, potok przetwarzania danych (ang. data pipeline) został podzielony na dwie odrębne fazy:

• Faza manualna (interaktywna weryfikacja): Utrzymano paradygmat human-in-the-loop – cały wygenerowany kod był ręcznie sprawdzany i weryfikowany przed zapisem pod kątem poprawnego renderowania stylów, estetyki wizualnej i responsywności. Zweryfikowane pary (Prompt → Kod) zapisywano w formacie JSON Lines (plik data.jsonl).
• Faza zautomatyzowana (rekonstrukcja CoT): W drugim kroku dedykowany skrypt komunikował się przez API Google, by wygenerować ustrukturyzowane wnioskowanie CoT. Po odblokowaniu dodatkowych środków w Google Cloud, podjęto decyzję o wygenerowaniu ścieżek CoT od nowa dla całego zbioru za pomocą potężniejszego wariantu Gemini 3.5 Flash High, co drastycznie podniosło jakość destylowanej logiki.

Struktura danych opiera się na monolitycznej spójności (Single-File Architecture – generowanie kodu HTML/CSS/JS w jednym pliku) oraz nowoczesnej estetyce (CSS Grid/Flexbox, glassmorphism, zmienne CSS, płynne animacje). Zbiór został opracowany w około 90% w języku angielskim i w 10% w języku polskim, zapewniając pełną dwujęzyczność.

3.1. Charakterystyka tokenizacji i ekstrapolacja na jednostki tekstowe

Zależność między liczbą tokenów a fizyczną objętością tekstu jest determinowana przez specyfikę językową i składniową. W języku angielskim 1 token odpowiada średnio 0,75 słowa (ok. 4 znakom), natomiast w języku polskim, z uwagi na fleksję, jest to od 1,2 do 1,8 tokenu na słowo. W przypadku hybrydowego kodu i myślenia w bazie STARK-WEB, empiryczny przelicznik wynosi około 3,2 znaku ze spacjami na 1 token. Przekłada się się to na następujące miary:

• Łączna objętość zbioru (12 287 335 tokenów): Odpowiada ponad 39,3 miliona znaków ze spacjami (ok. 6,7 miliona słów).
• Średnia długość rekordu (15 244,8 tokenów): Stanowi ekwiwalent ok. 48 800 znaków (ok. 8 400 słów) na jedno zadanie – objętość rozdziału książkowego.
• Najdłuższy pojedynczy rekord (42 341 tokenów): Przekłada się na blisko 135 500 znaków (ok. 23 200 słów) – objętość krótkiej książki wygenerowanej w jednym przebiegu.

4. Algorytmizacja Wnioskowania (Chain of Thought)

Podczas wstępnych testów, model stosujący tradycyjne wnioskowanie CoT często wpadał w nieskończone pętle myślowe, analizując problem cyklicznie i nie przechodząc do pisania kodu. Aby to rozwiązać, zaimplementowano sztywną algorytmizację procesu myślowego. Cały proces wnioskowania w zbiorze został podzielony na 9 kolejnych etapów i ograniczony twardym warunkiem stopu: znacznikiem [END_OF_THINKING] wewnątrz tagów strukturalnych.

<|channel>thought
1. Understand the Goal: [Podsumowanie celu]
2. Inputs: [Dane wejściowe i zdarzenia]
3. Output: [Elementy renderowane w DOM]
4. Identify Key Constraints & Technologies: [Wybór API i ograniczeń]
5. Design the HTML Structure: [Planowanie struktury tagów]
6. Design the CSS: [Mapowanie kolorów HSL i layoutów]
7. Design the JavaScript: [Projektowanie logiki zdarzeń i pętli]
8. Refinement & Implementation: [Autokorekta i optymalizacje]
9. Final Review: [Walidacja wymagań]
---
[END_OF_THINKING]
<channel|>

Sztywne oddzielenie kanału myślowego pozwoliło wyeliminować halucynacje logiczne i semantyczne niemal do zera.

4.1. Konieczność budowy dedykowanego interfejsu (Stream API)

Wprowadzenie dedykowanych tokenów strukturalnych (<|channel>thought) sprawiło, że standardowe oprogramowanie klienckie nie potrafiło poprawnie renderować tekstu wynikowego – wyświetlając myśli modelu jako jawny tekst dla użytkownika. Aby temu zapobiec, opracowano dedykowany interfejs webowy z asynchronicznym parserem API strumieniowego. Interfejs na bieżąco izoluje „napływające” fragmenty myślenia (chunks) do interaktywnego, zwijanego obszaru („brudnopisu”), wyświetlając użytkownikowi wyłącznie sformatowany, gotowy kod wynikowy.

5. Matematyczne Podstawy i Fuzja Wag LoRA (Low-Rank Adaptation)

Uczenie modelu Gemma 4 12B w pełnej precyzji wymaga ogromnych zasobów sprzętowych. Zastosowano adaptację LoRA [4], która zamiast aktualizować pełną macierz wag \(W \in \mathbb{R}^{d \times k}\) (np. 4096 × 4096 – 16 milionów wag), wprowadza zmianę \(\Delta W\) jako iloczyn dwóch wąskich macierzy o niskim rzędzie (rank) \(r\):

Przy rzędzie \(r=64\), zamiast 16 milionów wag w pojedynczej warstwie, modyfikuje się jedynie ok. 524 288 parametrów (\(B\): 4096 × 64, \(A\): 64 × 4096). W zastosowanej konfiguracji LoRA jest aplikowana do siedmiu typów projekcji (q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj), co łącznie daje znacznie większą, lecz wciąż niewielką w porównaniu z pełnym modelem, liczbę parametrów trenowalnych. Pozwoliło to na drastyczne obniżenie wymagań pamięciowych.

5.1. Zjawisko „Znikającej LoRA” (Vanishing LoRA) przy kompresji NF4

Zidentyfikowano krytyczny problem podczas próby fuzji wag (łączenia macierzy LoRA z bazową macierzą wag) bezpośrednio na modelu skwantyzowanym do formatu 4-bitowego (NF4). Z uwagi na ogromną kompresję i małą precyzyję siatki NF4, niewielkie przesunięcia wag wnoszone przez LoRA były zaokrąglane do zera (zanikały). Wyeksportowany model tracił wyuczone zdolności logiczne i zachowywał się jak czysty model bazowy. Rozwiązaniem okazało się przeprowadzenie fuzji w pełnej precyzji BFloat16.

5.2. Rozwiązanie limitu pamięci VRAM na GPU konsumenckim

Przeprowadzenie fuzji wag 12B w precyzji BFloat16 wymaga ponad 24 GB pamięci, co na testowej karcie RTX 5060 Ti (16 GB) prowadziło do błędów braku pamięci (OOM). Aby to obejść, proces scalania zaimplementowano hybrydowo bezpośrednio na pamięci RAM i procesorze komputera (Device Map ustawiony na cpu). Mimo dłuższego czasu obliczeń, pozwoliło to na 100% precyzyjne scalenie modelu przed ostatecznym eksportem.

5.3. Matematyczna walidacja fuzji wag normą L2

W celu naukowej weryfikacji poprawności scalenia wag, wdrożono algorytm liczący globalną normę macierzy wag (odległość euklidesową wag, czyli normę L2) za pomocą funkcji torch.norm() przed i po fuzji. Wykrycie mierzalnej zmiany normy tensorów po fuzji dało empiryczny dowód na prawidłową integrację adaptera LoRA z modelem bazowym.

6. Optymalizacja Procesu Treningowego i Regularyzacja

Proces dostrajania parametrów wymagał pokonania kilku barier algorytmicznych, które mogły doprowadzić do degradacji modelu:

6.1. Katastrofalne zapominanie (Catastrophic Forgetting)

Podczas wczesnej kalibracji zaobserwowano, że zbyt wysoka szybkość uczenia (Learning Rate) powodowała, że model szybko uczył się nowego formatu myślenia, ale drastycznie tracił swoją bazową wiedzę o składni języków [2]. Pętla CoT była poprawna, ale ostateczny kod HTML/JS zawierał błędy składniowe. Wymagało to obniżenia współczynnika uczenia.

6.2. Paradoks LoRA Dropout i regularyzacja L2

Początkowe założenie zerowej wartości Dropout (dla idealnej replikacji kodu) doprowadziło do dosłownego uczenia się kodu na pamięć (memoryzacja). Dopiero narzucenie 5% szumu (lora_dropout = 0.05) oraz L2 regularyzacji (weight_decay = 0.01) zmusiło model do wyciągania ogólnych reguł logicznych i składniowych, co całkowicie wyeliminowało błędy w wyjściowym kodzie.

6.3. Szum kwantyzacyjny (PTQ vs QAT)

Tradycyjna kompresja Post-Training Quantization (PTQ) modelu 16-bitowego do formatu 4-bitowego GGUF wprowadzała szum, który zacierał delikatne granice myślenia CoT (model mylił tokeny wyjścia [END_OF_THINKING]). Zastosowano technologię Quantization-Aware Training (QAT) [6] – jako model bazowy wybrano wariant google/gemma-4-12B-it-qat-q4_0-unquantized (symulujący szum kwantyzacyjny w trakcie uczenia). Dzięki temu ostateczny eksport do formatu GGUF 4-bit zachował stabilność logiczną modelu 16-bitowego.

6.4. Zarządzanie VRAM i anomalie logowania

Aby zmieścić trening kontekstu 43 000 tokenów w 16 GB VRAM, wdrożono Gradient Checkpointing [7] (dynamiczne przeliczanie aktywacji zamiast trzymania ich w pamięci podręcznej – oszczędność ok. 60% VRAM) oraz Paged AdamW 8-bit [8] (przenoszenie nieaktywnych stanów optymalizatora do pamięci RAM komputera). Wykryto i zdiagnozowano również błąd biblioteki Hugging Face Transformers, która przy nieliniowej akumulacji gradientów generowała fałszywe skoki błędu (skok train_loss do 2,3) na granicach epok, podczas gdy rzeczywista strata wynosiła stabilne 0,2.

7. Przebieg Eksperymentów i Ewolucja Modelu

Rozwój modelu STARK-WEB przebiegał w czterech głównych fazach, co pozwoliło na dokładną analizę wpływu parametrów uczenia i danych na wynik końcowy:

• Wersja v1.0 (Opublikowana wersja testowa): Pierwsza publiczna kompilacja testowa modelu. Była trenowana przy agresywnej skali LoRA (ratio Alpha/R = 2.0, czyli LORA_ALPHA=128, LORA_R=64) bez regularyzacji dropoutem. Model okazał się silnie przeuczony (overfitted). Choć generował estetycznie piękne style CSS, kod źródłowy zawierał krytyczne błędy logiczne i typos (literówki), co skutkowało pustym ekranem w przeglądarce i martwymi event handlerami.
• Wersja v1.1 (Wstępna kalibracja): Próba kalibracji parametrów przy wciąż agresywnych ustawieniach (ratio 2.0, LR 2e-5). Pomimo niskiej straty walidacyjnej (eval_loss = 0.84), model cierpiał na zjawisko catastrophic forgetting logicznego wnioskowania w JS. Kod CSS/HTML był bezbłędny, lecz logika JavaScript ulegała całkowitej degradacji.
• Wersja v1.2 (Regularyzacja parametrów): Wdrożono bezpieczniejszą konfigurację: zmniejszenie ratio Alpha/R do 1.0 (LORA_ALPHA=64), obniżenie LR do 1e-5, dodanie lora_dropout=0.05 oraz weight_decay=0.01. Zmiany te uratowały logikę modelu (stabilny eval_loss = 0.9316). Model pisał poprawny kod, lecz napotkano barierę w samym zbiorze danych – model radził sobie świetnie z layoutem, lecz brakowało mu zaawansowanych algorytmów i logiki JS.
• Wersja v1.3 (Zrównoważone rozszerzenie logiczne): Celowo rozszerzono zbiór danych o 77 niezwykle trudnych algorytmicznie przykładów (razem 806 rekordów / 12,28M tokenów) z zakresu CRUD, asynchroniczności, interakcji tabelarycznych i gier planszowych. Trening v1.3 zakończył się rewelacyjnym rezultatem – strata walidacyjna spadła do rekordowego eval_loss = 0,91493 bez jakichkolwiek szumów. Model zyskał bezprecedensową zdolność logicznej syntezy.

8. Wyniki i Analiza Porównawcza (Evaluation)

Ewaluacja przeprowadzona na wariancie STARK-WEB 12B ukazuje wyraźny skok jakościowy w stosunku do komercyjnych modeli referencyjnych o podobnym lub większym rozmiarze.

8.1. Wewnętrzny benchmark jakościowy (LLM-as-a-Judge)

W celu uzyskania powtarzalnej i skalowalnej metryki ewaluacyjnej, opracowano wewnętrzny benchmark oparty na metodologii LLM-as-a-Judge. Zbiór testowy składał się z zestawu zróżnicowanych promptów wykraczających poza dystrybucję danych treningowych, obejmujących zarówno proste komponenty UI, jak i złożone aplikacje webowe z zaawansowaną logiką JavaScript. Każdy wygenerowany kod był automatycznie oceniany przez duży, zewnętrzny model SOTA (Gemini) w skali 0–100 pod kątem czterech kryteriów: poprawności kodu HTML/CSS, funkcjonalności logiki JavaScript, estetyki wizualnej i nowoczesności interfejsu oraz zgodności z instrukcją użytkownika. Wynik końcowy stanowił średnią ważoną tych komponentów.

Wyniki ukazują charakterystyczną, nieliniową trajektorię rozwoju modelu. Wersja v1.0, pomimo subiektywnie lepszej estetyki generowanych interfejsów (wynikającej z agresywnej memoryzacji wzorców CSS ze zbioru treningowego), uzyskała wynik niższy od modelu bazowego (65,0 vs 66,5). Paradoks ten potwierdza destrukcyjny wpływ przeuczenia (overfitting) — model wytwarzał wizualnie atrakcyjne, lecz niedziałające aplikacje z martwymi event handlerami i błędami składniowymi w JavaScript, co sędzia LLM surowo penalizował. Dopiero wdrożenie regularyzacji w wersji v1.2 (Dropout 5%, L2 weight decay) pozwoliło przekroczyć baseline SOTA, osiągając 68,0. Ostateczna wersja v1.3, wzbogacona o 77 algorytmicznie zaawansowanych przykładów, osiągnęła wynik 70,5 — co stanowi wzrost o +6,0% względem modelu bazowego i potwierdza skuteczność zastosowanej metodologii ustrukturyzowanego CoT w połączeniu ze zbalansowaną regularyzacją.

8.2. Wizualna analiza porównawcza

(a) Oryginał (Nauczyciel) – Gemini 3.5 Flash

(b) Odtworzenie (Uczeń – wersja v0.9) – STARK-WEB 12B

Już na wczesnym etapie rozwoju (wersja v0.9) model lokalny („Uczeń”) zaczął w sposób powtarzalny przewyższać estetycznie swój model referencyjny („Nauczyciela”). Rysunek 1 przedstawia wygenerowaną przez oba systemy grę „Snake” na podstawie prostego promptu: "Make an HTML snake game in 1 file". O ile model Gemini wygenerował poprawny logicznie, lecz surowy wizualnie interfejs, o tyle STARK-WEB 12B już w wersji v0.9 stworzył cyberpunkową aplikację „NEON SNAKE” z zaawansowaną poświatą neonową, dedykowanymi licznikami z wiodącymi zerami oraz automatyczną responsywnością (samodzielnie wykrył urządzenie mobilne i wyrenderował dotykowe przyciski sterujące na ekranie, ukrywając je na komputerach desktopowych).

9. Wnioski, Publikacja i Dalsze Badania

Wytrenowany model zostanie udostępniony bezpłatnie w globalnym repozytorium Hugging Face pod nazwą STARK-WEB 12B na licencji Apache 2.0, umożliwiając komercyjne i naukowe wykorzystanie asystenta bez opłat licencyjnych.

Podczas przygotowania wersji do pracy lokalnej, zidentyfikowano brak kompatybilności narzędzi llama.cpp z nową klasą modelową Hugging Face: Gemma4UnifiedForConditionalGeneration. Przeprowadzono udany proces patchowania kodu źródłowego konwertera, co umożliwiło poprawny eksport wag.

Dalsze plany badawcze zakładają przeniesienie opracowanej metodologii ustrukturyzowanego CoT oraz potoku danych na większą architekturę – Gemma 4 26B. Eksperymenty będą realizowane w chmurze obliczeniowej z wykorzystaniem procesorów graficznych NVIDIA A100. Zakłada się hipotezę, że większa pojemność modelu 26B pozwoli na całkowite wyeliminowanie drobnych błędów w zaawansowanej logice, takich jak interakcje okienek w systemach operacyjnych typu Browser OS.

10. Bibliografia