Selvom basismodellerne er blevet bedre, skyldes det afgørende skift mod sikker brug i produktion en disciplineret evalueringspraksis
Veltilrettelagte evalueringer hjælper produktchefer, AI-governanceansvarlige og teknologidirektører med at implementere AI-agenter sikkert i stor skala og gøre AI til en konkurrencefordel frem for et isoleret legetøj.
Den tillid opstår, når AI-agenters adfærd evalueres ud fra virkelige brugerforespørgsler, edge cases og domænespecifikke scenarier, der afspejler jeres faktiske forretningskontekst – ikke ud fra en offentlig benchmark, der siger: »Denne model er bedst«
Målet er at underbygge denne tillid med målbare resultater. Succes kræver, at "godt" defineres konkret og målbart i overensstemmelse med jeres forretningsbehov og risikotolerance – uanset om det gælder faktuel korrekthed, passende tone, hastighed eller omkostningseffektivitet.
Ved at integrere evaluering i hele systemet (instrumentering, logning, A/B-test og sikkerhedsforanstaltninger) og afveje grundighed mod effektivitet kan teams implementere hurtigere og opnå større robusthed.
De fleste virksomheder er trygge ved, at medarbejderne eksperimenterer med ChatGPT eller Gemini. Men det er langt mindre udbredt at sætte LLM'er i arbejde i kritiske arbejdsgange eller miljøer.
Det har ofte været velbegrundet: Kvaliteten har været svingende, og risikoen for hallucinationer eller uønsket adfærd har vejet tungere end teknologiens potentielle fordele.
Balancen mellem risiko og gevinst har rykket sig markant det seneste år. Noget af det skyldes forbedringer i basismodellernes ydeevne, men en stor del kan tilskrives den voksende disciplin omkring evalueringer (eller »evals«). Evalueringer giver os og vores kunder tillid til på få uger at implementere kundevendte agenter i stor skala.
Denne vejledning gennemgår grundelementerne i evalueringer samt, hvordan de designes, implementeres og drives til produktionsformål.
Målet med evaluering er ikke at finde en perfekt model, men at skabe velbegrundet tillid til, at modellen opfører sig i overensstemmelse med jeres forretningsbehov, brugernes forventninger og organisationens risikotolerance.
Enhver evalueringsstrategi tager udgangspunkt i et enkelt spørgsmål: Hvordan ser »godt« ud? Svaret bør være konkret. For én organisation kan »godt« betyde faktuel korrekthed inden for snævre tolerancer, mens en anden prioriterer hastighed, omkostningseffektivitet eller et særligt toneleje. Alle de rammer, I arbejder under – fra hvilke data der må bruges, til hvilke myndighedskrav der gælder – former denne definition.
Det er afgørende, at 'godt' består af elementer, der faktisk kan måles. Hvis succes betyder at yde nyttig økonomisk vejledning, skal nytteværdien udtrykkes gennem egenskaber som faktuel korrekthed, passende forbehold, personlig ræsonnering og sikre grænser. Når »godt« er defineret målbart, er næste spørgsmål, hvordan resultaterne skal analyseres og fortolkes. Det er handling på baggrund af resultaterne, der gør evaluering til en metode frem for blot en række skøn.
Enhver evalueringspipeline bygger på tre indbyrdes forbundne søjler:
Input/benchmarks: Repræsentative eksempler fra virkeligheden til generel ydeevne og kuraterede interne datasæt til at teste anvendeligheden på domænet.
Modeladfærd: Hvordan modellen kaldes (retrieval-augmented generation, opsummering, struktureret informationssøgning og brug af værktøjer).
Målepunkter: Hvordan ydeevnen måles og fortolkes.
Inputtene skal repræsentere den verden, som systemet vil møde. Den mest værdifulde indsigt kommer fra virkelige eksempler: jeres kundeforespørgsler, økonomiske scenarier eller branchespecifikke cases. Kun ved at teste mod disse kan I forstå, om modellen reelt opfatter de nuancer, brugerne kræver, og opfylder forretningsbehovet.
Modellens adfærd – herunder hvordan den promptes, hvordan søgning og værktøjsbrug orkestreres, og hvordan kontekst tilføres – betyder lige så meget som selve modellen. To identiske modeller kan opføre sig meget forskelligt, alt efter hvordan de implementeres. Dette lag skal derfor indgå i evalueringsdesignet.
Endelig er der målepunkterne. Tal fortæller sjældent hele historien, men velvalgte målepunkter gør systemets adfærd forståelig. Svartid, nøjagtighed, sikkerhed, sammenhæng, bias, omkostninger og brugertilfredshed tegner tilsammen et flerdimensionelt billede af et system i produktion. Kunsten er at vælge målepunkter, der stemmer overens med projektets eller virksomhedens KPI'er og belyser de egenskaber, der betyder mest for brugerne. Enklere målepunkter er ofte mere præcise og billigere, mens dårlige valg kan vildlede teams. Sådan bør I tænke over valget af målepunkter:
Eksempler på gode valg af målepunkter:
Chatbot til kundeservice: Løsningsgrad ved første kontakt (blev brugerens problem løst uden eskalering?), gennemsnitlig behandlingstid, brugertilfredshed og andel af sager, der eskaleres til menneskelige agenter
Værktøj til finansiel research: Kildehenvisningernes nøjagtighed (procentdel af påstande med korrekt kilde), faktuel præcision valideret mod et facit, søgeresultaternes relevans (fandt værktøjet de rigtige dokumenter?) og ræsonneringens sammenhæng vurderet af domæneeksperter
Assistent til kodegenerering: Korrekt syntaks, andel beståede test, antal sikkerhedssårbarheder og tid til en fungerende løsning
Eksempler på dårlige valg af målepunkter:
Kun at bruge svarets længde som indikator for kvalitet (længere ≠ bedre)
At måle hastighed uden at tage højde for kompromiset med nøjagtighed
At følge modellens konfidensscore uden at validere den mod den faktiske korrekthed
Udelukkende at basere sig på modellens interne perplexity uden brugervendt validering
Typiske faldgruber ved målepunkter:
Modstridende målepunkter: Samtidig optimering af hastighed og grundighed uden at anerkende kompromiset
Overtilpasning til benchmarks: At opnå 95 % på testsættet, men fejle i produktion, fordi virkelige brugere opfører sig anderledes
For en kunde i en stærkt reguleret del af finanssektoren var nøjagtighed altafgørende i deres løsning til dybdegående research. Vi udviklede både ekspertskrevne QA-datasæt og værktøjsgenererede datasæt. Dermed kunne vi vurdere præcisionen, systemets evne til at vælge de rette værktøjer og hente de rette oplysninger og få et afbalanceret billede af nøjagtigheden og ræsonneringens kvalitet. Nøglen var at måle flere dimensioner: faktuel nøjagtighed (ekspertvalidering), søgekvalitet (precision/recall for relevante dokumenter) og ræsonneringens sammenhæng (struktureret vurdering af det logiske forløb).
Hvornår LLM-as-a-judge bør bruges til nuanceret kvalitetsvurdering
LLM-as-a-judge bruger en anden AI-model som evaluator og erstatter menneskelig gennemgang med skalerbar, automatisk kvalitetsbedømmelse. LLM-as-a-judge bruges ofte uhensigtsmæssigt, selvom enklere målepunkter kan give den nødvendige nøjagtighed. Metoden kan være nyttig, når deterministiske kontroller ikke kan indfange kvaliteten, eksempelvis når målepunktet er semantisk (hjælpsomhed, faktuelt grundlag, ræsonneringskvalitet, tone eller fortolkning af politikker), og deterministisk bedømmelse ikke er mulig. I kan have brug for skalerbar feedback på tværs af mange prompt- og modelvarianter samt for at definere klare bedømmelseskriterier og et skema til strukturerede outputs. Følg disse trin for at få metoden til at fungere:
Definér kriteriernes dimensioner eksplicit: korrekthed, faktuelt grundlag, overholdelse af politikker, handlingsanvisning og tone.
Brug strukturerede outputs (JSON-skema) til bedømmerens svar.
Registrer både binære gate-scorer og diagnostisk tekst til fejlanalyse.
Kalibrer bedømmerens outputs mod menneskeligt mærkede eksempler i hver udgivelsescyklus.
Brug to bedømmere eller regelmæssige konsensustjek på kritiske domæner.
Følg udviklingen i bedømmerens drift og uenighedsgrad over tid.
Et benchmarkdatasæt er et fast, kurateret sæt testeksempler med kendte svar, der bruges til konsekvent evaluering af modeller og retfærdig sammenligning af resultater på tværs af versioner. Det omfatter normalt input (f.eks. brugerforespørgsler), forventede outputs eller referencebedømmelser samt evalueringskriterier eller etiketter til bedømmelsen. Offentlige benchmarktest bruges til at sammenligne de nyeste modellers ydeevne og kan indledningsvis hjælpe jer med at udpege en model, der kunne være en god kandidat til systemet.
For jeres eget system kan disse benchmarks dog ikke bruges som indikator for ydeevnen i jeres forretningskontekst, da de har en række kendte problemer:
Kontaminering: Modeller kan være trænet på benchmarkdata. Evaluering på det samme datasæt kan derfor svare til at bedømme med en facitliste ved hånden.
Mætning: Alle de bedste modeller opnår allerede maksimumscore. Forbedringer eller forringelser vil derfor være begrænset til få procentpoint og ofte ligge inden for testresultaternes naturlige variation.
Snævert fokus: Benchmarkdata afspejler ikke jeres faktiske opgaver, da de er stærkt kuraterede og rensede. Nogle er endda genereret af LLM'er og afspejler derfor ikke kompleksiteten og de edge cases, der findes i jeres data, såsom slåfejl, usædvanlige formuleringer og støjfyldte billeder.
En elev beder applikationen om hjælp til at løse tekstopgaver.
Et eksempel på en offentlig benchmark, I kan bruge: GSM8K (matematisk ræsonnering på grundskoleniveau)
Valgfrit, sværere sæt: MATH.
Derfor er denne benchmark nyttig:
Sammenlign hurtigt, hvilken model der er bedst til generel matematisk ræsonnering,
Et godt første filter, før I investerer i fulde produktevalueringer.
Derfor har I stadig brug for jeres eget datasæt:
Jeres app har krav, som GSM8K ikke tester:
Ordlyden og emnerækkefølgen i jeres pensum,
En forklaringsstil, der passer til aldersgruppen,
Håndtering af tvetydige elevspørgsmål eller spørgsmål med mange slåfejl,
Regler for adfærd (f.eks. hvornår der skal gives hints frem for komplette svar).
Effektiv validering afhænger af, at I opretter applikationsspecifikke evalueringsbenchmarks. Disse datasæt bør bygge på virkelige interaktioner, typiske edge cases og sandsynlige fejlscenarier. Det kan være en vanskelig opgave ved implementering af et nyt produkt eller en ny proces. I de fleste tilfælde er det dog muligt at indsamle data fra et eksisterende produkt eller så tidligt som muligt, selv under den indledende testfase. Når applikationen er udviklet, bør disse benchmarks udvikle sig sammen med produktet og med tiden blive mere omfattende og repræsentative.
Case: Udvikling af en skræddersyet benchmark til en bankassistent for privatkunder
En bankchatbot besvarer spørgsmål om budgetter, forbrug og transaktioner. Offentlige QA-benchmarks og text-to-SQL indfangede ikke centrale bankrisici såsom SQL-injektion, datalækage eller videreførelse af kontekst gennem samtaler med flere beskeder. Vi udviklede en skræddersyet benchmark, der afspejler produktets agentpipeline.
Komponenter i den skræddersyede benchmark i denne kodebase:
Red-team-tests med ondsindede prompts til SQL-injektion, udtræk af personhenførbare oplysninger, tilsidesættelse af prompts og lækage på tværs af sessioner
Nultolerance på sikkerhedsområdet: Ethvert forsøg på SQL-injektion, udtræk af personhenførbare oplysninger eller lækage på tværs af sessioner skal afvises.
Nøjagtig videreførelse af kontekst: Omskrevne forespørgsler skal bevare brugerens hensigt og entiteter.
Konklusion: Behandl oprettelsen af benchmarks som en produktfunktion. Den nuværende harness viser, at evaluering fra start til slut er koblet korrekt, men dækningen og stikprøvestørrelserne skal øges for at afspejle virkelige bankrisici som angreb med flere hensigter, omgåelse af sikkerhedsforanstaltninger og kontekstafhængige forespørgsler. Benchmarken bør udvides i takt med nye agenter og sikkerhedsforanstaltninger.
Sammenhængen mellem jeres applikationsspecifikke benchmark og valget af model er afgørende. Benchmarken viser ikke blot, om en løsning fungerer, men også hvilken kombination af modelstørrelse og eftertræningsteknikker der mest omkostningseffektivt leverer den ønskede ydeevne. De største forbedringer af fortrænede modeller (»PT« i ChatGPT) kommer ikke fra genoptræning, men fra metoder til "eftertræning".
Metoderne fokuserer på at forme, hvilke oplysninger modellen har adgang til, hvordan oplysningerne struktureres, og hvordan modellen styres og orkestreres under inferens. Eftertræningsteknikker som:
Prompting med tankerækker og dynamisk tildeling af computerkraft (tænk mere over sværere problemer)
Selvkonsistens, hvor flere outputs genereres, hvorefter det bedste vælges
Kontekstopbygning og orkestrering, såsom Retrieval-Augmented Generation (RAG), eksempler med få eksempler og agentbaserede arbejdsgange
Brug af værktøjer og adgang til ekstern viden, så modellen kan handle ud over sine interne parametre
Strategier til repræsentation og lagring af viden, som er udviklet til effektiv søgning og ræsonnering på tværs af strukturerede og ustrukturerede data
Selvom disse eftertræningsteknikker kan forbedre systemets ydeevne markant, medfører de også kompromiser. Hvert ekstra lag af orkestrering, søgning eller ræsonnering øger systemets kompleksitet, inferenstid og driftsomkostninger. Når de anvendes med omtanke, gør den rette kombination af eftertræningsteknikker det dog ofte muligt at bruge mindre, hurtigere og billigere modeller og stadig opfylde kravene til ydeevne. I stedet for at øge modellens størrelse opnås ydeevnen gennem bedre systemdesign.
Den rette balance afhænger altid af applikationen og bør fastlægges ved hjælp af jeres applikationsspecifikke evalueringer. De gør det muligt at finde det punkt, hvor yderligere orkestrering ikke længere giver væsentlige gevinster, så teams kan vælge det laveste niveau af eftertræningskompleksitet, der kræves for at nå målet for ydeevne.
En AI-løsning skal betragtes som et samlet system: databaser, API'er, brugergrænseflader, orkestreringslag, overvågningsinfrastruktur med mere. Evalueringen skal derfor omfatte hele teknologistakken. I bør overvåge centrale dele af systemet for at bevare indblik i potentielle problemer og øge tempoet på en ansvarlig måde.
Overvågning af centrale dele af systemet indebærer:
Instrumentering af pipelines, så resultaterne kan måles.
Logning af eksperimenter, så effekten af hver justering bliver synlig.
Brug af enkle A/B-sammenligninger før implementering af større ændringer for at teste for mulige regressioner.
Datadrevet iteration forkorter vejen fra prototype til produktion uden blinde vinkler. Logning og overvågning er også vigtigt for at forstå, hvordan applikationen bruges i praksis. Her er et eksempel på, hvordan observerbarhed kan sikres:
Trin 1: Brugeranmodningen modtages med request_id, user_segment og intent.
Trin 2: Trace-loggen registrerer modelversion, promptversion, hentede dokumenter og værktøjskald.
Trin 3: En LLM-bedømmer scorer svaret (correctness, groundedness, policy_risk).
Trin 4: Regelmotoren evaluerer tærskelværdierne.
Trin 5: Hvis en tærskel overskrides, udløses en alarm, og sagen sendes til en reserveløsning eller menneskelig gennemgang.
Trin 6: Fejlen føjes til triagekøen og derefter til benchmarkens backlog.
Virkelige brugere opfører sig sjældent præcis, som designerne forventer. Nogle vil misforstå instruktionerne. Andre vil bevidst afsøge svage punkter. Disse edge cases er ikke afvigelser, men uvurderlige signaler. En velimplementeret evalueringspipeline registrerer og analyserer dem og føjer dem til fremtidige test. Hurtig iteration uden blinde vinkler er kun mulig, når evaluering er indbygget i systemet frem for tilføjet efter udviklingen.
Vi anbefaler, at sikkerhedsforanstaltninger og overvågning indbygges fra første dag:
Følg regelmæssigt modellens målepunkter og regressioner ved hjælp af jeres applikationsspecifikke benchmark.
Registrer og gennemgå edge cases eller fjendtlige input, og føj dem til datasættet for jeres applikationsspecifikke benchmark.
Sørg for, at disse evalueringsmålepunkter stemmer overens med jeres centrale KPI'er.
Udfordr regelmæssigt datasættet og benchmarken for at sikre, at I ikke overser nye risici eller er påvirket af bias.
Implementer automatiske alarmer ved forringede målinger (udløs f.eks. en gennemgang, hvis nøjagtigheden falder til under 85 %).
Oprethold en proces med menneskelig gennemgang af kritiske beslutninger (juridisk rådgivning, sundhedsvejledning og finansielle transaktioner).
Hver benchmarkkørsel bruger computerkraft og energi. Hvert overflødigt eksperiment øger omkostningerne. Ansvarlig evaluering bør afveje grundighed mod effektivitet.
En række praktiske tiltag kan forhindre, at energi- og omkostningsforbruget løber løbsk:
Brug mindre modeller, når det er muligt. Kør de første eksperimenter på billigere modeller, og skaler først op, når tilgangen er valideret.
Cache prompts og API-kald.
Brug energibevidst planlægning (batchbehandling, spot instances og fleksibel prioritet).
Følg forbruget af computerkraft sammen med ydeevnen.
Hold samtidig øje med ny AI-regulering. Selv når der ikke findes en særlig lov, gælder eksisterende regler og nødvendige tiltag stadig, herunder:
Databeskyttelse:
Sørg for, at benchmarkdatasæt ikke indeholder personhenførbare oplysninger uden gyldigt samtykke
Implementer politikker for opbevaring af loggede forespørgsler
Tilbyd mekanismer til anmodninger om sletning af data
Lighed og bias:
Test ydeevnen på tværs af demografiske grupper
Sørg for bred repræsentation ved udarbejdelse af benchmarks
Menneskerettigheder og gennemsigtighed:
Dokumenter modellens begrænsninger tydeligt for brugerne
Giv forklaringer på kritiske beslutninger
Muliggør menneskeligt tilsyn med kritiske applikationer
Evaluering er ikke en enkeltstående begivenhed, men et system i konstant udvikling. På et område i hastig udvikling ligger jeres fordel i, hvor hurtigt I kan teste, lære og tilpasse jer, så modeller og nye løsninger kan implementeres med større effekt.
Ved at gøre evaluering til en central del af udviklings- og produktledelsesarbejdet kan teams innovere hurtigere og mere sikkert. Begynd med at definere, hvordan »godt« ser ud i konteksten for jeres AI-applikation. Etabler derefter en evalueringsplatform, og videreudvikl den til en applikationsspecifik benchmark, som ved hver iteration giver tillid til, at løsningen er produktionsklar.