Att testa en AI-lösning innebär att mäta den mot ett testset av verkliga fall med kända rätta svar, med mått som passar uppgiften och godkännandenivåer som bestämts i förväg, och att köra om samma test vid varje ändring av modell, instruktion eller underlag. Det är samma disciplin som för annan programvara, men svaren är inte bara rätt eller fel: de kan vara mer eller mindre bra, och ibland påhittade.
En AI-lösning utan testset är ett experiment. Med testset är den mjukvara: den kan godkännas, förvaltas och förbättras, och ni märker när den blir sämre innan kunderna gör det.
Varför räcker inte demon?
Därför att demon visar det modellen klarar, inte det den missar. Tänk er att modellen svarar rätt på tio frågor i ett möte. Tio rätt av tio utesluter statistiskt inte att den gör fel i vart femte fall i verkligheten, och skillnaden mellan 90 och 97 procent rätt, som kan avgöra om allt måste granskas eller bara stickprov, syns inte alls.
Demon visar inte heller vad modellen gör när svaret saknas i underlaget. Då kan den hallucinera. Studien Why Language Models Hallucinate från 2025 beskriver hallucinationer som rimliga men felaktiga påståenden som modellen ger när den är osäker, och förklarar dem med att träning och utvärdering belönar gissningar framför ett ärligt "vet inte". Frågor utan svar i testsetet avslöjar beteendet.
I RAND:s intervjustudie The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed från 2024, med 65 erfarna datavetare och ingenjörer, är den första av fem huvudorsaker till misslyckade AI-projekt att organisationen missförstår eller kommunicerar fel vilket problem AI ska lösa, så att modeller optimeras mot fel mått. Ett testset är den mest konkreta definitionen av problemet: det här är indata, det här är rätt svar. Därför hör det hemma bland exitkriterierna när ni designar piloten för produktion.
Steg 1: Bygg testsetet av verkliga fall
Samla verkliga fall från flödet: ärenden, dokument, frågor. Ett riktvärde att utgå från är 100 till 300 fall, men antalet väljer ni själva; frågan om testsetets storlek längst ned visar vad antalet betyder. Ta fallen slumpmässigt, så att fördelningen speglar verkligheten, och lägg medvetet till de svåra: tvetydiga ärenden, dokument med saknade uppgifter och frågor som saknar svar i underlaget. För varje fall skriver en person som kan verksamheten ner det rätta svaret, eller de rätta svaren när flera är acceptabla. Tidsåtgången är antalet fall gånger de minuter det tar att bedöma ett fall.
När fallen innehåller personuppgifter
Att ta bort namnen räcker inte. Går personen fortfarande att peka ut, via ett kundnummer, en adress eller en kombination av datum och ort, är uppgifterna personuppgifter. Det gäller även pseudonymiserade uppgifter, som bara kan kopplas till personen med en separat förvarad nyckel: de förblir personuppgifter, slår Europeiska dataskyddsstyrelsen fast i sina riktlinjer om pseudonymisering. Riktlinjerna antogs i en version för samråd i januari 2025, som per oktober 2026 fortfarande är den publicerade. Samtidigt beskriver styrelsen pseudonymisering som en skyddsåtgärd som hjälper den ansvarige att visa att dataskyddsprinciperna följs. Så kan testdatan tas fram:
- Ta ett slumpmässigt urval verkliga ärenden, med undantagen kvar.
- Byt ut namn, personnummer, kontaktuppgifter och kundnummer mot konsekventa pseudonymer, så att samma kund alltid får samma pseudonym. Förvara nyckeln separat med egen behörighet, så som definitionen i GDPR artikel 4.5 förutsätter.
- Maskera identifierare i fritext, gärna med en modell, och låt en människa stickprova resultatet, till exempel var tionde text.
- Generalisera datum och platser så långt uppgiften tillåter: födelsedatum blir år, adress blir postnummerområde.
- Dokumentera vad som gjorts, vem som har nyckeln och när testdatan ska raderas.
- Hantera testdatan som personuppgifter, med rättslig grund och åtkomstkontroll. För er som har nyckeln är det vad den är.
Syntetisk data kan komplettera för att testa volym och format, men som enda underlag saknar den de verkliga undantag som avgör om lösningen håller.
Steg 2: Välj mått som passar uppgiften
Klassificering, som ärendekategori eller prioritet: andel rätt, gärna per kategori, eftersom ett snitt på 95 procent kan dölja att en kategori bara träffas i hälften av fallen.
Extraktion, som fält ur en order eller ett avtal: andel rätt per fält, med hårdare krav för fält som rör pengar, datum och identiteter. Hur det ser ut i ett orderflöde beskrivs i automatisera orderhantering med AI.
Generering, som svar till kund eller sammanfattningar: här finns inget exakt facit. Använd en bedömningsmall med tre till fem kriterier, som korrekthet mot underlaget, fullständighet, ton och längd, och låt en människa bedöma ett urval. En modell kan bedöma i stor skala: i studien Judging LLM-as-a-Judge (NeurIPS 2023) höll GPT-4 med människors bedömningar i över 80 procent av fallen, lika ofta som människor höll med varandra, men föredrog också längre svar och svar i en viss position. Kalibrera därför modellbedömaren mot människans bedömningar på samma fall.
Avhållsamhet: andelen fall utan svar i underlaget där modellen säger att den inte vet, hellre än gissar. Räkna tre utfall, rätt, fel och avstått, och låt ett fel kosta mer än ett avstående. Med ren rätt-eller-fel-poäng lönar det sig alltid att gissa, visar hallucinationsstudien ovan. Forskarna föreslår i stället en poäng för rätt svar, noll för "vet inte" och minuspoäng för fel; med nio minuspoäng lönar det sig bara att svara när modellen är mer än 90 procent säker. Straffets storlek avgör ni utifrån vad ett fel kostar i ert flöde.
Steg 3: Sätt godkännandenivåerna innan ni testar
Verksamheten, inte teknikerna, bestämmer vad som är bra nog, utifrån vad ett fel kostar. Ett felaktigt förslag som en människa ändå granskar kan tillåtas oftare än ett som går direkt till kund. Skriv ner nivåerna: minst så många procent rätt i kategori, noll fel i betalningsfält, minst så många procent korrekt avhållsamhet. Nivåerna styr också arbetssättet. Ett tänkt exempel: ni bestämmer att en lösning som klarar 97 procent granskas med stickprov, medan en som klarar 85 procent granskas i sin helhet. Båda kan vara rätt beslut, så länge siffrorna är era egna och valda medvetet.
Steg 4: Testa, läs felen, förbättra
Stanna inte vid siffran. Läs varje fel och sortera felen i grupper: en ärendetyp instruktionen inte beskriver, ett datumformat modellen misstolkar, en kategori som liknar en annan. Varje grupp pekar på en förbättring av instruktionen, av underlaget eller av reglerna runt modellen. Först när samma feltyp återkommer trots bättre instruktioner är det dags att pröva en annan modell, eller i undantagsfall finjustering. Testet visar också om en mindre och billigare modell klarar uppgiften lika bra, vilket påverkar vad AI kostar i drift.
Steg 5: Kör om vid varje ändring
Ny modellversion, ändrad instruktion, nytt dokument i underlaget, ny regel: samma testset, samma mått, jämfört med förra körningen. Det är regressionstest, och det gör ett modellbyte till en kontrollerad ändring. Leverantörerna byter ut modeller löpande; Anthropic skriver till exempel i sin policy för modellavveckling att äldre modeller pensioneras regelbundet och att anrop till en pensionerad modell slutar fungera (per oktober 2026). En ny modell kan vara bättre i allmänhet men sämre på just er uppgift, och utan testset märker ni det när kunderna hör av sig.
Steg 6: Fortsätt mäta i drift
Testsetet visar hur lösningen klarar gårdagens fall. Ta därför ett stickprov av produktionsfallen, till exempel varje vecka, bedöm dem på samma sätt och lägg de intressanta i testsetet, så växer det med verksamheten. Stickprovet mäter kvalitet; effekten, sparad tid och färre fel, mäts för sig, se AI ROI. Vem som äger mätningen och vad som händer när lösningen gör fel i drift beskrivs i AI-förvaltning.
Vad krävs för att komma igång?
En person från verksamheten som kan säga vad rätt svar är, tid att bedöma fallen och ett beslut om nivåerna innan första körningen. Bygg testsetet i början av bygget, inte i slutet. Nivåerna går att sätta redan i en AI-förstudie, den första fasen i ett bygge, och testsetet följer sedan lösningen genom AI-utvecklingen och in i drift.
Vill ni veta om er lösning är redo?
Byron Calles bygger AI-lösningar med mätetal och validering mot era krav som en del av bygget. Boka ett samtal om ni vill gå igenom hur testset och godkännandenivåer skulle se ut för ert flöde.
Vanliga frågor
Går det att få bort AI-hallucinationer helt?
Räkna inte med det. Hallucinationer finns kvar även i de mest avancerade språkmodellerna, konstaterar forskarna bakom studien Why Language Models Hallucinate från 2025, så målet är att begränsa dem och hindra att de når kunden. Låt modellen svara ur era egna dokument och data och visa varifrån svaret kommer; enligt samma studie minskar det hallucinationerna, men det tar inte bort dem. Avgränsa uppgiften så att utrymmet att gissa blir litet, låt en människa godkänna i de steg där ett fel får följder, och bygg in att modellen säger att den inte vet och lämnar över ärendet när underlaget saknas. Hur långt åtgärderna räcker i er lösning visar testsetet.
Hur många fall behöver testsetet?
Det väljer ni själva, men räkna på vad antalet betyder, för osäkerheten i en uppmätt andel krymper med antalet fall. Får lösningen 95 rätt av 100 kan den verkliga träffsäkerheten, med ett vanligt 95-procentigt konfidensintervall, ligga någonstans mellan ungefär 89 och 98 procent. Med 285 rätt av 300 krymper spannet till ungefär 92 till 97 procent. Samma räkning gäller kravet på noll fel: noll fel på 100 fall utesluter inte en verklig felfrekvens på omkring 3 procent, och med 300 fall sjunker gränsen till omkring 1 procent. Ju dyrare ett fel är, desto fler fall behövs i de kategorier där felet kan uppstå.
