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 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, anvendbare 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 var det som tiltalte deg til maskinlæring og AI?

Jeg startet å programmere fordi jeg ville lage videospill og ble interessert i datagrafikk først. Dette ledet meg til computer-vision, som er en slags omvendt prosess der du ikke har datamaskinen som lager en falsk omgivelse, men der den faktisk oppfatter den virkelige omgivelsen. Under studiet, tok jeg noen maskinlærings-kurser og ble interessert i computer-vision-vinkelen av det. Jeg tror det som er interessant med ML er at det er på grensen mellom programvare-utvikling, algoritmer og matematikk, og det føles fortsatt litt magisk når det fungerer.

Du har jobbet med å bruke maskinlæring til å analysere satellitt-bilder i mange år nå. Hva var ditt første prosjekt?

Min første erfaring med satellitt-bilder var Terra-i-prosjektet (for å detektere avskoging) og jeg jobbet med det under studiet. Jeg var imponert over mengden av fritt tilgjengelig satellitt-data som produseres av de forskjellige romfartsbyråene (NASA, ESA osv.). Du kan få regelmessige bilder av planeten gratis hver dag eller så, 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 er nå ledet av Louis Reymondin, fra CIAT (Colombia). Idéen bak prosjektet er å detektere avskoging ved hjelp av fritt tilgjengelige satellitt-bilder. På den tiden jobbet vi med MODIS-bilder (250m pixel-oppløsning) fordi de ga en enhetlig og forutsigbar dekning ( både geografisk og tidsmessig). Vi fikk en måling for hver pixel hver få dager, og fra denne tidsserien av målinger, kunne du prøve å detektere anomalier eller nyheter, som vi kaller det i ML noen ganger.

Dette prosjektet var veldig interessant fordi mengden data var en utfordring på den tiden, og det var også noen programvare-utvikling involvert for å gjøre det fungere på flere datamaskiner osv. Fra ML-siden, brukte det Bayesian Neural Network (ikke så dypt på den tiden 🙂 ) for å forutsi hva tidsserien av en pixel skulle se ut som. Hvis målingen ikke matchet forutsigelsen, så hadde vi en anomali.

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

Du har også designet og implementert et dyp-lærings-system for automatisk avlingstype-klassifisering fra luftfoto (drone-bilder) av jordbruksfelt. Hva var de viktigste utfordringene på den tiden?

Dette var min første virkelige eksponering for dyp-læring. På den tiden, tror jeg at de viktigste 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 felt, fra drone-bilder. Vi prøvde en tilnærming der det dyp-lærings-modellen brukte farge-histogrammer som inndata, i stedet for bare det rå bildet. For å få dette til å fungere rimelig raskt, husker jeg at jeg måtte implementere en tilpasset Theano-lag, helt ned til noen CUDA-kode. Det var en stor lærings-erfaring på den tiden og en god måte å grave litt i de tekniske detaljene av dyp-læring.

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

Det varierer virkelig, men mye av det handler om å holde et øye på den overordnede arkitekturen av systemet og produktet generelt, og kommunisere med de forskjellige interessentene. Selv om ML er kjernen av vår forretning, innser du raskt at mesteparten av tiden ikke brukes på ML-siden selv, men alle tingene rundt det: data-håndtering, infrastruktur, UI/UX, prototyping, forståelse av brukere osv… Dette er ganske en forandring fra akademiet eller tidligere erfaring i større selskaper hvor du er mye mer fokusert på et spesifikt problem.

Hva som er interessant med Picterra er at vi ikke bare kjører dyp-lærings-modeller for brukerne våre, men vi lar dem også trene sine egne. Det er forskjellig fra de typiske ML-arbeidsflytene hvor du har ML-teamet som trener en modell og så publiserer den til produksjon. Det betyr at vi ikke kan manuelt leke med trenings-parametrene som du ofte gjør. Vi må finne en trenings-metode som vil fungere for alle våre brukere. Dette ledet oss til å lage hva vi kaller vår “eksperiment-ramme”, som er et stort repository av datasett som simulerer trenings-dataene våre brukere ville bygge på plattformen. Vi kan deretter enkelt teste endringer i vår trenings-metodologi mot disse datasettene og evaluere om de hjelper eller ikke. I stedet for å evaluere en enkelt modell, evaluerer vi mer en arkitektur + trenings-metodologi.

Den andre utfordringen er at våre brukere ikke er ML-utøvere, så de vet ikke nødvendigvis hva en trenings-sett er, hva en label er osv. Bygging av en UI som lar ikke-ML-utøvere bygge datasett 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 ansvar inkluderer prototyping av nye ideer og teknologier. Hva er noen av de mer interessante prosjektene du har jobbet med?

