Hogyan teszteljük az ML modelleket a valós világban

A szabványos ML mérőszámoktól a termelésig

Milyen gyakran teszteli az ML modelleket egy Jupyter notebookban, jó eredményeket ér el, de még mindig nem tudja meggyőzni a főnökét, hogy a modellt azonnal használni kell?

Vagy talán sikerül meggyőznie őt, és elindítani a modellt, de nem lát semmilyen hatást az üzleti mutatókra?

Szerencsére az ML-modellek valós világban való tesztelésének jobb módjai is vannak, és mindenkit (beleértve Önt is) meggyőzhet arról, hogy értéket adnak az üzlethez.

Ebből a cikkből megtudhatja, melyek ezek az értékelési módszerek, hogyan kell alkalmazni őket, és mikor érdemes mindegyiket alkalmazni.

A probléma a szabványos ML kiértékelési mérőszámokkal

Mi, adattudósok és ML mérnökök ML modelleket fejlesztünk és tesztelünk helyi fejlesztői környezetünkben, például egy Jupyter notebookban.

A megoldani kívánt probléma típusától függően szabványos ML kiértékelési mérőszámokat használunk:

• Ha ez egy regressziós probléma, akkor olyan dolgokat nyomtatunk, mint az átlagos négyzetes hibák, a Huber-veszteségek stb.
• Ha osztályozási problémáról van szó, akkor összekeverési mátrixokat, pontosságokat, precizitást, visszahívást stb.

Az adatokat egy vonatra és egy teszthalmazra bontjuk, ahol az első a modell betanításához (vagyis a modell paramétereinek megkereséséhez), az utóbbi pedig a teljesítményének értékeléséhez szolgál. A vonat és a tesztkészletek szétválasztottak, hogy garantáljuk, hogy értékelési mutatóink ne legyenek elfogultak és túl optimisták.

A probléma az, hogy ezek a számok szinte semmit sem jelentenek a körülöttünk lévő nem ML emberek számára, beleértve azokat is, akik végül lehívják a felvételeket, és prioritást adnak, hogy mely szoftverek kerüljenek gyártásba, beleértve az ML modelljeinket is.

Más szóval, ez nem a legjobb módja az ML-modellek tesztelésének és mások meggyőzésének a működésükről.

Miért van így?

2 ok miatt:

1. Ezek a mutatók nem üzleti mutatók, hanem absztrakt.
2. Nincs garancia arra, hogy a telepítést követően az ML az elvárásoknak megfelelően fog működni a szabványos mérőszámok szerint, mert sok dolog elromolhat a termelésben.

Végső soron az ML modellek teszteléséhez éles üzemben kell futtatni őket, és figyelemmel kell kísérni a teljesítményüket. Azonban távolról sem optimális olyan stratégia követése, ahol a modelleket közvetlenül a Jupyter notebookból helyezik át a termelésbe.

Ez az elv minden szoftverre vonatkozik, de különösen fontos az ML modelleknél, rendkívüli törékenységük miatt.

A kérdés tehát az, hogyan járhatunk biztonságosan a helyi szabványos mérőszámoktól a termelésig?

Legalább 3 dolgot tehet, mielőtt közvetlenül a gyártásba kezd:

• A modell visszatesztelése
• Shadow üzembe helyezi a modellt
• A/B teszteli a modellt

Ezek a modell megfelelő értékeléséhez vezető lépések, és segíthetnek Önnek és a csapatnak biztonságosan telepíteni az ML-modelleket, és növelni a vállalkozás értékét.

Nézzük meg, hogyan működnek ezek az értékelési módszerek, egy példával.

1. módszer: Az ML modell utólagos tesztelése

A visszatesztelés egy olcsó módja az ML-modell értékelésének, amelyet a fejlesztői környezetben is megvalósíthat.

Miért olcsó?

Mert

• Csak előzményadatokat használ, így nincs szüksége több adatra, mint amennyivel már rendelkezik.
• Nem kell átmennie egy üzembe helyezési folyamaton, mert időbe telhet, és több iterációt is igénybe vehet, hogy megfelelő legyen.

Az utólagos tesztelés mögött meghúzódó ötlet nagyon egyszerű:

Ön kiválaszt egy D dátumot a múltban, amely határértékként szolgál az ML-modell betanításához/teszteléséhez használt adatok és a modell által a modellre gyakorolt ​​feltételezett hatás becsléséhez használt adatok között. üzleti mutatók, ha azt műveletek végrehajtására használták volna.

Képzelje el például, hogy egy pénzügyi kereskedő cégnél dolgozik ML fejlesztőként.

A cég befektetési portfóliót kezel különböző eszközökbe (részvények, kötvények, kriptopénzek, áruk stb.). Tekintettel ezekre az eszközökre vonatkozóan a rengeteg áradatra, úgy gondolja, hogy fel lehet építeni egy ML-modellt, amely megfelelően megjósolja az árváltozásokat, vagyis azt, hogy az egyes eszközök ára másnap emelkedik vagy csökken.

Ezzel a prediktív ML-modellel a cég módosíthatja portfóliópozícióit, és végső soron javíthatja jövedelmezőségét.

