Mandag fandt vores AI-researchagent en kryptofuturesstrategi med en Sharpe-ratio på 4.1. Torsdag var resultatet 0.8, efter at vi havde talt eksperimenterne og stoppet agenten i at finjustere mod det samme valideringsvindue. Strategien havde ikke ændret sig. Vores vurdering af, hvad søgningen havde opnået, havde.
Vi førte denne lille researchdagbog, fordi »optimér omhyggeligt« er let at sige og svært at omsætte til praksis, når en agent kan skrive kode, starte backtests, undersøge scoren og prøve igen på få minutter. Her er, hvad der gik galt, i rækkefølge.
Mandag: Giv agenten et afgrænset spørgsmål
Vi bad agenten teste en enkel idé om timebaseret trend på et likvidt perpetual futures-marked: Gå ind, når et kort glidende gennemsnit krydser et længere, tilpas positionsstørrelsen efter et fast volatilitetsmål, og luk positionen ved det modsatte signal. Vi angav instrument, datoer, gebyrstruktur, fundinghistorik, antagelse om eksekvering og de parameterintervaller, den måtte undersøge.
Den historiske stikprøve dækkede 2021 til 2025. Vi brugte 2021–2023 til udvikling, 2024 til validering og holdt 2025 forseglet som et endeligt holdout. Opdelingen var skrevet ind i jobkonfigurationen, så agenten kunne læse udviklingsresultater og valideringsscorer, men ikke hente afkast fra holdout-perioden.
Vores første fejl var at tillade 300 parameterkombinationer i ét job uden at registrere søgebudgettet som et forskningsresultat. Agenten returnerede den bedste variant: et hurtigt gennemsnit på 9 timer, et langsomt gennemsnit på 73 timer og et volatilitetsmål på 0.8%. Dens Sharpe på valideringsdata var 4.1. Vi vidste, at agenten havde prøvet mange indstillinger. Vi havde endnu ikke gjort det umuligt at glemme.
Tirsdag: Vinderen ændrede sig, da vi kørte jobbet igen
Vi kørte det samme job igen i et rent miljø. Den bedste indstilling ændrede sig, og dens Sharpe faldt til 2.7. En cache med markedsdata havde leveret en opdateret fundingserie ved første kørsel, mens genkørslen brugte et fastlåst snapshot. Begge jobs hævdede at bruge det samme datointerval; kun det ene havde en reproducerbar dataversion.
Vi holdt op med at sammenligne scorer og begyndte i stedet at registrere hele eksperimentet: koderevision, datasnapshot, gebyrer, funding, eksekveringsindstillinger, parameterværdier og hvert forsøg, agenten havde startet. Det viste, at resultatet på 4.1 ikke skyldtes en mystisk markedsfordel. Det tilhørte én indstilling i en søgning med 300 forsøg på det samme valideringsår.
Onsdag: Frys søgningen, før holdout-perioden åbnes
Vi kørte eksperimentet igen med et fastlåst datasnapshot og et mindre, forhåndsdefineret gitter: 24 kombinationer. Agenten kunne rangere dem på udviklingsperioden 2021–2023. Vi lod den se 2024 én gang med henblik på udvælgelsen og låste derefter de valgte indstillinger og koden.
Den udvalgte strategi opnåede en Sharpe på 0.8 på valideringsdata. På den forseglede holdout-periode i 2025 opnåede den 0.3 efter takergebyrer, funding og den samme eksekveringsforsinkelse på én bar, som blev anvendt gennem hele studiet. Det var et nyttigt svar. Det var ikke dokumentation for, at strategien ville tjene penge på en livekonto.
En lille sidebemærkning fra denne uge: Vi brugte mere tid på at blive enige om, hvad »ét forsøg« betød, end på at skrive koden til det glidende gennemsnit. Vi talte hvert ændret parametersæt som et forsøg og talte også kørsler med ændringer i signalet eller reglen for positionsstørrelse. Et nyt datasnapshot eller en ny antagelse om eksekvering fik sin egen kørselsregistrering, fordi det kunne ændre rangeringen lige så meget.
Torsdag: Det ville vi springe over næste gang
Vi ville springe det åbne første job over. En researchagent har brug for et søgebudget og en registrering af, hvad den har prøvet, især når den kan bruge hvert resultat til at beslutte, hvad den skal prøve som det næste. Holdout-perioden skal også beskyttes mod uformelle kig: Når nogen læser resultatet og ændrer strategien, er den blevet endnu et valideringssæt.
Til en lille søgning kan en praktisk eksperimentlog være enkel og tydelig:
| Registrér | Hvorfor det er vigtigt |
|---|---|
| Kode- og dataversioner | Så en genkørsel bruger de samme input og den samme logik |
| Alle afprøvede varianter | Så vinderen vurderes i lyset af søgningen |
| Rollerne for udvikling, validering og holdout | Så en endelig score ikke i det skjulte genbruges til finjustering |
| Gebyrer, funding og antagelser om eksekvering | Så det rapporterede resultat beskriver en simulering, der kan testes |
Når holdout-perioden er åbnet, skal I vende tilbage til udviklingsarbejdet med et nyt forskningsspørgsmål og bevare det gamle resultat som historisk dokumentation. Bliv ikke ved med at finpudse den samme strategi mod en periode, den allerede har set.
Agenten gjorde sit arbejde: Den søgte hurtigt og fandt en konfiguration, der var værd at undersøge. Vores opgave var at gøre søgningen gennemskuelig, bevare en urørt test og behandle scoren som en måling med en historik. Det interessante resultat var hverken 4.1 eller 0.3. Det var at se præcis, hvordan det første tal blev til.
← Alle indlæg
