Hat héttel azután, hogy lefuttattunk egy backtesztet, ugyanazzal a kóddal, konfigurációval és dátumtartománnyal újra lefuttattuk. Más lett a záró tőkeérték. Nem drasztikusan, de eléggé ahhoz, hogy a Sharpe-mutató 1.31-ről 1.08-ra változzon, és más paraméterkészlet tűnjön a legjobbnak.
A stratégia nem változott. A történeti adatok igen. Egy adatbeszállító több napnyi kötést és gyertyát módosított, az első futásunkhoz pedig nem őriztük meg a pontos bemeneti pillanatfelvételt. A következő néhány napot azzal töltöttük, hogy kiderítsük: adatkorrekcióról, pipeline-hibáról vagy egy reprodukálhatatlan kutatási folyamatról van-e szó.
Hétfő: az újrafuttatás eltért
Az első nyom egy kis eltérés volt egy likvid spot devizapárnál. Az eredeti gyertyánk maximuma 62,418 volt. Az újrafuttatásnál 62,431-et kaptunk. Ez a különbség ártalmatlannak tűnt, amíg vissza nem követtük a stratégia belépését: a küszöbértéke a két ár közé esett. Néhány módosult gyertya más jelzéseket eredményezett, azok pedig napokkal később más pozíciókat.
Összevetettük a napi kötésszámokat, és azt találtuk, hogy az eltérés egyetlen napon kezdődött. Ezután összehasonlítottuk az adott napot tápláló nyers sorokat. Az adatbeszállító aktuális válaszában néhány javított kötés és egy módosított aggregált gyertya szerepelt. A kapott válaszhoz nem tartozott változásnapló.
Az adatok viselkedése ilyen szokott lenni. A tőzsdék kijavítják a rekordokat; az adatbeszállítók pótolják a hiányokat, korrigálják a hibás kötéseket, és módosítják az aggregálási logikát. A „januári adatokra” vonatkozó lekérdezés márciusban más eredményt adhat.
Kedd: megtaláltuk a hiányzó bizonylatot
A futási rekordban eltároltuk az adatbeszállító nevét, a szimbólumot és a dátumtartományt. Magát a választ vagy az egyes bemeneti partíciók tartalmi hashét viszont nem. Így azt bizonyítani tudtuk, mit kértünk le, de azt nem, hogy az adatbeszállító milyen bájtokat küldött vissza.
Előkerestük a legrégebbi gyorsítótárazott fájlokat, amelyeket találtunk, és összehasonlítottuk őket az aktuális válasszal. Nem splitkorrekció vagy időzóna-átváltás okozta az eltérést. Néhány javított kötési rekord haladt át a gyertyakészítőnkön. Ezzel kizártunk egy lehetséges magyarázatot, de a gyorsítótár hiányos volt, ezért az összes érintett gyertyát továbbra sem tudtuk pontosan rekonstruálni.
| Amit rögzítettünk | Amire választ adott | Ami hiányzott |
|---|---|---|
| Adatbeszállító, szimbólum, dátumtartomány | Milyen lekérdezést indított a futás | A válasz tartalma |
| Pipeline-verzió | Melyik kód készítette a gyertyákat | A pontos bemeneti sorok |
| Futás időbélyege | Mikor futtattuk a feladatot | Melyik adatbeszállítói verzió volt akkor elérhető |
A „ugyanaz a lekérdezés” kifejezést úgy kezeltük, mintha azt jelentené: „ugyanazok az adatok”. Ez a feltételezés a valóságosnál reprodukálhatóbbnak mutatta a kísérletet.
Szerda: a korrekció megváltoztatta a történetet
Mindkét elérhető adatverzióval újrajátszottuk az érintett napokat. A módosított gyertyák miatt két belépés elmaradt, egy kilépés pedig egy gyertyával arrébb került. Ez a három kötés okozta a Sharpe-változás nagy részét. A stratégia érzékeny volt néhány, a kiváltó szinthez közeli megfigyelésre, még akkor is, ha az árfolyamsorozat egészét tekintve a grafikonon szinte semmi különbség nem látszott.
Ez nem jelentette azt, hogy az eredeti eredmény csalás lett volna, vagy hogy a módosított eredmény automatikusan jobb. Azt jelentette, hogy pontosítanunk kellett az állítást: a régi futás az akkori adat-pillanatfelvételt írta le, az újrafuttatás pedig az adatbeszállító jelenlegi adatait. Nem nevezhettük őszintén az egyiket a másik reprodukciójának.
Csütörtök: módosítottunk a kutatási nyilvántartáson
Az új kutatási futásokhoz megváltoztathatatlan bemeneti pillanatfelvételeket adtunk. Minden partíció tartalmi hashét rögzítjük, a futásjegyzék pedig tartalmazza a forrást, a lekérés idejét, a séma verzióját, a korrekciós szabályzatot és az átalakító kód verzióját. Nagy adathalmazoknál magukat a fájlokat tartalomcímzett tárhelyen tároljuk, így az azonos partíciók megoszthatók anélkül, hogy felülírnánk a korábbi verziókat.
Ha a tárolási vagy licencelési szabályok nem engedik a nyers adatok megőrzését, a feltételek szerint megengedett legerősebb bizonylatot mentjük el: a hasheket, a lekérdezés paramétereit, a forrás verzióazonosítóit, valamint a feldolgozott sorokból egy kis mintát a hibakereséshez. A hash nem tudja visszaállítani az adatokat, de megmutatja, ha két futás nem ugyanazokat a bájtokat használta fel.
A reprodukálható backteszthez a bemenet azonosítója kell, nem csupán egy adat-URL. Rögzítsük, mi érkezett be, mikor érkezett be, és hogyan lett belőle az a sorhalmaz, amelyet a stratégia felhasznált.
Péntek: mit hagynánk ki legközelebb
Legközelebb nem csak a fő mutatókat hasonlítanánk össze. A Sharpe változása jelzi, hogy valami elmozdult, de nem mutatja meg az okát. Kezdjük a sorszámokkal és a partíciók hashével, majd keressük meg az első eltérő bemeneti dátumot. Ezután ebben a sorrendben hasonlítsuk össze az átalakított sorokat, a jelzéseket, a megbízásokat és a teljesüléseket.
A régi adatokat sem cserélnénk le észrevétlenül a javított előzményekre. A korrekciók hasznosak, de a régi futásoknak továbbra is az eredeti bemeneteikhez kell kötődniük. Az új adathalmazból új futás induljon, amelynek kapcsolata a korábbival jól látható.
Mostantól egyszerű gyakorlati szabályt követünk: ha egy újrafuttatással egy kísérletet akarunk reprodukálni, rögzítsük az adat-pillanatfelvételt. Ha a javított előzményeket akarjuk felhasználni, jelöljük új kísérletként. Néhány napunkba telt megtanulni a különbséget, a futásjegyzékben pedig most már csak egy sorban szerepel.
← Összes bejegyzés
