Att få ett svar från en AI-modell betyder inte i sig att systemet fungerar korrekt. I klassisk mjukvara kan vi ofta entydigt kontrollera om en funktion returnerade det förväntade resultatet. I AI-system kan svaret vara flytande, logiskt och övertygande, men ändå innehålla fel.
Därför uppstår med AI:s utveckling ett nytt ingenjörsproblem: hur mäter man systematiskt kvaliteten på ett system vars svar inte alltid är identiska?
Detta är just området AI evaluation, alltså utvärdering av system för artificiell intelligens.
Och det är mycket bredare än att kontrollera om en chatbot ”svarar bra”.
Test av klassisk mjukvara och test av AI är inte samma sak
Låt oss föreställa oss en enkel funktion i en app.
Användaren skriver in: 2 + 2
Systemet ska returnera: 4
Om det returnerar 5 har vi ett entydigt fel.
Vi kan förbereda ett test: expect(calculate("2 + 2")).toBe(4)
och varje gång få ett tydligt resultat: testet passerar eller underkänns.
I AI-system ser situationen annorlunda ut.
Användaren kan fråga: ”Skriv ett kort svar till en kund som frågar om leveranstiden för sin beställning.”
Systemet kan generera flera olika svar. Alla kan vara språkligt korrekta. Alla kan låta professionella. Men ett kan innehålla en felaktig leveranstid, ett annat kan vara för långt, ett tredje kan utelämna viktig information och ett fjärde kan vara perfekt.
Det räcker alltså inte att kontrollera om svaret har genererats tekniskt.
Man måste kontrollera, om det uppfyller bestämda kvalitetskriterier.
Första problemet: ett bra svar är inte alltid sant
Detta är en av de mest karakteristiska egenskaperna hos generativ AI.
Modellen kan generera ett svar som låter mycket övertygande, men som inte stöds av källdata.
I fallet med ett system som använder RAG blir problemet ännu intressantare. Systemet kan få en fråga, söka i flera dokumentationsfragment och sedan generera ett svar.
Då måste man kontrollera åtminstone tre saker:
- Hittades rätt information? Hämtade sökningen fragment som verkligen var relaterade till frågan?
- Använder svaret den information som hittades? Har modellen inte lagt till något som inte fanns i källorna?
- Svarar svaret verkligen på frågan? Man kan nämligen ha en korrekt fungerande retrieval, men ett dåligt slutligt svar.
Just därför delar RAG-utvärdering bland annat upp sådana aspekter som relevansen hos det hämtade sammanhanget, sökningens fullständighet, svarets korrekthet och dess överensstämmelse med källorna.
Detta är en viktig förändring i sättet att tänka kring testning.
Vi testar inte längre bara: fråga → svar
utan hela kedjan: fråga → sökning → kontext → modell → svar
Man kan ha en bra modell och ett dåligt AI-system
Detta är en annan sak som lätt glöms bort.
Ett företag kan välja en mycket bra språkmodell och ändå skapa en dålig AI-produkt.
Varför? För att kvaliteten på det slutliga systemet inte bara beror på modellen.
Även följande spelar roll:
- datakvalitet,
- sättet kontexten förbereds på,
- prompten,
- sättet information söks på,
- modellens parametrar,
- verktyg som görs tillgängliga för AI,
- applikationens logik,
- minne,
- sättet fel hanteras på,
- säkerhetsåtgärder,
- sättet svar bedöms på.
Det betyder att frågan: ”Vilken modell är bäst?”
ofta är mindre användbar än: ”Vilken modell fungerar bäst i vårt specifika användningsfall?”
En modell som är utmärkt på att generera marknadsföringstexter behöver inte vara den bästa lösningen för dokumentklassificering, dataanalys eller hantering av affärsprocesser.
Därför bör modelljämförelser göras på verkliga uppgifter som systemet ska utföra.
Först måste man skapa sitt eget testset
Det går inte att på ett meningsfullt sätt utvärdera ett AI-system om vi inte vet vad vi förväntar oss av det.
Därför är en av de viktigaste delarna i utvärderingen att förbereda en testdataset, alltså en uppsättning verkliga eller representativa fall.
Till exempel bygger ett företag AI för kundsupportavdelningen.
I stället för att manuellt kontrollera ett svar efter varje promptändring kan man förbereda flera hundra fall:
- enkla frågor,
- otydliga frågor,
- frågor med felaktiga antaganden,
- frågor som kräver sökning i ett dokument,
- frågor om undantag,
- frågor om reklamationer,
- frågor som kräver avslag,
- frågor som innehåller data som AI inte bör avslöja.
Varje ändring i systemet kan sedan köras mot samma uppsättning.
Och just här börjar AI likna klassisk mjukvara.
Vi testar inte längre ett enskilt svar. Vi testar systemets beteende över hela uppsättningen fall.
Prompten kan också testas
Prompten behandlas ofta som en text som någon skrev en gång och lämnade i produktion.
I verkligheten kan den vara en del av applikationens logik.
Att ändra en enda mening kan orsaka:
- förbättring av svaret i ett scenario,
- försämring av svaret i ett annat,
- större benägenhet att neka,
- fler hallucinationer,
- längre svar,
- högre kostnad,
- större tokenförbrukning.
Därför bör prompten behandlas på liknande sätt som kod.
Om vi ändrar prompten är det värt att veta:
- vad förbättrades?
- vad försämrades?
- uppstod en regression?
Just därför blir automatisk utvärdering allt viktigare, inte manuell bedömning av några exempelsvar.
AI kan klara testet och ändå vara en dålig produkt
Anta att vi har förberett 100 testfall.
Systemet svarade korrekt på 95. Resultatet ser fantastiskt ut. Men vad händer om de fem felaktiga svaren gäller kritiska situationer?
Om en chatbot svarar på frågor om öppettider kan fem fel vara ett problem.
Om AI hjälper en anställd att analysera finansiella, medicinska eller juridiska dokument kan betydelsen av dessa fel vara helt annorlunda.
Därför räcker inte ett medelvärde.
Vi behöver också viktning av fall.
Vi kan anta att:
- en vanlig fråga har vikten 1,
- ett betydande fel har vikten 5,
- ett säkerhetsfel har vikten 10,
- avslöjande av konfidentiell information har vikten 100.
Då får systemet inte ”95 procent”. Vi får en mycket mer användbar bild av riskerna.
Allt kan inte mätas med ett enda tal
Det här är ett av de viktigaste problemen inom AI-utvärdering.
Vi kan ha flera metriker:
- Accuracy - är svaret korrekt?
- Relevance - svarar det på frågan?
- Faithfulness / groundedness - bygger det på de tillhandahållna källorna?
- Context precision - är de hämtade fragmenten relevanta?
- Context recall - hittade systemet den information som behövdes?
- Safety - utför det inga oönskade åtgärder?
- Latency - hur länge väntar användaren?
- Cost - hur mycket kostar det att utföra uppgiften?
RAG kan alltså ha mycket god svarskvalitet, men samtidigt hämta in enorma mängder kontext och generera en oacceptabel kostnad.
Ett annat system kan vara mycket billigt och snabbt, men göra för många misstag.
Det finns alltså inget enda universellt tal som avgör om AI är ”bra”. Kvalitet måste definieras i förhållande till den specifika användningen.
Och vad med att utvärdera AI med annan AI?
Här dyker ytterligare en intressant mekanism upp.
Ett sätt att automatisera utvärdering är att använda modellen som domare, alltså LLM-as-a-judge.
Till exempel:
Modell A genererar ett svar.
Modell B får frågan, svaret och de angivna kriterierna.
Sedan bedömer den:
- korrekthet,
- överensstämmelse med instruktionen,
- fullständighet,
- stil,
- säkerhet.
Moderna utvärderingsverktyg gör det också möjligt att kombinera sådan bedömning med klassiska textjämförelser, egna skript eller graderare baserade på specifika regler.
Det ökar testningsskalan enormt. Men det betyder inte att människan slutar behövas. Den utvärderande modellen kan också ha fel. Därför är det i system med större affärsmässig betydelse värt att kombinera automatiska utvärderingar med periodisk expertbedömning.
Det största problemet: regression
Låt oss föreställa oss ett system som fungerar mycket bra. Teamet byter modell till en nyare. Den nya versionen är snabbare och billigare. Det verkar alltså som att allt går åt rätt håll.
Efter driftsättning visar det sig dock att:
- svaren är mindre precisa,
- modellen vägrar oftare att svara,
- den använder dokumentationen sämre,
- den tolkar instruktioner annorlunda,
- i vissa scenarier börjar den ge felaktig information.
Detta är just AI regression.
Inom klassisk mjukvara känner vi till regression sedan länge. I AI måste vi också upptäcka den, men problemet är svårare eftersom systemets beteende kan förändras utan ett klassiskt ”fel”. Därför bör varje större ändring jämföras med den tidigare versionen.
Modell.
Prompt.
Embedding.
Retriever.
Dokumentation.
Agentlogik.
Parametrar.
Var och en av dessa delar kan påverka resultatet.
En agent räcker inte att utvärdera utifrån sitt slutliga svar
Det blir ännu svårare när det gäller AI-agenter.
En klassisk chatbot kan utföra en enda uppgift: fråga → svar.
En agent kan fungera helt annorlunda: mål → plan → verktyg → resultat → nästa steg → beslut → handling → svar.
Om agenten inte uppnådde målet vill vi inte bara veta att den förlorade.
Vi vill veta: var gjorde den fel?
- Förstod den uppgiften fel?
- Valde den fel verktyg?
- Skickade den fel parameter?
- Hämtade den fel data?
- Tog den ett dåligt beslut efter att ha fått resultatet?
- Utförde den för många steg?
- Stannade den för tidigt?
Inom forskningen om utvärdering av agenter analyserar man allt oftare inte bara slutresultatet, utan också förloppet, verktygsanvändningen, planeringen, minnet, tillförlitligheten och säkerheten.
Det betyder att framtiden för testning av AI i hög grad kommer att vara kopplad till analys av trace'ar, alltså hela systemets körförlopp.
AI behöver något som liknar CI/CD
Om AI är en del av produkten kan man inte testa den bara före den första driftsättningen.
Systemet kommer att förändras.
Modellen kommer att ändras.
Prompten kommer att ändras.
Kunskapsbasen kommer att ändras.
Sättet att söka kommer att ändras.
Konfigurationen kommer att ändras.
Därför bör utvärdering bli en del av utvecklingsprocessen.
Schemat kan se ut så här: ändring → tester → utvärdering → jämförelse med föregående version → beslut om driftsättning
Om den nya versionen förbättrar kvaliteten inom ett område men överskrider den fastställda feltröskeln i ett annat, kan driftsättningen stoppas.
Det är en mycket liknande filosofi som klassisk CI/CD, men kriterierna är andra.
I fallet med AI-applikationer kan vi samtidigt kontrollera svarskvalitet, korrekthet, säkerhet, kostnad och latens. Det finns redan forskningslösningar som kombinerar utvärdering med observability och kvalitetsgrindar i processen för driftsättning av LLM/RAG-system.
Kan man alltså testa AI på samma sätt som klassisk mjukvara?
Ja, men bara delvis.
Det klassiska angreppssättet behövs fortfarande.
Vi testar:
- API:er,
- integrationer,
- behörigheter,
- datavalidering,
- fel,
- timeoutar,
- säkerhet,
- prestanda,
- applikationslogik.
Men där kan vi inte sluta.
Det kommer ett andra lager: utvärdering av AI:s beteende.
- Är svaret korrekt?
- Stämmer det med källorna?
- Följer modellen instruktionerna?
- Beter sig systemet korrekt i oväntade situationer?
- Väljer agenten rätt verktyg?
- Har den nya versionen inte försämrat kvaliteten?
- Är driftskostnaden fortfarande acceptabel?
- Får användaren faktiskt ett värde?
Det här är inte längre ett klassiskt unit test.
Det bästa AI-testet är inte alltid ett laboratorietest
Det finns ytterligare en mycket viktig del.
Systemet kan prestera utmärkt på en förberedd testmängd och ändå ha problem i den verkliga världen. Därför är det värt att också observera verkliga interaktioner. Inte för att varje användare ska vara testare. Det handlar om att systemet ska kunna förbättras löpande utifrån verkliga fall:
- där användare rättar AI,
- där de ber om att få svaret upprepat,
- där de avbryter konversationen,
- där de eskalerar ärendet till en människa,
- där agenten inte uppnår målet,
- där ovanliga frågor dyker upp.
På så sätt uppstår en kontinuerlig utvärderingsloop: användare → AI-handling → resultat → analys → nytt testfall → nästa version av systemet
Det är en helt annan utvecklingsmodell än det en gångsvisa ”vi har implementerat AI och det fungerar”.
AI bör inte bedömas med frågan ”fungerar det?”
Det är för lite.
Bättre frågor är:
- Hur ofta fungerar det korrekt?
- I vilka situationer gör det fel?
- Hur allvarliga är dessa fel?
- Är den nya versionen bättre än den föregående?
- Är systemet tillräckligt säkert?
- Är svaren baserade på rätt data?
- Hur mycket kostar det att uppnå ett visst resultat?
Först med en sådan uppsättning frågor kan man tala om ett moget AI-system.
Den viktigaste förändringen i tankesättet
I åratal gällde en enkel regel inom mjukvaruutveckling: koden ska fungera.
I AI-system måste den utökas: systemet ska fungera bra, förutsägbart och mätbart.
Det är en enorm skillnad. För AI är inte en funktion som alltid ger samma resultat. Det är ett probabilistiskt system vars beteende beror på modellen, data, kontexten, instruktionerna och hela arkitekturen runt omkring det.
Därför slutar en professionell AI-implementering inte i samma ögonblick som modellen börjar svara.
Då börjar frågan först: hur vet vi att vi kan lita på den?
Och just den frågan bör en väl utformad utvärdering besvara.
I framtiden kommer testning av AI-system sannolikt att bli lika naturlig del av utvecklingsprocessen som enhetstester, integrationstester eller övervakning. Inte för att AI är ”farligt per definition”. Utan helt enkelt för att ett system vars resultat inte alltid är deterministiskt kräver ett annat sätt att mäta kvalitet.
Och ju mer AI går från att generera text till att hantera verkliga processer, använda data, RAG och utföra handlingar genom agenter, desto viktigare blir inte bara frågan ”kan AI göra det?”, utan också: ”kan vi bevisa att det gör det tillräckligt bra?”
