Tesztelési megközelítések Amazon SageMaker ML modellekhez

Ezt a bejegyzést Tobias Wenzellel, az Intuit Machine Learning Platform szoftverfejlesztési menedzserével közösen írták.

Mindannyian nagyra értékeljük a kiváló minőségű és megbízható gépi tanulási (ML) modell fontosságát például autonóm vezetés vagy Alexával való interakció során. Az ML-modellek kevésbé nyilvánvaló módon is fontos szerepet játszanak – üzleti alkalmazások, egészségügy, pénzintézetek, az amazon.com, a TurboTax és egyebek használják őket.

Mivel az ML-kompatibilis alkalmazások sok vállalkozás központi elemévé válnak, a modelleknek ugyanazt a lendületet és fegyelmet kell követniük, mint a szoftveralkalmazásoknak. Az MLOps egyik fontos szempontja, hogy a korábban kifejlesztett ML-modell új verzióját élesben szállítsa olyan bevált DevOps-gyakorlatok használatával, mint a tesztelés, a verziókezelés, a folyamatos szállítás és a figyelés.

Számos előíró az MLOps-okkal kapcsolatos irányelveket, és ez a bejegyzés áttekintést nyújt a követhető folyamatról és a teszteléshez használható eszközökről. közötti együttműködéseken alapul Intuit és AWS. Együtt dolgoztunk azon, hogy az ebben a bejegyzésben kifejtett ajánlásokat a gyakorlatban és nagymértékben megvalósítsuk. Az intuit célja, hogy egy AI-vezérelt szakértői platform erősen függ a kezdeti modellfejlesztés sebességének növelésére irányuló stratégiától, valamint az új verziók tesztelésétől.

követelmények

Az új modellverziók bevezetésekor a következő fő szempontokat kell figyelembe venni:

1. Modell pontossági teljesítmény – Fontos nyomon követni a modellértékelési metrikák, például a pontosság, precizitás és felidézés, és biztosítsa, hogy az objektív mérőszámok viszonylag változatlanok maradjanak, vagy a modell új verziójával javuljanak. A legtöbb esetben nincs értelme a modell új verziójának üzembe helyezésének, ha a végfelhasználók tapasztalata nem javul.
2. Teszt adatminőség – A nem termelési környezetben lévő adatoknak – akár szimulált, akár időpontban másoltak – reprezentatívnak kell lenniük azon adatok tekintetében, amelyeket a modell a teljes üzembe helyezéskor kap, a mennyiség vagy az elosztás tekintetében. Ha nem, akkor a tesztelési folyamatok nem lesznek reprezentatívak, és előfordulhat, hogy a modell eltérően viselkedik a gyártás során.
3. Funkció fontossága és paritása – A funkció fontossága a modell újabb verziójában viszonylag összehasonlítható a régebbi modellel, bár lehetnek új funkciók. Ezzel biztosítható, hogy a modell ne váljon elfogulttá.
4. Üzleti folyamatok tesztelése – Fontos, hogy egy modell új verziója elfogadható paramétereken belül teljesítse a szükséges üzleti célokat. Például az üzleti mérőszámok egyike lehet, hogy a végpontok közötti késleltetés egyetlen szolgáltatásnál sem lehet több 100 ezredmásodpercnél, vagy egy adott modell üzemeltetésének és átképzésének költsége nem haladhatja meg az évi 10,000 XNUMX USD-t.
5. Költség – A tesztelés egyszerű megközelítése a teljes éles környezet tesztkörnyezetként való replikálása. Ez bevett gyakorlat a szoftverfejlesztésben. Az ML modellek esetében azonban előfordulhat, hogy egy ilyen megközelítés az adatok méretétől függően nem hozza meg a megfelelő ROI-t, és hatással lehet a modellre az általa kezelt üzleti probléma szempontjából.
6. Biztonság – A tesztkörnyezetekben gyakran elvárják, hogy valódi ügyféladatok helyett mintaadatok legyenek, és ennek eredményeként az adatkezelési és megfelelési szabályok kevésbé szigorúak lehetnek. Csakúgy, mint a költségek, ha egyszerűen lemásolja az éles környezetet egy tesztkörnyezetbe, biztonsági és megfelelőségi kockázatokat jelenthet.
7. A szolgáltatástároló méretezhetősége – Ha egy szervezet úgy dönt, hogy költség- vagy biztonsági okokból nem hoz létre külön tesztszolgáltatás-tárolót, akkor a modelltesztelést az éles szolgáltatástárolóban kell elvégezni, ami méretezhetőségi problémákat okozhat, mivel a forgalom megduplázódik a tesztelési időszak alatt.
8. Online modell teljesítmény – Az online értékelések különböznek az offline értékelésektől, és bizonyos esetekben fontosak lehetnek, például az ajánlási modellek esetében, mivel valós időben mérik a felhasználói elégedettséget, nem pedig az észlelt elégedettséget. A szezonalitás vagy más felhasználói viselkedés miatt nehéz szimulálni a valós forgalmi mintákat nem gyártásban, ezért az online modell teljesítménye csak éles környezetben érhető el.
9. Működési teljesítmény – Ahogy a modellek egyre nagyobbak, és egyre inkább decentralizált módon kerülnek telepítésre a különböző hardvereken, fontos, hogy tesztelje a modellt a kívánt működési teljesítmény (például késleltetés, hibaarány stb.) szempontjából.

