Bliv en del af mit community / gratis nyhedsbrev — tilmeld dig her
OpenAI-evals gør accepttest til en del af releases af AI-workflows
Et par gennemarbejdede demoer kan være nok til at få godkendt et internt pilotprojekt med en AI-workflow. Men de bør ikke være nok til at sætte den i drift. Et system, der opsummerer supportsager, udarbejder svar, fordeler henvendelser eller klargør registreringer, kan virke pålideligt i en kontrolleret test og alligevel fejle, når prompten ændres, modellen opgraderes, et værktøj returnerer uoverskuelige data, eller en bruger formulerer sig uventet. Når workflowet først indgår i kundeservice, interne processer eller beslutningsstøtte, må kravene skærpes.
Det er her, OpenAI’s aktuelle vejledning bliver nyttig. På tværs af materialet om evals, graders, red teaming og forbedringsloops er budskabet entydigt: Pålidelige AI-applikationer kræver struktureret test, og testen skal gennemføres, før ændringer rulles bredere ud. OpenAI beskriver evals som strukturerede test, der måler en models performance, og fremhæver dem som afgørende for pålidelige applikationer – især når man afprøver nye modeller eller håndterer opgraderinger. Vejledningen om evaluering understreger også en pointe, som mange teams opdager sent: Generative systemer varierer i deres output, så deterministiske softwaretest alene dækker ikke risikoen.
Sådan ser accepttest ud for AI-workflows
I traditionel softwareudvikling skal accepttest afgøre, om et system opfylder betingelserne for release. Det samme princip gælder her, men testgrundlaget er anderledes. OpenAI’s guide til evals beskriver loopet enkelt: Definér opgaven, kør evalueringen på testinput, gennemgå resultaterne, og gentag processen. Vejledningen om best practices føjer den nødvendige driftsdisciplin til loopet: Evaluér tidligt, gør evalueringerne opgavespecifikke, log alt, automatisér scoring, hvor det er muligt, og inddrag fortsat menneskelig feedback, så bedømmelsen afspejler den forretningsmæssige virkelighed.
| Lag i workflowet | Hvad kan gå galt? | Acceptkontrol | Spørgsmål før release |
|---|---|---|---|
| Instruktioner og outputformat | Prompt drift, manglende obligatoriske afsnit og output, der bryder reglerne | Opgavespecifikke evals med kontrol af metrics eller bestået/ikke bestået-bedømmelse | Giver et standardinput stadig et acceptabelt resultat? |
| Strukturerede output og brug af værktøjer | Forkerte felter, fejlagtige klassifikationer og ukorrekte værktøjsargumenter | Strengkontrol, tekstlighed eller multigraders med vægtet scoring | Er workflowet præcist nok til, at man kan stole på det i det daglige arbejde? |
| Overdragelser og orkestrering | Fejlagtig routing, utilstrækkelig eskalering og tab af kontekst mellem trin | Regressionsevals baseret på virkelige traces og workflowspecifikke scorecards | Holder processen kursen, når kompleksiteten stiger? |
| Misbrug og fjendtlige input | Modstridende prompts, fejlformaterede anmodninger og adversarial formuleringer | Red-team-cases, der køres sammen med almindelige evals | Kan workflowet fejle på en sikker måde, før det når ud til brugerne i produktion? |
| Løbende forbedringer | Ændringer af prompts, modeller, værktøjer eller routing, som skaber regressioner | Traces, feedback og evals, der kan køres igen, bag en valideringsgate | Forbedrede ændringen reelt systemet, eller flyttede den blot problemet? |
Tag udgangspunkt i fejlscenarier – ikke begejstring for modellen
Den første opgave er at definere, hvad en fejl konkret er i det workflow, I vil sætte i drift. OpenAI’s vejledning tilskynder gentagne gange teams til at bruge opgavespecifikke evals frem for at tænke i generelle benchmarks. For et internt workflow betyder det, at man tester de beslutninger, systemet skal træffe korrekt i produktion: klassificere rigtigt, kalde det korrekte værktøj, bevare obligatoriske felter, eskalere ved lav sikkerhed og holde sig inden for det forventede svarformat. Et pilotprojekt bliver til et egentligt projekt, når disse forventninger skrives ned som testcases i stedet for at forblive en fælles mavefornemmelse i teamet.
Det bliver endnu vigtigere, når værktøjer eller flere agenter indgår. OpenAI’s guide til best practices påpeger, at værktøjer og overdragelser mellem flere agenter skaber nye muligheder for nondeterminisme. Den advarer også om, at evals – ikke en standardbeslutning – bør afgøre, om man vælger en multi-agent-arkitektur. Hvis et workflow kun fungerer, så længe ingen ændrer prompten, værktøjsskemaet eller modellen, er det ikke klar til en bredere udrulning.
Opbyg et datasæt, der ligner det virkelige arbejde
OpenAI anbefaler, at man logger under udviklingen, så teamet kan udlede nyttige eval-cases fra virkelige traces. OpenAI anbefaler også testdata, der dækker typiske cases, edge cases og adversarial cases, med deltagelse af menneskelige fageksperter som labellers. I en forretningsmæssig sammenhæng betyder det som regel, at man indsamler eksempler fra det normale, daglige arbejde og derefter bevidst tilføjer de situationer, der skaber driftsmæssige problemer: tvetydige henvendelser, manglende kontekst, modstridende instruktioner, støjfyldt historik og variationer i formateringen.
Den samme vejledning fremhæver udtrykkeligt flersprogede input, forskellige formater, lang kontekst, modstridende prompts, jailbreak-forsøg og komplekse interaktioner med værktøjer. Formålet med et accepttestprojekt er ikke at bevise, at en model generelt er intelligent. Det skal vise, at et workflow opfører sig acceptabelt i de situationer, teamet sandsynligvis vil møde – især dem, der med størst sandsynlighed kan føre til dyre fejl.
Brug graders til at gøre QA reproducerbar
OpenAI’s vejledning om graders er værdifuld, fordi den gør ”det ser fint ud for mig” til noget mere reproducerbart. Dokumentationen beskriver referencebaseret bedømmelse, der kan give scorer fra 0 til 1, herunder delvis godkendelse, når en binær bedømmelse som bestået eller ikke bestået er for grov. Den gennemgår også flere typer graders, herunder kontrol af eksakte strenge, bedømmelse af tekstlighed, scoremodelbedømmelse og afvikling af Python-kode. I praksis gør det teamet i stand til at skelne mellem det, der skal være helt korrekt, og det, der kan tåle en vis tilnærmelse.
Den skelnen er vigtig i driften. OpenAI’s multigrader-eksempel viser et praktisk mønster: Nogle felter må gerne være omtrentlige, mens andre ikke må, og den samlede score kan vægte kravene forskelligt. Man kan acceptere mindre variationer i formuleringen af et resumé, men samtidig kræve et eksakt konto-id, en routingetiket eller en statuskode. OpenAI’s designtips understøtter den samme disciplin: Start i det små, foretræk scorer, der synliggør gradvise forbedringer, beskyt mod reward hacking, undgå skæve datasæt, og brug LLM-as-a-judge, når kodebaserede kontroller ikke er tilstrækkelige.
Vejledningen om best practices tilføjer en vigtig sikkerhedsforanstaltning. Menneskelig evaluering giver den højeste kvalitet, men er langsom og dyr. Modelbaseret bedømmelse er billigere og nemmere at skalere, så OpenAI anbefaler, at man validerer, om den automatiserede bedømmelse stemmer overens med menneskelige labels, før man lægger stor vægt på den. I accepttest bør graders understøtte den menneskelige vurdering – ikke ukritisk erstatte den.
Red teaming finder de fejl, som almindelig QA overser
Almindelige evals tester, om et system opfører sig som tilsigtet. Red teaming undersøger, hvad der sker, når mennesker, prompts eller omstændigheder skubber det væk fra den tilsigtede kurs. OpenAI definerer red teaming som brugen af adversarial testcases til at afdække usikker, ubeskyttet eller regelstridig adfærd før deployment og betragter red teaming som et supplement til evals – ikke en erstatning.
Det er lige så relevant for intern automatisering som for offentligt tilgængelig AI. Et workflow, der udarbejder beskeder, foretager opslag i systemer eller fordeler handlinger, kan stadig skabe risici som følge af modstridende prompts, adversarial formuleringer, fejlformaterede input eller forsøg på at få workflowet til at ignorere sine instruktioner. Hvis planen for udrulning kun omfatter acceptkontroller af happy path, måler teamet performance – ikke robusthed.
Luk loopet, før I skalerer udrulningen
OpenAI’s cookbook om forbedringsloops adresserer det driftsmæssige hul, som mange pilotprojekter stadig har. Forløbet er enkelt: Indsaml virkelige traces, tilføj feedback fra mennesker og modeller, omdan feedbacken til evals, der kan køres igen, placér en valideringsgate foran den aktuelle adfærd, og brug den samlede dokumentation til at styre næste runde af ændringer i den omgivende harness. Notebooken definerer denne harness bredt, så den omfatter instruktioner, værktøjer, routing, outputkrav og valideringskontroller.
Det er forskellen på et enkeltstående pilotprojekt og et workflow, der kan vedligeholdes. Accepttest er ikke en ceremoni før lanceringen. Det er et letvægtsloop til regressionstest omkring enhver væsentlig ændring. I praksis vil et fornuftigt forløb her være forholdsvis afgrænset: Greg vil kortlægge workflowets sandsynlige fejlscenarier, opbygge et kompakt eval-datasæt, tilføje grader-kontroller og red-team-probes samt etablere en regressionsgate omkring ændringer af prompts, modeller og integrationer, før udrulningen udvides. Målet er ikke proces for processens egen skyld. Det er dokumentation. Når en ændring foreslås, skal I vide, om den forbedrede workflowet, flyttede risikoen et andet sted hen eller ødelagde noget, I er afhængige af.
Hvis et AI-workflow er vigtigt nok til at påvirke service, drift eller interne beslutninger, er det vigtigt nok til at have accepttest. OpenAI’s egen vejledning gør det til et rimeligt udgangspunkt – ikke et avanceret ekstraelement.
Har I brug for hjælp til denne type opgave?
Drøft en eval- og regressions-harness til jeres AI-workflow – kontakt Greg.
Kilder
Sidst ændret
2026-08-24