Testimisviisid Amazon SageMaker ML mudelite jaoks

See postitus kirjutati koos Intuiti masinõppeplatvormi tarkvaratehnika juhi Tobias Wenzeliga.

Me kõik hindame kvaliteetse ja töökindla masinõppemudeli (ML) tähtsust autonoomse juhtimise või Alexaga suhtlemisel. ML-mudelid mängivad olulist rolli ka vähem ilmselgelt – neid kasutavad ärirakendused, tervishoid, finantsasutused, amazon.com, TurboTax ja palju muud.

Kuna ML-toega rakendused muutuvad paljude ettevõtete tuumaks, peavad mudelid järgima sama jõudu ja distsipliini nagu tarkvararakendused. MLOps-i oluline aspekt on varem välja töötatud ML-i mudeli uue versiooni tarnimine tootmises, kasutades väljakujunenud DevOpsi tavasid, nagu testimine, versioonide loomine, pidev tarnimine ja jälgimine.

On mitmeid ettekirjutav juhised MLOps-i kohta ja see postitus annab ülevaate protsessist, mida saate jälgida ja milliseid tööriistu testimiseks kasutada. See põhineb koostööl Intuit ja AWS. Oleme teinud koostööd, et selles postituses kirjeldatud soovitusi praktikas ja ulatuslikult rakendada. Intuiti eesmärk on saada AI-põhine ekspertplatvorm sõltub suuresti mudeli esialgse arendamise kiiruse suurendamise ja uute versioonide testimise strateegiast.

Nõuded

Järgmised on peamised valdkonnad, mida uute mudeliversioonide juurutamisel arvesse võtta.

1. Mudeli täpsuse jõudlus – See on oluline jälgi mudeli hindamismõõdikute, nagu täpsus, täpsus ja meeldejätmine, ning tagada, et objektiivsed mõõdikud jäävad suhteliselt samaks või paranevad mudeli uue versiooniga. Enamikul juhtudel pole mudeli uue versiooni juurutamine mõttekas, kui lõppkasutajate kogemused ei parane.
2. Testi andmete kvaliteeti – Tootmisvälistes keskkondades olevad andmed, olgu need siis simuleeritud või ajakohastatud koopiad, peaksid esindama andmeid, mida mudel saab pärast täielikku kasutuselevõttu, nii mahu kui ka levitamise osas. Vastasel juhul ei ole teie testimisprotsessid esinduslikud ja teie mudel võib tootmises erinevalt käituda.
3. Funktsiooni tähtsus ja võrdsus – Mudeli uuema versiooni funktsioonide tähtsus peaks võrreldes vanema mudeliga olema suhteliselt kõrge, kuigi võib olla ka uusi funktsioone. Selle eesmärk on tagada, et mudel ei muutuks kallutatud.
4. Äriprotsesside testimine – On oluline, et mudeli uus versioon täidaks teie nõutavad ärieesmärgid vastuvõetavate parameetrite piires. Näiteks võib üks ärimõõdik olla see, et ühegi teenuse otsast lõpuni latentsusaeg ei tohi olla pikem kui 100 millisekundit või konkreetse mudeli hostimise ja ümberõppe kulud ei tohi ületada 10,000 XNUMX dollarit aastas.
5. Maksma – Lihtne lähenemine testimisele on kogu tootmiskeskkonna kordamine testkeskkonnana. See on tarkvaraarenduses tavaline praktika. Siiski ei pruugi selline lähenemine ML-mudelite puhul anda õiget ROI-d olenevalt andmete suurusest ja võib mõjutada mudelit äriprobleemi osas, millega see tegeleb.
6. TURVALISUS – Testikeskkondadel eeldatakse sageli näidisandmeid, mitte tegelikke kliendiandmeid, mistõttu võivad andmetöötluse ja vastavuse reeglid olla leebemad. Täpselt nagu kulu, võib tootmiskeskkonna lihtsalt testkeskkonnaks dubleerimine kaasa tuua turva- ja vastavusriske.
7. Funktsioonide poe skaleeritavus – Kui organisatsioon otsustab kulude või turvalisuse põhjustel eraldi testfunktsioonide poodi mitte luua, peab mudeli testimine toimuma tootmisfunktsioonide poes, mis võib põhjustada skaleeritavuse probleeme, kuna liiklus testimisperioodi jooksul kahekordistub.
8. Interneti-mudeli jõudlus – Veebipõhised hinnangud erinevad võrguühenduseta hindamistest ja võivad mõnel juhul (nt soovitusmudelid) olla olulised, kuna need mõõdavad kasutajate rahulolu pigem reaalajas kui tajutavat rahulolu. Hooajalisuse või muu kasutaja käitumise tõttu on raske simuleerida tegelikke liiklusmustreid tootmisvälisel ajal, seega saab veebimudelit toimida ainult tootmises.
9. Operatiivne jõudlus – Kuna mudelid muutuvad suuremaks ja neid kasutatakse üha enam detsentraliseeritult erinevatele riistvaradele, on oluline testida mudelit soovitud töövõime jaoks, nagu latentsusaeg, veamäär ja palju muud.

