Evalueringer for ikke-ingeniører: Se, om jeres AI-arbejdsgang bliver bedre eller dårligere

Her er et mønster, vi ser hele tiden. Et team bygger en AI-arbejdsgang til f.eks. indholdsudkast, kategorisering af kundesupport eller generering af salgsmails. Den fungerer godt i uge 1. Teamet er begejstret og udruller den.

Tre måneder senere føles noget forkert. Kvaliteten af outputtet virker dårligere. Kunder klager. Sælgerne holder op med at bruge den. Ingen ved, hvornår det ændrede sig eller hvorfor.

Årsagen er næsten altid den samme: Ingen målte noget. Den fungerende arbejdsgang fra uge 1 kan gradvist være blevet dårligere. Den underliggende model, prompterne eller fordelingen af input kan have ændret sig. Uden måling opdager I det først, når brugerne klager — og da har I mistet deres tillid.

Løsningen er evalueringer — systematisk måling af kvaliteten i AI-output. Evalueringer behandles som regel som et teknisk anliggende, men alle teams med AI-arbejdsgange har brug for dem. Grundprincipperne kræver ingen kode.

Denne artikel forklarer, hvad evalueringer er, hvorfor de betyder noget, og hvordan I etablerer dem til enhver AI-arbejdsgang uden at være ingeniører.

Evalueringer er ikke rapporteringsteater. En nyttig evaluering fører til en beslutning: udgiv, vent, rul tilbage eller undersøg. Hvis en score ikke kan ændre teamets handlinger, skal evalueringen forenkles, indtil den kan.

Hvad evalueringer er — og ikke er

En evaluering måler systematisk kvaliteten af AI’ens output i forhold til eksempler, I selv kontrollerer.

Komponenterne er:

• Et datasæt. En samling input, som jeres AI behandler.
• Forventet adfærd. Det, I ønsker, at AI’en skal gøre med disse input.
• En bedømmelsesmetode. Sådan måler I, om AI’en gjorde det rigtigt.
• En kørsel og rapport. Behandl datasættet, bedøm hvert output, og sammenfat resultatet.

Formålet er at kunne stille det samme spørgsmål igen og igen: “Gør AI’en det, jeg ønsker, i den forventede kvalitet?” — og at opdage, når svaret ændrer sig.

Evalueringer er ikke:

• En enkelt test under den første udvikling.
• Stikprøver, når noget virker forkert.
• Brugerfeedback, som er nyttig, men reaktiv, langsom og påvirket af bias.
• Mavefornemmelser som “outputtet føles rigtigt”.

Rigtige evalueringer køres efter en tidsplan på et defineret sæt input med ensartet bedømmelse. De giver et signal, selv når ingen klager.

Hvorfor “ingeniørernes værktøjer” er forkerte for de fleste teams

Hvis I googler “LLM evals”, finder I artikler om værktøjer som Promptfoo, LangSmith, Braintrust og Helicone. De er fremragende. De er også udviklet til ingeniører, der leverer LLM-baserede produkter i stor skala.

For de fleste teams, der driver AI-arbejdsgange inden for marketing, salg, drift eller support, er disse værktøjer mere end nødvendigt. I har brug for noget enklere: en måde at måle jeres konkrete arbejdsgang på uden at lære en hel værktøjsstack.

Den gode nyhed er, at det kan gøres med et regneark og en LLM. Ikke med LangSmiths avancerede funktioner, men godt nok til at opdage de fleste kvalitetsproblemer.

De fire evalueringsmønstre

Der findes fire almindelige evalueringsmønstre. De passer til hver sin type arbejdsgang.

Mønster 1: Præcist match

Brug det, når der findes ét korrekt svar.

Eksempel på arbejdsgang: Kategorisering af kundesupportsager i 8 kategorier.

Datasæt: 50 sager med den korrekte kategori. Bedømmelse: AI’ens svar matcher enten den korrekte kategori (1 point) eller gør ikke (0 point). Output: % korrekte.

