Datawetenschappers hebben meestal een andere achtergrond dan software-ingenieurs. Ze zijn niet noodzakelijkerwijs grote programmeurs. In feite is het nooit de bedoeling geweest dat ze dat zouden zijn – voor een kenniswetenschapper is codering gewoon een manier om de huidige puzzel te ontrafelen. En zip meer. In tegenstelling tot softwareontwikkelaars behandelen ze de code niet als een soort kunst. Natuurlijk is hun wijsheid van onschatbare waarde, maar het scala aan vaardigheden dat nodig is om een succesvolle datawetenschapper te zijn is al breed (vooral wanneer de sector zich vaak ontwikkelt met de nieuwe ontdekkingen, waardoor een groot deel van de zuurverdiende kennis dagelijks verouderd is). Te breed. Van een individu dat zeer gespecialiseerd is in computervisie of prescriptieve analyse verwacht je niet dat het ook nog eens een brood-en-botermaker is, die de modellen produceert en ze binnen de zwaar-schaalbare cloudomgeving plaatst. Met behoud van een topkwaliteit, herbruikbare code. Met behulp van functionele programmering. Of reactief. Of beide.

Aan de andere kant zijn software engineers nogal terughoudend als het gaat om machinaal leren. Het hele concept is nogal raar vanuit hun perspectief, vooral wanneer het merendeel van de zogenaamde modellen die hun data science team maakt korte, hacky scripts zijn met vreemde methode-aanroepen en onleesbare code in onbekende taal. Waar zijn alle planningspatronen? Waar is dat de schone code? Waar is de logging of monitoring? Waarom is die code niet herbruikbaar? Zou de code die zo’n chique probleem oplost niet vrij lang moeten zijn? het is een echt lelijk script dat slechts één persoon kan begrijpen! Is het nog wel te programmeren?

De fusie.

Met het ontstaan van dit conflict werd een vereiste geboren. Een vereiste voor een individu dat twee vechters zou kunnen herenigen. Een die slechts op beide terreinen vloeiend genoeg is om de koopwaar aan te sporen. Iemand die de code van de datawetenschapper neemt en deze eenvoudiger en schaalbaar maakt. Het introduceren van verschillende programmeerregels en goede praktijken. Abstraheren van delen van code die in de toekomst gebruikt kunnen worden. Het samenvoegen van de resultaten van potentieel ongerelateerde taken om de prestaties van de modellen nog meer te versterken. Het uitleggen van de verklaringen achter de architectonische ideeën aan het team van de ontwikkelaars. Het scheiden van softwareontwikkelaars van leerconcepten die veel verder gaan dan hun interessegebieden.

Die behoefte is vervuld met het ontstaan van de rol van machine learning engineer.

Wat altijd ontbreekt in alle artikelen, tutorials en boeken over de ML is dat de productieomgeving. Die bestaat letterlijk niet. Data wordt geladen vanuit CSV’s, modellen worden gemaakt in Jupyter, ROC-curves worden getekend en voilà – uw machine learning product is up and running. Tijd voor een extra ronde van zaadfinanciering!

Wacht even.

 

https://miro.medium.com/max/977/1*X5ZGVbZwkJkPfcH0h2BQQw.png

In werkelijkheid is het grootste deel van uw code niet gebonden aan machinaal leren. In feite kost de code betreffende het altijd maar een paar procent van uw hele codebase! Uw voorbewerkte recorder geeft alleen het kleine JSON antwoord – er zijn duizenden regels code nodig om daarop te kunnen reageren. Of zelfs alles wat u krijgt kan een gegenereerde database tabel met inzichten zijn. Nogmaals, een heel systeem moet er bovenop gebouwd worden om het nuttig te vormen! Je moet de info aansporen, transformeren en mungen, je jobs automatiseren, de inzichten ergens aan de topgebruiker presenteren. Ongeacht hoe klein de zaak ook is, de hoeveelheid werk die gedaan moet worden om de machine te leren is enorm, hoewel je je project opstart met technologieën zoals Apache Airflow of NiFi.

