Maskinlæringssystemer virker litt som et matteproblem. Finn ut algoritmen, trykk inn dataene, og svarene kommer ut.
Men hvordan vet du at svarene er riktige?
Når du prøver å forutsi hvilke filmer eller bøker folk liker, kan det være ekstremt viktig, forskjellen mellom en økning i inntekt og et rykte som vises på mediabuzz.com. Likevel er det sjelden toppen vi tenker på når vi prøver å utvikle og distribuere systemer basert på maskinlæringsalgoritmer. Bare å bygge et godt sett med algoritmer som modellerer problemområdet er vanskelig nok. Men testing er en del av programvareutviklings- og distribusjonsprosessen, og vi må se seriøst på hvordan disse systemene vil bli testet.
Den første, mer vanlige typen testing er hvor applikasjonen er enhetstestet av utviklere, "røyk testet" ved automatisering under bygge- og integrasjonsprosessen, og manuelt testet av testere. Denne prosessen er velkjent, selv om den vil variere avhengig av hvilken type system som utvikles.
Den andre typen testing er basert på virkelige input, som varierer basert på dataene som sendes inn. For eksempel skrev en av Matts kunder programvare for å begrense risikoen i finansielle transaksjoner. Programvaren vil analysere markedet og sakte slappe av en aksjeblokk over en periode på dager, designet for ikke å sette i gang advarsler på salgssiden. Den første innspillingen var selgen, men den andre sanntidsinnsatsen var finansmarkedene, som varierer over tid, slik at salg i test ikke vil matche salg i produksjon. Det er her testing blir mer problematisk. Hvordan tester vi systemer som kan gi et annet resultat tilbake til de samme dataene over tid? Tradisjonelle testteknikker har ingen måte å ta et slikt resultat i betraktning. Så hva skal testere gjøre?
Å teste maskinlæringssystemer kvalitativt er ikke det samme som å teste andre typer programvare. I de fleste testsituasjoner prøver du å forsikre deg om at den faktiske produksjonen samsvarer med forventet. Med maskinlæringssystemer er det akkurat feil tilnærming å lete etter nøyaktig riktig resultat. Du kan sannsynligvis ikke engang beregne “riktig utgang” uten å skrive programvaren to ganger. Selv da er det kanskje ikke mulig.
Hva testere trenger å fokusere på for maskinlæringsapplikasjoner:
1. Ha objektive og målbare akseptkriterier. Kjenn til standardavviket du kan akseptere i ditt problemrom. Dette krever litt kvantitativ informasjon, og evnen til å sørge for at du forstår og tolker disse målingene.
2. Test med nye data, i stedet for de originale treningsdataene. Del eventuelt treningssettet ditt i to grupper: en som trener og en som prøver. Bedre, skaff og bruk ferske data hvis du er i stand til det.
3. Ikke stol på at alle resultatene er nøyaktige; tenk på dem som den beste gjetningen basert på tilgjengelige data. Hvis det ikke er bra nok, kan problemet være fødselsdatoen eller, mer sannsynlig, datasettet. I noen tilfeller kan "finjustering" av datasettet for å få rene input være den raskeste løsningen på dette problemet.
4. Forstå arkitekturen til nettverket som en del av testprosessen. Testere vil ikke nødvendigvis forstå hvordan nevrale nettverk ble konstruert, men trenger å forstå om det oppfyller kravene. Og basert på målingene de tester, må de kanskje anbefale en helt annen tilnærming, eller innrømme at programvaren bare ikke er i stand til å gjøre det den ble bedt om å gjøre med tillit.
Bunnlinjen
Nøkkelen til å teste systemet er å forstå både kravene til produksjonsresultatene og begrensningene til algoritmene. Kravene må oversettes til objektive målinger; ideelt sett er standardavviket til gjennomsnittsresultatet, forutsatt at gjennomsnittsresultatet er nært knyttet til det faktiske resultatet som finnes i treningsdataene. Du må kunne vurdere resultatene dine fra et statistisk synspunkt, i stedet for et ja-nei-synspunkt.
Ikke stol på et nøyaktig riktig svar hele tiden, eller til og med mesteparten av tiden. Hvordan du tester, og hvordan du vurderer, avhenger helt av systemets mål. For testens muttere og bolter er det uvurderlig å ha en plattform som Intel Parallel Studio XE for både å utvikle og teste kode og algoritmer.
Nå er det enklere enn noensinne å skrive koden din for å kjøre parallelt - Prøv Intel® Parallel Studio XE gratis i 30 dager
