AutoResearch Karpathy'ego: co się dzieje, gdy AI prowadzi badania przez noc

W marcu 2026 roku Andrej Karpathy, współzałożyciel OpenAI i były dyrektor ds. AI w Tesli, opublikował framework o nazwie AutoResearch. Założenie jest proste: w pliku tekstowym opisuje się, co ma zostać zbadane, uruchamia system przed pójściem spać i następnego ranka otrzymuje się około 100 zakończonych eksperymentów machine learning z wynikami posortowanymi według wydajności. W trzy tygodnie projekt zebrał 65 000 gwiazdek na GitHubie. Tempo adopcji odzwierciedla coś realnego w tym, co projekt reprezentuje, nie tylko w tym, co robi.

Co AutoResearch faktycznie robi

AutoResearch uruchamia agenta AI do kodowania na pojedynczym skrypcie treningowym. Agent modyfikuje skrypt, przeprowadza pięciominutowy eksperyment treningowy, mierzy wynik za pomocą metryki walidacyjnej val_bpb (bity na bajt, miara wydajności modeli językowych) i decyduje, czy zachować zmianę, czy ją odrzucić. Jeśli zmiana poprawia wynik, staje się nowym punktem bazowym. W przeciwnym razie agent cofa zmianę i próbuje czegoś innego. Ta pętla działa nieprzerwanie, generując około 12 eksperymentów na godzinę, czyli mniej więcej 100 przez noc.

Stały budżet pięciu minut na eksperyment to celowa decyzja projektowa. Sprawia, że wyniki są porównywalne między uruchomieniami, zapobiega poświęcaniu przez agenta nieproporcjonalnie dużo czasu na jedną hipotezę i mieści się w profilu kosztów pojedynczego GPU H100 działającego przez noc. To ograniczenie zmusza system do pracy wydajnej, a nie wyczerpującej.

Architektura trzech plików

System jest zorganizowany wokół trzech plików, każdy z odrębną rolą:

• prepare.py jest stały. Zajmuje się przygotowaniem danych i nigdy się nie zmienia. To utrzymuje stabilne środowisko eksperymentalne, dzięki czemu różnice w wynikach odzwierciedlają rzeczywiste różnice modeli, a nie zmiany w potoku danych.
• train.py to płótno agenta. Zaczyna jako bazowy skrypt treningowy i jest modyfikowany, rozszerzany i udoskonalany przez agenta w setkach iteracji. Rano może wyglądać zupełnie inaczej niż na początku.
• program.md jest pisany przez człowieka. Tu opisuje się strategię badawczą: jakie podejścia eksplorować, jakie ograniczenia respektować, jakie hipotezy testować. To jedyna rzecz, którą człowiek musi napisać.

Prostota jest zamierzona. Ograniczenie modyfikacji do jednego pliku (train.py) sprawia, że każda zmiana jest możliwa do przejrzenia. Można spojrzeć na diff między poranną wersją a punktem startowym i zrozumieć, co agent faktycznie zrobił. Jest to trudniejsze do osiągnięcia, gdy agenci jednocześnie ingerują w wiele plików.

Strategia badawcza, nie kod

Ujęcie roli człowieka przez Karpathy'ego zasługuje na bezpośrednie przytoczenie. Opisuje to tak: "Przez 99% czasu kod nie jest pisany bezpośrednio. Orkiestruje się agentów." Zadaniem człowieka jest pisanie program.md, które Karpathy nazywa "kodem organizacji badawczej", strategią wysokiego poziomu definiującą, co agent ma realizować.

To znaczące przesunięcie względem sposobu, w jaki większość środowisk myśli obecnie o narzędziach AI do kodowania. Dominujące ujęcie pozycjonuje AI jako asystenta przyspieszającego pisanie kodu. AutoResearch odwraca tę logikę: agent pisze kod, prowadzi eksperymenty i ocenia wyniki. Człowiek pisze kierunek badań. Produktem pracy człowieka jest dokument strategiczny, a nie implementacja.

Czy takie podejście generalizuje się poza badania ML, pozostaje otwartą kwestią. W domenie iteracyjnej eksperymentacji, gdzie celem jest przeszukanie dużej przestrzeni możliwych podejść i zidentyfikowanie tego, co działa, model pasuje jednak doskonale. Agent może przeszukać tę przestrzeń znacznie szybciej niż jakikolwiek ludzki zespół.

Co pokazują liczby

Karpathy uruchamiał AutoResearch na osobistym projekcie przez dwa dni i odnotował około 700 autonomicznych zmian kodu. Z tych mniej więcej 20 przyniosło addytywne ulepszenia, które złożyły się na znaczący postęp. Skumulowany efekt to 11-procentowy wzrost wydajności w rankingu Time to GPT-2, benchmarku mierzącym, jak efektywnie model osiąga poziom wydajności GPT-2.

Wskaźnik trafień na poziomie około 3% może wydawać się niski. Wystarczy jednak rozważyć alternatywę: ręczne przeprowadzenie 700 eksperymentów przez badacza zajęłoby miesiące. Agent wykonuje to przez noc. Ekonomika zmienia się całkowicie, gdy koszt nieudanego eksperymentu spada do pięciu minut czasu GPU zamiast dni ludzkiego wysiłku.

Uczciwy mechanizm porównywania

Stały budżet pięciu minut rozwiązuje też subtelny problem w badaniach ML: jak uczciwie porównywać podejścia różniące się złożonością obliczeniową? Technika wymagająca dwukrotnie więcej obliczeń wyglądałaby korzystniej przy dłuższym treningu, nawet gdyby nie była lepsza. Utrzymując stały czas, AutoResearch zapewnia, że ulepszenia odzwierciedlają rzeczywiste zyski algorytmiczne, a nie strategie oparte na zwiększaniu nakładów obliczeniowych.