Det fungerer godt til klassifikation, udtræk og enkle strukturerede output.

Mønster 2: Sammenligning med reference

Brug det, når der findes et kendt godt svar, I kan sammenligne med.

Eksempel på arbejdsgang: Udkast til produktbeskrivelser.

Datasæt: 30 produkter med referencebeskrivelser, I selv har skrevet. Bedømmelse: Hvor tæt ligger AI’ens beskrivelse på referencen med hensyn til f.eks. nøjagtighed, tone og fuldstændighed?

I kan bedømme det manuelt ved at lade et menneske læse begge og give 1-5 point eller bruge en LLM som dommer, hvilket er det næste mønster. Sammenligning med reference er guldstandarden for indholdsarbejdsgange.

Mønster 3: LLM som dommer

Brug det, når outputtet kan have mange gyldige former, men kvaliteten kan bedømmes.

Eksempel på arbejdsgang: Generering af personaliserede salgsmails.

Datasæt: 30 profiler på kundeemner. Bedømmelse: En LLM fungerer som dommer og bedømmer ud fra input og output dimensioner som konkrethed, professionalisme, længde og match med tonen.

En LLM som dommer er effektiv, men kræver omhyggeligt promptdesign. Et almindeligt mønster:

You are evaluating a sales email for quality. Score it on these dimensions:

1. Specificity (1-5): Does it reference specific facts about the prospect, not generic flattery?
2. Professionalism (1-5): Does it sound like a peer rather than spam?
3. Length appropriateness (1-5): Is it concise (40-80 words)?
4. Voice match (1-5): Does it match our voice (direct, no buzzwords)?

For each dimension, give the score and a one-sentence reason.

Output JSON: {"specificity": {"score": N, "reason": "..."}, ...}

Prospect profile: [input]
Email to evaluate: [output]

Dommer-LLM’en giver en ensartethed, som menneskelige bedømmere ikke kan levere: Én dommermodel og én prompt anvendes ens på alt. Men en dommer, I aldrig har kontrolleret, er blot en anden mening af ukendt kvalitet. Kalibrér den derfor grundigt én gang:

1. Tag 50 eksempler, som teamet allerede har mærket med bestået/ikke bestået eller jeres pointskala. Genbrug virkelige sager fra gennemgangskøen; opfind ikke syntetiske eksempler.
2. Kør dommeren på de samme 50 og mål enigheden. Når enigheden er over cirka 85%, kan I bruge den til rutinemæssig screening og lade mennesker kontrollere en stikprøve. Ligger den mellem ~70% og 85%, skal I læse alle uenigheder. Det skyldes næsten altid uklare kriterier, ikke en dum dommer — præcisér kriterierne, og kør igen. Når den er under ~70%, må I ikke automatisere med dommeren, for så måler den noget andet end jer.
3. Se på fejlretningen, ikke kun fejlprocenten. En dommer, der godkender dårlige output, er farlig. En, der markerer gode output, er blot irriterende. Sæt grænsen derefter.
4. Kalibrér igen på 20-30 nye eksempler, hver gang I ændrer dommermodel, dommerprompt eller kriterier — alle tre kan flytte enigheden uden varsel.

Disse intervaller er vores anbefalede startprotokol, ikke en naturlov. Det ufravigelige krav er, at kalibreringen sker, før dommerens point får lov til at blokere eller godkende noget.

Mønster 4: Kontrol af egenskaber

Brug det, når I kan udtrykke “godt” som konkrete egenskaber, der kan testes.

Eksempel på arbejdsgang: Generering af produkttitler til en netbutik.

Datasæt: 50 produkter. Egenskaber, der kontrolleres for hvert output:

• Længden er 30-70 tegn.
• Indeholder mærkenavnet.
• Indeholder mindst én af produktets vigtigste egenskaber.
• Bruger ikke forbudte marketingord som “fantastisk”, “bedst” og “revolutionerende”.

