Google og Ubers bedste praksis for dyb læring

Der er mere ved at opbygge en bæredygtig Deep Learning-løsning end hvad der leveres af Deep Learning-rammer som TensorFlow og PyTorch. Disse rammer er gode nok til forskning, men de tager ikke højde for de problemer, der dukker op med produktionsinstallationen. Jeg har tidligere skrevet om teknisk gæld og behovet fra mere tilpasningsdygtige biologiske lignende arkitekturer. For at understøtte en bæredygtig virksomhed, der bruger Deep Learning, har du absolut brug for en arkitektur, der understøtter bæredygtig forbedring i nærvær af hyppige og uventede miljøændringer. De nuværende Deep Learning-rammer giver kun en enkelt del af en komplet løsning.

Heldigvis har Google og Uber givet et glimt af deres interne arkitekturer. Arkitekturerne af disse to giganter kan være to fremragende base-lejre, hvis du har brug for at bygge din egen produktion klar Deep Learning-løsning.

Den primære motivation for Ubers system ved navn Michelangelo var, at "der ikke var nogen systemer til at opbygge pålidelige, ensartede og reproducerbare rørledninger til oprettelse og styring af trænings- og forudsigelsesdata i skala." I deres papir beskriver de begrænsningerne af eksisterende rammer med spørgsmålene om distribution og håndtering af teknisk gæld. Avisen har nok argumenter til at overbevise enhver skeptiker om, at eksisterende rammer er utilstrækkelige til produktionen.

Jeg vil ikke gå igennem Ubers papir med dig i sin helhed. Snarere vil jeg bare fremhæve nogle vigtige punkter omkring deres arkitektur. Uber-systemet er ikke et strengt Deep Learning-system, men snarere et Machine Learning-system, der kan anvende mange ML-metoder afhængigt af egnethed. Det er bygget på følgende open source-komponenter: HDFS, Spark, Samza, Cassandra, MLLib, XGBoost og TensorFlow. Så det er et konventionelt BigData-system, der inkorporerer Machine Learning-komponenter til dets analyser:

Michelangelo er bygget oven på Ubers data og beregne infrastruktur, der leverer en datasø, der gemmer alle Ubers transaktionsmæssige og loggførte data, Kafka-mæglere, der samler loggede meddelelser fra alle Ubers tjenester, en Samza-streaming-computermotor, administrerede Cassandra-klynger og Uber's i -værktøj til levering af hus og tjenester.

Arkitekturen understøtter følgende arbejdsgang:

  1. Administrer data
  2. Tog modeller
  3. Evaluer modeller
  4. Implementere, forudsige og overvåge

Ubers Michaelangelo-arkitekturer er afbildet som følger:

Jeg vil springe over de sædvanlige Big Data-arkitekturproblemer og påpege nogle bemærkelsesværdige ideer, der relaterer mere til maskinlæring.

Michaelangelo deler administrationen af ​​data mellem online og offline rørledninger. For at tillade videndeling og genbrug på tværs af organisationen stilles en "funktionsbutik" til rådighed:

I øjeblikket har vi cirka 10.000 funktioner i Feature Store, der bruges til at fremskynde maskinindlæringsprojekter, og team i hele virksomheden tilføjer nye hele tiden. Funktioner i Feature Store beregnes og opdateres automatisk dagligt.

Uber oprettede et Domain Specific Language (DSL) for modelers til at vælge, transformere og kombinere funktionen inden en model sendes til træning og forudsigelse. Aktuelt understøttede ML-metoder er beslutningstræer, lineære og logistiske modeller, k-middel, tidsserier og dybe neurale netværk.

Modelkonfigurationen specificerer type, hyperparametre, datakildereferencer, funktionen DSL-udtryk og beregner ressourcekrav (dvs. cpus, hukommelse, brug af GPU osv.). Træning udføres i enten en YARN- eller Mesos-klynge.

Efter modeluddannelse beregnes præstationsmetrikerne og leveres i en evalueringsrapport. Alle oplysninger, det vil sige modelkonfigurationen, den indlærte model og evalueringsrapporten, gemmes i et versioneret modellager til analyse og implementering. Modeloplysningerne indeholder:

  • Hvem trente modellen
  • Start- og sluttidspunkt for træningsjobbet
  • Fuld modelkonfiguration (anvendte funktioner, hyperparameterværdier osv.)
  • Henvisning til trænings- og testdatasæt
  • Distribution og relativ betydning af hver funktion
  • Metrics for modelnøjagtighed
  • Standarddiagrammer og grafer for hver modeltype (f.eks. ROC-kurve, PR-kurve og forvirringsmatrix for en binær klassificering)
  • Fuld indlærte parametre for modellen
  • Resuméstatistik til visualisering af modeller

