Maskinindlæringssystemer virker lidt som et matematisk problem. Find ud af algoritmen, pop ind i dataene, og svarene kommer ud.
Men hvordan ved du, at svarene er rigtige?
Når du prøver at forudsige, hvilke film eller bøger folk kan lide, kan det være ekstremt vigtigt, forskellen mellem et løft i indtægterne og et omdømmehit, der vises på mediabuzz.com. Alligevel er test sjældent øverst på vores hjerne, når vi prøver at udvikle og implementere systemer baseret på maskinlæringsalgoritmer. Det er svært nok bare at opbygge et godt sæt algoritmer, der modellerer problemområdet. Men test er en del af softwareudviklings- og implementeringsprocessen, og vi skal seriøst se på, hvordan disse systemer vil blive testet.
Den første, mere almindelige type test er, hvor applikationen er enhedstestet af udviklere, "røgtestet" ved automatisering under bygge- og integrationsprocessen og manuelt testet af testere. Denne proces er velkendt, selvom den vil variere afhængigt af typen af system, der udvikles.
Den anden type test er baseret på input fra den virkelige verden, som varierer afhængigt af de data, der sendes ind. For eksempel skrev en af Matts kunder software for at begrænse risikoen i finansielle transaktioner. Softwaren ville analysere markedet og langsomt slappe af en blok af aktier over en periode på dage, designet til ikke at starte advarsler på salgssiden. Det første input var blokken, der skulle sælges, men det andet input i realtid var de finansielle markeder, der varierer over tid, så salget i test vil ikke matche salget i produktionen. Det er her testning bliver mere problematisk. Hvordan tester vi systemer, der muligvis returnerer et andet resultat til de samme data over tid? Traditionelle testteknikker har ingen mulighed for at tage et sådant resultat i betragtning. Så hvad skal testere gøre?
At teste maskinlæringssystemer kvalitativt er ikke det samme som at teste andre typer software. I de fleste testsituationer forsøger du at sikre dig, at den faktiske output svarer til den forventede. Med maskinlæringssystemer er det nøjagtigt den forkerte tilgang at lede efter nøjagtigt det rigtige output. Du kan sandsynligvis ikke engang beregne den "rigtige output" uden at skrive softwaren to gange. Selv da er det måske ikke muligt.
Hvad testere har brug for at fokusere på til maskinlæringsapplikationer:
1. Har objektive og målbare acceptkriterier. Kend til standardafvigelsen, du kan acceptere i dit problemrum. Dette kræver nogle kvantitative oplysninger og evnen til at sikre, at du forstår og fortolker disse målinger.
2. Test med nye data snarere end de originale træningsdata. Opdel om nødvendigt dit træningssæt i to grupper: en der træner og en der prøver. Bedre, skaff og brug nye data, hvis du er i stand til det.
3. Stol ikke på, at alle resultater er nøjagtige; tænk på dem som det bedste gæt baseret på de tilgængelige data. Hvis det ikke er godt nok, kan problemet være alogirthmn eller mere sandsynligt datasættet. I nogle tilfælde kan "finjustering" af datasættet for at få rent input være den hurtigste løsning på dette problem.
4. Forstå netværksarkitekturen som en del af testprocessen. Testere forstår ikke nødvendigvis, hvordan det neurale netværk blev konstrueret, men har brug for at forstå, om det opfylder kravene. Og baseret på de målinger, som de tester, skal de muligvis anbefale en radikalt anden tilgang eller indrømme, at softwaren bare ikke er i stand til at gøre, hvad den blev bedt om at gøre med tillid.
Bundlinjen
Nøglen til at teste systemet er at forstå både kravene til produktionsresultaterne og algoritmernes begrænsninger. Kravene skal oversættes til objektive målinger; ideelt set er standardafvigelsen for middelresultatet, forudsat at middelresultatet er tæt knyttet til det faktiske resultat, der findes i træningsdataene. Du skal være i stand til at vurdere dine resultater fra et statistisk synspunkt snarere end et ja-nej-synspunkt.
Stol ikke på et nøjagtigt rigtigt svar hele tiden eller endda det meste af tiden. Hvordan du tester, og hvordan du evaluerer, afhænger helt af systemets mål. For testens møtrikker og bolte er det uvurderligt at have en platform som Intel Parallel Studio XE til både at udvikle og teste kode og algoritmer.
Nu er det nemmere end nogensinde før at skrive din kode til at køre parallelt - Prøv Intel® Parallel Studio XE gratis i 30 dage
