Velge det beste AutoML Framework

En sammenligning fra topp til hodet av fire automatiske maskinlæringsrammer på 87 datasett.

Adithya Balaji og Alexander Allen

Introduksjon

Automatisk maskinlæring (AutoML) kan bringe AI innen rekkevidde for et mye større publikum. Den gir et sett med verktøy for å hjelpe datavitenskapsteam med forskjellige erfaringsnivåer å fremskynde datavitenskapens prosess. Derfor blir AutoML innvarslet som løsningen på å demokratisere AI. Selv med et erfarent team, kan du kanskje bruke AutoML for å få mest mulig ut av begrensede ressurser. Selv om det finnes proprietære løsninger som gir maskinlæring som en tjeneste, er det verdt å se på de nåværende open source-løsningene som imøtekommer dette behovet.

I vårt forrige stykke utforsket vi AutoML-landskapet og fremhevet noen pakker som kan fungere for data science-team. I dette stykket skal vi utforske de fire “full pipeline” -løsningene som er nevnt: auto_ml, auto-sklearn, TPOT og H2Os AutoML-løsning.

Hver pakkes styrker og svakheter er detaljert i hele papiret, "Benchmarking Automatic Machine Learning Frameworks". Oppgaven inneholder også tilleggsinformasjon om metodikken og noen tilleggsresultater.

metodikk

For å gi en nøyaktig og rettferdig vurdering ble et utvalg av 87 åpne datasett, 30 regresjon og 57 klassifisering valgt fra OpenML, et online depot for standardlæringsdatasett for maskiner som ble eksponert gjennom et REST API på en konsekvent måte. Delingen av datasett gir et bredt utvalg av tabelldatasett som kan bli funnet i et forretningsapparat for maskinlæring. Valget av datasett for å forhindre forurensning av valideringssettene ble tatt mye hensyn til. For eksempel bruker auto-sklearn en varm start som allerede er trent på et sett med OpenML-datasett. Datasett som disse ble unngått.

Hver av de fire rammene, auto_ml, auto-sklearn, TPOT og H2O ble testet med sine foreslåtte parametere over 10 tilfeldige frø per datasett. F1-score (vektet) og gjennomsnittlig kvadratfeil ble valgt som evalueringskriterier for henholdsvis klassifiserings- og regresjonsproblemer.

En begrensning på 3 timer ble brukt for å begrense hver AutoML-metode til en tidsperiode som gjenspeiler et innledende utforskende søk utført av mange data science-team. Dette resulterer i en estimert beregningstid på 10.440 timer. Som et resultat bestemte vi oss for å evaluere modellene ved å bruke AWSs batch-tjeneste for å håndtere parallellisering av denne oppgaven ved å bruke C4-beregningsoptimaliserte EC2-forekomster som fordeler 2 vCPUer og 4 GB minne per kjøring.

Vi brukte en best-innsats tilnærming for å sikre at alle testene ble fullført og at alle testene hadde minst 3 sjanser til å lykkes innenfor 3 timers grense. I noen tilfeller resulterte AWS Batchs datamiljøer og dockerbasert ressursstyring i uforutsigbar oppførsel. For å få bukt med dette utviklet vi en tilpasset "bare-metal" -tilnærming for å gjenskape AWS Batch på EC2-tilfeller med mer finkornet kontroll over styring av prosessminnet. Spesielt sendte docker-minnebehandleren et drepesignal til referanseprosessen hvis mengden minne som ble brukt av prosessen, overskred mengden som ble tildelt av Batch. Denne harde grensen kan ikke endres uten å øke forekomststørrelsen per kjøring kraftig. Ved å bruke de samme beregningsbegrensningene testet vi kjørene som mislyktes under disse helt spesifikke forholdene på vår tilpassede "bare-metal" -implementering.

Også i løpet av prosessen med å kjøre disse testene, fikset vi noen få feil i open source-rammene som er beskrevet i vår fulle artikkel. Etter disse rettelsene mislyktes ingen av datasettene. Disse feilene ble vanligvis tilslørt fra daglig bruk, men dukket opp i løpet av testskalaen som ble utført.

resultater

Figur 1 beskriver mangfoldet av de valgte datasettene. Du kan se at klassifisering typisk er binær, og antallet regresjonsrekke er relativt ensartet, mens antallet for klassifiseringsrekke er skjevt mot datasett rundt 1000 rader. Funksjonstellingen for både regresjon og klassifisering sentre rundt 10 funksjoner med klassifisering skjevt litt mot 100. Vi tror at denne datagruppen er et representativt utvalg av generelle datavitenskapelige problemer som mange dataforskere vil støte på.

Figur 1: Rå datasettegenskaper fordelt mellom klassifiserings- og regresjonsproblemer

Noen rammer gikk tom for tid på bestemte frø og rammer. Totalt 29 løpskombinasjoner (datasett og frø) ble droppet. Disse løpskombinasjonene ble droppet på tvers av alle rammer for å opprettholde sammenlignbarheten av individuelle rammer. Denne prosessen resulterte i totalt 132 datapunkter (29 * 4) som ble droppet, noe som er omtrent ~ 3% totalt (116/3480 løp).

Figur 2: Framework head to head betyr ytelse på tvers av klassifiseringsdatasett

Figur 3: Framework head to head betyr ytelse på tvers av regresjonsdatasett

Hver ramme ble evaluert på både regresjons- og klassifiseringsdatasett nevnt over. Deres ytelse ble beregnet ved å samle den vektede F1-poengsummen og MSE-score på tvers av datasett etter rammeverk. Hver beregning ble standardisert på basis av datasett på tvers av rammer og skalert fra 0 til 1. Når det gjelder MSE, ble disse verdiene omvendt, noe som betyr at høyere verdier representerer bedre resultater, slik at grafene vil forbli konsistente mellom klassifisering og regresjonsvisualiseringer. Gjennomsnittet for de 10 evaluerte frøene representerer et rammeverk ytelse på et spesifikt datasett. I figur 2 og 3 indikerer mørkere nyanser større ytelsesforskjeller.

Figur 4: Rammeprestasjoner på tvers av alle klassifiseringsdatasett

Figur 5: Rammeprestasjoner på tvers av alle regresjonsdatasett

Vi brukte kasseplott for å demonstrere rammeprestasjoner her i figur 4 og 5. Hakkene i kassetegningene representerer medianens tillitsintervall. Midlene og standardavvikene i tabell 1 viser de nøyaktige forskjellene.

Tabell 1: Presis per rammeresultat

Konklusjon og tolkning

Totalt sett presenterer hver visualisering og tolkning det samme bildet. Auto-sklearn presterer best på klassifiseringsdatasettene og TPOT presterer best på regresjonsdatasett. Det er viktig å legge merke til at de kvantitative resultatene fra dette eksperimentet har ekstremt høye varianser, og som sådan er det sannsynligvis viktigere å tenke på tilstanden til kodebasen, fortsette utvikling, funksjonssett og mål for disse individuelle rammene i stedet for frittstående ytelse. Vi anbefaler både TPOT og auto-sklearn på grunn av disse faktorene og på grunn av vår interaksjon med hvert av lokalsamfunnene deres i løpet av tiden vi arbeidet med denne analysen.

Her er koblingene (Auto-sklearn, TPOT, H2O, Auto_ml), hele papiret og implementeringen av benchmarking.