MLOps: DevOps mašīnmācīšanās pasaulē

2018. gadā profesionāļu aprindās un AI tematiskajās konferencēs parādījās MLOps koncepcija, kas ātri iekaroja nozarē un tagad attīstās kā neatkarīgs virziens. Nākotnē MLOps var kļūt par vienu no populārākajām IT jomām. Kas tas ir un ar ko to ēd? Uzzināsim tālāk.

Kas ir MLOps

MLOps (apvienojot mašīnmācības tehnoloģijas un procesus un pieejas izstrādāto modeļu ieviešanai biznesa procesos) ir jauns sadarbības veids starp biznesa pārstāvjiem, zinātniekiem, matemātiķiem, mašīnmācības speciālistiem un IT inženieriem, veidojot mākslīgā intelekta sistēmas.

Citiem vārdiem sakot, tas ir veids, kā mašīnmācīšanās metodes un tehnoloģijas pārvērst par noderīgu rīku biznesa problēmu risināšanai. 

Ir jāsaprot, ka produktivitātes ķēde sākas ilgi pirms modeļa izstrādes. Tās pirmais solis ir definēt biznesa problēmu, hipotēzi par vērtību, ko var iegūt no datiem, un biznesa ideju tās pielietošanai. 

Pati MLOps koncepcija radās kā analoģija DevOps jēdzienam saistībā ar mašīnmācīšanās modeļiem un tehnoloģijām. DevOps ir programmatūras izstrādes pieeja, kas ļauj palielināt atsevišķu izmaiņu ieviešanas ātrumu, vienlaikus saglabājot elastību un uzticamību, izmantojot vairākas pieejas, tostarp nepārtrauktu attīstību, funkciju sadalīšanu vairākos neatkarīgos mikropakalpojumos, automatizētu testēšanu un individuālu izvietošanu. izmaiņas, globālais veselības monitorings, ātrās reaģēšanas sistēma atklātajām kļūmēm u.c. 

DevOps ir definējis programmatūras dzīves ciklu, un sabiedrība ir nākusi klajā ar ideju piemērot to pašu metodoloģiju lielajiem datiem. DataOps ir mēģinājums pielāgot un paplašināt metodiku, ņemot vērā liela datu apjoma uzglabāšanas, pārsūtīšanas un apstrādes iespējas dažādās un sadarbspējīgās platformās.
  
Līdz ar uzņēmumu biznesa procesos ieviesto mašīnmācīšanās modeļu noteiktas kritiskās masas parādīšanos tika pamanīta spēcīga līdzība starp matemātisko mašīnmācīšanās modeļu dzīves ciklu un programmatūras dzīves ciklu. Vienīgā atšķirība ir tā, ka modeļu algoritmi tiek veidoti, izmantojot mašīnmācīšanās rīkus un metodes. Tāpēc dabiski radās ideja pielietot un pielāgot jau zināmās programmatūras izstrādes pieejas mašīnmācīšanās modeļiem. Tādējādi mašīnmācības modeļu dzīves ciklā var izdalīt šādus galvenos posmus:

• biznesa idejas definēšana;
• modeļu apmācība;
• modeļa testēšana un ieviešana biznesa procesā;
• modeļa darbība.

Ja darbības laikā ir nepieciešams mainīt vai pārkvalificēt modeli uz jauniem datiem, cikls sākas no jauna - modelis tiek pilnveidots, pārbaudīts un tiek ieviesta jauna versija.

Atkāpties. Kāpēc pārkvalificēties un nepārkvalificēties? Jēdzienam “modeļa pārkvalifikācija” ir divējāda nozīme: ekspertu vidū tas nozīmē modeļa defektu, kad modelis labi prognozē, faktiski atkārto prognozēto parametru apmācības komplektā, bet daudz sliktāk darbojas ārējā datu paraugā. Protams, šāds modelis ir defekts, jo šis defekts neļauj to izmantot.

Šajā dzīves ciklā šķiet loģiski izmantot DevOps rīkus: automatizētu testēšanu, izvietošanu un uzraudzību, modeļu aprēķinu projektēšanu atsevišķu mikropakalpojumu veidā. Taču ir arī vairākas funkcijas, kas neļauj tieši izmantot šos rīkus bez papildu ML saistīšanas.

