Julien Rebetez, Lead Machine Learning Engineer i Picterra – Intervju-serie

Julien Rebetez er Lead Software & Machine Learning Engineer i Picterra. Picterra tilbyr en geospatialt sky-basert plattform som er spesialdesignet for å trene dyp læringsbaserte detektorer, raskt og sikkert.

Uten en enkelt kode linje og med bare noen få menneskeskapte annotasjoner, bygger og distribuerer Picterras brukere unike, handlebare og ferdige dyp læringsmodeller.

Det automatiserer analysen av satellitt- og luftfoto, og gjør det mulig for brukerne å identifisere objekter og mønster.

Hva er det som tiltrekker deg til maskinlæring og AI?

Jeg begynte å programmere fordi jeg ville lage videospill og ble interessert i datagrafikk først. Dette ledet meg til datavisjon, som er en slags omvendt prosess der du ikke har datamaskinen som lager en falsk omgivelse, men der den isteden oppfatter den virkelige omgivelsen. Under studiet tok jeg noen maskinlæringskurs og ble interessert i datavisjonsaspektet ved det. Jeg tror det som er interessant med ML er at det er på grensen mellom programvareutvikling, algoritmer og matematikk, og at det fortsatt føles litt magisk når det fungerer.

Du har arbeidet med å bruke maskinlæring til å analysere satellittbilder i mange år nå. Hva var ditt første prosjekt?

Mitt første møte med satellittbilder var Terra-i-prosjektet (for å detektere avskoging) og jeg arbeidet med det under studiet. Jeg var imponert over mengden av fritt tilgjengelig satellittdata som produseres av de forskjellige romfartsbyråene (NASA, ESA osv.). Du kan få daglige bilder av planeten gratis, og dette er en stor ressurs for mange vitenskapelige anvendelser.

Kunne du dele mer detaljer om “Terra-i”-prosjektet?

