På mandag fant AI-forskningsagenten vår en strategi for kryptofutures med en Sharpe-ratio på 4.1. Innen torsdag var resultatet 0.8, etter at vi hadde telt eksperimentene og sluttet å la agenten finjustere mot det samme valideringsvinduet. Strategien hadde ikke endret seg. Det hadde anslaget vårt på hva søket hadde oppnådd.
Vi førte dette som en kort forskningsdagbok fordi «optimaliser forsiktig» er lett å si, men vanskelig å omsette i praksis når en agent kan skrive kode, kjøre backtester, undersøke poengsummen og prøve igjen på få minutter. Her er det som gikk galt, i rekkefølge.
Mandag: Gi agenten et avgrenset spørsmål
Vi ba agenten teste en enkel timebasert trendidé i et likvidt marked for perpetual futures: gå inn når et kort glidende gjennomsnitt krysser et lengre, tilpass posisjonsstørrelsen til et fast volatilitetsmål, og lukk posisjonen ved motsatt signal. Vi spesifiserte instrument, datoer, gebyrplan, finansieringshistorikk, utførelsesforutsetning og parameterområdene den kunne utforske.
Det historiske utvalget strakte seg fra 2021 til 2025. Vi satte av 2021–2023 til utvikling, 2024 til validering og holdt 2025 forseglet som en endelig holdout-periode. Denne inndelingen ble lagt inn i jobbkonfigurasjonen, slik at agenten kunne lese utviklingsresultater og valideringspoeng, men ikke hente ut avkastningen fra holdout-perioden.
Den første feilen vår var å tillate 300 parameterkombinasjoner i én jobb uten å føre søkebudsjettet som et forskningsresultat. Agenten ga oss den beste varianten: et raskt gjennomsnitt på 9 timer, et langsomt gjennomsnitt på 73 timer og et volatilitetsmål på 0.8%. Sharpe på valideringsperioden var 4.1. Vi visste at agenten hadde prøvd mange innstillinger. Vi hadde ennå ikke gjort det umulig å glemme dette.
Tirsdag: Vinneren endret seg da vi kjørte forsøket på nytt
Vi kjørte den samme jobben på nytt i et rent miljø. Toppinnstillingen endret seg, og Sharpe falt til 2.7. En hurtigbuffer for markedsdata hadde levert en oppdatert finansieringsserie i den første kjøringen, mens den nye kjøringen brukte et låst øyeblikksbilde. Begge jobbene oppga samme datointervall, men bare én hadde en reproduserbar dataversjon.
Vi sluttet å sammenligne poengsummer og begynte å registrere hele eksperimentet: kodeversjon, dataøyeblikksbilde, gebyrer, finansiering, utførelsesinnstillinger, parameterv verdier og hvert forsøk agenten satte i gang. Dermed ble det klart at 4.1 ikke skyldtes en mystisk markedsfordel. Resultatet kom fra én innstilling i et søk med 300 forsøk mot det samme valideringsåret.
Onsdag: Frys søket før holdout-perioden åpnes
Vi kjørte eksperimentet på nytt med et fast dataøyeblikksbilde og et mindre, forhåndsdefinert rutenett på 24 kombinasjoner. Agenten kunne rangere dem etter utviklingsperioden 2021–2023. Vi lot den se 2024 én gang for å velge en variant, og låste deretter innstillingene og koden.
Den valgte strategien fikk 0.8 Sharpe på valideringen. På den forseglede holdout-perioden i 2025 fikk den 0.3 etter taker-gebyrer, finansiering og den samme utførelsesforsinkelsen på én bar som ble brukt gjennom hele studien. Det var et nyttig svar. Det var ikke bevis på at strategien ville tjene penger på en live-konto.
En liten digresjon fra denne uken: Vi brukte mer tid på å bli enige om hva «ett forsøk» betydde enn på å skrive koden for glidende gjennomsnitt. Vi regnet et endret parametersett som et forsøk, og tok også med kjøringer der signalet eller posisjoneringsregelen var endret. Et nytt dataøyeblikksbilde eller en ny utførelsesforutsetning fikk en egen kjøringslogg, siden det kunne påvirke rangeringen like mye.
Torsdag: Dette ville vi droppet neste gang
Vi ville droppet den åpne jobben vi startet med. En forskningsagent trenger et søkebudsjett og en logg over hva den har prøvd, særlig når den kan bruke hvert resultat til å velge neste forsøk. Holdout-perioden må også beskyttes mot uformell sniktitting: Så snart noen leser resultatet og endrer strategien, har perioden blitt enda et valideringssett.
For et lite søk kan en praktisk forsøkslogg være enkel og tydelig:
| Registrer | Hvorfor det er viktig |
|---|---|
| Kode- og dataversjoner | Slik sikrer vi at en ny kjøring bruker de samme inndataene og den samme logikken |
| Alle utprøvde varianter | Slik kan vinneren forstås i lys av søket |
| Rollene til utvikling, validering og holdout | Slik unngår vi at en sluttscore i det stille brukes på nytt til finjustering |
| Gebyrer, finansiering og utførelsesforutsetninger | Slik beskriver det rapporterte resultatet en testbar simulering |
Når holdout-perioden er åpnet, går vi tilbake til utviklingsarbeidet med et nytt forskningsspørsmål og bevarer det gamle resultatet som historisk dokumentasjon. Vi fortsetter ikke å finpusse den samme strategien mot en periode den allerede har sett.
Agenten gjorde jobben sin: Den søkte raskt og fant en konfigurasjon som var verdt å undersøke. Vår jobb var å gjøre søket forståelig, bevare en uberørt test og behandle poengsummen som en måling med en historikk. Det interessante resultatet var verken 4.1 eller 0.3. Det var å se nøyaktig hvordan det første tallet ble til.
← Alle innlegg