Hver egenskab er en ja/nej-test. Point = % beståede egenskaber på tværs af alle output.

Kontrol af egenskaber er velegnet til strukturelle krav, der altid skal være opfyldt. Kontrollen kører hurtigt og opdager konkret drift.

Sådan etablerer I jeres første evaluering

En praktisk opsætning for ikke-ingeniører:

Trin 1: Vælg arbejdsgangen

Vælg én arbejdsgang. Forsøg ikke at evaluere alt på én gang. Vælg den, hvis kvalitet bekymrer jer mest, eller den, der har størst konsekvens.

Eksempel: “AI’en, der kategoriserer indgående kundesupportsager efter emne.”

Trin 2: Byg datasættet

Opret en liste med 20-50 repræsentative eksempler. Medtag:

• Lette tilfælde, der tydeligt tilhører kategori A.
• Svære tilfælde, der kan være A eller B.
• Grænsetilfælde, der ikke passer rent i nogen kategori.
• Almindelige variationer, hvor samme hensigt formuleres forskelligt.

Gem dem i et regneark eller Google Sheet:

Dette datasæt er jeres evalueringssæt. Det bør ikke ændres ofte, fordi formålet er at være en stabil reference.

Trin 3: Definér bedømmelsen

Hvad tæller som et korrekt svar for hvert eksempel? Vær præcis.

Ved klassifikation: præcist match med kategorien. Ved indhold: en score på 1-5 for hver af 2-4 navngivne dimensioner. Ved udtræk: hvert felt er korrekt eller forkert.

Skriv vurderingskriterierne ned. Hold jer til dem.

Trin 4: Kør arbejdsgangen på datasættet

Kør AI-arbejdsgangen på hvert eksempel i datasættet. Gem outputtet i en ny kolonne.

Ved klassifikation kan det gøres i et regneark med en funktion som Google Sheets’ GPT-integration eller ved manuel kopiering.

Ved mere komplekse arbejdsgange kan inputtene lægges i et værktøj som Promptfoo eller køres som et batchjob én gang om ugen.

Trin 5: Bedøm

Ved præcist match tilføjer I en kolonne kaldet “match” og indsætter ved match værdien 1 og ellers værdien 0 ved afvigelse. Læg tallene sammen; det er jeres nøjagtighed.

Med en LLM som dommer kører I en dommerprompt på hvert output og gemmer pointene.

Ved kontrol af egenskaber køres hver egenskab som en separat test. Resultaterne sammenlægges.

Den mindst mulige brugbare resultattavle

I den første evaluering skal I måle færre dimensioner, men sikre, at hver af dem kan føre til handling.

Resultattavlen skal angive en ejer og en udgivelsesregel. “Under 90% korrekthed kræver gennemgang fra produktejeren” er stærkere end “mål korrekthed”.

Trin 6: Sammenfat

Brug f.eks. en oversigtstabel:

Over tid viser den kvalitetsudviklingen. Fald udløser en undersøgelse.

Trin 7: Planlæg

Kør evalueringen efter en fast tidsplan. Ugentligt er tilstrækkeligt for de fleste arbejdsgange. Kør den før udrulning efter alle ændringer af prompts eller model.

Gør det til en ugentlig vane på 30 minutter. Opret en tilbagevendende kalenderaftale. Spring ikke over.

Den tilhørende resultattavle, der er linket fra artiklen, er udformet til denne første ugentlige kørsel.

Tilføj en udgivelsesport

Evalueringer betyder mest, når de står foran en ændring. Brug en lille udgivelsesport til alle AI-arbejdsgange, der berører kunder, driftsoplysninger eller teambeslutninger:

1. Baseline. Den nuværende produktionsarbejdsgang har en registreret score.
2. Kandidat. En ny prompt, model, et nyt værktøj eller trin køres på det samme evalueringssæt.
3. Sammenligning. Kandidaten skal bevare sikkerheds- og regressionsscorerne og må ikke reducere det primære kvalitetsmål ud over den aftalte tolerance.
4. Beslutning. Udgiv, vent, revidér eller rul tilbage. Registrér begrundelsen.
5. Kontrol efter udgivelse. Kør igen på en lille stikprøve af virkelige sager efter lanceringen.

