Maskininlärning (ML) har blivit en av de mest kritiska funktionerna för moderna företag att växa och förbli konkurrenskraftiga idag. Från att automatisera interna processer till att optimera design, skapande och marknadsföringsprocesser bakom praktiskt taget varje produkt som konsumeras, ML-modeller har genomsyrat nästan alla aspekter av vårt arbete och personliga liv – och för företag har insatserna aldrig varit högre. Att misslyckas med att anta ML som en kärnkompetens kommer att resultera i stora konkurrensnackdelar som kommer att definiera nästa marknadsledare.
På grund av detta måste företags- och teknikledare implementera ML-modeller i hela sin organisation, som spänner över ett stort spektrum av användningsfall. Men denna känsla av brådska, i kombination med en växande regulatorisk granskning, skapar nya och unika förvaltningsutmaningar som för närvarande är svåra att hantera. Till exempel:Hur påverkar mina modeller tjänster som tillhandahålls till slutkunder? Följer jag fortfarande både statliga och interna bestämmelser? Hur kommer mina säkerhetsregler att översättas till modeller i produktion?
Utöver regulatoriska eller juridiska problem, finns det ett antal skäl att ha styrprocesser och procedurer för maskininlärning. Exempel inkluderar sätt att öka produktiviteten (som att återanvända tillgångar som modeller och funktioner), kontrollera och underhålla modeller över många olika affärsområden för att säkerställa att affärskritiska applikationer gör vad de är avsedda att göra (eller hitta de som inte är det) , och se en historik över modeller och förutsägelser inklusive avskrivna tillgångar.
För att tackla dessa utmaningar är det värt att definiera vilka modeller och funktioner som är konceptuellt (se figur 1). Det finns många olika definitioner, men i allmänhet är en modell ett fristående paket som tar funktioner som beräknas från indata och producerar en förutsägelse (eller poäng) och metadata. Detta paket kan ta många former men innehåller alltid en matematisk representation, kod, affärslogik och utbildningsdata. Modellens förutsägelser konsumeras nedströms av system eller användare.
Många företag driver ML-modellinfrastruktur i olika storlekar och mognad som de behöver verktyg för att hjälpa dem att styra sina modeller. I slutändan kan behov av ML-styrning destilleras in i följande nyckelområden:synlighet; och modellförklarbarhet, tolkningsbarhet och reproducerbarhet.
Figur 1
Synlighet av modeller och funktioner inom team och över organisationer
Ett grundläggande krav för modellstyrning är att göra det möjligt för team att förstå hur maskininlärning tillämpas i deras organisationer. Detta kräver en kanonisk katalog över modeller och funktioner. I avsaknad av en sådan katalog är många organisationer omedvetna om sina modeller och funktioner, var de används, vad de gör, etc. Detta leder till omarbetning, modellinkonsekvens, omräkningsfunktioner och annan ineffektivitet.
Modellförklarbarhet, tolkningsbarhet och reproducerbarhet
Modeller ses ofta som en svart låda:data går in, något händer och en förutsägelse kommer ut. Denna bristande transparens är utmanande på ett antal nivåer och representeras ofta i löst relaterade termer som:
- Förklaring :beskrivning av den interna mekaniken i en ML-modell i mänskliga termer
- Tolkbarhet :förmågan att a) förstå sambandet mellan modellens indata, funktioner och utgångar, och b) att förutsäga responsen på förändringar i indata.
- Reproducerbarhet :förmågan att reproducera utdata från en modell på ett konsekvent sätt för samma indata.
Alla dessa kräver gemensam funktionalitet inklusive en koppling till källdata, en tydlig förståelse av modellernas interna delar som kod och träningsdata och andra metoder för att undersöka och analysera modeller själva.
Modell Metadata med ett exempel
För att ta itu med de styrningsproblem som definierats ovan, låt oss börja med att tänka på ett exempel. Överväg en webbplats för matleverans. Företaget vill utnyttja maskininlärning för att uppskatta tid för leverans.
Träningsdatauppsättningen består av händelseloggarna från tidigare leveranser, som innehåller leveranstiderna för varje tidigare gjord leverans. Dessa data används för att träna en modell för att uppskatta framtida leveranstider.
En händelselogg kan se ut ungefär så här:
En beställning gjordes kl. 10 för mat som skulle hämtas från loc1 och levereras till loc2. Kuriren hämtade den från restaurangen kl. 10.15 och levererade den kl. 10.55, vilket tog totalt 55 minuter från beställning till leverans
Antag att loc1 och loc2 är gatuadresser. Detta förkortas här för att hålla det kort och lätt att läsa.
Händelseloggarna lagras i HBase. Den tekniska arkitekturen för modellutvecklingen är följande:
- Dataingenjörer identifierar tidsfönstret för händelseloggar som ska användas för att lösa problemet. En ny strukturerad Hive-tabell skapas genom att analysera de råa händelseloggarna med det identifierade tidsfönstret.
- Funktionsingenjörer (detta kan vara en roll inom datavetare eller ML-ingenjörer) identifierar och utvecklar nya funktioner:
- Rusningsfunktion:En funktion för att identifiera om rusningsförhållanden råder givet en plats och en tid.
- Restaurangens "upptagen" funktion:En funktion för att identifiera om en viss restaurang upplever höga väntetider baserat på historiska data. Dessa historiska data samlas in separat.
- De ovan identifierade funktionerna byggs sedan som ett pythonbibliotek för återanvändning.
- Det här biblioteket används för att tillämpa funktionen på den strukturerade Hive-tabellen för att skapa en ny tabell som kommer att vara den slutliga träningsdatauppsättningen. En rad i den nya tabellen ser ut så här:
Antag att loc1 och loc2 är gatuadresser. Detta förkortas här för att hålla det kort och lätt att läsa.
- Dataforskare kör en linjär regression på träningsdatasetet för att förutsäga tiden för leverans. Vid det här laget måste de använda samma funktionsbibliotek som användes för att extrahera funktionerna i träningsdatauppsättningen.
- Modellen distribueras som en Function-as-a-Service (FaaS) slutpunkt som används av webbapplikationen för att förutsäga tid för leverans.
Observera att modellen måste beräkna funktionerna för förutsägelse i realtid. Dessa funktioner är bibliotek som används internt av modellen. En visualisering av de olika aktiviteterna som utförs och artefakter som genereras i detta exempel kan se ut så här:
De blå rutorna representerar ML-entiteter (substantiv) såsom en kod, projekt, builds, distributioner, etc. De gröna rutorna representerar processer (verb) som verkar på entiteter och producerar andra entiteter.
Visualiseringen och relationerna som definierar transformationerna av datastrukturen kallas gemensamt för härstamning . I databasvärlden kommer dess härkomst att ändras genom att lägga till en ny kolumn i en tabell. I maskininlärningsvärlden kommer omskolning av en modell genom att konsumera funktioner och datamängder att ändra linjen. För matleveranswebbplatsen, för att svara på frågan:"finns det en skillnad mellan funktionsextraktionen under träning och poängsättning", behöver vi härstamningsinformationen. Detta är bara ett exempel på användbarheten av härstamningsmetadata i maskininlärningsvärlden.
Apache Atlas som ett styrningsverktyg
Det är uppenbart att att bygga en komplett linje för ML-arbetsflöden – från utbildningsdatauppsättningar till modellimplementeringar – blir ett nyckelkrav för att lösa de identifierade styrningsproblemen. Integrationen av datahantering och maskininlärning måste möjliggöra förklaring, tolkning och reproducerbarhet.
Insamling, lagring och visualisering av ML-metadata kräver ett standardsystem för backend-programvara. En öppen och utvidgbar metadatadefinition kommer att möjliggöra standardisering av förvaltningsverksamheten oavsett var modellerna utvecklas eller serveras. Den självklara kandidaten för Cloudera (och våra kunder) är Apache Atlas.
Apache Atlas är redan en uppsättning brett använda styrverktyg med fördefinierade metadatatyper för datahantering. I samband med ML-styrning är den väl lämpad för att definiera och fånga de metadata som krävs för maskininlärningskoncept. Dessutom tillhandahåller Apache Atlas avancerade funktioner som klassificeringar, integration med Apache Ranger (för auktorisering och taggning) för att nämna några, och har ett utbyggbart tilläggssystem som gör att communityn kan samarbeta kring och stegvis definiera integrationer till olika andra verktyg i ML Plats. Det lämnas som en övning för läsaren att utforska Apache Atlas gränssnitt och se hur man använder dessa funktioner.
ML Metadata Definition i Apache Atlas
Apache Atlas Type System passar alla våra behov för att definiera ML Metadata-objekt. Den är öppen källkod, utbyggbar och har förbyggda styrfunktioner. En typ i atlas är en definition av hur en viss typ av metadataobjekt lagras och nås. Det representerar också ett eller flera attribut som definierar egenskaperna för metadataobjektet. För ML-styrning kan Atlas Type System användas för att definiera nya typer, fånga ML-entiteter och processer som Atlas-metadataobjekt. Utöver definitionen av typerna krävs också relationen mellan enheterna och processerna för att visualisera flödet av linjen från ände till ände.
Om vi relaterar detta till exemplet på matleveranswebbplatsen som beskrivits tidigare, ger Atlas Type System en bra grund för att definiera maskininlärningslinjen. Ett generaliserat ML-linjesystem visualiseras enligt följande:
Som framgår av diagrammet ovan följer metadatadefinitionen för maskininlärning noga det faktiska arbetsflödet för maskininlärning. Träningsdatauppsättningar är utgångspunkten för ett modelllinjeflöde. Dessa datamängder kan vara tabeller från ett datalager eller en inbäddad csv-fil. När en datamängd har identifierats följer härstamningen med i utbildning, byggande och implementering av modellen.
ML-funktionsutveckling är en parallell och specialiserad aktivitet som kan betecknas som funktionsteknik (till skillnad från modellteknik). Idag utförs i många fall de två aktiviteterna (modellteknik och funktionsteknik) av samma person eller team. Med demokratisering och industrialisering av funktioner kan detta förändras i framtiden, med specialiserade team för modellutveckling och funktionsutveckling.
ML-typsystemet kan nu definieras genom följande nya typer:
"Skapa maskininlärningsprojekt" och "maskininlärningsprojekt"
Ett enda maskininlärningsprojekt representerar ett enda affärsanvändningsfall. Machine Learning Project representerar behållaren med filer och andra inbäddade tillgångar. Projektmetadata innehåller åtminstone:
- Lista över filer som används i modellen
- Historisk version av alla filer
- Den enklaste implementeringen skulle vara att underhålla projektet som ett git-förråd som förlitar sig på Git för att upprätthålla historik för alla filer.
"Utbildningsdatauppsättning"
En undertyp av en datauppsättning i Atlas som representerar en träningsdatauppsättning. Entiteten Training Data Set används i modellutbildningsprocessen. Den kan associeras med en funktion om den data som genereras är resultatet av tillämpning av funktionsextraktion (eller transformation) på en annan datamängd.
"Träna och bygg"
En process som representerar handlingen att träna och bygga en modell. Inkluderar att köra experiment, trimma och slutföra valet av en träningsalgoritm. Train and Build Process kan eventuellt konsumera resultatet från en Feature Build; till exempel en biblioteksfunktion som definierar funktionsextraktion som används internt av modellen.
"Modellbyggnad"
Modellen härdas och versioneras när en dataforskare har avslutat experiment och utbildning av modellen. Denna bearbetning resulterar i en modellbygge, som är en oföränderlig artefakt som utgör byggstenen för produktion av modeller. En Docker-bild är ett exempel på en Model Build-enhet.
"Deploy Model" och "Model Deployment"
En modellbyggnad går igenom en distributionsprocess, vilket skapar en modelldistribution. Model Deployment representerar en aktiv instansiering av en modell. En Kubernetes-baserad REST-tjänst (FaaS-liknande distribution) är ett exempel på en modelldistributionsenhet.
"Funktionsfunktion"
En maskininlärningsfunktion har två tolkningar:1) Funktionsfunktion och 2) Transformerad datauppsättning.
Entiteten Feature Function är en anpassad funktion (uttryckt i kod) som definierar hur man extraherar en identifierad funktion från en indata. Detta representerar koden för funktioner, liknande hur ML Project representerar behållaren för ML-kod.
Funktionsfunktionen paketeras först som ett bibliotek (versionerad och härdad). Biblioteket konsumeras sedan och appliceras på en given datauppsättning för att omvandla den till en ny datauppsättning (med funktionerna extraherade). Den transformerade datamängden representeras av utbildningsdatauppsättningen som definieras ovan.
"Package Feature" och "Feature Build"
Koden i funktionsfunktionen är förpackad för delning (med andra modeller) eller för körtidspoäng. Dessa paket kallas Feature Builds. Till exempel kan en Feature Build innehålla ett paketerat bibliotek (i python) eller en jar-fil (i Java). Detta paket kan absorberas under modelltåget och byggprocessen för att säkerställa att samma funktion används under utvinning såväl som förutsägelse.
Prova och engagera dig i att definiera framtiden för ML Metadata Definition
Vi har påbörjat arbetet med ATLAS-3432 som är den första implementeringen av Machine Learning Type System som utnyttjar Cloudera Data Science Workbench (CDSW) som pilotklient. Tack till Na Li från Cloudera ingenjörsteam för att ha lett arbetet med att bygga CDSW-integrationen. ATLAS-3432 kommer att tillåta modellmetadata från en CDSW-instans att skjutas till en Apache Atlas-instans för att utforska härstamning. CDSW stöder för närvarande inte funktioner (eller en funktionsbutik), så härkomsten som är relaterade till funktioner kommer att vara otillgänglig.
På Cloudera vill vi inte bara lösa detta problem för våra kunder – vi anser att ML-metadatadefinitioner bör vara universella på samma sätt som tabeller, kolumner etc. är mycket standard för datastrukturer. Vi hoppas att gemenskaper kommer att bidra till att definiera denna standard för att hjälpa företag att få ut det mesta av sina ML-plattformar.
Har du ett användningsfall för styrning av maskininlärning som inte passar in i metadatamodellen? Gå med i konversationen genom att lägga upp dina förslag till [email protected].