Testauslähestymistapoja Amazon SageMaker ML -malleille

Tämä viesti on kirjoitettu yhdessä Intuit Machine Learning Platformin ohjelmistosuunnittelupäällikön Tobias Wenzelin kanssa.

Me kaikki ymmärrämme laadukkaan ja luotettavan koneoppimismallin (ML) tärkeyden esimerkiksi autonomisessa ajamisessa tai vuorovaikutuksessa Alexan kanssa. ML-malleilla on tärkeä rooli myös vähemmän ilmeisillä tavoilla – niitä käyttävät yrityssovellukset, terveydenhuolto, rahoituslaitokset, amazon.com, TurboTax ja muut.

Koska ML-yhteensopivista sovelluksista tulee monien yritysten ydin, mallien on noudatettava samaa tarmoa ja kurinalaisuutta kuin ohjelmistosovellusten. Tärkeä näkökohta MLOpsissa on toimittaa uusi versio aiemmin kehitetystä ML-mallista tuotannossa käyttämällä vakiintuneita DevOps-käytäntöjä, kuten testausta, versiointia, jatkuvaa toimitusta ja valvontaa.

On olemassa useita ohjaileva MLOps-ohjeita, ja tämä viesti antaa yleiskatsauksen prosessista, jota voit seurata ja mitä työkaluja testaukseen tulee käyttää. Tämä perustuu yhteistyöhön Tajuta intuitiivisesti ja AWS. Olemme työskennelleet yhdessä tämän postauksen suositusten toteuttamiseksi käytännössä ja laajasti. Intuitin tavoitteena on tulla Tekoälypohjainen asiantuntijaalusta on vahvasti riippuvainen strategiasta lisätä mallin alkuperäisen kehityksen nopeutta sekä uusien versioiden testaamista.

vaatimukset

Seuraavat ovat tärkeimmät huomioitavat alueet otettaessa käyttöön uusia malliversioita:

1. Mallin tarkkuussuorituskyky – On tärkeää pitää kirjaa mallin arvioinnin mittareista, kuten tarkkuus, tarkkuus ja muistaminen, ja varmistaa, että tavoitemittarit pysyvät suhteellisen samoina tai paranevat mallin uuden version myötä. Useimmissa tapauksissa mallin uuden version käyttöönotto ei ole järkevää, jos loppukäyttäjien kokemus ei parane.
2. Testaa tietojen laatua – Muissa kuin tuotantoympäristöissä olevien tietojen, olipa kyseessä sitten simuloitu tai ajankohtana kopio, tulisi edustaa dataa, jonka malli vastaanottaa, kun se on täysin käytössä, määrän tai jakelun osalta. Jos ei, testausprosessisi eivät ole edustavia ja mallisi voi toimia eri tavalla tuotannossa.
3. Ominaisuuden tärkeys ja pariteetti – Ominaisuuksien tärkeyden mallin uudemmassa versiossa pitäisi suhteellisesti verrata vanhaan malliin, vaikka uusia ominaisuuksia saattaakin tulla. Tällä varmistetaan, että malli ei muutu puolueelliseksi.
4. Liiketoimintaprosessien testaus – On tärkeää, että mallin uusi versio voi täyttää vaaditut liiketoimintatavoitteet hyväksyttävien parametrien puitteissa. Yksi liiketoiminnan mittareista voi esimerkiksi olla, että minkään palvelun päästä päähän -viive ei saa olla yli 100 millisekuntia tai tietyn mallin isännöinnin ja uudelleenkoulutuksen kustannukset eivät saa olla yli 10,000 XNUMX dollaria vuodessa.
5. Hinta – Yksinkertainen lähestymistapa testaukseen on kopioida koko tuotantoympäristö testiympäristöksi. Tämä on yleinen käytäntö ohjelmistokehityksessä. Tällainen lähestymistapa ML-mallien tapauksessa ei kuitenkaan välttämättä tuota oikeaa sijoitetun pääoman tuottoprosenttia datan koosta riippuen, ja se voi vaikuttaa malliin sen käsittelemään liiketoimintaongelmaan.
6. Turvallisuus – Testausympäristöissä odotetaan usein olevan näytedataa todellisen asiakasdatan sijaan, minkä seurauksena tietojen käsittely- ja noudattamissäännöt voivat olla vähemmän tiukkoja. Aivan kuten kustannukset, jos vain kopioit tuotantoympäristön testiympäristöksi, voit tuoda turvallisuus- ja vaatimustenmukaisuusriskejä.
7. Ominaisuusvaraston skaalautuvuus – Jos organisaatio päättää olla luomatta erillistä testiominaisuussäilöä kustannus- tai turvallisuussyistä, mallin testaus on suoritettava tuotantoominaisuusvarastossa, mikä voi aiheuttaa skaalautuvuusongelmia, koska liikenne kaksinkertaistuu testausjakson aikana.
8. Online-mallin suorituskyky – Online-arvioinnit eroavat offline-arvioinneista ja voivat olla tärkeitä joissakin tapauksissa, kuten suositusmalleissa, koska ne mittaavat käyttäjien tyytyväisyyttä reaaliajassa mieluummin kuin koettua tyytyväisyyttä. On vaikea simuloida todellisia liikennemalleja ei-tuotannossa kausiluonteisuuden tai muun käyttäjien käyttäytymisen vuoksi, joten verkkomallin suorituskykyä voidaan tehdä vain tuotannossa.
9. Operatiivinen suorituskyky – Kun mallit kasvavat ja niitä otetaan yhä useammin käyttöön hajautetusti eri laitteissa, on tärkeää testata mallia halutun toiminnallisen suorituskyvyn, kuten latenssin, virhesuhteen ja muiden, suhteen.

