De eerste stap van het automatisch hertrainen is het opnieuw trainen van het netwerk. Dit moet gebeuren op het moment dat er andere gegevens beschikbaar zijn. Er wordt gekeken naar de informatie van eerdere modellen, zodat er bepaald kan worden of er een nieuw model getraind moet worden. Deze informatie wordt achterhaald uit het informatiebestand dat aangemaakt is tijdens het trainingsproces. Het bestand (info.csv) is ook te zien in Figuur 15. De structuur van de inhoud van het bestand is te zien in Figuur 26. De informatie die gebruikt wordt om te kijken of een nieuw model getraind moet worden, zijn de major en minor versies en de hoeveelheid training en collected images. Wanneer er nog geen model is met een major en minor versie, wordt er altijd een nieuw model getraind. Wanneer er al wel een model met dezelfde versie is, wordt er enkel getraind wanneer er een verandering in de hoeveelheid data is.
Figuur 26: Structuur model informatie bestand
De tweede stap is het maken van scripts die gebruikt worden voor het ophalen van trainingsdata, het uploaden van een getraind model en het downloaden van getrainde modellen. De functionaliteit van deze scripts is mogelijk door de Github-API. Door middel van de API kunnen taken als het ophalen van gegevens, het downloaden van bestanden en het maken van releases (uploaden van getrainde modellen) gerealiseerd worden.
Figuur 27: Vesalius-Training scripts Figuur 28: Vesalius-Backend script
De scripts voor het downloaden van trainingsdata en modellen gebruiken dezelfde manier om de data op te halen. Het enige verschil tussen het downloaden van modellen en het downloaden van trainingsdata, is dat het downloaden van modellen via tags en releases gebeurt. Het downloaden van trainingsdata gebeurt op basis van specifieke mappen van de Repository (lichtelijk foutgevoelig wanneer deze mappen weggehaald worden). Het proces begint met het ophalen van de data die op de Github-Repository staat. Vervolgens wordt er gekeken naar de data die de applicatie al beschikbaar heeft. Op deze manier wordt achterhaald welke data nog gedownload moet worden. Wanneer er data is die alleen op de Repository staat, zal deze data gedownload worden. Dit is dus alleen de data die nog niet voor de applicatie beschikbaar is. De scripts zijn opgesplitst in een python en een bash bestand. Het bash bestand gebruikt door het python bestand gegeven data voor het ophalen van de juiste gegevens. Hierbij kan gedacht worden aan de nodige token en de Github-Repository. Het python bestand vult deze gegevens in, zodat de taak gemakkelijk uit te voeren is.
De aanvrager moet toegang krijgen tot het downloaden van de data, omdat deze data niet voor iedereen beschikbaar is. Github heeft hier een systeem voor. Door middel van een autorisatietoken kan aan dit systeem toegang gevraagd worden. Dit is te vergelijken met het invullen van een gebruikersnaam en wachtwoord. Er wordt gebruik gemaakt van een Ansible-Vault, omdat het niet veilig is om deze token hardcoded in de code te zetten. Deze ‘Vault’ slaat de token op en encrypt deze met een speciaal wachtwoord. Het resultaat van deze encryptie is te zien in Figuur 29. De token wordt pas beschikbaar op het moment dat de applicatie deployed wordt en het juiste wachtwoord wordt meegegeven.
Figuur 29: Voorbeeld inhoud Ansible-Vault
De laatste stap voor het automatisch hertrainen is het deployen van de Vesalius-training applicatie. Hiervoor is net zoals bij veel andere projecten binnen Nedap gebruik gemaakt van Ansible. Ansible is een tooling waarmee gemakkelijk en overzichtelijk een applicatie deployed kan worden. Dit wordt gedaan door gebruik te maken van de vele taken die Ansible mogelijk maakt.
De eerste stap van het deployen van een applicatie is het kopiëren van relevante bestanden naar de release omgeving (een server van Nedap). Dit kan gedaan worden door gebruik te maken van de copy functionaliteit. Met deze functionaliteit kan worden aangegeven welke bestanden/mappen gekopieerd moeten worden. Daarnaast kan de naam van het bestand/de map en de gewenste locatie meegegeven worden.
De tweede stap is het periodiek uitvoeren van de gemaakte scripts. Op deze manier wordt nieuwe data opgehaald waar een nieuw model mee getraind kan worden. Het gebruik van cronjobs maakt dit periodiek uitvoeren mogelijk. Een cronjob bevat een tijd waarop deze uitgevoerd moet worden en het commando dat uitgevoerd moet worden. In Figuur 31 zijn de gemaakte cronjobs te zien.
Figuur 31: Cronjobs voor de Vesalius-Training applicatie
De eerste cronjob is voor het ophalen van nieuwe trainingsdata van de Github-Repository. De taak wordt elke dag om 00:00 uur uitgevoerd door het gemaakte script uit te voeren. Door de locatie van het decrypted ‘secrets’-bestand mee te geven, kan de autorisatietoken achterhaald worden. Deze token wordt gebruikt in het script om autorisatie te krijgen voor het downloaden van de data. De tweede cronjob is voor het synchroniseren van de verzamelde feedback data van de backend naar de trainingsapplicatie. Hierbij wordt gebruik gemaakt van het rsync commando. Het gebruik van dit commando zorgt ervoor dat de bestanden in twee mappen gesynchroniseerd worden.
De laatste cronjob is voor het starten van het trainingsproces. Hierbij wordt het python bestand gestart dat het trainingsproces bevat. Wanneer dit proces is afgerond, wordt het getrainde model geüpload. Dit wordt gedaan door de release parameter mee te geven aan het commando.
De genoemde scripts worden gestart op de aangegeven tijd na het uitbrengen van een Vesalius- training instantie. Er zal een nieuwe versie van het model getraind en uitgebracht worden op het moment dat er nieuwe data beschikbaar is. In Figuur 32 is te zien dat een nieuw getraind model automatisch uitgebracht wordt.
Figuur 32: Uitgebrachte versies van Vesalius modellen
Op het moment dat er een nieuwe modelversie beschikbaar is, moeten deze alleen nog gedownload worden door de Vesalius-backend instanties. Hiervoor wordt het eerdergenoemde script voor het downloaden van modellen gebruikt. Dit script controleert op dezelfde manier als het downloaden van trainingsafbeeldingen. Er wordt namelijk gekeken of er modellen uitgebracht zijn die nog niet in de backend zijn opgeslagen. Het aanroepen van het script wordt ook gedaan met een cronjob. Deze wordt elk uur uitgevoerd. In Figuur 33 is te zien hoe deze cronjob is toegevoegd aan het deploy script.