Aerobotics förbättrar träningshastigheten med 24 gånger per prov med Amazon SageMaker och TensorFlow

Redaktörens anteckning: Det här är ett gästinlägg skrivet av Michael Malahe, datachef på Aerobotics, en sydafrikansk startup som bygger AI-drivna verktyg för jordbruk.

Aerobotics är ett agri-tech-företag verksamt i 18 länder runt om i världen, baserat från Kapstaden, Sydafrika. Vårt uppdrag är att tillhandahålla intelligenta verktyg för att mata världen. Vi strävar efter att uppnå detta genom att förse jordbrukare med handlingskraftig data och insikter på vår plattform, Aeroview, så att de kan göra nödvändiga ingrepp vid rätt tidpunkt under växtsäsongen. Vår dominerande datakälla är flygdrönare: fånga visuella och multispektrala bilder av träd och frukt i en fruktträdgård.

I det här inlägget tittar vi på hur vi använder Amazon SageMaker och TensorFlow för att förbättra vår Tree Insights-produkt, som ger mätningar per träd av viktiga kvantiteter som trädkronor och hälsa, och tillhandahåller platser för döda och saknade träd. Jordbrukare använder denna information för att göra exakta ingrepp som att fixa bevattningslinjer, applicera gödningsmedel i varierande mängd och beställa ersättningsträd. Följande är en bild av verktyget som bönder använder för att förstå hälsan hos sina träd och fatta några av dessa beslut.

För att tillhandahålla denna information för att fatta dessa beslut måste vi först tilldela varje förgrundspixel till ett enda unikt träd. För den här instanssegmenteringsuppgiften är det viktigt att vi är så noggranna som möjligt, så vi använder en maskininlärningsmodell (ML) som har varit effektiv i storskaliga benchmarks. Modellen är en variant av Mask R-CNN, som parar ihop ett konvolutionellt neuralt nätverk (CNN) för funktionsextraktion med flera ytterligare komponenter för detektion, klassificering och segmentering. I följande bild visar vi några typiska utdata, där pixlarna som tillhör ett givet träd är markerade av en kontur.

När du tittar på utgångarna kan du tro att problemet är löst.

Utmaningen

Den största utmaningen med att analysera och modellera jordbruksdata är att den är mycket varierande över ett antal dimensioner.

Följande bild illustrerar några ytterligheter av variationen i storleken på träd och i vilken utsträckning de entydigt kan separeras.

I lunden av pekannötsträd har vi ett av de största träden i vår databas, med en yta på 654 m² (lite över en minut att gå runt i en typisk hastighet). Vinrankorna till höger om lunden mäter 50 cm i diameter (storleken på en typisk krukväxt). Våra modeller måste vara toleranta mot dessa variationer för att ge korrekt segmentering oavsett skala.

En ytterligare utmaning är att variationskällorna inte är statiska. Jordbrukare är mycket innovativa och bästa praxis kan förändras avsevärt över tiden. Ett exempel är plantering med ultrahög densitet för äpplen, där träd planteras så nära som en fot från varandra. En annan är antagandet av skyddsnät, som döljer flygbilder, som i följande bild.

Inom denna domän med breda och skiftande variationer måste vi upprätthålla korrekta modeller för att ge våra kunder tillförlitliga insikter. Modeller bör förbättras för varje utmanande nytt prov vi möter, och vi bör distribuera dem med tillförsikt.

I vår första inställning till denna utmaning tränade vi helt enkelt på all data vi hade. När vi skalade kom vi dock snabbt till den punkt där träning på all vår data blev omöjlig, och kostnaden för att göra det blev ett hinder för experiment.

Lösningen

Även om vi har variation i kantfallen, insåg vi att det fanns mycket redundans i våra standardfall. Vårt mål var att komma till en punkt där våra modeller tränas på endast de mest framträdande data och kan konvergera utan att behöva se varje prov. Vårt tillvägagångssätt för att uppnå detta var först att skapa en miljö där det är enkelt att experimentera med olika tillvägagångssätt för datauppsättningskonstruktion och sampling. Följande diagram visar vårt övergripande arbetsflöde för den dataförbearbetning som möjliggör detta.

Resultatet är att träningsprover finns tillgängliga som individuella filer i Amazon enkel lagringstjänst (Amazon S3), vilket bara är vettigt att göra med skrymmande data som multispektrala bilder, med referenser och rik metadata lagrad i Amazon RedShift tabeller. Detta gör det trivialt att konstruera datamängder med en enda fråga, och gör det möjligt att hämta individuella prover med godtyckliga åtkomstmönster vid tågtid. Vi använder LASTA AV för att skapa en oföränderlig datauppsättning i Amazon S3, och vi skapar en referens till filen i vår Amazon Relational Databas Service (Amazon RDS) databas, som vi använder för träning av proveniens och utvärderingsresultatspårning. Se följande kod:

UNLOAD ('[subset_query]') TO '[s3://path/to/dataset]' IAM_ROLE '[redshift_write_to_s3_role]' FORMAT PARQUET 

