Een scenario-evaluatieset bouwen voor een zakelijk AI-systeem

Een bruikbare scenario-evaluatieset begint niet bij een stapel slimme prompts, maar bij één afgebakende workflow en de beslissing die de test moet ondersteunen. Stel dat een inkoopassistent een geloofwaardig aanvraagpakket ontvangt met een afwijkend leveranciersnummer, een onbereikbare beleidsbron en een offerte waarin instructies aan de assistent zijn verstopt. Een gemiddelde score op keurige voorbeelden zegt weinig over deze combinatie. Leg daarom vooraf vast welk werk is toegestaan, welke uitzonderingen ertoe doen, welk gedrag verboden is, hoe uitkomsten worden beoordeeld en welke fouten een release blokkeren.

Wat moet een scenario-evaluatieset afdekken?

Een scenario-evaluatieset moet zowel de normale werkverdeling als belangrijke uitzonderingen, bekende fouten en expliciet verboden gedrag afdekken. Begin met één systeemversie en één workflow: wie mag het systeem gebruiken, welke invoer en kennis zijn beschikbaar, welke tools en bevoegdheden heeft het, en welke beslissing moet de evaluatie informeren? Realistische testsets sluiten aan op verwachte gebruiksomstandigheden, maar representativiteit alleen is onvoldoende wanneer zeldzame fouten grote gevolgen kunnen hebben.

Breng taakfamilies en relevante variaties in kaart met uitsluitend geautoriseerde bronnen, zoals werkregistraties, ondersteuningsvragen, gebruikersonderzoek, incidenten en walkthroughs met domeinexperts. Productielogboeken zijn niet vanzelf volledig, representatief, correct gelabeld of vrij herbruikbaar. Noteer daarom onzekerheid wanneer betrouwbare operationele gegevens ontbreken. Synthetische casussen kunnen hiaten vullen, mits iemand controleert of hun uitgangssituatie, bewijs en verwachte gedrag werkelijk bij de workflow passen.

Voor de illustratieve inkoopassistent omvat de kaart complete aanvragen, ontbrekende stukken, strijdige bedragen of leverancierscodes, onvoldoende bewijs, pogingen om goedkeuring te omzeilen, instructies in uploads en onbetrouwbare retrieval. Een bevestigde eerdere fout krijgt een geminimaliseerde reproductie. De precieze inkoopregels blijven organisatiespecifiek. Bepaal vóór de eerste uitvoer welke segmenten worden gerapporteerd, welke verboden gedragingen als poort gelden en welke releasebeslissing de resultaten mogen ondersteunen.

Hoe leg je ieder evaluatiescenario reproduceerbaar vast?

Leg ieder scenario vast als een casus die een andere evaluator opnieuw kan opbouwen en beoordelen. Geef de casus een stabiel ID, eigenaar, versiegeschiedenis, dekkingsgroep, taakfamilie, segmentlabels, gevolgklasse, herkomst, toestemmingsregistratie en beoogde set. Beschrijf vervolgens de actor en het doel, de beginsituatie, aanvraag en bestanden, relevante historie, toegestane kennis, tools, bevoegdheden, toolresultaten, omgevingscondities en systeeminstructies.

• Vereiste uitkomst: de feiten, statuswijzigingen of vervolgstappen die aantoonbaar aanwezig moeten zijn.
• Toegestane variatie: alternatieve formuleringen of routes die hetzelfde geldige resultaat bereiken.
• Grenzengedrag: wanneer het systeem moet verduidelijken, afzien, weigeren of naar een bevoegde medewerker escaleren.
• Verboden uitkomst: afzonderlijk vastgelegde uitvoer, openbaarmaking, toolaanroep, handeling of statuswijziging die niet mag plaatsvinden.

Koppel daaraan de beoordelaar, rubric, poorten en eventuele referentieoplossing. Zo’n referentie kan bewijzen dat een begrensde taak uitvoerbaar is en de beoordelaar helpen testen, maar is niet automatisch de enige geldige formulering of route. Leg bij niet-deterministische of meerstaps systemen vooraf het aantal proeven en de aggregatieregel vast. Bewaar ook de versies van model, prompt, kenniscollectie, tools, beleid en testharnas, plus reviewerkwalificaties, adjudicatieroute en onopgeloste beperkingen.

Een sterke evaluatiecasus stelt niet alleen een lastige vraag, maar maakt werk, geldige variatie en verboden gedrag inspecteerbaar.

Hoe beoordeel je een scenario zonder verkeerd gedrag te belonen?

Kies per scenario de smalste beoordelingsmethode die succes werkelijk van falen kan onderscheiden. Gebruik deterministische controles voor objectief verifieerbare antwoorden, schema’s, berekeningen, toolargumenten, registratiestaten en verboden handelingen. Controleer wel of de test volledig is en de taak oplosbaar blijft: een precieze automatische controle kan nog steeds een onjuist criterium afdwingen of een geldige alternatieve route afwijzen.

