Een AI-agent testen: van mooie antwoorden naar bruikbaar bewijs

Definieer wat goed genoeg betekent

Schrijf de taak en de foutgevolgen op voordat je voorbeelden verzamelt. Voor een interne samenvatting kunnen volledigheid en bruikbaarheid centraal staan. Voor een afspraakwijziging tellen ook identiteit, beschikbaarheid en de feitelijke verwerking. Behandel die uitkomsten afzonderlijk. Een hoog cijfer voor taal mag een onjuiste systeemactie niet compenseren in een gemiddelde kwaliteitsscore.

Maak per criterium duidelijk wat acceptabel, herstelbaar en blokkerend is. Een onhandige formulering kan herstelbaar zijn; gegevens van een andere klant tonen kan de hele test blokkeren. Leg vast wie dit beoordeelt. Zo voorkom je dat tijdens een demonstratie ongemerkt andere eisen worden gebruikt dan tijdens ontwerp of in het uiteindelijke dagelijkse werk.

Verzamel representatieve en lastige gevallen

Gebruik voorbeelden uit het echte soort werk dat je wilt ondersteunen, aangevuld met gerichte uitzonderingen. Denk aan ontbrekende nummers, verouderde documenten, tegenstrijdige wensen en een vraag buiten de afgesproken taak. OpenAI adviseert toepassingsgerichte evaluaties; een algemene modelbenchmark vertelt weinig over de specifieke records en beslissingen van jouw organisatie.

Houd ontwikkelvoorbeelden en een afzonderlijke controleset uit elkaar. Als dezelfde paar vragen steeds worden gebruikt om instructies te verbeteren, kan de toepassing daarop goed lijken zonder andere formuleringen aan te kunnen. Voeg daarom nieuwe varianten toe die inhoudelijk hetzelfde vragen. Gebruik voor gevoelige praktijksituaties waar mogelijk geschoonde of fictieve gegevens met behoud van de relevante structuur en uitzonderingen.

OpenAI: Evaluation best practices ↗

Beschrijf verwachte uitkomsten zonder één tekst voor te schrijven

Een bruikbaar antwoord kan op verschillende manieren worden geformuleerd. Leg daarom de vereiste feiten, toegestane actie en noodzakelijke vervolgvraag vast, in plaats van alleen een exacte voorbeeldzin. Voor een ontbrekend ordernummer kan de verwachting zijn: stel één gerichte vraag, toon geen ordergegevens en start nog geen wijziging. Verschillende beleefde formuleringen kunnen daaraan voldoen.

Maak ook zichtbaar wat niet mag gebeuren. Een toepassing mag bijvoorbeeld geen retourrecht bevestigen wanneer de bron alleen een algemeen contactadres geeft. Een testgeval krijgt dan broninformatie, bekende feiten, ontbrekende gegevens en verboden gevolgtrekkingen. Die structuur helpt beoordelaars consistente feedback geven en maakt duidelijk waarom een antwoord fout is, ook als de tekst overtuigend klinkt.

Gebruik de testgevallen ook in een begrensde praktijkproef, met een vergelijkbare uitgangssituatie: Een automatiseringspilot opzetten: bewijs verzamelen voor de volgende stap.

Test zoeken en antwoorden afzonderlijk

Wanneer een agent bronnen gebruikt, onderzoek dan eerst of relevante informatie wordt gevonden. Een fout antwoord kan ontstaan doordat de juiste passage ontbreekt, doordat de verkeerde versie wordt opgehaald of doordat het model de gevonden tekst onjuist gebruikt. Alleen het eindantwoord bekijken maakt die oorzaken moeilijk te onderscheiden. Bewaar daarom per test de gebruikte bronverwijzingen en relevante versies.

Gebruik een geval waarin de bron het antwoord ondersteunt, een waarin informatie ontbreekt en een waarin twee bronnen elkaar tegenspreken. In het tweede geval kan een gerichte vraag de juiste uitkomst zijn; in het derde kan overdracht nodig zijn. Beoordeel terughoudendheid dus als onderdeel van kwaliteit. Een agent die altijd antwoordt, presteert niet vanzelf beter dan een agent die grenzen herkent.