Tanken er at demokratisere adgangen til ML-modeller og dele den med andre for at forbedre organisatorisk viden. Det unikke ved Ubers tilgang er overfladen af ​​en "Feature Store", der giver mange forskellige parter mulighed for at dele deres data på tværs af forskellige ML-modeller.

Folk på Google har et nyligt papir, "TFX: En TensorFlow-baseret produktionsskala maskineuddannelsesplatform", der beskriver deres interne system.

Papiret er struktureret på lignende måde som Ubers papir, idet de dækker den samme arbejdsgang:

  1. Administrer data - Dataanalyse, transformation og validering
  2. Togmodeller - Modeltræning: Varmstart og modelspecifikation
  3. Evaluer modeller - modelevaluering og validering
  4. Implementere, forudsige og overvåge - Model Servering

Googles arkitektur er drevet af følgende angivne retningslinjer på højt niveau:

  • Fang data-anomalier tidligt.
  • Automatiser datavalidering.
  • Behandle datafeil med samme strenghed som kode.
  • Støtte kontinuerlig træning.
  • Ensartet konfiguration for at forbedre delingen.
  • Pålidelig og skalerbar produktionsinstallation og servering.

Lad os grave lidt dybere i Googles TFX-unikke funktioner. Der er masser af spidser af visdom såvel som en introduktion af flere unikke evner.

TFX leverer flere muligheder inden for omfanget af datastyring. Dataanalyse udfører statistikker over hvert datasæt med information om værdifordeling, kvantiler, middelværdi, standardafvigelse osv. Idéen er, at dette giver brugerne mulighed for hurtigt at få indsigt i datasætets form. Denne automatiske analyse bruges til at forbedre kontinuerlig trænings- og serveringsmiljø.

TFX håndterer datakranglen og gemmer transformationerne for at opretholde konsistensen. Derudover er systemet tilvejebragt ensartede og konsistente rammer til styring af kortlægning af funktion til tal.

TFX beviser et skema, der er en version, der specificerer forventningerne til dataene. Dette skema bruges til at markere eventuelle fundne afvigelser og giver også anbefalinger om handlinger såsom blokering af træning eller forringelse af funktioner. Værktøjet giver automatisk generering af dette skema for at gøre det let at bruge til nye projekter. Dette er en unik kapacitet, der henter inspiration fra den statiske kontrol, der findes i programmeringssprog.

TFX bruger TensorFlow som modelbeskrivelse. TFX har denne opfattelse af 'varmstart', der er inspireret af transfer learning-teknik findes i Deep Learning. Tanken er at reducere træningsmængden ved at udnytte den eksisterende træning. I modsætning til overførselslæring, der anvender et eksisterende foruddannet netværk, identificerer varmstart selektivt et generelt funktionsnetværk som dets startpunkt. Det netværk, der er trænet i generelle funktioner, bruges som grundlag for at træne mere specialiserede netværk. Denne funktion ser ud til at blive implementeret i TF-Slim.

TFX bruger en fælles TensorFlow-specifikation på højt niveau (se: TensorFlow Estimators: Management of Simplicity vs. Flexibility in High Level Machine Learning Framework) for at give ensartethed og kode bedste praksis på tværs af forskellige implementeringer. Se denne artikel om estimatorer for mere detaljeret information.

TFX bruger TensorFlow Serving-rammerne til distribution og servering. Rammen tillader, at forskellige modeller serveres, mens de holder den samme arkitektur og API. TensorFlow Serving beviser en "blød modelisolering" for at muliggøre installation af flere lejere af modeller. Rammerne er også designet til at understøtte skalerbare konklusioner.

TFX-papiret nævnte behovet for at optimere deserialisering af modeller. Tilsyneladende blev der tilpasset en tilpasset protokolbufferteparse for at forbedre ydelsen op til 2–5 gange.

At dissekere Uber og Googles interne arkitektur giver god indsigt i smertepunkter og løsninger til opbygning af din egen interne platform. Sammenlignet med tilgængelige open source DL-rammer er der en større vægt på styring og deling af metainformation. Googles tilgang kræver også en ekstra indsats for at sikre ensartethed såvel som automatiseret validering. Dette er praksis, som vi tidligere har set i konventionelle softwaretekniske projekter.

Software engineering praksis såsom Test Driven Development (TDD), kontinuerlig integration, rollback og gendannelse, ændringskontrol osv. Introduceres i avanceret maskinlæring praksis. Det er ikke nok for en specialist at udvikle sig på en Jupyter-notebook og kaste den over væggen til et team for at gøre operationel. Den samme end-to-end devops-praksis, som vi finder i dag i de bedste ingeniørfirmaer, bliver også efterspurgt inden for maskinlæringsbestræbelser. Vi ser dette i dag i både Uber og Google, og derfor bør vi forvente det i enhver bæredygtig ML / DL-praksis.

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

Udforsk Deep Learning: Kunstig intuition: Den usandsynlige Deep Learning RevolutionUdnyt Deep Learning: The Deep Learning AI Playbook