Du har bygget en evalueringssuite. Den består. Du udruller. Brugerne klager straks over regressioner, som din evaluering ikke opdagede.
Det er et af de mest almindelige — og mest demoraliserende — mønstre i arbejdet med LLM’er i produktion. Evalueringssuiter ser imponerende ud, men overser de regressioner, der betyder noget. De giver falsk tryghed. Teamet stoler på dem, sender ændringer ud, som forringer kvaliteten, og opdager først problemet, når brugerne gør opmærksom på det.
Det er sværere, end det ser ud, at bygge evalueringer, der faktisk opdager regressioner. Det grundlæggende (datasæt, forventede output, bedømmelse) er nemt. Arbejdet ligger i at gøre dem til et pålideligt signal.
Denne artikel gennemgår, hvad vi har lært om at bygge evalueringer, der holder i praksis — til teams, som tager kvaliteten af AI i produktion alvorligt.
Hvad gode evalueringer gør
Når en god evalueringssuite køres på en mulig ændring, giver den dig et svar med høj sikkerhed på spørgsmålet: “Er denne ændring bedre, dårligere eller på niveau med den nuværende version?”
Forskellene er:
- Opdager regressioner. Når kvaliteten falder for mønstre fra den virkelige verden, falder evalueringsscoren.
- Registrerer forbedringer. Når kvaliteten forbedres, afspejler scoren det (og ikke kun i håndplukkede tilfælde).
- Er stabil uden reelle ændringer. Når intet væsentligt har ændret sig, er scoren konsistent.
- Kan danne grundlag for beslutninger. Beslutninger baseret på evalueringsscorer stemmer overens med de faktiske resultater for brugerne.
Hvert af disse punkter er sværere, end det lyder.
Problemet med datasættet
Din evaluering er kun så god som dit datasæt. De fleste utilstrækkelige evalueringssuiter fejler her.
Almindelige fejl i datasæt
Fejl 1: Håndplukkede, nemme tilfælde. Datasættet blev bygget, mens systemet fungerede, ofte af den udvikler, der byggede det. Vedkommende valgte tilfælde, som “gav mening” — tydelige eksempler på hver adfærd. Reel produktionstrafik er mere rodet. Svære, tvetydige tilfælde og kanttilfælde står for en stor del af fejlene, men er underrepræsenterede i datasættet.
Fejl 2: Forældet datasæt. Datasættet blev bygget for seks måneder siden. Siden da har brugeradfærden ændret sig, nye funktionsområder er kommet til, og nye produktegenskaber er blevet lanceret. Datasættet tester en gammel version af virkeligheden.
Fejl 3: Manglende dækning af regressionsudsatte områder. Evalueringen dækker den problemfri standardsti grundigt, men undersøger ikke de grænsetilfælde, hvor regressionerne faktisk opstår.
Fejl 4: Kontaminering af datasættet. Eksempler, der bruges i evalueringen, findes også i prompten eller finjusteringsdataene. Modellen “husker” dem. Testscorerne bliver kunstigt høje, mens den reelle ydeevne er dårligere.
Fejl 5: Skæv fordeling. 80% af datasættet består af én type input, mens 5% udgør den lange hale. En regression i den lange hale påvirker knap nok scoren, selv om det er en reel regression.
Sådan bygger du et stærkt datasæt
Her er nogle principper, der skaber stærke datasæt:
Brug reel produktionstrafik som kilde. De bedste eksempler er rigtige brugerinput (med personhenførbare oplysninger fjernet). De indeholder netop den kompleksitet, systemet skal kunne håndtere.
Et praktisk arbejdsforløb:
- Indsaml en stikprøve af produktionskald (med passende kontrol af privatliv og databeskyttelse).
- Mærk de forventede output manuelt (eller lad en LLM mærke dem, og få derefter et menneske til at verificere dem).
- Føj tilfældet til evalueringsdatasættet.
- Opdater datasættet regelmæssigt (en månedlig rytme fungerer godt).
Medtag forskellige fejltyper. Medtag specifikt tilfælde, der tidligere er fejlet i produktion. De bliver til regressionstest — når du retter en fejl, tilføjer du det fejlede tilfælde, så fejlen forbliver rettet.
Stratificér datasættet. Kategorisér tilfældene (nemme/mellem/svære, efter emne, brugertype og længde). Sørg for, at hver kategori har meningsfuld dækning. Følg scorerne for hver kategori, ikke kun samlet.
Bland sværhedsgrader. Medtag nogle nemme tilfælde (så du kan opdage katastrofale regressioner), nogle mellemtilfælde (hovedparten af den reelle trafik) og nogle svære tilfælde (kanttilfældene). Et datasæt med kun svære tilfælde svinger voldsomt ved små ændringer, mens et datasæt med kun nemme tilfælde ikke reagerer på reelle regressioner.
Vælg en passende størrelse. Er datasættet for lille, bliver statistikken støjfyldt. Er det for stort, bliver kørslerne langsomme og dyre. Typiske størrelser:
- Klassifikation: 200-500 tilfælde.
- Generering: 50-200 tilfælde.
- Komplekse agentforløb: 20-50 tilfælde.
Du kan altid begynde i mindre skala og udvide.
Fast opdateringsdisciplin. Planlæg en månedlig gennemgang af datasættet. Tilføj nye fejltyper. Fjern forældede tilfælde. Opdater de forventede output, hvis den ønskede adfærd har ændret sig.
Problemet med målingerne
Det, du måler, afgør, hvad du optimerer efter. Dårligt valgte målinger er den næstmest almindelige årsag til fejl i evalueringer.
Almindelige fejl i målinger
Fejl 1: Opsummeringer med ét tal skjuler problemer. En samlet nøjagtighed på 90% kan skjule, at en vigtig kategori faldt fra 95% til 70% samtidig med, at andre blev bedre. Gennemsnittet ser fint ud.
Løsning: opdel altid efter kategori.
Fejl 2: Målingen registrerer det forkerte. En måling af “korrekthed” for svar fra kundesupport opdager måske ikke, at svaret er korrekt, men uhøfligt. Målingen indfanger ikke tonen.
Løsning: flerdimensionel bedømmelse. Bedøm korrekthed + tone + længde + format hver for sig.
Fejl 3: Ufølsom over for alvorlighedsgrad. Et forkert svar behandles ens, uanset om det er en ubetydelig fejl eller en farlig hallucination.
Løsning: vægtet bedømmelse. Alvorlige fejl tæller mere. Nogle fejl tæller som 0 (sikkerhedsbrud), mens andre tæller som -1 (katastrofale fejl, der er værre end intet svar).
Fejl 4: Bimodal følsomhed. Scoren går enten fra 100% til 99% (umærkeligt) eller fra 100% til 50% (katastrofalt). Små regressioner bliver ikke synlige.
Løsning: gradueret bedømmelse. Hvert output bedømmes på en kontinuerlig skala (1-5 eller 0-1), ikke binært.
Fejl 5: Aggregering på tværs af populationer. Gennemsnittet for alle brugere skjuler, at ydeevnen for en undergruppe på 10% er kollapset.
Løsning: dimensionelle opdelinger efter relevante udsnit (brugerniveau, forespørgselstype, sprogvariant).
Sådan bygger du stærke målinger
Flerdimensionelle. Hvert output får flere scorer: korrekthed, tone, format, sikkerhed, længde og alt andet, der betyder noget.
Vægtede. Nogle dimensioner betyder mere end andre. Vægt dem i enhver sammensat måling.
Kalibrerede alvorlighedsgrader. Skeln mellem mindre og større fejl inden for en dimension. Et faktuelt forkert svar er værre end et svar med en lille unøjagtighed.
Målinger pr. kategori. Rapportér scorer opdelt efter relevante udsnit: nem/mellem/svær, pr. emne og pr. brugertype.
Udvikling over tid. En enkelt score er ikke nyttig; det er udviklingen. Afbild scorerne over tid. Opdag afdrift.
Afstemt med brugerne. Målingerne skal hænge sammen med det, brugerne faktisk går op i. Hvis brugerne klager over uhøflighed, måler du uhøflighed. Hvis de klager over længden, måler du længden.
Problemet med dommermodellen
Når du bruger en LLM som dommer (en LLM bedømmer en anden LLM’s output), er dommermodellen din bedømmer. Er dommeren forudindtaget eller forkert, er dine evalueringer værdiløse.
Almindelige fejl hos dommermodeller
Fejl 1: Præference for længde. LLM-dommere foretrækker ofte længere svar. De giver et længere svar en højere score, selv når det er unødigt omstændeligt.
Fejl 2: Præference for format. Dommere foretrækker strukturerede output (punktopstillinger, overskrifter) frem for prosa, uanset hvad der passer bedst til opgaven.
Fejl 3: Præference for egen modelfamilie. Når dommermodellen tilhører samme familie som den model, der bedømmes, giver den sin egen families output højere scorer.
Fejl 4: Følgagtighed. Dommere tilslutter sig den rammesætning, de får. Fortæller du dommeren, at “den tidligere version var dårlig, bedøm den nye version”, bliver de nye scorer kunstigt høje.
Fejl 5: Manglende forankring. Dommere bedømmer ud fra indtryk frem for konkrete kriterier. Samme prompt giver forskellige scorer ved forskellige kørsler.
Sådan bygger du stærke dommermodeller
Kalibrér mod mennesker. Tag en stikprøve af dommerscorerne, og få et menneske til at bedømme dem igen. Når de er uenige, skal du forbedre dommerprompten eller acceptere, at der kræves mennesker til den pågældende dimension.
Brug forskellige dommermodeller. Brug om muligt en dommer fra en anden modelfamilie end det system, der evalueres. Det reducerer præferencen for egen modelfamilie.
Vær eksplicit om kriterierne. Dommerprompten skal præcisere, hvordan gode og dårlige resultater ser ud, med eksempler. Vage kriterier giver vag bedømmelse.
Undgå ledende rammesætning. Fortæl ikke dommeren: “Bedøm dette på en skala, hvor de fleste output er gode.” Forankr i konkrete former for adfærd.
Forankrede bedømmelseskriterier. Bedøm efter klart definerede kriterier med eksempler for hvert niveau. “Score 5: faktuelt korrekt, konkret, velstruktureret. Score 4: overvejende korrekt, men mangler muligvis én detalje. Score 3: …” Med holdepunkter er dommeren konsistent. Uden dem driver bedømmelsen.
Kræv struktureret output. Dommeren leverer strukturerede scorer (pr. dimension og med begrundelse), ikke fri tekst. Det er nemmere at aggregere og revidere.
En stærk dommerprompt ser sådan ud:
You are evaluating an AI assistant's response.
User query: {query}
Assistant response: {response}
Score on the following dimensions, on a scale of 1-5:
1. Factual accuracy: Are all claims correct? (5 = all correct, 4 = mostly correct with minor issues, 3 = some incorrect, 2 = many incorrect, 1 = mostly wrong)
2. Relevance: Does the response address the user's actual question? (5 = perfectly addresses, 1 = doesn't address)
3. Completeness: Does the response contain enough information? (5 = complete, 1 = severely incomplete)
4. Tone: Is the response appropriately professional? (5 = perfect tone, 1 = inappropriate)
For each score, provide:
- The score
- A one-sentence specific reason
- The specific text in the response that supports your score
Output JSON: {"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}
Kør denne dommer mod et kalibreringssæt (eksempler bedømt af mennesker). Juster, indtil dommerens vurdering ligger inden for en acceptabel afvigelse fra menneskenes.
Design af evalueringssuiter til produktion
Her er nogle mønstre, der fungerer i produktion:
Suite 1: Regressionssuiten
Et fastlagt sæt af testtilfælde (200-500), som systemet skal bestå før enhver udrulning. Det er sammensat ud fra reelle fejl, kanttilfælde og kendte, velfungerende mønstre. Det ændres ikke ofte.
Dette er din “må ikke gå i stykker”-suite. CI-integration: Hver PR kører den. Blokér sammenfletning ved regression.
Suite 2: Røgtesten
Et lille udsnit (10-30 tilfælde), der køres ofte. Det giver hurtig feedback under udvikling og opdager straks katastrofale regressioner.
Integration: en pre-commit-hook eller en hurtig røgtest før hovedevalueringen.
Suite 3: Opdagelsessuiten
Et større og mere varieret datasæt (1000s af tilfælde), udvalgt fra reel produktionstrafik. Det køres sjældnere (ugentligt?) og leder efter mønstre, som de mindre suiter kan overse.
Integration: planlagt job. Resultaterne gennemgås på ugentlige kvalitetsmøder.
Suite 4: Onlinesuiten
En stikprøve af reel produktionstrafik, som bedømmes automatisk (LLM-dommer) eller via brugersignaler. Den opdager afdrift, som offlineevalueringer overser.
Integration: kontinuerlig og dashboardbaseret.
Suite 5: Brugerforløbssuiten
End-to-end-test, der afprøver hele brugerforløb og ikke kun enkelte LLM-kald. Til agentsystemer og arbejdsgange med flere trin.
Integration: før udrulning af større ændringer.
Et modent produktionssystem har alle fem. Begynd med regressionssuiten, og tilføj de øvrige, efterhånden som kapaciteten vokser.
Disciplin omkring omkostninger og tid
Evalueringer koster penge (LLM-kald) og tid (til at køre og gennemgå dem).
En evaluering med 500 tilfælde og en flagskibsmodel som dommer kan koste €5-20 pr. kørsel. Kør den på hver PR (10/day), og du er oppe på €50-200/day. Det er håndterbart, men reelt.
Strategier:
Kør røgtest i PR’en, og kør de fulde suiter ved sammenfletning. Det sparer omkostninger på PR’er, der ikke bliver sammenflettet.
Cache resultater. Hvis hverken prompten eller modellen har ændret sig, behøver du ikke køre evalueringen igen. Cache efter (prompt_version, model, dataset_version).
Brug billigere dommere, hvor det er muligt. En billigere dommermodel med god kalibrering er ofte tilstrækkelig.
Parallelisér. Evalueringskørsler er oplagte at parallelisere. Brug samtidighed.
Tag en stikprøve frem for at køre alt. Ved rutinekontrol kan du udtage 50 tilfælde fra et datasæt med 500 tilfælde. Kør det hele ved vigtige ændringer.
Tidsbudgettet er som regel “hvor længe kan en PR vente?” Sigt efter en fuld evaluering på <15 minutter. Derefter skifter udviklerne kontekst og mister produktivitet.
Operationelle mønstre
Her er nogle fremgangsmåder, der kendetegner modne evalueringsprogrammer:
Mønster 1: Udrulninger styret af evalueringer
Udrulning i produktion af ændringer, der påvirker LLM’er, afhænger af evalueringsresultaterne. Er scoren faldet under tærsklen? Så blokeres udrulningen. En udvikler undersøger årsagen.
Tærsklen er som regel relativ: “Scoren skal ligge inden for 2% af basislinjen.” Det tillader støj, men opdager væsentlige regressioner.
Mønster 2: Undersøgelse, når scorerne ændrer sig
Enhver meningsfuld ændring i scoren (op eller ned) bliver undersøgt. Steg scoren? Hvorfor? Har vi forbedret noget, eller blev testen nemmere? Faldt scoren? Hvor præcist? Er regressionen begrænset til ét udsnit?
Undgå at fejre eller gå i panik over samlede bevægelser; undersøg dem.
Mønster 3: Løbende kuratering af datasættet
Datasættet er ikke noget, man bygger én gang. Det kurateres løbende. Processen er:
- En bruger klager over et svar → føj det til datasættet som en regressionstest.
- En ny funktion lanceres → tilføj tilfælde, der dækker den.
- Modellens adfærd overrasker nogen → hvis det er en reel fejl, så tilføj den.
- Forældede tilfælde (ikke længere relevante): fjern dem.
Et månedligt gennemgangsmøde fungerer godt. Datasættet behandles som et levende aktiv.
Mønster 4: Gennemgang baseret på forskelle
Når du gennemgår et evalueringsresultat, skal du fokusere på forskellene i forhold til basislinjen:
- Tilfælde, hvor den nye version scorede højere end basislinjen (forbedringer).
- Tilfælde, hvor den nye version scorede lavere (regressioner).
- Tilfælde, hvor scoren var uændret (intet signal).
Forskellen er signalet. Det er urealistisk at gennemgå 500 tilfælde fra ende til anden; 30 forskelle kan håndteres.
Mønster 5: Menneskelig gennemgang af uenighed med dommeren
Udtag med jævne mellemrum (ugentligt?) tilfælde, hvor dommeren gav henholdsvis en lav og en høj score. Et menneske kontrollerer: Er du enig med dommeren?
Uenigheder afdækker:
- Dommerens bias (kalibrér dommerprompten).
- Reelle kvalitetsproblemer (ret systemet).
- Problemer i datasættet (tilfældets forventede output er forkert).
Sådan vedligeholder du dommerkvaliteten over tid.
Mønster 6: Kvartalsvis gennemgang af evalueringerne
Et kvartalsvist tilbageblik på selve evalueringsprogrammet:
- Hvilke reelle regressioner opdagede evalueringssuiten i dette kvartal?
- Hvilke reelle regressioner overså den?
- Hvilke falske alarmer udløste den?
- Hvilke kendte huller har vi i dækningen?
- Hvor godt dækker datasættet den aktuelle adfærd i produktion?
Det er en meta-evaluering: en evaluering af evalueringen. Uden den forringes evalueringsprogrammet.
Et gennemarbejdet eksempel: evaluering af kundesupport
For at gøre det konkret får du her en produktionsklar evalueringsopsætning til et AI-system, der svarer på henvendelser til kundesupport.
Mål: Sørg for, at AI’ens svar på kundernes spørgsmål er korrekte, hjælpsomme, i tråd med brandet og sikre.
Datasæt:
-
Regressionssuite (300 tilfælde):
- 50 nemme tilfælde (tydelige politikker, enkle svar).
- 100 mellemsvære tilfælde (typisk kompleksitet).
- 100 svære tilfælde (tvetydige, følsomme, sammensatte).
- 50 kendte fejltilfælde (scenarier, der tidligere har haft regressioner).
-
Opdagelsessuite (1000 tilfælde): Udvælges månedligt fra reel produktionstrafik med personhenførbare oplysninger fjernet.
-
Adversarial suite (50 tilfælde): Specialdesignede prompts, der forsøger at udtrække oplysninger, få refusion i tilfælde, der ikke opfylder betingelserne, eller manipulere AI’en.
Målinger:
For hvert tilfælde bedømmer dommeren:
- Faktuel korrekthed (1-5)
- Overholdelse af politikker (1-5)
- Passende tone (1-5)
- Fuldstændighed (1-5)
- Passende længde (1-5)
- Sikkerhed (binært: bestået/ikke bestået)
Dommere:
- Primær dommer: Claude (en anden udbyder end det testede system, som bruger GPT — valget af en anden udbyder modvirker dommerens præference for sin egen model).
- Kalibreret mod en menneskelig bedømmer på 100 referenceeksempler.
- Genkalibreres kvartalsvist.
Aggregering:
- Gennemsnitlig score pr. dimension pr. udsnit (udsnit: sagstype, kundeniveau, sprog).
- Beståelsesprocent for sikkerhed (skal være 100%).
- Vægtet score pr. tilfælde (bruges til sammenligninger).
Drift:
- Røgtest (30 tilfælde) på hver PR.
- Fuld regressionssuite (300 tilfælde), når en PR sammenflettes.
- Opdagelsessuite (1000 tilfælde) ugentligt.
- Adversarial suite (50 tilfælde) før enhver ændring af prompt eller model.
- Onlinestikprøve af 1% af produktionstrafikken, bedømt i realtid.
Gennemgang:
- Månedligt møde: Gennemgå udviklingen i evalueringerne, nye fejltyper og opdateringer af datasættet.
- Kvartalsvist møde: Meta-evaluering, kalibrering af dommeren og revision af datasættet.
Resultater (fra reelle udrulninger af lignende systemer):
- ~3 opdagede regressioner pr. måned, som ville være blevet sendt i produktion uden evalueringer.
- ~1 falsk alarm pr. måned (evalueringen markerer en regression, der reelt er acceptabel).
- Afdrift opdages inden for dage frem for uger/måneder.
- Større tryghed ved at sende ændringer af prompts og modeller i produktion.
Sådan ser evalueringer i produktionskvalitet ud. Det er ikke et hurtigt weekendprojekt, men en løbende investering med reelt investeringsafkast.
Almindelige faldgruber
Her er nogle mønstre, vi ser igen og igen:
Faldgrube 1: Evalueringer bygges, efter produktet er lanceret. “Vi tilføjer evalueringer senere.” Senere kommer aldrig. Byg dem fra første dag.
Faldgrube 2: Én udvikler ejer det hele. Én person bygger evalueringen, og ingen andre vedligeholder den. Når personen forlader teamet, forfalder evalueringen. Fordel ejerskabet.
Faldgrube 3: Evalueringer behandles som statiske. De bygges én gang og opdateres aldrig. De bliver ubrugelige, efterhånden som produktet udvikler sig. Behandl evalueringen som et levende aktiv.
Faldgrube 4: Blind tillid til evalueringsscorer. Evalueringen sagde, at det var bedre, så vi sender det ud. Uden menneskelige stikprøver sender du løsninger ud, som evalueringen vurderede højt, men som brugerne hader. Kombinér evalueringer med menneskelig gennemgang ved vigtige ændringer.
Faldgrube 5: Optimering mod evalueringen. Prompts finjusteres specifikt til at klare sig godt i evalueringen. Evalueringen bliver bedre, men virkeligheden gør ikke. Vær opmærksom på dette — hvis forbedringer i evalueringen ikke følges af forbedringer i produktion, optimerer du mod testen.
Faldgrube 6: Infrastrukturens omkostninger ignoreres. Evalueringer i stor skala er dyre (LLM-kaldene løber op). Uden omkostningssporing opdager du det først ved månedens udgang.
Faldgrube 7: Ingen klare kriterier for bestået/ikke bestået. “Scoren gik fra 4.2 til 4.0 — er det en regression?” Fastlæg tærsklerne på forhånd. Hold dig til dem.
Faldgrube 8: Evalueringssuiten optager al testindsatsen. Der bygges omfattende evalueringer, mens grundlæggende test af korrekthed mangler. Evalueringer er beregnet til kvalitetsafdrift; ikke al test er evaluering.
Den kulturelle del
Den sværeste del af evalueringer i produktion er kulturel. Udviklere og produktfolk skal:
- Stole nok på evalueringerne til at lade dem styre udrulninger. Ellers er evalueringerne blot teater.
- Være tilstrækkeligt skeptiske over for evalueringerne til at undersøge ændringer. Blind tillid fører til optimering mod testen.
- Investere i kuratering af datasættet som en løbende opgave. Det er ikke et engangsprojekt.
- Acceptere, at evalueringer ikke erstatter menneskelig dømmekraft. De reducerer den mængde, mennesker skal gennemgå.
- Erkende, når en evalueringssuite ikke fungerer. Når reelle regressioner slipper igennem, er problemet evalueringssuiten, ikke den bruger, der klager.
Teams med denne kultur leverer hurtigere og mere pålideligt. Teams uden den ender med enten at stole for meget på defekte evalueringer eller blive handlingslammede i deres fravær.
Konklusionen
Det er sværere, end det ser ud, at bygge evalueringer, der faktisk opdager regressioner, men det kan lade sig gøre.
Nøglerne er:
- Reelle, varierede datasæt hentet fra virkeligheden i produktion.
- Flerdimensionelle, udsnitsbevidste målinger, der stemmer overens med brugeroplevelsen.
- Kalibrerede dommere, som du faktisk har kontrolleret mod menneskelig dømmekraft.
- Flere evalueringssuiter til forskellige formål (regression, røgtest, opdagelse, online, end-to-end).
- Operationel disciplin: evalueringsstyrede udrulninger, løbende kuratering af datasættet og undersøgelse af ændringer.
- En kulturel forpligtelse til at bruge og forbedre evalueringerne over tid.
Når det gøres godt, bliver evalueringer den mest værdifulde infrastruktur i din AI-stack. De gør det muligt at levere hurtigt uden at miste kvalitet. Uden dem flyver du i blinde.
Byg evalueringerne. Stol på evalueringerne. Forbedr evalueringerne. Sådan fastholdes kvaliteten af AI i produktion.
