Wyobraź sobie, że kładziesz się spać, a Twoja karta graficzna przez całą noc „mieli” kod treningowy modelu AI, testując odważne hipotezy i śrubując wyniki. Andrej Karpathy, wizjoner znany z Tesli i OpenAI, właśnie urzeczywistnił ten scenariusz w swoim najnowszym projekcie autoresearch. Ten niepozorny, liczący 630 linii skrypt otwiera drzwi do nowej ery, w której ludzie zajmują się wysokopoziomowym projektowaniem, a żmudne badania oddają w ręce maszyn.

TL;DR

  • Autoresearch to zaledwie 630 linii kodu w Pythonie (licencja MIT), które automatyzują optymalizację treningu LLM na pojedynczym GPU.
  • W ciągu jednej nocy agent przeprowadził 126 eksperymentów, obniżając stratę walidacyjną z poziomu 0.9979 do 0.9697.
  • Dwa dni pracy i 700 autonomicznych zmian przyniosły 20 realnych ulepszeń, skracając czas osiągnięcia poziomu GPT-2 o 11%.
  • Społeczność już adaptuje narzędzie do sieci P2P i marketingu, osiągając nawet 333 testy w jedną noc.
  • Karpathy twierdzi, że to dopiero początek – emulacja pracy doktoranta wkrótce zmieni się w działanie całego roju cyfrowych badaczy.

Czym jest autoresearch i skąd się wziął

Andrej Karpathy, były szef działu AI w Tesli i jeden z ojców założycieli OpenAI, udostępnił na GitHubie skrypt o nazwie autoresearch. To minimalistyczny system – zamknięty w zaledwie 630 liniach kodu – który pozwala agentom AI na całkowicie samodzielne prowadzenie badań nad procesem uczenia modeli językowych. Całość została zaprojektowana tak, by działać na pojedynczym procesorze graficznym (GPU), bez konieczności stosowania skomplikowanego treningu rozproszonego, narzucając sztywny limit 5 minut na pojedynczy eksperyment.

Cyfrowy agent otrzymuje plik train.py z kodem treningowym, wytyczne w pliku program.md oraz stały budżet obliczeniowy. Maszyna analizuje kod źródłowy, formułuje hipotezę – na przykład modyfikację szybkości uczenia (learning rate) czy zmianę głębokości architektury – po czym modyfikuje plik i uruchamia test. Wszystko to odbywa się pod bardzo liberalną licencją MIT, co jest jasnym sygnałem dla firm, że mogą śmiało eksperymentować z tym rozwiązaniem.

Karpathy zaznacza, że jego celem jest stworzenie agentów zdolnych do generowania niekończącego się postępu badawczego bez jakiejkolwiek interwencji człowieka. Zamiast ręcznego „kręcenia gałkami” i żmudnego dobierania hiperparametrów, sztuczna inteligencja sama iteruje nad rozwiązaniami. Brzmi to jak czyste science-fiction, ale ten system naprawdę działa na domowym sprzęcie.

Jak działa autonomiczna pętla optymalizacji?

Cały proces jest genialny w swojej prostocie. Na początku użytkownik jednorazowo uruchamia skrypt prepare.py, który przygotowuje dane i konfiguruje tokenizer BPE. Następnie wyznacza się tzw. baseline: ręcznie uruchamia się train.py na 5 minut, aby sprawdzić kluczową metrykę val_bpb – czyli stratę walidacyjną wyrażoną w bitach na bajt (im niższa wartość, tym lepsza kompresja tekstu i predykcja modelu).

Agent, napędzany przez zaawansowane modele językowe takie jak Claude czy GPT, analizuje pliki wejściowe i proponuje konkretną zmianę. Może to być edycja architektury, modyfikacja optymalizatora Muon+AdamW czy usprawnienie samej pętli treningowej. Zmiana jest zapisywana jako nowa gałąź w systemie Git, po czym następuje dokładnie 5-minutowy trening i ocena wyniku val_bpb zapisanego w pliku results.tsv. Jeśli rezultat jest lepszy od poprzedniego, zmiana zostaje zachowana; w przeciwnym razie następuje powrót do poprzedniej wersji (revert) i kolejna próba. W ten sposób system wykonuje około 12 eksperymentów na godzinę, co daje ponad 100 testów w ciągu jednej nocy.