Det behøver ikke være automatiseret fra første dag. Et regneark med en navngiven godkender er tilstrækkeligt, hvis det konsekvent forhindrer umålte ændringer i at gå i produktion.

Hvad I gør, når scoren falder

Evalueringernes formål er at opdage kvalitetsforringelse. Når det sker, undersøger I årsagen.

En enkel undersøgelse:

Trin 1: Find de fejlede tilfælde. Hvad gik konkret galt?

Trin 2: Find mønstre. Er fejlene samlet omkring lignende input eller spredt over forskellige inputtyper?

Trin 3: Diagnosticér.

• Mønster → sandsynligvis en konkret svaghed som et promptproblem eller manglende viden.
• Spredt → sandsynligvis et generelt kvalitetsfald som modelændring eller drift.

Trin 4: Opstil en hypotese om årsagen.

• Er den underliggende model blevet ændret for nylig? Kontrollér leverandørens ændringslog.
• Er prompten blevet ændret for nylig? Rul tilbage, og test.
• Har fordelingen af input ændret sig? Undersøg de seneste virkelige data.
• Er datasættet blevet forældet? Opdater eksemplerne.

Trin 5: Test rettelsen. Foretag én ændring. Kør evalueringen igen. Blev scoren genoprettet?

Denne systematiske fremgangsmåde er bedre end panik og gætværk.

Udbygning af datasættet over tid

Det første datasæt er et udgangspunkt. Forbedr det over tid ved at:

Tilføje virkelige fejltilfælde. Når en sag fra en virkelig kunde eller bruger giver et dårligt output, skal den føjes til evalueringssættet. Nu er den en regressionstest, der opdager netop denne fejl, hvis den opstår igen.

Fjerne forældede tilfælde. Når arbejdsgangen udvikler sig, bliver nogle tests irrelevante. Fjern dem.

Udvide dækningen. Hvis evalueringssættet har 20 sager om “kontoadgang” og 1 om “fakturering”, er det skævt. Skab balance.

Tilføje grænsetilfælde, når I finder dem. Nye mønstre i kundeklager, nye produktfunktioner og nye kategorier.

Et godt evalueringsdatasæt er levende — det afspejler den aktuelle virkelighed, ikke den historiske.

Typiske fejl

Nogle mønstre får evalueringsprogrammer til at mislykkes:

Fejl 1: At bygge den perfekte evaluering før start. Et datasæt med 50 eksempler og avanceret bedømmelse kan virke uoverskueligt. Et datasæt med 10 eksempler og enkel bedømmelse kan bygges i dag. Begynd småt. Tilpas løbende.

Fejl 2: Kun at evaluere normale succesforløb. Enkle eksempler alene opdager ikke virkelige fejl. Medtag svære tilfælde, grænsetilfælde og kendte tidligere fejl.

Fejl 3: Drift i evalueringssættet. Hvis sættet opdateres, hver gang arbejdsgangen ændres, bliver scoren meningsløs. Evalueringssættet bør ændres sjældent; arbejdsgangen må ændres oftere. Formålet er at måle arbejdsgangen, ikke evalueringen.

Fejl 4: Blind tillid til LLM-dommeren. LLM-dommere har bias. De lægger for stor vægt på overfladiske egenskaber som længde og format. Kalibrér jævnligt dommeren mod menneskelig dømmekraft. Hvis I er uenige med dommeren, skal dommerprompten forbedres.

Fejl 5: Point uden handling. Ugentlige evalueringer uden handling på dataene er teater. Formålet er at opdage og rette problemer. Hvis et fald ikke udløser en undersøgelse, spilder I tiden.