Useimmilla ML-tiimeillä on monitahoinen lähestymistapa mallien testaukseen. Seuraavissa osioissa tarjoamme tapoja vastata näihin haasteisiin eri testausvaiheiden aikana.

Offline-mallin testaus

Tämän testausvaiheen tavoitteena on validoida olemassa olevan mallin uudet versiot tarkkuusnäkökulmasta. Tämä tulisi tehdä offline-tilassa, jotta se ei vaikuta tuotantojärjestelmän ennusteisiin, jotka palvelevat reaaliaikaisia ​​ennusteita. Tämä testaus vastaa haasteeseen 1 (mallin tarkkuussuorituskyky) varmistamalla, että uusi malli toimii paremmin sovellettavien arviointimittojen suhteen. Lisäksi käyttämällä oikeaa tietojoukkoa tämä testaus voi vastata haasteisiin 2 ja 3 (testitietojen laatu, ominaisuuksien tärkeys ja pariteetti), ja lisäetu on haaste 5 (kustannukset).

Tämä vaihe tehdään lavastusympäristössä.

Sinun tulisi siepata tuotantoliikennettä, jota voit käyttää uudelleentoistoon offline-takaisin testauksessa. On parempi käyttää aikaisempaa tuotantoliikennettä synteettisten tietojen sijaan. The Amazon SageMaker -mallimonitori kaapata dataominaisuus voit kaapata tuotantoliikennettä malleille, joita isännöidään Amazon Sage Maker. Näin mallinkehittäjät voivat testata mallejaan ruuhka-arkipäivien tai muiden merkittävien tapahtumien tiedoilla. Siepatut tiedot toistetaan sitten uutta malliversiota vastaan ​​erämuodossa käyttäen Sagemaker erämuunnos. Tämä tarkoittaa, että erämuunnosajo voi testata viikkojen tai kuukausien aikana kerätyillä tiedoilla vain muutamassa tunnissa. Tämä voi nopeuttaa huomattavasti mallin arviointiprosessia verrattuna kahden tai useamman reaaliaikaisen mallin version käyttämiseen rinnakkain ja päällekkäisten ennustepyyntöjen lähettämiseen kuhunkin päätepisteeseen. Sen lisäksi, että tämä lähestymistapa löytää paremmin toimivan version nopeammin, se myös käyttää laskentaresursseja lyhyemmän ajan, mikä vähentää kokonaiskustannuksia.

Tämän testaustavan haasteena on, että ominaisuusjoukko muuttuu malliversiosta toiseen. Tässä skenaariossa suosittelemme luomaan ominaisuusjoukon, jossa on superjoukko ominaisuuksia molemmille versioille, jotta kaikista ominaisuuksista voidaan tehdä kyselyitä kerralla ja tallentaa tiedonkeruun kautta. Jokainen ennustekutsu voi sitten toimia vain niissä ominaisuuksissa, jotka ovat tarpeen mallin nykyisessä versiossa.

Lisäbonuksena integroimalla Amazon SageMaker selkeyttää offline-mallin testauksessa voit tarkistaa mallin uuden version harhaisuuden varalta ja myös verrata ominaisuuksien määritystä mallin aiempaan versioon. Liukuputkien avulla voit organisoida koko työnkulun siten, että koulutuksen jälkeen voidaan suorittaa laaduntarkistusvaihe mallin mittareiden ja ominaisuuksien tärkeyden analysoimiseksi. Nämä mittarit on tallennettu SageMaker-mallirekisteri vertailua varten seuraavalla harjoituskierroksella.

