Slik vet du om AI-systemet ditt faktisk virker
Evaluering
Nesten alle AI-systemer ser bra ut i demo, fordi demoen kjører de eksemplene som ble prøvd ut mens systemet ble bygget. Problemene ligger i halen: henvendelsene ingen tenkte på, og dokumentene som mangler et felt.
Spørsmålet er ikke om systemet kan gjøre oppgaven, men hvor ofte det ikke gjør den, og hva som skjer neste gang noen endrer en prompt.
3 spørsmål en evaluering må kunne svare på
- Hvor ofte er svaret riktig, målt på noe annet enn magefølelse?
- Når det er feil, er det feil på en måte brukeren oppdager, eller på en måte som ser riktig ut?
- Ble det bedre eller dårligere enn forrige versjon?
Det tredje er viktigst, og mangler oftest. Uten det er hver endring et sjansespill, og team som ikke kan svare slutter til slutt å endre noe.
Løkka
Det som gjør løkka verdt noe er den stiplede linjen tilbake. Hver feil dere finner i produksjon legges inn i datasettet. Etter et halvår beskriver datasettet presist det systemet deres har vært dårlig på.
Start med 30 eksempler
Evaluering blir oftest ikke gjort fordi folk tror det krever tusen merkede eksempler. 30 eksempler valgt fordi de er vanskelige, sier mer enn tusen tilfeldige.
Sett dem sammen før dere bygger, så beskriver de oppgaven og ikke løsningen. Ta med de kjedelige: tom input, feil språk, spørsmål systemet ikke skal svare på.
Velg metode etter hva feilen koster
| Type oppgave | Hvordan måle | Hva det krever |
|---|---|---|
| Ett riktig svar | Eksakt treff mot fasit | Nesten ingenting |
| Svaret er tekst | En modell vurderer mot et referansesvar | Referansesvar må skrives én gang |
| Feilen er dyr | Samplet gjennomgang av mennesker | Noen timer i uka fra fagfolk |
Den andre raden har to forbehold. En dommer fra samme modellfamilie liker gjerne sin egen stil, og en dommer uten fasit vurderer om svaret ser fornuftig ut, ikke om det er sant. Derfor referansesvaret.
Sett en terskel og la den blokkere
En evaluering som bare produserer en rapport, er en rapport. Verdien kommer når den kan si nei.
Regelen kan være så enkel som dette: faller treffraten mer enn 2 prosentpoeng fra forrige kjøring, går ikke endringen ut. Marginen er der med vilje, for en terskel uten slingringsmonn blokkerer på støy til noen skrur den av.
Ta med Tiden fra forespørselen sendes til svaret er ferdig. Halen betyr ofte mer enn snittet: p95 er tiden de tregeste fem prosentene venter. i samme regel. Et snitt på 2 sekunder kan skjule at hver tjuende bruker venter i femten, og det er den tjuende brukeren som ringer.
Hva dette gjør mulig
Poenget er ikke et tall til styret. Det er at dere kan endre ting: bytte modell, skrive om en prompt, kutte et steg, uten å lure på om dere ødela noe. Team som kan måle, tør å optimalisere. Team som ikke kan, betaler for det hver måned.