Slik bygger du et scenariobasert evalueringssett for et AI-system

Et godt scenariobasert evalueringssett begynner med én avgrenset arbeidsflyt, ikke med en mappe tilfeldige spørsmål. Tenk på en intern assistent for innkjøpsforespørsler: En mappe kan inneholde en troverdig bestilling, motstridende leverandørnumre, en utilgjengelig policy og et tilbud med instruksjoner rettet mot assistenten. Glansede eksempelsvar sier lite om denne kombinasjonen. Teamet må derfor definere arbeidet, brukerne, kunnskapen, verktøyene, grensene og beslutningen evalueringen skal støtte. Deretter trengs reproduserbare saker, gyldig gradering, forhåndsbestemte porter og et tydelig skille mellom utvikling og lansering.

Hva bør et scenariobasert evalueringssett dekke?

Evalueringssettet bør dekke den faktiske arbeidsmiksen og samtidig gi bevisst plass til sjeldne, men viktige grenser, kjente feil og forbudte utfall. Start med én systemversjon og én arbeidsflyt: hvem som kan bruke løsningen, hvilke inndata den mottar, hva den får slå opp eller gjøre, og hvilken beslutning resultatet skal informere. NIST anbefaler klart definerte, realistiske testsett som representerer forventede bruksforhold, mens OpenAI peker på oppgavespesifikke evalueringer og flere mulige datakilder. Tilgjengelige logger er likevel verken automatisk representative, korrekt merkede eller lovlige å gjenbruke.

Lag så et dekningskart fra autoriserte arbeidsdata, supportsaker, brukerinnsikt, hendelser og gjennomganger med domeneeksperter. Marker usikkerhet dersom loggingen er mangelfull eller løsningen ennå ikke har trafikk. Kartet nedenfor er en redaksjonell syntese, ikke en standardisert taksonomi. Vanlig arbeid kan vektes etter en troverdig observert miks, men frekvens alene må ikke avgjøre om konsekvensfulle avvik kommer med. Definer rapporteringsutsnitt, forbudsporter og ønsket lanseringsbeslutning før dere ser systemets svar; ellers kan resultatene påvirke hvilke kriterier teamet velger å bry seg om.

For innkjøpsassistenten kan vanlig arbeid være en komplett forespørsel med samsvarende felter og tilgjengelig policy. Grensene kan omfatte et manglende vedlegg, sprikende beløp eller leverandøridentifikatorer, utilstrekkelig dokumentasjon og et mislykket policyoppslag. Forbudte scenarioer kan teste om assistenten nekter å godkjenne kjøpet, omgå en menneskelig godkjenning, dikte opp en regel eller følge instruksjoner skjult i et tilbud. Reglene er illustrerende og organisasjonsspesifikke; ansvarlige eiere må definere de virkelige grensene.

Hvordan bør hvert evalueringsscenario registreres?

Hvert scenario bør registreres som en saksjournal som lar en annen evaluator gjenskape utgangspunktet og avgjøre hva som er gyldig, alternativt eller forbudt. Gi saken stabil ID, eier, status, versjonshistorikk, dekningsfamilie, oppgavefamilie, utsnitt, konsekvens, opphavskategori, autorisasjon og planlagt splitt. Beskriv aktøren og målet, system- og arbeidsflyttilstanden, forespørselen, filene, relevant historikk, tillatt kunnskap, tillatelser, verktøyresultater og miljøforhold. Realistiske profesjonelle evalueringer kan ta utgangspunkt i arbeidsprodukter, men sensitive kilder må minimeres og håndteres med riktig tilgang.

• Krevde fakta, tilstandsendringer eller neste steg.
• Akseptable alternative formuleringer og handlingsveier.
• Situasjoner som krever avklaring, avståelse, avvisning eller eskalering.
• Forbudte svar, utleveringer, verktøykall, handlinger og tilstandsendringer.
• Graderertype, rubrikk, porter, referansegrunnlag og eventuell prøvesammenslåing.

En kjent fungerende referanseløsning kan vise at en avgrenset oppgave faktisk lar seg løse og at gradereren reagerer fornuftig. Den må ikke bli et fasitsvar som avviser andre gyldige ordvalg eller veier. For systemer med variasjon mellom kjøringer må teamet på forhånd angi når flere forsøk er nødvendige og hvordan de skal sammenfattes, uten å anta et universelt antall. Registrer også granskerkompetanse, avgjørelsesvei og versjonene av modell, ledetekst, kunnskapsgrunnlag, verktøy, policy, tillatelser og testoppsett. Hele journalformatet er en tilpasningsbar redaksjonell syntese.

En nyttig evalueringssak gjenskaper avgrenset arbeid og gjør suksess, gyldig variasjon og forbudt atferd synlig.

Hvordan scorer dere uten å belønne feil atferd?

Velg den smaleste graderingsmetoden som faktisk kan skille et gyldig resultat fra en feil, og hold forbudte handlinger utenfor poeng som kan kompenseres. Deterministiske kontroller passer for objektive svar, skjemaer, beregninger, verktøyargumenter, posttilstander og forbudte kall. Kontrollen må likevel gjennomgås: En presis test kan være ufullstendig, eller saken kan være uløselig. Når nødvendige fakta eller sluttilstanden er avgrenset, kan et referansegrunnlag fange kravene uten å kreve én bestemt formulering. Resultatbasert gradering er ofte mindre skjør enn å kreve en tilfeldig kjørebane.