• Gebruik referentiefeiten of een referentieoplossing wanneer het bewijs of eindresultaat begrensd is, maar meerdere formuleringen of routes geldig zijn.
• Gebruik afzonderlijke rubricdimensies met observeerbare ankers voor open kwaliteiten zoals bruikbaarheid, volledigheid of onderbouwing.
• Kalibreer een modelbeoordelaar tegen relevante oordelen van gekwalificeerde mensen; overeenstemming op zichtbare ontwikkelcasussen bewijst geen algemene validiteit.
• Schakel bevoegde domeinexperts in wanneer interpretatie of gevolgen niet valide door automatische controles kunnen worden beslist.

Deelscores zijn nuttig wanneer taakonderdelen een betekenisvolle voortgang vormen, maar een verboden openbaarmaking of onbevoegde handeling hoort buiten die compensatie te blijven. Behandel zo’n gebeurtenis als een vooraf bepaalde poort, ongeacht hoe verzorgd de rest van het antwoord is. Product- en risico-eigenaren bepalen de concrete poorten en gevolgen. Zet ook rubricversies, segmentdefinities, aggregatie en beslisregel vast voordat kandidaten worden vergeleken; een latere wijziging vormt een nieuwe evaluatieversie.

Hoe laat je beoordelaars de criteria consequent toepassen?

Geef beoordelaars vóór iedere uitvoer dezelfde taakcontext, bewijsgrenzen en observeerbare scoreankers. De beoordelaarsgids vermeldt het doel van de workflow, de actor, beschikbare informatie, toegestaan gedrag, productgrens en rubricversie. Omschrijf ieder scorepunt met positieve, negatieve en grensvoorbeelden. Voeg bovendien een route voor ‘onvoldoende bewijs’ of ‘niet te beoordelen’ toe, zodat een defecte casus niet ten onrechte als systeemfout wordt geregistreerd.

1. Beoordeel eerst kalibratiecasussen en bespreek waar de ankers verschillend zijn geïnterpreteerd.
2. Herhaal de kalibratie wanneer taakmix, beleid, rubric of groep beoordelaars wezenlijk verandert.
3. Verberg waar praktisch de systeemidentiteit en wissel de uitvoervolgorde bij vergelijkende beoordeling.
4. Laat beoordelaars onafhankelijk scoren en motiveren voordat zij hun oordeel bespreken.
5. Leg labels, argumentatie, rubricversie en de uitkomst van adjudicatie duurzaam vast.

Onderzoek meningsverschillen in plaats van ze direct weg te stemmen. Een verschil kan wijzen op een onduidelijke drempel, ontbrekende context, een kapotte taak, legitieme variatie of een productbeslissing die nog niet is genomen. Wijs een adjudicatie-eigenaar aan die onderscheid maakt tussen herstel van de evaluatie en een nieuwe beleidskeuze. OpenAI’s GDPval demonstreert meerstaps expertcontrole, geblindeerde vergelijking en gedetailleerde rubrieken, maar vormt geen universeel protocol voor bedrijfsbeoordelaars.

Hoe blijft de evaluatieset bruikbaar tijdens ontwikkeling en release?

Houd een zichtbare ontwikkelset voor iteratie en een afzonderlijke, beschermde releasetest voor spaarzaam beslisbewijs. Het team mag ontwikkelcasussen herhaald gebruiken om prompts, retrieval, tools, beleid en workflowlogica te verbeteren; daardoor zijn de scores ontwikkelbewijs. Wijs de set van een nieuwe casus toe wanneer deze in het register komt, vóór routinematige uitvoering of inspectie van uitkomsten. De exacte releasecasussen, antwoorden, rubrieken en resultaten mogen de iteratie niet inhoudelijk sturen.

Controleer tussen de sets op exacte en bijna-duplicaten, gedeelde bronrecords, parafrases en varianten uit dezelfde scenariosjabloon. Registreer wie toegang had tot casusinhoud, referentieantwoorden, rubrieken en resultaten. Een bekende fout die diagnose of herstel al heeft gestuurd, hoort bij ontwikkeling of regressie. De releasetest kan dezelfde foutklasse afdekken met een onafhankelijk gemaakte, niet-dubbele casus die de wijziging niet heeft beïnvloed.

• Registreer eigenaar, herkomst, toestemming, settoewijzing, blootstelling, versies, beoordelingshistorie en wijzigingsreden.
• Verplaats een blootgestelde releasecasus naar ontwikkeling of regressie zodra zij een wijziging materieel heeft gestuurd.
• Voeg alleen een versiebeheerste vervanger toe die geen duplicaat of nabije variant van de blootgestelde casus is.
• Herzie dekking na materiële wijzigingen in workflow, gebruikers, beleid, kennis, model, prompts, tools, bevoegdheden of omgeving.
• Rapporteer per taakfamilie, dekkingsgroep, relevant segment, gevolg en poort, naast een eventuele totaalsamenvatting.

Er bestaat geen universeel aantal casussen, splitsingspercentage of verversingsinterval. Omvang en samenstelling hangen af van de releasebeslissing, workflowvariatie, belangrijke segmenten, beoordelingsbetrouwbaarheid en beschikbare geautoriseerde gegevens. Een offline voldoende resultaat is bovendien geen certificaat voor bedrijfswaarde, veiligheid, eerlijkheid, naleving of productierijpheid. Combineer dit bewijs met monitoring, gebruikersonderzoek en incidentanalyse. Laat gereguleerde of anderszins ingrijpende oordelen bij passend gekwalificeerde en bevoegde mensen.