Integrointi ja suorituskyvyn testaus

Integraatiotestausta tarvitaan päästä päähän -liiketoimintaprosessien validointiin toiminnallisesta ja ajonaikaisesta suorituskyvystä. Tämän prosessin aikana tulee testata koko liukuhihna, mukaan lukien ominaisuussäilön ominaisuuksien hakeminen ja laskeminen sekä ML-sovelluksen suorittaminen. Tämä tulisi tehdä useilla eri hyötykuormilla, jotta voidaan kattaa erilaisia ​​skenaarioita ja pyyntöjä ja saavuttaa korkea kattavuus kaikille mahdollisille koodiajoille. Tämä vastaa haasteisiin 4 ja 9 (liiketoimintaprosessien testaus ja toimintakyky) varmistaakseen, että mikään liiketoimintaprosesseista ei katkea mallin uudessa versiossa.

Tämä testaus tulisi tehdä lavastusympäristössä.

Sekä integraatiotestaus että suorituskyvyn testaus on toteutettava yksittäisten tiimien toimesta käyttämällä MLOps-putkistoaan. Integraatiotestaukseen suosittelemme testattua menetelmää, jossa ylläpidetään toiminnallisesti vastaava esituotantoympäristö ja testataan muutamalla eri hyötykuormalla. Testaustyönkulku voidaan automatisoida kuvan osoittamalla tavalla tämä työpaja. Suorituskykytestaukseen voit käyttää Amazon SageMakerin päätelmäsuositus, joka tarjoaa loistavan lähtökohdan määrittämään, minkä ilmentymän tyyppiä ja kuinka monta niistä käytetään. Tätä varten sinun on käytettävä latauksen luontityökalua, kuten avoimen lähdekoodin projekteja perfsizeagemaker ja perfsize että Intuit on kehittänyt. Perfsizesagemakerin avulla voit testata automaattisesti mallin päätepistekokoonpanoja erilaisilla hyötykuormilla, vasteajoilla ja huipputapahtumien sekunnissa vaatimuksilla. Se tuottaa yksityiskohtaisia ​​testituloksia, jotka vertaavat eri malliversioita. Perfsize on kumppanityökalu, joka kokeilee erilaisia ​​konfiguraatioita, kun otetaan huomioon vain huipputapahtumat sekunnissa ja odotettu vasteaika.

/ B-testaus

Monissa tapauksissa, joissa vaaditaan käyttäjän reagointia mallin välittömään tuotteeseen, kuten verkkokauppasovelluksiin, offline-mallin toiminnallinen arviointi ei riitä. Näissä skenaarioissa sinun on A/B-testattava mallit tuotannossa ennen kuin teet päätöksen mallien päivittämisestä. A/B-testauksessa on myös riskinsä, koska sillä voi olla todellista asiakasvaikutusta. Tämä testausmenetelmä toimii viimeisenä ML-suorituskyvyn validointina, kevyenä teknisenä mielenterveystarkastuksena. Tämä menetelmä vastaa myös haasteisiin 8 ja 9 (verkkomallin suorituskyky ja toiminnallinen erinomaisuus).

A/B-testaus tulee suorittaa tuotantoympäristössä.

SageMakerin avulla voit helposti suorittaa A/B-testauksen ML-malleilla ajamalla useita tuotantoversioita päätepisteessä. Liikennettä voidaan ohjata portaittain uuteen versioon, mikä vähentää riskiä, ​​että huonosti käyttäytyvä malli voi joutua tuotannossa. Jos A/B-testin tulokset näyttävät hyviltä, ​​liikenne ohjataan uuteen versioon, joka lopulta ottaa haltuunsa 100 % liikenteestä. Suosittelemme käyttämään suojakaiteita mallista A malliin B siirtymiseen. Täydellisen keskustelun saamiseksi A/B-testauksesta Amazon Muokkaa mallit esimerkkinä, katso A / B-testien avulla Amazon Personalise -sovelluksen tuottamien suositusten tehokkuuden mittaaminen.

Mallin testaus verkossa

