Googles og Ubers beste fremgangsmåter for dyp læring

Det er mer å bygge en bærekraftig Deep Learning-løsning enn det som tilbys av Deep Learning-rammer som TensorFlow og PyTorch. Disse rammene er gode nok for forskning, men de tar ikke hensyn til problemene som dukker opp ved produksjonsutplassering. Jeg har skrevet tidligere om teknisk gjeld og behovet fra mer tilpasningsdyktige biologiske som arkitekturer. For å støtte en levedyktig virksomhet som bruker Deep Learning, trenger du absolutt en arkitektur som støtter bærekraftig forbedring i nærvær av hyppige og uventede miljøendringer. Gjeldende Deep Learning-rammer gir bare en enkelt del av en komplett løsning.

Heldigvis har Google og Uber gitt et glimt av sine interne arkitekturer. Arkitekturene til disse to gigantene kan være to utmerkede baseleirer hvis du trenger å bygge din egen produksjonsklare Deep Learning-løsning.

De viktigste motivasjonene til Ubers system ved navn Michelangelo var at "det ikke var noen systemer for å bygge pålitelige, ensartede og reproduserbare rørledninger for å lage og administrere opplærings- og prediksjonsdata i skala." I papiret deres beskriver de begrensningene for eksisterende rammer med spørsmålene om distribusjon og håndtering av teknisk gjeld. Avisen har nok argumenter som skal overbevise enhver skeptiker om at eksisterende rammer er utilstrekkelige for produksjonen.

Jeg har ikke tenkt å gå gjennom Ubers papir med deg i sin helhet. Snarere vil jeg bare trekke frem noen viktige punkter rundt deres arkitektur. Uber-systemet er ikke et strengt Deep Learning-system, men snarere et Machine Learning-system som kan bruke mange ML-metoder avhengig av egnethet. Det er bygget på følgende open source-komponenter: HDFS, Spark, Samza, Cassandra, MLLib, XGBoost og TensorFlow. Så det er et konvensjonelt BigData-system som inneholder Machine Learning-komponenter for analysene:

Michelangelo er bygget på toppen av Ubers data- og beregningsinfrastruktur, og gir en datasjø som lagrer alle Ubers transaksjons- og loggførte data, Kafka-meglere som samler loggførte meldinger fra alle Ubers tjenester, en Samza streaming-beregningsmotor, administrerte Cassandra-klynger og Uber-er i -leverandør og distribusjonsverktøy.

Arkitekturen støtter følgende arbeidsflyt:

  1. Administrer data
  2. Togmodeller
  3. Evaluer modeller
  4. Distribuere, forutsi og overvåke

Ubers Michaelangelo-arkitekturer er avbildet som følger:

Jeg kommer til å hoppe over de vanlige problemene med Big Data-arkitektur og påpeke noen viktige ideer som knytter seg mer til maskinlæring.

Michaelangelo deler behandlingen av data mellom online og offline rørledninger. I tillegg, for å tillate kunnskapsdeling og gjenbruk i hele organisasjonen, gjøres en "funksjonsbutikk" tilgjengelig:

For øyeblikket har vi omtrent 10.000 funksjoner i Feature Store som brukes til å akselerere maskinlæringsprosjekter, og team over hele selskapet legger til nye hele tiden. Funksjoner i Feature Store beregnes og oppdateres automatisk hver dag.

Uber opprettet et Domain Specific Language (DSL) for modellerere å velge, transformere og kombinere funksjonen før du sender en modell til trening og prediksjon. For tiden støttede ML-metoder er beslutningstrær, lineære og logistiske modeller, k-middel, tidsserier og dype nevrale nettverk.

Modellkonfigurasjonen spesifiserer type, hyperparametere, datakildereferanser, funksjonen DSL-uttrykk og beregner ressurskrav (dvs. cpus, minne, bruk av GPU, etc.). Opplæring utføres i enten en YARN- eller Mesos-klynge.

Etter modellopplæring blir resultatmålinger beregnet og gitt i en evalueringsrapport. All informasjonen, det vil si modellkonfigurasjonen, den innlærte modellen og evalueringsrapporten, lagres i et versjonert modelllager for analyse og distribusjon. Modellinformasjonen inneholder:

  • Som trente modellen
  • Start- og sluttid på treningsjobben
  • Full modellkonfigurasjon (funksjoner brukt, hyperparameterverdier, etc.)
  • Henvisning til trenings- og testdatasett
  • Distribusjon og relativ betydning av hver funksjon
  • Metoder for modellnøyaktighet
  • Standard diagrammer og grafer for hver modelltype (f.eks. ROC-kurve, PR-kurve og forvirringsmatrise for en binær klassifiserer)
  • Fullt innlærte parametere for modellen
  • Sammendragsstatistikk for modellvisualisering

Tanken er å demokratisere tilgangen til ML-modeller, dele den med andre for å forbedre organisasjonskunnskapen. Det unike ved Ubers tilnærming er overflaten av en "Feature Store" som lar mange forskjellige parter dele sine data på tvers av forskjellige ML-modeller.

