Best practices van Google en Uber voor diepgaand leren

Het bouwen van een duurzame Deep Learning-oplossing is meer dan wat wordt geboden door Deep Learning-frameworks zoals TensorFlow en PyTorch. Deze frameworks zijn goed genoeg voor onderzoek, maar ze houden geen rekening met de problemen die zich voordoen bij productie-implementatie. Ik heb eerder geschreven over technische schulden en de behoefte van adaptievere biologische architecturen. Om een ​​levensvatbaar bedrijf met Deep Learning te ondersteunen, hebt u absoluut een architectuur nodig die duurzame verbetering ondersteunt in de aanwezigheid van frequente en onverwachte veranderingen in de omgeving. Het huidige Deep Learning-framework biedt slechts één onderdeel van een complete oplossing.

Gelukkig hebben Google en Uber een glimp van hun interne architecturen gegeven. De architecturen van deze twee reuzen kunnen twee uitstekende basiskampen zijn als u uw eigen productieklare Deep Learning-oplossing moet bouwen.

De primaire motivatie van het systeem van Uber, Michelangelo, was dat "er geen systemen waren om betrouwbare, uniforme en reproduceerbare pijpleidingen te bouwen voor het maken en beheren van training- en voorspellingsgegevens op schaal." In hun artikel beschrijven ze de beperkingen van bestaande kaders met de problemen van de inzet en het beheer van technische schulden. Het artikel heeft voldoende argumenten die sceptici ervan moeten overtuigen dat bestaande kaders onvoldoende zijn voor de productie.

Ik ga Uber's papier niet in zijn geheel doornemen. Ik ga eerder enkele belangrijke punten over hun architectuur benadrukken. Het Uber-systeem is geen strikt Deep Learning-systeem, maar eerder een Machine Learning-systeem dat afhankelijk van de geschiktheid vele ML-methoden kan gebruiken. Het is gebouwd op de volgende open source-componenten: HDFS, Spark, Samza, Cassandra, MLLib, XGBoost en TensorFlow. Het is dus een conventioneel BigData-systeem dat componenten van Machine Learning bevat voor zijn analyses:

Michelangelo is gebouwd bovenop de gegevens- en computerinfrastructuur van Uber en biedt een gegevensmeer waarin alle transactionele en gelogde gegevens van Uber worden opgeslagen, Kafka-makelaars die gelogde berichten van alle Uber-services verzamelen, een Samza-streamingcomputer, beheerde Cassandra-clusters en Uber's in -house service provisioning en implementatie tools.

De architectuur ondersteunt de volgende workflow:

  1. Gegevens beheren
  2. Treinmodellen
  3. Evalueer modellen
  4. Implementeren, voorspellen en bewaken

De Michaelangelo-architecturen van Uber worden als volgt afgebeeld:

Ik ga de gebruikelijke zorgen over Big Data-architectuur overslaan en wijzen op enkele opmerkelijke ideeën die meer betrekking hebben op machine learning.

Michaelangelo verdeelt het gegevensbeheer tussen online en offline pijpleidingen. Om kennisuitwisseling en hergebruik in de hele organisatie mogelijk te maken, is bovendien een 'feature store' beschikbaar:

Op dit moment hebben we ongeveer 10.000 functies in de Feature Store die worden gebruikt om machine learning-projecten te versnellen, en teams in het hele bedrijf voegen voortdurend nieuwe toe. Functies in de Feature Store worden automatisch dagelijks berekend en bijgewerkt.

Uber creëerde een Domain Specific Language (DSL) voor modelleerders om een ​​functie te selecteren, te transformeren en te combineren alvorens een model naar training en voorspelling te sturen. Momenteel ondersteunde ML-methoden zijn beslissingsbomen, lineaire en logistieke modellen, k-gemiddelden, tijdreeksen en diepe neurale netwerken.

De modelconfiguratie specificeert het type, hyperparameters, gegevensbronreferenties, de DSL-expressies van de functie en vereisten voor rekenbronnen (d.w.z. cpus, geheugen, gebruik van GPU, enz.). Training wordt gegeven in een YARN- of Mesos-cluster.

Na de training van het model worden de prestatiestatistieken berekend en verstrekt in een evaluatierapport. Alle informatie, dat wil zeggen de modelconfiguratie, het aangeleerde model en het evaluatierapport, worden opgeslagen in een versiebeheerde modelrepository voor analyse en implementatie. De modelinformatie bevat:

  • Wie heeft het model getraind
  • Begin- en eindtijd van de training
  • Volledige modelconfiguratie (gebruikte functies, hyperparameterwaarden, enz.)
  • Verwijzing naar trainings- en testdatasets
  • Distributie en relatief belang van elke functie
  • Meetnauwkeurigheidscijfers
  • Standaardgrafieken en grafieken voor elk modeltype (bijvoorbeeld ROC-curve, PR-curve en verwarringmatrix voor een binaire classificatie)
  • Volledig aangeleerde parameters van het model
  • Overzichtsstatistieken voor modelvisualisatie

Het idee is om de toegang tot ML-modellen te democratiseren en deze met anderen te delen om de kennis van de organisatie te verbeteren. Het unieke kenmerk van de aanpak van Uber is het opduiken van een 'Feature Store' waarmee veel verschillende partijen hun gegevens kunnen delen met verschillende ML-modellen.