Co istotne, pliki konfiguracyjne prepare.py i program.md pozostają nienaruszone – agent ma prawo modyfikować wyłącznie train.py. Taka struktura idealnie emuluje pracę ambitnego doktoranta: postawienie hipotezy, test, ewaluacja i kolejna iteracja. Choć Karpathy testował to rozwiązanie na potężnym układzie H100, liczne forki projektu dowodzą, że skrypt radzi sobie świetnie także na komputerach Mac z procesorem M4 czy systemach Windows.

Pierwsze wyniki: od ręcznego tuningu do automatu

Podczas pierwszego poważnego sprawdzianu Karpathy zostawił agenta samopas na całą noc, pracując nad modelem o głębokości 12 warstw. Efekt? Po 126 eksperymentach wskaźnik val_bpb spadł z 0.9979 do 0.9697. Po dwóch dniach i przeprowadzeniu 700 autonomicznych zmian, aż 20 z nich okazało się na tyle skutecznych, że z powodzeniem przeniesiono je na znacznie większe modele o głębokości 24 warstw.

Te drobne, ale liczne ulepszenia pozwoliły skrócić czas potrzebny na osiągnięcie wydajności legendarnego modelu GPT-2 z 2,02 godziny do zaledwie 1,80 godziny – co oznacza 11% czystego zysku na efektywności. Co ciekawe, agent wyłapał błędy, których sam Karpathy nie dostrzegł przez dwie dekady pracy w branży: brak odpowiedniego skalera w mechanizmie QKnorm (co powodowało rozproszoną uwagę modelu), brak regularyzacji w Value Embeddings, zbyt zachowawcze podejście do banded attention czy błędy w parametrach beta optymalizatora AdamW.

Widzieć agenta wykonującego cały proces badawczy samodzielnie… to po prostu szalone.

Karpathy przyznaje, że nie są to może odkrycia na miarę Nobla, ale realne, techniczne poprawki w już i tak mocno zoptymalizowanym projekcie nanochat. Poniższa tabela prezentuje najważniejsze usprawnienia wypracowane przez AI:

Ulepszenie Opis Efekt
QKnorm scaler Dodał mnożnik skalujący uwagę Wyostrzył uwagę modelu
Value Embeddings reg. Wprowadził regularyzację Lepsza stabilność treningu
Banded attention Dostroił szerokość okna Mniej konserwatywne podejście
AdamW betas Zoptymalizował parametry beta Sprawniejszy optymalizator
Weight decay sched. Dostroił harmonogram zanikania Optymalny poziom decay
Inicjalizacja sieci Poprawił parametry startowe Szybsza zbieżność modelu

Kluczowe ulepszenia znalezione przez agenta autoresearch w projekcie nanochat.

Społeczność eksperymentuje: od P2P do marketingu

Reakcja branży była natychmiastowa – wpis Karpathy’ego wygenerował ponad 8,6 mln wyświetleń. Varun Mathur z Hyperspace AI poszedł o krok dalej i rozproszył pętlę badawczą na całą sieć peer-to-peer. Efekt? Grupa 35 agentów w nocy z 8 na 9 marca przeprowadziła łącznie 333 eksperymenty. Wykorzystano niesamowitą różnorodność sprzętową – od potężnych jednostek H100 po zwykłe laptopy, które skupiły się na optymalizacji inicjalizacji wag (metody Kaiming i Xavier) oraz normalizacji.

Dzięki protokołowi GossipSub sukcesy jednego agenta błyskawicznie rozprzestrzeniały się w sieci. Przykładowo, nowa metoda inicjalizacji Kaiming przyniosła 21-procentowy spadek straty, a w ciągu zaledwie godziny zaadoptowały ją 23 inne agenty. W ciągu 17 godzin systemy te „odkryły na nowo” RMSNorm oraz tied embeddings – techniki, które w Google Brain i OpenAI były owocem lat żmudnych badań ludzkich ekspertów.

