Sådan bygger du et scenariebaseret evalueringssæt til et AI-system

Et brugbart evalueringssæt begynder ikke med en bunke velformulerede prompts, men med én afgrænset arbejdsgang og den beslutning, resultaterne skal understøtte. Forestil dig en intern indkøbsassistent, der modtager en tilsyneladende normal anmodning, et modstridende leverandørnummer, et utilgængeligt politiksvar og et tilbud med skjulte instruktioner til assistenten. En gennemsnitlig kvalitetsscore fortæller ikke, om systemet håndterer denne kombination forsvarligt. Det kræver reproducerbare scenarier, foruddefinerede udsnit og særskilte gates for handlinger, som systemet aldrig må udføre.

Hvad skal et scenariebaseret evalueringssæt dække?

Et scenariebaseret evalueringssæt bør kombinere den almindelige arbejdsgang med vigtige randtilfælde, kendte fejl og udtrykkeligt forbudt adfærd. Begynd med én systemversion, tilladte brugerroller og input, tilgængelig viden og værktøjer samt den efterfølgende beslutning. Kortlæg derefter opgavefamilier og relevante variationer ud fra autoriserede arbejdsdata, supportsager, brugerundersøgelser, hændelser og gennemgange med domæneeksperter. Hvis logningen er mangelfuld eller systemet endnu ikke er lanceret, skal usikkerheden stå synligt i stedet for at blive omsat til kunstig præcision.

Almindelige cases bør afspejle den observerede fordeling, men hyppighed må ikke alene styre sættet. Sjældne forhold kan have store konsekvenser, og et forbud bliver ikke mindre relevant, fordi det sjældent udfordres. For indkøbsassistenten kan dækningen omfatte komplette anmodninger, manglende bilag, modstridende beløb, utilgængelig politik, forsøg på at springe godkendelsen over og instruktioner i uploadede dokumenter. Reglerne er illustrative og skal erstattes af organisationens faktiske arbejdsgang, tilladelser og risikobeslutninger.

Fastlæg de udsnit, der skal rapporteres, og de gates, der kan blokere en frigivelse, før systemets svar genereres eller undersøges. Ellers kan et flot resultat friste teamet til efterfølgende at fremhæve de mål, kandidaten allerede klarer. Rapporter eksempelvis efter opgavefamilie, dækningsfamilie, brugerrolle, konsekvens og gate, når disse dimensioner faktisk er relevante. Den firedelte model er en redaktionel syntese af flere vejledninger, ikke en standard eller en formel for lige mange cases i hver gruppe.

Hvordan skal hvert evalueringsscenarie registreres?

Hvert scenarie skal registreres, så en anden evaluator kan genskabe starttilstanden, se hvilke udfald der er acceptable, og opdage forbudte udfald. Giv casen et stabilt id, en ejer, versionshistorik, dæknings- og opgavefamilie, udsnit, konsekvens, provenienskategori, autorisationsnotat og planlagt placering i udviklings- eller release-sættet. Proveniens er ikke blot et link: posten skal også vise, om materialet må bruges, hvordan følsomme oplysninger er minimeret, og hvilke usikkerheder der følger med kilden.

• Opsætning: aktør, mål, indledende workflowtilstand, input, filer, relevant historik og miljøforhold.
• Råderum: autoriseret viden, værktøjer, tilladelser, kendte værktøjsresultater samt systemets instruktioner og begrænsninger.
• Forventninger: nødvendige fakta eller tilstandsændringer, acceptable alternativer og krav om afklaring, afståelse, afvisning eller eskalering.
• Forbud: output, afsløringer, værktøjskald, handlinger og tilstandsændringer, som skal registreres adskilt fra almindelig kvalitet.
• Drift: bedømmertype, rubrik, gates, eventuel referenceløsning, forsøgsregel, reviewerkompetence, afgørelsesvej og alle relevante systemversioner.