Tässä skenaariossa mallin uusi versio eroaa merkittävästi jo tuotannossa elävää liikennettä palvelevasta versiosta, joten offline-testaustapa ei enää sovellu uuden malliversion tehokkuuden määrittämiseen. Näkyvin syy tähän on muutos ennusteen tuottamiseen tarvittaviin ominaisuuksiin, jolloin aiemmin tallennettuja tapahtumia ei voida käyttää mallin testaamiseen. Tässä skenaariossa suosittelemme varjokäyttöönottoa. Varjo-asennukset tarjoavat mahdollisuuden ottaa käyttöön varjo (tai haastaja) mallia tuotannon rinnalla (tai mestari) malli, joka tällä hetkellä palvelee ennusteita. Tämän avulla voit arvioida, kuinka varjomalli toimii tuotantoliikenteessä. Varjomallin ennusteita ei toimiteta pyytävälle sovellukselle; ne on kirjattu offline-arviointia varten. Testauksen varjomenetelmällä vastaamme haasteisiin 4, 5, 6 ja 7 (liiketoimintaprosessien testaus, kustannukset, turvallisuus ja ominaisuuskaupan skaalautuvuus).

Online-mallin testaus tulisi tehdä lavastus- tai tuotantoympäristöissä.

Tätä uusien malliversioiden testausmenetelmää tulisi käyttää viimeisenä keinona, jos kaikkia muita menetelmiä ei voida käyttää. Suosittelemme sitä viimeisenä keinona, koska useisiin malleihin suuntautuvien puhelujen kaksipuolinen lähettäminen kuormittaa kaikkia tuotantoketjun loppupään palveluita, mikä voi johtaa suorituskyvyn pullonkauloihin sekä tuotannon kustannusten nousuun. Ilmeisin vaikutus tällä on ominaisuuksia palvelevaan tasoon. Käyttötapauksissa, joissa on yhteisen fyysisen tiedon joukon ominaisuuksia, meidän on kyettävä simuloimaan useita käyttötapauksia, jotka käyttävät samaa tietotaulukkoa samanaikaisesti, jotta voimme varmistaa, ettei resurssikilpailua esiinny ennen tuotantoon siirtymistä. Aina kun mahdollista, päällekkäisiä kyselyitä ominaisuussäilöön tulee välttää ja mallin molemmissa versioissa tarvittavia ominaisuuksia tulee käyttää uudelleen toisessa päätelmässä. Ominaisuusvarastot perustuvat Amazon DynamoDB, jonka Intuit on rakentanut, voi toteuttaa Amazon DynamoDB Accelerator(DAX) tallentaaksesi välimuistiin ja välttääksesi tietokannan I/O:n kaksinkertaistamisen. Nämä ja muut välimuistivaihtoehdot voivat lieventää haastetta 7 (ominaisuusvaraston skaalautuvuus).

Haasteen 5 (kustannus) ja 7 ratkaisemiseksi ehdotamme varjokäyttöönottoa saapuvasta liikenteestä. Tämä antaa mallinomistajille toisen tason hallintaa tuotantojärjestelmiin kohdistuvien vaikutusten minimoimiseksi.

Shadow-käyttöönotto tulee ottaa käyttöön Malli Monitor tarjontaa aivan kuten tavanomaiset tuotantoasennukset, jotta voit seurata haastajaversion parannuksia.

Yhteenveto

Tämä viesti havainnollistaa rakennuspalikoita, joiden avulla voidaan luoda kattava prosesseja ja työkaluja, joilla voidaan vastata erilaisiin mallitestauksen haasteisiin. Vaikka jokainen organisaatio on ainutlaatuinen, tämän pitäisi auttaa sinua pääsemään alkuun ja rajaamaan huomioita, kun otat käyttöön omaa testausstrategiaasi.

---

Tietoja kirjoittajista

Tobias Wenzel on ohjelmistosuunnittelupäällikkö Intuit Machine Learning Platformissa Mountain View'ssa, Kaliforniassa. Hän on työskennellyt alustan parissa sen perustamisesta vuonna 2016 lähtien ja on auttanut sen suunnittelussa ja rakentamisessa alusta alkaen. Hän on työssään keskittynyt alustan toiminnalliseen erinomaisuuteen ja tuomaan sitä menestyksekkäästi Intuitin kausiliiketoiminnan kautta. Lisäksi hän on intohimoinen alustan jatkuvaan laajentamiseen uusimmilla teknologioilla.

Shivanshu Upadhyay on pääratkaisuarkkitehti AWS Business Development and Strategic Industries -ryhmässä. Tässä roolissa hän auttaa edistyneimpiä AWS:n käyttäjiä muuttamaan toimialaansa käyttämällä tehokkaasti dataa ja tekoälyä.

Alan Tan on SageMakerin vanhempi tuotepäällikkö, joka johtaa suuria mallipäätelmiä. Hän on intohimoinen koneoppimisen soveltamisesta analytiikan alalla. Työn ulkopuolella hän viihtyy ulkona.