MLOps: DevOps i Machine Learning-verdenen

I 2018 dukkede konceptet MLOps op i fagkredse og på temakonferencer dedikeret til AI, som hurtigt fik fat i branchen og nu udvikler sig som en selvstændig retning. I fremtiden kan MLOps blive et af de mest populære områder inden for IT. Hvad er det, og hvad spises det med? Lad os finde ud af det nedenfor.

Hvad er MLOps

MLOps (kombinerer maskinlæringsteknologier og -processer og tilgange til at implementere udviklede modeller i forretningsprocesser) er en ny måde at samarbejde mellem virksomhedsrepræsentanter, videnskabsmænd, matematikere, maskinlæringsspecialister og it-ingeniører, når de skaber kunstige intelligenssystemer.

Det er med andre ord en måde at gøre maskinlæringsmetoder og -teknologier til et nyttigt værktøj til at løse forretningsproblemer. 

Det er nødvendigt at forstå, at produktivitetskæden begynder længe før udviklingen af ​​modellen. Dets første skridt er at definere et forretningsproblem, en hypotese om den værdi, der kan udvindes fra dataene, og en forretningsidé til at anvende det. 

Selve begrebet MLOps opstod som en analogi til begrebet DevOps i forhold til maskinlæringsmodeller og -teknologier. DevOps er en tilgang til softwareudvikling, der giver dig mulighed for at øge hastigheden for implementering af individuelle ændringer og samtidig bevare fleksibilitet og pålidelighed ved hjælp af en række tilgange, herunder løbende udvikling, opdeling af funktioner i en række uafhængige mikrotjenester, automatiseret test og implementering af individuelle ændringer, global sundhedsovervågning, hurtig reaktionssystem for opdagede fejl mv. 

DevOps har defineret softwarens livscyklus, og fællesskabet har fundet på ideen om at anvende den samme metode til big data. DataOps er et forsøg på at tilpasse og udvide metodikken under hensyntagen til funktionerne ved lagring, transmission og behandling af store mængder data i forskellige og interoperable platforme.
  
Med fremkomsten af ​​en vis kritisk masse af maskinlæringsmodeller implementeret i virksomheders forretningsprocesser, blev der bemærket en stærk lighed mellem livscyklussen for matematiske maskinlæringsmodeller og softwarens livscyklus. Den eneste forskel er, at modelalgoritmerne er skabt ved hjælp af maskinlæringsværktøjer og -metoder. Derfor opstod ideen naturligt om at anvende og tilpasse allerede kendte tilgange til softwareudvikling til maskinlæringsmodeller. Således kan der skelnes mellem følgende nøglestadier i maskinlæringsmodellers livscyklus:

• definere en forretningsidé;
• model uddannelse;
• test og implementering af modellen i forretningsprocessen;
• drift af modellen.

Når der under drift er behov for at ændre eller genoptræne modellen på nye data, starter cyklussen igen - modellen forfines, testes, og en ny version implementeres.

Trække sig tilbage. Hvorfor omskole og ikke omskole? Udtrykket "model genoptræning" har en dobbelt betydning: blandt eksperter betyder det en modeldefekt, når modellen forudsiger godt, faktisk gentager den forudsagte parameter på træningssættet, men klarer sig meget dårligere på den eksterne dataprøve. Naturligvis er en sådan model en defekt, da denne defekt ikke tillader dens brug.

I denne livscyklus virker det logisk at bruge DevOps-værktøjer: automatiseret test, implementering og overvågning, design af modelberegninger i form af separate mikrotjenester. Men der er også en række funktioner, der forhindrer direkte brug af disse værktøjer uden yderligere ML-binding.

Sådan får du modeller til at fungere og være rentable

Som et eksempel, hvor vi vil demonstrere brugen af ​​MLOps-tilgangen, vil vi tage den klassiske opgave at robotisere en chatunderstøttelse til et bank- (eller et hvilket som helst andet) produkt. Typisk ser en forretningsproces for chatsupport sådan ud: en klient indtaster en besked med et spørgsmål i en chat og modtager et svar fra en specialist i et foruddefineret dialogtræ. Opgaven med at automatisere en sådan chat løses normalt ved hjælp af ekspertdefinerede regelsæt, som er meget arbejdskrævende at udvikle og vedligeholde. Effektiviteten af ​​en sådan automatisering, afhængigt af opgavens kompleksitetsniveau, kan være 20-30%. Naturligvis opstår ideen om, at det er mere rentabelt at implementere et kunstig intelligens-modul - en model udviklet ved hjælp af maskinlæring, som:

• er i stand til at behandle et større antal anmodninger uden operatørdeltagelse (afhængigt af emnet kan effektiviteten i nogle tilfælde nå op på 70-80%);
• tilpasser sig bedre til ikke-standardiserede formuleringer i dialog - er i stand til at bestemme hensigten, brugerens reelle ønske baseret på en ikke klart formuleret anmodning;
• ved, hvordan man bestemmer, hvornår modellens svar er tilstrækkeligt, og når der er tvivl om "bevidstheden" om dette svar, og du skal stille et yderligere opklarende spørgsmål eller skifte til operatøren;
• kan desuden trænes automatisk (i stedet for at en gruppe udviklere konstant tilpasser og korrigerer svarscripts, trænes modellen desuden af ​​en Data Science-specialist ved hjælp af de passende maskinlæringsbiblioteker). 