Folk på Google har en fersk artikkel "TFX: En TensorFlow-basert produksjonsskala maskinlæringsplattform" som beskriver deres interne system.

Oppgaven er strukturert på samme måte som Ubers papir ved at de dekker den samme arbeidsflyten:

  1. Administrer data - Dataanalyse, transformasjon og validering
  2. Togmodeller - Modelltrening: Varmstart og modellspesifikasjon
  3. Evaluer modeller - Evaluering og validering av modeller
  4. Distribuere, forutsi og overvåke - Model Servering

Googles arkitektur er drevet av følgende uttalte retningslinjer på høyt nivå:

  • Fang inn dataavvik tidlig.
  • Automatiser datavalidering.
  • Behandle datafeil med samme strenghet som kode.
  • Støtte kontinuerlig trening.
  • Ensartet konfigurasjon for å forbedre delingen.
  • Pålitelig og skalerbar produksjons distribusjon og servering.

La oss grave litt dypere i de unike egenskapene til Googles TFX. Det er mange små ting av visdom, samt en introduksjon av flere unike evner.

TFX gir flere funksjoner innen datahåndtering. Dataanalyse utfører statistikk over hvert datasett som gir informasjon om verdifordeling, kvantiler, gjennomsnitt, standardavvik osv. Tanken er at dette lar brukerne raskt få innsikt i datasettets form. Denne automatiserte analysen brukes til å forbedre kontinuerlig opplærings- og serveringsmiljø.

TFX håndterer datakranglingen og lagrer transformasjonene for å opprettholde konsistensen. Videre tilveiebringer systemet enhetlige og konsistente rammer for håndtering av funksjoner-til-heltall-tilordninger.

TFX beviser et skjema som er versjon som spesifiserer forventningene til dataene. Dette skjemaet brukes til å flagge eventuelle avvik som er funnet, og gir også anbefalinger om handlinger som blokkering av trening eller avskrivning av funksjoner. Verktøyet gir automatisk generering av dette skjemaet for å gjøre det enkelt å bruke til nye prosjekter. Dette er en unik evne som henter inspirasjon fra den statiske typen kontrollen som finnes i programmeringsspråk.

TFX bruker TensorFlow som modellbeskrivelse. TFX har denne forestillingen om 'varmstart' som er inspirert av transfer learning-teknikk som finnes i Deep Learning. Tanken er å redusere treningsmengden ved å utnytte eksisterende trening. I motsetning til overføringslæring som bruker et eksisterende forhåndstrenert nettverk, identifiserer varmstart selektivt et generelt funksjonsnettverk som utgangspunkt. Nettverket som er trent på generelle funksjoner brukes som grunnlag for å trene mer spesialiserte nettverk. Denne funksjonen ser ut til å bli implementert i TF-Slim.

TFX bruker en felles TensorFlow-spesifikasjon på høyt nivå (se: TensorFlow Estimators: Managing Simplicity vs. Flexibility in High Level Machine Learning Framework) for å gi enhetlighet og kode beste praksis på tvers av forskjellige implementeringer. Se denne artikkelen om estimater for mer detalj.

TFX bruker TensorFlow Serveringsrammeverket for distribusjon og servering. Rammeverket gjør det mulig å servere forskjellige modeller, samtidig som de har samme arkitektur og API. TensorFlow Servering beviser en "myk modellisolasjon" for å tillate distribusjon av modeller med flere leietakere. Rammeverket er også designet for å støtte skalerbare slutninger.

TFX-papiret nevnte behovet for å optimalisere deserialiseringen av modeller. Tilsynelatende ble det laget en tilpasset protokollbufferpares for å forbedre ytelsen opptil 2–5 ganger.

Dissecting Uber og Googles interne arkitektur gir god innsikt i smertepunkter og løsninger for å bygge din egen interne plattform. Sammenlignet med tilgjengelige DL-rammer med åpen kildekode, er det en større vektlegging av styring og deling av metainformasjon. Googles tilnærming krever også ytterligere innsats for å sikre enhetlighet og automatisert validering. Dette er praksis som vi har sett tidligere i konvensjonelle programvaretekniske prosjekter.

Programvareteknisk praksis som Test Driven Development (TDD), kontinuerlig integrering, tilbakestilling og gjenoppretting, endringskontroll etc. blir introdusert i avanserte praksis for maskinlæring. Det er ikke nok for en spesialist å utvikle seg på en Jupyter-notisbok og kaste den over veggen til et team for å gjøre det operativt. Den samme end-to-end devops-praksis som vi finner i dag i de beste ingeniørfirmaene vil også bli krevd i maskinlæringsarbeid. Vi ser dette i dag i både Uber og Google, og dermed bør vi forvente det i enhver bærekraftig ML / DL-praksis.

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

Utforsk Deep Learning: Kunstig intuisjon: Den usannsynlige Deep Learning RevolutionUtnytt Deep Learning: The Deep Learning AI Playbook