Machine learning (ML) er blevet en af de mest kritiske muligheder for moderne virksomheder til at vokse og forblive konkurrencedygtige i dag. Fra automatisering af interne processer til optimering af design-, skabelses- og markedsføringsprocesserne bag stort set alle produkter, der forbruges, har ML-modeller gennemsyret næsten alle aspekter af vores arbejde og privatliv - og for virksomheder har indsatsen aldrig været højere. At undlade at adoptere ML som en kernekompetence vil resultere i store konkurrencemæssige ulemper, som vil definere de næste markedsledere.
På grund af dette skal forretnings- og teknologiledere implementere ML-modeller på tværs af hele deres organisation, der spænder over et stort spektrum af use cases. Imidlertid skaber denne følelse af uopsættelighed, kombineret med voksende regulatorisk kontrol, nye og unikke styringsudfordringer, som i øjeblikket er svære at håndtere. For eksempel:Hvordan påvirker mine modeller tjenester, der leveres til slutkunder? Er jeg stadig i overensstemmelse med både statslige og interne regler? Hvordan vil mine sikkerhedsregler omsættes til modeller i produktion?
Ud over regulatoriske eller juridiske bekymringer er der en række grunde til at have styringsprocesser og -procedurer for Machine Learning. Eksempler omfatter måder til at øge produktiviteten (såsom genbrug af aktiver som modeller og funktioner), kontrol og vedligeholdelse af modeller på tværs af mange forskellige forretningsområder for at sikre, at forretningskritiske applikationer gør, hvad de er beregnet til (eller finde dem, der ikke er det) , og se en historie med modeller og forudsigelser, herunder forældede aktiver.
For at tackle disse udfordringer er det værd at definere, hvilke modeller og funktioner der er konceptuelt (se figur 1). Der findes mange forskellige definitioner, men generelt er en model enhver selvstændig pakke, der tager funktioner beregnet ud fra inputdata og producerer en forudsigelse (eller score) og metadata. Denne pakke kan antage mange former, men inkluderer altid en matematisk repræsentation, kode, forretningslogik og træningsdata. Modellens forudsigelser forbruges downstream af systemer eller brugere.
Mange virksomheder driver ML-modelinfrastruktur i forskellige størrelser og modenheder, så de har brug for værktøjer til at hjælpe dem med at styre deres modeller. I sidste ende kan behov for ML-styring destilleres til følgende nøgleområder:synlighed; og modelforklarlighed, fortolkbarhed og reproducerbarhed.
Figur 1
Synlighed af modeller og funktioner i teams og på tværs af organisationer
Et grundlæggende krav til modelstyring er at gøre det muligt for teams at forstå, hvordan maskinlæring anvendes i deres organisationer. Dette kræver et kanonisk katalog over modeller og funktioner. I mangel af et sådant katalog er mange organisationer uvidende om deres modeller og funktioner, hvor de er implementeret, hvad de laver osv. Dette fører til omarbejdning, modelinkonsistens, genberegningsfunktioner og andre ineffektiviteter.
Modelforklarlighed, fortolkbarhed og reproducerbarhed
Modeller ses ofte som en sort boks:data går ind, noget sker, og en forudsigelse kommer ud. Denne manglende gennemsigtighed er udfordrende på en række niveauer og er ofte repræsenteret i løst beslægtede termer såsom:
- Forklarlighed :beskrivelse af den interne mekanik i en ML-model i menneskelige termer
- Fortolkning :evnen til at a) forstå forholdet mellem modelinput, funktioner og output, og b) at forudsige responsen på ændringer i input.
- Reproducerbarhed :evnen til at gengive output fra en model på en ensartet måde for de samme input.
Alle disse kræver fælles funktionalitet, herunder en tilknytning til kildedata, en klar forståelse af modellernes interne elementer som kode og træningsdata og andre metoder til selv at undersøge og analysere modeller.
Modelmetadata med et eksempel
For at løse de styringsproblemer, der er defineret ovenfor, lad os starte med at tænke på et eksempel. Overvej en hjemmeside for levering af mad. Virksomheden ønsker at udnytte maskinlæring til at estimere leveringstid.
Træningsdatasættet består af hændelsesloggene fra tidligere leverancer, som indeholder leveringstiderne for hver tidligere leveret leverance. Disse data bruges til at træne en model til at estimere fremtidige leveringstider.
En hændelseslog kunne se sådan ud:
Der blev afgivet en ordre kl. 10.00 for, at mad skulle hentes fra loc1 og leveres til loc2. Kureren hentede den fra restauranten kl. 10.15 og leverede den kl. 10.55, hvilket tog i alt 55 minutter fra afgivelse af ordre til levering
Antag loc1 og loc2 er gadeadresser. Dette er forkortet her for at gøre det kort og let at læse.
Hændelsesloggene gemmes i HBase. Den tekniske arkitektur for modeludviklingen er som følger:
- Datateknikere identificerer tidsvinduet for hændelseslogfiler, der skal bruges til at løse problemet. En ny struktureret Hive-tabel oprettes ved at parse de rå hændelseslogfiler med det identificerede tidsvindue.
- Funktionsingeniører (dette kan være en rolle inden for datavidenskabsmænd eller ML-ingeniører) identificerer og udvikler nye funktioner:
- Myldretidsfunktion:En funktion til at identificere, om myldretidsforholdene eksisterer givet et sted og et tidspunkt.
- Restaurant "Travlhed"-funktion:En funktion til at identificere, om en given restaurant oplever høje ventetider baseret på historiske data. Disse historiske data er indsamlet separat.
- Ovenstående identificerede funktioner er derefter bygget som et python-bibliotek til genbrug.
- Dette bibliotek bruges til at anvende funktionen på den strukturerede Hive-tabel for at skabe en ny tabel, som vil være det endelige træningsdatasæt. En række i den nye tabel ser sådan ud:
Antag loc1 og loc2 er gadeadresser. Dette er forkortet her for at gøre det kort og let at læse.
- Dataforskere kører en lineær regression på træningsdatasættet for at forudsige tidspunktet for levering. På dette tidspunkt skal de bruge det samme funktionsbibliotek, som blev brugt til at udtrække funktionerne i træningsdatasættet.
- Modellen er implementeret som et Function-as-a-Service (FaaS) slutpunkt, der bruges af webapplikationen til at forudsige leveringstidspunkt.
Bemærk, at modellen skal beregne funktionerne til forudsigelse i realtid. Disse funktioner er biblioteker, der bruges internt af modellen. En visualisering af de forskellige udførte aktiviteter og artefakter genereret i dette eksempel kan se sådan ud:
De blå felter repræsenterer ML-entiteter (navneord), såsom en kode, projekt, builds, implementeringer osv. De grønne felter repræsenterer processer (verber), som virker på entiteter og producerer andre entiteter.
Visualiseringen og relationerne, der definerer transformationerne af strukturen af data, betegnes samlet som slægt . I databaseverdenen vil tilføjelse af en ny kolonne til en tabel ændre dens afstamning. I maskinlæringsverdenen vil genoptræning af en model ved at forbruge funktioner og datasæt ændre afstamningen. Til madleveringswebstedet, for at besvare spørgsmålet:"er der en forskel mellem funktionsudtrækningen under træning vs. scoring", har vi brug for afstamningsoplysningerne. Dette er blot et eksempel på nytten af lineage-metadata i maskinlæringsverdenen.
Apache Atlas som et styringsværktøj
Det er tydeligt, at opbygning af en komplet ende-til-ende-linje for ML-arbejdsgange – fra træningsdatasæt til modelimplementeringer – bliver et nøglekrav for at løse de identificerede styringsproblemer. Integrationen af datastyring og maskinlæring skal muliggøre forklaring, fortolkning og reproducerbarhed.
Indsamling, lagring og visualisering af ML-metadata kræver et standard backend-softwaresystem. En åben og udvidelig metadatadefinition vil muliggøre standardisering af styringsoperationer, uanset hvor modellerne udvikles eller betjenes. Den oplagte kandidat til Cloudera (og vores kunder) er Apache Atlas.
Apache Atlas er allerede et sæt udbredte styringsværktøjer med foruddefinerede metadatatyper til datastyring. I forbindelse med ML governance er det velegnet til at definere og indfange de metadata, der kræves til maskinlæringskoncepter. Derudover giver Apache Atlas avancerede funktioner såsom klassifikationer, integration med Apache Ranger (til autorisation og tagging) for at nævne nogle få, og har et udvideligt tilføjelsessystem, som gør det muligt for fællesskabet at samarbejde omkring og trinvist definere integrationer til forskellige andre værktøjer i ML. plads. Det er efterladt som en øvelse for læseren at udforske Apache Atlas' UI og se, hvordan man bruger disse muligheder.
ML Metadata Definition i Apache Atlas
Apache Atlas Type System passer til alle vores behov for at definere ML Metadata-objekter. Det er open source, kan udvides og har forudbyggede styringsfunktioner. En Type i Atlas er en definition af, hvordan en bestemt type metadataobjekt lagres og tilgås. Det repræsenterer også en eller flere attributter, der definerer egenskaberne for metadataobjektet. Til ML-styring kan Atlas Type System bruges til at definere nye typer, der fanger ML-enheder og processer som Atlas-metadataobjekter. Ud over definitionen af typerne er forholdet mellem enhederne og processerne også påkrævet for at visualisere ende-til-ende afstamningsflowet.
Hvis vi relaterer dette til det tidligere beskrevne websted for fødevarelevering, giver Atlas Type System et godt grundlag for at definere Machine Learning-afstamningen. Et generaliseret ML-afstamningssystem visualiseres som følger:
Som det fremgår af diagrammet ovenfor, følger Metadata-definitionen for maskinlæring tæt den faktiske maskinlærings-workflow. Træningsdatasæt er udgangspunktet for et modelafstamningsflow. Disse datasæt kan være tabeller fra et datavarehus eller en indlejret csv-fil. Når et datasæt er blevet identificeret, følger afstamningen med i træning, opbygning og implementering af modellen.
ML funktionsudvikling er en parallel og specialiseret aktivitet, der kan betegnes som feature engineering (forskellig fra model engineering). I dag udføres de to aktiviteter (modelteknik og feature engineering) i mange tilfælde af den samme person eller team. Med demokratisering og industrialisering af funktioner kan dette ændre sig i fremtiden, med specialiserede teams til modeludvikling og funktionsudvikling.
ML-typesystemet kan nu defineres gennem følgende nye typer:
"Create Machine Learning Project" og "Machine Learning Project"
Et enkelt Machine Learning-projekt repræsenterer en enkelt business use case. Machine Learning Project repræsenterer beholderen med filer og andre indlejrede aktiver. Projektets metadata indeholder som minimum:
- Liste over filer brugt i modellen
- Historisk version af alle filer
- Den enkleste implementering ville være at vedligeholde projektet som et git-lager, der er afhængigt af Git til at vedligeholde historikken for alle filer.
"Træningsdatasæt"
En undertype af et datasæt i Atlas, som repræsenterer et træningsdatasæt. Træningsdatasæt-enheden bruges i modeltræningsprocessen. Det kan associeres med en funktion, hvis de genererede data er resultatet af at anvende funktionsudtræk (eller transformation) til et andet datasæt.
"Træn og byg"
En proces, der repræsenterer handlingen med træning og opbygning af en model. Inkluderer løbende eksperimenter, tuning og færdiggørelse af valget af en træningsalgoritme. Train and Build Process kunne eventuelt være at forbruge output fra en Feature Build; for eksempel en biblioteksfunktion, der definerer udtræk af funktioner, som bruges internt af modellen.
"Modelopbygning"
Modellen hærdes og versioneres, når en dataforsker har afsluttet eksperimentering og træning af modellen. Denne bearbejdning resulterer i en Model Build, som er en uforanderlig artefakt, der danner byggestenen til produktion af modeller. Et Docker-billede er et eksempel på en Model Build-entitet.
"Deploy Model" og "Model Deployment"
En modelopbygning gennemgår en implementeringsproces, som skaber en modelimplementering. Modelimplementeringen repræsenterer en aktiv instansiering af en model. En Kubernetes-baseret REST-tjeneste (FaaS-lignende implementering) er et eksempel på en Model Deployment-entitet.
"Funktionsfunktion"
En maskinlæringsfunktion har to fortolkninger:1) Funktionsfunktion og 2) Transformeret datasæt.
Entiteten Feature Function er en brugerdefineret funktion (udtrykt i kode), der definerer, hvordan en identificeret funktion udtrækkes fra et input. Dette repræsenterer koden for funktioner, svarende til hvordan ML Project repræsenterer containeren for ML-kode.
Funktionsfunktionen pakkes først som et bibliotek (versioneret og hærdet). Biblioteket forbruges derefter og anvendes på et givet datasæt for at transformere det til et nyt datasæt (med funktionerne udtrukket). Det transformerede datasæt er repræsenteret af træningsdatasæt-entiteten defineret ovenfor.
"Pakkefunktion" og "Funktionsbyg"
Koden i Feature Function er pakket til deling (med andre modeller) eller til runtime scoring. Disse pakker kaldes Feature Builds. For eksempel kan en Feature Build indeholde et pakket bibliotek (i python) eller en jar-fil (i Java). Denne pakke kan absorberes under modeltoget og byggeprocessen for at sikre, at den samme funktion bruges under udvinding såvel som forudsigelse.
Prøv og bliv involveret i at definere fremtiden for ML Metadata Definition
Vi har startet arbejdet med ATLAS-3432, som er den første implementering af Machine Learning Type System, der udnytter Cloudera Data Science Workbench (CDSW) som pilotklient. Tak til Na Li fra Cloudera-ingeniørteamet for at lede arbejdet med at opbygge CDSW-integrationen. ATLAS-3432 vil tillade, at modelmetadata fra en CDSW-instans kan skubbes til en Apache Atlas-instans for at udforske afstamning. CDSW understøtter i øjeblikket ikke funktioner (eller en funktionsbutik), og derfor vil slægten relateret til funktioner ikke være tilgængelig.
Hos Cloudera ønsker vi ikke blot at løse dette problem for vores kunder - vi mener, at ML-metadatadefinitioner bør være universelle, ligesom tabeller, kolonner osv. er meget standard for datastrukturer. Vi håber, at fællesskaber vil bidrage til at definere denne standard for at hjælpe virksomheder med at få mest muligt ud af deres ML-platforme.
Har du en use-case for maskinlæringsstyring, som ikke passer ind i metadatamodellen? Deltag i samtalen ved at sende dine forslag til [email protected].