Bygg en scenariobaserad utvärderingsmängd för ett AI-system

En användbar utvärderingsmängd börjar med ett avgränsat arbetsflöde, inte med en samling välformulerade frågor. Tänk på en inköpsassistent som får en rimlig beställningsbegäran, motstridiga leverantörs-id:n, ett otillgängligt policysvar och en uppladdad offert med instruktioner riktade till assistenten. Ett högt genomsnitt från enkla testpromptar säger då föga om huruvida systemet hittar konflikten, avstår från att gissa och lämnar ärendet till rätt person. Releaseunderlaget måste därför återskapa arbetets normalläge, viktiga gränser, tidigare fel och uttryckligen förbjudna handlingar.

Vad ska en scenariobaserad utvärderingsmängd täcka?

Den ska täcka ett bestämt arbetsflöde genom en karta över representativt arbete, viktiga gränsfall, kända fel och förbjudna beteenden. Ange först vilken systemversion som prövas, vilka aktörer och indata som är tillåtna, vilken kunskap och vilka verktyg systemet får använda samt vilket beslut utvärderingen ska stödja. Kartan är en anpassningsbar redaktionell syntes, inte en standardiserad taxonomi. Den hindrar ändå en vanlig sammanblandning: frekvens beskriver vardagsarbetet, medan konsekvens avgör vilka ovanliga fall som också måste finnas med.

Bygg vardagsdelen från godkända arbetsunderlag, supportärenden, användarstudier och genomgångar med domänexperter. Driftloggar kan bidra, men är inte automatiskt kompletta, representativa, korrekt märkta eller tillåtna att återanvända. Saknas tillförlitlig driftdata inför lansering, märk fördelningen som en hypotes i stället för att låtsas att procentsatserna är kända. Komplettera sedan med variationer som faktiskt kan ändra utfallet: oklar avsikt, saknade dokument, motstridiga uppgifter, behörighetsgränser, otillgängliga verktyg eller otillräckligt beslutsunderlag.

För inköpsassistenten kan normalläget vara en komplett begäran med samstämmiga fält och åtkomlig policy. Riktade fall kan i stället innehålla ett saknat dokument, olika belopp eller leverantörs-id:n, otillräckligt underlag, en begäran om att kringgå godkännandet, instruktioner gömda i en offert eller ett motsägelsefullt sökresultat. Reglerna är illustrativa och måste ersättas med organisationens egna. Bestäm samtidigt vilka delmängder som ska redovisas och vilka förbjudna utfall som stoppar en release, innan systemets svar kan påverka kriterierna.

Hur ska varje utvärderingsscenario dokumenteras?

Varje scenario ska dokumenteras som en versionshanterad fallpost som en annan utvärderare kan återskapa utan muntlig bakgrundskunskap. Posten behöver beskriva vem som agerar, vad personen försöker göra, systemets utgångsläge, indata och relevanta filer samt vilken historik, kunskap, behörighet och vilka verktygsresultat som är tillgängliga. Den ska också skilja mellan nödvändiga resultat, godtagbara alternativ och situationer där systemet måste be om förtydligande, avstå, vägra eller eskalera. Det är mer robust än att kräva en enda ideal formulering.

• Identitet: stabilt fall-id, ägare, status, versionshistorik, täckningsfamilj, uppgiftsfamilj, delmängdsetiketter, konsekvens och avsedd uppdelning.
• Proveniens: källkategori, behörighetsbeslut, dataminimering och en skyddad hänvisning till originalet när åtkomsten medger det.
• Förväntningar: nödvändiga fakta eller tillståndsändringar, giltiga alternativa vägar, förbjudna svar, utlämnanden, verktygsanrop och åtgärder.
• Drift: bedömartyp, matris, grindar, eventuell referenslösning, förhandsbestämt antal försök och aggregeringsregel samt versioner av modell, prompt, sökkorpus, verktyg, policy och testsele.

För slumpmässiga eller flerstegade system kan flera försök behövas, men antalet och sammanvägningen ska bestämmas före körningen. Dokumentera även vilken kompetens granskaren behöver, vilken kalibreringsversion som gäller och vem som avgör oenighet. En fungerande referenslösning är värdefull när den visar att fallet går att lösa och att bedömaren reagerar rätt. Den får däremot inte göra andra sakligt giltiga formuleringar eller arbetsvägar ogiltiga. Den samlade fallposten är ett redaktionellt arbetsförslag och bör förenklas eller utökas efter systemets faktiska risker.

Ett bra testfall ställer inte bara en svår fråga – det återskapar ett avgränsat arbete och gör framgång, giltig variation och förbjudet beteende synliga.

Hur poängsätts scenarier utan att fel beteende belönas?

Välj den smalaste bedömningsmetod som faktiskt kan skilja ett godtagbart utfall från ett fel. Använd deterministiska kontroller för objektivt verifierbara värden, scheman, verktygsargument, poststatusar och förbjudna åtgärder. Kontrollera ändå att regeln är fullständig och att uppgiften går att lösa; en exakt kontroll kan vara exakt fel. När flera formuleringar eller vägar är giltiga kan referensfakta eller en fungerande referenslösning ange nödvändiga delar utan att låsa svaret till en ordalydelse.

