Źródło: Link
Mind Architect to 180-dniowy program Jana Gajosa: decyzje, nawyki i granice przeniesione do codziennych reakcji. 180 lekcji w 6 modulach, Manfred AI Coach i powtorki rozlozone w czasie.
Pobierasz bibliotekę PyTorch, kopiujesz 30 linijek kodu z tutoriala, klikasz "Run" - i oczekujesz, że sieć neuronowa zacznie działać. Nie zadziała. Albo zadziała, ale źle. Albo zadziała dobrze na testach, ale w produkcji się wysypie.
Andrej Karpathy, były dyrektor AI w Tesli i współtwórca GPT-2 w OpenAI, napisał w 2019 roku tekst, który do dziś pozostaje jednym z najlepszych praktycznych przewodników po trenowaniu sieci neuronowych. Nie ma w nim teorii - jest wyjaśnienie, dlaczego Twój model nie działa, mimo że "wszystko zrobiłeś dobrze".
Ten przewodnik zakłada, że rozumiesz podstawy uczenia maszynowego: wiesz czym jest sieć neuronowa, warstwa konwolucyjna, funkcja straty. Jeśli nie - zacznij od podstaw działania sztucznego neuronu.
Potrzebujesz też:
Karpathy zaczyna od dwóch obserwacji, które wyjaśniają, dlaczego większość ludzi odpada na starcie.
Biblioteki do AI lubią pokazywać "cudowne snippety" - 30 linijek kodu, które rozwiązują Twój problem. To aktywuje część mózgu przyzwyczajoną do standardowego software'u, gdzie czyste API i abstrakcje są normą.
Przykład? Biblioteka Requests w Pythonie. Chcesz pobrać stronę WWW? requests.get('https://example.com'). Ktoś ukrył przed Tobą całą złożoność HTTP, query stringów, połączeń - i to działa. Zawsze.
Sieci neuronowe działają inaczej. Nie są technologią "off-the-shelf" w momencie, gdy odchodzisz choć trochę od trenowania klasyfikatora ImageNet. Karpathy nazywa to "leaky abstraction" - nieszczelną abstrakcją. Backpropagation + SGD nie sprawią magicznie, że Twoja sieć zadziała. Batch normalization nie sprawi, że model zbiegnie się szybciej. RNN-y nie pozwalają Ci "podłączyć" tekstu jak kabla USB.
Jeśli nalegasz na używanie technologii bez rozumienia mechanizmu - najprawdopodobniej poniesiesz porażkę.
Gdy piszesz zwykły kod i coś się psuje, dostajesz exception. "Expected string, got integer". "Function takes 3 arguments, got 5". Import się nie powiódł. Klucz nie istnieje.
Sieci neuronowe nie działają tak. Możesz mieć błąd w implementacji, który sprawi, że model będzie trenował się 3 dni - i osiągnie 12% accuracy zamiast 95%. Nie dostaniesz błędu. Nie dostaniesz ostrzeżenia. Dostaniesz liczbę, która wygląda "jakoś dziwnie".
Przykłady cichych awarii:
Nie ma unit testów, które wyłapią te problemy. Musisz wiedzieć, czego szukać.
Karpathy proponuje proces, który minimalizuje ryzyko cichych awarii. To nie jest lista "najczęstszych błędów" - to metodologia pracy.
Nie zaczynaj od ResNet-152 z attention mechanism i 5 warstwami dropout. Zacznij od logistic regression. Potem dodaj jedną warstwę ukrytą. Potem drugą.
Dlaczego? Bo gdy coś się zepsuje, będziesz wiedział gdzie. Jeśli Twój baseline (najprostszy model) nie działa - nie ma sensu budować czegoś skomplikowanego.
Konkretnie:
Test overfittingu na małym batchu to podstawowa sanity check. Jeśli model nie potrafi zapamiętać 10 przykładów - coś jest fundamentalnie źle.
Większość błędów siedzi w danych, nie w modelu. Karpathy zaleca:
Przykład: trenujesz klasyfikator kotów vs psów. Wyświetlasz 20 losowych obrazków z labelem "kot". Widzisz 3 psy. Masz problem z danymi, nie z modelem.
Jeśli pracujesz z tekstem - sprawdź jak poprawić jakość danych treningowych.
Zanim zaczniesz eksperymentować z architekturą, ustal baseline:
Jeśli Twój skomplikowany model osiąga 45% accuracy, a losowe zgadywanie daje 40% - masz problem. Jeśli prosty model daje 60%, a Twój 45% - masz większy problem.
Baseline to punkt odniesienia. Bez niego nie wiesz, czy idziesz w dobrą stronę.
Accuracy to metryka dla ludzi. Loss to metryka dla modelu. Gdy model się nie uczy, patrzysz na loss.
Co sprawdzać:
Karpathy radzi: loguj wszystko. Loss, learning rate, gradient norms, weight norms. Nie zgaduj - mierz.
Masz działający prosty model. Teraz możesz eksperymentować:
Kluczowa zasada: zmieniaj JEDNĄ rzecz na raz. Jeśli zmienisz 5 rzeczy jednocześnie i accuracy wzrośnie - nie wiesz, która zmiana zadziałała.
Tak jak debugowanie kodu: nie refaktorujesz 200 linijek naraz, tylko jedną funkcję. Podobnie z modelami.
Widzisz, że model działa na 1000 przykładach. Rzucasz go na pełny dataset (1 milion przykładów) i... przestaje działać. Dlaczego?
Bo małe problemy (lekki overfitting, suboptymalne hyperparametry) stają się dużymi problemami na dużej skali. Karpathy radzi: skaluj stopniowo. 1k → 10k → 100k → 1M. Po każdym kroku sprawdzaj, czy model nadal się uczy.
Normalizacja danych to nie opcja. To konieczność. Jeśli Twoje dane wejściowe mają wartości od 0 do 255, a wagi są inicjalizowane blisko zera - gradient będzie gigantyczny lub mikroskopijny.
Standard: normalizuj do średniej 0 i odchylenia standardowego 1. Dla obrazów: podziel przez 255 i odejmij średnią z datasetu.
Przy pracy z tekstem - sprawdź jak działa preprocessing w systemach RAG.
Trenujesz model, testujesz na tym samym zbiorze danych - i dostajesz 99% accuracy. Wdrażasz do produkcji - 60% accuracy. Co się stało?
Overfitting. Model zapamiętał dane treningowe, ale nie nauczył się generalizować. Rozwiązanie: zawsze miej osobny zbiór walidacyjny (10-20% danych), którego model NIGDY nie widzi podczas treningu.
Optymalizujesz model pod accuracy, ale w produkcji liczy się precision (ile z przewidzianych pozytywów to prawdziwe pozytywy). Albo recall (ile prawdziwych pozytywów model złapał).
Przykład: detekcja spamu. 99% maili to nie-spam. Model, który zawsze mówi "nie-spam" ma 99% accuracy - ale jest bezużyteczny. Potrzebujesz precision/recall, nie accuracy.
Karpathy radzi: wybierz metrykę, która odpowiada biznesowemu celowi. I optymalizuj pod nią.
Podejście Karpathy'ego działa, bo minimalizuje przestrzeń możliwych błędów. Zamiast debugować 50 rzeczy naraz (architektura, dane, hyperparametry, preprocessing), debugujesz jedną.
Dlaczego większość ludzi tego nie robi? Bo to wolniejsze. Zamiast od razu zbudować "najlepszy możliwy model", zaczynasz od najprostszego. Frustrujące - szczególnie gdy masz deadline.
Paradoks jest taki: wolniejsze podejście jest szybsze. Bo nie tracisz 3 dni na debugowanie modelu, który ma 7 błędów jednocześnie. Łapiesz błędy wcześniej, gdy są małe.
Karpathy pisze o tym wprost: "Neural net training fails silently". Nie dostaniesz exception. Dostaniesz liczbę, która wygląda dziwnie. I jeśli nie wiesz, czego szukać - przegapisz problem.
Jeśli trenujesz sieci neuronowe (albo planujesz zacząć), wprowadź te zmiany:
To nie jest lista "nice to have". To lista "must have", jeśli chcesz, żeby Twoje modele działały.
Karpathy napisał ten tekst w 2019 roku, ale pozostaje aktualny - bo fundamenty trenowania sieci neuronowych się nie zmieniły. Zmieniły się narzędzia (w 2026 mamy GPT-5, Claude Opus 4.7, DeepSeek V4-Pro), ale proces pozostał ten sam: zaczynasz od prostego, testujesz, debugujesz, skalujesz.
Jeśli chcesz zobaczyć, jak te zasady działają w praktyce przy budowaniu systemów RAG lub integracjach z narzędziami biznesowymi - proces jest analogiczny. Zaczynasz od najprostszej wersji, testujesz, iterujesz.
Trenowanie modeli AI to jedno - ale większość ludzi potrzebuje AI do konkretnych zadań biznesowych, nie budowania sieci od zera. Na darmowym webinarze pokazuję, jak oszczędzać 10 godzin tygodniowo dzięki AI - bez kodowania i wiedzy technicznej.
Zapisz się na darmowy webinar →Wolisz uczyć się we własnym tempie? Sprawdź kurs AI Evolution
Przepis Karpathy'ego to nie teoria - to praktyczna metodologia, która oszczędza tygodnie debugowania. Kluczowa różnica między osobami, które skutecznie trenują modele, a tymi, które się poddają? Proces. Nie talent, nie wiedza teoretyczna - proces.
Zacznij od jednej rzeczy: następnym razem, gdy będziesz trenować model, przetestuj go najpierw na 10 przykładach. Jeśli nie potrafi ich overfitować - nie przechodź dalej. Znajdź błąd. To zaoszczędzi Ci dni frustracji.
Podstawy - tak. Musisz rozumieć, czym jest funkcja straty, gradient, backpropagation. Nie potrzebujesz doktoratu z matematyki. Karpathy pisze dla praktyków, nie teoretyków. Jeśli rozumiesz, dlaczego model minimalizuje loss - wystarczy.
Na początku - dłużej niż chaotyczne eksperymentowanie. Ostatecznie - krócej. Zamiast 3 dni debugowania modelu z 7 błędami, spędzasz 30 minut na każdym kroku walidacji. Łapiesz błędy wcześniej, gdy są małe. Oszczędzasz czas.
Tak. Karpathy pisał tekst w 2019, ale zasady pozostają aktualne. Fine-tuning GPT-5 czy Claude Opus 4.7 wymaga tego samego procesu: zaczynasz od małego datasetu, sprawdzasz overfitting, logujesz loss, iterujesz. Narzędzia się zmieniły, proces - nie.
To klasyczny problem skalowania. Najczęstsze przyczyny: zbyt wysoki learning rate (zmniejsz go), zbyt mały batch size (zwiększ), problemy z regularizacją (dodaj dropout lub weight decay). Skaluj stopniowo - 1k, 10k, 100k przykładów - i sprawdzaj, gdzie model zaczyna się gubić.
Możesz. Najprawdopodobniej stracisz czas. Jeśli skomplikowany model nie działa - nie wiesz, czy problem jest w architekturze, danych, preprocessing, czy hyperparametrach. Prosty model to baseline - punkt odniesienia. Bez niego debugujesz w ciemno.
Na podstawie: A Recipe for Training Neural Networks - Andrej Karpathy
Pola recepcyjne decydują, które fragmenty obrazu wpływają na wynik sieci. Pokazuję, jak je policzyć krok po kroku - bez matematycznych fajerwerków.
Chcesz, żeby AI rozróżniało metal od disco? Poznaj krok po kroku proces fine-tuningu modelu do klasyfikacji muzyki - bez doktoratu z informatyki.
Dane treningowe to fundament każdego modelu AI. Sprawdź, jak zaprojektować proces zbierania adnotacji od ludzi, żeby Twój model uczył się na solidnych podstawach.
Gradient descent to fundament uczenia maszynowego. Dowiedz się krok po kroku, jak sieci neuronowe uczą się rozpoznawać obrazy i wzorce - bez matematyki wyższej.
Modele AI podejmują decyzje w medycynie, finansach i zatrudnieniu. Jak sprawdzić, czy nie faworyzują jednych grup kosztem innych? Przewodnik po narzędziach odpowiedzialnej AI.
Regresja ML to podstawa predykcji liczbowej w AI. Poznaj cztery sprawdzone metody budowy modelu regresji w Scikit-learn - od przygotowania danych po walidację wyników.
