I 2018 dukket konseptet MLOps opp i fagmiljøer og på temakonferanser dedikert til AI, som raskt tok tak i bransjen og nå utvikler seg som en uavhengig retning. I fremtiden kan MLOps bli et av de mest populære områdene innen IT. Hva er det og hva spises det med? La oss finne ut nedenfor.
Hva er MLOps
MLOps (som kombinerer maskinlæringsteknologier og prosesser og tilnærminger for å implementere utviklede modeller i forretningsprosesser) er en ny måte for samarbeid mellom bedriftsrepresentanter, forskere, matematikere, maskinlæringsspesialister og IT-ingeniører når de lager kunstig intelligens-systemer.
Med andre ord er det en måte å gjøre maskinlæringsmetoder og teknologier til et nyttig verktøy for å løse forretningsproblemer.
Det er nødvendig å forstå at produktivitetskjeden begynner lenge før utviklingen av modellen. Det første trinnet er å definere et forretningsproblem, en hypotese om verdien som kan trekkes ut fra dataene, og en forretningsidé for å anvende den.
Selve konseptet MLOps oppsto som en analogi til konseptet DevOps i forhold til maskinlæringsmodeller og -teknologier. DevOps er en tilnærming til programvareutvikling som lar deg øke hastigheten på implementeringen av individuelle endringer samtidig som du opprettholder fleksibilitet og pålitelighet ved hjelp av en rekke tilnærminger, inkludert kontinuerlig utvikling, oppdeling av funksjoner i en rekke uavhengige mikrotjenester, automatisert testing og distribusjon av individuelle endringer, global helseovervåking, hurtigresponssystem for oppdagede feil, etc.
DevOps har definert programvarens livssyklus, og fellesskapet har kommet opp med ideen om å bruke samme metodikk på big data. DataOps er et forsøk på å tilpasse og utvide metodikken ved å ta hensyn til funksjonene ved lagring, overføring og behandling av store datamengder i ulike og interoperable plattformer.
Med ankomsten av en viss kritisk masse av maskinlæringsmodeller implementert i forretningsprosessene til bedrifter, ble det lagt merke til en sterk likhet mellom livssyklusen til matematiske maskinlæringsmodeller og programvarens livssyklus. Den eneste forskjellen er at modellalgoritmene er laget ved hjelp av maskinlæringsverktøy og metoder. Derfor oppsto ideen naturlig om å anvende og tilpasse allerede kjente tilnærminger til programvareutvikling for maskinlæringsmodeller. Følgende nøkkelstadier kan derfor skilles i livssyklusen til maskinlæringsmodeller:
- definere en forretningsidé;
- modell trening;
- testing og implementering av modellen i forretningsprosessen;
- drift av modellen.
Når det under drift er behov for å endre eller omskolere modellen på nye data, starter syklusen igjen - modellen foredles, testes og en ny versjon distribueres.
Retrett. Hvorfor omskolere seg og ikke omskolere seg? Begrepet "modellomopplæring" har en dobbel betydning: blant eksperter betyr det en modellfeil, når modellen forutsier godt, faktisk gjentar den forutsagte parameteren på treningssettet, men presterer mye dårligere på det eksterne datautvalget. Naturligvis er en slik modell en defekt, siden denne defekten ikke tillater bruk.
I denne livssyklusen virker det logisk å bruke DevOps-verktøy: automatisert testing, distribusjon og overvåking, design av modellberegninger i form av separate mikrotjenester. Men det er også en rekke funksjoner som forhindrer direkte bruk av disse verktøyene uten ekstra ML-binding.
Hvordan få modeller til å fungere og være lønnsomme
Som et eksempel der vi skal demonstrere bruken av MLOps-tilnærmingen, vil vi ta den klassiske oppgaven med å robotisere en chat-støtte for et bank- (eller et hvilket som helst annet) produkt. Vanligvis ser en forretningsprosess for chatstøtte slik ut: en klient skriver inn en melding med et spørsmål i en chat og mottar et svar fra en spesialist i et forhåndsdefinert dialogtre. Oppgaven med å automatisere en slik chat løses vanligvis ved hjelp av ekspertdefinerte regelsett, som er svært arbeidskrevende å utvikle og vedlikeholde. Effektiviteten til slik automatisering, avhengig av kompleksitetsnivået til oppgaven, kan være 20–30%. Naturligvis oppstår ideen om at det er mer lønnsomt å implementere en kunstig intelligens-modul - en modell utviklet ved hjelp av maskinlæring, som:
- er i stand til å behandle et større antall forespørsler uten operatørdeltakelse (avhengig av emnet, i noen tilfeller kan effektiviteten nå 70–80%);
- tilpasser seg bedre til ikke-standard formulering i dialog - er i stand til å bestemme intensjonen, det virkelige ønsket til brukeren basert på en ikke klart formulert forespørsel;
- vet hvordan du bestemmer når modellens svar er tilstrekkelig, og når det er tvil om "bevisstheten" om dette svaret, og du må stille et ekstra oppklarende spørsmål eller bytte til operatøren;
- kan i tillegg trenes automatisk (i stedet for at en gruppe utviklere stadig tilpasser og korrigerer svarskript, trenes modellen i tillegg av en Data Science-spesialist som bruker de riktige maskinlæringsbibliotekene).
Hvordan få en så avansert modell til å fungere?
Som med å løse ethvert annet problem, før du utvikler en slik modul, er det nødvendig å definere en forretningsprosess og formelt beskrive den spesifikke oppgaven vi skal løse ved hjelp av maskinlæringsmetoden. På dette tidspunktet begynner operasjonaliseringsprosessen, utpekt av akronymet Ops.
Neste steg er at dataforskeren i samarbeid med dataingeniøren sjekker tilgjengeligheten og tilstrekkeligheten av data og forretningshypotesen om forretningsideens levedyktighet, utvikler en prototypemodell og tester dens faktiske effektivitet. Først etter bekreftelse fra virksomheten kan overgangen fra å utvikle en modell til å integrere den i systemer som utfører en bestemt forretningsprosess begynne. End-to-end implementeringsplanlegging, en dyp forståelse på hvert trinn av hvordan modellen skal brukes og hvilken økonomisk effekt den vil gi, er et grunnleggende poeng i prosessene med å introdusere MLOps-tilnærminger i selskapets teknologiske landskap.
Med utviklingen av AI-teknologier øker antallet og variasjonen av problemer som kan løses ved hjelp av maskinlæring eksponentielt. Hver slik forretningsprosess er en besparelse for selskapet på grunn av automatisering av arbeidskraften til masseansatte (telefonsenter, sjekking og sortering av dokumenter, etc.), det er en utvidelse av kundebasen ved å legge til nye attraktive og praktiske funksjoner, det sparer penger på grunn av optimal bruk og omfordeling av ressurser og mye mer. Til syvende og sist er enhver prosess fokusert på å skape verdi og må som et resultat gi en viss økonomisk effekt. Her er det svært viktig å formulere forretningsideen tydelig og beregne forventet fortjeneste ved å implementere modellen i den samlede verdiskapingsstrukturen til bedriften. Det er situasjoner når implementering av en modell ikke rettferdiggjør seg selv, og tiden brukt av maskinlæringsspesialister er mye dyrere enn arbeidsplassen til operatøren som utfører denne oppgaven. Det er derfor det er nødvendig å prøve å identifisere slike tilfeller i de tidlige stadiene av å lage AI-systemer.
Følgelig begynner modeller å generere profitt først når forretningsproblemet er riktig formulert i MLOps-prosessen, prioriteringer er satt, og prosessen med å introdusere modellen i systemet er formulert i de tidlige utviklingsstadiene.
Ny prosess – nye utfordringer
Et omfattende svar på det grunnleggende forretningsspørsmålet om hvor anvendelige ML-modeller er for å løse problemer, det generelle spørsmålet om tillit til AI er en av hovedutfordringene i prosessen med å utvikle og implementere MLOps-tilnærminger. I utgangspunktet er bedrifter skeptiske til introduksjonen av maskinlæring i prosesser - det er vanskelig å stole på modeller på steder hvor folk tidligere som regel jobbet. For bedrifter ser programmer ut til å være en "svart boks", hvis relevans fortsatt må bevises. I tillegg, i bankvirksomhet, i virksomheten til teleoperatører og andre, er det strenge krav fra offentlige regulatorer. Alle systemer og algoritmer som er implementert i bankprosesser er gjenstand for revisjon. For å løse dette problemet, for å bevise for næringslivet og regulatorer gyldigheten og riktigheten av responser med kunstig intelligens, introduseres overvåkingsverktøy sammen med modellen. I tillegg er det en uavhengig valideringsprosedyre, obligatorisk for regulatoriske modeller, som oppfyller kravene til sentralbanken. En uavhengig ekspertgruppe reviderer resultatene oppnådd av modellen og tar hensyn til inputdata.
Den andre utfordringen er å vurdere og ta hensyn til modellrisiko ved implementering av en maskinlæringsmodell. Selv om en person ikke kan svare på spørsmålet med hundre prosent sikkerhet om den samme kjolen var hvit eller blå, så har kunstig intelligens også rett til å gjøre en feil. Det er også verdt å tenke på at data kan endre seg over tid, og modeller må omskoleres for å gi et tilstrekkelig nøyaktig resultat. For å sikre at forretningsprosessen ikke lider, er det nødvendig å håndtere modellrisiko og overvåke ytelsen til modellen, regelmessig omskolere den på nye data.
Men etter den første fasen av mistillit, begynner den motsatte effekten å vises. Jo flere modeller som er vellykket implementert i prosesser, jo mer vokser bedriftens appetitt for bruk av kunstig intelligens - nye og nye problemer blir funnet som kan løses ved hjelp av maskinlæringsmetoder. Hver oppgave utløser en hel prosess som krever visse kompetanser:
- dataingeniører forbereder og behandler data;
- dataforskere bruker maskinlæringsverktøy og utvikler en modell;
- IT implementerer modellen i systemet;
- ML-ingeniøren bestemmer hvordan denne modellen skal integreres korrekt i prosessen, hvilke IT-verktøy som skal brukes, avhengig av kravene til modellens bruksmåte, under hensyntagen til flyten av forespørsler, responstid osv.
- En ML-arkitekt designer hvordan et programvareprodukt kan implementeres fysisk i et industrielt system.
Hele syklusen krever et stort antall høyt kvalifiserte spesialister. På et visst tidspunkt i utviklingen og graden av penetrering av ML-modeller i forretningsprosesser, viser det seg at lineær skalering av antall spesialister i forhold til økningen i antall oppgaver blir dyrt og ineffektivt. Derfor oppstår spørsmålet om å automatisere MLOps-prosessen - definere flere standardklasser av maskinlæringsproblemer, utvikle standard databehandlingsrørledninger og tilleggstrening av modeller. I et idealbilde krever løsning av slike problemer fagfolk som er like dyktige på kompetanse i skjæringspunktet mellom Big Data, Data Science, DevOps og IT. Derfor er det største problemet i Data Science-bransjen og den største utfordringen med å organisere MLOps-prosesser mangelen på slik kompetanse i det eksisterende opplæringsmarkedet. Spesialister som oppfyller disse kravene er i dag sjeldne på arbeidsmarkedet og er gull verdt.
På spørsmålet om kompetanse
I teorien kan alle MLOps-oppgaver løses ved hjelp av klassiske DevOps-verktøy og uten å ty til en spesialisert utvidelse av rollemodellen. Så, som vi bemerket ovenfor, må en dataforsker ikke bare være en matematiker og dataanalytiker, men også en guru for hele rørledningen - han er ansvarlig for å utvikle arkitekturen, programmere modeller på flere språk avhengig av arkitekturen, forberede en datamart og distribuere selve applikasjonen. Å lage det teknologiske rammeverket implementert i ende-til-ende MLOps-prosessen tar imidlertid opptil 80 % av lønnskostnadene, noe som betyr at en kvalifisert matematiker, som er en kvalitetsdataforsker, bare vil vie 20 % av tiden sin til spesialiteten sin. . Derfor blir det viktig å avgrense rollene til spesialister som er involvert i prosessen med å implementere maskinlæringsmodeller.
Hvor detaljert rollene skal avgrenses avhenger av størrelsen på virksomheten. Det er én ting når en startup har én spesialist, en hard arbeider i energireserven, som er hans egen ingeniør, arkitekt og DevOps. Det er en helt annen sak når alle modellutviklingsprosesser i en stor bedrift er konsentrert om noen få datavitenskapsspesialister på høyt nivå, mens en programmerer eller databasespesialist – en mer vanlig og rimeligere kompetanse i arbeidsmarkedet – kan ta på det meste av arbeidet rutineoppgaver.
Dermed avhenger hastigheten og kvaliteten på de utviklede modellene, produktiviteten til teamet og mikroklimaet i det direkte av hvor grensen går i valg av spesialister for å støtte MLOps-prosessen og hvordan prosessen med operasjonalisering av de utviklede modellene er organisert. .
Hva teamet vårt allerede har gjort
Vi begynte nylig å bygge en kompetansestruktur og MLOps-prosesser. Men våre prosjekter om modelllivssyklusstyring og bruk av modeller som en tjeneste er allerede i MVP-teststadiet.
Vi bestemte også den optimale kompetansestrukturen for en stor bedrift og den organisatoriske strukturen for samhandling mellom alle deltakerne i prosessen. Det ble organisert smidige team for å løse problemer for hele spekteret av bedriftskunder, og en prosess med samhandling med prosjektteam for å skape plattformer og infrastruktur, som er grunnlaget for MLOps-bygget under oppføring, ble etablert.
Spørsmål for fremtiden
MLOps er et voksende område som opplever mangel på kompetanse og vil få fart i fremtiden. I mellomtiden er det best å bygge på DevOps-utvikling og -praksis. Hovedmålet med MLOps er å mer effektivt bruke ML-modeller for å løse forretningsproblemer. Men dette reiser mange spørsmål:
- Hvordan redusere tiden for å lansere modeller i produksjon?
- Hvordan redusere byråkratisk friksjon mellom team med ulik kompetanse og øke fokuset på samarbeid?
- Hvordan spore modeller, administrere versjoner og organisere effektiv overvåking?
- Hvordan lage en virkelig sirkulær livssyklus for en moderne ML-modell?
- Hvordan standardisere maskinlæringsprosessen?
Svarene på disse spørsmålene vil i stor grad avgjøre hvor raskt MLOps vil nå sitt fulle potensial.
Kilde: www.habr.com