Un backtest perfect reproductibil poate fi mai puțin demn de încredere decât unul care variază puțin. Repetabilitatea dovedește că poți obține același răspuns de două ori; nu spune nimic despre dependența răspunsului de un instantaneu arbitrar al datelor, de o particularitate a unei biblioteci sau de o valoare implicită ascunsă.
Pare un argument împotriva reproductibilității, dar nu este. Fixează rularea ca să o poți explica. Apoi variază în mod deliberat ipotezele care n-ar trebui să decidă rezultatul. Primul pas face rezultatul auditabil; al doilea îți spune dacă are vreo semnificație.
Ce demonstrează, de fapt, un backtest reproductibil?
Dacă același cod, aceleași date, aceeași configurație și aceeași sămânță aleatoare produc aceleași tranzacții și aceiași indicatori, ai controlat o sursă importantă de confuzie. Poți compara „îmbunătățirea” unui agent cu rularea părinte. Poți separa o corectare de bug de o modificare a grilei de comisioane. Un coleg poate inspecta același registru și poate găsi aceleași execuții.
Însă rezultatul depinde de tot ce ai fixat. Să luăm o strategie crypto al cărei fișier istoric conține bare de 1 minut. Salvezi hash-ul fișierului, fixezi codul și obții un Sharpe de 1.4 la fiecare rerulare. Dacă furnizorul corectează ulterior câteva lumânări, reproductibilitatea impecabilă descrie în continuare fișierul vechi. Nu-ți spune dacă semnalul rezistă istoricului corectat și nici dacă acele lumânări erau disponibile în forma respectivă la momentul respectiv.
Hash-ul este util: face vizibilă dependența. Nu dovedește că dependența este inofensivă.
Păstrează rularea fixă; pune constatarea la încercare
Prefer să separ două întrebări. Putem reconstrui exact această rulare? Și rezistă concluzia cercetării unor schimbări rezonabile? Prima cere o înregistrare imuabilă; a doua cere perturbări controlate, câte una pe rând.
| Ce să înregistrezi | Ce să variezi ulterior | Ce poate scoate la iveală |
|---|---|---|
| Versiunea datelor brute și sumele de control | O revizie a furnizorului sau o a doua sursă | Dependența de valori corectate sau specifice furnizorului |
| Commitul codului și versiunile pachetelor | O implementare echivalentă numeric | Sensibilitatea la ordine, rotunjire sau bibliotecă |
| Comisioanele, funding-ul și ipotezele privind execuțiile | Un interval de costuri justificabil | Dacă un avantaj mic necesită condiții de execuție neobișnuit de favorabile |
| Universul și componența la momentul respectiv | Reguli alternative pentru eligibilitatea piețelor | Dependența de deciziile de includere sau excludere |
De exemplu, să presupunem că o strategie pe contracte futures arată un randament excedentar anualizat de 8% într-o rerulare de bază. Ruleaz-o din nou cu costuri taker cu 25% mai mari, cu funding-ul mutat la următoarea decontare observată și cu cei doi contribuitori principali eliminați pe rând. Nu sunt trei moduri de a îmbunătăți modelul. Sunt teste: fiecare verifică dacă un detaliu plauzibil susține rezultatul principal.
Păstrează fiecare test separat. Dacă modifici datele, grila de comisioane și momentul execuției deodată, un rezultat mai slab îți oferă prea puține indicii despre cauză. Iar dacă un test este neverosimil, etichetează-l drept scenariu de stres în loc să-l prezinți ca rezultat probabil.
Nu confunda identitatea byte cu byte cu adevărul numeric
Unele calcule sunt sensibile la ordine. Adunarea în virgulă mobilă nu este asociativă, așa că însumarea multor valori mici de P&L într-o ordine diferită poate schimba ultimele câteva cifre. Reducerile paralele, hardware-ul și versiunile bibliotecilor pot afecta rezultatul exact. De obicei, efectul este inofensiv; uneori, o modificare numerică minusculă schimbă pragul, modifică o poziție și trimite restul simulării pe o cale diferită.
De aceea aș păstra atât artefactele exacte, cât și toleranțele pentru comparații. Înregistrează registrul tranzacțiilor, nu doar Sharpe-ul final. Compară mai întâi deciziile și fluxurile de numerar, apoi indicatorii în limitele unei toleranțe declarate. Dacă o diferență de un cent schimbă decizia de a trimite un ordin, examinează explicit acel prag.
O înregistrare utilă a rulării include identitatea datelor și a codului, configurația, sămânța aleatoare, mediul de execuție și suficiente rezultate intermediare pentru a urmări un indicator până la execuții și fluxuri de numerar. Un scor final, singur, nu este un artefact de cercetare reproductibil.
Când variația este zgomot și când este o constatare
Nu orice număr schimbat este o criză. O variație infimă a indicatorului, cauzată de o ordine diferită de reducere, poate lăsa tranzacțiile neschimbate. O tranzacție modificată în apropierea unui prag merită analizată. O strategie care își pierde cea mai mare parte din rezultat când un furnizor revizuiește o mică porțiune din istoric a aflat ceva despre propria fragilitate, chiar dacă rularea inițială rămâne perfect reproductibilă.
Criticii testelor de robustețe au dreptate într-o privință: e ușor să tot schimbi ipotezele până când strategia preferată pare rezilientă sau să respingi un rezultat solid fiindcă îl invalidează un scenariu dus intenționat la extrem. Stabilește dinainte variațiile plauzibile, raportează setul complet și distinge alternativele obișnuite de scenariile de stres. Apoi păstrează scenariul de bază, astfel încât alt cercetător să poată reproduce exact ce ai observat.
Reproductibilitatea îți oferă un punct de plecare pe care te poți baza. Urmează întrebarea utilă: ce părți ale răspunsului rămân neschimbate când lumea din jurul acelei rulări se schimbă în moduri la care te-ai putea aștepta în mod rezonabil?
← Toate articolele