For en åben opgave bør posten beskrive nødvendige fakta og acceptable variationer frem for én ideel formulering. En fungerende referenceløsning kan vise, at opgaven faktisk kan løses, og afsløre en defekt kontrol, men den må ikke afvise andre gyldige veje. Hvis systemet er ikke-deterministisk eller udfører flere trin, skal antal forsøg og sammenlægningsregel besluttes, før output ses. Registrer model, prompt, retrieval-korpus, værktøjer, politik, tilladelser og testharness; ellers kan resultatet ikke knyttes entydigt til den løsning, der blev afprøvet.

En god evalueringscase stiller ikke blot et svært spørgsmål; den genskaber et afgrænset stykke arbejde og gør succes, acceptable variationer og forbud synlige.

Hvordan bedømmes et scenarie uden at belønne forkert adfærd?

Vælg den snævreste bedømmelsesmetode, der gyldigt kan skelne succes fra fejl i den konkrete case. Brug deterministiske kontroller til objektive svar, skemaer, beregninger, værktøjsargumenter, registrerede tilstande og klart forbudte handlinger. Kontrollér samtidig, at testen er komplet, og at opgaven kan løses; en præcis kontrol kan stadig belønne en genvej eller afvise et gyldigt resultat. Når flere formuleringer eller veje er acceptable, kan afgrænsede referencefakta eller en kendt løsning bruges som støtte uden at blive facitordlyd.

• Deterministisk kontrol til objektivt verificerbare svar, tilstande, værktøjskald og forbud.
• Referencefakta eller referenceløsning, når det krævede evidensgrundlag er afgrænset, men vejen kan variere.
• Rubrik med observerbare holdepunkter, når kvalitet som nytte, fuldstændighed eller forklaring reelt er åben.
• Kvalificeret menneskelig vurdering, når gyldig bedømmelse kræver domænefortolkning eller autoriseret fagligt ansvar.

En modelbaseret bedømmer af åbne svar bør have særskilte, observerbare dimensioner og kalibreres mod kvalificerede menneskers vurderinger i samme kontekst. Overensstemmelse på synlige udviklingscases er ikke i sig selv bevis for gyldighed; OpenAI oplyser eksempelvis, at den automatiske GDPval-bedømmer ikke var pålidelig nok til at erstatte erfarne fagbedømmere. Gennemgå både karakter, svar og eventuelle spor, når en fejl skal diagnosticeres, så et problem i casen, miljøet eller bedømmeren ikke forveksles med en systemfejl.

Delpoint kan synliggøre, hvilke meningsfulde opgavedele systemet klarer, men et udtrykkeligt forbud må ikke forsvinde i gennemsnittet. Hvis produkt- og risikoejerne på forhånd har bestemt, at en fortrolig afsløring eller uautoriseret handling blokerer frigivelse, skal den behandles som en ikke-kompenserbar gate. Rubrikversion, gate-logik, udsnit, forsøgsaggregering og beslutningsregel skal låses før sammenligningen. Senere ændringer er tilladte, men de skaber en ny evalueringsversion og må ikke omskrive det gamle resultat.

Hvordan kan bedømmere anvende kriterierne ensartet?

Bedømmere kan arbejde mere ensartet, når de får samme kontekst, observerbare holdepunkter og en tydelig vej for tvivl og uenighed. Før et output vises, skal vejledningen angive arbejdsgangens formål, aktøren, den tilgængelige evidens, tilladt adfærd, produktgrænsen og rubrikversionen. Beskriv hvert bedømmelsespunkt gennem synlige egenskaber frem for løse ord som “god” eller “professionel”, og medtag positive, negative og grænsenære eksempler. En mangelfuld case skal kunne mærkes som utilstrækkelig evidens eller kan ikke bedømmes.

1. Kør kalibreringscases, før den egentlige gennemgang begynder.
2. Blind systemidentitet og rækkefølge, hvor en sammenlignende vurdering gør det praktisk relevant.
3. Indsaml uafhængige karakterer og begrundelser, før bedømmerne taler sammen.
4. Undersøg uenighed som mulig fejl i case, tærskel, kontekst eller en uafklaret produktbeslutning.
5. Lad en navngiven ejer afgøre egentlige konflikter, og gem etiketter, begrundelser, versioner og udfald.