Lättheten att söka i brickmetadata gjorde det möjligt för oss att snabbt skapa och testa delmängder av våra data, och så småningom kunde vi träna till konvergens efter att bara ha sett 1.1 miljoner prover av totalt 3.1 miljoner. Denna underepokkonvergens har varit mycket fördelaktig för att få ner våra beräkningskostnader, och vi fick en bättre förståelse av våra data längs vägen.

Det andra steget vi tog för att minska våra utbildningskostnader var att optimera vår beräkning. Vi använde TensorFlow-profilerare kraftigt under detta steg:

import tensorflow as tf tf.profiler.experimental.ProfilerOptions(host_tracer_level=2, python_tracer_level=1,device_tracer_level=1) tf.profiler.experimental.start("[log_dir]") [train model] tf.profiler.experimental.stop() 

För träning använder vi Amazon SageMaker med P3-instanser tillhandahållna av Amazon Elastic Compute Cloud (Amazon EC2), och till en början fann vi att NVIDIA Tesla V100 GPU:er i fallen flaskades
kontrolleras av CPU-beräkning i indatapipelinen. Det övergripande mönstret för att lindra flaskhalsen var att flytta så mycket av beräkningen från inbyggd Python-kod till TensorFlow-operationer som möjligt för att säkerställa effektiv trådparallellism. Den största fördelen var att byta till tf.io för datahämtning och deserialisering, vilket förbättrade genomströmningen med 41 %. Se följande kod:

serialised_example = tf.io.decode_compressed(tf.io.gfile.GFile(fname, 'rb').read(), compression_type='GZIP') example = tf.train.Example.FromString(serialised_example.numpy()) 

En bonusfunktion med detta tillvägagångssätt var att byte mellan lokala filer och Amazon S3-lagring inte krävde några kodändringar på grund av filobjektabstraktionen som tillhandahålls av GFile.

Vi upptäckte att den sista kvarvarande flaskhalsen kom från standardinställningarna för TensorFlow CPU-parallellism, som vi optimerade med en SageMaker hyperparameterjusteringsjobb (se följande exempel config).

När CPU-flaskhalsen togs bort gick vi över till GPU-optimering och fick ut det mesta av V100:s Tensor Cores genom att använda blandad precisionsträning:

from tensorflow.keras.mixed_precision import experimental as mixed_precision policy = mixed_precision.Policy('mixed_float16') mixed_precision.set_policy(policy) 

Smakämnen blandad precisionsguide är en solid referens, men övergången till att använda blandad precision kräver fortfarande lite noggrann uppmärksamhet för att säkerställa att operationerna som sker med halv precision inte är dåligt konditionerade eller benägna att underflyta. Några specifika fall som var kritiska var terminalaktiveringar och anpassade regleringsvillkor. Se följande kod:

import tensorflow as tf ... y_pred = tf.keras.layers.Activation('sigmoid', dtype=tf.float32)(x) loss = binary_crossentropy(tf.cast(y_true, tf.float32), tf.cast(y_pred, tf.float32), from_logits=True) ... model.add_loss(lambda: tf.keras.regularizers.l2()(tf.cast(w, tf.float32))) 

Efter att ha implementerat detta mätte vi följande benchmarkresultat för en enda V100.

Effekten av att byta till blandad precision var att träningshastigheten ungefär fördubblades, och effekten av att använda de optimala CPU-parallellitetsinställningarna som upptäcktes av SageMaker var en ytterligare ökning med 16 %.

Att implementera dessa initiativ allt eftersom vi växte resulterade i att kostnaden för att träna en modell minskade från $122 till $68, medan vår datauppsättning växte från 228 tusen prover till 3.1 miljoner, vilket motsvarar en 24 gångers minskning av kostnaden per prov.

Slutsats

Denna minskning av utbildningstid och kostnad har gjort att vi snabbt och billigt kan anpassa oss till förändringar i vår datadistribution. Vi stöter ofta på nya fall som är förvirrande även för människor, till exempel följande bild.

De blir dock snabbt standardfodral för våra modeller, som visas på följande bild.

Vi siktar på att fortsätta göra träningen snabbare genom att använda fler enheter och göra den effektivare genom att utnyttja SageMaker lyckades Spot Instanser. Vi siktar också på att göra träningsslingan tätare genom att servera SageMaker-modeller som kan läras online, så att förbättrade modeller är tillgängliga i nästan realtid. Med dessa på plats borde vi vara väl rustade att hantera all variation som lantbruket kan kasta på oss. För att lära dig mer om Amazon SageMaker, besök Produktsida.

Innehållet och åsikterna i det här inlägget tillhör tredjepartsförfattaren och AWS ansvarar inte för innehållet eller noggrannheten i detta inlägg.

Om författaren

Michael Malahe är datachef på Aerobotics, en sydafrikansk startup som bygger AI-drivna verktyg för jordbruk.

Källa: https://aws.amazon.com/blogs/machine-learning/aerobotics-improves-training-speed-by-24-times-per-sample-with-amazon-sagemaker-and-tensorflow/