MLOps: DevOps i en värld av maskininlärning

Under 2018 dök konceptet MLOps upp i professionella kretsar och på tematiska konferenser dedikerade till AI, som snabbt tog fäste i branschen och nu utvecklas som en oberoende riktning. I framtiden kan MLOps bli ett av de mest populära områdena inom IT. Vad är det och vad äts det med? Låt oss ta reda på det nedan.

Vad är MLOps

MLOps (som kombinerar maskininlärningsteknologier och processer och tillvägagångssätt för att implementera utvecklade modeller i affärsprocesser) är ett nytt sätt att samarbeta mellan företagsrepresentanter, vetenskapsmän, matematiker, maskininlärningsspecialister och IT-ingenjörer när de skapar artificiell intelligenssystem.

Det är med andra ord ett sätt att omvandla metoder och teknologier för maskininlärning till ett användbart verktyg för att lösa affärsproblem. 

Det är nödvändigt att förstå att produktivitetskedjan börjar långt före utvecklingen av modellen. Dess första steg är att definiera ett affärsproblem, en hypotes om värdet som kan extraheras från data och en affärsidé för att tillämpa den. 

Själva konceptet MLOps uppstod som en analogi till konceptet DevOps i relation till maskininlärningsmodeller och teknologier. DevOps är ett tillvägagångssätt för mjukvaruutveckling som låter dig öka hastigheten på implementeringen av individuella förändringar samtidigt som du bibehåller flexibilitet och tillförlitlighet med hjälp av ett antal tillvägagångssätt, inklusive kontinuerlig utveckling, uppdelning av funktioner i ett antal oberoende mikrotjänster, automatiserad testning och driftsättning av individuella förändringar, global hälsoövervakning, system för snabbinsats för upptäckta fel m.m. 

DevOps har definierat mjukvarans livscykel, och communityn har kommit på idén att tillämpa samma metodik på big data. DataOps är ett försök att anpassa och utöka metodiken med hänsyn till funktionerna för att lagra, överföra och bearbeta stora mängder data i olika och interoperabla plattformar.
  
Med tillkomsten av en viss kritisk massa av maskininlärningsmodeller implementerade i företagens affärsprocesser, märktes en stark likhet mellan livscykeln för matematiska maskininlärningsmodeller och mjukvarans livscykel. Den enda skillnaden är att modellalgoritmerna skapas med hjälp av verktyg och metoder för maskininlärning. Därför uppstod naturligtvis idén att tillämpa och anpassa redan kända metoder för mjukvaruutveckling för maskininlärningsmodeller. Således kan följande nyckelstadier urskiljas i livscykeln för maskininlärningsmodeller:

• definiera en affärsidé;
• modellutbildning;
• testning och implementering av modellen i affärsprocessen;
• modellens funktion.

När det under drift finns ett behov av att ändra eller träna om modellen på nya data, startar cykeln igen - modellen förfinas, testas och en ny version distribueras.

Reträtt. Varför skola om och inte omskola? Termen "modellomskolning" har en dubbel betydelse: bland experter betyder det en modelldefekt, när modellen förutsäger väl, faktiskt upprepar den förutsagda parametern på träningssetet, men presterar mycket sämre på det externa dataprovet. Naturligtvis är en sådan modell en defekt, eftersom denna defekt inte tillåter dess användning.

I denna livscykel verkar det logiskt att använda DevOps-verktyg: automatiserad testning, driftsättning och övervakning, design av modellberäkningar i form av separata mikrotjänster. Men det finns också ett antal funktioner som förhindrar direkt användning av dessa verktyg utan ytterligare ML-bindning.

Hur man får modeller att fungera och vara lönsamma

Som ett exempel där vi kommer att demonstrera användningen av MLOps-metoden, kommer vi att ta den klassiska uppgiften att robotisera ett chattstöd för en bank (eller någon annan) produkt. Vanligtvis ser en affärsprocess för chattstöd ut så här: en klient anger ett meddelande med en fråga i en chatt och får ett svar från en specialist inom ett fördefinierat dialogträd. Uppgiften att automatisera en sådan chatt löses vanligtvis med hjälp av expertdefinierade regeluppsättningar, som är mycket arbetskrävande att utveckla och underhålla. Effektiviteten för sådan automatisering, beroende på hur komplex uppgiften är, kan vara 20–30 %. Naturligtvis uppstår idén att det är mer lönsamt att implementera en artificiell intelligensmodul - en modell utvecklad med hjälp av maskininlärning, som:

• kan behandla ett större antal förfrågningar utan operatörens deltagande (beroende på ämnet kan effektiviteten i vissa fall nå 70–80 %);
• anpassar sig bättre till icke-standardiserade formuleringar i dialog - kan bestämma avsikten, användarens verkliga önskan baserat på en inte tydligt formulerad begäran;
• vet hur man avgör när modellens svar är adekvat, och när det finns tvivel om "medvetenheten" om detta svar och du behöver ställa en ytterligare förtydligande fråga eller byta till operatören;
• kan dessutom tränas automatiskt (istället för att en grupp utvecklare ständigt anpassar och korrigerar svarsskript, tränas modellen dessutom av en Data Science-specialist som använder lämpliga maskininlärningsbibliotek). 

Hur får man en så avancerad modell att fungera? 

Som med att lösa alla andra problem, innan du utvecklar en sådan modul, är det nödvändigt att definiera en affärsprocess och formellt beskriva den specifika uppgift som vi kommer att lösa med hjälp av maskininlärningsmetoden. Vid denna tidpunkt börjar operationaliseringsprocessen, betecknad med akronymen Ops. 

Nästa steg är att Datavetaren i samarbete med Dataingenjören kontrollerar tillgängligheten och tillräckligheten av data och affärshypotesen om affärsidéns genomförbarhet, utvecklar en prototypmodell och testar dess faktiska effektivitet. Först efter bekräftelse av verksamheten kan övergången från att utveckla en modell till att integrera den i system som utför en specifik affärsprocess påbörjas. End-to-end implementeringsplanering, en djup förståelse i varje steg av hur modellen kommer att användas och vilken ekonomisk effekt den kommer att ge, är en grundläggande punkt i processerna för att introducera MLOps-metoder i företagets tekniska landskap.

Med utvecklingen av AI-teknologier ökar antalet och variationen av problem som kan lösas med hjälp av maskininlärning exponentiellt. Varje sådan affärsprocess är en besparing för företaget på grund av automatiseringen av massanställdas arbete (callcenter, kontroll och sortering av dokument, etc.), det är en utökning av kundbasen genom att lägga till nya attraktiva och bekväma funktioner, det sparar pengar på grund av optimal användning och omfördelning av resurser och mycket mer. I slutändan är varje process fokuserad på att skapa värde och måste som ett resultat ge en viss ekonomisk effekt. Här är det mycket viktigt att tydligt formulera affärsidén och beräkna den förväntade vinsten av att implementera modellen i företagets övergripande värdeskapande struktur. Det finns situationer när implementeringen av en modell inte motiverar sig själv, och den tid som specialister på maskininlärning spenderar är mycket dyrare än arbetsplatsen för operatören som utför denna uppgift. Det är därför det är nödvändigt att försöka identifiera sådana fall i de tidiga stadierna av att skapa AI-system.

Följaktligen börjar modeller generera vinst först när affärsproblemet har formulerats korrekt i MLOps-processen, prioriteringar har gjorts och processen för att introducera modellen i systemet har formulerats i de tidiga utvecklingsstadierna.

Ny process – nya utmaningar

Ett heltäckande svar på den grundläggande affärsfrågan om hur tillämpliga ML-modeller är för att lösa problem, den allmänna frågan om förtroende för AI är en av de viktigaste utmaningarna i processen att utveckla och implementera MLOps-metoder. Inledningsvis är företag skeptiska till införandet av maskininlärning i processer - det är svårt att förlita sig på modeller på platser där man tidigare som regel arbetade. För företag verkar program vara en "svart låda", vars relevans fortfarande måste bevisas. Dessutom finns det strikta krav från statliga tillsynsmyndigheter inom banker, i teleoperatörers verksamhet och andra. Alla system och algoritmer som implementeras i bankprocesser är föremål för revision. För att lösa detta problem, för att bevisa för företag och tillsynsmyndigheter giltigheten och riktigheten av artificiell intelligens-svar, introduceras övervakningsverktyg tillsammans med modellen. Dessutom finns det ett oberoende valideringsförfarande, obligatoriskt för regulatoriska modeller, som uppfyller kraven från centralbanken. En oberoende expertgrupp granskar resultaten av modellen med hänsyn till indata.

Den andra utmaningen är att bedöma och ta hänsyn till modellrisker när man implementerar en maskininlärningsmodell. Även om en person inte kan svara på frågan med hundra procent säkerhet om samma klänning var vit eller blå, så har artificiell intelligens också rätt att göra ett misstag. Det är också värt att tänka på att data kan förändras över tid, och modeller behöver tränas om för att ge ett tillräckligt korrekt resultat. För att säkerställa att affärsprocessen inte blir lidande är det nödvändigt att hantera modellrisker och övervaka modellens prestanda och regelbundet omskola den på ny data.

Men efter det första skedet av misstro börjar den motsatta effekten uppstå. Ju fler modeller som framgångsrikt implementeras i processer, desto mer växer verksamhetens aptit för användningen av artificiell intelligens - nya och nya problem upptäcks som kan lösas med hjälp av maskininlärningsmetoder. Varje uppgift utlöser en hel process som kräver vissa kompetenser:

