By Eugène Yan, Applied Science bij Amazon, Writer & Speaker.

Onlangs kwam ik een reddit thread over de verschillende rollen in data science en machine learning: data scientist, decision scientist, product data scientist, data engineer, machine learning engineer, machine learning tooling engineer, AI architect, etc.

Ik vond dit zorgen te maken. Het is moeilijk om effectief te zijn als het datawetenschapsproces (framing van problemen, data engineering, ML, implementatie / onderhoud) over verschillende mensen is verdeeld. Het leidt tot overhead van coördinatie, verspreiding van verantwoordelijkheid en een gebrek aan een totaalbeeld.

NAAR MIJN BESCHEIDEN MENING, Ik geloof dat datawetenschappers effectiever kunnen zijn door end-to-end te zijn. Hier zal ik de betekent en tegenargumenten, hoe te worden end-to-end, en de ervaringen van Stitch Fix en Netflix.

Van start (identificeer het probleem) tot finish (los het op)

Misschien bent u soortgelijke tegengekomen labels en definities, zoals:

• generalist: Gericht op rollen (PM, BA, DE, DS, MLE); een negatieve connotatie
• Volledige stapel: Gericht op technologie (Spark, Torch, Docker); populair gemaakt door full-stack ontwikkelaars
• Eenhoorn: Gericht op mythologie; geloofde niet te bestaan

Ik vind deze definities prescriptiever dan ik verkies. In plaats daarvan heb ik een eenvoudige (en pragmatische) definitie: een end-to-end datawetenschapper kan dat problemen met gegevens identificeren en oplossen om waarde te leveren. Om het doel te bereiken, dragen ze zoveel (of zo weinig) hoeden als nodig is. Ze zullen ook elke technologie, methodologie en proces die werkt, leren en toepassen. Tijdens het hele proces stellen ze vragen zoals:

• Wat is het probleem? Waarom is het belangrijk?
• Kunnen we het oplossen? Hoe moeten we het oplossen?
• Wat is de geschatte waarde? Wat was de werkelijke waarde?

Data Science-processen

Een andere manier om end-to-end datawetenschap te definiëren, is via processen. Deze processen zijn meestal complex en ik heb ze buiten de hoofddiscussie gelaten. Hier volgen er echter een paar voor het geval u nieuwsgierig bent:

• CRISP-DM: Industrieoverschrijdend standaardproces voor datamining (1997).
• KDD: Knowledge Discovery in databases.
• TDSP: Team Data Science Process, voorgesteld door Microsoft in 2018.
• DSLP: Data Science levenscyclusproces.

Maak je geen zorgen als deze processen zwaar en overweldigend lijken. U hoeft ze niet in het groot te adopteren - begin beetje bij beetje, bewaar wat werkt en pas de rest aan.

.

Meer context, snellere iteratie, meer tevredenheid

Voor de meeste datawetenschappelijke functies betekent meer end-to-end zijn uw vermogen om een ​​zinvolle impact te hebben. (Toch zijn er rollen die gericht zijn op machine learning.)

End-to-end werken biedt meer context. Hoewel gespecialiseerde rollen de efficiëntie kunnen verhogen, vermindert het de context (voor de datawetenschapper) en leidt het tot suboptimale oplossingen.

De truc om het grote geheel te vergeten, is door alles van dichtbij te bekijken. - Chuck Palahniuk

Het is moeilijk om een ​​holistische oplossing te ontwerpen zonder de volledige context van het stroomopwaartse probleem. Stel dat de conversie is afgenomen en een PM een verzoek indient om ons zoekalgoritme te verbeteren. Maar wat veroorzaakt de afname in de eerste plaats? Er kunnen verschillende oorzaken zijn:

• Product: verminderen frauduleuze producten / producten van slechte kwaliteit het vertrouwen van de klant?
• Datapijplijnen: is de datakwaliteit aangetast of zijn er vertragingen / storingen?
• Model vernieuwen: wordt het model niet regelmatig / correct vernieuwd?

Vaker wel dan niet, ligt het probleem - en de oplossing - buiten van machine learning. Een oplossing voor het algoritme verbeteren zou de hoofdoorzaak missen.

