Voitot:
- Kyky tunnistaa koodi-data-malli-trioon ja paketointiin liittyvät ML:n erityishaasteet ja esitellä malli verkossa tai erässä liiketoiminnan tarpeiden mukaan.
- Mahdollisuus toteuttaa asteittaisia ja peruutuskäyttöönottomalleja (varjo, kanaria, A/B, palautus) ja lisätä testattu palautussuunnitelma jokaiseen käyttöön.
- Kyky pitää tuotantoon asetetun mallin data-koodi-metrinen linkki jäljitettävänä arviointikynnysohjatulla CI/CD:llä ja mallirekisterillä
Mallin saaminen 95 %:n tarkkuuden saavuttamiseksi kannettavassa on vain puolet tarinasta. Toinen puoli – usein vaikein osa – on saada malli todellisille käyttäjille luotettavalla, skaalautuvalla ja ylläpidettävällä tavalla. MLOps (Machine Learning Operations: ML-mallien tuonnin, käytön ja ylläpidon kurinalaisuus) yhdistää ohjelmistosuunnittelun DevOps-käytännöt ML:n ainutlaatuisiin haasteisiin. Tässä osiossa käymme läpi mallin tuotantoon siirtymisen vaiheita ja miten tekoäly auttaa tässä prosessissa.
Miksi ML eroaa tavallisesta ohjelmistosta?
Tavallisissa ohjelmistoissa käyttäytyminen on koodissa; Jos koodi ei muutu, käyttäytyminen ei muutu. ML:ssä käyttäytyminen riippuu sekä koodista, tiedoista että mallista. Nämä kolme ulottuvuutta luovat MLOpsin lisähaasteita:
- Tietojen ajautuminen: Tuotannossa oleva data siirtyy ajan myötä pois koulutuksen tiedoista; malli on vanhentunut.
- Sinun täytyy versioida kolme asiaa: koodi, data ja malli – kaikki kolme.
- Hiljainen vika: Malli voi epäonnistua kaatumatta, antamatta virheitä, yksinkertaisesti tuottamalla vääriä ennusteita. Tämän saaminen vaatii seurantaa.
Siksi "toimivan mallin" ja "tuotantovalmis mallin" välillä on suuri ero.
Mallin pakkaus ja esittely
Ensimmäinen askel mallin tuotannossa on sen pakkaaminen: mallitiedosto, tarvittavat kirjastot, esikäsittelykoodi ja versiotiedot yhdessä toistettavana kokonaisuutena. Säiliöinti (esim. Docker: sovelluksen sijoittaminen eristettyyn laatikkoon kaikkine riippuvuuksineen) on vakiona tässä; Se poistaa "se toimi koneellani" -ongelman.
Kaksi mallin palvelemisen perusmallia:
- Online/reaaliaikainen (online): Malli on API:n takana ja palauttaa välittömän ennusteen jokaisesta saapuvasta pyynnöstä. Matala latenssi on kriittinen.
- Erä: Malli käsittelee suuria tietojoukkoja ajoittain (esim. luo pisteet kaikille asiakkaille yöllä). Latenssilla ei ole merkitystä, tehokkuus on tärkeää.
Kumpi on oikea, riippuu liiketoiminnan tarpeesta: välitön suositus verkossa, kuukausittaiset riskipisteet eränä.
Vinkki: "Reaaliaikainen" on hinta, ei oletusarvo. Erä on paljon halvempi ja yksinkertaisempi, jos tulos käytetään muutamassa tunnissa. Tarvitsetko todella välitöntä vastausta? Kysy sitä ensin.
Turvalliset jakelustrategiat
Uuden mallin avaaminen suoraan kaikelle liikenteelle on riskialtista; Jos se on väärin, se vaikuttaa kaikkiin. Turvalliset jakelumallit:
- Varjokäyttö: Uusi malli vastaanottaa tuotantoliikennettä, mutta sen ennusteita ei näytetä käyttäjälle, vaan ne kirjataan lokiin. Sitä verrataan vanhaan malliin, jotta nähdään, onko se turvallista todellisessa datassa.
- Kanariansaarten käyttöönotto: Uusi malli otetaan ensin käyttöön pienelle prosenttiosuudelle liikenteestä (esim. 5 %). Jos ongelmaa ei ole, sitä lisätään vähitellen.
- A/B-testaus: Kaksi mallia esitetään todelliselle käyttäjälle rinnakkain ja liiketoimintamittareita (konversiot, napsautukset) verrataan.
- Palautus: Mahdollisuus palata nopeasti vanhaan versioon, jos uusi malli osoittautuu huonoksi. Jokaisella käyttöönotolla tulee olla palautussuunnitelma.
Varoitus: Käyttöönotto ilman palautussuunnitelmaa ei ole valmis. Mahdollisuus palauttaa vanhaan versioon muutamassa minuutissa suojaa käyttäjää, kun uusi malli käyttäytyy odottamatta tuotannossa. Testaa tämä ennen käyttöönottoa.
Heikko lähestymistapa / Vahva lähestymistapa
Heikko: "Malli oli hyvä testauksessa, aloitimme livenä, avasimme sen kaikille."
Güçlü: "Säilöimme mallin, merkitsimme sen versioksi. Käytimme sitä ensin varjotilassa tuotantoliikenteen kanssa 3 päivän ajan ja verrattiin ennusteita vanhaan malliin – poikkeama oli hyväksyttävä. Sitten avasimme sen 5 %:lla kanaarilla, seurasimme läpimenomittareita ja latenssia. Kun ongelmia ei ollut, nostimme sen vähitellen testaamaan takaisin 100%.
Ero: vahva lähestymistapa on asteittainen, mitattu ja palautuva. Riski on rajallinen joka vaiheessa.
CI/CD ja automaatio
CI/CD (Continuous Integration / Continuous Deployment: automaattinen testaus ja koodimuutosten julkaisu) ML:ssä kattaa koodin lisäksi myös datan ja mallin vaiheet. Hyvä ML CI/CD -liukuhihna: suorittaa testejä, kun koodi muuttuu, suorittaa tietojen validoinnin, kouluttaa mallin uudelleen (tarvittaessa), tarkistaa arviointikynnykset ja edistää käyttöönottoa vain, jos kynnykset ovat voimassa. Periaate ”koulutus on automaattista, käyttöönotto kynnysperusteista” estää huonon mallin hiljaisen vuotamisen tuotantoon.
Tekoäly on erittäin hyödyllinen näitä putkia määritettäessä: konfigurointitiedostojen (YAML) luonnosten, testitapausten ja käyttöönottokomentosarjojen kirjoittamisessa. Mutta sinä määrität jakelukynnykset (mikä tahansa mittari ylittää julkaistun arvon) ja palautuskäytännön. nämä ovat liiketoimintariskipäätöksiä.
Toistettavuuden infrastruktuuri
Mallin toiminnan toistamiseksi tuotannossa, mallirekisteri: tietue, joka säilyttää, mikä malli on koulutettu millä tiedoilla ja koodilla ja mitkä mittarit se vastaanotti. Jokaisen tuotantomallin osalta seuraavien pitäisi olla seurattavissa: koulutusdatan versio, koodiversio (git commit), hyperparametrit, arviointipisteet ja käyttöönottopäivämäärä. Kun ongelma ilmenee, sinun pitäisi pystyä vastaamaan kysymykseen "mikä malli tuotti tämän ennusteen, millä tiedoilla?" minuuteissa. Syvennämme tätä yksikössä 11.
kolme minilaukkua
Tapaus 1 - Varjojakauman havaitsema ongelma. Suositusmalli voitti testauksessa vanhan. Sen suorittamisen tuotantoliikenteellä varjotilassa todettiin tuottavan erittäin huonoja suosituksia tietylle käyttäjäsegmentille (uudet käyttäjät) – testidata ei edustanut tätä segmenttiä. Malli korjattiin ilman, että sitä koskaan näytettiin käyttäjälle. Jos se avattaisiin suoraan, uusi käyttökokemus häiriintyisi.
Tapaus 2 - Peruuttamaton jakelu. Tiimi otti käyttöön uuden hinnoittelumallin kaikelle liikenteelle ilman peruutussuunnitelmia. Malli hinnoitteli jotkin tuotteet yllättäen erittäin halvalla. Paluu vanhaan versioon kesti tunteja, koska prosessi ei ollut valmis. Tuli menetetty vakavasti. Myöhemmin pakollinen palautustestaus lisättiin jokaiseen käyttöön.
Tapaus 3 - Hiljainen tiedonsiirto. Petoskuvio ilmestyi kuukausia ilman virheitä. Mutta huijareiden taktiikka muuttui (datan ajautuminen) ja mallin takaisinveto putosi hiljaa. Kukaan ei huomannut, koska valvontaa ei ollut. Kun ennustejakauman seurantapaneeli perustettiin, ajautuminen tuli näkyviin aikaisin. Käsittelemme seurannan yksikössä 8.
Kopioitavat mallit
Kirjoita tämän mallin käyttöönottosuunnitelmaluonnos. Malli: [mitä se tekee], käyttö: [verkossa vai erä?] Pitäisi sisältää:1) Pakkaus (säiliö, versiointi)2) Inkrementaalinen käyttöönottostrategia (shadow/Canary/A-B) ja miksi3) Seurattavat mittarit (liiketoiminta + tekninen + viive)4) Palautussuunnitelma ja kuinka testata5) Käyttöönoton tulisi ylittää mitkä rajat.
Tarkista tämä ML CI/CD-liukuhihna:1) Onko tietojen validointi rivillä?2) Voiko käyttöönotto jatkua ilman arviointikynnystä (eikö pitäisi)?3) Onko palautus automaattinen?4) Seurataanko tietoja+koodia+metriikkaa mallirekisterissä?Pline-kokoonpano: [config]
Auta minua päättämään, sopiiko verkko- vai eräesitys tähän malliin. Kuinka kauan tulosta käytetään: [välitön / minuutti / tunti / päivä]Odotettu pyyntöjen määrä: [numero]Onko viiverajoitus: [ms]Kumpaa suosittelisit kustannusten ja monimutkaisuuden kannalta ja miksi?
Kirjoita palautusmenettely tälle mallille.- Mikä mitta/kynnys laukaisee huonon suorituskyvyn?- Mitkä ovat palautusvaiheet?- Kuinka kauan palautuksen tulisi kestää (tavoite)?- Kuinka testaan tätä menettelyä ennen tuotantoa?
Esityksen kuviotaulukko
kriteeri
Online (reaaliaikainen)
Erä
viive
Kriittinen (ms)
merkityksetön
Käyttö
Välitön vastaus vaaditaan
Jaksottaiset pisteet
Kustannukset
korkea
alhainen
monimutkaisuus
korkea
alhainen
esimerkki
Live suositus, huijaus
Kuukauden riskipisteet
Yleisiä virheitä
- Levitä ilman hakusuunnitelmaa. Väärä malli koskettaa koko käyttäjää.
- Avautuu suoraan 100 % liikenteelle. Rajoita riskiä porrastetulla jakelulla.
- Valvontaa ei perusteta. Malli tuottaa virheitä hiljaa, ilman virheitä.
- Ylimääräinen reaaliaikainen esitys. Vaikka erät ovat riittävät, kustannukset ja monimutkaisuus kasvavat.
- Ei linkitä malli-data-koodiversioita. Et voi toistaa ongelmaa.
- Automaattinen julkaisu ilman jakelukynnystä. Huono malli hiipii sisään hiljaa.
Yhteenvetona
Mallin siirtäminen tuotantoon on erilainen ja usein vaikeampi suunnittelutehtävä kuin sen kouluttaminen. ML vaatii ylimääräistä kurinalaisuutta, koska se riippuu koodi-data-mallikolmiosta: pakkaus ja versiointi, liiketoimintatarpeen mukainen toimitusmalli (online/erä), asteittainen ja palautuva käyttöönotto, kynnysohjattu CI/CD ja mallin rekisteröinti. Tekoäly on tehokas apu tämän infrastruktuurin koodin ja kokoonpanon luomisessa; mutta jakelukynnykset, takaisinperintäpolitiikka ja riskipäätökset ovat sinun. Jakelu ilman palautussuunnitelmaa ei ole valmis.
Sovellustehtävä
Säiliöi (Docker) malli ja merkitse sen versio. Päätä, tarjoatko verkossa vai erässä yrityksesi tarpeiden perusteella, ja kirjoita perustelut. Dokumentoi vaiheittainen käyttöönottosuunnitelma (varjo tai kanarialintu) ja testattu palautusmenettely. Muista tallentaa tietojen versio, koodin vahvistus ja arviointipisteet mallirekisteriin.
tarkistuslista
- [ ] Malli on pakattu ja versioitu (säiliö + etiketti).
- [ ] Esitysmalli (online/erä) valittiin liiketoiminnan tarpeiden mukaan.
- [ ] Vaiheittainen käyttöönottostrategia (varjo/kanaari) toteutettu.
- [ ] Palautusmenettely kirjoitettu ja testattu.
- [ ] CI/CD ei edistä käyttöönottoa ennen kuin arviointikynnys on saavutettu.
- [ ] Mallirekisterissä on data+koodi+metrinen linkki.