Sådan ved du om din LLM rent faktisk er blevet bedre
Den vigtige nyhed først. Towards AI har publiceret – og den 24. august 2026 opdateret – The Evaluation Stack af Armin Norouzi, Ph.D., en guide der hævder, at det sværeste ingeniørproblem i LLM‑udrulning ikke er latenstid eller rå pris. Citat: “The hardest engineering problem in LLM deployment is not latency or cost, it is knowing whether your model got better.” Pointen er måling af reel forbedring – ikke en flot score i et regneark, men forudsigelser af brugernes faktiske oplevelse i drift.
Hvor traditionelle metrics svigter
Guiden kalder BLEU, ROUGE og BERTScore “metrics that seem rigorous” men påpeger, at de korrelerer svagt med menneskelig vurdering. Mekanismen er velkendt: overlap belønnes, variation straffes, og metrikkerne kan spilles. Det er afgørende for CI/CD: Lader man et pull request gå igennem på et par procentpoints i BLEU, risikerer man at skubbe en regression til brugerne næste dag.
Hvad virker bedre – og hvad koster det
Ifølge Towards AI korrelerer GPT‑4‑agtige dommere og task success‑rate langt bedre med menneskelig præference. Task success måler, om opgaven faktisk blev løst i henhold til en specifikation – ikke om svaret ligner en reference. Det kræver klare succeskriterier og ofte dyre modelkald.
Kilden advarer eksplicit om prisen. Citat: “Metrics that correlate well … cost hundreds of dollars per evaluation run.” Det er et omtrentligt niveau og bør valideres mod faktisk vendor‑prissætning eller interne regninger, for priser flytter sig og afhænger af eval‑sættets størrelse. Bundlinjen: uden budget ender man let tilbage ved billige overflademetrikker.
Bias i LLM‑dommere og hvorfor det betyder noget
LLM‑dommere er ikke neutrale. Towards AI oplister blinde vinkler, man bør mitigere: self‑preference, positionseffekter, længdeeffekter, rubric‑drift og benchmark‑mætning. Eksempel: første svar vinder, fordi det står først – eller længere svar vurderes som mere kompetente.
Guiden anbefaler bevidst mitigering, men konkrete, repeterbare teknikker og målt effekt mangler i kilden. Her efterlyses interviews med ML‑evalueringsfolk om brug af prompt‑ensembler, kalibrering og kontrafaktiske prompts i produktions‑pipelines.
Fire lag af evaluering der kan holde kvaliteten
Norouzi foreslår en firelags stack, der optimerer signal pr. krone. Første lag er kontinuerlige deterministiske checks: unit‑tests til kæder, schema‑validering, specificerede regex‑regler og regressioner på hver commit. Hurtigt feedback, lav pris.
Andet lag er natlige semantiske og faktuelle tjek: automatiserede LLM‑baserede kontroller, der kan udtrække fakta, tjekke citater, validere henvisninger og teste retriever‑kvalitet. Dyrere end rene deterministiske checks, men langt billigere end menneskelig A/B.
Tredje lag er release‑candidate‑vurdering med en stærk dommermodel som GPT‑4. Her samles et repræsentativt eval‑sæt, og en kandidat build gates på baggrund af dommerens præference og rubric. Fjerde lag er periodisk menneskelig A/B‑evaluering: mennesker, systematisk, med klare rubrics. Langsomt og dyrt – men det kalibrerer hele stakken.
Tradeoffs er tydelige: nederste lag svarer hurtigt og billigt, men er grovkornet; øverste lag er signalstærke, men sene og dyre. Planlæg på forhånd, hvornår hvert lag må blokere en release.
Implikationer for drift og CI/CD
For produktionspipelines betyder det instrumentering – ikke kun dashboards. Task success skal måles i produktion, ikke blot i lab: fx andel automatisk løste sager uden eskalation, korrekt udfyldte felter i et formularflow, tid til løsning eller forsøg før succes. Metrics bindes til builds, så regressioner spores til konkrete ændringer.
Derudover bør natlige semantiske kontroller være en planlagt jobklasse i MLOps: fast eval‑sæt med viden der driver, hallucinationstests i kritiske dele af produktet, og retriever‑sanity‑checks. Release‑gating bør bruge et ensemble af signaler, ikke ét tal. Og en kvartalsvis menneskelig A/B‑runde bør have fast kalenderplads og budget.
Sikkerhedsterskler er produktvalg
Guiden rammer et vigtigt punkt om sikkerhedsevaluering. Base‑rate, precision og recall trækker i hver sin retning, og en flot F1 er ikke et entydigt mål. Nogle produkter bør tåle flere falsk positive advarsler for at undgå få falsk negative hændelser; andre har omvendt præmis. Det er et produktvalg – teknikken måler, forretningen bærer risikoen.
Praktisk bør sikkerhedstærskler sættes i et forum, hvor produktledelse, sikkerhed, jura og drift deltager. Vælg fx en konservativ blokering for farlige handlinger, men advisering for gråzoner. Dokumentér beslutningen, og følg op, når distributionsskift ændrer base‑raten.
Benchmark‑mætning og eval‑set‑hygiejne
Norouzi advarer om benchmark‑mætning: træning op mod de samme åbne sæt gør papirgevinster mindre forudsigelige for produktion. Løsningen er egne, opgavespecifikke eval‑sæt med headroom. Det kræver kuratering, versionsstyring og en strategi for at holde sæt hemmelige for træningen.
I praksis: holdouts der simulerer distribution shifts, adversariale testcases og løbende opdatering baseret på fejl fra drift. Kilden giver rammerne, men ikke en detaljeret opskrift – her kræves eget metodearbejde.
Ensemble‑evaluering og signalfusion
Towards AI anbefaler ensemble‑evaluering på tværs af dimensioner. Ét tal kan snyde; tre uafhængige signaler gør det sværere. Vægt funktionelle metrics højere end overflademetrikker, lad dommermodeller give præference‑signal, og læg en sikkerhedsscore som hård gating. Det reducerer varians og falske positiver.
Det kræver disciplin: korrelationsanalyse mellem signaler, så en metric ikke dominerer ubemærket; undgå at tune thresholds på det samme eval‑sæt, der senere bruges til at bekræfte forbedringer.
Hvorfor funktionelle metrics er sværere at spille
Et særskilt råd i guiden er at lægge mere vægt på funktionelle metrics som task success og specifikations‑tjeklister. De er ofte billigere end dommermodeller, mere diagnostiske og sværere at spille, fordi de knytter sig til produktets regler. Et korrekt udfyldt skattekodefelt er binært – enten rigtigt eller forkert – og regex’en fanger det.
Begrænsningen er dækning. Ikke alt kan tjekkes deterministisk. Derfor fungerer de bedst i første og andet lag, hvor de fanger brede regressioner hurtigt, mens de øverste lag kalibrerer den overordnede brugeroplevelse.
Et konkret modstykke: Harvey Tenet
MarkTechPost rapporterer, at Harvey har frigivet Harvey Tenet som research preview. Ifølge artiklen er Tenet en Kimi K3‑base post‑trænet med Fireworks via asynkron reinforcement learning til langhorisontet juridisk agentarbejde. Harvey angiver, at træningskorpusset kombinerede syntetiske data, offentligt tilgængelige juridiske data og menneskelig ekspertdata, og at der ikke blev brugt kundedata.
Harvey rapporterer markante benchmarkforbedringer: næsten dobbelt så mange løste held‑out opgaver på Harvey’s Legal Agent Benchmark sammenlignet med base K3 og 20 procent flere på LAB: Contracts. All‑pass‑rate stiger med henholdsvis 9 og 2 procentpoint. Det er stærke tal, men MarkTechPost understreger også, at Tenet er en research preview uden publicerede vægte, modelkort eller API. Det illustrerer kløften: benchmarkfremskridt er ikke i sig selv deploybarhed.
Hvad man kan gøre i morgen
Start med fem ting: 1) instrumentér task success i produktion og bind signalet til builds; 2) sæt natlige semantiske kontroller op med et fast eval‑sæt; 3) definér et ensemble af gating‑signaler, hvor ingen enkeltmetric alene kan tillade deploy; 4) planlæg en kvartalsvis menneskelig A/B med budget og tydelige rubrics; 5) lav en eval‑set‑hygiejneplan med versionering og headroom.
Åbne spørgsmål og hvad der mangler af dokumentation
Nogle udsagn i denne artikel hviler alene på de to kilder fra Towards AI (opdateret 24. august 2026, Armin Norouzi, Ph.D.) og MarkTechPost. Det gælder centrale citater, prisanslag og listen over bias‑typer i LLM‑dommere. Flere forhold kræver yderligere verificering: præcise prisstrukturer for GPT‑4‑dommerkørsler og menneskelig A/B samt uafhængige, peer‑reviewede studier, der kvantificerer korrelationen mellem BLEU, ROUGE, BERTScore og menneskelig præference på tværs af opgaver.
Der mangler også håndfaste mitigation‑eksempler med målbar effekt, plus cases fra produktion, der har implementeret firelagsstakken og kan dele ROI, regressionsfrekvenser og tidsomkostninger. Endelig efterlyses konkrete metoder til at skabe headroom i eval‑sæt over tid og beslutningsprocesser for sikkerhedstærskler med de rigtige stakeholders til stede.
Kildestatus og transparens
Påstande om svag korrelation for BLEU, ROUGE og BERTScore er rapporteret af Towards AI. Der findes akademisk litteratur, der diskuterer variabel korrelation, men da specifikke referencer ikke er gennemgået her, markeres det som et område for opfølgende verificering, før der konkluderes bredt.