Evenzo is het riskant om een ​​oplossing te ontwikkelen zonder je bewust te zijn van downstream engineering en productbeperkingen. Het heeft geen zin:

• Het bouwen van een bijna realtime aanbeveler als infra en ingenieur dit niet kunnen ondersteunen
• Een oneindige scroll-aanbeveler bouwen als deze niet in ons product en onze app past

Door end-to-end te werken, hebben datawetenschappers de volledige context om de juiste problemen te identificeren en bruikbare oplossingen te ontwikkelen. Het kan ook leiden tot innovatieve ideeën die specialisten, met hun beperkte context, misschien missen. Over het algemeen vergroot het de mogelijkheid om waarde te leveren.

De overhead voor communicatie en coördinatie wordt verminderd. Met meerdere rollen komt extra overhead. Laten we eens kijken naar een voorbeeld van een data engineer (DE) die de data opschoont en features creëert, een data scientist (DS) die de data analyseert en het model traint, en een machine learning engineer (MLE) die het implementeert en onderhoudt.

Wat een programmeur in één maand kan, kunnen twee programmeurs in twee maanden. - Frederick P. Brooks

De DE en DS moeten communiceren over welke gegevens beschikbaar zijn (en niet), hoe ze moeten worden opgeschoond (bijv. uitbijters, normalisatie) en welke functies moeten worden gemaakt. Evenzo moeten de DS en MLE bespreken hoe het model moet worden geïmplementeerd, bewaakt en onderhouden, en hoe vaak het moet worden vernieuwd. Als er problemen optreden, hebben we drie mensen in de kamer nodig (waarschijnlijk met een PM) om de hoofdoorzaak te achterhalen en de volgende stappen om het probleem op te lossen.

Het leidt ook tot extra coördinatie, waarbij planningen moeten worden afgestemd terwijl het werk wordt uitgevoerd en doorgegeven in een sequentiële benadering. Als de DS wil experimenteren met aanvullende gegevens en functies, moeten we wachten tot de DE de gegevens heeft opgenomen en de functies heeft gemaakt. Als een nieuw model klaar is voor A / B-testen, moeten we wachten tot de MLE is (geconverteerd naar productiecode) en geïmplementeerd.

Hoewel het eigenlijke ontwikkelingswerk dagen kan duren, kan het heen en weer communiceren en de coördinatie weken duren, zo niet langer. Met end-to-end datawetenschappers kunnen we deze overhead minimaliseren en voorkomen dat technische details verloren gaan bij de vertaling.

(Maar kan een end-to-end DS dat echt allemaal doen? Ik denk het wel. Hoewel de DS misschien niet zo bedreven is in sommige taken als een DE of MLE, kunnen ze de meeste taken effectief uitvoeren. hulp bij aanslag of verharding, ze kunnen altijd hulp krijgen van gespecialiseerde DE's en MLE's.)

De kosten van communicatie en coördinatie

Richard Hackman, een psycholoog van Harvard, toonde aan dat het aantal relaties in een team is N (N-1) / 2, WAAR N is het aantal mensen. Dit leidt tot een exponentiële groei van links, waarbij:

• Een start-up team van 7 heeft 21 links te onderhouden
• Een groep van 21 (dwz drie startende teams) heeft 210 links
• Een groep van 63 heeft bijna 2,000 links.

In ons eenvoudige voorbeeld hadden we maar drie rollen (dwz zes links). Maar aangezien een PM, BA en extra leden worden meegerekend, leidt dit tot een meer dan lineaire groei in communicatie- en coördinatiekosten. Dus terwijl elk extra lid de totale teamproductiviteit verhoogt, betekent de verhoogde overhead dat de productiviteit in een afnemend tempo groeit. (Van Amazon twee pizzateams zijn hiervoor een mogelijke oplossing.)

Het iteratie- en leersnelheid wordt verhoogd. Met meer context en minder overhead kunnen we nu itereren, falen (lees: leren) en sneller waarde leveren.