Decyzje projektowe, które mają znaczenie

Kilka wyborów projektowych AutoResearch wywodzi się z praktyki produkcyjnych systemów ML:

Te ograniczenia czynią system zrozumiałym. Potężniejszy agent z mniejszymi restrykcjami mógłby dawać szybsze, ale trudniejsze do interpretacji wyniki. AutoResearch poświęca część surowej zdolności na rzecz czytelności, co ma znaczenie wszędzie tam, gdzie chodzi o faktyczne uczenie się z odkryć agenta.

Szerszy sygnał: samodoskonaląca się AI

Opis tego, co reprezentuje AutoResearch, jest bardziej znaczący niż samo narzędzie. Karpathy nazywa je początkiem "epoki pętli samodoskonalenia AI": systemów, w których agenci AI prowadzą badania sprawiające, że przyszłe systemy AI są lepsze. Pętla wygląda następująco: lepsi agenci prowadzą lepsze eksperymenty, odkrywają lepsze techniki treningowe, produkują lepsze modele, które stają się lepszymi agentami.

Badacze teoretyzują o rekurencyjnym samodoskonaleniu od dekad. Nowością jest infrastruktura mieszcząca się na pojedynczym GPU, którą można skonfigurować w jedno popołudnie, przynajmniej w ograniczonej domenie. AutoResearch demonstruje jeden konkretny element tej pętli: eksperymentalne poszukiwania sterowane przez AI, dające prawdziwe, mierzalne ulepszenia wydajności treningu AI.

Implikacje wykraczają poza badania ML. Każda domena z jasną metryką oceny, modyfikowalnym artefaktem i dużą przestrzenią poszukiwań możliwych podejść jest kandydatem do tego wzorca. Optymalizacja oprogramowania, odkrywanie leków, nauka o materiałach, modelowanie finansowe. Wąskim gardłem jest w każdym przypadku koszt przeprowadzania eksperymentów; obniżenie tego kosztu zmienia to, co jest wykonalne.

Rozszerzenia społeczności

W ciągu kilku dni od wydania społeczność rozszerzyła AutoResearch na sprzęt, który nie był częścią oryginalnego projektu:

• macOS z Apple Silicon przez MLX, zapewniając dostęp bez kosztów GPU w chmurze dla użytkowników Maców z chipami z serii M
• Windows z kartami RTX przez forki społeczności adaptujące potok treningowy do CUDA na sprzęcie konsumenckim
• Karty AMD przez adaptacje oparte na ROCm dla użytkowników spoza ekosystemu NVIDIA

Szerokość adaptacji społeczności odzwierciedla autentyczne zainteresowanie wykraczające poza środowisko badań ML. Deweloperzy poza tym środowiskiem mają teraz ścieżkę do eksperymentów z optymalizacją treningu na sprzęcie, który już posiadają.

Kryteria oceny dla zespołów

AutoResearch to narzędzie badawcze. Zespoły mogą ponownie wykorzystać jego pętlę: wygenerować kandydata, przetestować go, uchwycić niepowodzenia, a następnie uruchomić kolejną iterację z uwzględnieniem tych niepowodzeń.

Rola człowieka się zmienia

Gdy agent prowadzi eksperymenty, wartość człowieka tkwi w zadawaniu właściwych pytań. Napisanie dobrego program.md wymaga rozumienia, które podejścia warto eksplorować, jakie ograniczenia mają znaczenie i jak naprawdę wygląda sukces. To praca na wyższym poziomie niż pisanie kodu, wymagająca wiedzy domenowej i osądu. Praca przesuwa się od implementacji w stronę kierowania.

Nocna zdolność obliczeniowa jest niedostatecznie wykorzystana

Większość zespołów korzystających z infrastruktury chmurowej dysponuje bezczynną pojemnością GPU w nocy. AutoResearch stawia tezę, że ta pojemność mogłaby wykonywać produktywną pracę eksperymentalną zamiast pozostawać niewykorzystana. Pytanie dla każdego zespołu z wyraźnym celem optymalizacji i testowalną metryką brzmi: czy ten sam wzorzec ma zastosowanie do jego problemu.

Czytelność musi być zaprojektowana od początku

Ograniczenie jednego pliku w AutoResearch to cecha czytelności. Gdy agenci mogą ingerować w dowolny element systemu, zrozumienie tego, co zrobili, wymaga znacznej inżynierii wstecznej. Projektowanie systemów, w których działania agentów są ograniczone i możliwe do audytowania, staje się coraz ważniejsze w miarę wzrostu autonomii. Zespoły zdolne ufać pracy agentów i iterować na niej to te, które interpretowalność zaprojektowały od samego początku.

Jak zacząć

AutoResearch jest dostępne na github.com/karpathy/autoresearch. Repozytorium zawiera instrukcje konfiguracji, przykładowe pliki program.md i dokumentację dotyczącą adaptacji do różnych zadań treningowych. Dla osób mających dostęp do H100 lub GPU obsługiwanego przez społeczność bariera wejścia dla pierwszego nocnego eksperymentu jest niska.

Ciekawsze pytanie dotyczy tego, co warto zbadać. AutoResearch dostarcza mechanizmu. Kierunek badań, jak zawsze, wywodzi się ze zrozumienia, które problemy są warte rozwiązania.

webvise współpracuje z zespołami integrującymi AI w przepływy pracy deweloperskiej i badawczej. Jeśli w centrum uwagi jest kwestia dopasowania autonomicznych agentów do procesów organizacji, prosimy o kontakt w celu praktycznej oceny tego, co ma sens w danym kontekście.