• Deterministisk kontroll passar när rätt värde, struktur, åtgärd eller slutstatus kan verifieras entydigt.
• Referensfakta passar när beviskraven är avgränsade men flera formuleringar och arbetsvägar är giltiga.
• En förankrad bedömningsmatris passar öppna kvaliteter som användbarhet, fullständighet och tydlig åtskillnad mellan fakta och osäkerhet.
• Kvalificerad expertbedömning behövs när domäntolkning eller konsekvenser inte kan avgöras giltigt med automatiska kontroller.

Modellbaserade bedömare för öppna kvaliteter behöver separata, observerbara dimensioner och kalibrering mot relevanta mänskliga bedömningar. OpenAI uppger exempelvis att den automatiska bedömaren i GDPval inte kunde ersätta erfarna yrkesgranskare; det är en varning mot att förväxla automatisering med objektivitet, inte ett förbud mot automatiskt stöd. Meningsfulla delmoment kan få delpoäng, samtidigt som förbjudna utlämnanden eller obehöriga åtgärder ligger i en separat, icke-kompenserbar grind. Behöriga produkt- och riskansvariga måste fastställa grindar, matrisversion, delmängder, sammanvägning och beslutsregel innan kandidater jämförs.

Hur kan granskare tillämpa kriterierna konsekvent?

Ge granskarna samma kontext, observerbara ankare och kalibreringsfall innan de bedömer levande resultat. Guiden ska förklara arbetsflödets syfte, aktören, tillgängliga bevis, tillåtet beteende, produktgränsen och vilken matrisversion som gäller. Varje poängnivå behöver kännetecken som går att se i svaret eller körspåret, tillsammans med positiva, negativa och gränsnära exempel. Lägg också till valet ”kan inte bedömas” för trasiga fall, saknat underlag eller en testmiljö som inte kan nå det avsedda tillståndet.

1. Kör kalibreringsfall före skarp granskning och på nytt när uppgiftsmix, policy, matris eller granskargrupp ändras.
2. Dölj systemidentitet och variera ordningen när jämförelsen annars kan påverkas av förväntningar.
3. Samla in oberoende poäng och motiveringar innan granskarna diskuterar med varandra.
4. Undersök oenighet som möjlig signal om trasigt fall, oklart ankare, saknad kontext eller legitimt flera godtagbara utfall.
5. Utse en ansvarig för avgöranden och bevara etiketter, motiveringar, matrisversioner och beslut.

Konsekvens betyder här inte att människor alltid sätter samma poäng. Oenighet kan visa att en produktfråga ännu inte är avgjord eller att flera resultat faktiskt är acceptabla. Pressa då inte fram en falsk samsyn; skilj mellan rättning av ett defekt fall, förtydligande av ett kriterium och ett nytt produkt- eller policybeslut. Strukturerade matriser, kalibrering samt granskning av poäng och körspår hjälper dessutom teamet att avgöra om problemet sitter i systemet, fallet, bedömaren eller miljön. Förfarandet är en syntes och behöver anpassas efter uppgiften.

Hur förblir utvärderingsmängden användbar genom utveckling och release?

Skilj en synlig utvecklingsmängd för återkommande förbättringar från ett skyddat releasetest som används sparsamt för slutliga jämförelser och releasebeslut. Utvecklingsfallen får styra ändringar av promptar, sökning, verktyg, policy och arbetsflöde, men resultaten är då utvecklingsbevis. Upprepad styrning mot samma test riskerar anpassning till just de synliga fallen. Tilldela därför uppdelningen när fallet registreras, före rutinmässiga körningar och resultatgranskning, och skydda releasetestets exakta fall, referenser, matriser och resultat från förbättringsarbetet.

Oberoende handlar inte bara om identiska texter. Kontrollera även närdubbletter, gemensamma källposter, parafraser och syskon från samma scenariomall mellan mängderna. Ett bekräftat fel som har använts för felsökning eller åtgärd hör hemma bland utvecklings- eller regressionsfallen. Releasetestet kan täcka samma felklass med ett självständigt skapat fall som inte har styrt ändringen. Om ett skyddat fall ändå påverkar konstruktionen ska det flyttas till utvecklingsunderlaget och ersättas i en ny, dokumenterad version.

• Registrera ägare, proveniens, behörighet, uppdelning, exponering, versioner, senaste granskning och skälet till varje ändring.
• Lägg till verifierade fel först efter kontroll av förväntat beteende och minimering av känsligt material.
• Ompröva täckningen när arbetsflöde, användare, policy, kunskapsbas, modell, prompt, verktyg, behörigheter eller driftmiljö ändras väsentligt.
• Redovisa resultat per uppgiftsfamilj, täckningsfamilj, relevant delmängd, konsekvens och grind – inte bara som ett medelvärde.

Det finns ingen universell mängdstorlek, delningsprocent eller uppdateringstakt. Sammansättningen beror på vilket beslut som ska fattas, arbetsflödets variation, viktiga delmängder, konsekvenser, bedömarnas tillförlitlighet och vilket godkänt underlag som finns. En godkänd offlinekörning är därför beslutsunderlag, inte ett intyg om affärsnytta, säkerhet, rättvisa, regelefterlevnad eller produktionsberedskap. Kombinera den med övervakning, användarstudier och incidentuppföljning. När juridiska, medicinska, finansiella, arbetsrättsliga, säkerhets-, integritets- eller andra reglerade bedömningar berörs ska de ligga kvar hos lämpligt kvalificerade och behöriga personer.