Data Leakage and Model Drift — E-044 Adatszivárgás és modell drift

Bevezetés

Két probléma miatt egy gépi tanulási trading rendszer jobbnak tűnhet a kutatásban, mint amilyen valójában. Az első az adatszivárgás: olyan információ kerül a kutatási folyamatba, amely a döntés pillanatában nem állhatott rendelkezésre. A második a modell drift, amikor a modell által megtanult kapcsolat az éles használat után vagy közben megváltozik.A két probléma különböző. Az adatszivárgás érvényteleníti a történelmi bizonyítékot. A drift akkor is létrejöhet, ha az eredeti kutatás teljesen tiszta volt. Egy professzionális rendszernek mindkettő ellen védelemmel kell rendelkeznie.Ebben a leckében azt vizsgáljuk, hogyan kerülhet információszivárgás a feature-ökbe, célváltozókba, előfeldolgozásba, validációba és univerzumképzésbe, valamint hogyan ismerhető fel, ha egy éles modell már nem úgy viselkedik, mint amelyet korábban validáltunk.

1. Az adatszivárgás és a modell drift különböző problémák

Adatszivárgás akkor történik, amikor a megengedett információs határon kívülről származó információ hatással van egy feature-re, célváltozóra, modellválasztásra vagy értékelésre.Modell drift alatt azt értjük, amikor a bemenetek és a kimenetek közötti kapcsolat megváltozik a telepítés után vagy közben. Az adatok továbbra is lehetnek időhelyesek, mégis pontatlanabbá válhat a modell megtanult kapcsolata.A különbség működésileg fontos. A leakage esetén a kutatási folyamatot kell kijavítani. Drift esetén az éles folyamatot kell monitorozni, és meg kell határozni, mikor szükséges felülvizsgálat, újrakalibrálás, újratanítás vagy visszavonás.

2. Az információs határ

Minden történelmi megfigyelést a döntés időpontjából kell vizsgálni. A kérdés: mit tudhatott akkor a rendszer, és pontosan mikor vált ez az információ elérhetővé?A határ vonatkozik a piaci adatokra, fundamentumokra, eseményekre, univerzumtagságra, vállalati eseményekre, címkékre, előfeldolgozásra és modellválasztásra.Egy pipeline matematikailag hibátlan lehet, miközben megsérti az információs határt. Az időhelyesség ezért nem pusztán a végső feature képletének tulajdonsága, hanem az egész adat-előállítási folyamaté.

3. Feature leakage — információszivárgás a feature-ben

Feature leakage akkor történik, amikor egy prediktor olyan információt tartalmaz, amely csak a kereskedési döntés után válhatott volna elérhetővé. Tipikus példa a jövőbeli hozam véletlen bekerülése egy gördülő számításba, rossz irányú shift vagy teljes időszakból számított statisztika az időrendi split előtt.A szivárgás közvetett is lehet. Egy feature tartalmazhat olyan változót, amelyet maga is jövőbeli információból számítottak.A legerősebb ellenőrző kérdés egyszerű: ezt a pontos feature-értéket ki lehetett volna számítani valós időben az adott történelmi pillanatban, kizárólag az akkor elérhető információból?

4. Target leakage — célváltozó okozta szivárgás

Target leakage akkor történik, amikor a jövőbeli kimenettel kapcsolatos információ bekerül a bemenetek közé. Ez különösen alattomos lehet, ha a célváltozót transzformáljuk, vagy ha a feature időablaka átfed a célváltozó horizontjával.Ha például a cél a következő tíz gyertya hozama, akkor egy olyan feature, amely véletlenül e tíz gyertya bármelyik részét felhasználja, már szennyezett.A célváltozót és a feature-konstrukciót ezért együtt kell megtervezni. A forecast horizont legyen explicit, a bemeneti ablak pedig érjen véget a cél információs határa előtt.

5. Előfeldolgozási leakage

A skálázás, imputálás, feature-kiválasztás, dimenziócsökkentés és más előfeldolgozási lépések is okozhatnak szivárgást, ha a jövőből származó megfigyelésekkel vannak illesztve.Klasszikus hiba, amikor a teljes adathalmazból számítjuk az átlagot és szórást, minden adatot normalizálunk, és csak ezután osztjuk fel az adatot tanítási és tesztidőszakra.A helyes megoldás az, hogy minden kutatási szakaszban a rendelkezésre álló tanítási információból illesztjük az előfeldolgozás paramétereit, majd ezeket alkalmazzuk előre.