Dit is vooral belangrijk voor het ontwikkelen van data en algoritmische producten. In tegenstelling tot software-engineering (een veel volwassener vak), kunnen we niet al het leren en ontwerpen doen voordat we beginnen met bouwen - onze blauwdrukken, architecturen en ontwerppatronen zijn niet zo ontwikkeld. Snelle iteratie is dus essentieel voor de ontwerp-bouw-leercyclus.

Er is meer eigenaarschap en verantwoordelijkheid. Als het datawetenschapsproces over meerdere mensen wordt verdeeld, kan dit leiden tot verspreiding van verantwoordelijkheid en, erger nog, sociale loafing.

Een algemeen waargenomen antipatroon is "over de muur gooien. " De DE maakt bijvoorbeeld features en gooit een databasetabel naar de DS, de DS traint een model en stuurt de R-code naar de MLE, en de MLE vertaalt deze naar Java naar productie.

Als er dingen verloren gaan in de vertaling of als de resultaten onverwacht zijn, wie is dan verantwoordelijk? Met een sterke cultuur van eigenaarschap, treedt iedereen op om bij te dragen in hun respectievelijke rollen. Maar zonder dit kan werk ontaarden in kont-bedekken en met de vinger wijzen, terwijl het probleem aanhoudt en klanten en het bedrijf eronder lijden.

Door de end-to-end datawetenschapper eigenaar en verantwoordelijkheid te laten nemen voor het hele proces, kan dit worden beperkt. Ze moeten in staat worden gesteld om van begin tot eind actie te ondernemen, van het klantprobleem en de input (dwz onbewerkte gegevens) tot de output (dwz het geïmplementeerde model) en meetbare resultaten.

Verspreiding van verantwoordelijkheid en sociale loafing

Spreiding van verantwoordelijkheid: We nemen minder snel verantwoordelijkheid en handelen als er anderen aanwezig zijn. Individuen voelen minder verantwoordelijkheid en urgentie om te helpen als we weten dat anderen ook naar de situatie kijken.

Een vorm hiervan is de Omstandereffect, Waar Kitty Genovese werd neergestoken buiten het flatgebouw aan de overkant van de straat waar ze woonde. Hoewel er 38 getuigen waren die de aanval zagen of hoorden, belde niemand de politie of hielp haar.

Sociaal loafing: We doen minder moeite als we in een groep werken dan als we alleen werken. In de jaren 1890 liet Ringelmann mensen zowel afzonderlijk als in groepen aan touwen trekken. Hij mat hoe hard ze trokken en ontdekte dat leden van een groep de neiging hadden om minder moeite te doen om aan een touw te trekken dan individuen alleen.

Voor (sommige) datawetenschappers kan het leiden tot meer motivatie en werkplezierDit is nauw verbonden naar autonomie, meesterschap en doel.

• Autonomie: Door zelfstandig problemen op te lossen. In plaats van te wachten en afhankelijk van anderen, kunnen end-to-end datawetenschappers het probleem identificeren en definiëren, hun eigen datapijplijnen bouwen en een oplossing implementeren en valideren.
• Meesterschap: In het probleem, de oplossing, het resultaat van begin tot eind. Ze kunnen indien nodig ook het domein en de technologie ophalen.
• Doel: Door diep betrokken te zijn bij het hele proces, hebben ze een directere verbinding met het werk en de resultaten, wat leidt tot een groter gevoel van doel.

Maar we hebben ook gespecialiseerde experts nodig

End-to-end zijn is echter niet voor iedereen (en elk team) weggelegd, om redenen zoals:

Zich willen specialiseren in machine learning, of misschien een specifieke niche in machine learning, zoals het genereren van neurale tekst (lees: GPT-3-primer). Hoewel end-to-end werken waardevol is, hebben we ook experts van wereldklasse in onderzoek en industrie nodig die de grenzen verleggen. Veel van wat we hebben in ML kwam uit de academische wereld en puur onderzoek.

Niemand bereikt grootsheid door generalist te worden. Je scherpt een vaardigheid niet aan door je aandacht voor de ontwikkeling ervan te verdunnen. De enige manier om naar het volgende niveau te gaan, is focus. - John C. Maxwell