A legtöbb ML-csapat sokrétű megközelítést alkalmaz a modelltesztelésben. A következő szakaszokban módokat kínálunk ezeknek a kihívásoknak a különböző tesztelési szakaszok során történő kezelésére.

Offline modelltesztelés

Ennek a tesztelési szakasznak a célja egy meglévő modell új verzióinak hitelesítése a pontosság szempontjából. Ezt offline módon kell megtenni, hogy ne befolyásolja a valós idejű előrejelzéseket kiszolgáló előrejelzéseket az éles rendszerben. Azáltal, hogy az új modell jobban teljesít az alkalmazható értékelési mérőszámok tekintetében, ez a tesztelés az 1. kihívást (a modell pontossági teljesítménye) kezeli. Ezenkívül a megfelelő adatkészlet használatával ez a tesztelés kezelheti a 2. és 3. kihívást (tesztadatok minősége, jellemzők fontossága és paritása), az 5. kihívás (költség) kezelésének további előnyével.

Ez a fázis a színpadi környezetben történik.

Rögzítse az éles forgalmat, amelyet az offline visszatesztelés során újrajátszhat. Szintetikus adatok helyett célszerű korábbi éles forgalmat használni. A Amazon SageMaker Model Monitor adatrögzítés funkció lehetővé teszi a termelési forgalom rögzítését a webhelyen tárolt modellekhez Amazon SageMaker. Ez lehetővé teszi a modellfejlesztők számára, hogy teszteljék modelljeiket a csúcsnapok vagy más jelentős események adataival. A rögzített adatokat ezután kötegelt módon lejátssza az új modellverzióval Sagemaker kötegelt transzformáció. Ez azt jelenti, hogy a kötegelt átalakítás futtatása néhány óra alatt képes tesztelni a hetek vagy hónapok során gyűjtött adatokkal. Ez jelentősen felgyorsíthatja a modellértékelési folyamatot ahhoz képest, hogy egy valós idejű modell két vagy több verzióját egymás mellett futtatnák, és duplikált előrejelzési kéréseket küldenének minden végponthoz. Amellett, hogy gyorsabban talál egy jobban teljesítő verziót, ez a megközelítés rövidebb ideig használja a számítási erőforrásokat, csökkentve a teljes költséget.

A tesztelés ilyen megközelítésével kapcsolatos kihívás az, hogy a funkciókészlet egyik modellváltozatról a másikra változik. Ebben a forgatókönyvben azt javasoljuk, hogy mindkét verzióhoz hozzon létre egy szolgáltatáskészletet a szolgáltatások szuperkészletével, hogy az összes szolgáltatást egyszerre lehessen lekérdezni és rögzíteni az adatrögzítésen keresztül. Ezután minden előrejelzési hívás csak a modell aktuális verziójához szükséges funkciókon működhet.

További bónuszként, integrálással Amazon SageMaker Clarify az offline modelltesztelés során ellenőrizheti a modell új verziójának torzítását, és összehasonlíthatja a funkciók hozzárendelését a modell előző verziójával. A folyamatok segítségével a teljes munkafolyamatot úgy irányíthatja, hogy a betanítás után minőségellenőrzési lépésre kerülhessen sor a modell metrikáinak és a jellemzők fontosságának elemzéséhez. Ezeket a mutatókat a SageMaker modellnyilvántartás összehasonlítás céljából a következő edzés során.

