Goede testgegevens zijn alles wat u nodig heeft

Een methode voor het optimaliseren van de ROI van datasets & TTM maximaliseren in toegepaste AI

Het bouwen van machine learning (ML) en deep learning (DL) modellen vereist uiteraard veel data als trainingsset en een testset waarop het model wordt getoetst en geëvalueerd. Best practices met betrekking tot het opzetten van treinsets en testsets zijn in academische kringen geëvolueerd, maar binnen de context van toegepaste datawetenschap moeten organisaties rekening houden met een heel andere reeks vereisten en doelen. Uiteindelijk is elk model dat een bedrijf bouwt bedoeld om een ​​zakelijk probleem aan te pakken. In dit verband zijn er twee overkoepelende doelen: bouwen met de hoogste return-on-investment (ROI) en met de snelste time-to-market (TTM). Beide hebben aanzienlijke financiële implicaties – vooral TTM, dat naast het verminderen van directe kosten een bedrijf in staat stelt sneller op de markt te komen dan zijn concurrenten en daardoor tactische en strategische financiële voordelen te behalen.

Neural Guard produceert geautomatiseerde oplossingen voor bedreigingsdetectie, aangedreven door AI, voor de markt voor beveiligingsonderzoeken. We bouwen technologie die specifieke, risicovolle items in CT- en röntgenbeelden detecteert door gebruik te maken van geavanceerde neurale netwerken om de uitvoer van een beveiligingsscanner te analyseren. In deze blogpost bespreken we de methodologie die we hebben ontwikkeld voor het bouwen van datasets voor DL-modellen die onze ROI en TTM optimaliseren. Deze methodologie heeft ons in staat gesteld om ons concurrentievermogen in deze markt aanzienlijk te vergroten.

Zoals elke fatsoenlijke datawetenschapper weet, moet je om een ​​model te valideren de testgegevens opzij zetten. Het is ook een goed idee dat de testgegevens geen deel kunnen uitmaken van de trainingsdataset zelf.

De standaardpraktijk in wetenschappelijk onderzoek is om eerst een treinstel te maken en vervolgens een klein deel ervan als testset opzij te zetten. Uiteindelijk worden in academisch onderzoek de prestaties van algoritmen en modellen getoetst aan bekende, geaccepteerde datasets, zodat vergelijkingen kunnen worden gemaakt. In deze situaties is de dataset onveranderlijk en kan deze niet worden gewijzigd. Voor dit doel is de methodologie zinvol.

Als gevolg hiervan leggen onderzoekers en datawetenschappers de meeste focus op de kwaliteit van het model, waarbij datasets – als onveranderlijk – minder focus krijgen; en de test-set bijna een gegeven. Toegegeven, je wilt er zeker van zijn dat de testset een afspiegeling is van de treinset. Elke subset wordt willekeurig gekozen of soms gekozen met een meer geavanceerde methodologie, maar nog steeds willekeurige methodologie voor elk label, waarbij de distributie van labels altijd behouden blijft. Maar daar blijft het bij.

Data kost geld. Veel geld

Als vuistregel geldt dat deep learning-netwerken datahongerig zijn. Wanneer datawetenschappers wordt gevraagd “hoeveel gegevens heb je nodig?” het juiste antwoord, althans van de kant van de onderzoeker, is vrijwel altijd: “meer”. Maar dit antwoord negeert een fundamenteel probleem: in academisch onderzoek hebben onderzoekers zelden te maken met de last van het zelf maken van de dataset, of het nu voor testen of training is. Dit komt omdat er een benchmark bekend is of omdat ze aan een specifieke dataset moeten werken. Aan de andere kant worden we voor onderzoek (en ontwikkeling) in de context van toegepaste wetenschap in reële industriële toepassingen inderdaad belast door de moeilijkheden en complexiteiten die verband houden met het maken van de dataset.

Het verkrijgen van meer gegevens vereist meer tijd en geld. Het onderhouden ervan is ook niet goedkoop. Zo gebruiken we bij Neural Guard momenteel zo'n twee miljoen afbeeldingen. Terwijl dit in de auto-industrie niet als significant wordt beschouwd, is dit in de beveiligingsmarkt dat wel. Het maken van een dergelijke dataset vereist dure röntgenapparatuur, echte bedreigingen (bijv. geweren, messen, explosieven, enz.), een grote verscheidenheid aan bagage-items en goed opgeleide gegevensannotators.