Hvordan får man sådan en avanceret model til at fungere? 

Som med at løse ethvert andet problem, før udvikling af et sådant modul, er det nødvendigt at definere en forretningsproces og formelt beskrive den specifikke opgave, som vi vil løse ved hjælp af maskinlæringsmetoden. På dette tidspunkt begynder operationaliseringsprocessen, betegnet med akronymet Ops. 

Næste skridt er, at Data Scientisten i samarbejde med Dataingeniøren kontrollerer tilgængeligheden og tilstrækkeligheden af ​​data og forretningshypotesen om forretningsideens levedygtighed, udvikler en prototypemodel og tester dens faktiske effektivitet. Først efter bekræftelse fra virksomheden kan overgangen fra at udvikle en model til at integrere den i systemer, der udfører en bestemt forretningsproces, begynde. End-to-end implementeringsplanlægning, en dyb forståelse på hvert trin af, hvordan modellen vil blive brugt, og hvilken økonomisk effekt den vil medføre, er et grundlæggende punkt i processerne med at introducere MLOps-tilgange i virksomhedens teknologiske landskab.

Med udviklingen af ​​AI-teknologier stiger antallet og mangfoldigheden af ​​problemer, der kan løses ved hjælp af maskinlæring, eksponentielt. Hver sådan forretningsproces er en besparelse for virksomheden på grund af automatiseringen af ​​medarbejdernes arbejde i massestillinger (callcenter, kontrol og sortering af dokumenter osv.), Det er en udvidelse af kundebasen ved at tilføje nye attraktive og bekvemme funktioner , det er at spare penge på grund af optimal deres brug og omfordeling af ressourcer og meget mere. I sidste ende er enhver proces fokuseret på at skabe værdi og skal som følge heraf have en vis økonomisk effekt. Her er det meget vigtigt at formulere forretningsideen tydeligt og beregne det forventede overskud ved at implementere modellen i virksomhedens samlede værdiskabelsesstruktur. Der er situationer, hvor implementering af en model ikke retfærdiggør sig selv, og den tid, der bruges af maskinlæringsspecialister, er meget dyrere end arbejdspladsen for operatøren, der udfører denne opgave. Derfor er det nødvendigt at forsøge at identificere sådanne tilfælde i de tidlige stadier af oprettelse af AI-systemer.

Følgelig begynder modeller først at generere overskud, når forretningsproblemet er blevet korrekt formuleret i MLOps-processen, prioriteringer er fastsat, og processen med at introducere modellen i systemet er blevet formuleret i de tidlige udviklingsstadier.

Ny proces – nye udfordringer

Et omfattende svar på det grundlæggende forretningsspørgsmål om, hvordan anvendelige ML-modeller er til at løse problemer, det generelle spørgsmål om tillid til AI er en af ​​de vigtigste udfordringer i processen med at udvikle og implementere MLOps-tilgange. I første omgang er virksomheder skeptiske over for indførelsen af ​​maskinlæring i processer - det er svært at stole på modeller på steder, hvor folk tidligere som regel arbejdede. For erhvervslivet ser programmer ud til at være en "sort boks", hvis relevans stadig mangler at blive bevist. Derudover er der i bankvirksomhed, i teleoperatørers og andres forretninger strenge krav fra offentlige tilsynsmyndigheder. Alle systemer og algoritmer, der er implementeret i bankprocesser, er underlagt revision. For at løse dette problem, for at bevise over for virksomheder og regulatorer gyldigheden og rigtigheden af ​​kunstig intelligens-svar, introduceres overvågningsværktøjer sammen med modellen. Derudover er der en uafhængig valideringsprocedure, obligatorisk for reguleringsmodeller, som opfylder kravene fra centralbanken. En uafhængig ekspertgruppe reviderer resultaterne opnået af modellen under hensyntagen til inputdata.

Den anden udfordring er at vurdere og tage højde for modelrisici ved implementering af en machine learning-model. Selvom en person ikke kan besvare spørgsmålet med hundrede procent sikkerhed, om den samme kjole var hvid eller blå, så har kunstig intelligens også ret til at begå en fejl. Det er også værd at overveje, at data kan ændre sig over tid, og modeller skal omskoles for at producere et tilstrækkeligt præcist resultat. For at sikre, at forretningsprocessen ikke lider, er det nødvendigt at styre modelrisici og overvåge modellens ydeevne og regelmæssigt genoptræne den på nye data.

Men efter den første fase af mistillid begynder den modsatte effekt at vise sig. Jo flere modeller, der med succes implementeres i processer, jo mere vokser virksomhedens appetit på brugen af ​​kunstig intelligens - nye og nye problemer bliver fundet, som kan løses ved hjælp af maskinlæringsmetoder. Hver opgave udløser en hel proces, der kræver visse kompetencer:

• dataingeniører forbereder og behandler data;
• datavidenskabsmænd bruger maskinlæringsværktøjer og udvikler en model;
• IT implementerer modellen i systemet;
• ML-ingeniøren bestemmer, hvordan denne model skal integreres korrekt i processen, hvilke IT-værktøjer der skal bruges, afhængigt af kravene til modellens anvendelsesmåde, under hensyntagen til strømmen af ​​anmodninger, responstid mv. 
• En ML-arkitekt designer, hvordan et softwareprodukt fysisk kan implementeres i et industrielt system.

Hele cyklussen kræver et stort antal højt kvalificerede specialister. På et vist tidspunkt i udviklingen og graden af ​​penetration af ML-modeller i forretningsprocesser viser det sig, at lineær skalering af antallet af specialister i forhold til stigningen i antallet af opgaver bliver dyrt og ineffektivt. Derfor opstår spørgsmålet om at automatisere MLOps-processen - definere flere standardklasser af maskinlæringsproblemer, udvikle standarddatabehandlingspipelines og yderligere træning af modeller. I et idealbillede kræver løsning af sådanne problemer fagfolk, der er lige så dygtige til kompetencer i krydsfeltet mellem Big Data, Data Science, DevOps og IT. Derfor er det største problem i Data Science-industrien og den største udfordring i at organisere MLOps-processer manglen på en sådan kompetence på det eksisterende træningsmarked. Specialister, der opfylder disse krav, er i øjeblikket sjældne på arbejdsmarkedet og er guld værd.

Om spørgsmålet om kompetencer

I teorien kan alle MLOps-opgaver løses ved hjælp af klassiske DevOps-værktøjer og uden at ty til en specialiseret udvidelse af rollemodellen. Så, som vi bemærkede ovenfor, skal en dataforsker ikke kun være en matematiker og dataanalytiker, men også en guru af hele pipelinen - han er ansvarlig for at udvikle arkitekturen, programmere modeller på flere sprog afhængigt af arkitekturen, forberede en datamart og implementer selve applikationen. Men at skabe den teknologiske ramme implementeret i end-to-end MLOps-processen tager op til 80 % af arbejdsomkostningerne, hvilket betyder, at en kvalificeret matematiker, som er en kvalitetsdataforsker, kun vil afsætte 20 % af sin tid til sit speciale . Derfor bliver det afgørende at afgrænse rollerne for specialister involveret i processen med at implementere maskinlæringsmodeller. 

Hvor detaljeret rollerne skal afgrænses afhænger af virksomhedens størrelse. Det er én ting, når en startup har én specialist, en hård arbejder i energireserven, som er sin egen ingeniør, arkitekt og DevOps. Det er en helt anden sag, når alle modeludviklingsprocesser i en stor virksomhed er koncentreret om nogle få højtstående Data Science-specialister, mens en programmør eller databasespecialist - en mere almindelig og billigere kompetence på arbejdsmarkedet - kan tage på det meste af arbejdet rutineopgaver.

Hastigheden og kvaliteten af ​​de udviklede modeller, holdets produktivitet og mikroklimaet i det afhænger således direkte af, hvor grænsen går i udvælgelsen af ​​specialister til at understøtte MLOps-processen, og hvordan processen med operationalisering af de udviklede modeller er organiseret. .

Hvad vores team allerede har gjort

Vi er for nylig begyndt at opbygge en kompetencestruktur og MLOps-processer. Men vores projekter om modellivscyklusstyring og om at bruge modeller som en service er allerede i MVP-teststadiet.

Vi fastlagde også den optimale kompetencestruktur for en stor virksomhed og den organisatoriske struktur for interaktion mellem alle deltagere i processen. Agile teams blev organiseret for at løse problemer for hele rækken af ​​erhvervskunder, og en proces med interaktion med projektteams for at skabe platforme og infrastruktur, som er fundamentet for MLOps-bygningen under opførelse, blev etableret.

Spørgsmål til fremtiden

MLOps er et område i vækst, der oplever mangel på kompetencer og vil tage fart i fremtiden. I mellemtiden er det bedst at bygge videre på DevOps-udviklinger og -praksis. Hovedmålet med MLOps er at bruge ML-modeller mere effektivt til at løse forretningsproblemer. Men dette rejser mange spørgsmål:

• Hvordan kan man reducere tiden til at lancere modeller i produktion?
• Hvordan reducerer man bureaukratisk gnidning mellem teams med forskellige kompetencer og øger fokus på samarbejde?
• Hvordan sporer man modeller, administrerer versioner og organiserer effektiv overvågning?
• Hvordan skaber man en virkelig cirkulær livscyklus for en moderne ML-model?
• Hvordan standardiseres maskinlæringsprocessen?

Svarene på disse spørgsmål vil i vid udstrækning afgøre, hvor hurtigt MLOps vil nå sit fulde potentiale.

Kilde: www.habr.com