Controleer acties en statusovergangen

Voor een agent met hulpmiddelen moet de test aantonen welke functie is gevraagd en wat daadwerkelijk in het doelsysteem is veranderd. Controleer het juiste record, de toegestane velden en de teruggegeven status. Laat de interface onderscheid maken tussen voorgesteld, goedgekeurd en uitgevoerd. Anders kunnen gebruikers een concept verwarren met een bevestigde afspraak of verzonden bericht.

Test ook een dubbele invoer en een storing op een ongemakkelijk moment. Denk aan een verbinding die wegvalt nadat een taak mogelijk al is opgeslagen. De juiste reactie kan onderzoek zijn voordat opnieuw wordt geschreven. Neem daarnaast ingetrokken rechten en gewijzigde records op. Zulke gevallen laten zien of de toepassing ook buiten het gladde demonstratiepad begrijpelijk en beheersbaar blijft.

Illustratieve beoordelingsronde voor een service-assistent

Een fictief team beoordeelt twintig voorbeeldvragen: gewone informatievragen, onvolledige aanvragen, bronconflicten en verboden acties. Twee medewerkers beoordelen eerst een kleine gezamenlijke selectie. Zij bespreken verschillen, zoals wanneer een antwoord voldoende concreet is en wanneer een ontbrekend detail een vervolgvraag vereist. Pas daarna beoordelen ze de rest met dezelfde criteria.

Het team merkt dat de assistent vaak het juiste onderwerp kiest maar bij onbekende afspraken te snel een datum suggereert. Die fout wordt afzonderlijk geregistreerd. Na een aanpassing wordt de oorspronkelijke set opnieuw uitgevoerd en worden nieuwe formuleringen toegevoegd. Dit is een werkmethode, geen garantie dat twintig gevallen voldoende zijn. De omvang moet passen bij de variatie en gevolgen van de taak.

Meet ook het werk van medewerkers

Een correcte uitkomst kan toch veel controle vragen. Meet daarom hoeveel tijd medewerkers nodig hebben om bronnen te openen, voorstellen te herstellen en uitzonderingen af te handelen. Vergelijk dat met de bestaande route. Maak onderscheid tussen eenvoudige en moeilijke gevallen, zodat tijdwinst op veel korte vragen geen grote herstelproblemen bij andere aanvragen verbergt.

Leg ook vast hoeveel aanvragen werkelijk binnen de taakgrens vallen. Een goede score op een klein ondersteund deel zegt weinig over de hele afdeling. Bij weinig gebruik kan het langer duren voordat voldoende verschillende situaties zijn gezien. Combineer cijfers daarom met concrete bevindingen. Een overzicht van aantoonbare fouten en hun gevolgen geeft vaak meer richting dan één percentage zonder context.

Maak testen onderdeel van wijzigingen

Bewaar testgevallen, bronversies, instructies en beoordelingsafspraken op een beheerde plek. Een gewijzigde prompt, nieuw hulpmiddel of andere documentset kan eerder werkend gedrag veranderen. Bepaal welke controles bij iedere wijziging opnieuw nodig zijn en welke extra gevallen ontstaan. Een oplossing kan op het nieuwe onderwerp beter worden terwijl een oude overdrachtsroute verslechtert.

Spreek een besluit af met duidelijke voorwaarden: beschikbaar voor een kleine groep, alleen concepten, of nog geen ingebruikname. Benoem openstaande beperkingen en wie de opvolging doet. Na introductie worden echte incidenten en bruikbare feedback nieuwe testgevallen. Evaluatie levert zo een doorlopend leerproces op, met controleerbaar bewijs voor elke uitbreiding van taken of bevoegdheden.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• AI Agent Laten Bouwen ↗
• AI Chatbot Laten Maken ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag