Een scenariogebaseerde evaluatieset bouwen voor een zakelijk AI-systeem

Een bruikbare evaluatieset begint bij één afgebakende werkstroom, niet bij een verzameling slimme vragen. Denk aan een assistent die een aankoopaanvraag controleert: een dossier kan geloofwaardig ogen, maar tegelijk een verkeerd leveranciersnummer, een ontbrekend beleidsresultaat en instructies in een bijlage bevatten. Alleen een reproduceerbare casus toont dan of het systeem ontbrekend bewijs signaleert, binnen zijn bevoegdheden blijft en naar de juiste menselijke stap doorstuurt. Leg daarom dekking, geldige uitkomsten, verboden gedrag, beoordelingsregels en het beoogde vrijgavebesluit vast voordat resultaten die keuzes kunnen beïnvloeden.

Wat moet een scenariogebaseerde evaluatieset afdekken?

Een goede set dekt zowel het verwachte dagelijkse werk als zeldzame situaties waarin een fout zwaar kan doorwegen. Begin met één systeemversie, de toegelaten gebruikers, invoer, kennisbronnen, hulpmiddelen en beslissingen. Breng daarna taakfamilies en relevante variaties in kaart via bevoegde werkgegevens, supportdossiers, gebruikersonderzoek, incidenten en workshops met domeinexperts. Productielogboeken zijn daarbij geen automatische waarheid: ze kunnen onvolledig, verkeerd gelabeld, niet representatief of ongeschikt voor hergebruik zijn. Noteer onzekerheid wanneer betrouwbare operationele gegevens ontbreken.

Gebruik vervolgens vier aanpasbare dekkingsfamilies. Laat gewone aanvragen de waargenomen werklast weerspiegelen, zonder een schijnprecisie te verzinnen. Voeg grensgevallen, bevestigde fouten en verboden gedrag bewust toe, ook als ze in het verkeer zelden voorkomen. Voor de aankoopassistent omvat dat bijvoorbeeld een volledig dossier, een ontbrekende offerte, tegenstrijdige bedragen, onvoldoende bewijs, een vraag om de goedkeuringsstap te omzeilen, onbetrouwbare beleidsophaling en instructies die in een geüpload document verborgen zitten. De concrete regels blijven organisatiegebonden.

Bepaal vóór de eerste systeemuitvoer welke segmenten afzonderlijk worden gerapporteerd en welke verboden uitkomsten een vrijgave blokkeren. Mogelijke segmenten zijn taakfamilie, gebruikersrol, taal, documenttype, ontbrekende informatie, permissieniveau, hulpmiddelresultaat en gevolg, maar gebruik alleen dimensies die voor de werkstroom relevant zijn. Die voorafgaande keuze verhindert dat een aantrekkelijk totaalcijfer achteraf bepaalt welke fouten meetellen. De vier families vormen een praktische redactionele synthese, geen universele taxonomie of formule voor gelijke aantallen.

Hoe legt u elk evaluatiescenario reproduceerbaar vast?

Leg elk scenario vast als een versieerbaar casusrecord waarmee een andere evaluator dezelfde beginsituatie kan reconstrueren en dezelfde beoordelingsregels kan toepassen. Geef de casus een stabiele identificatie, eigenaar, status, wijzigingsgeschiedenis, dekkingsfamilie, taakfamilie, segmentlabels, gevolg, herkomstcategorie, gebruiksautorisatie en vooraf toegewezen set. Een realistische taak mag op een bestaand werkproduct zijn gebaseerd, maar vertrouwelijke of gereguleerde productie-inhoud hoort alleen na passende toestemming en minimalisering in de evaluatie.

• Beschrijf actor, doel, beginsituatie, aanvraag, bestanden, relevante voorgeschiedenis en omgevingsvoorwaarden.
• Leg vast welke kennis, hulpmiddelen, permissies, toolresultaten en systeeminstructies werkelijk beschikbaar zijn.
• Benoem vereiste feiten of toestandsovergangen en laat ruimte voor meerdere geldige formuleringen of werkroutes.
• Noteer wanneer verduidelijking, onthouding, weigering of escalatie vereist is wegens ontbrekend bewijs.
• Houd verboden uitvoer, onthullingen, tooloproepen en toestandsovergangen apart van algemene kwaliteitsverwachtingen.
• Bewaar beoordelaarstype, rubric, poorten, referentieoplossing, systeemcomponentversies en adjudicatieroute.

Voor de aankoopassistent kan de beginsituatie een aanvraag met een offerte en een geautoriseerd leveranciersrecord bevatten, terwijl de beleidsophaling tijdelijk niet beschikbaar is. Een geldige uitkomst kan dan ontbrekend bewijs benoemen, geen beleidsregel verzinnen en het dossier nog niet doorsturen. Een andere formulering kan even correct zijn. Een bekende werkende referentie toont dat de taak oplosbaar is en helpt de beoordelaar controleren, maar wordt niet automatisch het enige toegelaten antwoord.

Een sterke evaluatiecasus stelt niet alleen een moeilijke vraag: ze maakt het werk, geldige variatie en verboden gedrag controleerbaar.

Bij een niet-deterministisch of meerstaps systeem kan één poging onvoldoende bewijs leveren. Leg dan vóór inzage in de uitvoer vast hoeveel proeven nodig zijn en hoe de resultaten worden samengevoegd, zonder van één aantal een algemene norm te maken. Registreer ook de versies van model, prompt, retrievalcorpus, hulpmiddelen, beleid, permissies en evaluatieharnas. Anders blijft onduidelijk of een scoreverandering door het systeem, de testomgeving of een stil gewijzigde casus ontstond.

Hoe scoort u een scenario zonder verkeerd gedrag te belonen?

Scoor elk scenario met de smalste methode die succes werkelijk van mislukking kan onderscheiden. Gebruik deterministische controles voor objectief verifieerbare feiten, schema’s, berekeningen, toolargumenten, recordtoestanden en verboden acties. Controleer wel of de test volledig is en de casus oplosbaar blijft: een precieze controle kan nog altijd een verkeerde verwachting coderen. Wanneer meerdere formuleringen of routes geldig zijn, beoordeel dan de vereiste feiten en eindtoestand in plaats van één exacte tekst of toevallig uitvoeringstraject.

• Gebruik een deterministische controle voor een objectief antwoord, verplicht veld, toegelaten tooloproep of recordtoestand.
• Gebruik referentiefeiten of een referentieoplossing wanneer de vereiste inhoud begrensd is maar de vorm kan variëren.
• Gebruik afzonderlijke rubricdimensies met observeerbare ankers voor open kwaliteiten zoals volledigheid, bruikbaarheid en onderbouwing.
• Kalibreer een modelbeoordelaar tegen relevant oordeel van bevoegde mensen; overeenkomst op ontwikkelingscasussen bewijst geen algemene geldigheid.
• Laat gekwalificeerde experts oordelen wanneer domeininterpretatie of gevolgen niet geldig kunnen worden geautomatiseerd.

Gedeeltelijke punten zijn nuttig wanneer taakonderdelen een betekenisvolle voortgang vormen. Toon dan afzonderlijk welk onderdeel faalde, zodat een gemiddelde geen belangrijk tekort verbergt. Zet een vooraf omschreven verboden onthulling, ongeoorloofde actie of omzeilde goedkeuring buiten die compenseerbare kwaliteitsscore. Zo kan een keurige nota de overtreding niet uitmiddelen. De bevoegde product- en risico-eigenaars moeten bepalen welk gedrag verboden is en welk gevolg een mislukte poort voor de vrijgave heeft.

OpenAI meldde voor GDPval dat zijn geautomatiseerde beoordelaar niet betrouwbaar genoeg was om ervaren beroepsbeoordelaars te vervangen. Dat resultaat maakt geautomatiseerde beoordeling niet waardeloos, maar waarschuwt tegen schijnobjectiviteit. Leg rubricversie, poortlogica, segmentdefinities, samenvoeging van proeven en beslissingsregel vast vóór u kandidaten vergelijkt. Wijzigt een criterium nadien, behandel de nieuwe opzet dan als een nieuwe evaluatieversie en herinterpreteer oude scores niet stilzwijgend.

Hoe laat u beoordelaars de criteria consequent toepassen?

Geef beoordelaars vóór de uitvoer een beknopte gids met het doel van de werkstroom, de actor, het beschikbare bewijs, het toegelaten gedrag, de productgrens en de rubricversie. Beschrijf voor ieder scorepunt observeerbare ankers en voeg positieve, negatieve en grensvoorbeelden toe. Voorzie ook een optie onvoldoende bewijs of niet te beoordelen. Zo hoeft een defecte casus niet kunstmatig als systeemfout te eindigen en kan ontbrekende context afzonderlijk worden hersteld.