De mensen bij Google hebben een recent artikel “TFX: een op TensorFlow gebaseerd machine-leerplatform voor productieschalen” dat hun interne systeem beschrijft.

Het papier is op dezelfde manier gestructureerd als het papier van Uber omdat het dezelfde workflow betreft:

  1. Gegevens beheren - Gegevensanalyse, transformatie en validatie
  2. Train-modellen - Modeltraining: warmstart en modelspecificatie
  3. Evalueer modellen - Modelevaluatie en -validatie
  4. Implementeren, voorspellen en bewaken - Model Serving

De architectuur van Google is gebaseerd op de volgende richtlijnen op hoog niveau:

  • Leg gegevensafwijkingen vroeg vast.
  • Automatiseer gegevensvalidatie.
  • Behandel gegevensfouten met dezelfde nauwkeurigheid als code.
  • Ondersteuning van continue training.
  • Uniforme configuratie om het delen te verbeteren.
  • Betrouwbare en schaalbare productie-inzet en bediening.

Laten we wat dieper ingaan op de unieke mogelijkheden van Google's TFX. Er zijn tal van weetjes van wijsheid, evenals een introductie van verschillende unieke mogelijkheden.

TFX biedt verschillende mogelijkheden op het gebied van gegevensbeheer. Gegevensanalyse voert statistieken uit over elke gegevensset en biedt informatie over waardeverdeling, kwantielen, gemiddelde, standaardafwijking enz. Het idee is dat gebruikers hierdoor snel inzicht kunnen krijgen in de vorm van de gegevensset. Deze geautomatiseerde analyse wordt gebruikt om de continue trainings- en serveeromgeving te verbeteren.

TFX zorgt voor de data-ruzie en slaat de transformaties op om de consistentie te behouden. Bovendien biedt het systeem een ​​uniform en consistent raamwerk voor het beheren van toewijzingen tussen functies.

TFX bewijst een schema dat een versie is die de verwachtingen op de gegevens specificeert. Dit schema wordt gebruikt om eventuele gevonden afwijkingen te markeren en biedt ook aanbevelingen voor acties zoals het blokkeren van training of het afschaffen van functies. De tooling zorgt voor het automatisch genereren van dit schema zodat het gemakkelijk te gebruiken is voor nieuwe projecten. Dit is een unieke mogelijkheid die inspiratie haalt uit de statische typecontrole in programmeertalen.

TFX gebruikt TensorFlow als modelbeschrijving. TFX heeft het idee van ‘warm starten’ dat is geïnspireerd op de overdrachtleertechniek in Deep Learning. Het idee is om de hoeveelheid training te verminderen door gebruik te maken van bestaande training. In tegenstelling tot overdrachtsonderwijs dat gebruik maakt van een bestaand vooraf opgeleid netwerk, identificeert warmstarten selectief een netwerk met algemene kenmerken als uitgangspunt. Het netwerk dat is getraind op algemene functies wordt gebruikt als basis voor het trainen van meer gespecialiseerde netwerken. Deze functie lijkt geïmplementeerd te zijn in TF-Slim.

TFX maakt gebruik van een algemene TensorFlow-specificatie op hoog niveau (zie: TensorFlow-schatters: beheer van eenvoud versus flexibiliteit in high-level machine learning Frameworks) om uniformiteit te bieden en best practices voor verschillende implementaties te coderen. Zie dit artikel over schatters voor meer informatie.

TFX gebruikt het TensorFlow Serving-framework voor implementatie en weergave. Met het framework kunnen verschillende modellen worden bediend, terwijl dezelfde architectuur en API behouden blijven. TensorFlow Serving bewijst een "zachte model-isolatie" om multi-tenant inzet van modellen mogelijk te maken. Het framework is ook ontworpen om schaalbare gevolgtrekkingen te ondersteunen.

Het TFX-artikel noemde de noodzaak om de deserialisatie van modellen te optimaliseren. Blijkbaar is een aangepaste protocolbufferpars gemaakt om de prestaties tot 2-5 keer te verbeteren.

Het ontleden van de interne architectuur van Uber en Google biedt goed inzicht in pijnpunten en oplossingen voor het bouwen van uw eigen interne platform. In vergelijking met beschikbare open source DL-frameworks ligt de nadruk meer op het beheren en delen van meta-informatie. De aanpak van Google vereist ook extra inspanningen om uniformiteit en geautomatiseerde validatie te garanderen. Dit zijn praktijken die we eerder hebben gezien in conventionele software-engineeringprojecten.

Software engineering praktijken zoals Test Driven Development (TDD), continue integratie, rollback en herstel, verandercontrole etc. worden geïntroduceerd in geavanceerde machine learning praktijken. Het volstaat niet dat een specialist zich ontwikkelt op een Jupyter-notebook en het over de muur gooit naar een team om het operationeel te maken. Dezelfde end-to-end devops-praktijken die we vandaag bij de beste engineeringbedrijven vinden, zullen ook worden geëist bij inspanningen op het gebied van machine learning. We zien dit vandaag zowel in Uber als Google, en daarom moeten we het in elke duurzame ML / DL-praktijk verwachten.

Update: https://www.linkedin.com/pulse/ai-layer-diego-oppenheimer, https://arxiv.org/abs/1804.09997v1

Verken Deep Learning: kunstmatige intuïtie: de onwaarschijnlijke diepe leerrevolutieExploit Deep Learning: The Deep Learning AI Playbook