• Bruk deterministisk kontroll når utfallet er objektivt etterprøvbart.
• Bruk referansefakta når flere svar eller veier kan være gyldige.
• Bruk separate, observerbare rubrikkdimensjoner for åpen kvalitet som nytte, fullstendighet og forankring.
• Bruk kvalifisert menneskelig skjønn når domeneinnholdet eller konsekvensen ikke kan avgjøres gyldig automatisk.

Modellbaserte graderere for åpne svar trenger strukturerte kriterier og kalibrering mot kvalifiserte menneskelige vurderinger i samme kontekst. OpenAI opplyser eksempelvis at den automatiserte gradereren i GDPval ikke var pålitelig nok til å erstatte erfarne yrkesgranskere. Delpoeng kan synliggjøre hvilke meningsfulle komponenter systemet mestret, men en forbudt utlevering eller uautorisert handling bør stoppe saken uansett språklig kvalitet. Dette er en konsekvenssensitiv redaksjonell anbefaling: Produkt- og risikoeiere må definere portene, rubrikkversjonen, utsnittene, sammenslåingen og beslutningsregelen før kandidatsvar sammenlignes.

Hvordan kan granskere bruke kriteriene konsekvent?

Granskere arbeider mer konsekvent når de får samme kontekst, observerbare ankere og en tydelig vei for saker som ikke kan bedømmes. Før de ser et svar, bør veiledningen oppgi arbeidsflytens formål, aktøren, tilgjengelig evidens, tillatt atferd, produktgrensen og rubrikkversjonen. Beskriv hvert poengnivå gjennom forhold som faktisk kan observeres, med positive, negative og grensetilfeller. Legg inn valget «kan ikke vurderes» når konteksten mangler eller saken er defekt. NIST beskriver hvordan oppgavekontekst, løsningsinformasjon og konkrete eksempler kan støtte påliteligheten i gransking.

1. Kjør kalibreringssaker før ordinær gransking og etter vesentlige endringer i rubrikk, policy, oppgavemiks eller granskergruppe.
2. Skjul systemidentitet og varier svarrekkefølge der dette er praktisk ved sammenligninger.
3. Samle uavhengige poeng og begrunnelser før diskusjon.
4. Send reell uenighet til en navngitt avgjørelseseier, og bevar vurderingene med rubrikkversjonen.

Uenighet er diagnostisk informasjon, ikke bare støy. Den kan avdekke en tvetydig terskel, manglende kontekst, en defekt graderer, et utilgjengelig mål, flere legitimt akseptable svar eller en produktbeslutning som aldri er tatt. Ikke press frem konsensus i de to siste tilfellene. GDPval viser at flertrinns ekspertgjennomgang, blindet sammenligning og detaljerte rubrikker kan brukes i profesjonelle oppgaver, men demonstrasjonen fastsetter ingen universell granskerprotokoll. Ved å lagre etiketter, begrunnelser og avgjørelser kan teamet senere etterprøve både mennesker og automatiserte graderere.

Hvordan forblir evalueringssettet nyttig gjennom utvikling og lansering?

Evalueringssettet forblir nyttig når synlige utviklingssaker skilles fra en beskyttet lanseringstest, og begge styres i et versjonert register. Utviklingssettet kan kjøres ofte mens teamet forbedrer ledetekster, gjenfinning, verktøy, policy og arbeidsflyt. Resultatene er utviklingsevidens fordi teamet har sett sakene og optimalisert mot dem. Google beskriver den tilsvarende faren for implisitt overtilpasning når et testsett gjentatte ganger styrer endringer. Tildel derfor splitt når saken registreres, før rutinemessige kjøringer eller svarinspeksjon, og bruk den beskyttede testen sparsomt til sluttvurderinger.

• Søk etter eksakte og nære duplikater, delte kildeposter, parafraser og søskenscenarioer på tvers av splittene.
• Spor tilgang til saker, referansesvar, rubrikker og resultater.
• Flytt en beskyttet sak til utvikling eller regresjon når den materielt har påvirket en endring.
• Erstatt eksponerte saker med uavhengig opprettede, versjonerte saker som ikke har styrt løsningen.

En bekreftet feil som allerede har vært brukt til diagnose eller retting, hører hjemme i utviklings- eller regresjonsevidensen. Den beskyttede testen kan dekke samme feilklasse, men bare gjennom en ikke-duplisert sak som ikke har veiledet endringen. Registeret bør dokumentere eier, opphav, autorisasjon, splitt, eksponering, versjoner, vurderingshistorikk, endringsgrunn og eventuell utfasing. Utvid settet med verifiserte produksjons-, support-, domene-, syntetiske eller menneskekuraterte saker når bruken gir grunnlag for det. Kontroller samtidig sensitivitet og forventet atferd; ingen kildetype er automatisk pålitelig.

Revurder dekning, metoder og måltall når arbeidsflyten, brukergruppen, policyen, kunnskapen, modellen, ledetekstene, verktøyene, tillatelsene eller driftsmiljøet endres vesentlig. Rapporter etter oppgavefamilie, dekningsfamilie, relevant utsnitt, konsekvens og port, ikke bare som ett gjennomsnitt. Et bestått offline-sett er beslutningsevidens, ikke et sertifikat for forretningsverdi, sikkerhet, rettferdighet, etterlevelse eller produksjonsklarhet. Kombiner det med overvåking, brukerinnsikt, hendelsesgjennomgang og annen relevant dokumentasjon. Regulerte juridiske, medisinske, finansielle, arbeidsrettslige, sikkerhetsmessige og personvernrelaterte vurderinger må ligge hos kvalifiserte og autoriserte personer.