Det at få et svar fra en AI-model betyder ikke i sig selv, at systemet fungerer korrekt. I klassisk software kan vi ofte entydigt tjekke, om en funktion returnerede det forventede resultat. I AI-systemer kan svaret være flydende, logisk og overbevisende og alligevel indeholde fejl.
Derfor opstår der med AI's udvikling et nyt ingeniørmæssigt problem: hvordan måler man systematisk kvaliteten af et system, hvis svar ikke altid er identiske?
Det er netop området AI evaluation, altså evaluering af kunstig intelligens-systemer.
Og det er langt bredere end at tjekke, om en chatbot „svarer godt”.
Test af klassisk software og test af AI er ikke det samme
Lad os forestille os en simpel funktion i en app.
Brugeren indtaster: 2 + 2
Systemet bør returnere: 4
Hvis det returnerer 5, har vi en entydig fejl.
Vi kan lave en test: expect(calculate("2 + 2")).toBe(4)
og hver gang få et klart resultat: testen består eller fejler.
I AI-systemer ser situationen anderledes ud.
Brugeren kan spørge: „Skriv et kort svar til en kunde, der spørger om leveringstiden for ordren.”
Systemet kan generere flere forskellige svar. Alle kan være sprogligt korrekte. Alle kan lyde professionelle. Men ét kan indeholde en forkert leveringstid, et andet kan være for langt, et tredje kan udelade vigtig information, og et fjerde kan være perfekt.
Det er derfor ikke nok bare at tjekke, om svaret er teknisk genereret.
Man skal tjekke, om det opfylder bestemte kvalitetskriterier.
Første problem: Et godt svar er ikke altid sandt
Det er en af de mest karakteristiske egenskaber ved generativ AI.
Modellen kan generere et svar, der lyder meget overbevisende, men som ikke har dækning i kildedataene.
I et system, der bruger RAG, er problemet endnu mere interessant. Systemet kan få et spørgsmål, søge efter flere uddrag i dokumentationen og derefter generere et svar.
Så skal man som minimum tjekke tre ting:
- Er de rigtige oplysninger fundet? Har søgemekanismen hentet uddrag, der faktisk er relevante for spørgsmålet?
- Bruger svaret de fundne oplysninger? Har modellen ikke tilføjet noget, som ikke fandtes i kilderne?
- Svarer svaret faktisk på spørgsmålet? Man kan nemlig have et korrekt fungerende retrieval, men et dårligt endeligt svar.
Derfor adskiller evaluering af RAG blandt andet sådanne aspekter som relevansen af den hentede kontekst, søgefuldstændighed, svarets korrekthed og dets overensstemmelse med kilderne.
Det er en vigtig ændring i måden at tænke test på.
Vi tester ikke længere kun: spørgsmål → svar
men hele kæden: spørgsmål → søgning → kontekst → model → svar
Man kan have en god model og et dårligt AI-system
Det er endnu en ting, man let glemmer.
En virksomhed kan vælge en meget god sprogmodel og alligevel skabe et svagt AI-produkt.
Hvorfor? Fordi kvaliteten af det endelige system ikke kun afhænger af modellen.
Også følgende tæller:
- datakvalitet,
- måden konteksten forberedes på,
- prompten,
- måden information søges på,
- modelparametre,
- værktøjer stillet til rådighed for AI,
- applikationens logik,
- hukommelse,
- måden fejl håndteres på,
- sikkerhedsforanstaltninger,
- måden svar vurderes på.
Det betyder, at spørgsmålet: „Hvilken model er bedst?”
ofte er mindre nyttigt end: „Hvilken model fungerer bedst i vores konkrete brugsscenarie?”
En model, der er fremragende til at generere marketingindhold, behøver ikke være den bedste løsning til dokumentklassificering, dataanalyse eller håndtering af forretningsprocesser.
Derfor bør sammenligning af modeller ske på virkelige opgaver, som systemet skal udføre.
Først skal man lave sit eget testsæt
Det giver ikke mening at evaluere et AI-system, hvis vi ikke ved, hvad vi forventer af det.
Derfor er et af de vigtigste elementer i evaluering at forberede et testdataset, altså et sæt virkelige eller repræsentative cases.
For eksempel bygger en virksomhed AI til kundeserviceafdelingen.
I stedet for manuelt at tjekke ét svar efter hver promptændring kan man forberede flere hundrede cases:
- simple spørgsmål,
- tvetydige spørgsmål,
- spørgsmål med forkerte antagelser,
- spørgsmål, der kræver opslag i et dokument,
- spørgsmål om undtagelser,
- spørgsmål om reklamationer,
- spørgsmål, der kræver et afslag,
- spørgsmål, der indeholder data, som AI ikke bør afsløre.
Hver ændring i systemet kan derefter køres på det samme sæt.
Og netop her begynder AI at minde om klassisk software.
Vi tester ikke længere et enkelt svar. Vi tester systemets adfærd på hele sættet af cases.
Prompten kan også testes
En prompt bliver ofte behandlet som en tekst, nogen skrev én gang og lod blive i produktion.
I virkeligheden kan den være en del af applikationens logik.
En ændring af én sætning kan føre til:
- bedre svar i ét scenarie,
- dårligere svar i et andet,
- større tilbøjelighed til at afvise,
- flere hallucinationer,
- længere svar,
- højere omkostninger,
- større tokenforbrug.
Derfor bør prompten behandles på samme måde som kode.
Hvis vi ændrer prompten, er det værd at vide:
- hvad blev bedre?
- hvad blev dårligere?
- opstod der en regression?
Det er netop derfor, automatisk evaluering får stadig større betydning, frem for manuel vurdering af nogle få eksemplariske svar.
AI kan bestå testen og stadig være et dårligt produkt
Lad os antage, at vi har forberedt 100 testcases.
Systemet svarede korrekt på 95. Resultatet ser fantastisk ud. Men hvad hvis de fem forkerte svar vedrører kritiske situationer?
Hvis chatbotten svarer på spørgsmål om åbningstider, kan fem fejl være et problem.
Hvis AI hjælper en medarbejder med at analysere finansielle, medicinske eller juridiske dokumenter, kan betydningen af disse fejl være helt anderledes.
Derfor er gennemsnittet alene ikke nok.
Vi har også brug for vægtning af cases.
Vi kan antage, at:
- et almindeligt spørgsmål har vægt 1,
- en væsentlig fejl har vægt 5,
- en sikkerhedsfejl har vægten 10,
- afsløring af fortrolige oplysninger har vægten 100.
Så får systemet ikke „95 procent”. Vi får et langt mere brugbart billede af risikoen.
Ikke alt kan måles med ét tal
Dette er et af de vigtigste problemer i AI-evaluering.
Vi kan have flere metrikker:
- Accuracy - er svaret korrekt?
- Relevance - svarer det på spørgsmålet?
- Faithfulness / groundedness - bygger det på de leverede kilder?
- Context precision - er de søgte uddrag relevante?
- Context recall - fandt systemet de nødvendige oplysninger?
- Safety - udfører det ikke uønskede handlinger?
- Latency - hvor længe venter brugeren?
- Cost - hvor meget koster det at udføre opgaven?
RAG kan altså have meget god svarskvalitet, men samtidig hente en enorm mængde kontekst og generere en uacceptabel omkostning.
Et andet system kan være meget billigt og hurtigt, men begå for mange fejl.
Der findes altså ikke ét universelt tal, der afgør, om AI er „god”. Kvalitet skal defineres i konteksten af den konkrete anvendelse.
Og hvad med at vurdere AI med anden AI?
Her opstår endnu en interessant mekanisme.
En af måderne at automatisere evaluering på er at bruge en model som dommer, altså LLM-as-a-judge.
For eksempel:
Model A genererer et svar.
Model B får spørgsmålet, svaret og de fastsatte kriterier.
Derefter vurderer den:
- korrekthed,
- overensstemmelse med instruktionen,
- fuldstændighed,
- stil,
- sikkerhed.
Moderne evalueringsværktøjer gør det også muligt at kombinere sådan vurdering med klassiske tekstsammenligninger, egne scripts eller gradere baseret på specifikke regler.
Det øger testskalaen enormt. Men det betyder ikke, at mennesket ikke længere er nødvendigt. Den model, der vurderer, kan også tage fejl. Derfor er det i systemer med større forretningsmæssig betydning værd at kombinere automatiske evalueringer med periodisk ekspertvurdering.
Det største problem: regression
Lad os forestille os et system, der fungerer rigtig godt. Teamet skifter modellen til en nyere. Den nye version er hurtigere og billigere. Det ser derfor ud til, at alt går i den rigtige retning.
Efter implementeringen viser det sig dog, at:
- svarene er mindre præcise,
- modellen afslår oftere at svare,
- den bruger dokumentationen dårligere,
- den fortolker instruktioner anderledes,
- i nogle scenarier begynder den at give forkerte oplysninger.
Det er netop AI regression.
I klassisk software har vi kendt regression i årevis. I AI skal vi også opdage den, men problemet er vanskeligere, fordi systemets adfærd kan ændre sig uden en klassisk „fejl”. Derfor bør enhver større ændring sammenlignes med den tidligere version.
Model.
Prompt.
Embedding.
Retriever.
Dokumentation.
Agentlogik.
Parametre.
Hvert af disse elementer kan påvirke resultatet.
En agent er ikke nok at vurdere på dens endelige svar
Det bliver endnu sværere i tilfælde af AI-agenter.
En klassisk chatbot kan udføre én opgave: spørgsmål → svar.
En agent kan fungere helt anderledes: mål → plan → værktøj → resultat → næste skridt → beslutning → handling → svar.
Hvis agenten ikke nåede målet, vil vi ikke kun vide, at den tabte.
Vi vil vide: hvor begik den en fejl?
- Forstod den opgaven forkert?
- Valgte den det forkerte værktøj?
- Sendte den en forkert parameter?
- Hentede den forkerte data?
- Træf den en dårlig beslutning efter at have modtaget resultatet?
- Udførte den for mange skridt?
- Stoppede den for tidligt?
I forskning i evaluering af agenter analyserer man i stigende grad ikke kun slutresultatet, men også forløbet, værktøjsbrug, planlægning, hukommelse, pålidelighed og sikkerhed.
Det betyder, at fremtiden for AI-testning i høj grad vil være knyttet til analyse af trace'er, altså systemets fulde forløb.
AI har brug for noget, der ligner CI/CD
Hvis AI er en del af produktet, kan man ikke kun teste det før den første implementering.
Systemet vil ændre sig.
Modellen vil ændre sig.
Prompten vil ændre sig.
Vidensbasen vil ændre sig.
Måden at søge på vil ændre sig.
Konfigurationen vil ændre sig.
Derfor bør evaluering blive en del af udviklingsprocessen.
Skemaet kan se sådan ud: ændring → tests → evaluering → sammenligning med den tidligere version → beslutning om implementering
Hvis den nye version forbedrer kvaliteten på ét område, men overskrider den fastsatte fejlgrænse på et andet, kan deployment blive stoppet.
Det er en meget lignende filosofi som klassisk CI/CD, men kriterierne er anderledes.
I tilfælde af AI-applikationer kan vi samtidig kontrollere svarenes kvalitet, korrekthed, sikkerhed, omkostning og latenstid. Der findes allerede forskningsløsninger, som kombinerer evaluering med observability og kvalitetsporte i implementeringsprocessen for LLM/RAG-systemer.
Kan man så teste AI på samme måde som klassisk software?
Ja, men kun delvist.
Den klassiske tilgang er stadig nødvendig.
Vi tester:
- API,
- integrationer,
- rettigheder,
- datavalidering,
- fejl,
- timeouts,
- sikkerhed,
- ydeevne,
- applikationslogik.
Men det kan vi ikke stoppe ved.
Der kommer et andet lag til: evaluering af AI-adfærd.
- Er svaret korrekt?
- Er det i overensstemmelse med kilderne?
- Holder modellen sig til instruktionen?
- Opfører systemet sig korrekt i uventede situationer?
- Vælger agenten de rigtige værktøjer?
- Har den nye version ikke forringet kvaliteten?
- Er driftsomkostningen stadig acceptabel?
- Får brugeren reelt værdi?
Det er ikke længere en klassisk unit test.
Den bedste AI-test er ikke altid en laboratorietest
Der er endnu en meget vigtig faktor.
Systemet kan klare sig fremragende på et forberedt testsæt, og alligevel have problemer i den virkelige verden. Derfor er det værd også at observere reelle interaktioner. Ikke for at gøre hver bruger til tester. Det handler om, at systemet løbende kan forbedres på baggrund af virkelige tilfælde:
- hvor brugerne retter AI'en,
- hvor de beder om at få svaret gentaget,
- hvor de afbryder samtalen,
- hvor de eskalerer sagen til et menneske,
- hvor agenten ikke når målet,
- hvor der opstår usædvanlige spørgsmål.
På den måde opstår en kontinuerlig evalueringssløjfe: bruger → AI-handling → resultat → analyse → ny testcase → næste version af systemet
Det er en helt anden udviklingsmodel end den ene gang, hvor vi siger: „vi har implementeret AI, og det virker.”
AI bør ikke vurderes med spørgsmålet „virker det?”
Det er for lidt.
Bedre spørgsmål lyder:
- Hvor ofte virker det korrekt?
- I hvilke situationer tager det fejl?
- Hvor alvorlige er disse fejl?
- Er den nye version bedre end den forrige?
- Er systemet tilstrækkeligt sikkert?
- Er svarene baseret på de rigtige data?
- Hvor meget koster det at opnå et bestemt resultat?
Først et sådant sæt spørgsmål gør det muligt at tale om et modent AI-system.
Den vigtigste ændring i tankegangen
I årevis har der i softwareudvikling været en enkel regel: koden skal virke.
I AI-systemer skal den udvides: systemet skal fungere godt, forudsigeligt og målbart.
Det er en enorm forskel. For AI er ikke en funktion, der altid returnerer det samme resultat. Det er et probabilistisk system, hvis adfærd afhænger af modellen, dataene, konteksten, instruktionerne og hele arkitekturen omkring det.
Derfor slutter en professionel AI-implementering ikke i det øjeblik, modellen begynder at svare.
Det er netop dér, spørgsmålet begynder: hvor ved vi fra, at vi kan stole på den?
Og det er netop det spørgsmål, en veludformet evaluering bør besvare.
I fremtiden vil test af AI-systemer sandsynligvis blive lige så naturlig en del af udviklingsprocessen som unit tests, integrationstests eller overvågning. Ikke fordi AI er „farlig per definition”. Enkelt og alene fordi et system, hvis output ikke altid er deterministisk, kræver en anden måde at måle kvalitet på.
Og jo mere AI bevæger sig fra generering af tekst til håndtering af virkelige processer, brug af data, RAG og udførelse af handlinger via agenter, desto vigtigere bliver det ikke kun at spørge „kan AI gøre det?”, men også: „kan vi bevise, at den gør det godt nok?”
