Testdata i en søknad om AI-utvikling
En god treffprosent er lite verdt hvis testen bruker kjente eksempler eller overser de feilene kunden ikke kan akseptere.
Oppdatert
Forklar hva modellen må håndtere
Beskriv de faktiske situasjonene løsningen skal brukes i: datakilder, variasjon, sjeldne hendelser og hva som skjer når modellen tar feil. Dette gir et bedre utviklingsgrunnlag enn en generell ambisjon om å «øke nøyaktigheten».
Skille mellom trening, valg under utviklingen og avsluttende test er en sentral del av et troverdig forsøksopplegg. Googles fagveiledning om datasett forklarer blant annet hvorfor gjenbruk og duplikater kan gjøre resultatet misvisende. Hvordan skillet skal gjøres i deres prosjekt, må vurderes faglig.
Beskriv datagrunnlaget som en del av metoden
| Forhold | Spørsmål som må besvares |
|---|---|
| Opprinnelse | Hvor kommer dataene fra, og har dere rett til å bruke dem? |
| Representasjon | Hvilke brukssituasjoner finnes, og hvilke mangler? |
| Separasjon | Kan samme objekt eller nesten identiske data havne på begge sider av testen? |
| Fasit | Hvem har vurdert riktig svar, og hvor er det usikkerhet? |
| Feil | Hvilke feiltyper måles hver for seg? |
En søknad trenger ikke gjengi hele datasettet. Den bør gjøre datagrunnlagets betydning og begrensninger forståelig.
Eksempel: bilder fra samme produksjonsserie
Et oppdiktet selskap vil oppdage overflatefeil. Flere bilder viser samme komponent fra nesten samme vinkel. Hvis noen av bildene brukes i trening og andre i test, kan modellen få hjelp av likheten uten å håndtere nye komponenter godt.
Fagteamet bør derfor undersøke om oppdelingen må skje etter komponent, serie eller annet relevant nivå. En tilfeldig fordeling av enkeltbilder er ikke nødvendigvis en god test av den virkelige oppgaven.
Hvis oversette feil er kritiske, må disse vises separat fra unødvendige alarmer. Én samlet prosent kan skjule en uakseptabel feiltype.
Avklar hva prosjektet faktisk skal lære
Er usikkerheten knyttet til en ny modell, datatilgang, merking, kombinasjon av metoder eller overføring til et nytt driftsmiljø? Beskriv hvilke alternativer som undersøkes og hva som gjør kjent praksis utilstrekkelig.
Bruk av AI er ikke alene FoU. Forskningsrådets SkatteFUNN-veiledning beskriver søknadsrammen. Tekniske, rettslige og sikkerhetsmessige krav må håndteres i tillegg med riktig kompetanse.
Budsjetter testing, ikke bare modellbygging
Innsamling, merking, faglig kontroll og nye forsøk kan kreve betydelig arbeid. Skille forsøksaktivitetene fra ordinær drift og kundestøtte. Hvis nødvendig datatilgang ikke er avklart, skal det framgå som en risiko med en konkret neste handling.
Les fra kundekrav til FoU-hypotese og testplan for prototypen. En rådgiver kan strukturere beskrivelsen; den faglige vurderingen av data og metode må fortsatt eies av prosjektets tekniske ansvarlige.