Toch moet iemand alle “data science” en “software” onderdelen aan elkaar lijmen. Neem het getrainde model en laat het werken aan een kwaliteitsvolle productieomgeving. Plan batchjobs die inzichtstabellen herberekenen. Serveer het model in real time en controleer de prestaties in de vrije natuur. En dit is vaak het precieze gebied waarin de machine-lerende ingenieur schittert.

Bij het maken van software proberen ontwikkelaars natuurlijk alle mogelijke uitkomsten te vinden in elk onderdeel van de applicatie. Wat je van een kenniswetenschapper krijgt is gewoon een vrolijk pad dat resulteert in het maken van modellen voor de werkelijke gegevens op het werkelijke moment in de tijd. Tenzij het een eenmalige specifieke analyse is, zal het model na de productie nog geruime tijd blijven bestaan. En omdat de tijd vliegt, duiken de bugs en alle angelgevallen op (veel van hen waren niet eens mogelijk toen de code werd geschreven). Plotseling verschijnt er een vervangende onbekende waarde in één van de kolommen en daardoor begint het hele model veel slechter te presteren.

Als machine learning engineer bereidt u uw applicaties voor op dergelijke gebeurtenissen. U zorgt voor het loggen en monitoren van de pijpleidingen, niet alleen rond de machine leertaken, maar ook daarbinnen. U probeert alle kennis te behouden zodat het mogelijk is om een echt belangrijke vraag te beantwoorden: wat is de verklaring voor de slechte prestaties van het model? Sinds wanneer gebeurt dat?

Het is gewoon een andere API

https://miro.medium.com/max/1824/1*QLI2IgsNlRhDZ-oWmIO5Iw.png

Omdat je ML niet als magie behandelt, ben je je bewust van alle andere typische programmeergevaren die zich voordoen bij het uitvoeren van een machinale leeropdracht. Database zou de verbinding kunnen weigeren. GroupBy kan vergroten voor een gigantische dataset. Het geheugen of de schijf is vaak vol. Combinatie van parameters die door de gebruiker zijn opgegeven kan illegaal zijn, zeker als het gaat om een algoritme. Externe service zou kunnen reageren met Timeout Exception in plaats van referenties. Kolom zou niet meer kunnen bestaan. Hoewel niemand een oogje dichtknijpt als dergelijke gebeurtenissen zich voordoen tijdens een veilige labomgeving op een dag, is het uw verantwoordelijkheid om ervoor te zorgen dat ze niet gebeuren als het topproduct echt wordt afgeleverd.

Uw datawetenschappelijk team zit meestal vol met ideeën. Je moet er zeker van zijn dat geen enkele technologie ze beperkt. Bijna net zo goed en aanpasbaar, want de huidige ML-raamwerken zijn, vroeg of laat zullen uw teamgenoten een intrigerende use case hebben die met geen van hen haalbaar is. Wel, niet met standaard API’s. Maar als je eenmaal hun internals peilt, ze een beetje aanpast en ze mixt in een of twee andere bibliotheken, dan maak je het mogelijk. Je maakt misbruik van de frameworks en gebruikt ze optimaal. Dat vereist zowel uitgebreide kennis van programmeren als van machinaal leren, iets wat vrij uniek is voor jouw rol binnen het team.

En zelfs als het framework alles biedt wat je wilt programmeren, kunnen er nog steeds problemen zijn met het tekort aan rekenkracht. Grote neurale netwerken nemen veel tijd in beslag om te coachen. Deze kostbare tijd kan met een orde van grootte worden verminderd als u GPU-frameworks gebruikt die op krachtige machines draaien. U bent degene die de kansen scout, de voor- en nadelen van gevarieerde cloudopties ziet en de meest geschikte kiest.

U kunt zelfs verantwoordelijk zijn voor het kiezen van andere tools en ecosystemen, waarbij u altijd rekening houdt met de gehele levenscyclus van het project (niet alleen het roekeloze onderzoeksgedeelte) – bijvoorbeeld Azure ML Workbench of IBM Watson kunnen geweldige tools zijn voor het opstarten van het project en het uitvoeren van onderzoek, maar voldoen niet noodzakelijkerwijs aan alle wensen van uw definitieve versie van de goederen wanneer het gaat om aangepaste planning en monitoring.