Kā likt modeļiem strādāt un gūt peļņu

Kā piemēru, kurā demonstrēsim MLOps pieejas izmantošanu, mēs ņemsim klasisko uzdevumu robotizēt tērzēšanas atbalstu banku (vai jebkuram citam) produktam. Parasti tērzēšanas atbalsta biznesa process izskatās šādi: klients tērzēšanā ievada ziņojumu ar jautājumu un saņem atbildi no speciālista iepriekš noteiktā dialoga kokā. Šādas tērzēšanas automatizācijas uzdevums parasti tiek atrisināts, izmantojot profesionāli definētus noteikumu kopumus, kuru izstrāde un uzturēšana ir ļoti darbietilpīga. Šādas automatizācijas efektivitāte atkarībā no uzdevuma sarežģītības pakāpes var būt 20–30%. Likumsakarīgi rodas doma, ka izdevīgāk ir ieviest mākslīgā intelekta moduli - modeli, kas izstrādāts, izmantojot mašīnmācīšanos, kas:

• spēj apstrādāt lielāku pieprasījumu skaitu bez operatora līdzdalības (atkarībā no tēmas atsevišķos gadījumos efektivitāte var sasniegt 70–80%);
• labāk pielāgojas nestandarta formulējumam dialogā - spēj noteikt nolūku, lietotāja patieso vēlmi, pamatojoties uz nepārprotami formulētu pieprasījumu;
• zina, kā noteikt, kad modeļa atbilde ir adekvāta un kad rodas šaubas par šīs atbildes “apziņu” un jāuzdod papildu precizējošs jautājums vai jāpārslēdzas pie operatora;
• var papildus apmācīt automātiski (tā vietā, lai izstrādātāju grupa pastāvīgi pielāgotu un labotu atbildes skriptus, modeli papildus apmāca datu zinātnes speciālists, izmantojot atbilstošās mašīnmācīšanās bibliotēkas). 

Kā panākt, lai šāds uzlabots modelis darbotos? 

Tāpat kā jebkuras citas problēmas risināšanā, pirms šāda moduļa izstrādes ir nepieciešams definēt biznesa procesu un formāli aprakstīt konkrēto uzdevumu, kuru risināsim, izmantojot mašīnmācīšanās metodi. Šajā brīdī sākas operacionalizācijas process, ko apzīmē ar akronīmu Ops. 

Nākamais solis ir tas, ka Datu zinātnieks sadarbībā ar Datu inženieri pārbauda datu pieejamību un pietiekamību un biznesa hipotēzi par biznesa idejas dzīvotspēju, izstrādājot prototipa modeli un pārbaudot tā faktisko efektivitāti. Tikai pēc uzņēmuma apstiprinājuma var sākties pāreja no modeļa izstrādes uz tā integrēšanu sistēmās, kas veic noteiktu biznesa procesu. Pilnīga ieviešanas plānošana, dziļa izpratne katrā posmā par to, kā modelis tiks izmantots un kādu ekonomisko efektu tas dos, ir būtisks punkts MLOps pieeju ieviešanas procesos uzņēmuma tehnoloģiskajā vidē.

Attīstoties AI tehnoloģijām, eksponenciāli pieaug to problēmu skaits un daudzveidība, kuras var atrisināt, izmantojot mašīnmācīšanos. Katrs šāds biznesa process uzņēmumam ir ietaupījums, pateicoties masu darbinieku darba automatizācijai (zvanu centrs, dokumentu pārbaude un šķirošana u.c.), tā ir klientu bāzes paplašināšana, pievienojot jaunas pievilcīgas un ērtas funkcijas, tā ietaupa naudu, pateicoties optimālai to izmantošanai un resursu pārdalei un daudz ko citu. Galu galā jebkurš process ir vērsts uz vērtības radīšanu, un rezultātā tam ir jāsniedz zināms ekonomisks efekts. Šeit ļoti svarīgi ir skaidri formulēt biznesa ideju un aprēķināt sagaidāmo peļņu no modeļa ieviešanas kopējā uzņēmuma vērtības radīšanas struktūrā. Ir situācijas, kad modeļa ieviešana neattaisno sevi, un mašīnmācības speciālistu pavadītais laiks ir daudz dārgāks nekā operatora darba vieta, kas veic šo uzdevumu. Tāpēc ir jāmēģina identificēt šādus gadījumus AI sistēmu izveides sākumposmā.