Z kolei Eric Siu z Single Grain dostrzegł potencjał autoresearch w marketingu. Zamiast przeprowadzać 30 testów A/B rocznie, firma może ich teraz wykonać ponad 36 500. Zmienia się tylko obiekt badań: zamiast pliku train.py optymalizowany jest landing page lub treść maila, a kluczową metryką staje się współczynnik odpowiedzi (reply rate). Firmy nie będą już wygrywać lepszymi marketerami, lecz sprawniejszymi pętlami eksperymentów, które działają, gdy zespół smacznie śpi.

Problemy i dyskusje na GitHub

Jak to zwykle bywa w świecie open source, projekt nie uniknął krytyki. Użytkownik Alexisthual podniósł ważną kwestię: czy setki eksperymentów przeprowadzanych jeden po drugim nie prowadzą do „zepsucia” zbioru walidacyjnego? Nadmierna optymalizacja pod konkretne testy może bowiem dawać złudne poczucie postępu, które nie przekłada się na ogólną inteligencję modelu.

Z kolei Samionb poddał w wątpliwość skalę spadku val_bpb, na co Karpathy odpowiedział krótko: „Optymalizujemy wydajność w przeliczeniu na moc obliczeniową, to są realne zyski”. Ciekawy przypadek opisał Witcheer, który testował skrypt na Mac Mini M4: na 35 przeprowadzonych testów aż 26 zakończyło się niepowodzeniem, ale 7 sukcesów wystarczyło, by model stał się lepszy dzięki uproszczeniu kodu.

Dyskusje na GitHubie ujawniają też techniczne ograniczenia: agenty oparte na modelu Codex miewają problemy z poprawnym domykaniem pętli (zgłoszenie issue #57). Karpathy planuje wprowadzenie interaktywnych sesji w tmux zamiast pracy w trybie headless. To wyraźnie pokazuje, że choć AI świetnie radzi sobie z iteracjami, wciąż potrzebuje ludzkiego nadzoru w sytuacjach skrajnych i nietypowych.

Przyszłość: od pojedynczego agenta do roju

Dla Karpathy’ego obecny autoresearch to zaledwie ziarno, z którego wyrośnie coś znacznie większego. Kolejnym krokiem ma być asynchroniczna współpraca agentów, przypominająca ideę projektu SETI@home. Chodzi o emulację całej społeczności badaczy, a nie tylko jednego, cyfrowego doktoranta. Prototypem takiego rozwiązania jest AgentHub, gdzie tysiące commitów na różnych gałęziach tworzą żywy ekosystem.

Każda dziedzina, w której metryki można ocenić w krótkim czasie – od uczenia maszynowego, przez marketing, aż po diagnostykę medyczną – idealnie nadaje się do wdrożenia autoresearch. Wąskim gardłem przestaje być samo pisanie kodu, a staje się nim umiejętne definiowanie kierunków poszukiwań. Podobnie jak w przypadku, gdy AI rozwiązało problem Erdősa #728 prawie samodzielnie, co Terence Tao nazwał nowym rozdziałem w nauce, tak autoresearch redefiniuje rolę człowieka. Stajemy się projektantami eksperymentów, a nie ich wykonawcami.

Ironią losu jest fakt, że Karpathy po raz kolejny zmienia zasady gry: zamiast mozolnie kodować modele, zaczynamy siać cyfrowe ekosystemy, które uczą się i doskonalą we śnie. Giganci tacy jak OpenAI z pewnością wdrożą to na masową skalę – roje agentów będą tunować mniejsze modele, a najlepsze rozwiązania będą automatycznie promowane do potężnych systemów klasy frontier.

Źródła: VentureBeat (https://venturebeat.com/technology/andrej-karpathys-new-open-source-autoresearch-lets-you-run-hundreds-of-ai), GitHub karpathy/autoresearch, tweety Karpathy’ego (@karpathy statusy 2030371219518931079 i 2031135152349524125)

Najczęściej zadawane pytania