Integráció és teljesítményteszt

Integrációs tesztelésre van szükség a végpontok közötti üzleti folyamatok érvényesítéséhez mind funkcionális, mind futási teljesítmény szempontjából. Ezen a folyamaton belül a teljes folyamatot tesztelni kell, beleértve a szolgáltatások lekérését és számítását a szolgáltatástárolóban, valamint az ML alkalmazás futtatását. Ezt különféle hasznos adatokkal kell megtenni, hogy lefedje a különféle forgatókönyveket és kéréseket, és magas lefedettséget érjen el az összes lehetséges kódfuttatáshoz. Ez a 4. és 9. kihívást (üzleti folyamatok tesztelése és működési teljesítmény) kezeli annak biztosítása érdekében, hogy a modell új verziója egyetlen üzleti folyamatot se sértsen meg.

Ezt a tesztelést átmeneti környezetben kell elvégezni.

Mind az integrációs tesztelést, mind a teljesítménytesztet az egyes csapatoknak végre kell hajtaniuk az MLOps folyamat segítségével. Az integrációs teszteléshez azt a bevált módszert ajánljuk, amely egy funkcionálisan egyenértékű gyártás előtti környezetet tart fenn, és tesztel néhány különböző hasznos adatmennyiséggel. A tesztelési munkafolyamat automatizálható, ahogy az ábrán látható ezt a műhelyt. A teljesítményteszthez használhatja Amazon SageMaker Inference Recommender, amely nagyszerű kiindulópontot kínál annak meghatározásához, hogy melyik példánytípust és hány példányt használjon. Ehhez egy terhelésgeneráló eszközt kell használnia, például a nyílt forráskódú projekteket perfsizegemaker és a perfsize hogy az Intuit kifejlesztette. A Perfsizesagemaker lehetővé teszi a modell végpont-konfigurációinak automatikus tesztelését különféle hasznos terhelésekkel, válaszidőkkel és másodpercenkénti csúcsforgalommal. Részletes teszteredményeket generál, amelyek összehasonlítják a különböző modellváltozatokat. A Perfsize egy olyan segédeszköz, amely különböző konfigurációkat próbál ki, figyelembe véve a másodpercenkénti tranzakciók csúcsértékét és a várható válaszidőt.

A / B tesztelés

Sok esetben, amikor felhasználói reakcióra van szükség a modell azonnali kimenetére, például az e-kereskedelmi alkalmazásokban, az offline modell funkcionális értékelése nem elegendő. Ezekben a forgatókönyvekben a modellek A/B tesztelése a termelésben, mielőtt a modellek frissítéséről döntene. Az A/B tesztelésnek is megvannak a maga kockázatai, mert valódi hatást gyakorolhat az ügyfelekre. Ez a tesztelési módszer szolgál a végső ML teljesítményellenőrzésként, egy könnyű mérnöki épségellenőrzésként. Ez a módszer a 8. és 9. kihívásra is választ ad (online modellteljesítmény és működési kiválóság).

Az A/B tesztelést éles környezetben kell elvégezni.

A SageMaker segítségével egyszerűen végezhet A/B tesztelést ML modelleken futtatással többféle gyártási változat egy végponton. A forgalmat fokozatosan lehet irányítani az új verzióra, hogy csökkentsék annak kockázatát, hogy egy rosszul viselkedő modell a gyártás során előfordulhat. Ha az A/B teszt eredménye jónak tűnik, a forgalmat az új verzióra irányítják, és végül a forgalom 100%-át átveszik. Javasoljuk, hogy az A modellről a B modellre való átmenethez használjon telepítési védőkorlátokat. Az A/B tesztelés részletesebb megbeszéléséhez használja a Az Amazon testreszabása modellekre példaként hivatkozzon A/B tesztelés az Amazon Personalize által generált ajánlások hatékonyságának mérésére.

Online modelltesztelés