Līdz ar to modeļi sāk nest peļņu tikai tad, kad MLOps procesā ir pareizi formulēta biznesa problēma, noteiktas prioritātes un modeļa ieviešanas process sistēmā ir noformulēts attīstības sākumposmā.

Jauns process – jauni izaicinājumi

Visaptveroša atbilde uz biznesa pamatjautājumu par to, cik ML modeļi ir piemēroti problēmu risināšanai, vispārējais jautājums par uzticēšanos AI ir viens no galvenajiem izaicinājumiem MLOps pieeju izstrādes un ieviešanas procesā. Sākotnēji uzņēmēji ir skeptiski par mašīnmācības ieviešanu procesos – grūti paļauties uz modeļiem vietās, kur iepriekš parasti strādāja cilvēki. Uzņēmējdarbībai programmas šķiet “melnā kaste”, kuras atbilstība vēl ir jāpierāda. Turklāt banku jomā, telekomunikāciju operatoru biznesā un citos ir stingras valdības regulatoru prasības. Visas sistēmas un algoritmi, kas tiek ieviesti banku procesos, ir pakļauti auditam. Lai atrisinātu šo problēmu, pierādītu uzņēmējiem un regulatoriem mākslīgā intelekta reakciju pamatotību un pareizību, kopā ar modeli tiek ieviesti monitoringa rīki. Turklāt pastāv neatkarīga apstiprināšanas procedūra, kas ir obligāta regulējošiem modeļiem un atbilst Centrālās bankas prasībām. Neatkarīga ekspertu grupa veic modeļa iegūto rezultātu auditu, ņemot vērā ievades datus.

Otrs izaicinājums ir modeļa risku novērtēšana un ņemšana vērā, ieviešot mašīnmācības modeli. Pat ja cilvēks nevar simtprocentīgi atbildēt uz jautājumu, vai tā pati kleita bija balta vai zila, tad arī mākslīgajam intelektam ir tiesības kļūdīties. Ir arī vērts ņemt vērā, ka dati laika gaitā var mainīties, un modeļi ir jāpārkvalificē, lai iegūtu pietiekami precīzu rezultātu. Lai biznesa process neciestu, nepieciešams pārvaldīt modeļu riskus un sekot līdzi modeļa veiktspējai, regulāri to pārkvalificējot uz jauniem datiem.

Bet pēc pirmās neuzticības stadijas sāk parādīties pretējs efekts. Jo vairāk modeļu tiek veiksmīgi ieviesti procesos, jo vairāk pieaug biznesa apetīte pēc mākslīgā intelekta izmantošanas – tiek atrastas jaunas un jaunas problēmas, kuras var atrisināt ar mašīnmācīšanās metodēm. Katrs uzdevums aktivizē visu procesu, kam nepieciešamas noteiktas kompetences:

• datu inženieri sagatavo un apstrādā datus;
• datu zinātnieki izmanto mašīnmācīšanās rīkus un izstrādā modeli;
• IT ievieš modeli sistēmā;
• ML inženieris nosaka, kā pareizi šo modeli integrēt procesā, kādus IT rīkus izmantot, atkarībā no modeļa pielietošanas režīma prasībām, ņemot vērā pieprasījumu plūsmu, atbildes laiku u.c. 
• ML arhitekts izstrādā, kā programmatūras produktu var fiziski ieviest rūpnieciskā sistēmā.

Visam ciklam ir nepieciešams liels skaits augsti kvalificētu speciālistu. Noteiktā ML modeļu attīstības un iespiešanās pakāpē biznesa procesos izrādās, ka speciālistu skaita lineāra mērogošana proporcionāli uzdevumu skaita pieaugumam kļūst dārga un neefektīva. Līdz ar to rodas jautājums par MLOps procesa automatizāciju - vairāku mašīnmācīšanās problēmu standarta klašu definēšanu, standarta datu apstrādes konveijeru izstrādi un modeļu papildu apmācību. Ideālā gadījumā šādu problēmu risināšanai ir nepieciešami profesionāļi, kas ir vienlīdz labi kompetenti lielo datu, datu zinātnes, DevOps un IT krustpunktā. Tāpēc lielākā problēma datu zinātnes nozarē un lielākais izaicinājums MLOps procesu organizēšanā ir šādas kompetences trūkums esošajā apmācību tirgū. Speciālisti, kas atbilst šīm prasībām, šobrīd darba tirgū ir reti sastopami un ir zelta vērti.