Az építeni kívánt modell lényegében egy 3 osztályú osztályozó, ahol

• a cél up, ha a következő napi ár magasabb, mint a mai, same ha változatlan marad (vagy nagyon közel), és down, ha csökken.
• A jellemzők statikus változók, például eszköztípus és viselkedési változók, például múltbeli volatilitás, ártrendek és korrelációk az elmúlt N napban.

A modellt a helyi környezetben fejleszti, és szabványos osztályozási mérőszámokat nyomtat, például a pontosságot.

Az egyszerűség kedvéért tegyük fel, hogy a 3 osztály tökéletesen kiegyensúlyozott a tesztkészletben, ami 33,333%-ot jelent a up, same, down osztályok mindegyikére.

És a teszt pontossága 34%.

A pénzpiaci mozgások előrejelzése rendkívül nehéz, és modellünk pontossága meghaladja azt a 33% alapvonali pontosságot, amelyet akkor kap, ha mindig ugyanazt az osztályt jósolja.

A dolgok nagyon ígéretesnek tűnnek, és azt mondjuk menedzserünknek, hogy azonnal kezdjük el használni a modellt.

A menedzserünk, egy nem ML személy, aki egy ideje már ebben az iparágban dolgozik, ránéz a számra, és megkérdezi:

„Biztosan működik a modell? Több pénzt fog hozni, mint a jelenlegi stratégiák?”

Valószínűleg nem ez a válasz, amire számítottál, de sajnos számodra ez az egyik leggyakoribb válasz. Ha ilyen mutatókat mutat meg nem ML-es embereknek, akik behívják a céget, akkor gyakran NEM-et fog kapni. Ezért egy lépéssel tovább kell lépnie, hogy bebizonyítsa, hogy a modellje több profitot termel.

És ezt megteheti egy visszateszttel.

Ön kiválasztja a záró dátumot D,például 2 héttel ezelőtt, és

• Tanítsa meg ML osztályozóját a D napig tartó adatok felhasználásával.
• Számítsa ki azt a napi nyereséget és veszteséget, amely a portfólión a D naptól a mai napig rendelkezett volna, ha a modell előrejelzéseit használtuk volna annak eldöntésére, hogy megvásároljuk, megtartjuk vagy eladjuk az egyes pozícióinkat.

Ha a visszatesztje negatív eredményt mutat, vagyis a portfóliója veszteséget termelt volna, akkor vissza kell térnie az 1-eshez. Ellenkezőleg, ha a portfólió nyeresége a backtest időszakban pozitív, akkor vissza kell térnie a menedzseréhez:

"A visszateszt pozitív eredményt mutatott, kezdjük el használni a modellt"

Amire ő válaszol

„Menjünk lépésről lépésre. Először telepítsük, és győződjünk meg arról, hogy valóban működik-e az éles környezetünkben.”

Ez elvezet a következő értékelési lépésünkhöz.

2. módszer: Árnyékos üzembe helyezés a termelésben

Az ML modellek nagyon törékenyek a betanításukhoz használt adatok és a következtetés időpontjában a modellnek küldött adatok közötti kis különbségek miatt.

Például, ha olyan funkcióval rendelkezik a modellben, amely:

• szinte nem voltak hiányzó értékek az edzési adatokból, de
• szinte mindig nem elérhető (és ezért hiányzik) a következtetés időpontjában

A modell teljesítménye a következtetés időpontjában romlik, és rosszabb lesz, mint amire számított. Más szóval, mind a standard értékelési mérőszámok, mind az utólagos tesztelés eredményei szinte mindig a modell valódi teljesítményének felső határát jelentik.

Ezért egy lépéssel tovább kell lépnie, és tesztelnie kell a modellt, amikor azt ténylegesen termelésben használják.

Ennek biztonságos módja az árnyékbevezetés, ahol a modell üzembe helyezése és előrejelzése (ebben az esetben az eszközárak változásai) történik, de a kimenetét NEM használják fel intézkedések végrehajtására (azaz a portfólió egyensúlyának helyreállítására). ).

N nap elteltével megnézzük a modell előrejelzéseit, és azt, hogy milyen lett volna a portfólió nyeresége, ha a modellt használtuk volna a cselekvéshez.

Ha a hipotetikus teljesítmény negatív (azaz veszteség), akkor vissza kell térnünk a modellünkhöz, és meg kell próbálnunk megérteni, hogy mi a baj, pl.

• a modellnek küldött adatok nagyon különböztek a betanítási adatokban szereplőktől? Mint hiányzó paraméterek? Vagy eltérő kategóriás jellemzők?
• nagyon nyugodt és kiszámítható volt a leghátsó időszak, míg a mai piaci viszonyok nagyon eltérőek?
• van hiba a korábban futtatott backtestben?
• …

Ha a hipotetikus profit pozitív, akkor újabb jelet kapunk, hogy a modellünk működik. Tehát pénteken visszamész a főnöködhöz, és azt mondod:

“A modell profitot termelt volna ezen a héten, ha használjuk. Kezdjük el használni, gyerünk.”