U moet tot nu toe wakker blijven met de nieuwste technologieën en voortdurend zoeken naar de plaatsen waar de algemene productprestaties kunnen worden verbeterd. Of het nu gaat om een in de strijd geteste programmeertaal , nieuwe technologie binnen de cloud, slimme planning of monitoring systeem – door het zien van uw product op het grotere plaatje en het goed kennen van zowel engineering, business en wetenschap, bent u vaak de enige persoon die de kans heeft om het potentiële gebied van verbetering te identificeren.

Dit betekent vaak dat u de werkende code moet nemen en deze volledig moet herschrijven in een andere technologie en taal. Gelukkig, zodra je “grip” hebt op wat er echt aan de hand is en welke stappen er altijd worden genomen binnen het proces van het leren en produceren van de modellen, besef je dat de meerderheid van die API’s in het geheel niet verschillen. Als je eenmaal tussen verschillende kaders hebt gegoocheld, blijft de overgrote meerderheid van het hele proces een equivalent. Je brengt al het eenvoudigste softwarevakmanschap mee en begint al snel een abstractie te maken over vele repetitieve taken die het datawetenschappelijke team niet kan automatiseren en het softwareontwikkelingsteam is bang om te lijken. een robuuste brug tussen twee werelden. Een solide, robuuste basis voor een werkende software.

Onnoemelijke nadelen

U kunt vrijelijk communiceren met de meest geliefde technologieën binnen het vakgebied. Keras, pyTorch, TensorFlow, H2O, scikit-learn, Apache Spark – kies een reputatie, je zult het waarschijnlijk gebruiken. Apache Kafka! Pulsar! AWS! Elke conferentie die je bijwoont spreekt luidkeels over je technologiestapel, alsof het The Chosen One is geweest. Mensen kijken je jaloers aan, wetende dat jij gewoon de man bent die alle goede dingen gebruikt.

Wat altijd handig weggelaten wordt, is dat het onweerlegbare feit dat die coole dingen ook toevallig niet veel gebruikt worden. En als de technologie nieuw is, is het enige wat je nog over hebt slechte documentatie en een hoop blogberichten. Wat je ziet op de conferenties en tech talks zijn gewoon de gelukkige groene paden (vergelijkbaar met die Jupyter notitieboekjes die je van je DS team krijgt). je erkent dat het niet is hoe software werkt. Herhaaldelijk, na uren van debugging Apache Spark internals, heb ik mijn wil om mijn programmeercarrière in het machinaal leren voort te zetten in twijfel getrokken. Zou ik niet gelukkiger zijn zonder dit alles? Was webontwikkeling echt zo saai?

https://miro.medium.com/max/800/1*nBdPYqVieDtpv47SNQuj7Q.png

Er wordt van je verwacht dat je tonnen concepten begrijpt, zowel in de softwareontwikkeling als in de datawetenschap. Het belangrijkste is dat mensen willen dat je zeer snel nieuwe kennis realiseert. Ik leer tonnen door iemand anders zijn snippets te nemen, ze te veranderen en te breken en te zien wat er gebeurt. Nou, wat als er geen fragmenten zijn? Wat als de stacktrace die je krijgt vrij betekenisloos is en het googelen van de uitzonderingsnaam alleen leidt tot de code bij GitHub het gooien van het?

Het leren en begrijpen van de curve is op sommige gebieden nogal steil, vooral als het gaat om de uitvoering van ideeën die in whitepapers zijn geschreven. Hoe cool (en soms exotisch) deze ook zijn, hun vorm is meestal vrij wetenschappelijk en het zal je een tijdje duren om ze te begrijpen. Dan komt het coderingsgedeelte waar je helemaal alleen bent. alhoewel je applicatie prima samenkomt en niet overal Runtime Exceptions gooit de plaats waar het vaak onduidelijk is hoe je ervoor kunt zorgen dat je implementatie ook echt goed werkt. En als dat niet het geval is, denkt u na over de vraag of uw code een bug bevat, of de gegevens scheef zijn of dat zelfs het hele idee gewoon niet toepasbaar is in uw gebruiksdossier.