Andrej Karpathy i deep learning: lekcje dotyczące wdrażania AI

Dlaczego deep learning często trudno użyć w prawdziwych produktach

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:

• Powtarzalne: zachowuje się przewidywalnie na powszechnych wejściach, nie tylko na wyselekcjonowanych demach.
• Mierzalne: możesz zdefiniować „dobrze” liczbą, a nie odczuciem.
• Utrzymalne: możesz aktualizować dane, prompty lub modele bez łamania wszystkiego.
• Operacyjne: możesz monitorować błędy, koszty, opóźnienia i jakość po wydaniu.

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.

Wczesna praca: traktowanie sieci neuronowych jak inżynierię, nie magię

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:

• Zacznij od bazowego rozwiązania, które możesz pokonać, nawet jeśli jest proste.
• Wybierz jedną metrykę, która decyduje o „lepsze” vs „gorsze”.
• Zmieniaj jedną rzecz naraz, żeby wiedzieć, co spowodowało efekt.
• Analizuj błędy i przykłady, nie tylko końcowy wynik.

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.

Uczynienie sieci neuronowych zrozumiałymi dla inżynierów

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.

Wyjaśnij to, jakbyś miał to utrzymywać

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:

• Jakie jest dokładne wejście i wyjście (format, limity, redakcje)?
• Jakiej bazy musisz pokonać (reguły, wyszukiwanie, szablony lub mniejszy model)?
• Jak wygląda „dobrze” (liczba, rubryka lub oba)?
• Które błędy są niedopuszczalne (bezpieczeństwo, prywatność, ton marki)?
• Kto przegląda wyniki i jak często?

Reprodukowalność jest częścią wyjaśnienia

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.

Z prototypu do produkcji: co się zmienia przy wdrożeniu

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.

Ograniczenia, które nagle stają się ważne

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ń:

• Jaki jest maksymalny dopuszczalny czas odpowiedzi i koszt na zapytanie?
• Co robi fallback, gdy model zawiedzie lub wygaśnie czas?
• Jakie metryki definiują jakość i jakie progi wywołują alerty?
• Jak zapobiegać niebezpiecznym lub niezgodnym wyjściom?
• Jak szybko wycofać, jeśli jakość spadnie?

To wymaga więcej niż umiejętności modelu

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.

Kultura inżynierska: założenia, bazy i iteracja

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:

• „Użytkownicy zaakceptują sugerowaną odpowiedź, jeśli jest poprawna i pasuje do ich tonu.”
• „Wymagana jest latencja poniżej 800 ms, inaczej ludzie przestaną z tego korzystać.”

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:

• Adopcja (kto próbuje i dalej używa)
• Jakość (wskaźnik akceptacji, edycje przed wysłaniem, kciuk w górę/w dół)
• Szybkość (latencja i czas do pierwszego użytecznego wyniku)
• Koszt (tokeny, compute, czas przeglądu ludzkiego)
• Bezpieczeństwo (naruszenia polityk, wycieki danych, próby jailbreak)

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.

Krok po kroku: prosty workflow do wdrażania funkcji AI

Wysyłanie AI działa najlepiej, gdy traktujesz je jak inżynierię: jasne cele, baza i szybkie pętle informacji zwrotnej.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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”.

Jasne założenia i mierzalne wyniki (co zapisać)

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:

• Wejścia: co model widzi (pola, limity, redakcje) i co oznacza „wystarczająco czyste”
• Kontrakt wyjścia: co musi zwrócić (format, ton, dozwolone akcje)
• Ewaluacja offline: mały zestaw z etykietami z zasadami punktacji (zaliczenie/oblanie plus metryka)
• Metryka online: co robią użytkownicy (wskaźnik akceptacji, edycje, zaoszczędzony czas, ponowne otwarcia ticketów)
• Guardrails: kiedy odmówić, dopytać lub przejść do prostszego flow

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.

Najczęstsze błędy zespołów dodających AI do produktu

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:

• Wydanie bez nie-AI bazy, więc poprawa jest nieudowodniona.
• Gonienie jakości kosztem latencji i kosztów (3% gain nie wart 5x spowolnienia).
• Poleganie na niejasnym feedbacku („użytkownicy to lubią”) zamiast instrumentacji.
• Strojenie na maleńkim lub wyselekcjonowanym zbiorze, który nie odzwierciedla ruchu.
• Brak planu rollbacku, gdy prompt lub update modelu generuje dziwne wyjścia.

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”.

Szybka lista kontrolna przed wydaniem

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:

• Jednozdaniowe stwierdzenie problemu i jasnych docelowych użytkowników.
• Zmierzoną bazę (nawet jeśli jest prosta).
• Jedną główną metrykę online powiązaną z wartością użytkownika oraz logi przechwytujące wejścia, wyjścia i rezultaty.
• Przegląd bezpieczeństwa: prawdopodobne tryby awarii, kto może ucierpieć i co UI robi (ostrzeżenie, blokada, prośba o potwierdzenie).
• Plan rollbacku z właścicielem: co wywołuje rollback i co sprawdzić w pierwszej godzinie.

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.

Przykład scenariusza: wdrażanie funkcji draftowania odpowiedzi dla supportu

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:

• Średni czas obsługi (od otwarcia do rozwiązania)
• Wskaźnik edycji (ile agenci zmieniają szkice przed wysłaniem)
• Wskaźnik eskalacji (przepięcie ticketów na wyższe poziomy)
• Wskaźnik ponownych otwarć (ticketów ponownie otwartych w ciągu 7 dni)
• Wynik satysfakcji klienta (jeśli już go śledzisz)

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.

Następne kroki: zastosuj te lekcje przy kolejnym wydaniu AI

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ć.