Mire ő azt válaszolja,

„Nem láttad portfóliónk e heti teljesítményét? Hihetetlenül jó volt. A modelled még jobb vagy rosszabb volt?”

Az egész hetet annyira az élő tesztre összpontosítottad, hogy még a tényleges teljesítményt is elfelejtetted ellenőrizni.

Most nézd meg a két számot:

• a hét tényleges portfólióteljesítménye
• és a modell hipotetikus teljesítménye

és arra a következtetésre jut, hogy a szám valamivel meghaladja a tényleges teljesítményt. Ez nagyszerű hír az Ön számára! Szóval rohansz vissza a menedzseredhez, és mondd el neki a jó hírt.

Ezt válaszolja:

„Futtassunk egy A/B tesztet a jövő héten, hogy megbizonyosodjunk arról, hogy ez az ML-modell jobb, mint ami jelenleg van”

Ön most a robbanás szélén áll. Tehát megkérdezed:

„Mit kell még látnia ahhoz, hogy elhiggye, ez az ML-modell jobb?”

És azt mondja:

„Tényleges pénz”

Egy hétnek nevezed, és tartasz jól megérdemelt 2 napos pihenőt.

3. módszer: a modell A/B tesztelése

Eddig minden értékelésünk az volt

• túl elvont, mint a 34% pontosság
• vagy hipotetikus. Az utólagos tesztelés és az árnyéktelepítés sem hozott tényleges pénzt. Ehelyett a nyereséget becsültük meg.

Össze kell hasonlítanunk a tényleges dollárt a tényleges dollárral, hogy eldönthessük, használjuk-e inkább az új, ML-alapú stratégiánkat. Ez az ML modellek tesztelésének utolsó módja, amelyet senki sem cáfolhat.

Ennek érdekében úgy döntünk, hogy hétfőtől péntekig lefuttatjuk az A/B tesztet.

Jövő hétfőn véletlenszerűen felosztjuk az eszközportfóliót:

• egy kontrollcsoport (A), pl. piaci értékét tekintve 90%.
• tesztcsoport (B), pl. piaci értékben a fennmaradó 10%-ot

Az A kontrollcsoport kiegyensúlyozására a vállalat jelenlegi stratégiája szerint kerül sor. A B tesztcsoport az ML-alapú stratégiánkkal újra egyensúlyba kerül.

Minden nap figyeljük a 2 részportfólió mindegyikének tényleges nyereségét, és pénteken leállítjuk a tesztet.

Ha összehasonlítjuk az ML-alapú rendszerünk összesített profitját a status quo-val, 3 dolog történhet. Bármelyik

• a status quo sokkal jobban teljesített, mint az Ön ML rendszere. Ebben az esetben nehéz lesz meggyőznie menedzserét arról, hogy stratégiájának életben kell maradnia.
• mindkét alportfólió nagyon hasonlóan teljesített, ami arra késztetheti a vezetőt, hogy további héttel meghosszabbítsa a tesztet, hogy észrevegye a jelentős különbségeket.
• vagy az Ön ML rendszere jelentősen felülteljesítette a status quót. Ebben az esetben minden az Ön oldalán van, hogy mindenkit meggyőzzön a cégben arról, hogy az Ön modellje jobban működik, mint a status quo, és legalább a teljes vagyon 10%-ára kell használni, ha nem többre. Ebben az esetben a körültekintő megközelítés az lenne, ha fokozatosan növelnénk az ML-alapú stratégia alapján kezelt vagyon arányát, hétről hétre figyelemmel kísérve a teljesítményt.

3 hosszú hét hullámvölgy után végre kap egy értékelési mérőszámot, amely mindenkit (beleértve Önt is) meggyőzhet arról, hogy az Ön modellje hozzáadott értéket ad az üzlethez.

Becsomagolva

Ha legközelebb nehéznek találja meggyőzni a körülötte lévőket, hogy az ML-modellek működnek, emlékezzen arra a 3 stratégiára, amellyel az ML-modelleket tesztelheti, a kevésbé meggyőzőtől,

• Visszatesztelés
• Árnyéktelepítés a termelésben
• A/B tesztelés

Az ML fejlesztéstől a gyártásig vezető út köves és elbátortalanító lehet, különösen olyan kisebb cégeknél és startupoknál, amelyek nem rendelkeznek megbízható A/B tesztelési rendszerrel.

Néha unalmas az ML modellek tesztelése, de megéri a fáradságot.

Higgye el, ha valós értékelési mérőszámokat használ az ML-modellek teszteléséhez, sikerrel jár.

Akarsz támogatni?

Szeretsz olvasni és tanulni az ML-ről a való világban, az adattudományról és a szabadúszó munkáról?

Korlátlan hozzáférést kaphat a Mediumon közzétett összes tartalomhoz, és támogathatja az írásomat.

👉🏽 Legyen tag még ma az ajánló linkem segítségével.

👉🏽 Iratkozzon fel az adatgépek hírlevélre.

👉🏽 Kövess engem a Medium, a Twitter és a «LinkedIn oldalon.

További szép napot 🤗

Pau