Enamikul ML-meeskondadel on mudelitestimisel mitmekülgne lähenemisviis. Järgmistes jaotistes pakume võimalusi nende väljakutsetega tegelemiseks erinevate testimisetappide ajal.

Võrguühenduseta mudeli testimine

Selle testimisetapi eesmärk on valideerida olemasoleva mudeli uued versioonid täpsuse seisukohast. Seda tuleks teha võrguühenduseta, et mitte mõjutada reaalajas prognoose teenindavaid tootmissüsteemi prognoose. Tagades, et uus mudel toimib paremini kohaldatavate hindamismõõdikute jaoks, käsitleb see testimine 1. väljakutset (mudeli täpsuse jõudlus). Õiget andmekogumit kasutades saab see testimine käsitleda ka 2. ja 3. väljakutset (testiandmete kvaliteet, funktsioonide tähtsus ja pariteet), mille lisakasu on 5. väljakutse (kulu) lahendamine.

See etapp tehakse lavastuskeskkonnas.

Peaksite jäädvustama tootmisliiklust, mida saate võrguühenduseta tagasitestimisel taasesitamiseks kasutada. Sünteetiliste andmete asemel on eelistatav kasutada varasemat tootmisliiklust. The Amazon SageMakeri mudelimonitor andmete püüdmise funktsioon võimaldab jäädvustada saidil hostitud mudelite tootmisliiklust Amazon SageMaker. See võimaldab mudelite arendajatel testida oma mudeleid tipptööpäevade või muude oluliste sündmuste andmetega. Seejärel esitatakse kogutud andmed partiiviisiliselt uue mudeliversiooni vastu Sagemakeri partii teisendus. See tähendab, et partii teisenduskäivitust saab testida andmetega, mis on kogutud nädalate või kuude jooksul vaid mõne tunniga. See võib mudeli hindamisprotsessi märkimisväärselt kiirendada võrreldes kahe või enama reaalajas mudeli versiooni kõrvuti käitamisega ja igale lõpp-punktile dubleeritud ennustuspäringute saatmisega. Lisaks parema jõudlusega versiooni kiiremale leidmisele kasutab see lähenemisviis arvutusressursse ka lühema aja jooksul, vähendades sellega üldkulusid.

Selle testimisviisi puhul on väljakutseks funktsioonide komplekti muutumine ühelt mudeliversioonilt teisele. Selle stsenaariumi korral soovitame mõlema versiooni jaoks luua funktsioonide komplekti koos funktsioonide superkomplektiga, et kõigi funktsioonide kohta saaks korraga päringuid teha ja andmehõive kaudu salvestada. Seejärel saab iga ennustuskõne töötada ainult mudeli praeguse versiooni jaoks vajalike funktsioonidega.

Lisaboonusena integreerides Amazon SageMaker Clarify Võrguühenduseta mudeli testimisel saate kontrollida mudeli uue versiooni kallutatust ja võrrelda funktsioonide omistamist mudeli eelmise versiooniga. Torujuhtmete abil saate kogu töövoo korraldada nii, et pärast koolitust saab läbi viia kvaliteedikontrolli, et analüüsida mudeli mõõdikuid ja funktsioonide tähtsust. Need mõõdikud on salvestatud SageMakeri mudeliregister võrdluseks järgmises treeningus.

