I klassisk software ved alle, hvad der sker efter en kundefejl: genskab, skriv en test der fejler, ret, kør, behold testen. Fejlen kommer ikke lydløst tilbage. Med LLM- og agent-systemer fordamper fejl ofte som morgendis — og vender tilbage få sprints senere i ny form. Eval Flywheel importerer den gamle disciplin til en ujævn virkelighed: gør hver produktionstabbe til en regressionstest, der kører automatisk i CI.
Det er jordnært — og presserende. En VentureBeat-undersøgelse blandt 157 virksomheder beskriver et evalueringsgab: halvdelen har udsendt et agentfeature, der passerede interne tests men fejlede hos en kunde; kun 1 ud af 20 har fuld tillid til automatiske evals, samtidig med at omtrent to tredjedele er på vej mod at deploye ændringer på baggrund af automatiske evals alene. Kilden er VentureBeat Pulse Research; tallene er friske og genkendelige i praksis.
Den tekniske opskrift på Eval Flywheel er udfoldet af Rashmi på Towards AI. Strukturen ligner den klassiske loop, men med nye brikker: hurtig triage i produktion, destillér en minimal reproducerbar case, vælg en grader (exact match, field-diff, regelbaseret eller LLM-as-judge), føj casen til et eval-datasæt og kør det i CI, så kendte fejl ikke krydser grænsen igen.
Problemet i dag
Interne evals kører ofte i pæne rammer og på velopdragne data. Produktion er støj: skæve input, tidsgrænser, værktøjskonflikter og data, der flytter sig time for time. VentureBeat peger på, at 50 procent har oplevet et agentfeature fejle hos kunden efter grønne interne evals. Samme undersøgelse viser lav tillid til automatiske evals — 5 procent svarer “fuld tillid” — mens cirka to tredjedele vil lade dem styre deploys. Det er et tydeligt spænd.
Hvorfor holder de gamle mønstre ikke? Fordi LLM’er er ikke-deterministiske. Identiske kald kan give forskellige svar; små kontekstskift eller tool-ændringer kan vippe en agent af sporet; “rigtige” svar er sjældent eksakte strenge. Uden et varigt, fejlet test-artefakt sætter rettelser sig ikke som sikkerhed. Her hører Eval Flywheel hjemme.
Eval Flywheel i korte, konkrete trin
Opskriften er enkel på papiret, mere ujævn i praksis — men den virker:
Først triage: klassificér og prioriter hændelsen fra produktion. Er det faktuel fejl, brudt tool-kontrakt, eller latency-udfald, der fik agenten til at antage for meget? Tag stilling med det samme. Dernæst en minimal reproducerbar case. Ikke et skærmbillede, men et komplet spor: input, systemprompt, relevante værktøjsopkald, kontekstudsnit, tidsstempel, modelversion, temperatur og seed, samt evt. eksterne API-svar. Uden det kan casen ikke testes igen.
Vælg så en grader. Hvor målet er binært, rækker exact match eller field-diff. Hvor svaret er sprogligt, hjælper regelbaserede checks (fx “ingen opfundne kilder”) eller LLM-as-judge, der vurderer regeloverholdelse. Til sidst: føj casen til eval-datasættet og kør det i CI. Blokér ved regressioner — eller hæv minimum et rødt flag med krav om menneskelig accept. Rashmis gennemgang på Towards AI er tydelig og matcher det, mange MLOps-miljøer bevæger sig mod.
Hvad er en minimal reproducerbar case for en LLM
En MRC er mere end et input–output-par. Den skal fastholde nok kontekst til at bevare fejldynamikken over tid. Tre ting er afgørende: snapshot af eksterne afhængigheder (værktøjsresponse, caches, udklip af vector store), model- og promptversionering samt seed og samplingparametre. Små afvigelser kan skjule fejlen — eller skabe en ny. Tænk MRC som et lille terrarium af situationen. Uden det bliver eval-flywheelen hul.
Tre fejlklasser og hvorfor unit-tests ikke fanger dem
Konkurrence og staleness: Flere agenttråde eller samtidige tool-kald kan køre i utakt. Enhedstests på en enkelt funktion dækker ikke timing, backoff eller data, der blev forældet midt i en kæde. Her er en grader, der tjekker tidsorden og konsistens i feltværdier, stærkere end strengmatch. Field-diffs med toleranceregler virker ofte bedst.
Citation og grounding: Modellen svarer pænt men sætter forkert kildecitat på. En unit-test kan tjekke, at der er et link — ikke at linkets indhold faktisk underbygger svaret. En LLM-as-judge kan vurdere citationens dækning mod svarteksten, gerne suppleret af en simpel regel: kræv URL’er fra godkendte domæner. Ikke perfekt, men markant bedre end tomme “indeholder kilde”-checks.
Værktøjs- og kontraktfejl i svindel-/risikoflows: Et agentkald til et “fraud score”-værktøj kommer tilbage med et andet feltnavn end specifikationen lover (fx score_value vs. score). En klassisk enhedstest af biblioteket fanger det måske, men ikke altid samspillet mellem agent, parsing og værktøj. En robust grader validerer JSON-kontrakten og kritiske felters semantik. Her vinder regelbaserede kontrakt-checks typisk.
Hvad det kræver i praksis
CI/CD for modeller og prompts er første skridt: pipeline-jobs, der kan hæve/sænke modelversioner, bundte prompts som artefakter og køre eval-suiter ved hvert merge. Velkendte værktøjer rækker: GitHub Actions, GitLab CI, Argo — plus en modelregistry (MLflow, Vertex Model Registry eller intern). Data og eval-cases kan versioneres i DVC eller Git-LFS afhængigt af størrelse.
Derudover: automatisk sporopsamling. Ikke kun API-logs, men fulde traces: input, systemprompt, mellemtrin, tool-kald, kontekstudsnit, eksterne svar, temperatur, seed, latenstid. Uden spor ingen MRC. Sørg også for artefakthåndtering: gem judge-prompter, graders kode og versionsnoter, så grader-ændringer ikke mudrer historikken. Kør periodiske evals mod produktionens seneste inputdistribution for at fange drift — ikke kun ved merges.
Teknologistak og workflow, konkret
En lav-friktion opsætning: GitHub Actions til CI, DVC til eval-datasæt, MLflow til model- og promptversioner, Postgres eller object store til spor og artefakter, og et dashboard (Grafana, Metabase) til gradertrends. En nightly-job kører hele suiten; en light-suite kører ved hver PR. Start med “soft fail”-gating via labels og stram gradvist til blocking på kritiske cases.
Kompetencer: en MLOps-profil til versionering og pipelines, en produktnær ingeniør til graderlogik og domænechecks, samt en dataanalytiker til at holde øje med distributionsskift. Omkostningerne ligger i tid (konvertere incidents til MRC’er, vedligeholde graders) og compute til CI-kørsler. Eval-suiten bliver en fast budgetpost. Til gengæld falder MTTR for incidents, og gentagne fejl bliver sjældnere — præcis pointen.
Risici og begrænsninger
Eval-bloat er den klassiske fælde: hver incident bliver en test, og pludselig tager suiten timer og koster dyr inference. Modtræk: dedupliker, pensionér gamle cases, og sæt SLA på, hvor hurtigt en ny case vurderes. Prioritér efter impact og frekvens — ikke efter højeste decibel på Slack.
LLM-as-judge kan være svingende: dommen kan skifte med prompt, kontekst eller modelopdatering. Hvis den er nødvendig, så versionér judge-prompt, kalibrér mod kendte labels, og kør periodiske stikprøver med mennesker. Nondeterminisme er vilkår; brug seeds og tolerancer i graders, hvor det giver mening, i stedet for at låse til exact match og blive skuffet.
Forældede cases er den stille dræber: en vigtig case i april siger måske intet i august efter kildedata skifter. Indfør retirement-policy: hvis en case ikke længere matcher produktionens inputdistribution, arkivmærk den. Og pas på incitamenter: hvis teams kun måles på “grøn CI”, fristes man til at blødgøre graders. Det skaber falsk tryghed.
Menneske i loop og governance
Der er områder, hvor mennesker stadig skal på: juridiske afgørelser, kredit/økonomi, sikkerhedskritiske svar — samt sære hjørnesager, hvor forretningslogik ikke kan fanges rent i regler. Integrér eval-flywheelen med governance: klare politikker for, hvornår en sag kræver menneskelig signoff, og hvordan graders justeres uden at skrive virkeligheden ud.
Det flugter med VentureBeats observation: lav tillid til automatiske evals. Et pragmatisk greb er to lag: automatiser det robuste og gentagelige, og læg menneskelig gennemgang på sager med høj konsekvens eller lav LLM-judge-konfidens. Det koster tid nu og sparer kriser senere.
Prioriteringsguide, så man ikke drukner
Ikke alle fejl skal i suiten nu. Start med tre kategorier: høj kundepåvirkning, høj frekvens og “familier” af samme årsag. Resten i backlog. Vælg graders efter svageste led: kan en regel eller field-diff løse det, så gør det. Ellers LLM-judge — men kun med versionering og kalibrering.
Hvornår er nondeterminisme acceptabel? Når forretningsværdien ikke kræver identiske svar, og graders kan måle en tolerance (fx “mindst 2 af 3 felter korrekte” eller “ingen forbudte mønstre”). Hvornår kræves embargo eller menneskelig signoff? Ved juridiske/økonomiske risici eller nye, ukendte fejltyper. Brug en enkel tjekliste: impact-score, gentagelsesrisiko, gradermodning og tid til MRC.
KPI’er der giver mening
Fire nøgletal går igen: regressionsrate (antal tidligere lukkede bugs, der vender tilbage), MTTR for production incidents, eval-suite runtime/omkostning og andelen af sager med menneskelig gennemgang. De er målbare og kan forbedres. Sæt mål — og aftal loft over CI-runtime, så udviklingshastigheden ikke kvæles.
Hvem gør hvad i organisationen
Eval Flywheel flytter rollerne: ML-ingeniører ejer typisk graders og eval-datasæt. SRE sikrer pipeline-stabilitet, logning og artefakter. Produkt sætter politikker for, hvilke sager der bliver til tests, og hvornår røde tests må forbigås. Compliance definerer bånd i fx finans og sundhed. Utydeligt ejerskab skaber huller — der, hvor regressionsfejl trives.
Justér incitamenter: beløn fald i regressionsrate og MTTR — ikke kun antal lukkede tickets. Gør eval-suiten synlig. Når alle kan se, hvad der blokerer, falder fristelsen til at “nudge” graders i blød retning. VentureBeats eval-gap handler i høj grad om styring, ikke kun teknik.
Næste skridt, helt lavpraktisk
I morgen kan et team gøre tre ting: slå sporopsamling til (gem input, prompts, værktøjsopkald og seeds), udpeg de 10 mest smertefulde incidents fra de seneste to måneder og lav MRC’er, og tilføj dem til en lille eval-suite i CI som advarsler. Det er discover, codify, enforce i miniature.
Næste fase: vælg grader-arkitektur, definér gatingregler for de dyreste fejlkategorier, og hold ugentlige gennemgange, hvor cases pensioneres, samles eller skærpes. Sidste fase: ryk fra soft til hard gates på kritiske områder, mål KPI’erne og hold governance levende med faste signoff-regler.
Kilder og metodik
Arbejdsgangen er beskrevet af Rashmi på Towards AI, inkl. gradertyper og fejlklasser som concurrency/staleness, citation-grounding og værktøjskontrakter. De organisatoriske tal stammer fra VentureBeat Pulse Research blandt 157 virksomheder og dokumenterer evalueringsgabet: mere autonomi, mindre tillid, flere produktionsoverraskelser. Faglige MLOps-manualer underbygger behovet for CI/CD for modeller, driftsovervågning og dataversionering.
Usikkerheder skal nævnes. Især LLM-as-judge: der mangler åbne, langsigtede benchmarkserier for stabiliteten i daglig drift. Der savnes også offentlige end-to-end-cases med før/efter på regressionsrate og MTTR. Og omkostningsprofilen for lange eval-suiter? Den varierer kraftigt med stack og frekvens; detailtal er fortsat sparsomme.
Den korte slutning
Eval Flywheel er ikke en mirakelkur — men en effektiv disciplin, der flytter AI fra “håb” til “kontrol”. Gør hver produktionstabbe til en test, der ikke forsvinder. Sørg for spor, graders og versioner, og behold mennesket tæt på, hvor konsekvensen er høj. Alternativet er at genopleve den samme fejl igen og igen. Forskellen mærkes først, når hjulet ruller i praksis.