1. Oefen eerst op kalibratiecasussen en bespreek waar criterium, voorbeeld en verwachte uitkomst uiteenlopen.
2. Herhaal de kalibratie wanneer taakmix, beleid, rubric of beoordelaarspool wezenlijk verandert.
3. Verberg systeemidentiteit en wissel uitvoervolgorde waar dat praktisch en relevant is voor een vergelijking.
4. Verzamel onafhankelijke scores en korte motiveringen voordat beoordelaars met elkaar overleggen.
5. Laat een benoemde eigenaar beslissen of onenigheid een casusfout, onduidelijke drempel, geldig alternatief of open productkeuze blootlegt.

Behandel verschil van oordeel als onderzoeksinformatie, niet als hinder die altijd door consensus moet verdwijnen. Twee antwoorden kunnen legitiem zijn, of de organisatie heeft misschien nog niet beslist waar een grens ligt. Bewaar daarom oorspronkelijke labels, motiveringen, rubricversies en adjudicatieresultaten. Die geschiedenis maakt latere controle en herkalibratie mogelijk. GDPval toont dat stapsgewijze expertreview, geblindeerde vergelijking en gedetailleerde rubrieken uitvoerbaar zijn, maar bewijst geen universeel protocol of vast aantal beoordelaars.

Hoe blijft de evaluatieset bruikbaar tijdens ontwikkeling en vrijgave?

Houd een zichtbare ontwikkelingsset apart van een afgeschermde vrijgavetest en registreer de toewijzing voordat routine-uitvoer wordt bekeken. Het team mag de ontwikkelingsset herhaaldelijk gebruiken om prompts, retrieval, hulpmiddelen, beleid en workflowlogica te verbeteren; de score is dan ontwikkelingsbewijs omdat de oplossing tegen die casussen werd gevormd. Gebruik de vrijgavetest spaarzaam voor eindvergelijkingen of beslissingen en laat de exacte casussen, antwoorden, rubrieken en resultaten de iteratie niet sturen.

• Zoek tussen sets naar exacte dubbels, bijna-dubbels, gedeelde bronrecords, parafrases en verwante scenariomodellen.
• Registreer toegang tot casusinhoud, referentieantwoorden, rubrieken en resultaten.
• Plaats een bevestigde fout die diagnose of herstel stuurde in ontwikkeling of regressie.
• Test dezelfde foutklasse in de afgeschermde set alleen met onafhankelijk gemaakte, niet-blootgestelde casussen.
• Verplaats een vrijgavecasus zodra ze een wijziging wezenlijk beïnvloedt en voeg een versieerbare vervanging toe.
• Bewaar eigenaar, herkomst, autorisatie, set, blootstelling, reviewdatum, wijzigingsreden en pensioneringsreden in één register.

Een set verslijt wanneer het team haar inhoud leert kennen of wanneer de werkstroom verandert. Herbekijk daarom dekking na betekenisvolle wijzigingen aan gebruikers, beleid, kennisbronnen, model, prompts, hulpmiddelen, permissies of bedrijfsomgeving. Voeg geverifieerde incidenten en supportsignalen pas toe nadat gevoelige gegevens zijn geminimaliseerd en de verwachte reactie is bevestigd. Synthetische casussen kunnen nuttig zijn voor gerichte variatie, maar moeten eveneens op realisme, oplosbaarheid en geldige labels worden gecontroleerd.

Rapporteer niet alleen één totaalscore, maar ook resultaten per taakfamilie, dekkingsfamilie, relevant segment, gevolg en poort. Een offline geslaagde set bewijst op zichzelf geen bedrijfswaarde, veiligheid, billijkheid, conformiteit of productierijpheid. Combineer de uitkomst met monitoring, gebruikersonderzoek, incidentreview en ander passend bewijs. Laat juridische, medische, financiële, arbeidsrechtelijke, veiligheids-, beveiligings-, privacy- en andere gereguleerde oordelen bij bevoegde en gekwalificeerde personen. De evaluatieset ondersteunt hun beslissing; ze vervangt die beslissing niet.