Jeg tror det mest interessante 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 bygning-detektor, en bil-detektor osv…

Dette er faktisk den typiske ML-arbeidsflyten: du har en ML-ingeniør som utvikler en modell for et spesifikt tilfelle og så publiserer den til kundene.

Men vi ville gjøre noe annerledes 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 beholde denne følelsen av interaktivitet, bør trenings-tiden være noen minutter på mest. For det andre, ville vi ikke at dette skulle kreve tusenvis av annotasjoner, som er typisk hva du trenger for store dyp-lærings-modeller.

Så vi startet med en super enkel modell, gjorde en del tester i jupyter og så 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 hvor det fungerte. Dette ga oss håp, og vi startet å iterere over trenings-metodologien og modellen. Etter noen måneder, var vi i stand til å nå et punkt hvor det fungerte bra, og nå har våre brukere dette i bruk hele tiden.

Hva som var interessant med dette, er den doble utfordringen av å holde trenings-tiden rask (nåværende noen minutter) og derfor ikke gjøre modellen for kompleks, men likevel kompleks nok til at den fungerer og løser brukerens problemer. I tillegg til dette, 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 starter å optimere modellen. Det setter deg i “system-tenkning”-modus hvor du innser at ikke alle dine problemer skal håndteres av ML-kjernen, men noen av dem kan skyves til UI, noen av dem for- eller etter-prosesseres osv…

Hva er noen av 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 spesifikke modeller utviklet for kunder. For øvrig, er det en ganske standard vitenskapelig Python-stakk (numpy, scipy) med noen geospatial-biblioteker (gdal) kastet inn.

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

Ja, så først når du 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 gjør at vi kan aksessere blokker av bildet raskt uten å måtte laste ned hele bildet senere. Dette er et viktig punkt fordi geospatial-bilder kan være enorme: vi har brukere som rutinemessig jobber med 50000×50000 bilder.

Så, for å trene din modell, må du opprette din trenings-datasett gjennom vår web-UI. Du vil gjøre det ved å definere 3 typer områder:

1. ‘trenings-områder’, hvor du vil tegne trenings-labels
2. ‘test-områder’, hvor modellen vil forutsi for å la deg visualisere noen resultater
3. ‘nøyaktighets-område’, hvor du vil tegne labels også, men disse brukes ikke til trening, bare til scoring

Når du har opprettet dette datasett, kan du enkelt klikke ‘Tren’ og vi vil trene en detektor for deg. Hva som skjer neste, er at vi setter en trenings-jobb i kø, får en av våre GPU-arbeidere til å plukke det opp (nye GPU-arbeidere startes automatisk hvis det er mange samtidige jobber), trener din modell, lagrer vekterne til blob-lagringen og til slutt forutsier i ‘test-området’ for å vise på UI. Derfra kan du iterere over din modell. Vanligvis vil du se noen feil i ‘test-områdene’ og legge til ‘trenings-områder’ for å hjelpe modellen med å forbedre.

Når du er fornøyd med poengsummen til din modell, kan du kjøre den i stor skala. Fra brukerens synspunkt, er dette virkelig enkelt: bare klikk på ‘Detekt’ ved siden av bildet du vil kjøre det på. Men det er litt mer komplisert under hånden hvis bildet er stort. For å få det til å fungere raskt, håndtere feil og unngå å få detektering som tar flere timer, bryter vi ned store detekteringer i grid-celler og kjører en uavhengig detekterings-jobb for hver celle. Dette gjør at vi kan kjøre svært store skala-detekteringer. For eksempel, hadde vi en kunde som kjørte detektering over hele Danmark på 25cm-bilder, som er i rekkefølgen av TB-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 geospatial. Hva som skiller oss fra andre selskaper som prosesserer geospatial-data, er at vi utstyrer våre brukere med en selv-betjenings-plattform. De kan lett finne steder, analysere mønster, og detektere og telle objekter på jord-observasjons-bilder. Det ville være umulig uten maskinlæring, men våre brukere trenger ikke engang grunnleggende kode-ferdigheter – plattformen gjør jobben basert på noen menneskeskapte annotasjoner. For de som vil gå dypere og lære de grunnleggende konseptene av maskinlæring i geospatial-domænet, har vi lansert en omfattende online-kurs.

Hva som også er verdt å nevne, er at mulige anvendelser av Picterra er endeløse – detektorer bygget på plattformen er blitt brukt i by-forvaltning, presisjons-jordbruk, skog-forvaltning, humanitær- og katastrofe-risiko-håndtering, jordbruk osv., bare for å nevne 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.