Machine learning (ML) is een van de meest cruciale mogelijkheden geworden voor moderne bedrijven om te groeien en vandaag de dag concurrerend te blijven. Van het automatiseren van interne processen tot het optimaliseren van de ontwerp-, creatie- en marketingprocessen achter vrijwel elk geconsumeerd product, ML-modellen zijn doorgedrongen in bijna elk aspect van ons werk en persoonlijke leven - en voor bedrijven is de inzet nog nooit zo groot geweest. Als ML niet als kerncompetentie wordt geadopteerd, zal dit leiden tot grote concurrentienadelen die de volgende marktleiders zullen bepalen.
Daarom moeten bedrijfs- en technologieleiders ML-modellen implementeren in hun hele organisatie, die een breed spectrum aan gebruiksscenario's omvat. Dit gevoel van urgentie, gecombineerd met een toenemend toezicht op de regelgeving, creëert echter nieuwe en unieke governance-uitdagingen die momenteel moeilijk te beheren zijn. Bijvoorbeeld:welke invloed hebben mijn modellen op de dienstverlening aan eindklanten? Voldoe ik nog steeds aan zowel de overheids- als de interne regelgeving? Hoe worden mijn beveiligingsregels vertaald naar modellen in productie?
Naast regelgevende of juridische zorgen, zijn er een aantal redenen om governanceprocessen en -procedures voor Machine Learning te hebben. Voorbeelden zijn manieren om de productiviteit te verhogen (zoals het hergebruiken van activa zoals modellen en functies), het controleren en onderhouden van modellen in veel verschillende bedrijfsonderdelen om ervoor te zorgen dat bedrijfskritieke applicaties doen waarvoor ze bedoeld zijn (of diegene vinden die dat niet zijn) en een geschiedenis van modellen en voorspellingen bekijken, inclusief verouderde activa.
Bij het aanpakken van deze uitdagingen is het de moeite waard om te definiëren welke modellen en functies conceptueel zijn (zie figuur 1). Er bestaan veel verschillende definities, maar over het algemeen is een model elk op zichzelf staand pakket dat functies gebruikt die zijn berekend op basis van invoergegevens en een voorspelling (of score) en metagegevens produceert. Dit pakket kan vele vormen aannemen, maar bevat altijd een wiskundige weergave, code, bedrijfslogica en trainingsgegevens. De voorspellingen van het model worden stroomafwaarts gebruikt door systemen of gebruikers.
Veel ondernemingen gebruiken ML-modelinfrastructuur met verschillende groottes en volwassenheid die ze tools nodig hebben om hun modellen te beheren. Uiteindelijk kunnen de behoeften aan ML-governance worden gedistilleerd in de volgende hoofdgebieden:zichtbaarheid; en modelleerbaarheid, interpreteerbaarheid en reproduceerbaarheid.
Figuur 1
Zichtbaarheid van modellen en functies binnen teams en tussen organisaties
Een basisvereiste voor modelgovernance is dat teams kunnen begrijpen hoe machine learning wordt toegepast in hun organisaties. Dit vereist een canonieke catalogus van modellen en functies. Bij het ontbreken van een dergelijke catalogus zijn veel organisaties niet op de hoogte van hun modellen en functies, waar ze worden ingezet, wat ze doen, enz. Dit leidt tot herbewerking, inconsistentie van modellen, herberekeningsfuncties en andere inefficiënties.
Verklaarbaarheid, interpreteerbaarheid en reproduceerbaarheid van het model
Modellen worden vaak gezien als een black box:er gaan gegevens in, er gebeurt iets en er komt een voorspelling uit. Deze ondoorzichtigheid is een uitdaging op een aantal niveaus en wordt vaak weergegeven in losjes verwante termen zoals:
- Verklaarbaarheid :beschrijving van de interne mechanica van een ML-model in menselijke termen
- Interpretabiliteit :het vermogen om a) de relatie tussen invoer, kenmerken en uitvoer van modellen te begrijpen, en b) de reactie op veranderingen in invoer te voorspellen.
- Reproduceerbaarheid :de mogelijkheid om de uitvoer van een model op een consistente manier te reproduceren voor dezelfde invoer.
Al deze vereisen gemeenschappelijke functionaliteit, waaronder een koppeling met brongegevens, een duidelijk begrip van de interne onderdelen van de modellen, zoals code en trainingsgegevens, en andere methoden om modellen zelf te onderzoeken en te analyseren.
Modelmetadata met een voorbeeld
Laten we, om de hierboven gedefinieerde bestuursproblemen aan te pakken, beginnen met een voorbeeld te bedenken. Overweeg een website voor het bezorgen van maaltijden. Het bedrijf wil machine learning gebruiken om de levertijd in te schatten.
De trainingsgegevensset bestaat uit de gebeurtenislogboeken van eerdere leveringen, die de levertijden bevatten voor elke levering die in het verleden is gedaan. Deze gegevens worden gebruikt om een model te trainen om toekomstige levertijden in te schatten.
Een gebeurtenislogboek kan er ongeveer zo uitzien:
Er is om 10.00 uur een bestelling geplaatst om eten op te halen bij loc1 en te bezorgen bij loc2. De koerier haalde het om 10:15 uur op bij het restaurant en leverde het om 10:55 uur af, in totaal 55 minuten tussen het plaatsen van de bestelling en de bezorging
Stel dat loc1 en loc2 straatadressen zijn. Dit wordt hier afgekort om het kort en gemakkelijk te lezen te houden.
De gebeurtenislogboeken worden opgeslagen in HBase. De technische architectuur voor de modelontwikkeling is als volgt:
- Data-engineers bepalen het tijdvenster van gebeurtenislogboeken dat moet worden gebruikt om het probleem op te lossen. Er wordt een nieuwe gestructureerde Hive-tabel gemaakt door de onbewerkte gebeurtenislogboeken te ontleden met het geïdentificeerde tijdvenster.
- Functie-engineers (dit kan een rol zijn binnen datawetenschappers of ML-engineers) identificeren en ontwikkelen nieuwe functies:
- Spitsfunctie:een functie om vast te stellen of er sprake is van spitsuren, gegeven een locatie en een tijd.
- Restaurant 'druk'-functie:een functie om op basis van historische gegevens te identificeren of een bepaald restaurant hoge wachttijden heeft. Deze historische gegevens worden afzonderlijk verzameld.
- De hierboven geïdentificeerde functies worden vervolgens gebouwd als een python-bibliotheek voor hergebruik.
- Deze bibliotheek wordt gebruikt om de functie toe te passen op de gestructureerde Hive-tabel om een nieuwe tabel te maken die de definitieve trainingsgegevensset zal zijn. Een rij in de nieuwe tabel ziet er als volgt uit:
Stel dat loc1 en loc2 straatadressen zijn. Dit wordt hier afgekort om het kort en gemakkelijk te lezen te houden.
- Datawetenschappers voeren een lineaire regressie uit op de trainingsdataset om de leveringstijd te voorspellen. Op dit moment moeten ze dezelfde functiebibliotheek gebruiken die werd gebruikt om de functies in de trainingsgegevensset te extraheren.
- Het model wordt geïmplementeerd als een Function-as-a-Service (FaaS)-eindpunt dat door de webtoepassing wordt gebruikt om de leveringstijd te voorspellen.
Merk op dat het model de functies voor voorspelling in realtime moet berekenen. Deze functies zijn bibliotheken die intern door het model worden gebruikt. Een visualisatie van de verschillende uitgevoerde activiteiten en gegenereerde artefacten in dit voorbeeld kan er als volgt uitzien:
De blauwe vakken vertegenwoordigen ML-entiteiten (zelfstandige naamwoorden) zoals een code, project, builds, implementaties, enz. De groene vakken vertegenwoordigen processen (werkwoorden) die op entiteiten inwerken en andere entiteiten produceren.
De visualisatie en relaties die de transformaties op de structuur van gegevens definiëren, worden gezamenlijk aangeduid als afstamming . In de databasewereld zal het toevoegen van een nieuwe kolom aan een tabel de afstamming ervan wijzigen. In de wereld van machine learning zal het hertrainen van een model door het consumeren van functies en datasets de afstamming wijzigen. Voor de website voor het bezorgen van eten, om de vraag te beantwoorden:"is er een verschil tussen de functie-extractie tijdens training versus scoren", hebben we de afstammingsinformatie nodig. Dit is slechts één voorbeeld van het nut van afstammingsmetadata in de wereld van machine learning.
Apache Atlas als bestuurstool
Het is duidelijk dat het bouwen van een complete end-to-end-lijn voor ML-workflows - van trainingsdatasets tot modelimplementaties - een belangrijke vereiste wordt om de vastgestelde governanceproblemen aan te pakken. De integratie van datamanagement en machine learning moet uitlegbaarheid, interpreteerbaarheid en reproduceerbaarheid mogelijk maken.
Het verzamelen, opslaan en visualiseren van ML-metadata vereist een standaard backend-softwaresysteem. Een open en uitbreidbare definitie van metadata maakt standaardisatie van governance-activiteiten mogelijk, ongeacht waar de modellen worden ontwikkeld of bediend. De voor de hand liggende kandidaat voor Cloudera (en onze klanten) is Apache Atlas.
Apache Atlas is al een set veelgebruikte beheertools met vooraf gedefinieerde metadatatypen voor gegevensbeheer. In de context van ML-governance is het zeer geschikt voor het definiëren en vastleggen van de metadata die nodig zijn voor machine learning-concepten. Bovendien biedt Apache Atlas geavanceerde mogelijkheden zoals classificaties, integratie met Apache Ranger (voor autorisatie en tagging) om er maar een paar te noemen, en heeft het een uitbreidbaar add-onssysteem waarmee de gemeenschap kan samenwerken rond en stapsgewijs integraties met verschillende andere tools in de ML kan definiëren. ruimte. Het wordt overgelaten als een oefening voor de lezer om de gebruikersinterface van Apache Atlas te verkennen en te zien hoe deze mogelijkheden kunnen worden gebruikt.
ML-metadatadefinitie in Apache Atlas
Het Apache Atlas Type System voldoet aan al onze behoeften voor het definiëren van ML Metadata-objecten. Het is open-source, uitbreidbaar en heeft vooraf gebouwde beheerfuncties. Een type in Atlas is een definitie van hoe een bepaald type metadata-object wordt opgeslagen en benaderd. Het vertegenwoordigt ook een of meer attributen die de eigenschappen voor het metadata-object definiëren. Voor ML-governance kan Atlas Type System worden gebruikt om nieuwe typen te definiëren, waarbij ML-entiteiten en -processen worden vastgelegd als Atlas-metadata-objecten. Naast de definitie van de typen is ook de relatie tussen de entiteiten en processen vereist om de end-to-end lineage-stroom te visualiseren.
Als we dit relateren aan het eerder beschreven voorbeeld van een voedselbezorgwebsite, biedt het Atlas Type System een goede basis om de Machine Learning-lijn te definiëren. Een algemeen ML-afstammingssysteem wordt als volgt gevisualiseerd:
Zoals blijkt uit het bovenstaande diagram, volgt de metagegevensdefinitie voor machine learning nauw de feitelijke workflow voor machine learning. Trainingsdatasets zijn het startpunt voor een modellijnstroom. Deze datasets kunnen tabellen uit een datawarehouse of een embedded csv-bestand zijn. Zodra een dataset is geïdentificeerd, volgt de afstamming bij het trainen, bouwen en implementeren van het model.
De ontwikkeling van ML-functies is een parallelle en gespecialiseerde activiteit die kan worden aangeduid als feature-engineering (anders dan modelengineering). Tegenwoordig worden in veel gevallen de twee activiteiten (modelengineering en feature engineering) uitgevoerd door dezelfde persoon of hetzelfde team. Met de democratisering en industrialisering van functies zou dit in de toekomst kunnen veranderen, met gespecialiseerde teams voor modelontwikkeling en functieontwikkeling.
Het ML-type systeem kan nu worden gedefinieerd via de volgende nieuwe typen:
'Machine Learning-project maken' en 'Machine Learning-project'
Een enkel Machine Learning-project vertegenwoordigt een enkele zakelijke use-case. Het Machine Learning Project vertegenwoordigt de container met bestanden en andere ingesloten middelen. De metadata van het project bevat minimaal:
- Lijst met bestanden die in het model worden gebruikt
- Historische versie van alle bestanden
- De eenvoudigste implementatie zou zijn om het project te onderhouden als een git-repository die vertrouwt op Git om de geschiedenis van alle bestanden bij te houden.
'Trainingsgegevensset'
Een subtype van een DataSet in Atlas dat een trainingsdataset vertegenwoordigt. De entiteit Trainingsgegevensset wordt gebruikt in het modeltrainingsproces. Het kan aan een kenmerk worden gekoppeld als de gegenereerde gegevens het resultaat zijn van het toepassen van kenmerkextractie (of transformatie) op een andere gegevensset.
'Train en bouw'
Een proces dat de actie van training en het bouwen van een model vertegenwoordigt. Omvat het uitvoeren van experimenten, afstemmen en finaliseren van de keuze van een trainingsalgoritme. Train and Build Process kan optioneel de output van een Feature Build verbruiken; bijvoorbeeld een bibliotheekfunctie die kenmerkextractie definieert die intern door het model wordt gebruikt.
“Modelbouw”
Het model wordt gehard en geversied zodra een datawetenschapper klaar is met experimenteren en het model trainen. Deze verwerking resulteert in een Model Build, een onveranderlijk artefact dat de bouwsteen vormt voor het produceren van modellen. Een Docker-afbeelding is een voorbeeld van een Model Build-entiteit.
'Model implementeren' en 'Modelimplementatie'
Een Model Build doorloopt een implementatieproces, dat een Modelimplementatie creëert. De modelimplementatie vertegenwoordigt een actieve instantie van een model. Een op Kubernetes gebaseerde REST-service (implementatie in FaaS-stijl) is een voorbeeld van een Model Deployment-entiteit.
"Functiefunctie"
Een machine learning-functie heeft twee interpretaties:1) Feature Function en 2) Transformed Data Set.
De Feature Function-entiteit is een aangepaste functie (uitgedrukt in code) die definieert hoe een geïdentificeerde functie uit een invoer moet worden geëxtraheerd. Dit vertegenwoordigt de code voor functies, vergelijkbaar met hoe ML Project de container voor ML-code vertegenwoordigt.
De Feature Function wordt eerst verpakt als een bibliotheek (versie en gehard). De bibliotheek wordt vervolgens verbruikt en toegepast op een bepaalde dataset om deze om te zetten in een nieuwe dataset (waarbij de functies zijn geëxtraheerd). De getransformeerde dataset wordt vertegenwoordigd door de hierboven gedefinieerde entiteit Trainingsdataset.
“Pakketfunctie” en “Functieopbouw”
De code in de Feature Function is verpakt om te delen (met andere modellen) of voor runtime-scores. Deze pakketten worden Feature Builds genoemd. Een Feature Build kan bijvoorbeeld een ingepakte bibliotheek (in python) of een jar-bestand (in Java) bevatten. Dit pakket kan worden opgenomen tijdens het modeltrein- en bouwproces om ervoor te zorgen dat dezelfde functie wordt gebruikt tijdens extractie en voorspelling.
Probeer het uit en raak betrokken bij het definiëren van de toekomst van ML Metadata Definition
We zijn begonnen met het werk aan ATLAS-3432, de eerste implementatie van het Machine Learning Type System dat gebruikmaakt van Cloudera Data Science Workbench (CDSW) als proefclient. Met dank aan Na Li van het Cloudera-engineeringteam voor het leiden van het werk aan het bouwen van de CDSW-integratie. Met ATLAS-3432 kunnen de modelmetadata van een CDSW-instantie naar een Apache Atlas-instantie worden gepusht om de afstamming te verkennen. CDSW ondersteunt momenteel geen functies (of een feature store), en dus zal de lijn met betrekking tot functies niet beschikbaar zijn.
Bij Cloudera willen we dit probleem niet alleen voor onze klanten oplossen - we zijn van mening dat ML-metadatadefinities universeel moeten zijn, vergelijkbaar met hoe tabellen, kolommen, enz. zeer standaard zijn voor datastructuren. We hopen dat gemeenschappen zullen bijdragen aan het definiëren van deze standaard om bedrijven te helpen het meeste uit hun ML-platforms te halen.
Heeft u een use-case voor machine learning governance die niet past in het metadatamodel? Neem deel aan het gesprek door uw suggesties te posten op [email protected].