2018. aastal ilmus professionaalsetes ringkondades ja tehisintellektile pühendatud temaatilistel konverentsidel MLOps-ide kontseptsioon, mis haaras tööstuses kiiresti ja areneb nüüd iseseisva suunana. Tulevikus võib MLOps-st saada IT üks populaarsemaid valdkondi. Mis see on ja millega seda süüakse? Uurime allpool.
Mis on MLOps
MLOps (masinõppetehnoloogiate ja -protsesside ning väljatöötatud mudelite äriprotsessidesse juurutamise lähenemisviiside ühendamine) on uus koostööviis ettevõtete esindajate, teadlaste, matemaatikute, masinõppe spetsialistide ja IT-inseneride vahel tehisintellektisüsteemide loomisel.
Teisisõnu on see viis masinõppemeetodite ja -tehnoloogiate muutmiseks kasulikuks tööriistaks äriprobleemide lahendamisel.
On vaja mõista, et tootlikkuse ahel algab ammu enne mudeli väljatöötamist. Selle esimene samm on määratleda äriprobleem, hüpotees andmetest eraldatava väärtuse kohta ja äriidee selle rakendamiseks.
MLOpside kontseptsioon tekkis analoogina DevOpsi kontseptsiooniga seoses masinõppe mudelite ja tehnoloogiatega. DevOps on lähenemine tarkvaraarendusele, mis võimaldab suurendada üksikute muudatuste rakendamise kiirust, säilitades samal ajal paindlikkuse ja töökindluse, kasutades mitmeid lähenemisviise, sealhulgas pidevat arendust, funktsioonide jagamist mitmeks sõltumatuks mikroteenuseks, automatiseeritud testimist ja üksikisiku juurutamist. muutused, globaalne terviseseire, kiirreageerimissüsteem avastatud rikete korral jne.
DevOps on määratlenud tarkvara elutsükli ja kogukond on tulnud välja ideega rakendada sama metoodikat suurandmete puhul. DataOps on katse kohandada ja laiendada metoodikat, võttes arvesse suurte andmemahtude salvestamise, edastamise ja töötlemise funktsioone erinevatel ja koostalitlusvõimelistel platvormidel.
Ettevõtete äriprotsessides rakendatavate masinõppemudelite teatud kriitilise massi tulekuga märgati tugevat sarnasust matemaatiliste masinõppemudelite elutsükli ja tarkvara elutsükli vahel. Ainus erinevus seisneb selles, et mudelialgoritmid luuakse masinõppevahendeid ja meetodeid kasutades. Seetõttu tekkis loomulikult idee rakendada ja kohandada masinõppe mudelite jaoks juba teadaolevaid tarkvaraarenduse lähenemisviise. Seega saab masinõppemudelite elutsüklis eristada järgmisi põhietappe:
- äriidee määratlemine;
- mudelikoolitus;
- mudeli testimine ja juurutamine äriprotsessi;
- mudeli toimimine.
Kui töötamise ajal on vaja mudelit uute andmete põhjal muuta või ümber õpetada, algab tsükkel uuesti - mudelit täpsustatakse, testitakse ja võetakse kasutusele uus versioon.
Taganeda. Miks ümberõppida ja mitte ümber õppida? Mõistel “mudeli ümberõpe” on kahekordne tähendus: ekspertide seas tähendab see mudeli defekti, kui mudel ennustab hästi, tegelikult kordab ennustatud parameetrit koolituskomplektis, kuid toimib välise andmevalimi puhul palju halvemini. Loomulikult on selline mudel defektne, kuna see defekt ei võimalda seda kasutada.
Selles elutsüklis tundub loogiline kasutada DevOpsi tööriistu: automatiseeritud testimine, juurutamine ja jälgimine, mudeliarvutuste kujundamine eraldi mikroteenuste näol. Kuid on ka mitmeid funktsioone, mis takistavad nende tööriistade otsest kasutamist ilma täiendava ML-i sidumiseta.
Kuidas panna mudelid tööle ja kasumlikuks
Näitena, milles demonstreerime MLOps-lähenemise kasutamist, võtame klassikalise ülesande – robotiseerida pangandus- (või mõne muu) toote vestlustoe. Tavaliselt näeb vestlustoe äriprotsess välja selline: klient sisestab vestluses küsimusega sõnumi ja saab eelnevalt määratletud dialoogipuus spetsialistilt vastuse. Sellise vestluse automatiseerimise ülesanne lahendatakse tavaliselt asjatundlikult määratletud reeglistiku abil, mille arendamine ja hooldamine on väga töömahukas. Sellise automatiseerimise efektiivsus võib olenevalt ülesande keerukusastmest olla 20–30%. Loomulikult tekib mõte, et tulusam on rakendada tehisintellekti moodulit – masinõppe abil välja töötatud mudelit, mis:
- suudab ilma operaatori osaluseta töödelda suuremat hulka päringuid (olenevalt teemast võib mõnel juhul efektiivsus ulatuda 70–80%);
- kohandub dialoogis paremini ebastandardse sõnastusega - oskab mitte selgelt sõnastatud taotluse põhjal kindlaks teha kavatsust, kasutaja tegelikku soovi;
- teab, kuidas teha kindlaks, millal mudeli vastus on adekvaatne ja kui on kahtlusi selle vastuse "teadlikkuses" ja peate esitama täiendava täpsustava küsimuse või pöörduma operaatori poole;
- saab täiendavalt koolitada automaatselt (selle asemel, et grupp arendajaid pidevalt vastuseskripte kohandaks ja parandaks, koolitab mudelit täiendavalt andmeteaduse spetsialist, kasutades vastavaid masinõppe teeke).
Kuidas selline arenenud mudel tööle panna?
Nagu iga muu probleemi lahendamisel, on enne sellise mooduli väljatöötamist vaja defineerida äriprotsess ja ametlikult kirjeldada konkreetne ülesanne, mida masinõppe meetodil lahendame. Siinkohal algab operatiivsuse protsess, mida tähistab akronüüm Ops.
Järgmise sammuna kontrollib Andmeteadlane koostöös Andmeinseneriga andmete kättesaadavust ja piisavust ning äriidee elujõulisuse kohta püstitatud ärihüpoteesi, töötades välja prototüübi mudeli ja testides selle tegelikku efektiivsust. Alles pärast ettevõttepoolset kinnitust saab alata üleminek mudeli väljatöötamiselt selle integreerimisele konkreetset äriprotsessi teostavatesse süsteemidesse. Täielik juurutamise planeerimine, sügav mõistmine igas etapis, kuidas mudelit kasutatakse ja millist majanduslikku efekti see toob, on MLOps-lähenemiste juurutamise protsessi põhipunkt ettevõtte tehnoloogilisele maastikule.
Tehisintellekti tehnoloogiate arenedes kasvab plahvatuslikult masinõppe abil lahendatavate probleemide arv ja mitmekesisus. Iga selline äriprotsess on ettevõtte jaoks kokkuhoid tänu masstöötajate tööjõu automatiseerimisele (kõnekeskus, dokumentide kontrollimine ja sorteerimine jne), see on kliendibaasi laiendamine uute atraktiivsete ja mugavate funktsioonide lisamisega, see on raha kokkuhoid tänu nende optimaalsele kasutamisele ja ressursside ümberjagamisele ning paljule muule. Lõppkokkuvõttes on iga protsess keskendunud väärtuse loomisele ja peab sellest tulenevalt tooma teatud majandusliku efekti. Siin on väga oluline äriidee selgelt sõnastada ja arvutada mudeli rakendamisest oodatav kasum ettevõtte üldises väärtusloome struktuuris. On olukordi, kus mudeli juurutamine ei õigusta ennast ning masinõppe spetsialistide ajakulu on palju kallim kui seda ülesannet täitva operaatori töökoht. Seetõttu on vaja selliseid juhtumeid püüda tuvastada juba tehisintellektisüsteemide loomise algfaasis.
Järelikult hakkavad mudelid kasumit tootma alles siis, kui äriprobleem on MLOps protsessis õigesti sõnastatud, prioriteedid paika pandud ja mudeli süsteemi juurutamise protsess on sõnastatud arenduse algfaasis.
Uus protsess – uued väljakutsed
Põhjalik vastus põhilisele äriküsimusele selle kohta, kui rakendatavad on ML-mudelid probleemide lahendamisel, üldine usalduse küsimus tehisintellekti vastu on üks peamisi väljakutseid MLOps-i lähenemisviiside väljatöötamise ja rakendamise protsessis. Ettevõtjad suhtuvad masinõppe protsessidesse juurutamisesse esialgu skeptiliselt – mudelitele on raske loota kohtades, kus varem reeglina töötati. Ettevõtluse jaoks näivad programmid olevat "must kast", mille asjakohasus vajab veel tõestamist. Lisaks kehtivad panganduses, telekommunikatsioonioperaatorite ja teistes ärides valitsuse regulaatorite ranged nõuded. Kõik süsteemid ja algoritmid, mida pangandusprotsessides rakendatakse, kuuluvad auditeerimisele. Selle probleemi lahendamiseks, tõestamaks ettevõtetele ja regulaatoritele tehisintellekti vastuste paikapidavust ja õigsust, võetakse koos mudeliga kasutusele seirevahendid. Lisaks on olemas sõltumatu valideerimisprotseduur, mis on regulatiivsetele mudelitele kohustuslik ja mis vastab keskpanga nõuetele. Sõltumatu ekspertrühm auditeerib mudeli abil saadud tulemusi, võttes arvesse sisendandmeid.
Teiseks väljakutseks on mudeliriskide hindamine ja nendega arvestamine masinõppemudeli rakendamisel. Isegi kui inimene ei oska sajaprotsendilise kindlusega vastata küsimusele, kas see sama kleit oli valge või sinine, siis on ka tehisintellektil õigus eksida. Samuti tasub arvestada, et andmed võivad aja jooksul muutuda ning piisavalt täpse tulemuse saamiseks tuleb mudeleid ümber õpetada. Tagamaks, et äriprotsess ei kannataks, on vaja juhtida mudeliriske ja jälgida mudeli toimivust, koolitades seda regulaarselt uute andmete osas.
Kuid pärast usaldamatuse esimest etappi hakkab ilmnema vastupidine efekt. Mida rohkem mudeleid edukalt protsessidesse juurutatakse, seda enam kasvab ettevõtete isu tehisintellekti kasutamise järele – leitakse üha uusi ja uusi probleeme, mida saab lahendada masinõppemeetodite abil. Iga ülesanne käivitab kogu protsessi, mis nõuab teatud pädevusi:
- andmeinsenerid valmistavad ette ja töötlevad andmeid;
- andmeteadlased kasutavad masinõppevahendeid ja töötavad välja mudeli;
- IT juurutab mudeli süsteemi;
- ML-i insener määrab, kuidas seda mudelit protsessi õigesti integreerida, milliseid IT-tööriistu kasutada, olenevalt mudeli rakendusviisile esitatavatest nõuetest, võttes arvesse päringute voogu, reageerimisaega jne.
- ML-i arhitekt kavandab, kuidas tarkvaratoodet saab tööstussüsteemis füüsiliselt rakendada.
Kogu tsükkel nõuab suurt hulka kõrgelt kvalifitseeritud spetsialiste. ML-mudelite arengu ja äriprotsessidesse tungimise teatud ajahetkel selgub, et spetsialistide arvu lineaarne skaleerimine proportsionaalselt ülesannete arvu suurenemisega muutub kulukaks ja ebaefektiivseks. Seetõttu kerkib küsimus MLOps protsessi automatiseerimisest – mitmete masinõppeprobleemide standardklasside määratlemisest, standardsete andmetöötluskonveierite väljatöötamisest ja mudelite lisakoolitusest. Ideaalses pildis on selliste probleemide lahendamiseks vaja professionaale, kes on samaväärselt valdavad kompetentsides suurandmete, andmeteaduse, DevOpsi ja IT ristumiskohas. Seetõttu on andmeteaduse tööstuse suurim probleem ja suurim väljakutse MLOps protsesside korraldamisel sellise kompetentsi puudumine olemasoleval koolitusturul. Nendele nõuetele vastavad spetsialistid on praegu tööturul haruldased ja on kulda väärt.
Pädevuste teemal
Teoreetiliselt saab kõiki MLOpsi ülesandeid lahendada klassikaliste DevOpsi tööriistade abil ja kasutamata eeskuju spetsiaalset laiendust. Seejärel, nagu eespool märkisime, peab andmeteadlane olema mitte ainult matemaatik ja andmeanalüütik, vaid ka kogu torujuhtme guru - ta vastutab arhitektuuri arendamise, mitmes keeles mudelite programmeerimise, olenevalt arhitektuurist, ettevalmistamise eest. andmeturu ja rakenduse enda juurutamine. End-to-end protsessis rakendatava tehnoloogilise raamistiku loomine võtab aga kuni 80% tööjõukuludest, mis tähendab, et kvalifitseeritud matemaatik, kes on kvaliteetne andmeteadlane, pühendab oma erialale vaid 20% oma ajast. . Seetõttu muutub masinõppe mudelite juurutamise protsessi kaasatud spetsialistide rollide piiritlemine ülioluliseks.
Kui üksikasjalikult tuleks rollid piiritleda, sõltub ettevõtte suurusest. Üks asi on see, kui idufirmal on üks spetsialist, kõva energiareservi töötaja, kes on tema enda insener, arhitekt ja DevOps. Hoopis teine asi on see, kui suures ettevõttes on kõik mudeliarenduse protsessid koondunud mõnele kõrgetasemelisele andmeteaduse spetsialistile, samal ajal kui programmeerija või andmebaasispetsialist - tööturul levinum ja odavam kompetents - võib võtta. enamikul töödest.rutiinsed ülesanded.
Seega sõltub väljatöötatud mudelite kiirus ja kvaliteet, meeskonna tootlikkus ja mikrokliima selles otseselt sellest, kus on piir MLOps protsessi toetavate spetsialistide valikul ja kuidas on korraldatud väljatöötatud mudelite operatiivsuse protsess. .
Mida meie meeskond on juba teinud
Hiljuti alustasime kompetentsistruktuuri ja MLOps protsesside ülesehitamist. Kuid meie projektid mudelite elutsükli haldamise ja mudelite teenusena kasutamise kohta on juba MVP testimise etapis.
Samuti määrasime kindlaks suurettevõtte optimaalse kompetentsistruktuuri ja kõigi protsessis osalejate vahelise suhtluse organisatsioonilise struktuuri. Moodustati agiilsed meeskonnad probleemide lahendamiseks kogu äriklientide ringile ning rajati projektimeeskondadega suhtlemisprotsess platvormide ja infrastruktuuri loomiseks, mis on ehitatava MLOpsi hoone vundament.
Küsimused tulevikuks
MLOps on kasvav valdkond, millel on pädevuste nappus ja mis saab tulevikus hoogu juurde. Vahepeal on kõige parem tugineda DevOpsi arendustele ja tavadele. MLOps-i peamine eesmärk on ML-mudelite efektiivsem kasutamine äriprobleemide lahendamisel. Kuid see tekitab palju küsimusi:
- Kuidas lühendada mudelite tootmisse laskmise aega?
- Kuidas vähendada bürokraatlikku hõõrdumist erineva kompetentsiga meeskondade vahel ja suurendada fookust koostööle?
- Kuidas jälgida mudeleid, hallata versioone ja korraldada tõhusat jälgimist?
- Kuidas luua kaasaegsele ML-mudelile tõeliselt ringikujuline elutsükkel?
- Kuidas masinõppe protsessi standardida?
Vastused neile küsimustele määravad suuresti ära, kui kiiresti MLOps oma täieliku potentsiaali saavutab.
Allikas: www.habr.com