6. Leakage az instrumentum-univerzum kialakításán keresztül

A történelmi tesztben szereplő instrumentumok listája maga is információ. Ha az univerzum csak a ma is létező instrumentumokat tartalmazza, a kutatás kizárhatja a történelmi kudarcokat.Az univerzumképzés jövőbeli osztályozási információt is beengedhet. Egy vállalat például egy olyan szektor-, index- vagy jogosultsági besorolást kaphat, amelyet az adott történelmi időpontban még nem ismerhetett a kereskedő.Ezért keresztmetszeti feature-ök és kiválasztási szabályok esetén point-in-time univerzumdefinícióra van szükség.

7. Leakage vállalati és fundamentális adatokon keresztül

A fundamentális és vállalati adatokhoz közzétételi időpont, hatálybalépési idő, revíziótörténet és sokszor késleltetett hozzáférés tartozik. Egy gazdasági tény dátuma nem feltétlenül azonos azzal a dátummal, amikor a kereskedő először megismerhette.Utólag javított pénzügyi kimutatások, restatelt fundamentumok vagy módosított történelmi besorolások használata szivárgást okozhat, ha nem tartjuk be a rendelkezésre állás időpontját.A trading kutatás szempontjából tehát nem pusztán az számít, hogy milyen időszakra vonatkozik az adat, hanem az is, hogy mikor vált ténylegesen elérhetővé.

8. Leakage a validáción keresztül

Maga a validáció is lehet szivárgási csatorna. Ha a kutató újra és újra megnézi a validációs eredményeket, majd ezek alapján változtatja a feature-öket, célváltozót, modellarchitektúrát vagy küszöböket, akkor a validációs adatok hatással voltak a végső modellre.Ez nem mindig technikai programhiba. Gyakran kutatási folyamatból eredő probléma, amely szorosan kapcsolódik a Data Snoopinghoz és a Túltanuláshoz.A védett Mintán kívüli adatszakaszt addig nem szabad felhasználni, amíg az értékelendő kutatási döntéseket le nem fagyasztottuk.

9. Az adatszivárgás felismerése

A leakage nehezen látható, mert gyakran szokatlanul jó eredményeket produkál. Hasznos vizsgálat lehet a feature-ök előre- és hátrafelé tolása, a pipeline újraépítése nyers adatokból, az időbélyegek ellenőrzése, gyanús változók eltávolítása és szándékosan korlátozott verziókkal való összehasonlítás.Ha egy gyanús leakage útvonal kijavítása után összeomlik a teljesítmény, az bizonyíték arra, hogy az eredeti teljesítmény szennyezett információtól függött.A kódreview, az adatvonal követhetősége és a reprodukálható pipeline különösen értékes, mert a leakage a modellen kívül is létrejöhet.

10. Mit jelent a modell drift?

Modell drift alatt azt értjük, hogy megváltozik a modell bemenetei és a célváltozó közötti statisztikai kapcsolat. A modell továbbra is érvényes adatokat kaphat, de az általa megtanult leképezés már kevésbé írja le az aktuális környezetet.Drift megjelenhet a feature-ök eloszlásának, a célváltozó eloszlásának vagy a feature-ök és a cél közötti kapcsolat változásaként.A „drift” kifejezést nem szabad minden veszteséges időszakra használni. Egy stratégia normál változékonyság miatt is szenvedhet veszteséges szakaszt anélkül, hogy az alapvető kapcsolat megváltozott volna.

11. Data drift és concept drift

A data drift a bemeneti változók eloszlásának megváltozását jelenti. Például a volatilitás, forgalom vagy hozamok eloszlása eltolódhat.A concept drift a bemenetek és a célváltozó közötti kapcsolat megváltozását jelenti. Egy korábban hasznos feature gyengébbé válhat vagy másképp viselkedhet.A kettő egymástól függetlenül is létrejöhet. Az inputok eloszlása megváltozhat úgy, hogy a kapcsolat stabil marad, vagy a kapcsolat változhat akkor is, ha az inputeloszlás hasonlónak tűnik.

12. A rezsimváltás nem automatikusan modell drift

A piac különböző környezeteken megy keresztül. Egy modell eltérően teljesíthet magas és alacsony volatilitás, trendelő és oldalazó piac, illetve normál és stresszes likviditás mellett.A teljesítmény átmeneti változása önmagában nem bizonyít driftet. A megfigyelt viselkedést össze kell vetni a modell validált rezsimlefedettségével és a várt változékonysággal.Erősebb a drift hipotézise, ha a romlás tartós, a feature-cél kapcsolat megváltozik, vagy az élő megfigyelések kilépnek azokból a feltételekből, amelyekben a modellt validáltuk.

13. A feature-eloszlások monitorozása

A feature-ök monitorozása már a P&L romlása előtt jelezhet változásokat. Figyelhető a gördülő átlag, szóródás, kvantilisek, hiányosság, szélsőséges értékek és más releváns tulajdonságok.A monitorozásnál a validáció során rögzített baseline-okat használjuk, ne utólag kitalált tetszőleges küszöböket.Az eloszlásváltozás figyelmeztető jel, nem ítélet. A feature továbbra is lehet hasznos az új környezetben, ezért a változást a realizált eredményekkel együtt kell kivizsgálni.

14. Az előrejelzés és a kimenet viselkedésének monitorozása

Ha a modell valószínűséget ad, figyeljük a kalibrációt. Ha pontszámot vagy rangsort ad, vizsgáljuk annak kapcsolatát a későbbi kimenetekkel. Ha trade-eket generál, figyeljük a Várható értéket, az R-többszörös viselkedését, a visszaesést és a költségeket.Fontos a predikció és a kimenet közötti idő. Egyes monitorozási mutatók azonnal értékelhetők, másokhoz meg kell várni az előrejelzési horizont végét.A Mintanagyság szintén kritikus. Kevés friss trade véletlenül is nagy változást mutathat.

15. Driftfelismerés és statisztikai bizonyíték

A driftfelismerésnek egyensúlyt kell teremtenie az érzékenység és a téves riasztások között. Ha a monitorozás minden kis ingadozásra reagál, felesleges modellváltoztatásokhoz vezethet.Statisztikai tesztek, eloszlás-összehasonlítások, gördülő teljesítménybecslések és kontrollküszöbök mind részei lehetnek a monitorozásnak. Egyik sem mágikus drift-detektor.A Statisztikai szignifikanciát a Mintanagysággal és a monitorozási döntések számával együtt kell értelmezni. Ha folyamatosan okot keresünk az újratanításra, maga a folyamat is Data Snoopinggá válhat.

16. Esettanulmány — A szivárgó feature

Egy modell ötnapos hozamot jelez momentum- és volatilitási feature-ök segítségével. A backteszt szokatlanul magas pontosságot mutat. Az audit során kiderül, hogy a volatilitási normalizálást a teljes adathalmazból számították még az időrendi split előtt.A normalizálási paraméterek ezért későbbi időszakok információját is tartalmazták. Az előfeldolgozás tanítási ablakonkénti újraépítése után a teljesítmény jelentősen visszaesik.Nem feltétlenül a modell volt a probléma. A bizonyíték már azelőtt szennyeződött, hogy a modell megkapta volna a bemeneteket. Ezért kell a leakage elleni védelemnek az egész pipeline-ra kiterjednie.

17. Esettanulmány — Valódi modell drift

Egy live modellt több történelmi környezeten validáltak. Az éles használat során a piaci volatilitás megemelkedik, és a modell fő feature-e, valamint a későbbi hozam közötti kapcsolat több hónapra gyengül.A bemeneti eloszlások is kilépnek a korábbi tartományból, és megfelelő számú megfigyelés után a realizált Várható érték továbbra is a validált baseline alatt marad.Ez már jobban illeszkedik a drift hipotéziséhez, mint egyetlen veszteséges sorozathoz. A helyes reakció strukturált vizsgálat: adatminőség, végrehajtás, rezsimkitettség, feature-viselkedés és feature-cél kapcsolat ellenőrzése, mielőtt újratanításról döntünk.

18. Az újratanítás nem automatikusan a megoldás