De kosten van het verkrijgen en het onderhouden van een dataset, zoals hieronder beschreven, is niet te verwaarlozen:.

• Het verzamelen van gegevens op zich kan kostbaar zijn als u niet al een brede operationele implementatie van uw oplossing heeft. Sensoren (camera's of andere typen) zijn nodig om gegevens vast te leggen, met opslag en netwerken om de gegevens van de verzamelsite(s) naar uw trainingslocatie te verplaatsen.
• Labelers zijn verplicht om het te labelen. In sommige gevallen heeft u wellicht hoogopgeleide arbeidskrachten nodig, zoals artsen of technici, en in ons geval operators van röntgenmachines.
• We hebben personeel voor gegevensverzameling en gegevenstechnici nodig om de gegevens samen te voegen en te sorteren. , en maak het toegankelijk voor de datawetenschappers in de relevante opslag en formaten.
• Meer gegevens betekent hogere opslagkosten en meer rekentijd voor het trainen van het model, wat zich direct vertaalt in dollarkosten wanneer het een cloudinstantie is die de code uitvoert of als de extra belasting het nodig maakt om meer on-prem rekenbronnen aan te schaffen. On-prem resources kosten geld om aan te schaffen en meer om vervolgens te beheren en te onderhouden.
• Het onderhouden van datasets (buiten opslag, etc.) is kostbaar. Gegevenssets moeten vaak worden aangepast, labels moeten mogelijk worden gerepareerd en af ​​en toe ontdekken we dat de manier waarop we klassen hebben gelabeld misschien niet de optimale methode is en dat we de hele klasse opnieuw moeten labelen (we hebben bijvoorbeeld gevouwen en open messen gegroepeerd, maar ontdekte toen dat het model beter presteert als we de twee in verschillende klassen scheiden). Hoe groter de dataset, hoe groter de kosten voor herlabelen en fixeren. En omdat datawetenschap reproduceerbaarheid vereist, hebben we versiebeheer nodig. Hoe groter de dataset, hoe hoger de kosten die gepaard gaan met het bewaren van oudere versies.

We kunnen dus stellen dat voor een toegepast wetenschappelijk probleem het doel van een organisatie zou zijn om de “beste resultaten” te behalen (in wezen het best presterende model dat mogelijk is), met de minste hoeveelheid gegevens. In feite willen we de beste prestaties krijgen voor de minste investering, in gegevens en alle gerelateerde processen, evenals andere kosten, waaronder tijd.

Natuurlijk is het definiëren van “beste prestaties” schieten op een ontwijkend doel. In academisch onderzoek willen we SOTA-resultaten verslaan, en elke verbetering van 0,1% in nauwkeurigheid is eigenlijk indrukwekkend (toegegeven, er zijn academische papers over zichzelf met optimalisatie van kosten of ROI voor bepaalde modellen. Maar ze zijn niet relevant voor de hypothese hiervan posten om verschillende redenen). Maar onderzoek doen in een commerciële context is iets anders. Er moeten zakelijke afwegingen worden gemaakt en prestatieverbeteringen van modellen brengen soms kosten met zich mee (hogere latentie voor gevolgtrekkingen, langere onderzoekstijd, enz.). We moeten inzicht hebben in de bedrijfsdoelstelling om de juiste maatstaven voor succes te definiëren. Laten we nog nauwkeuriger stellen dat ons doel vaak is om een ​​bepaalde prestatiedrempel (niet noodzakelijk de best haalbare prestatie) voor dat budget te bereiken.

Waarom zou de testset vóór de treinset komen? ?

In de context van op deep learning gebaseerde oplossingen, worden de bedrijfsstatistieken en prestatie-indicatoren die onze bedrijfsdoelen bepalen, weerspiegeld in onze testset. Modelprestaties op de testset bepalen of ons model “klaar” is. We vergelijken ons model eerst met de testset en als we resultaten krijgen die voldoen aan onze KPI's, zijn we klaar om te gaan! De testset wordt het “single point of truth”. Dit maakt het bouwen van een testset een van de belangrijkste aspecten van toegepast onderzoek en ontwikkeling.

Op basis van al het bovenstaande zou ik willen stellen dat we voor de opleiding van industriële modellen niet de methode om een ​​dataset te maken en vervolgens een deel ervan opzij te zetten als testset. Integendeel, onze eerste prioriteit is het definiëren en bouwen van de best mogelijke testset. In feite is de kwaliteit van de testset een van de meest kritische variabelen die uiteindelijk van invloed zijn op de kwaliteit van de prestaties van het eindmodel. Als de testset het werkelijke scenario nauwkeurig weerspiegelt (d.w.z. het is van “hoge kwaliteit”), dan zal een model dat er goed op presteert uiteindelijk een model zijn dat in productie aan onze verwachtingen voldoet. Dit is waar domeinkennis en -ervaring van onschatbare waarde worden, omdat het proces van het bouwen van testsets van eenvoudige toewijzing van subsets naar een set regels en procedures gaat. Enkele belangrijke aspecten waarmee rekening moet worden gehouden bij het aanpakken van dat begrip “hoge kwaliteit”:

• Het aantal testafbeeldingen, per klasse, moet groot genoeg zijn om statistisch haalbaar te zijn
• De dataset moet goed gebalanceerd zijn en het domein volledig vertegenwoordigen. Dit zijn enkele van de eigenschappen die we volgen en balanceren:
  • Klasse
  • Klasse instantie
  • Complexiteit van de plaatsing en hoek van het object.
  • Achtergrond (bagage) type
  • Achtergrondcomplexiteit
  • Scannermodel

Onze dataset uitbreiden naar treinset & trainen

Pas als we de testset klaar hebben, kunnen we naar de volgende stap: het maken van de treinset. De noodzaak om onze eigen datasets te bouwen betekent ook dat we de testset kunnen ontwerpen voor onze implementatieomgeving en in staat zijn om de mix van de testset voor de treinset te repliceren. Als we eenmaal een testset hebben gebouwd, gaan we gewoon een treinset bouwen door in wezen “klonen” van de testset te maken: hetzelfde label en dezelfde achtergronddistributie, dezelfde achtergrondobjecten en objecthoudingen, maar verschillende afbeeldingen en bij voorkeur verschillende object- en achtergrondinstanties. Bij Neural Guard hebben we een interne dataproductiefaciliteit, waar we nieuwe afbeeldingen produceren met een snelheid van ongeveer 130.000 nieuwe gelabelde afbeeldingen per maand.

Wanneer we een verhouding van 1:1 van testset versus treinset bereiken, kunnen we onze eerste pass van “train en evalueren” doen (we beginnen met de 1:1-verhouding omdat het geen zin heeft om een ​​trein te hebben -set kleiner dan de testset). Als de prestaties van het model tijdens de evaluatie aan de eisen voldoen, kunnen we hier stoppen. Als dat niet het geval is – en meestal ook niet – moeten we onze treinset uitbreiden en testen met steeds grotere verhoudingen. We beginnen met een verhouding van 2: 1 treinen: testdataset, enzovoort, en gaan door totdat we de vereiste drempel hebben bereikt. Uit onze ervaring komt de verhouding meestal uit op 4:1 tot 5:1. Idealiter zou het treinstel niet uniform moeten worden uitgebreid, maar op basis van elke klasse; de verhouding per klas hangt af van hoe moeilijk de klas is. In ons domein zijn objecten die opgaan in hun achtergrond moeilijker te trainen.

Zie onderstaand voorbeeld van een mes en hetzelfde mes in een tas met metalen objecten:

Door deze methodologie te volgen, kunnen we alleen zoveel gegevens genereren als we nodig hebben, waardoor we de gegevensgerelateerde kosten kunnen minimaliseren: productie- en etikettering van gegevens, gegevensopslag en archiveringskosten, onderhoud, enz. Door de dataset uiteindelijk kleiner te houden, kunnen we de snelste TTM en tegelijkertijd de kosten laag houden. In de hierboven beschreven methodologie kunnen we dit doen zonder concessies te doen aan de prestaties.

Van theorie naar praktijk

In theorie is dit allemaal geweldig, maar hoe pak je de taak om daadwerkelijk te bouwen aan? zo'n testset? We kwamen tot de conclusie dat intiem omgaan met de gegevens – terwijl je ze kunt beheren – de sleutel isom een ​​goede testset te kunnen bouwen. Idealiter moeten we in staat zijn om:

• Gemakkelijk labeldistributie en andere statistieken voor elke dataset te krijgen
• Versiedatasets zodat we de voortgang kunnen volgen
• Zorg voor een fijnmazige controle over welke subsets van onze dataset worden gebruikt voor elke trainingsrun en voor de testset.
• Verbind de datasetbeheertool met de experimentbeheertool om resultaten, gegevens en metadata aan elkaar te koppelen< /li>
• Wijzig gegevens on-the-fly tijdens langere experimenten en voer halverwege de training nieuwe gegevens in
• Gebruik eenvoudige API's voor het opnieuw in evenwicht brengen en aanpassen van datasets. Dit helpt bij het bouwen van uitgebalanceerde datasets en zorgt ervoor dat het evenwicht tijdens de training behouden blijft

Tot dit punt in ons verhaal is het belangrijkste om je gegevens te kennen, een goede testset op te bouwen en de rest zal op zijn plaats vallen. Maar het is een moeilijke taak om uw gegevens te leren kennen. Ten eerste is het verkrijgen van zoveel mogelijk veldgegevens van onschatbare waarde. Het helpt een onderzoeker echt om de verschillende objecten, posities, achtergronden enzovoort te begrijpen waarmee een model te maken krijgt. Als u eenmaal veldkennis heeft, kunt u ook zelf synthetische gegevens maken (Bij Neural Guard hebben we onze eigen faciliteit voor het genereren van gegevens met een verscheidenheid aan röntgenapparaten en toegang tot een grote verzameling bedreigingsitems. Er zijn verschillende soorten van synthetische gegevens die we creëren, maar dat valt buiten het bestek van deze blogpost). Dit helpt bij de logistiek van het verzamelen van gegevens en geeft ons controle over de geproduceerde gegevens, zodat we weten dat we alle randgevallen behandelen.

Tooling is ook van groot belang. Het is mogelijk om veel code en stitch-scripts te schrijven om te proberen alle bovengenoemde functionaliteit te bouwen. Maar als je werk eenmaal schaalt – en we zouden zeggen dat zelfs voordat schaalvergroting plaatsvindt – wordt het onmogelijk om ermee om te gaan.

Voor ons had het geen zin om dergelijke tools alleen te bouwen. We wilden ons blijven concentreren op het bouwen van de beste autodetectieoplossingen voor de markt voor beveiligingsonderzoeken. Alle hierboven genoemde functionaliteiten zijn wat een best-of-breed ML-Ops-oplossing naar onze mening zou moeten leveren. Meestal zijn de functionaliteiten echter alleen te vinden in verschillende individuele oplossingen die met elkaar moeten worden geïntegreerd.

Daarom hebben we ClearML Enterprise gekozen als de toolchain bij uitstek voor ons. Het biedt alle functionaliteit in een enkele, sterk geïntegreerde toolchain. Ook is het heel eenvoudig om daar gespecialiseerde pijplijnen op te bouwen en deze aan te sluiten op de rest van uw onderzoeks- of productieomgeving. Wat bovendien van onschatbare waarde was voor ons werk, was de mogelijkheid om gegevens on-the-fly binnen ClearML te wijzigen en toe te voegen. In ClearML is gegevensbeheer sterk geïntegreerd in experimentbeheer, dus zodra een ingenieur voor gegevensverzameling een nieuwe gegevenssetversie uploadt, kunnen we de resultaten onmiddellijk volgen en het effect ervan in realtime zien. Een eenvoudig voorbeeld: het stelt ons in staat om problemen met verkeerde labels te ontdekken en de oplossing zeer snel te verifiëren.

In deze blogpost kun je meer lezen over waarom en hoe we ClearML (f.k.a. Allegro Trains) gebruiken.

De bottom line

In deze blogpost hebben we een methode voor het maken van gegevens onderzocht die is het tegenovergestelde van traditionele methoden: eerst je testset bouwen en er vervolgens de treinset uit afleiden. We leggen uit waarom het voor bedrijven die deep learning doen, een geweldige methode is om met de data-acquisitiekosten om te gaan. Deze methode om eerst op de testset te focussen, helpt datawetenschapsorganisaties ook om een ​​beter begrip te krijgen van de aard van hun gegevens 'in het wild'. Dit leidt tot de creatie van datasets van hogere kwaliteit (zowel treinset als testset) die uiteindelijk leiden tot beter presterende modellen tegen lagere kosten, wat het einddoel is van een dergelijke onderneming.

Het is het is ook belangrijk op te merken dat, hoewel het uitvoerbaar is, het zelf beheren van de volledige gegevenslevenscyclus een nieuwe laag van aanzienlijke complexiteit met zich meebrengt en dat men serieus moet nadenken over speciaal gebouwde tool(s) voor de taak.

Raviv Pavel
CTO en mede-oprichter, Neural Guard