Industrieel machinaal leren: 10 ontwerpprincipes
Tegenwoordig worden er elke dag nieuwe diensten, applicaties en andere belangrijke programma's gemaakt die het mogelijk maken om ongelooflijke dingen te creëren: van software voor het besturen van een SpaceX-raket tot interactie met een waterkoker in de volgende kamer via een smartphone.
En soms komt elke beginnende programmeur, of hij nu een gepassioneerde startup is of een gewone Full Stack of Data Scientist, vroeg of laat tot het besef dat er bepaalde regels zijn voor het programmeren en maken van software die het leven enorm vereenvoudigen.
In dit artikel zal ik kort 10 principes beschrijven voor het programmeren van industrieel machine learning, zodat het eenvoudig kan worden geïntegreerd in een applicatie/dienst, gebaseerd op de 12-factor App-methodologie. . Mijn initiatief is om het bewustzijn van deze techniek te vergroten, wat veel ontwikkelaars en datawetenschappers kan helpen.
Dit artikel is een proloog op een reeks artikelen over industrieel Machine Learning. Daarin zal ik verder praten over hoe je daadwerkelijk een model kunt maken en in productie kunt nemen, er een API voor kunt maken, evenals voorbeelden uit verschillende gebieden en bedrijven die ML in hun systemen hebben ingebouwd.
Principe 1: Eén codebasis
Sommige programmeurs in de beginfase vergeten Git uit luiheid om het uit te zoeken (of om een of andere reden die zij zelf hebben). Ofwel vergeten ze het woord helemaal, dat wil zeggen, ze gooien bestanden naar elkaar in de drive/gooien gewoon tekst/versturen per post, of ze denken niet na over hun workflow, en committeren ze allemaal aan hun eigen branch, en dan aan de meester.
Dit principe luidt: hebben één codebase en veel implementaties.
Git kan zowel in de productie als in onderzoek en ontwikkeling (R&D) worden gebruikt, waarin het niet zo vaak wordt gebruikt.
In de R&D-fase kun je bijvoorbeeld commits laten staan met verschillende dataverwerkingsmethoden en -modellen, om vervolgens de beste te selecteren en daar eenvoudig verder mee te werken.
Ten tweede is dit in de productie iets onvervangbaars: je zult voortdurend moeten kijken hoe je code verandert en weten welk model de beste resultaten opleverde, welke code uiteindelijk werkte en wat er gebeurde waardoor het niet meer werkte of onjuiste resultaten begon te produceren. . Daar zijn commits voor!
U kunt ook een pakket van uw project maken, dit bijvoorbeeld op Gemfury plaatsen en er vervolgens eenvoudigweg functies uit importeren voor andere projecten, zodat u ze niet 1000 keer hoeft te herschrijven, maar daarover later meer.
Principe 2: Maak duidelijk afhankelijkheden bekend en isoleer ze
Elk project heeft verschillende bibliotheken die je van buitenaf importeert om ze ergens toe te passen. Of het nu gaat om Python-bibliotheken, of bibliotheken van andere talen voor verschillende doeleinden, of systeemtools - uw taak is:
- Declareer afhankelijkheden duidelijk, dat wil zeggen een bestand dat alle bibliotheken, tools en hun versies bevat die in uw project worden gebruikt en die moeten worden geïnstalleerd (in Python kan dit bijvoorbeeld worden gedaan met Pipfile of require.txt). link die het goed maakt om te begrijpen: )
- Isoleer afhankelijkheden specifiek voor uw programma tijdens de ontwikkeling. Wil je niet voortdurend van versie wisselen en bijvoorbeeld Tensorflow opnieuw installeren?
Op deze manier kunnen ontwikkelaars die zich in de toekomst bij uw team voegen snel vertrouwd raken met de bibliotheken en hun versies die in uw project worden gebruikt, en krijgt u ook de mogelijkheid om de versies en bibliotheken zelf te beheren die voor een specifiek project zijn geïnstalleerd. project, waarmee u incompatibiliteit van bibliotheken of hun versies kunt voorkomen.
Uw toepassing mag ook niet afhankelijk zijn van systeemtools die mogelijk op een specifiek besturingssysteem zijn geïnstalleerd. Deze tools moeten ook worden gedeclareerd in het dependencies-manifest. Dit is nodig om situaties te voorkomen waarin de versie van de tools (en ook hun beschikbaarheid) niet overeenkomt met de systeemtools van een bepaald besturingssysteem.
Dus zelfs als curl op bijna alle computers kan worden gebruikt, moet u het nog steeds in afhankelijkheden declareren, omdat het bij het migreren naar een ander platform er mogelijk niet is of de versie niet de versie zal zijn die u oorspronkelijk nodig had.
Uw vereisten.txt kan er bijvoorbeeld als volgt uitzien:
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
Principe 3: Configuraties
Velen hebben verhalen gehoord over verschillende ontwikkelaars die per ongeluk code naar GitHub uploadden naar openbare opslagplaatsen met wachtwoorden en andere sleutels van AWS, en de volgende dag wakker werden met een schuld van €6000, of zelfs €50000.
Natuurlijk zijn deze gevallen extreem, maar zeer significant. Als u uw inloggegevens of andere gegevens die nodig zijn voor de configuratie in de code opslaat, maakt u een fout, en ik denk dat het niet nodig is uit te leggen waarom.
Een alternatief hiervoor is het opslaan van configuraties in omgevingsvariabelen. U kunt meer lezen over omgevingsvariabelen .
Voorbeelden van gegevens die doorgaans worden opgeslagen in omgevingsvariabelen:
- Domeinnamen
- API-URL's/URI's
- Publieke en private sleutels
- Contacten (e-mail, telefoons, enz.)
Op deze manier hoeft u de code niet voortdurend te wijzigen als uw configuratievariabelen veranderen. Dit zal u helpen tijd, moeite en geld te besparen.
Als u bijvoorbeeld de Kaggle API gebruikt om tests uit te voeren (bijvoorbeeld door de software te downloaden en het model er doorheen te laten lopen om tijdens het uitvoeren te testen of het model goed werkt), dan moeten privésleutels van Kaggle, zoals KAGGLE_USERNAME en KAGGLE_KEY, opgeslagen in omgevingsvariabelen.
Principe 4: Diensten van derden
Het idee hier is om het programma zo te maken dat er qua code geen verschil is tussen lokale bronnen en bronnen van derden. U kunt bijvoorbeeld zowel lokale MySQL als die van derden verbinden. Hetzelfde geldt voor verschillende API's zoals Google Maps of Twitter API.
Om een service van derden uit te schakelen of een andere aan te sluiten, hoeft u alleen maar de sleutels in de configuratie in de omgevingsvariabelen te wijzigen, waarover ik in de bovenstaande paragraaf sprak.
Dus in plaats van elke keer het pad naar bestanden met datasets in de code op te geven, is het dus beter om de pathlib-bibliotheek te gebruiken en het pad naar de datasets in config.py te declareren, zodat ongeacht welke service u gebruikt (voor CircleCI), kon het programma het pad naar de datasets achterhalen, rekening houdend met de structuur van het nieuwe bestandssysteem in de nieuwe service.
Principe 5. Bouwen, vrijgeven, runtime
Veel mensen in Data Science vinden het nuttig om hun schrijfvaardigheden voor software te verbeteren. Als we willen dat ons programma zo min mogelijk crasht en zo lang mogelijk zonder fouten werkt, moeten we het proces van het uitbrengen van een nieuwe versie in 3 fasen verdelen:
- Stadium assemblages. Je bare code transformeer je met losse middelen tot een zogenaamd pakket dat alle benodigde code en data bevat. Dit pakket wordt een assembly genoemd.
- Stadium vrijlating — hier verbinden we onze configuratie met de assembly, zonder welke we ons programma niet zouden kunnen vrijgeven. Dit is nu een volledig kant-en-klare release.
- Vervolgens komt het podium vervulling. Hier geven we de applicatie vrij door de noodzakelijke processen uit onze release uit te voeren.
Met een dergelijk systeem voor het vrijgeven van nieuwe versies van een model of de gehele pijplijn kunt u rollen scheiden tussen beheerders en ontwikkelaars, kunt u versies volgen en wordt ongewenste stopzetting van het programma voorkomen.
Voor de releasetaak zijn veel verschillende services gemaakt waarin je processen kunt schrijven om zelf uit te voeren in een .yml-bestand (in CircleCI is dit bijvoorbeeld config.yml om het proces zelf te ondersteunen). Wheely is geweldig in het maken van pakketten voor projecten.
U kunt pakketten maken met verschillende versies van uw machine learning-model, deze vervolgens verpakken en verwijzen naar de benodigde pakketten en hun versies om de functies te gebruiken die u van daaruit hebt geschreven. Dit helpt u bij het maken van een API voor uw model en uw pakket kan bijvoorbeeld op Gemfury worden gehost.
Principe 6. Voer uw model uit als een of meer processen
Bovendien mogen processen geen gedeelde gegevens bevatten. Dat wil zeggen dat processen afzonderlijk moeten bestaan en dat alle soorten gegevens afzonderlijk moeten bestaan, bijvoorbeeld op services van derden zoals MySQL of andere, afhankelijk van wat u nodig heeft.
Dat wil zeggen dat het zeker niet de moeite waard is om gegevens op te slaan in het procesbestandssysteem, anders kan dit leiden tot het wissen van deze gegevens tijdens de volgende release/wijziging van configuraties of overdracht van het systeem waarop het programma draait.
Maar er is een uitzondering: voor machine learning-projecten kunt u een cache met bibliotheken opslaan, zodat u deze niet telkens opnieuw hoeft te installeren wanneer u een nieuwe versie start, als er geen extra bibliotheken zijn of als er wijzigingen in hun versies zijn aangebracht. Op deze manier verkort u de tijd die nodig is om uw model in de industrie te lanceren.
Om het model als meerdere processen uit te voeren, kunt u een .yml-bestand maken waarin u de benodigde processen en hun volgorde specificeert.
Principe 7: Recycleerbaarheid
De processen die in uw modelapplicatie worden uitgevoerd, moeten eenvoudig te starten en te stoppen zijn. Hierdoor kunt u snel codewijzigingen en configuratiewijzigingen implementeren, snel en flexibel schalen en mogelijke storingen van de werkende versie voorkomen.
Dat wil zeggen dat uw proces met het model:
- Minimaliseer de opstarttijd. Idealiter bedraagt de opstarttijd (vanaf het moment dat het opstartcommando wordt gegeven tot het moment dat het proces in werking treedt) niet meer dan enkele seconden. Bibliotheekcaching, zoals hierboven beschreven, is één techniek om de opstarttijd te verkorten.
- Sluit correct af. Dat wil zeggen dat het luisteren op de servicepoort feitelijk wordt opgeschort en dat nieuwe verzoeken die naar deze poort worden verzonden, niet worden verwerkt. Hier moet je óf een goede communicatie met DevOps-engineers opzetten, óf zelf begrijpen hoe het werkt (het liefst natuurlijk dat laatste, maar de communicatie moet altijd onderhouden worden, in welk project dan ook!)
Principe 8: Continue implementatie/integratie
Veel bedrijven hanteren een scheiding tussen de applicatieontwikkelings- en deploymentteams (het beschikbaar maken van de applicatie voor eindgebruikers). Dit kan de ontwikkeling van software en de voortgang bij het verbeteren ervan aanzienlijk vertragen. Het bederft ook de DevOps-cultuur, waarin ontwikkeling en integratie grofweg worden gecombineerd.
Dit principe stelt daarom dat uw ontwikkelomgeving zo dicht mogelijk bij uw productieomgeving moet liggen.
Dit zal toestaan:
- Verkort de releasetijd met tientallen keren
- Verminder het aantal fouten als gevolg van code-incompatibiliteit.
- Dit vermindert ook de werkdruk voor het personeel, omdat ontwikkelaars en mensen die de applicatie implementeren nu één team vormen.
Tools waarmee je hiermee kunt werken zijn CircleCI, Travis CI, GitLab CI en anderen.
Je kunt het model snel aanvullen, updaten en direct starten, terwijl je bij eventuele storingen heel snel terug kunt keren naar de werkende versie, zodat de eindgebruiker er niets van merkt. Dit kan vooral gemakkelijk en snel worden gedaan als u over goede tests beschikt.
Minimaliseer verschillen!!!
Principe 9. Uw logbestanden
Logboeken (of “Logboeken”) zijn gebeurtenissen, meestal vastgelegd in tekstformaat, die plaatsvinden binnen de applicatie (gebeurtenisstroom). Een eenvoudig voorbeeld: "2020-02-02 - systeemniveau - procesnaam." Ze zijn zo ontworpen dat de ontwikkelaar letterlijk kan zien wat er gebeurt als het programma draait. Hij ziet de voortgang van processen en begrijpt of het is zoals de ontwikkelaar het zelf bedoeld heeft.
Dit principe houdt in dat u uw logbestanden niet in uw bestandssysteem moet opslaan; u moet ze gewoon naar het scherm 'uitvoeren', bijvoorbeeld via de standaarduitvoer van het systeem. En op deze manier wordt het mogelijk om tijdens de ontwikkeling de flow in de terminal te monitoren.
Betekent dit dat het helemaal niet nodig is om logs op te slaan? Natuurlijk niet. Uw applicatie zou dit gewoon niet moeten doen; laat het over aan diensten van derden. Uw toepassing kan logboeken alleen doorsturen naar een specifiek bestand of terminal voor realtime weergave, of doorsturen naar een gegevensopslagsysteem voor algemene doeleinden (zoals Hadoop). Uw toepassing zelf mag geen logboeken opslaan of er interactie mee hebben.
Principe 10. Testen!
Voor industriële machine learning is deze fase uiterst belangrijk, omdat je moet begrijpen dat het model correct werkt en produceert wat je wilde.
Tests kunnen worden gemaakt met behulp van pytest en worden getest met behulp van een kleine gegevensset als u een regressie-/classificatietaak hebt.
Vergeet niet hetzelfde uitgangspunt voor deep learning-modellen in te stellen, zodat ze niet voortdurend verschillende resultaten opleveren.
Dit was een korte beschrijving van de 10 principes, en het is natuurlijk moeilijk om ze te gebruiken zonder te proberen en te zien hoe ze werken, dus dit artikel is slechts een proloog van een reeks interessante artikelen waarin ik zal onthullen hoe je industriële machine learning-modellen, hoe deze in systemen te integreren en hoe deze principes het leven voor ons allemaal gemakkelijker kunnen maken.
Ik zal ook proberen coole principes te gebruiken die iedereen in de reacties kan achterlaten als hij dat wil.
Bron: www.habr.com