Integratsiooni ja jõudluse testimine

Integratsiooni testimine on vajalik täielike äriprotsesside valideerimiseks nii funktsionaalsest kui ka käitusaja toimivuse vaatenurgast. Selle protsessi käigus tuleks testida kogu konveierit, sealhulgas funktsioonide toomist ja arvutamist funktsioonide poes ning ML-rakendust. Seda tuleks teha erinevate kasulike koormustega, et katta erinevaid stsenaariume ja taotlusi ning saavutada kõigi võimalike koodikäituste kõrge katvus. See käsitleb 4. ja 9. väljakutseid (äriprotsesside testimine ja toimivus), et tagada mudeli uue versiooniga, et ükski äriprotsess ei katkeks.

Seda testimist tuleks teha lavastuskeskkonnas.

Nii integratsiooni testimise kui ka jõudluse testimise peavad rakendama üksikud meeskonnad, kes kasutavad oma MLOps-konveieri. Integratsioonitestimiseks soovitame järeleproovitud meetodit funktsionaalselt samaväärse tootmiseelse keskkonna säilitamiseks ja mõne erineva kasuliku koormusega testimiseks. Testimise töövoogu saab automatiseerida, nagu näidatud see töötuba. Toimivuse testimiseks võite kasutada Amazon SageMakeri järelduste soovitus, mis on suurepärane lähtepunkt, et määrata, millist eksemplari tüüpi ja kui paljusid neist kasutada. Selleks peate kasutama laadimisgeneraatori tööriista, näiteks avatud lähtekoodiga projekte perfsizeagemaker ja perfsize et Intuit on arenenud. Perfsizesagemaker võimaldab teil automaatselt testida mudeli lõpp-punkti konfiguratsioone mitmesuguste kasulike koormuste, reaktsiooniaegade ja tehingute tipptaseme nõuetega sekundis. See genereerib üksikasjalikud testitulemused, mis võrdlevad erinevaid mudeliversioone. Perfsize on kaastööriist, mis proovib erinevaid konfiguratsioone, võttes arvesse ainult tehingute tippsagedust sekundis ja eeldatavat reageerimisaega.

A / B testimise

Paljudel juhtudel, kui kasutaja reageerib mudeli vahetule väljundile (nt e-poe rakendused), ei piisa võrguühenduseta mudeli funktsionaalsuse hindamisest. Nende stsenaariumide puhul peate enne mudelite värskendamise otsuse tegemist A/B-testima tootmismudeleid. A/B testimisel on ka omad riskid, sest see võib avaldada tegelikku mõju klientidele. See testimismeetod toimib lõpliku ML-i jõudluse valideerimisena, mis on kerge inseneri mõistuse kontroll. See meetod käsitleb ka 8. ja 9. väljakutseid (veebimudelite jõudlus ja toimimise tipptase).

A/B testimine tuleks läbi viia tootmiskeskkonnas.

SageMakeriga saate hõlpsalt ML-mudelitel A/B-testimise läbi teha mitu tootmisvarianti lõpp-punktis. Liiklust saab uude versiooni suunata järk-järgult, et vähendada ohtu, et halvasti käituv mudel võib tootmisel olla. Kui A/B testi tulemused näivad head, suunatakse liiklus uude versiooni, mis lõpuks võtab üle 100% liiklusest. Mudelilt A mudelile B üleminekuks soovitame kasutada kaitsepiirdeid. A/B testimise täielikumaks aruteluks kasutage Isikupärastage Amazon mudelid, näiteks A/B testimise kasutamine Amazon Personalize'i loodud soovituste tõhususe mõõtmiseks.

Interneti-mudelite testimine