Fejl 6: Kun at evaluere én dimension. “Min evaluering viser 95% nøjagtighed!” — men måske er svarenes kvalitet blevet dårligere, svartiden længere eller hallucinationsfrekvensen højere. Mål flere dimensioner, hvor de betyder noget.

Værktøjer, der hjælper, men ikke er nødvendige

Hvis I vil videre fra regneark, er der nogle tilgængelige muligheder:

Promptfoo. Open source, konfigureres med YAML og kører på jeres computer eller i CI. Fremragende til at teste og sammenligne prompts.

Braintrust. Hostet platform til evalueringer med en god brugergrænseflade. Dyrere, men effektiv.

LangSmith. Specifikt knyttet til LangChain-arbejdsgange og velegnet, hvis I bruger det økosystem.

Helicone. Logning og analyse af LLM-kald med evalueringsfunktioner.

OpenAI Evals. Open source-framework med større fokus på udviklere.

For de fleste teams uden ingeniører er et regneark + ChatGPT/Claude nok. Promptfoo er det letteste “rigtige værktøj”, når I vil videre.

Et evalueringsprogram på 4 uger

En realistisk plan for et team, der begynder fra nul:

Uge 1: Vælg og definér.

• Vælg én arbejdsgang.
• Byg et datasæt med 20 eksempler.
• Definér bedømmelsen som præcist match, LLM-dommer eller egenskaber.

Uge 2: Første baseline.

• Kør evalueringen. Gem baseline-scoren.
• Find åbenlyse fejl.
• Ændr ikke noget endnu — observér blot.

Uge 3: Tilpas.

• Foretag én ændring, som I tror vil forbedre kvaliteten.
• Kør evalueringen igen.
• Steg scoren? Faldt den? Var den uændret? Undersøg hvorfor.

Uge 4: Planlæg.

• Planlæg ugentlige kørsler.
• Dokumentér evalueringsprocessen.
• Orientér teamet om, hvad scorerne betyder, og hvad der udløser handling.

Efter 4 uger har I en fungerende evaluering. Udvid derfra: Føj flere arbejdsgange til evalueringsprogrammet, gør datasættet dybere, og finjustér bedømmelsen.

Kulturændringen

Evalueringer kræver i højere grad en kulturel end en teknisk ændring. Teams, der er vant til at udrulle AI-arbejdsgange, “fordi de ser ud til at virke”, skal tage måling til sig.

Ændringen indebærer:

Villighed til at se tallene falde. Nogle gange skader en ændring, I glædede jer til, kvaliteten. Evalueringerne viser det. I skal være villige til at rulle tilbage.

Investering i kalibrering. I den første måned med en ny evaluering skal I forvente at bruge tid på at justere datasættet, bedømmelsen og prompterne. Det er en investering.

En vane med “før og efter”. Alle væsentlige ændringer i en AI-arbejdsgang køres gennem evalueringen, før de går i produktion. Det bliver en selvfølge.

At fastholde kvalitetskravet. Når scorerne falder, retter I eller ruller tilbage. I udgiver ikke forringet kvalitet på grund af en deadline.

Kulturændringen er den sværeste del. Når den er på plads, er værktøjerne lette.

Én arbejdsgang, tyve eksempler, en halv time om ugen

Evalueringer er forskellen mellem AI-arbejdsgange, I kan stole på over tid, og arbejdsgange, der ubemærket glider ned i middelmådighed.

I behøver ikke ingeniører, ML-ekspertise eller avancerede værktøjer for at begynde. I har brug for en arbejdsgang, der er værd at måle, et lille datasæt, en bedømmelsesmetode og en halv time om ugen.

Vælg én arbejdsgang i denne uge. Byg en evaluering med 20 eksempler. Kør den. Se resultatet. Kør den igen i næste uge. Bemærk den disciplin, det skaber.

Om 6 måneder vil teams med evalueringer have AI-arbejdsgange, der faktisk er blevet bedre. Teams uden evalueringer vil have arbejdsgange, der ligner dem, de havde for 6 måneder siden — bare dårligere.