Amikor romlik a teljesítmény, az újratanítás kézenfekvőnek tűnhet. A legfrissebb adatokra való újratanítás azonban egyszerűen egy átmeneti környezethez is illesztheti a modellt, miközben csökkenti a rendelkezésre álló történelmi bizonyítékot.Újratanítás előtt meg kell határozni, hogy adatminőség, végrehajtás, rezsimkitettség, célváltozó, feature-viselkedés vagy valódi kapcsolatváltozás okozza-e a problémát.Ha újratanítás történik, az új modellt új kutatási verzióként kell kezelni. Saját validációra van szüksége; a korábbi modell bizonyítékát nem örökölheti automatikusan.

19. Modell-visszavonás és verziókezelés

Professzionális rendszerben előre definiálni kell, mikor kerül egy modell felülvizsgálatra vagy visszavonásra. Ilyen lehet tartós teljesítményromlás, jelentős kalibrációs romlás, a validált tartományon kívüli feature-eloszlás vagy olyan működési környezet, amelyet a kutatás nem reprezentált.A verziókezelés alapvető. Rögzíteni kell a modellverziót, feature-definíciókat, tanítási időszakot, validációs időszakot, paramétereket, élesítés dátumát és a jelentős változásokat.Verziótörténet nélkül nehéz megállapítani, hogy egy teljesítményváltozás a piachoz, a modellhez vagy egy szoftvermódosításhoz kapcsolódik.

20. Professzionális leakage- és driftkeretrendszer

Egy robusztus keretrendszer hat rétegre bontható:1. Point-in-time adatok és explicit információs határok.2. Leakage-biztos feature-, target- és előfeldolgozás.3. Időrendi validáció védett Mintán kívüli bizonyítékkal.4. Baseline-ok a feature-eloszlásokhoz és a modell teljesítményéhez.5. Élő monitorozás az adatokra, predikciókra, kimenetekre, végrehajtásra és kockázatra.6. Dokumentált felülvizsgálati, újratanítási, visszaállítási vagy visszavonási folyamat.A cél nem minden teljesítményváltozás megakadályozása. A cél a normál bizonytalanság és az érdemi kutatási vagy működési változás megkülönböztetése.

21. Szakértői gyakorlat — Leakage- és drift-audit

Vegyél egy hipotetikus vagy már létező ML-stratégiát, és készíts két ellenőrzőlistát.Leakage-lista: feature-időbélyegek, célhorizont, gördülő ablakok, előfeldolgozás, univerzumtagság, vállalati adatok, revíziók, validáció, modellválasztás és külső adatok.Drift-lista: feature-eloszlások, predikciós kalibráció, célváltozó eloszlása, feature-cél kapcsolat, Várható érték, R-többszörös-eloszlás, visszaesés, költségek és Mintanagyság.Ezután definiálj három állapotot: normál változékonyság, vizsgálat szükséges, modellfelülvizsgálat szükséges. Határozd meg, milyen bizonyíték viszi át a rendszert egyik állapotból a másikba. Végül írd le a felülvizsgálat utáni lehetséges lépést: folytatás, korlátozás, újratanítás, visszaállítás vagy visszavonás.

22. Tudásellenőrzés

1. Mi az adatszivárgás?2. Miért különbözik a leakage a modell drift problémájától?3. Hogyan okozhat leakage-et az előfeldolgozás?4. Miért szivárogtathat jövőbeli információt az univerzumképzés?5. Mi a különbség data drift és concept drift között?6. Miért nem bizonyít minden veszteséges időszak modell driftet?7. Mit kell monitorozni a P&L-en kívül?8. Miért fontos a Mintanagyság a drift felismerésében?9. Miért nem automatikusan helyes válasz az újratanítás?10. Miért kell az újratanított modellt új kutatási verzióként kezelni?Az erős válasz felismeri az alapvető különbséget: a leakage azért érvényteleníti a bizonyítékot, mert a múltbeli teszt szennyezett volt; a drift pedig azért jelent kihívást, mert egy korábban érvényes modell kapcsolata megváltozhatott. Mindkettőre kontrollált mérés a professzionális válasz, nem az azonnali optimalizálás.

Copying, reproducing, adapting, distributing, or publicly displaying any part or all of the Academy’s textual content without the author’s prior written consent is prohibited.