Selle stsenaariumi korral erineb mudeli uus versioon oluliselt sellest, mis juba pakub reaalajas liiklust tootmises, mistõttu võrguühenduseta testimise lähenemisviis ei sobi enam uue mudeliversiooni tõhususe määramiseks. Selle kõige silmatorkavam põhjus on ennustuse loomiseks vajalike funktsioonide muutus, nii et varem salvestatud tehinguid ei saa mudeli testimiseks kasutada. Selle stsenaariumi korral soovitame kasutada varijuurutusi. Varju juurutamine pakub võimalust varju juurutada (või väljakutsuja) mudel tootmise kõrval (või meister) mudel, mis praegu ennustusi teenindab. See võimaldab teil hinnata varimudeli toimivust tootmisliikluses. Varimudeli ennustusi taotlevale rakendusele ei edastata; nad on võrguühenduseta hindamiseks sisse logitud. Testimise varimeetodiga tegeleme väljakutsetega 4, 5, 6 ja 7 (äriprotsesside testimine, kulu, turvalisus ja funktsioonide poe skaleeritavus).

Interneti-mudelite testimine peaks toimuma lavastus- või tootmiskeskkondades.

Seda uute mudeliversioonide testimise meetodit tuleks kasutada viimase abinõuna, kui kõiki teisi meetodeid ei saa kasutada. Soovitame seda kasutada viimase abinõuna, sest mitme mudeli kõnede dupleksprintimine tekitab lisakoormuse kõikidele tootmisjärgus teenustele, mis võib kaasa tuua nii jõudluse kitsaskohti kui ka tootmiskulude suurenemise. Selle kõige ilmsem mõju on funktsioonide serveerimiskihile. Kasutusjuhtumite puhul, mis jagavad funktsioone ühisest füüsiliste andmete kogumist, peame suutma simuleerida mitut kasutusjuhtumit, mis pääsevad samaaegselt juurde samale andmetabelile, et enne tootmisse üleminekut ei tekiks ressurssidega tüli. Võimaluse korral tuleks vältida funktsioonide salvestusruumi dubleerivaid päringuid ja mudeli mõlema versiooni jaoks vajalikke funktsioone tuleks teiseks järelduseks uuesti kasutada. Funktsioonide kauplused põhinevad Amazon DynamoDB, mida Intuit on loonud, saab rakendada Amazon DynamoDB Accelerator(DAX) vahemällu salvestamiseks ja andmebaasi sisend-/väljundi kahekordistamise vältimiseks. Need ja muud vahemällu salvestamise valikud võivad leevendada väljakutset 7 (funktsioonide poe skaleeritavus).

Nii 5. (kulu) kui ka 7. väljakutse lahendamiseks teeme ettepaneku kasutada sissetuleva liikluse proovivõtmiseks varijuurutusi. See annab mudeliomanikele veel ühe kontrollikihi, et minimeerida mõju tootmissüsteemidele.

Varju juurutamine peaks olema sisse lülitatud Mudeli monitor pakkumisi nagu tavalised tootmisjuurutused, et jälgida väljakutseversiooni täiustusi.

Järeldus

See postitus illustreerib ehitusplokke, et luua kõikehõlmav protsesside ja tööriistade komplekt, et lahendada mudelitestimisega seotud väljakutseid. Kuigi iga organisatsioon on ainulaadne, peaks see aitama teil alustada ja piirata oma kaalutlusi oma testimisstrateegia rakendamisel.

---

Autoritest

Tobias Wenzel on Californias Mountain View's asuva Intuiti masinõppe platvormi tarkvaratehnika juht. Ta on platvormi kallal töötanud alates selle loomisest 2016. aastal ning aidanud seda algusest peale kujundada ja ehitada. Oma töös on ta keskendunud platvormi töökvaliteedile ja selle edukale toomisele läbi Intuiti hooajalise äri. Lisaks on ta kirglik platvormi pideva laiendamise vastu uusimate tehnoloogiatega.

Shivanshu Upadhyay on AWS-i äriarenduse ja strateegiliste tööstusharude grupi peamine lahenduste arhitekt. Selles rollis aitab ta kõige arenenumatel AWS-i kasutuselevõtjatel muuta oma tööstust, kasutades tõhusalt andmeid ja tehisintellekti.

Alan Tan on SageMakeri vanem tootejuht, kes juhib jõupingutusi suurte mudelite järelduste tegemisel. Ta on kirglik masinõppe rakendamisest analüütika valdkonnas. Väljaspool tööd naudib ta õues olemist.