Gebrek aan interesse. Niet iedereen is erop gebrand om met klanten en bedrijven in gesprek te gaan om het probleem te definiëren, vereisten te verzamelen en ontwerpdocumenten te schrijven. Evenzo is niet iedereen geïnteresseerd in software-engineering, productiecode, unit-tests en CI / CD-pijplijnen.

Werken aan grote systemen met een hoge hefboomwerking waarbij 0.01% verbetering een enorme impact heeft. Bijvoorbeeld algoritmische handel en reclame. In dergelijke situaties is hyperspecialisatie vereist om die verbeteringen te vinden.

Anderen hebben ook argumenten aangevoerd waarom datawetenschappers zich zouden moeten specialiseren (en niet end-to-end). Hier zijn een paar artikelen om balans en tegenargumenten te geven:

• Waarom je geen data science-generalist zou moeten zijn
• Waarom elke datawetenschapper zich moet specialiseren
• Wil je een baan in Data Science? Hier is waarom u zich moet specialiseren

De beste manier om het op te pakken, is door te leren door te doen

Als je nog steeds graag meer end-to-end wilt worden, bespreken we nu hoe je dat kunt doen. Voordien, zonder in te gaan op specifieke technologieën, zijn hier de emmers van vaardigheden die end-to-end datawetenschappers vaak gebruiken:

• Product: begrijp klantproblemen, definieer en prioriteer vereisten
• Communicatie: faciliteer tussen teams, verkrijg buy-in, schrijf documenten, deel resultaten
• Data engineering: verplaats en transformeer data van punt A naar B
• Gegevensanalyse: gegevens begrijpen en visualiseren, A / B-testen en inferentie
• Machine learning: het gebruikelijke plus experimenteren, implementeren en metrische gegevens
• Software engineering: productiecodepraktijken inclusief unit tests, documenten, logging
• Dev Ops: Basistools voor containerisatie en cloudvaardigheid, build en automatisering

(Deze lijst is niet verplicht en ook niet volledig. De meeste projecten hebben ze niet allemaal nodig.)

Hier zijn vier manieren waarop u dichter bij een end-to-end datawetenschapper kunt komen:

Bestudeer de juiste boeken en cursussen. (Oké, dit is niet leren door te doen, maar we moeten allemaal ergens beginnen). Ik zou me concentreren op cursussen die stilzwijgende kennis behandelen in plaats van specifieke tools. Hoewel ik dergelijke materialen niet ben tegengekomen, heb ik er goede recensies over gehoord Volledige stapel diep leren Deep.

Doe uw eigen projecten van begin tot eind om uit de eerste hand ervaring op te doen met het hele proces. Met het risico het te vereenvoudigen, zijn hier enkele stappen die ik zou nemen met de bijbehorende vaardigheden.

Ik hoor het en ik vergeet het. Ik zie het en ik herinner het me. Ik doe en ik begrijp het. - Confucius

Begin met het identificeren van een op te lossen probleem en het bepalen van de successtatistiek (artikel). Zoek dan wat ruwe data (dwz niet Kaggle-wedstrijdgegevens); hiermee kunt u de gegevens opschonen en voorbereiden en functies maken (data-engineering). Probeer vervolgens verschillende ML-modellen, waarbij u leercurves, foutverdelingen en evaluatiestatistieken (data science).

