Ar mašininio mokymosi iliuzija pateko į jūsų galvą? Jūs sukate nešiojamąjį kompiuterį, išvalysite fiksuotą duomenų rinkinį ir mokysite modelį, kol spindės tikslumas. Pasitikėjimas auga. Prototypas yra tobulas, ir jis sužavėjo suinteresuotuosius subjektus. „Ar tai gali išgyventi?“ yra pavojingiausias klausimas duomenų moksle. Štai kur daugelyje mašininio mokymosi programų dauguma perspektyvių iniciatyvų per anksti nutraukiamos arba netgi visiškai atšaukiamos. Vieno nešiojamojo kompiuterio prototipo kūrimas į labai perspektyvią debesies gamybos sistemą yra ne tik jūsų demonstravimo pratęsimas. Why Notebook Success Does Not Translate to Production Reality Kodėl nešiojamojo kompiuterio sėkmė nevirsta gamybos realybe Tikriausiai, nešiojamieji kompiuteriai yra patogūs dėl trinties trūkumo. Jūsų duomenys yra statiški. Aplink jus esantis pasaulis yra uždarytas. krašto atvejus ir gedimus labai lengva ignoruoti. Gamyba pašalina viską, kas yra patogu. Iš tikrųjų informacija vėluoja, yra suskaidyta arba iškraipoma. Jūs konkuruojate su kitais aukšto prioriteto procesais, o kai atsiranda klaidų, jie veikia faktinius vartotojus. Vienas iš rizikingiausių prielaidų, dėl kurių komanda žlunga, yra tai, kad modelis, kuris istoriniu požiūriu veikė, veikia su nuolatinėmis, vienalaikėmis apkrovomis taip pat, kaip ir per izoliuotą, vieną prognozę knygelėje. Toks eksperimentavimo ir realybės atotrūkis retai vertinamas rimtai, kol jis tampa žalingas verslui. The Data Problem Nobody Sees Coming Duomenų problemos, kurių niekas nemato Jūsų prototipe informacija yra tobula. Tačiau gamyboje tai yra duomenys, kurie diktuoja darbotvarkę. Upstream formato pokyčiai dažnai būna tylūs. Vertybės sklinda. Naudotojo modeliai vystosi. Jūs diegiate modelius, pagrįstus istoriniais duomenimis; jie pradeda senėti, kai tik juos naudosite dinamiškame pasaulyje. Dauguma komandų yra pasirengusios išplėsti savo debesų infrastruktūros dydį ir netgi neatsižvelgia į duomenų patikimumą. Nuomonė, kad neįtikėtinai lengva sukti daugiau skaičiavimo debesų teikėjams, bet kad nėra automatinio skalavimo mygtuko, kai duomenų vamzdynai teka neteisingai, yra visiškai baisu. Jūsų modelio tikslumas tyliai pablogės, nes jis ignoruoja gaunamų duomenų modelius, o serveriai tampa vis užsiėmę, sukuriant linksmų triukšmų. Accuracy Is Not the Finish Line Tikslumas nėra galutinė linija Praktiškai prognozavimo kokybė, jo vėlavimas, stabilumas ir modelio kaina debesyje yra visi parametrai, nuo kurių priklauso modelio našumas. Galima dirbti su sunkiu modeliu, tačiau galite išleisti daugiau nei savo išvados biudžetą, kad sumokėtumėte debesies sąskaitą.Problema ta, kad inžinieriai labiau linkę padaryti klaidą, naudojant didžiulius ir sudėtingus modelius tik todėl, kad jie egzistuoja.Mažesni, labai optimizuoti modeliai beveik visada yra geresnis inžinerinis pasirinkimas: jie yra pigesni, greitesni ir reikalauja mažiau operacinės kūdikių priežiūros. Environment Mismatch and Dependency Chaos Aplinkosauga ir priklausomybės chaosas Įdiegimas dažnai nepavyksta dėl aplinkos nesuderinamumo. Gamybos debesies serveriai jokiu būdu nepanašūs į nešiojamųjų kompiuterių aplinką. Bibliotekos versijos skiriasi. Įrangos greitintuvai nėra vienodi. Sistemos konfigūracijos įveda subtilius, erzinančius kodo vykdymo būdo pokyčius. Kai komandos nesilaiko griežtos aplinkos kontrolės, dislokavimo metu atsiranda chaosas. Bandymo rinkinys nebėra naudojamas visų prognozėms atlikti. Paslaugos paprasčiausiai išnyksta. Debugavimo procesas tampa košmaru. Atkuriamumas turi būti pagrindinis rūpestis. Reikalingi griežtai supakuoti modeliai ir konteinerizuotos priklausomybės (Docker), siekiant užtikrinti, kad skalavimas būtų ne tik patikimas, bet ir atsparus. Scaling ML Is Not the Same as Scaling Software Skalavimo ML nėra tas pats kaip skalavimo programinė įranga Tradicinę žiniatinklio programą galima lengvai išplėsti pridedant papildomų serverių už apkrovos balansavimo. Modeliams gali prireikti specialios techninės įrangos (pavyzdžiui, GPU ar TPU). Atminties suvartojimas gali smarkiai ir žymiai padidėti darant išvadas. Šaltasis paleidimas gali sulėtinti jūsų atsako laiką į nuskaitymo procesą, o realaus laiko srautinio darbo apkrovoms reikia visiškai kitokios architektūros nei nakties partijos procesui. Nemanykite, kad debesies automatinis skalavimas automatiškai išspręs šias spragas. The Silent Danger of Poor Monitoring Silentinis prastos priežiūros pavojus API ir serverio sveikatą atidžiai stebi dauguma inžinerinių komandų, tačiau modelio stebėjimas dažnai pamirštamas. Kai žiniatinklio serveris žlunga, jis staiga žlunga ir palieka paslaugą nepasiekiamą. Tačiau su ML modeliu gali nebūti žlugimo. Prognozės lėtai dreifuoja. Prietarai įsiskverbia. Produktas tampa nesuderintas. Jūsų modelis blogėja, ir jūs negalite sau leisti laukti, kol klientai skundžiasi ir pajamos atsisakė tai suvokti. Duomenų dreifavimo ir prognozių dreifavimo stebėjimas nėra prabanga; tai vienintelis būdas įsitikinti, ar jūsų sistema iš tikrųjų daro tai, ką jūs sukūrėte. Security and Governance Are Not Afterthoughts Saugumas ir valdymas nėra apmąstymai Kai kuriems žmonėms prototipo nešiojamojo kompiuterio saugumas nėra rūpestis, tačiau darbai, kuriuos paliekate atvirame internete, gali turėti vertingos intelektinės nuosavybės ir labai jautrios informacijos. Hakeriai atvirus galutinius taškus suvokia kaip galimybes pavogti modelius arba sugadinti mokymo duomenis. Jūsų debesų tiekėjo saugumo ir valdymo įrankiai neturėtų būti palikti nenaudojami. Saugus prieiga prie duomenų naudojant griežtus IAM vaidmenis. Užtikrinkite, kad modelio pakeitimai ir duomenų užklausos būtų audituojami. Jei iš pradžių šių priemonių neįgyvendinsite, ilgalaikis saugumo atnaujinimas bus skausmingas ir brangus. Treating ML as a Living System ML kaip gyva sistema Didžiausias MLOps mitas yra tas, kad tikslas yra diegimas. Tiesą sakant, diegimas yra nulinė diena. Sėkmingos inžinerijos komandos nelaiko mašininio mokymosi programinės įrangos išleidimu, bet gyvu organizmu. Jūs turite tęsti savo modelių perkvalifikavimą, tobulinimą ir stebėjimą, nes jie veikia besikeičiančiame pasaulyje. Šios komandos nemano, kad debesis yra pagalbinė priemonė, kad būtų išvengta rimtos inžinerijos; priešingai, jie mato jį kaip tvirtą pagrindą atsparių sistemų kūrimui. Closing Thoughts Uždaromos mintys Konkrečiai kalbant, iššūkis paversti prototipą į gamybą yra ten, kur mašininis mokymasis tampa tikrai įmanomas ir kur daugelis iniciatyvų žlunga. Būdamas debesies pagrindu, nekalbama apie didesnio modelio dydžio ar paleistų serverių skaičiaus didinimą.Tai apie planavimą, architektūrą ir realaus pasaulio grynosios sudėtingumo gerbimą.Sėkmė slypi ne prototipo versijoje, bet kuriant sistemą, galinčią patikimai veikti realybėje.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Šis garso įrašas sukurtas originalia istorijos kalba!

Kodėl jūsų ML prototipas nepavyks gaminti (ir kaip tai išspręsti)

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps