autoresearch – autonomní ML experiment loop

autoresearch je open-source framework od Andreje Karpathyho, který umožňuje AI agentovi autonomně provádět opakované ML experimenty bez zásahu člověka. Podle README je původní záměr jednoduchý: agent upravuje trénovací kód, spustí krátký běh, změří výsledek a podle metriky rozhodne, jestli změnu ponechat. Ve videu Claude Code + autoresearch je ten samý princip ukázaný i jako obecný pattern pro autonomní experimentování mimo ML.

Celý cyklus je přímočarý:

• Agent si přečte instrukce v program.md
• Navrhne změnu v train.py - architekturu, hyperparametry, optimizer
• Spustí trénink s fixním časovým rozpočtem 5 minut
• Změří výsledek podle metriky val_bpb
• Pokud je výsledek lepší, změnu ponechá; pokud horší, zahodí
• Cyklus se opakuje

Za noc tak může proběhnout přibližně 100 experimentů. Člověk nastaví pravidla hry v program.md, agent dělá experimenty sám.

prepare.py - jednosměrná příprava dat. Stáhne trénovací data, natrénuje BPE tokenizer a obsahuje pomocné runtime utility. Tento soubor se nemá upravovat.

train.py - jediný soubor, který agent edituje. Obsahuje architekturu GPT-like modelu, optimizer (Muon + AdamW) a celý trénovací loop. Agent může měnit hloubku modelu, batch size, attention pattern, regularizaci i scheduling.

program.md - instrukce pro agenta. Tento soubor upravuje člověk; nastavuje výzkumný směr, omezení a cíle experimentů.

Potřebuješ NVIDIA GPU a Python 3.10+.

curl -LsSf https://astral.sh/uv/install.sh | sh
uv sync
uv run prepare.py
uv run train.py

Repo je primárně dělané pro NVIDIA GPU. V README jsou zmíněné i komunitní forky pro macOS, Windows a AMD.

Všechny experimenty se v původním repu porovnávají podle jedné metriky - validation bits per byte (val_bpb). Čím nižší číslo, tím lepší model. Fixní časový rozpočet 5 minut zajišťuje, že jednotlivé běhy jsou přímo srovnatelné na stejném hardware.

Repo obsahuje:

• architekturu malého GPT-like modelu
• trénovací pipeline s optimizery Muon + AdamW
• skript pro přípravu dat a tokenizer
• jednoduchý pattern pro autonomní experiment loop

Repo neobsahuje:

• natrénované váhy ani hotový model ke stažení
• velký foundation model
• hotový marketingový nebo growth nástroj
• univerzální AutoML platformu pro libovolný problém

Při spuštění se model inicializuje s náhodnými vahami a trénuje se od nuly.

Video neprezentuje autoresearch jako hotový nástroj pro marketing. Používá ho hlavně jako pattern / framework pro autonomní experimentování: existuje baseline, objektivní metrika, experimentální varianta, vyhodnocení a rozhodnutí keep/discard.

V ukázce se tedy nemění train.py a neoptimalizuje se val_bpb. Místo toho se princip přenáší do cold email workflow:

• mutovaný artefakt je baseline.md s copy kampaně
• kontext a heuristiky jsou v resource.md
• historie pokusů je v results.log
• cílová metrika je positive reply rate
• nasazení běží přes API platformy Instantly
• orchestrace je plánovaná na GitHub Actions

Prakticky řečeno: video neukazuje „spusť repo a dostaneš marketingový autopilot“, ale „vezmi logiku autoresearch a přepiš ji pro jiný problém s měřitelným výsledkem“.

Podle videa a následného rozboru přes NotebookLM vypadá demo workflow přibližně takto:

1. Naklonuje se repozitář autoresearch jako referenční kostra
2. Spustí se Claude Code v terminálu nebo editoru
3. Zadá se prompt, aby stejný pattern použil místo ML pro cold email
4. V test.md se popíše cíl, metrika a test method
5. V resource.md se drží znalostní báze o tom, co zvyšuje reply rate
6. orchestrator.py řídí loop harvest → generate → deploy → measure → promote/revert
7. GitHub Actions nebo cron spouští tick v pravidelných intervalech
8. Instantly API dodává metriky a umožní nasadit nové varianty

Nejde tedy o to, že by původní ML kód najednou uměl marketing. Původní repo se použije hlavně jako architektonický vzor.