Terra-i-prosjektet (http://terra-i.org/terra-i.html) ble startet av professor Andrez Perez-Uribe, fra HEIG-VD (Sveits) og ledes nå av Louis Reymondin, fra CIAT (Colombia). Idéen bak prosjektet er å detektere avskoging ved hjelp av fritt tilgjengelige satellittbilder. På den tiden arbeidet vi med MODIS-bilder (250m pikseloppløsning) fordi de ga en enhetlig og forutsigbar dekning (både romlig og tidsmessig). Vi fikk en måling for hver piksel hver få dager, og fra denne tidsrekken av målinger kunne vi prøve å detektere anomalier eller nyheter, som vi kaller dem i ML noen ganger.

Dette prosjektet var veldig interessant fordi mengden data var en utfordring på den tiden, og det var også noen programvareutviklingsaspekt som måtte løses for å få det til å fungere på flere datamaskiner osv. Fra ML-siden brukte vi Bayesian Neural Network (ikke så dypt på den tiden) for å forutsi hva tidsrekken av en piksel skulle se ut som. Hvis målingen ikke matchet forutsigelsen, så hadde vi en anomali.

Som en del av dette prosjektet arbeidet jeg også med skyfjerning. Vi tok en tradisjonell signalbehandlingsmetode der, hvor du har en tidsrekke av målinger og noen av dem vil være helt feil på grunn av en sky. Vi brukte en fourier-basert metode (HANTS) for å rense tidsrekken før vi detekterte nyheter i den. En av utfordringene var at hvis vi rensket for sterkt, ville vi også fjerne nyheter, så det var noen eksperimenter å gjøre for å finne riktige parametre.

Du har også designet og implementert et dyp læringsystem for automatisk avlingstypeklassifisering fra luftfoto (drone) av jordbruksområder. Hva var de største utfordringene på den tiden?

Dette var mitt første virkelige møte med dyp læring. På den tiden tror jeg at de største utfordringene var mer å få rammeverket til å fungere og korrekt bruke en GPU enn på ML-siden selv. Vi brukte Theano, som var en av forgjengerne til Tensorflow.

Målet med prosjektet var å klassifisere avlingstypen i et jordbruksområde, fra dronefoto. Vi prøvde en metode der det dype læringsmodellen brukte fargehistogrammer som inndata, i stedet for bare de rå bildene. For å få dette til å fungere rimelig raskt, måtte jeg implementere en egen Theano-lag, helt ned til noen CUDA-kode. Dette var en god læringserfaring på den tiden og en god måte å grave litt i de tekniske detaljene ved dyp læring.

Du er nå Lead Software og Machine Learning Engineer i Picterra. Hvordan ville du beskrive din dag-til-dag aktivitet?

Det varierer mye, men mye av det er å holde øye på den overordnede arkitekturen til systemet og produktet generelt, og kommunisere med de forskjellige interessentene. Selv om ML er kjernevirksomheten vår, innser du raskt at mesteparten av tiden ikke brukes på ML-siden selv, men på alle ting rundt det: datahåndtering, infrastruktur, UI/UX, prototyping, forståelse av brukerne osv. Dette er ganske forskjellig fra akademiske eller tidligere erfaringer i større selskaper, der du er mye mer fokusert på et bestemt problem.

Hva som er interessant med Picterra er at vi ikke bare kjører dyp læringsmodeller for brukerne våre, men vi lar dem også trene sine egne. Dette er forskjellig fra de typiske ML-arbeidsflytene, der du har en ML-avdeling som trener en modell og så publiserer den til produksjon. Dette betyr at vi ikke kan manuelt leke med treningsparameterne som du ofte gjør. Vi må finne en treningsmetode som vil fungere for alle våre brukere. Dette har ført til at vi har laget vår egen “eksperimentramme”, som er en stor samling av datasæt som simulerer treningsdataene våre brukere bygger på plattformen. Vi kan så enkelt teste endringer i treningsmetodikken vår mot disse datasættene og evaluere om de hjelper eller ikke. I stedet for å evaluere en enkelt modell, evaluerer vi mer en arkitektur + treningsmetode.

En annen utfordring er at våre brukere ikke er ML-eksperter, så de vet ikke nødvendigvis hva en treningssett er, hva en label er osv. Å bygge en UI som lar ikke-ML-eksperter bygge datasæt og trene ML-modeller er en konstant utfordring, og det er mye frem og tilbake mellom UX- og ML-teamene for å sikre at vi guider brukerne i riktig retning.

Noen av dine ansvarsområder inkluderer å prototypere nye ideer og teknologier. Hva er noen av de mest interessante prosjektene du har arbeidet med?

Jeg tror det mest interessante prosjektet på Picterra var Custom Detector-prototypen. For 1,5 år siden hadde vi “bygget-inn” detektorer på plattformen: disse var detektorer som vi hadde trenet selv og gjort tilgjengelig for brukerne. For eksempel hadde vi en bygningdetektor, en bil-detektor osv.

Dette er den typiske ML-arbeidsflyten: du har en ML-ingeniør som utvikler en modell for en bestemt sak og så serverer den til kundene.

Men vi ville gjøre noe annet og pushe grensene litt. Så vi sa: “Hva hvis vi lar brukerne trene sine egne modeller direkte på plattformen”? Det var noen utfordringer for å få dette til å fungere: først ville vi ikke at dette skulle ta flere timer. Hvis du vil holde denne følelsen av interaktivitet, bør treningsprosessen ta noen minutter som mest. For det andre ville vi ikke at dette skulle kreve tusenvis av annotasjoner, som typisk er hva du trenger for store dyp læringsmodeller.

Så vi startet med en veldig enkel modell, gjorde en del tester i Jupyter og prøvde å integrere det i vår plattform og teste hele arbeidsflyten, med en grunnleggende UI og så videre. Først fungerte det ikke så bra i de fleste tilfeller, men det var noen tilfeller der det fungerte. Dette ga oss håp, og vi startet å iterere på treningsmetodikken og modellen. Etter noen måneder var vi i stand til å nå et punkt der det fungerte bra, og nå har vi våre brukere som bruker dette hele tiden.

Hva som var interessant med dette var den doble utfordringen med å holde treningsprosessen rask (nå noen minutter) og derfor ikke gjøre modellen for kompleks, men samtidig gjøre den kompleks nok til at den fungerer og løser brukerens problemer. I tillegg fungerer det med få (<100) labels for mange tilfeller.

Vi har også brukt mange av Googles “Rules of Machine Learning“, spesielt de om å implementere hele pipeline og metrikker før du begynner å optimere modellen. Dette setter deg i “systemtenkning”-modus der du innser at ikke alle dine problemer skal håndteres av kjerne-ML, men noen av dem kan skyves til UI, noen av dem kan forhåndsgenereres, osv.

Hva er noen av de maskinlærings-teknologiene som brukes i Picterra?

I produksjon bruker vi for tiden Pytorch til å trene og kjøre våre modeller. Vi bruker også Tensorflow fra tid til annen, for noen bestemte modeller utviklet for kunder. For øvrig er det en ganske standard vitenskapelig Python-stakk (numpy, scipy) med noen geospatialt biblioteker (gdal) kastet inn.

Kan du diskutere hvordan Picterra fungerer på bakenden når noen laster opp bilder og ønsker å trene neuralt nettverk for å korrekt annotere objekter?

Ja, så når du først laster opp et bilde, prosesserer vi det og lagrer det i en “Cloud-Optimized-Geotiff” (COG) format på vår blob-lagring (Google Cloud Storage), som lar oss raskt aksessere blokker av bildet uten å måtte laste ned hele bildet senere. Dette er et viktig punkt fordi geospatialt bilde kan være enormt: vi har brukere som rutinemessig arbeider med 50000×50000 bilder.

Så deretter, for å trene din modell, må du opprette din treningsdatasett gjennom vår web-grensesnitt. Du vil gjøre dette ved å definere 3 typer områder:

1. ‘treningsområder’, hvor du vil tegne treningslabels
2. ‘testområder’, hvor modellen vil forutsi for å la deg visualisere noen resultater
3. ‘nøyaktighetsområde’, hvor du vil tegne labels som ikke brukes til trenings, bare til scoring

Når du har opprettet denne datasetten, kan du bare klikke ‘Tren’ og vi vil trene en detektor for deg. Hva som skjer deretter er at vi setter en treningsjobb i kø, får en av våre GPU-arbeidere til å plukke den opp (nye GPU-arbeidere startes automatisk hvis det er mange samtidige jobber), trener din modell, lagrer vektene til blob-lagringen og til slutt forutsier i ‘testområdet’ for å vise på grensesnittet. Derfra kan du iterere over din modell. Typisk vil du se noen feil i ‘testområdene’ og legge til ‘treningsområder’ for å hjelpe modellen å forbedre seg.

Når du er fornøyd med modellens score, kan du kjøre den i stor skala. Fra brukerens synspunkt er dette veldig enkelt: bare klikk på ‘Detekt’ ved siden av bildet du vil kjøre det på. Men det er litt mer komplisert under bakken hvis bildet er stort. For å få det til å gå raskt, håndtere feil og unngå å få deteksjoner som tar flere timer, bryter vi ned store deteksjoner i grid-celler og kjører en uavhengig deteksjonsjobb for hver celle. Dette lar oss kjøre veldig store skala-deteksjoner. For eksempel hadde vi en kunde som kjørte deteksjon over hele Danmark på 25cm-bilder, som er i størrelsesordenen TB av data – for ett enkelt prosjekt. Vi har dekket et lignende prosjekt i denne medium-posten.

Er det noe annet du ville like å dele om Picterra?

Jeg tror det som er bra med Picterra er at det er et unikt produkt, på grensen mellom ML og geospatialt. Hva som skiller oss fra andre selskaper som behandler geospatialt data er at vi utstyrer våre brukere med en selvbetjeningsplattform. De kan lett finne steder, analysere mønster og detektere og telle objekter på jordobservasjonsbilder. Dette ville være umulig uten maskinlæring, men våre brukere trenger ikke engang grunnleggende kodeferdigheter – plattformen gjør arbeidet basert på noen menneskeskapte annotasjoner. For de som ønsker å gå dypere og lære de grunnleggende konseptene i maskinlæring i geospatialt domene, har vi lansert en omfattende nettbasert kurs.

Hva som også er verdt å nevne er at mulige anvendelser av Picterra er endeløse – detektorer bygget på plattformen har blitt brukt i byforvaltning, presisjonsjordbruk, skogforvaltning, humanitær og katastroferisikostyring, jordbruk osv., bare for å nevne noen av de vanligste anvendelsene. Vi blir faktisk overrasket hver dag av hva våre brukere prøver å gjøre med vår plattform. Du kan prøve det og la oss vite hvordan det fungerte på sosiale medier.

Takk for det flotte intervjuet og for å dele med oss hvor kraftig Picterra er, lesere som ønsker å lære mer bør besøke Picterra-nettstedet.