Par kompetenču jautājumu

Teorētiski visus MLOps uzdevumus var atrisināt, izmantojot klasiskos DevOps rīkus un neizmantojot specializētu lomu modeļa paplašinājumu. Tad, kā jau minēts iepriekš, datu zinātniekam ir jābūt ne tikai matemātiķim un datu analītiķim, bet arī visa konveijera guru - viņš ir atbildīgs par arhitektūras izstrādi, programmēšanas modeļus vairākās valodās atkarībā no arhitektūras, sagatavošanu. datu tirgus un pašas lietojumprogrammas izvietošana. Tomēr tehnoloģiskā ietvara izveide, kas tiek ieviesta end-to-end MLOps procesā, aizņem līdz pat 80% no darbaspēka izmaksām, kas nozīmē, ka kvalificēts matemātiķis, kas ir kvalitatīvs datu zinātnieks, savai specialitātei veltīs tikai 20% sava laika. . Tāpēc ļoti svarīgi kļūst mašīnmācības modeļu ieviešanas procesā iesaistīto speciālistu lomu noteikšana. 

Tas, cik detalizēti ir jānošķir lomas, ir atkarīgs no uzņēmuma lieluma. Tā ir viena lieta, ja startup ir viens speciālists, cītīgs strādnieks enerģijas rezervē, kas ir viņa paša inženieris, arhitekts un DevOps. Pavisam cita lieta ir tad, ja lielā uzņēmumā visi modeļu izstrādes procesi ir koncentrēti uz dažiem augsta līmeņa datu zinātnes speciālistiem, savukārt programmētājs vai datubāzes speciālists - darba tirgū biežāk sastopama un lētāka kompetence. par lielāko daļu darba.parastie uzdevumi.

Tādējādi izstrādāto modeļu ātrums un kvalitāte, komandas produktivitāte un mikroklimats tajā ir tieši atkarīgs no tā, kur ir robeža speciālistu atlasē MLOps procesa atbalstam un kā tiek organizēts izstrādāto modeļu operacionalizācijas process. .

Ko mūsu komanda jau ir paveikusi

Mēs nesen sākām veidot kompetenču struktūru un MLOps procesus. Taču mūsu projekti par modeļu dzīves cikla pārvaldību un modeļu izmantošanu kā pakalpojumu jau ir MVP testēšanas stadijā.

Mēs arī noteicām optimālo kompetenču struktūru lielam uzņēmumam un visu procesa dalībnieku mijiedarbības organizatorisko struktūru. Tika organizētas veiklās komandas, lai risinātu problēmas visam biznesa klientu lokam, un tika izveidots mijiedarbības process ar projektu komandām, lai izveidotu platformas un infrastruktūru, kas ir topošās MLOps ēkas pamats.

Jautājumi nākotnei

MLOps ir augoša joma, kurā trūkst kompetenču un kas nākotnē iegūs impulsu. Tikmēr vislabāk ir balstīties uz DevOps attīstību un praksi. MLOps galvenais mērķis ir efektīvāk izmantot ML modeļus biznesa problēmu risināšanai. Bet tas rada daudz jautājumu:

• Kā samazināt modeļu palaišanas laiku ražošanā?
• Kā samazināt birokrātisko berzi starp dažādu kompetenču komandām un palielināt fokusu uz sadarbību?
• Kā izsekot modeļus, pārvaldīt versijas un organizēt efektīvu uzraudzību?
• Kā izveidot patiesi apļveida dzīves ciklu modernam ML modelim?
• Kā standartizēt mašīnmācīšanās procesu?

Atbildes uz šiem jautājumiem lielā mērā noteiks, cik ātri MLOps pilnībā sasniegs savu potenciālu.

Avots: www.habr.com