Video docela dobře ukazuje i rozdělení práce:

• Člověk definuje cíl, objektivní metriku, mantinely a dodá přístup k API
• AI agent navrhuje konkrétní hypotézy, píše integrační kód, spouští experimenty a vyhodnocuje výsledky
• Člověk udělá počáteční setup a průběžně hlídá, jestli systém nedělá něco nežádoucího
• AI agent běží 24/7 a je rychlejší v objemu iterací než člověk, i když jednotlivé rozhodnutí nemusí být vždy lepší

Praktický posun je v tom, že člověk je z velké části vytažený ze samotné experimentální smyčky. Nestará se o každou jednotlivou variantu, ale nastavuje systém a čte výsledky.

Člověk:
  - nastaví cíl
  - dodá API klíče
  - připraví počáteční know-how a omezení

Soubory:
  baseline.md     = aktuální nejlepší varianta
  resource.md     = shrnuté poznatky a heuristiky
  results.log     = historie pokusů a výsledků
  test.md         = cíl, metrika, test method
  orchestrator.py = pravidla smyčky

Smyčka:
  1. HARVEST
     - stáhni výsledky starších experimentů
     - porovnej baseline vs challenger

  2. PROMOTE / REVERT
     - challenger vyhrál -> stane se nový baseline
     - challenger prohrál -> zahodit

  3. GENERATE
     - vezmi baseline + resource + historii
     - vytvoř 1 nový challenger

  4. DEPLOY
     - pošli baseline i challenger na nové leady

  5. WAIT
     - po vyhodnocovacím okně se výsledek vrátí do další iterace

def scheduler_tick():
    matured = harvest_finished_experiments(older_than_hours=48)
 
    append_results_log(matured)
 
    if has_decisive_winner(matured.latest_pair):
        if matured.latest_pair.challenger_reply_rate > matured.latest_pair.baseline_reply_rate:
            promote_challenger_to_baseline()
            update_resource_md(with_lessons_from=matured.latest_pair)
        else:
            record_failed_hypothesis(matured.latest_pair)
            keep_current_baseline()
 
    prompt_context = {
        "baseline": read("baseline.md"),
        "resource": read("resource.md"),
        "goal": read("test.md"),
    }
 
    challenger = llm_generate_one_challenger(prompt_context)
    save_challenger(challenger)
 
    baseline_leads, challenger_leads = split_fresh_leads_evenly()
    deploy_campaign("baseline", read("baseline.md"), baseline_leads)
    deploy_campaign("challenger", challenger, challenger_leads)

Tento pseudokód není opsaný zdroják z videa. Je to zjednodušený model toho, co je na obrazovce a v komentáři videa vidět.

Tady je důležité neplést si dvě různé věci:

• původní repo optimalizuje model přes krátké trénovací běhy
• marketingová adaptace neaktualizuje váhy modelu z odpovědí na emaily

V marketingové verzi se systém „učí“ hlavně provozně:

• výsledek každého pokusu se zapíše do historie
• vítěz se stane novým baseline
• poznatky se shrnují do resource.md
• další challenger se generuje z baseline a těchto shrnutých learnings

Jinými slovy: nejde o gradient descent nad emaily, ale o automatizovaný experiment loop s pamětí v souborech.

Ve videu je potřeba rozlišit dva různé intervaly:

• scheduler interval - jak často se spouští orchestrátor, na screenu zhruba každé 4 hodiny
• measurement window - jak dlouho se čeká na použitelný výsledek experimentu, na screenu zhruba 48 hodin

To znamená, že čtyřhodinový tick není doba vyhodnocení experimentu. Je to jen cadence, ve které systém:

• zkontroluje starší běhy
• sklidí dozrálé výsledky
• rozhodne promote/revert
• vygeneruje další challenger
• nasadí nový baseline/challenger pár

Praktický dopad je tento:

• za 24 hodin vznikne asi 6 nových experimentů
• za 48 hodin se pipeline naplní
• ve steady state může běžet přibližně 12 paralelních experimentů, což odpovídá tomu, co je vidět na screenu

Dává to smysl hlavně jako průběžně naplňovaná pipeline, ne jako jednorázová dávka pokusů.

Rozumné přínosy takového rozdělení intervalů jsou:

• systém nemusí čekat celé 2 dny, než spustí další pokus
• lead volume se rozkládá průběžně v čase místo jedné velké dávky
• špatný challenger má menší blast radius než při hromadném spuštění mnoha variant naráz
• pozdější challengery mohou časem vycházet z novějších learnings, jakmile se začnou vracet první výsledky
• monitoring a zásahy jsou jednodušší než při jednorázovém vyrobení celé sady testů

Současně to má i slabiny:

• prvních zhruba 48 hodin systém ještě skoro nemá vlastní čerstvou zpětnou vazbu a opírá se hlavně o počáteční heuristiky v resource.md
• příliš krátký scheduler interval bez dostatečného objemu leadů může zvyšovat šum a dělit provoz na příliš malé vzorky
• příliš dlouhý scheduler interval zase zpomaluje throughput a učení celého systému

Jinými slovy: nejde hledat jeden „správný interval“, ale rozumný kompromis mezi rychlostí iterace, velikostí vzorku a rychlostí návratu signálu.

Z videa i z reportu vychází tři praktické podmínky, bez kterých se takový systém rozpadá:

• Rychlá nebo aspoň použitelná smyčka zpětné vazby - čím dřív se vrátí výsledek pokusu, tím rychleji se systém může posouvat dál
• Jasná objektivní metrika - ideálně něco jako reply rate, CTR, CVR nebo jiná metrika, která nejde snadno zaměnit za subjektivní dojem
• API nebo jiná programová ovladatelnost - agent musí umět změnit vstupy a zase si stáhnout výsledek bez ručního zásahu

Proto se ten pattern hodí hlavně tam, kde existuje měřitelný signál a kde lze experiment rozumně nasadit i vyhodnotit strojově.

Video i report zmiňují, že stejný princip by šel přenést i na další typy experimentů mimo trénování modelů. Typicky jde o situace, kde lze měnit vstup, měřit výsledek a iterovat:

• landing pages a jejich konverzní poměr
• reklamní kreativy a nadpisy
• zákaznické support skripty
• názvy nebo metadata videí, pokud existuje měřitelný signál a API

Tady je ale potřeba stejná opatrnost jako u cold emailů: čím pomalejší nebo hlučnější metrika, tím slabší bude celý loop.

Potvrzené z videa a zdrojů:

• původní repo mění train.py a optimalizuje val_bpb
• ve videu se princip používá pro cold email optimalizaci
• mutovaný soubor je baseline.md, ne ML trénovací kód
• video výslovně mluví o inspiraci Karpathyho patternem
• na obrazovce je vidět harvest/generate/deploy/measure/promote-or-revert loop
• learnings se zapisují do resource.md
• autor zmiňuje, že po stovkách běhů bude potřeba learnings konsolidovat
• na screenu je vidět scheduler cadence kolem 4 hodin a measurement window kolem 48 hodin

Rozumná interpretace:

• resource.md funguje jako pracovní paměť nebo komprimovaná znalostní báze
• kvalita návrhů se může časem zlepšovat hlavně díky akumulaci poznatků, ne díky „učení vah“
• delší historie bude muset být průběžně shrnovaná, aby kontext nerostl bez omezení
• stejný pattern jde přenést i mimo marketing, pokud existuje jasná metrika a API
• rozdělení na kratší scheduler interval a delší measurement window pomáhá udržet průběžně běžící pipeline experimentů

• feedback loop je výrazně pomalejší než v původním ML repu - ne minuty, ale spíš desítky hodin na vyhodnocení
• je potřeba dostatečný objem leadů, aby reply rate dával použitelný signál
• metrika je statistická a hlučnější než val_bpb
• systém se neučí gradient descentem z odpovědí; učí se hlavně přes logy, soubory a shrnuté poznatky
• dlouhodobě roste kontext v resource.md a historii výsledků, takže je potřeba průběžná konsolidace
• bez dobře definované objektivní metriky a API přístupu se pattern rozpadá

• automatické noční ladění malého LLM na konkrétním GPU
• hledání optimálních hyperparametrů
• testování různých architektur modelu
• sandbox pro pochopení agentic coding nad měřitelným cílem
• prototyp vlastního autonomního experiment loopu i mimo ML, pokud existuje jasná metrika a programové ovládání systému

• karpathy/autoresearch - GitHub
• karpathy/autoresearch - README
• YouTube: Claude Code + autoresearch
• VentureBeat: Andrej Karpathy's new open-source autoresearch