• dataingenjörer förbereder och bearbetar data;
• datavetare använder verktyg för maskininlärning och utvecklar en modell;
• IT implementerar modellen i systemet;
• ML-ingenjören bestämmer hur denna modell korrekt ska integreras i processen, vilka IT-verktyg som ska användas, beroende på kraven på modellens tillämpningssätt, med hänsyn till flödet av förfrågningar, svarstid etc. 
• En ML-arkitekt designar hur en mjukvaruprodukt fysiskt kan implementeras i ett industrisystem.

Hela cykeln kräver ett stort antal högt kvalificerade specialister. Vid en viss tidpunkt i utvecklingen och graden av penetration av ML-modeller i affärsprocesser visar det sig att linjärt skala antalet specialister i proportion till ökningen av antalet uppgifter blir dyrt och ineffektivt. Därför uppstår frågan om att automatisera MLOps-processen - definiera flera standardklasser av maskininlärningsproblem, utveckla standarddatabehandlingspipelines och ytterligare utbildning av modeller. I en idealbild kräver att lösa sådana problem proffs som är lika skickliga på kompetenser i skärningspunkten mellan Big Data, Data Science, DevOps och IT. Därför är det största problemet i Data Science-branschen och den största utmaningen med att organisera MLOps-processer bristen på sådan kompetens på den befintliga utbildningsmarknaden. Specialister som uppfyller dessa krav är idag sällsynta på arbetsmarknaden och är guld värda.

På frågan om kompetens

I teorin kan alla MLOps-uppgifter lösas med klassiska DevOps-verktyg och utan att tillgripa en specialiserad förlängning av förebilden. Sedan, som vi noterade ovan, måste en datavetare inte bara vara en matematiker och dataanalytiker, utan också en guru för hela pipelinen - han är ansvarig för att utveckla arkitekturen, programmera modeller på flera språk beroende på arkitekturen, förbereda en datamart och distribuera själva applikationen. Att skapa det tekniska ramverket som implementeras i MLOps-processen tar dock upp till 80 % av arbetskostnaderna, vilket innebär att en kvalificerad matematiker, som är en kvalitetsdataforskare, endast kommer att ägna 20 % av sin tid åt sin specialitet . Därför blir det viktigt att definiera rollerna för specialister som är involverade i processen att implementera maskininlärningsmodeller. 

Hur detaljerat rollerna ska avgränsas beror på företagets storlek. Det är en sak när en startup har en specialist, en hård arbetare i energireserven, som är hans egen ingenjör, arkitekt och DevOps. Det är en helt annan sak när, i ett stort företag, alla modellutvecklingsprocesser är koncentrerade till ett fåtal datavetenskapsspecialister på hög nivå, medan en programmerare eller databasspecialist - en vanligare och billigare kompetens på arbetsmarknaden - kan ta på det mesta av arbetet, rutinuppgifter.

Således beror hastigheten och kvaliteten på de utvecklade modellerna, teamets produktivitet och mikroklimatet i det direkt på var gränsen går i valet av specialister för att stödja MLOps-processen och hur processen för operationalisering av de utvecklade modellerna är organiserad. .

Vad vårt team redan har gjort

Vi har nyligen börjat bygga en kompetensstruktur och MLOps-processer. Men våra projekt om modelllivscykelhantering och om att använda modeller som en tjänst är redan i MVP-teststadiet.

Vi fastställde också den optimala kompetensstrukturen för ett stort företag och den organisatoriska strukturen för interaktion mellan alla deltagare i processen. Agila team organiserades för att lösa problem för hela skalan av företagskunder, och en process av interaktion med projektteam för att skapa plattformar och infrastruktur, som är grunden för MLOps-byggnaden under uppbyggnad, etablerades.

Frågor inför framtiden

MLOps är ett växande område som upplever brist på kompetens och kommer att ta fart i framtiden. Under tiden är det bäst att bygga vidare på DevOps utvecklingar och praxis. Huvudmålet med MLOps är att mer effektivt använda ML-modeller för att lösa affärsproblem. Men detta väcker många frågor:

• Hur kan man minska tiden för att lansera modeller i produktion?
• Hur minskar man byråkratisk friktion mellan team med olika kompetenser och ökar fokus på samarbete?
• Hur spårar man modeller, hanterar versioner och organiserar effektiv övervakning?
• Hur skapar man en verkligt cirkulär livscykel för en modern ML-modell?
• Hur standardiserar man maskininlärningsprocessen?

Svaren på dessa frågor kommer till stor del avgöra hur snabbt MLOps kommer att nå sin fulla potential.

Källa: will.com