Testgevallen voor een AI-pilot met duidelijke verwachtingen
Een klein plan met gevallen legt verwachtingen vóór de AI-test vast. Het voorbeeld onderscheidt routine, onduidelijkheid en invoer buiten de taak.
De taak en verwachte routering afspreken
Een fictief softwarebedrijf plant een AI-pilot voor supportberichten. De AI moet een routering voorstellen: bug, access, review of out-of-scope. Toegang verlenen, statussen wijzigen en tickets sluiten blijven taken van het supportteam. De beoordeling gaat dus over het voorstel, niet over een automatisch afgeronde supportdienst.
Leg de verwachte beslissing met de inhoudelijk verantwoordelijken vast voordat de modeluitvoer bekend is. Kunnen zij het niet eens worden, dan moet eerst de regel worden verduidelijkt. Het NIST AI RMF adviseert gedocumenteerde testomstandigheden en beoordeling onder omstandigheden die op de inzet lijken.
Voorbeeldgevallen met verschillende controledoelen kiezen
De volgende selectie is fictief. De teksten illustreren de gevallen; voor de echte pilot worden goedgekeurde oorspronkelijke invoeren met taal en herkomst vastgelegd.
Geval | Voorbeeldbericht | Verwachte routering | Reden |
|---|---|---|---|
| De app crasht als ik een projectnotitie opsla. |
| Duidelijk beschreven foutsymptoom |
| Geef mij toegang tot mijn project. |
| Duidelijk toegangsverzoek; nog geen goedkeuring |
| Ik kom er niet in. |
| Toegangsverzoek of technische fout nog onduidelijk |
| Bij opslaan verschijnt een fout; daarnaast heb ik projecttoegang nodig. |
| Gemengde verzoeken; deze pilot verwacht één categorie per bericht |
| Meld u aan voor ons promotieseminar. |
| Geen supportvraag binnen de afgesproken catalogus |
Het laatste label leidt in dit voorbeeld niet tot verwijdering. De selectie maakt verschillende beslissingen zichtbaar; zij bewijst geen gevalsfrequentie of voldoende omvang van een testdataset. Neem bij latere verzameling ook de werkelijk benodigde talen, invoervormen en ontbrekende informatie mee.
Ontwikkelgevallen scheiden van de latere controle
Voorbeelden die het team gebruikt om prompts of routeringsregels te wijzigen zijn ontwikkelgevallen. Reserveer andere gevallen voor een latere controle die nog niet voor optimalisatie zijn gebruikt. Kopieën en nabije herformuleringen van hetzelfde oorspronkelijke bericht horen niet als onafhankelijk bewijs over beide kanten te worden verdeeld.
Google legt uit hoe hergebruikte testdata en duplicaten de beoordeling bij machine learning kunnen vertekenen. Voor promptontwikkeling volgt daaruit een praktische voorzorg: bekende voorbeelden helpen bij foutonderzoek, maar een latere controle hoort extra onbekende gevallen te bevatten. Een prompt bewerken is geen modeltraining.
Resultaten per geval en fouttype vastleggen
Noteer bij de latere test de model-, prompt- en testsetversies, verwachte routering, werkelijke uitvoer en inhoudelijke beoordeling. Verwachte handmatige beoordeling is passend bij een onduidelijk geval. Een overhaaste definitieve toewijzing kan juist een fout zijn.
Rapporteer routinegevallen, onduidelijke gevallen en invoer buiten de taak afzonderlijk. Wordt een fout gebruikt om de oplossing aan te passen, dan blijft de oorspronkelijke bevinding in het verslag; het geval dient vervolgens ontwikkeling en controle op terugkeer van de bekende fout. Een nieuwe onafhankelijke controle vraagt om verdere geschikte gereserveerde voorbeelden. De tabel is een onderbouwd begin voor de selectie, geen uitgevoerde test of bewijs van geschiktheid voor productie.
Bronnen
Verder lezen
Alle artikelen
AI & automatisering met ASES
AI-assistenten en geautomatiseerde processen