Beoordeel de prestaties van elk model (bijv. Wachttijd van query's, geheugenvoetafdruk) voordat u er een kiest en een basis schrijft inferentieklasse eromheen voor productie (software engineering). (Misschien wilt u ook een eenvoudige gebruikersinterface bouwen). Zet het vervolgens in een container en implementeer het online zodat anderen het kunnen gebruiken via uw favoriete cloudprovider (ontwikkelaar).

Als dat eenmaal is gebeurd, doe dan een stapje extra om over uw werk te vertellen. U kunt een artikel voor uw site schrijven of erover praten tijdens een bijeenkomst (communicatie). Laat zien wat je in de gegevens hebt gevonden via betekenisvolle visuals en tabellen (gegevensanalyse). Deel je werk op GitHub. Learning en in het openbaar werken is een geweldige manier om feedback te krijgen en potentiële medewerkers te vinden.

Doe vrijwilligerswerk via groepen zoals DataKind. DataKind werkt samen met maatschappelijke organisaties (bijv. NGO's) en dataprofessionals om humanitaire problemen aan te pakken. Door samen te werken met deze ngo's, krijg je de kans om als onderdeel van een team echte problemen aan te pakken met echt (rommelige) data.

Hoewel vrijwilligers specifieke rollen kunnen krijgen (bijv. PM, DS), bent u altijd welkom om mee te kijken en te observeren. Je zult zien (en leren) hoe PM's samenwerken met NGO's om het probleem te kaderen, oplossingen te definiëren en het team eromheen te organiseren. Je leert van collega-vrijwilligers hoe je met data kunt werken om werkende oplossingen te ontwikkelen. Vrijwilligerswerk doen in hackathon-achtig Dataduiken en op langere termijn DataKorps is een geweldige manier om end-to-end bij te dragen aan het data science-proces.

Word lid van een startup-achtig team. Opmerking: een startup-achtig team is niet hetzelfde als een startup. Er zijn grote organisaties die teams runnen op een startup-achtige manier (bijvoorbeeld teams met twee pizza's) en startups met specialisten. Zoek een gestroomlijnd team waar je wordt aangemoedigd en de kans krijgt om end-to-end te werken.

End-to-end in Stitch Fix en Netflix

Eric Colson van Stitch Fix werd aanvankelijk "gelokt tot een functie-gebaseerde taakverdeling door de aantrekkingskracht van procesefficiënties" (dwz de data science pin fabriek). Maar met vallen en opstaan ​​ontdekte hij dat end-to-end datawetenschappers effectiever waren. In plaats van datateams te organiseren voor specialisatie en productiviteit, organiseert Stitch Fix ze voor leren en ontwikkelen van nieuwe data en algoritmische producten.

Het doel van data science is niet om uit te voeren. Het doel is eerder om te leren en nieuwe zakelijke capaciteiten te ontwikkelen. … Er zijn geen blauwdrukken; dit zijn nieuwe mogelijkheden met inherente onzekerheid. ... Alle elementen die je nodig hebt, moeten worden geleerd door middel van experimenteren, vallen en opstaan ​​en iteratie. - Eric Colson

Hij suggereert dat datawetenschapsrollen algemener moeten worden gemaakt, met brede verantwoordelijkheden die losstaan ​​van technische functies en geoptimaliseerd voor leren. Daarom neemt zijn team generalisten aan die kunnen conceptualiseren, modelleren, implementeren en meten. Dit is natuurlijk afhankelijk van een solide dataplatform dat de complexiteit van infra-instellingen, gedistribueerde verwerking, monitoring, geautomatiseerde failover, enz.

Het hebben van end-to-end datawetenschappers hebben de leer- en innovatiemogelijkheden van Stitch Fix verbeterd, waardoor ze meer zakelijke mogelijkheden kunnen ontdekken en opbouwen (in vergelijking met een gespecialiseerd team).

Netflix Edge Engineering had aanvankelijk gespecialiseerde rollen. Dit veroorzaakte echter inefficiënties gedurende de levenscyclus van het product. Het vrijgeven van code kostte meer tijd (weken in plaats van dagen), implementatieproblemen duurden langer om te detecteren en op te lossen, en productieproblemen vereisten meerdere heen-en-weercommunicatie.

In het uiterste geval is elk functiegebied / product eigendom van 7 personen ((bron)).

Om dit aan te pakken, experimenteerden ze met Full Cycle-ontwikkelaars die in staat waren om gedurende de hele levenscyclus van de software te werken. Dit vereiste een mentaliteitsverandering - in plaats van alleen te kijken naar ontwerp en ontwikkeling, moesten ontwikkelaars ook rekening houden met implementatie en betrouwbaarheid.

In plaats van meerdere rollen en mensen hebben we nu de volledige cyclusontwikkelaar ((bron)).

Om ontwikkelaars van een volledige cyclus te ondersteunen, hebben gecentraliseerde teams tooling gebouwd om algemene ontwikkelingsprocessen te automatiseren en te vereenvoudigen (bijv. Bouwen en implementeren van pijplijnen, monitoring, beheerde rollbacks). Dergelijke tooling is herbruikbaar voor meerdere teams, fungeert als een krachtvermenigvuldiger en hielp ontwikkelaars om gedurende de hele cyclus effectief te zijn.

Met de volledige ontwikkelaarsaanpak kon Edge Engineering sneller itereren (in plaats van tussen teams te coördineren), met snellere en meer routinematige implementaties.

Werkte het voor mij? Hier zijn een paar voorbeelden

Bij IBM zat ik in een team dat jobaanbevelingen voor personeel opstelde. Het runnen van de hele pijpleiding duurde erg lang. Ik dacht dat we de tijd konden halveren door de datavoorbereiding en feature engineering pipelines naar de database te verplaatsen. Maar de databaseman had geen tijd om dit te testen. Omdat ik ongeduldig was, heb ik een aantal benchmarks uitgevoerd en de totale looptijd met 90% verminderd. Hierdoor konden we 10x sneller experimenteren en besparen op rekenkosten in de productie.

Tijdens het bouwen van het classificatiesysteem van Lazada vond ik Spark nodig voor datapijplijnen (vanwege het grote datavolume). Ons cluster ondersteunde echter alleen de Scala API, waar ik niet bekend mee was. Omdat ik niet wilde wachten (op ondersteuning voor data engineering), koos ik voor de snellere - maar pijnlijke - route om Scala Spark uit te zoeken en de pijpleidingen zelf te schrijven. Dit heeft de ontwikkelingstijd waarschijnlijk gehalveerd en gaf me een beter begrip van de gegevens om een ​​beter model te bouwen.

Na een succesvolle A / B-test ontdekten we dat belanghebbenden uit het bedrijfsleven het model niet vertrouwden. Als gevolg hiervan kozen ze handmatig topproducten om weer te geven, waardoor online statistieken (bijv. CTR, conversie) afnamen. Om meer te begrijpen, maakte ik uitstapjes naar onze markten (bijv. Indonesië, Vietnam). Door wederzijds onderwijs waren we in staat om hun zorgen weg te nemen, de hoeveelheid handmatig overschrijven te verminderen en de winst te oogsten.

In de bovenstaande voorbeelden, Door het reguliere DS & ML-takenpakket te verlaten, werd sneller meer waarde geleverd. In het laatste voorbeeld was het nodig om onze inspanningen op het gebied van datawetenschap te deblokkeren.

Probeer het

U bent nu misschien niet end-to-end. Dat is oké, maar weinig mensen zijn dat. Overweeg echter de voordelen ervan en strek u er dichter naar toe.

Welke aspecten zouden uw prestatievermogen als datawetenschapper onevenredig verbeteren? Meer betrokkenheid bij klanten en belanghebbenden om meer holistische, innovatieve oplossingen te ontwerpen? Uw eigen datapijplijnen bouwen en orkestreren? Meer bewustzijn van engineering- en productbeperkingen voor snellere integratie en implementaties?

Onpopulaire visie: datawetenschappers zouden meer end-to-end moeten zijn.

Hoewel dit wordt afgekeurd (te generalistisch!), Heb ik gezien dat het leidde tot meer context, snellere iteratie, meer innovatie - meer waarde, sneller.

Meer details en de ervaring van Stitch Fix en Netflix 👇 https://t.co/aOBjuBSsSz

- Eugene Yan (@eugeneyan) 12 Augustus 2020

ORIGINELE. Met toestemming opnieuw gepost.

Bio: Eugène Yan (@eugeneyan) werkt op het snijvlak van consumentendata en technologie om machine learning-systemen te bouwen die klanten helpen. Eugene schrijft ook over hoe je effectief kunt zijn in data science, leren en carrière. Momenteel is Eugene een Applied Scientist bij Amazon en helpt hij gebruikers meer te lezen en meer uit lezen te halen.

Zie ook:

• Wat is er nodig om een ​​succesvolle datawetenschapper te zijn?
• Dit is wat ik heb geleerd in twee jaar als datawetenschapper
• Machine Learning Engineer vs Data Scientist (Is Data Science voorbij?)