By Aaron Söllinger & Will Kunzo

Bij het ontwerpen van de MLOps-stack voor ons project hadden we een oplossing nodig die een hoge mate van maatwerk en flexibiliteit mogelijk maakte om te evolueren naarmate onze experimenten dicteerden. We hebben grote platforms overwogen die veel functies omvatten, maar vonden het op een aantal belangrijke gebieden beperkend. Uiteindelijk hebben we gekozen voor een aanpak waarbij afzonderlijke gespecialiseerde tools werden geïmplementeerd voor labeling, gegevensversiebeheer en continue integratie. Dit artikel documenteert onze ervaring met het bouwen van deze aangepaste MLOps-aanpak.

Foto door Dan vinden | Dan Grinwis on Unsplash

NBDEV

(Genomen van https://github.com/fastai/nbdev)

Het klassieke probleem bij het gebruik van Jupyter voor ontwikkeling was om van prototype naar productie te gaan en code te kopiëren en plakken van een notebook naar een python-module. NBDEV automatiseert de overgang tussen notebook en module, waardoor de Jupyter-notebook een officieel onderdeel van een productiepijplijn kan worden. Met NBDEV kan de ontwikkelaar aangeven welke module een notebook moet maken, welke notebookcellen naar de module moeten worden gepusht en welke notebookcellen worden getest. Een belangrijk vermogen van NBDEV is de benadering van testen binnen de notebooks, en de NBDEV-sjabloon biedt zelfs een basis Github-actie om testen in het CI/CD-framework te implementeren. De resulterende Python-module vereist geen bewerking door de ontwikkelaar en kan eenvoudig worden geïntegreerd in andere notebooks of het project in het algemeen met behulp van ingebouwde python-importfunctionaliteit.

Iteratief.ai: DVC/CML

(Genomen van https://iterative.ai/)

De bestanden die in machine learning-pijplijnen worden gebruikt, zijn vaak grote archieven van binaire/gecomprimeerde bestanden, die niet toegankelijk of onbetaalbaar zijn voor bestaande versiebeheeroplossingen zoals git. DVC lost gegevensversiebeheer op door grote datasets weer te geven als een hash van de bestandsinhoud, waardoor DVC wijzigingen kan volgen. Het werkt vergelijkbaar met git (bijv dvc add, dvc push). Wanneer je rent dvc add op uw dataset, wordt deze toegevoegd aan de .gitignore en bijgehouden voor wijzigingen door dvc. CML is een project dat functionaliteit biedt voor het publiceren van modelartefacten uit Github Actions-workflows in bijgevoegde opmerkingen Github-problemen, pull-verzoeken, enz. nauwkeurigheid en effectiviteit van het model.

Github-acties

(Genomen van https://github.com/features/actions)

We willen geautomatiseerde codetests, inclusief het bouwen van modellen in de geautomatiseerde testpijplijn. Github Actions concurreert met CircleCI, Travis, Jenkins, dat het testen van code pushes, commits, pull-verzoeken, enz. automatiseert. Aangezien we Github al gebruiken om onze repo's te hosten, vermijden we een andere app van derden door Actions te gebruiken. In dit project moeten we door Github zelf gehoste runners gebruiken om taken uit te voeren op een on-prem GPU-cluster.

Labelstudio

(Genomen van https://labelstud.io/)

We hebben een diepe duik genomen in hoe we Label Studio gebruiken gevonden hier. Label Studio is een oplossing voor het labelen van data. Het werkt goed en is flexibel om in verschillende omgevingen te draaien.

Waarom ze samen gebruiken?

 
 
De setup is ontworpen om modellen sneller te implementeren. Dat betekent dat meer datawetenschappers harmonieus parallel werken, transparantie in de repository en snellere inwerktijd voor nieuwe mensen. Het doel is om de soorten activiteiten die datawetenschappers in projecten moeten uitvoeren te standaardiseren en duidelijke instructies te geven.

Het volgende is een lijst met taken die we willen stroomlijnen met dit systeemontwerp:

1. Automatiseer de opname vanuit Label Studio en zorg voor één enkel punt voor de opname ervan in de modeltraining- en evaluatieactiviteiten.
2. Geautomatiseerd testen op de datapijplijncode, dat wil zeggen het testen van eenheden en het opnieuw inzetten van containers die door het proces worden gebruikt.
3. Geautomatiseerd testen op de modelcode, dat wil zeggen het testen van eenheden en het opnieuw inzetten van containers die door het proces worden gebruikt.
4. Schakel geautomatiseerd testen in om modelhertraining en evaluatiecriteria op te nemen. Wanneer de modelcode verandert, traint u een model met de nieuwe code en vergelijkt u deze met het bestaande bestaande model.
5. Activeer modelhertraining wanneer trainingsgegevens worden gewijzigd.

Hieronder vindt u de beschrijving van de pijplijn voor elke taak.

Traditionele CI/CD-pijplijn

 
 
Deze pijplijn implementeert geautomatiseerde testfeedback voor elk pull-verzoek, inclusief evaluatie van syntaxis, eenheids-, regressie- en integratietests. Het resultaat van dit proces is een functioneel getest docker-image naar onze private repository. Dit proces maximaliseert de kans dat de nieuwste beste code zich in een volledig geteste afbeelding bevindt die beschikbaar is in de repository voor downstream-taken. Zo werkt de levenscyclus van de ontwikkelaar in de context van een nieuwe functie:

Hier laten we zien hoe de workflow functioneert tijdens het bewerken van de code. Door NBDEV te gebruiken, kunnen we rechtstreeks vanuit de Jupyter-notebooks werken, inclusief het rechtstreeks schrijven van de tests in de notebook. NBDEV vereist dat alle cellen in de notebooks zonder uitzondering worden uitgevoerd (tenzij de cel is gemarkeerd om niet te worden uitgevoerd). (Afbeelding door auteur)

Gegevenspijplijn

 
 
Label Studio heeft momenteel geen event hooks die updates mogelijk maken bij wijzigingen in de opgeslagen labelgegevens. Dus we nemen een cron getriggerde aanpak, waarbij de dataset elk uur wordt bijgewerkt. Bovendien, hoewel de trainingsdataset van labelstudio klein genoeg is, kunnen de updates ook worden gedaan als onderdeel van de trainingspijplijn. We hebben de mogelijkheid om de vernieuwing van de gegevenspijplijn op aanvraag te activeren met behulp van de Github Actions-interface.

De datapijplijn wordt gevoed vanuit Label Studio en bewaart elke versie van de dataset en relevante invoer naar de DVC-cache die is opgeslagen in AWS S3. (Afbeelding door auteur)

Modelpijpleiding

 
 
De modelleringspijplijn integreert modeltraining in de CI/CD-pijplijn voor de repository. Hierdoor kan elk pull-verzoek de syntaxis-, eenheids-, integratie- en regressietests evalueren die op de codebase zijn geconfigureerd, maar kan ook feedback worden gegeven, waaronder het evalueren van het nieuwe resulterende model

De workflow voert in dit geval het modeltrainingsexperiment uit dat is opgegeven in het configuratiebestand (model_params.yaml) en werkt het modelartefact (best-model.pth) bij (afbeelding door auteur)

Benchmark-evaluatiepijplijn

 
 
De benchmarking-pijplijn vormt een "officieel indieningsproces" om ervoor te zorgen dat alle modelleringsactiviteiten worden gemeten aan de hand van de statistieken van het project.

Het nieuw getrainde model in best-model.pth wordt geëvalueerd ten opzichte van de benchmark-dataset en de resultaten worden getagd met de laatste commit-hash en bewaard in AWS S3. (Afbeelding door auteur)

Workflow

 
 
Hier is het DAG-definitiebestand dat door DVC wordt gebruikt. Het legt de workflowstappen en hun invoer vast en zorgt voor reproduceerbaarheid tussen gebruikers en machines.

stages: labelstudio_export_trad: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/traditional_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/traditional_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_trad: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_traditional.yaml --proj_root "." deps: - data/raw_labels/traditional.json params: - pipelines/create_traditional.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir train_model_trad: cmd: python pipelines/3_train_model.py --config_fp pipelines/model_params.yaml --proj_root "." deps: - data/traditional_labeling params: - pipelines/model_params.yaml: - dataloader.bs - dataloader.size - dataloader.train_fp - dataloader.valid_fp - learner.backbone - learner.data_dir - learner.in_checkpoint - learner.metrics - learner.n_out - learner.wandb_project_name - train.cycles labelstudio_export_bench: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/benchmark_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/benchmark_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_bench: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_benchmark.yaml --proj_root "." deps: - data/raw_labels/benchmark.json params: - pipelines/create_benchmark.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir eval_model_trad: cmd: python pipelines/4_eval_model.py --config_fp pipelines/bench_eval.yaml --proj_root "." deps: - data/models/best-model.pth params: - pipelines/bench_eval.yaml: - eval.bench_fp - eval.label_config - eval.metrics_fp - eval.model_conf - eval.overlay_dir

Bevindingen

1. De Github Actions-workflow cron trigger is niet extreem betrouwbaar. Het garandeert geen timing.
2. DVC werkt niet op een duidelijke manier binnen een Github Action-workflow die wordt geactiveerd bij push. Het zal de trackers wijzigen die door de bron worden beheerd en wanneer dat is vastgelegd, zal het een nieuwe Github-actie creëren.
3. De orkestratie van Github-acties als een mechanisme om het model uit te voeren, vereist een zelf-gehoste runner om een ​​GPU te gebruiken. Dit betekent verbinding maken met een GPU-instantie in de cloud of op locatie, en dit levert problemen op met toegangscontrole. We kunnen bijvoorbeeld de exacte repo niet openen zonder die zelf-gehoste runner-configuratie uit de repo te verwijderen, anders zouden willekeurige mensen workloads op onze trainingsserver kunnen uitvoeren door code naar het project te pushen.
4. De ingebouwde workflow van NBDEV test de code op de verkeerde plaats. Het test de notebook in plaats van het gecompileerde pakket. Aan de ene kant is het fijn om te kunnen zeggen dat de “tests zo in het schrift kunnen worden geschreven”. Aan de andere kant laat het rechtstreeks testen van de notebooks de mogelijkheid open dat het codepakket dat door NBDEV is gemaakt, faalt, ook al liep de notebook. Wat we nodig hebben, is de mogelijkheid om het door NBDEV gecompileerde pakket rechtstreeks te testen
5. NBDEV werkt niet samen met "traditionele" Python-ontwikkeling in de zin dat NBDEV eenrichtingsverkeer is. Hiermee kan het project eenvoudig worden ontwikkeld in de interactieve Jupyter-notebookstijl. Het maakt het onmogelijk om de Python-modules direct te ontwikkelen. Als het project op enig moment wil worden geconverteerd naar "traditionele" Python-ontwikkelingstests, moet dit op een andere manier worden uitgevoerd.
6. In het begin gebruikten we Weights & Biases als ons dashboard voor het volgen van experimenten, maar er waren problemen bij het implementeren ervan in een Github-actie. Wat we wel kunnen zeggen is dat de gebruikerservaring voor de implementatie wandb raakte zijn eerste hik in de actieworkflow. Het verwijderen van gewichten en vooroordelen loste het probleem meteen op. Daarvoor, wandb viel op als de beste gebruikerservaring in MLOps.

Conclusies

 
 
Uiteindelijk duurde het een week om de implementatie van deze tools voor het beheer van onze code met Github Actions, Iterative.ai tools (DVC & CML) en NBDEV te voltooien. Dit biedt ons de volgende mogelijkheden:

1. Werk vanuit Jupyter-notebooks als het registratiesysteem voor de code. We houden van Jupiter. De belangrijkste use-case die het bereikt, is om ons in staat te stellen rechtstreeks te werken op alle hardware waar we SSH in kunnen gebruiken door daar een Jupyter-server te hosten en deze door te sturen naar een desktop. Voor alle duidelijkheid, we zouden dit zelfs doen als we NBDev niet zouden gebruiken, omdat het alternatief Vim is of een dergelijke tool die we niet zo leuk vinden. Eerdere experimenten om verbinding te maken met externe servers met VS Code of Pycharm zijn mislukt. Dus het is Jupyter.
2. Het testen van de code en het testen van het model dat het maakt. Als onderdeel van de CI/CD-pijplijn kunnen we nu evalueren of het model dat voortvloeit uit de wijzigingen in de repo het model beter, slechter of hetzelfde maakt. Dit is allemaal beschikbaar in het pull-verzoek voordat het wordt samengevoegd in main.
3. Door de Github Actions-server als orkestrator voor trainingsruns te gebruiken, kunnen meerdere datawetenschappers tegelijkertijd op een duidelijkere manier werken. In de toekomst zullen we de beperkingen van deze opstelling zien voor het orkestreren van het collaboratieve datawetenschapsproces.

 
Aaron Söllinger heeft voorheen als datawetenschapper en software-engineer gewerkt bij het oplossen van problemen op het gebied van financiën, voorspellend onderhoud en sport. Momenteel werkt hij als consultant voor machine learning-systemen bij Hoplabs aan een computervisietoepassing met meerdere camera's.

Will Kunzo is een back-end softwareontwikkelaar, met een can-do-houding en vastberadenheid om uitdagingen aan te gaan. Het maakt niet uit of het gaat om het opsporen van een ongrijpbare bug of het snel aanpassen aan een nieuwe technologie. Als er een oplossing is, wil Will die vinden.

ORIGINELE. Met toestemming opnieuw gepost.

Zie ook:

• MLOps-best practices
• MLOps is een technische discipline: een overzicht voor beginners
• MLOps en stappenplan voor machine learning