Ebben a forgatókönyvben egy modell új verziója jelentősen eltér a már éles forgalmat kiszolgáló verziótól, így az offline tesztelési megközelítés már nem alkalmas az új modellverzió hatékonyságának meghatározására. Ennek legszembetűnőbb oka az előrejelzés előállításához szükséges jellemzők megváltozása, így a korábban rögzített tranzakciók nem használhatók a modell tesztelésére. Ebben a forgatókönyvben az árnyéktelepítések használatát javasoljuk. Az árnyéktelepítések lehetőséget kínálnak árnyék telepítésére (vagy kihívó) modell a gyártás mellett (ill bajnok) modell, amely jelenleg előrejelzéseket szolgál ki. Ezzel kiértékelheti, hogy az árnyékmodell hogyan teljesít az éles forgalomban. Az árnyékmodell előrejelzései nem jelennek meg a kérelmező alkalmazás számára; naplózva vannak az offline értékeléshez. A tesztelés árnyék-megközelítésével a 4., 5., 6. és 7. kihívást kezeljük (üzleti folyamatok tesztelése, költség, biztonság és a szolgáltatástároló méretezhetősége).

Az online modelltesztelést átmeneti vagy éles környezetben kell elvégezni.

Az új modellverziók tesztelésének ezt a módszerét végső megoldásként kell használni, ha az összes többi módszer nem használható. Utolsó megoldásként javasoljuk, mert a több modellre irányuló kétoldalas hívások további terhelést jelentenek a termelés összes downstream szolgáltatására, ami a teljesítmény szűk keresztmetszetéhez, valamint a gyártási költségek növekedéséhez vezethet. Ennek legnyilvánvalóbb hatása a funkciókiszolgáló rétegre van. A közös fizikai adatok készletéből származó funkciókat megosztó használati eseteknél képesnek kell lennünk szimulálni több használati esetet, amelyek egyidejűleg hozzáférnek ugyanahhoz az adattáblázathoz, hogy biztosítsuk, hogy az élesre való átállás előtt ne álljon fenn erőforrás-verseny. Ahol lehetséges, kerülni kell a funkciótárba irányuló ismétlődő lekérdezéseket, és a modell mindkét verziójához szükséges szolgáltatásokat újra fel kell használni a második következtetéshez. Feature stores alapján Amazon DynamoDB, ahogy azt az Intuit építette, megvalósíthatja Amazon DynamoDB Accelerator(DAX) gyorsítótárazásához, és elkerülje az adatbázis I/O-jának megkétszerezését. Ezek és más gyorsítótárazási lehetőségek mérsékelhetik a 7. kihívást (a szolgáltatástároló méretezhetősége).

Az 5. (költség) és a 7. kihívás megoldásához árnyéktelepítések használatát javasoljuk a bejövő forgalom mintavételéhez. Ez a modelltulajdonosok számára egy újabb irányítási szintet biztosít a termelési rendszerekre gyakorolt ​​hatás minimalizálása érdekében.

Az árnyéktelepítést be kell építeni a Modell monitor kínálata csakúgy, mint a szokásos éles telepítéseknél, hogy megfigyelje a kihívó verzió fejlesztéseit.

Következtetés

Ez a bejegyzés bemutatja a folyamatok és eszközök átfogó készletének építőköveit a modelltesztelés során felmerülő különféle kihívások kezelésére. Bár minden szervezet egyedi, ez segíthet az indulásban és leszűkíteni a szempontokat a saját tesztelési stratégia megvalósítása során.

---

A szerzőkről

Tobias Wenzel az Intuit Machine Learning Platform szoftvermérnöki menedzsere a kaliforniai Mountain View-ban. 2016-os kezdete óta dolgozik a platformon, és az alapoktól kezdve segített megtervezni és felépíteni. Munkája során a platform működési kiválóságára és annak sikeres megvalósítására összpontosított az Intuit szezonális üzletén keresztül. Emellett szenvedélyesen törekszik a platform folyamatos bővítésére a legújabb technológiákkal.

Shivanshu Upadhyay az AWS Business Development and Strategic Industries csoport vezető megoldási építésze. Ebben a szerepkörben segít az AWS legfejlettebb alkalmazóinak átalakítani iparágukat az adatok és a mesterséges intelligencia hatékony felhasználásával.

Alan Tan a SageMaker vezető termékmenedzsere, aki a nagy modellkövetkeztetések terén tett erőfeszítéseket vezeti. Szenvedélyesen szereti a gépi tanulást az analitika területén alkalmazni. Munkán kívül élvezi a szabad levegőt.