No products added!
Generativ AI kan give mærkbar fart og kvalitet i vidensarbejde, kundedialog, marketing og analyse. Men værdien holder kun, hvis systemet også er stabilt, sikkert og pålideligt, når det møder virkelige brugere, skæve input og travle perioder.
Kvalitetssikring af generativ AI er ikke én test, man “klarer” før go-live. Det er en disciplin, der kobler testcases, evalueringsmetoder og KPI’er til en praksis, hvor man løbende opdager fejlmønstre, lærer af dem og styrker løsningen sprint for sprint.
Hvorfor evaluering af generativ AI er anderledes end klassisk softwaretest
I klassisk software kan man ofte definere et entydigt korrekt output. I generativ AI er “rigtigt” tit et spørgsmål om relevans, tone, faglig forsigtighed og om svaret passer til konteksten.
Samtidig er systemet probabilistisk: den samme prompt kan give lidt forskellige svar. Det betyder, at kvalitetssikring skal håndtere variation uden at kvæle kreativitet, og uden at acceptere upræcise eller opfundne påstande.
En vigtig konsekvens er, at evaluering bør ske på flere niveauer: indholdskvalitet, sikkerhed/etik, performance og forretningsværdi. Hvis bare ét niveau halter, kan en ellers “klog” løsning blive svær at stole på.
Testcases: sådan bygger du en test-suite, der rammer virkeligheden
Start med at definere, hvad modellen må og ikke må i jeres kontekst. En intern skriveassistent må gerne foreslå formuleringer, men bør være tilbageholdende med jura, persondata og skråsikre fakta uden kilde. En kundeservicebot skal kunne svare hurtigt, men også kunne sige “det ved jeg ikke” og sende brugeren videre.
Når rammerne er klare, kan I designe testcases, der dækker både normale flows og de situationer, der typisk skaber problemer. En god test-suite udvikler sig over tid og bliver et aktiv på linje med unit tests i software.
Efter en kort analyse af jeres risikoprofil kan det give mening at samle testcases i disse spor:
- Happy-path
- Belastning og svartid
- Edge cases og tastefejl
- Prompt injection og “rød-hold” angreb
- Bias, toksicitet og uønsket indhold
- Hallucinationer og usande påstande
Det afgørende er ikke at have tusindvis af tilfældige prompts, men at have et repræsentativt sæt, der afslører fejlmønstre og kan køres igen og igen.
Designgreb, der gør testcases skarpe
Særligt ved etiske og bias-relaterede tests er det effektivt at bruge parallelle prompts, hvor kun én variabel ændres (køn, alder, etnicitet, rolle). Så ser man hurtigere, om modellen giver systematisk skæve svar.
Ved hallucinationstest kan man blande faktuelle spørgsmål med “falske ankre”, hvor det korrekte svar er, at kilden ikke findes. Det tester, om modellen gætter, eller om den stopper op og bliver forsigtig.
Ved robusthedstest bør I bevidst forsøge at få modellen til at bryde reglerne. Det kan gøres manuelt, men også via automatiserede værktøjer, der genererer mange variationer af samme angrebsmønster.
Evalueringsmetoder: kombiner tal, rubrics og menneskelig dømmekraft
Der findes ikke én metrisk, der kan stå alene. En moden evalueringspraksis blander kvantitative mål (hurtige, skalerbare) med kvalitative vurderinger (nuancerede, kontekstfølsomme).
Kvantitative metoder kan måle teknisk adfærd og stabilitet: svartider, fejlrate, afvisningsrate, samt simple kvalitetsmål på afgrænsede opgaver. På fritekst kan klassiske mål som BLEU/ROUGE have begrænset værdi, medmindre opgaven er stærkt standardiseret.
Kvalitative metoder er stærke, når I skal vurdere om svaret er hjælpsomt, velstruktureret, juridisk forsigtigt, brand-korrekt eller pædagogisk. Her giver en rubric med klare kriterier mere ensartede vurderinger end “synes godt om”.
Et praktisk greb er at vurdere output på flere dimensioner, hvor hver dimension har en tydelig skala. Det kan se sådan ud:
- Relevans: Svarer teksten faktisk på spørgsmålet og den konkrete kontekst?
- Faktuel disciplin: Er der kilder, forbehold og ingen opdigtede detaljer?
- Sprog og tone: Er det klart, venligt, professionelt og målgruppepasset?
- Sikkerhed: Undgår systemet persondata, hadtale og ulovlige instruktioner?
- Handlingsværdi: Kan brugeren gøre noget konkret med svaret?
“Model-as-judge” og sammenligningsscoring
Mange teams bruger i dag en ekstra LLM som dommer, der scorer svar ud fra faste kriterier. Det kan øge tempoet, men kræver disciplin: dommeren skal være stabil, rubric’en skal være skarp, og der skal laves stikprøver med menneskelig kontrol for at undgå, at I automatiserer en fejl.
I praksis fungerer pairwise sammenligning ofte bedre end pointwise scoring: To svar sættes op mod hinanden, og man vælger det bedste ud fra rubric’en. Det er enklere at bedømme, og det hjælper, når I tester forskellige prompts, systembeskeder, temperatur eller modeller.
KPI’er: mål det, der både gør systemet bedre og skaber værdi
KPI’er for generativ AI bør dække fire lag: modelkvalitet, drift, adoption og forretningsværdi. Hvis I kun måler brug, risikerer I at belønne et system, der er populært men upræcist. Hvis I kun måler faktuel korrekthed, risikerer I at kvæle nytte og tempo.
En god tommelfingerregel er, at KPI’er skal kunne føre til en handling: Hvad gør vi, hvis tallet går den forkerte vej?
Her er et forslag til en enkel oversigt, der ofte passer til virksomhedsbrug:
| KPI-lag | Eksempel på KPI | Hvad den fortæller | Typisk handling ved afvigelse |
|---|---|---|---|
| Modelkvalitet | Hallucinationsrate (stikprøvebaseret) | Om systemet gætter og opfinder “fakta” | Strammere prompt, bedre kildelag/RAG, flere afvisningsregler |
| Modelkvalitet | Relevansscore (rubric eller judge-model) | Om svar matcher opgaven | Justér kontekst, forbedr instruktioner, kuratér eksempler |
| Drift | P50/P95 svartid | Oplevet hastighed ved normal og spidsbelastning | Skalér infrastruktur, cache, kortere kontekst, batch-kald |
| Drift | Fejl- og timeout-rate | Stabilitet og robusthed i pipeline | Bedre retries, rate limits, fallback-svar |
| Adoption | Andel aktive brugere pr. uge | Om løsningen faktisk bliver brugt | Træning, bedre UX, tydeligere use cases |
| Forretningsværdi | Tidsbesparelse pr. opgave (målt) | Effektivisering i arbejdet | Automatisér dele af flowet, skærp guidelines |
| Forretningsværdi | First-contact resolution i support | Om botten løser henvendelser uden eskalering | Udvid vidensbase, forbedr routing, bedre afklaring i dialog |
KPI-design til kreative opgaver
Hvis AI bruges til idegenerering eller tekstudkast, skal I også kunne måle variation og nytte, uden at belønne støj. I kan måle diversitet indirekte ved at se, hvor ofte brugere gemmer, redigerer og genbruger output.
Det vigtigste er, at kreativitet ikke bliver en undskyldning for upræcise påstande. I mange teams giver det mening at separere “kreative” outputs fra “faktuelle” outputs og stille hårdere krav til det sidste.
Produktion: løbende monitorering, drift og feedbackloops
Når systemet er i drift, opstår de mest værdifulde signaler. Brugerne stiller spørgsmål, I ikke forudså, og nye mønstre sniger sig ind. Derfor bør I etablere monitorering, der både ser på tekniske forhold og på indholdets adfærd.
Det handler ikke kun om data- og modeldrift i statistisk forstand. Det handler også om adfærdsdrift: at brugerne ændrer måde at spørge på, at nye produkter eller regler ændrer konteksten, eller at en opdatering i vidensbasen skubber svar i en ny retning.
Et robust setup indeholder ofte logning af prompts og outputs (med ansvarlig håndtering af persondata), dashboards med KPI’er og alarmer ved afvigelser. Derudover er stikprøvekontrol vigtig, fordi automatiske målinger sjældent fanger alle nuancer i tone, bias og skjulte fejl.
Værktøjsmæssigt vælger mange at kombinere klassiske performanceværktøjer (JMeter, Gatling) med monitorering (Prometheus, Dynatrace) og AI-specifik overvågning (Arize, Fiddler, Evidently.ai). Til datakvalitet kan Great Expectations være en praktisk måde at fange ændringer i inputfelter og distributionsskift.
En praktisk implementeringsplan, der kan køre i sprint
Det er fristende at starte med KPI-dashboardet. Start hellere med en lille, skarp testsuite og få rytmen på plads. Når det virker, udvider I.
En simpel 30-dages plan kan se sådan ud:
- Definér use case, risikoniveau og “acceptabel adfærd” som korte regler, der kan testes.
- Byg 30 til 80 testcases fordelt på normalbrug, edge cases, injection og etik.
- Vælg evalueringsmix: automatiske checks, rubric med menneskelig scoring, samt evt. judge-model til skala.
- Fastlæg KPI’er pr. lag (kvalitet, drift, adoption, værdi) og beslut alarmer og ejerskab.
- Kør ugentlige review-møder, hvor de dårligste cases gennemgås og bliver til nye testcases.
Den sidste del er ofte der, kvaliteten virkelig flytter sig: når fejl bliver til læring, og læring bliver til nye tests.
Kompetencer og roller: gør evaluering til en fælles disciplin
Evaluering af generativ AI kræver både teknisk blik og domæneindsigt. Jurister, HR, marketing, kundeservice og IT ser forskellige risici, og det er netop styrken, når de vurderer sammen ud fra en fælles rubric.
Én rolle bør eje testplanen og sørge for, at testcases versioneres, at KPI’er giver mening, og at ændringer i prompt, model eller vidensbase følges af en ny evalueringsrunde.
Hos Nordisk Business Academy møder man ofte et behov for at gøre evaluering konkret og anvendelig på tværs af fagligheder, så teams kan arbejde sikkert med AI uden at gøre processen tung. Når testcases, evalueringsmetoder og KPI’er hænger sammen, bliver kvalitetssikring ikke en kontroløvelse, men en motor for bedre resultater i hverdagen.