Kalibrering bør gentages, når opgaveblandingen, politikken, rubrikken eller bedømmergruppen ændres væsentligt. Målet er ikke at presse alle forskelle væk: flere svar kan være legitimt acceptable, og en uenighed kan afsløre, at organisationen endnu ikke har truffet den nødvendige produktbeslutning. GDPval viser, at ekspertgennemgang, blindet sammenligning og detaljerede rubrikker kan kombineres, men det etablerer ikke én universel procedure. Den konkrete reviewerproces skal tilpasses konsekvens, opgavetype og den kompetence, som gyldig bedømmelse kræver.

Hvordan forbliver evalueringssættet nyttigt under udvikling og frigivelse?

Evalueringssættet forbliver nyttigt ved at adskille synlige udviklingscases fra beskyttet release-evidens og registrere enhver eksponering. Udviklingssættet må bruges gentagne gange til at forbedre prompts, retrieval, værktøjer, politik og workflow, men dets score er udviklingsevidens, fordi teamet har optimeret mod casene. Tildel derfor split, når en case optages i registret og før rutinemæssig kørsel eller outputinspektion. Det beskyttede sæt bruges sparsomt til endelige sammenligninger eller frigivelsesbeslutninger.

• Kontrollér eksakte og nære dubletter, fælles kilderegistreringer, parafraser og søskende fra samme scenarieskabelon.
• Spor adgang til caseindhold, reference­svar, rubrikker og resultater, ikke kun filens formelle placering.
• Flyt en beskyttet case til udvikling eller regression, hvis den materielt har påvirket diagnose eller ændring.
• Erstat eksponerede release-cases med versionsstyrede, uafhængigt fremstillede cases fra samme relevante fejlklasse.
• Bevar ejerskab, proveniens, autorisation, split, eksponering, reviewhistorik, ændringsgrund og pensionsgrund i registret.

Gentagen brug af et testsæt til at styre ændringer kan skabe implicit overtilpasning, og både validerings- og testsæt kan slides. Beskyttelse kræver derfor mere end et mappenavn. Når en release-case, dens svar, rubrik eller resultat har formet en rettelse, er casen ikke længere uafhængig evidens for netop den rettelse. En kendt fejl, der allerede har støttet diagnosen, hører hjemme i udviklings- eller regressionssættet. Samme fejlklasse kan stadig dækkes i release-sættet gennem en ny, ikke-duplikeret case, der ikke har styret ændringen.

Vedligehold registret som en versionsstyret beslutningslog. Tilføj verificerede fejl fra autoriserede kilder efter nødvendig minimering, og revurdér dækningen, når arbejdsgang, brugere, politik, vidensgrundlag, model, prompt, værktøjer, tilladelser eller driftsmiljø ændres væsentligt. Undersøg også forældede referencer, uklare opgaver, fejlagtige etiketter, umulige sluttilstande og bedømmere, der afviser gyldige alternativer. Der findes ingen universel case-mængde, splitprocent eller opdateringsfrekvens; sammensætningen afhænger af beslutningen, variationen, konsekvenserne og det autoriserede evidensgrundlag.

Et offline resultat er beslutningsevidens, ikke et certifikat for forretningsværdi, sikkerhed, fairness, compliance eller produktionsparathed. Produkt- og risikoejere bør fastlægge konsekvensfølsomme gates og anvendelsen af resultaterne på forhånd, mens domæneeksperter validerer realisme og acceptable udfald. Når materialet berører jura, økonomi, ansættelse, sikkerhed, privatliv eller andre regulerede områder, skal relevante kvalificerede og autoriserede funktioner beholde beslutningsansvaret. Kombinér derfor offlineevaluering med overvågning, brugerundersøgelser, hændelsesgennemgang og anden evidens, der passer til systemets faktiske anvendelse.