LLM-as-a-judge er ikke bare en prompt
En LLM-dommer er en sprogmodel, der bedømmer en anden models output efter eksplicitte kriterier eller en rubric. Det lyder bekvemt. Det er det også, når dommeren bygges og vedligeholdes som et lille ML-system. Ellers rammer den ved siden af. Den praktiske vejledning samler definitioner og fejlkilder, og en faglig manual advarer mod falsk tryghed, når scorer ikke er kalibrerede.
Hvorfor teams bruger dommere nu
Skalering er hovedtrækket. LLM-dommere bruges i stigende grad i stedet for mennesker eller simple string- og code-tjek, fordi de kan køre tusindvis af outputs døgnet rundt og holde en ensartet rubric. De passer ind i A/B-tests før release, i CI-regressions-gates og i produktionsmonitorering, hvor man vil fange kvalitetsfald uden manuelt at læse alt. Det er udbredt i flere produktionsnære miljøer, ikke kun i labs.
Automatisering uden styring giver dog sjældent ro i maven. Når en dommer ændrer adfærd efter en modelopdatering, eller en skjult bias rammer netop den tone eller opgavetype, der pludselig fylder, skrider billederne. Bedøm derfor også dommeren, ikke kun modellen.
Tre måder at dømme på
Der er tre udbredte tilgange: Single-output scoring (én score til ét svar). Pairwise (to svar sammenlignes, ét vinder). Reference-baseret (hvert svar holdes op mod et facit eller en kanonisk tekst). Pairwise anbefales ofte som robust udgangspunkt i praksis, fordi man undgår skala-glid og fanger relative præferencer bedre.
Reference-baseret er stærk, når der faktisk findes et troværdigt facit. Det gør der ikke altid, især ikke ved stil, tone eller længere sammenfatninger. Single-output scorer er hurtige, men følsomme for rubric, skala og kontekst. Små promptændringer kan flytte middelscoren mere end selve forandringen i modelkvalitet. Upraktisk, hvis scorekurver styrer release.
Hvor dommere går galt
Position-bias er klassisk: første (eller sidste) svar favoriseres. Self-preference er mere snedig: dommeren favoriserer svar, der ligner dens egen stil eller træningssignaler. Begge dele er væsentlige fejlkilder og kræver designværn. Læg dertil den stille dræber: manglende kalibrering til den konkrete opgave. Uden det flytter dommeren målestokken fra dag til dag.
Konsekvensen er ikke kun akademisk. Ustabile dommere kan pege en udviklingsretning ud, der ser lovende ud i metrics, men ikke i brugerhænder. Eller godkende automatiske svar i kundeservice, som en erfaren medarbejder ville have underkendt. Det er dyrt at rydde op efter og en smule pinligt.
En praktisk tjekliste, der faktisk hjælper
Ni skridt, som kan stå i kalenderen. Ikke pænt symmetrisk, bare brugbare.
- Start med virkelige fejl. Saml konkrete fejlsvar fra jeres model, og lad dommeren lære sin dømmekraft dér.
- Begræns kriterierne. Få, skarpe rubrics er mere stabile end brede kataloger.
- Brug binære beslutninger når muligt. Vælg A eller B. Godkend eller afvis. Skalaer skrider.
- Tving begrundelser før dom. Kræv strukturerede rationaler før “vinder er B”.
- Læg few-shot ankre ind. Få, faste eksempler, der binder tolkningen op.
- Decomponér subjektive domme. Del “god e-mail” i korrekthed, tone, klarhed.
- Pin konfigurationen. Versionér prompts, skalaer, ankre og dommermodel.
- Kalibrér mod menneskelige labels og mål enigheden. Aftal metrikker på forhånd.
- Lav et ensemble, når indsatsen er høj. Flere dommere, eventuelt med menneske i løkken.
Det er disciplinarbejde. Ikke magi.
Kalibrering og validering i praksis
Kalibrering handler om at tilpasse dommeren til opgaven og bekræfte, at dens afgørelser stemmer med mennesker. I praksis: lav et stratificeret sæt eksempler, hvor mennesker bedømmer outputs efter samme rubric som dommeren. Mål enigheden mellem dommer og mennesker med robuste mål som Cohen’s kappa eller Krippendorff’s alpha. Hold en del af data helt ude som sandt hold-out.
Hvor stort et sample? Kilderne giver ikke faste tal, og det er en reel mangel. Subjektive opgaver (tone, stil, opsummering) kræver typisk større og bredere sæt end faktuelle tjek. Stratificér på sværhedsgrad, længde og domæne, så dommeren ikke “lærer” kun de nemme hjørner. Kør en pilot for at teste rubric og instruktioner. Ret til. Først derefter fuld kalibrering. Markér også “kan ikke vurderes” som en særskilt mulighed, så uenighed ikke blandes med usikkerhed.
Kontinuerlig monitorering af dommeren
Dommerens adfærd kan drive. Nye modelversioner, driftsændringer eller skift i indkommende emner. Overvåg den som en selvstændig komponent. Track enighedsmål på friske stikprøver. Indfør alarmgrænser for kappa/alpha og for stabilitet i pairwise-udfald. Gem auditerbare logs af domsbegrundelser, så en kendelse kan efterprøves uger senere uden at gætte, hvad prompten sagde dengang.
Benchmark-contamination og NEEDLEs modsvar
Når et system kan læse facit, er evalueringen ikke længere gyldig. Det gælder både når gold labels ligger i et offentligt datasæt, som en agent kan hente under testen, og når svarene i praksis allerede er indkodet i modellens parametre. En reportage om NEEDLE-benchmarket beskriver en konkret mitigation: kør med live, hyppigt regenererede queries, som ikke kan memoreres én gang for alle.
Hvornår live-benchmarks giver mening
Live eller hyppigt regenererede benchmarks er stærke i domæner, hvor fakta flytter sig: nyheder, finans, dele af jura. I mere statiske domæner er gevinsten mindre. Man kan i stedet rotere et stort, upubliceret testlager og variere formulering, rækkefølge og navne for at undgå, at dommeren (eller modellen) kører på genkendelse.
I regulerede domæner rejser live-benchmarks også governance-spørgsmål. Hvem godkender kildelisterne? Hvordan auditeres versionsskift i query-generatoren? Der skitseres ikke en fuld metode her. Det er et hul, som bør lukkes med domænespecifikke retningslinjer.
Integration i udviklingscyklussen
Gør dommeren til en førsteklasses borger i repoet. Versionér alt: dommermodel, prompts, ankre, rubric, skala. Lås dem i CI via pin-filer. Et versionsskift i dommeren skal behandles som et produktionsskift, ikke en gratis opgradering. Ellers får man metrik-svingninger, der ligner modelforbedringer, men i virkeligheden er nye dommervaner.
Før release: kør pairwise A/B med dommeren og valider stikprøver med mennesker, især dér, hvor dommeren er uenig eller usikker. I produktion: overvåg distributionsskift i input, hold øje med længde og struktur i domsbegrundelser, og hav en rollback-strategi. En enkel regel virker: hvis dommerens aftale med mennesker dykker under den aftalte tærskel, så slå dommerstyret automatisering fra og gå tilbage til HITL.
Risici og tradeoffs i klar tekst
Falsk tillid er hovedrisikoen. En pæn kurve kan dække over systematisk bias. Beslutninger, der rammer kunder, produkter og compliance, bliver derefter forkerte og kan koste mere, end de sparer. Samtidig er der en reel omkostning ved løbende kalibrering: menneskelige labels, CI-minutter, pipeline-vedligehold. Der sættes ikke tal på budgettet her, og det er værd at efterlyse.
Governance kommer oveni. Hvem ejer dommeren, hvem må ændre rubric, hvordan godkendes nye ankre. Uden klare svar ender dommeren som et gråt område mellem data science og drift, og det er præcis dér, fejl trives.
Hvornår man bør lade være
Hvis opgaven kan løses med deterministiske checks, så gør det. Hvis der findes billig, pålidelig ground truth, brug den. Og hvor specialistviden er snæver og vigtig (fx medicinske diagnoser eller kontraktfortolkning) er en LLM-dommer ofte den forkerte hammer. Ikke et nederlag. Sund fornuft.
Nogle gange er en simpel diff-test eller en statisk parser mere ærlig end en stor model med fine ord. Den siger bare ja eller nej. Nogle systemer har netop brug for det.
Teknisk tjekliste til implementering
En kort, jordnær liste over komponenter, der gør en LLM-dommer driftsklar.
- Versionering og pin-filer for dommermodel, prompts, skalaer og ankre.
- Reproducerbar kørsel med faste seeds, temperatur og kontekstvindue.
- Storage til few-shot ankre og rubric-udgaver med changelog.
- Ensemble-manager til at kombinere dommere og vægte afgørelser.
- Kalibreringspipeline med menneskelige labels og enighedsmål.
- Overvågningsdashboard, inkl. drift, distributionsskift og judge-the-judge.
- Audit-logs af domsbegrundelser og endelige kendelser.
Ikke glamourøst. Men det er forskellen på held og metode.
Valg mellem judging-modes i praksis
Hvornår er pairwise bedst? Når målet er præference eller kvalitet uden entydigt facit, og man vil minimere skala-drift. Reference-baseret passer, når der findes stabile, troværdige svarnøgler (klassiske QA, faktatjek). Single-output er fint til hurtige regressionstjek, men kræver tæt kalibrering og faste skalaer.
Der mangler stadig kvantitative retningslinjer for gevinsten ved at skifte mode i konkrete domæner. Hvor meget stiger kappa, når man går fra single til pairwise i opsummering. Der gives ikke tal. Det må testes lokalt.
Hvad der bør undersøges videre
Tre huller står tilbage: For det første kvantitative effekter af kalibrering på enighedsmål i almindelige arbejdsgange. For det andet praktiske guidelines for sample-størrelser og stratificering per opgavetype. For det tredje domænespecifikke varianter af live-benchmarks uden uoverkommelige driftsomkostninger. Her kan branchen løfte sig hurtigt med åben metode.
Indtil tallene kommer, må produktteams lave deres egne små, men stringente forsøg. Hellere ét godt kalibreret domæne end ti halvbagte.
Konklusion uden sløjfe
LLM-as-a-judge kan øge tempoet i udvikling og drift. Men dommeren er selv en model, ikke en magisk målepind. Byg den som et lille ML-system, kalibrér den mod mennesker, overvåg den, og brug ensembles og HITL, når indsatsen er høj. Integrér den i CI som en versioneret komponent med faste pins og auditerbare logs. Slå automatiseringen fra, når den mister fodfæste.
Man opdager forskellen, når en ny release ser bedre ud på kurven og bedre ud for dem, der faktisk læser svarene.
Appendiks forslag
Skabelon til rubric (kort): Korrekthed, Fuldstændighed, Klarhed, Stil. Binary per delkriterium, samlet dom efter vægtning. Few-shot ankre gemmes med versions-id og datostempel.
Kalibreringsmatrix: Rækker = delkriterier, kolonner = menneskelig dom vs. LLM-dom. Udfyld med confusion counts og beregn kappa per del. Hold-outs markeres separat. Tærskler: under 0,4 er svagt, 0,4–0,6 tåleligt, over 0,6 brugbart; sig højere, hvor stakes er høje. Fortolk tallene som heuristik, ikke som en lov. Sørg for at rubric og label-sæt er identiske for mennesker og dommer, og dokumentér hvordan uenighed og “kan ikke vurderes” håndteres.
Kilder og metode
Artiklens definitioner, modes og tjekliste stammer fra en teknisk gennemgang af LLM-as-a-judge. Advarsler om falsk tryghed, behov for kalibrering og praktiske safeguards går igen i en faglig manual. Eksemplet på live-benchmarking og contamination-mitigation er beskrevet i en reportage om NEEDLE, der regenererer queries løbende. Hvor kilder ikke kvantificerer anbefalinger, er det markeret eksplicit som åbne spørgsmål.
