03 gru 2025·6 min
Andrej Karpathy i deep learning: lekcje dotyczące wdrażania AI
Andrej Karpathy i deep learning pokazują, jak zamieniać sieci neuronowe w produkty z jasnymi założeniami, metrykami i workflowem nastawionym na inżynierię.
Andrej Karpathy i deep learning pokazują, jak zamieniać sieci neuronowe w produkty z jasnymi założeniami, metrykami i workflowem nastawionym na inżynierię.
Demo deep learningu może wyglądać jak magia. Model pisze czysty akapit, rozpoznaje obiekt albo odpowiada na trudne pytanie. Potem próbujesz zamienić to demo w przycisk, którego użytkownicy będą naciskać codziennie, i robi się nieporządnie. Ten sam prompt zachowuje się inaczej, pojawiają się przypadki brzegowe, a moment „wow” zamienia się w zgłoszenie do supportu.
Ta luka to powód, dla którego prace Andreja Karpathy'ego przemawiają do budujących produkty. Promował podejście, w którym sieci neuronowe nie są tajemniczym artefaktem — to systemy, które projektujesz, testujesz i utrzymujesz. Modele nie są bezużyteczne. Produkty po prostu wymagają spójności.
Kiedy zespoły mówią, że chcą „praktycznego” AI, zwykle mają na myśli cztery rzeczy:
Zespoły mają trudności, bo deep learning jest probabilistyczny i wrażliwy na kontekst, a produkty oceniane są pod kątem niezawodności. Chatbot, który odpowiada dobrze na 80% pytań, może ciągle wydawać się zepsuty, jeśli pozostałe 20% to odpowiedzi pewne siebie, błędne i trudne do wykrycia.
Weźmy asystenta „auto-reply” dla wsparcia klienta. Świetnie wygląda na kilku wyselekcjonowanych ticketach. W produkcji klienci piszą slangiem, dołączają zrzuty ekranu, mieszają języki lub pytają o niestandardowe zasady. Teraz potrzebujesz zabezpieczeń, jasnego zachowania odmowy i sposobu na zmierzenie, czy szkic rzeczywiście pomógł agentowi.
Wiele osób po raz pierwszy zetknęło się z pracami Karpathy'ego przez praktyczne przykłady, a nie abstrakcyjną matematykę. Nawet wczesne projekty przekazywały prosty punkt: sieci neuronowe stają się użyteczne, gdy traktujesz je jak oprogramowanie, które możesz testować, łamać i naprawiać.
Zamiast zatrzymywać się na „model działa”, uwaga przesuwa się na uzyskanie działania na brudnych, rzeczywistych danych. To obejmuje pipeline'y danych, uruchomienia treningu, które zawodzą z nudnych powodów, i wyniki, które zmieniają się po drobnej poprawce. W takim świecie deep learning przestaje brzmieć mistycznie i zaczyna przypominać inżynierię.
Podejście w stylu Karpathy'ego to mniej sekretne sztuczki, więcej nawyków:
To podstawy, które się potem zwracają, bo produktowe AI to w większości ta sama gra, tylko na większą stawkę. Jeśli nie zbudujesz rzemiosła wcześnie (jasne wejścia, jasne wyjścia, powtarzalne uruchomienia), wdrożenie funkcji AI zamienia się w zgadywanie.
Duża część wpływu Karpathy'ego polegała na traktowaniu sieci jako czegoś, co da się rozumowo wyjaśnić. Jasne wyjaśnienia zmieniają pracę z „systemu wierzeń” w inżynierię.
To ważne dla zespołów, bo osoba, która tworzy pierwszy prototyp, często nie będzie tą, która go utrzymuje. Jeśli nie potrafisz wytłumaczyć, co model robi, prawdopodobnie nie naprawisz go, i na pewno nie obsłużysz w produkcji.
Wymuś jasność wcześnie. Zanim zbudujesz funkcję, wypisz, co model widzi, co zwraca i jak sprawdzisz, czy się poprawia. Większość projektów AI odpada na podstawach, nie na matematyce.
Krótka lista kontrolna, która się potem opłaca:
Jasne myślenie objawia się zdyscyplinowanymi eksperymentami: jeden skrypt, który możesz ponownie uruchomić, stałe zbiory ewaluacyjne, wersjonowane prompt-y i zarejestrowane metryki. Bazy trzymają cię w prawdzie i czynią postęp widocznym.
Prototyp dowodzi, że pomysł działa. Wdrożona funkcja dowodzi, że działa dla prawdziwych ludzi, w brudnych warunkach, codziennie. Ta luka to miejsce, gdzie wiele projektów AI ugrzęźnie.
Demo badawcze może być wolne, kosztowne i kruche, o ile pokazuje możliwość. Produkcja odwraca priorytety. System musi być przewidywalny, obserwowalny i bezpieczny nawet gdy wejścia są dziwne, użytkownicy niecierpliwi, a ruch gwałtownie rośnie.
W produkcji latencja to cecha. Jeśli model potrzebuje 8 sekund, użytkownicy rezygnują lub spamują przycisk, a ty płacisz za każde ponowienie. Koszt też staje się decyzją produktową, bo drobna zmiana promptu może podwoić rachunek.
Monitoring jest niepodważalny. Musisz wiedzieć nie tylko, że usługa działa, ale czy wyjścia pozostają w akceptowalnej jakości z czasem. Przesunięcia danych, nowe zachowania użytkowników i zmiany upstream mogą po cichu zepsuć wydajność bez żadnego błędu.
Kontrole bezpieczeństwa i zgodności przechodzą z „fajnie mieć” do wymogu. Musisz obsłużyć szkodliwe zapytania, dane prywatne i przypadki brzegowe w sposób spójny i testowalny.
Zespoły zwykle odpowiadają na ten sam zestaw pytań:
Prototyp może zbudować jedna osoba. Wdrożenie zwykle potrzebuje produktu do zdefiniowania sukcesu, pracy z danymi do walidacji wejść i zbiorów ewaluacyjnych, infrastruktury do niezawodnego działania i QA do testowania trybów awarii.
„Działa na mojej maszynie” nie jest kryterium wydania. Wydanie znaczy, że działa dla użytkowników pod obciążeniem, z logowaniem, zabezpieczeniami i sposobem na mierzenie, czy pomaga czy szkodzi.
Wpływ Karpathy'ego jest kulturowy, nie tylko techniczny. Traktował sieci neuronowe jak coś, co możesz zbudować, testować i poprawiać z tą samą dyscypliną, jak każdą inną część inżynierii.
Zaczyna się od spisania założeń zanim napiszesz kod. Jeśli nie potrafisz powiedzieć, co musi być prawdą, żeby funkcja działała, nie będziesz w stanie później jej debugować. Przykłady:
To są testowalne stwierdzenia.
Bazy (baselines) są kolejne. Baza to najprostsza rzecz, która może zadziałać, i twój punkt odniesienia. Może to być zestaw reguł, szablon wyszukiwania, a nawet „nic” z dobrym UI. Silne bazy chronią przed spędzeniem tygodni nad wyszukanym modelem, który nic nie przebija.
Instrumentacja umożliwia iterację. Jeśli patrzysz tylko na dema, sterujesz „na wyczucie”. Dla wielu funkcji AI mały zestaw liczb wystarczy, by powiedzieć czy się poprawiasz:
Potem iteruj w krótkich pętlach. Zmień jedną rzecz, porównaj do bazy i prowadź prosty log tego, co próbowałeś i co się zmieniło. Gdy postęp jest realny, widać go na wykresie.
Wysyłanie AI działa najlepiej, gdy traktujesz je jak inżynierię: jasne cele, baza i szybkie pętle informacji zwrotnej.
Sformułuj problem użytkownika jednym zdaniem. Napisz to jak skargę, którą mógłby wypowiedzieć prawdziwy człowiek: „Agenci wsparcia trwonią za dużo czasu na pisanie odpowiedzi na typowe pytania.” Jeśli nie potrafisz tego ująć w jednym zdaniu, funkcja jest prawdopodobnie za duża.
Wybierz mierzalny wynik. Wybierz jedną liczbę, którą możesz śledzić co tydzień. Dobre opcje to czas oszczędzony na zadaniu, wskaźnik akceptacji pierwszego szkicu, redukcja edycji albo wskaźnik defleksji ticketów. Zdecyduj, co oznacza „wystarczająco dobre” zanim zbudujesz.
Zdefiniuj bazę, którą musisz pobić. Porównaj do prostego szablonu, podejścia regułowego lub „tylko człowiek”. Jeśli AI nie pobije bazy na wybranej metryce, nie wdrażaj.
Zaprojektuj mały test z reprezentatywnymi danymi. Zbierz przykłady odpowiadające rzeczywistości, włączając brudne przypadki. Zachowaj mały zbiór ewaluacyjny, na którym nie „trenujesz mentalnie” przez codzienne przeglądanie. Zapisz, co liczy się jako zaliczenie, a co jako porażka.
Wdrażaj za flagą, zbieraj feedback i iteruj. Zacznij od małej grupy wewnętrznej lub niewielkiego % użytkowników. Loguj wejście, wyjście i czy to pomogło. Najpierw napraw największy tryb awarii, potem ponownie uruchom ten sam test, żeby widzieć realny postęp.
Praktyczny wzorzec dla narzędzi do draftowania: mierz „sekundy do wysłania” i „% szkiców użytych po drobnych edycjach”.
Wiele porażek funkcji AI to nie błędy modelu. To porażki „nigdy nie uzgodniliśmy, co oznacza sukces”. Jeśli chcesz, by deep learning wydawał się praktyczny, zapisz założenia i miary zanim zaczniesz stroić prompt lub trenować modele.
Zacznij od założeń, które mogą złamać funkcję w rzeczywistej użyteczności. Częste dotyczą danych i ludzi: tekst wejściowy jest w jednym języku, użytkownicy żądają jednej intencji na raz, UI daje wystarczający kontekst, przypadki brzegowe są rzadkie, a wczorajszy wzorzec będzie nadal prawdziwy za miesiąc (drift). Zapisz też, czego nie będziesz obsługiwać na razie, np. sarkazmu, porad prawnych czy długich dokumentów.
Przekształć każde założenie w coś, co możesz przetestować. Użyteczny format: „Dając X, system powinien zrobić Y, a można to zweryfikować przez Z.” Trzymaj to konkretne.
Pięć rzeczy, które warto zapisać na jednej stronie:
Celowo trzymaj offline i online oddzielnie. Metryki offline mówią, czy system nauczył się zadania. Metryki online mówią, czy funkcja pomaga ludziom. Model może dobrze wypaść offline, a mimo to irytować użytkowników, bo jest wolny, zbyt pewny siebie albo błędny tam, gdzie to istotne.
Zdefiniuj „wystarczająco dobrze” jako progi i konsekwencje. Przykład: „Offline: co najmniej 85% poprawnych na zbiorze ewaluacyjnym; Online: 30% szkiców akceptowanych po drobnych edycjach.” Jeśli nie osiągniesz progu, ustal z wyprzedzeniem, co wtedy robisz: trzymaj za flagą, zmniejsz rollout, kieruj przypadki o niskim zaufaniu do szablonu lub wstrzymaj się i zbierz więcej danych.
Zespoły często traktują funkcję AI jak zwykłą poprawkę UI: wypuść, zobacz co się stanie, popraw później. To szybko zawodzi, bo zachowanie modelu może zmieniać się wraz z promptami, dryftem i małymi zmianami konfiguracji. Efekt: dużo wysiłku bez jasnego dowodu, że pomogło.
Praktyczna zasada jest prosta: jeśli nie potrafisz nazwać bazy i pomiaru, jeszcze nie wysyłasz.
Najczęstsze tryby porażki:
Przykład: dodajesz AI do draftowania odpowiedzi. Jeśli liczysz tylko kciuk w górę, możesz nie zauważyć, że agenci potrzebują więcej czasu na przegląd szkiców, albo że odpowiedzi są poprawne, ale za długie. Lepsze miary to „% wysłanych z minimalnymi edycjami” i „mediana czasu do wysłania”.
Traktuj dzień wydania jak przekazanie inżynierskie, nie demo. Powinieneś umieć prosto wyjaśnić, co robi funkcja, jak wiesz, że działa i co zrobisz, gdy się zepsuje.
Przed wypuszczeniem upewnij się, że masz:
Trzymaj też offline zbiór ewaluacyjny, który wygląda jak rzeczywisty ruch, zawiera przypadki brzegowe i jest wystarczająco stabilny, by porównywać tygodniami. Gdy zmieniasz prompt, model lub czyszczenie danych, ponownie uruchom ten sam zestaw i zobacz, co się przesunęło.
Zespół wsparcia chce asystenta, który szkicuje odpowiedzi w widoku ticketu. Agent nie wysyła wiadomości automatycznie. Asystent sugeruje szkic, podkreśla kluczowe fakty i prosi agenta o sprawdzenie i edycję przed wysłaniem. Ten wybór obniża ryzyko i pozwala uczyć się bezpiecznie.
Zacznij od ustalenia, co znaczy „lepiej” liczbami. Wybierz wyniki, które możesz mierzyć od pierwszego dnia używając istniejących logów:
Zanim włączysz model, ustaw nudną, ale realistyczną bazę: zapisane szablony plus warstwa reguł (wykryj refundację vs wysyłkę vs reset hasła i wypełnij najlepszy szablon). Jeśli AI nie pobije tej bazy, nie jest gotowe.
Uruchom mały pilotaż. Niech będzie opcjonalny dla kilku agentów, ograniczony do jednej kategorii ticketów (np. status zamówienia). Dodaj szybki feedback przy każdym szkicu: „pomocne” lub „niepomocne” z krótkim powodem. Zbieraj też, co agent zmienił, nie tylko czy kliknął przycisk.
Zdefiniuj kryteria wysyłki z góry, aby później nie zgadywać. Na przykład: czas obsługi poprawia się o 10% bez wzrostu eskalacji czy ponownych otwarć, a agenci akceptują szkice z minimalnymi edycjami przynajmniej w 30% przypadków.
Ustal też, co wywoła rollback: skok eskalacji, spadek satysfakcji lub powtarzające się błędy polityki.
Wybierz jeden pomysł AI, który możesz wypuścić w 2–4 tygodnie. Trzymaj go na tyle małym, by można było go zmierzyć, debugować i wycofać bez dramatu. Celem nie jest udowodnienie, że model jest inteligentny. Celem jest realna poprawa wyniku użytkownika względem tego, co już macie.
Przekształć pomysł w jednostronicowy plan: co funkcja robi, czego nie robi i jak sprawdzisz, że działa. Dołącz bazę i dokładną metrykę, którą będziesz śledzić.
Jeśli chcesz szybko przejść do implementacji, Koder.ai (koder.ai) jest zbudowany wokół tworzenia aplikacji webowych, serwerowych i mobilnych przez interfejs czatu, z funkcjami takimi jak snapshoty/rollback i eksport kodu źródłowego, gdy potrzebujesz głębszej kontroli.
Nawyk, który warto zachować, jest prosty: każda zmiana AI powinna iść w parze ze spisanym założeniem i mierzalnym wynikiem. Dzięki temu deep learning przestaje być magią, a staje się pracą, którą można wypuścić.
Ponieważ dema zwykle opierają się na czystych, starannie dobranych wejściach i są oceniane „na wyczucie”, a produkty muszą radzić sobie z brudnymi danymi, presją użytkownika i powtarzalnym użyciem.
Aby zmniejszyć lukę: zdefiniuj kontrakt wejścia/wyjścia, mierz jakość na reprezentatywnych danych i zaprojektuj fallbacky na timeouty oraz przypadki o niskim zaufaniu.
Wybierz jedną metrykę związaną z wartością dla użytkownika, którą możesz śledzić co tydzień. Dobre domyślne wybory:
Ustal cel „wystarczająco dobry” zanim zaczniesz stroić prompt lub model.
Użyj najprostszej alternatywy, którą realistycznie można wdrożyć:
Jeśli AI nie przebije bazy na głównej metryce (bez łamania latency/kosztów), nie wdrażaj go jeszcze.
Utrzymuj mały zbiór przypominający rzeczywisty ruch, nie tylko najlepsze przykłady.
Praktyczne zasady:
To sprawia, że postęp jest widoczny i zmniejsza przypadkowe regresje.
Zacznij od przewidywalnych, testowalnych guardrails:
Traktuj guardrails jako wymagania produktowe, a nie opcjonalne poprawki.
Monitoruj zarówno zdrowie systemu, jak i jakość outputu:
Loguj też wejścia/wyjścia (z kontrolami prywatności), żeby odtwarzać błędy i naprawiać najczęstsze wzorce.
Ustal maksymalny budżet wcześniej: docelowa latencja i maksymalny koszt na zapytanie.
Potem zmniejszaj wydatki bez zgadywania:
Mały wzrost jakości rzadko jest wart dużego spadku prędkości lub wzrostu kosztów w produkcji.
Wdrażaj za flagą i rozszerzaj stopniowo.
Praktyczny plan rolloutu:
Rollback to nie porażka; to element utrzymania AI.
Minimalne role, które trzeba pokryć (nawet jeśli jedna osoba pełni kilka ról):
Wysyłka działa najlepiej, gdy wszyscy zgadzają się co do metryki, bazy i planu rollbacku.
Używaj go, gdy chcesz szybko przejść od pomysłu do działającej aplikacji, ale zachować dyscyplinę inżynierską.
Praktyczny workflow:
Narzędzie przyspiesza iterację; wciąż potrzebujesz jasnych założeń i mierzalnych wyników.