Bijna elke AI-assistent die ik tegenkom is live gegaan na één goede demo. Daarna heeft niemand meer gemeten of hij nog net zo goed antwoordt. Het model krijgt een update, iemand past de prompt aan, de kennisbank groeit, en de kwaliteit schuift ongemerkt mee.
Bij gewone software zou niemand dat accepteren. Daar heet het een regressietest. Bij AI heet het AI-evaluatie, en het is kleiner en saaier dan het klinkt.
- Een demo is één meting op één dag. Daarna veranderen model, prompt en bronnen, vaak zonder dat iemand het merkt.
- AI-evaluatie begint met een vaste set van 30–50 echte vragen met verwachte antwoorden: een golden set.
- Elke wijziging aan prompt, model of bronnen gaat pas live als die set niet slechter scoort.
- Dit is geen onderzoekslab. Een spreadsheet, een eigenaar en een vaste drempel zijn genoeg om te beginnen.
Wat er gebeurde
Een interne assistent voor klantvragen, bij een organisatie waar ik meekeek, draaide maanden prima. Medewerkers gebruikten hem voor vragen over leveringsvoorwaarden, retouren en garantie. Tevreden gebruikers, geen klachten.
Toen veranderden er in korte tijd drie dingen. De leverancier zette het onderliggende model op een nieuwere versie. Iemand uit het team voegde een zin aan de systeemprompt toe om antwoorden korter te maken. En er kwam een nieuwe versie van de retourvoorwaarden in de kennisbank, terwijl de oude er ook nog in stond.
Niemand testte iets. Waarom zou je, het werkte toch? Pas weken later merkte een teamleider dat de assistent bij retourvragen soms de oude termijn noemde, en bij garantievragen de uitzonderingen wegliet. Korter, zoals gevraagd. Ook fout.
Het vervelendste was niet de fout zelf. Niemand kon zeggen wanneer het begon, welke van de drie wijzigingen de oorzaak was en hoeveel antwoorden er verkeerd waren gegaan. Er was geen nulmeting. Er was alleen een demo van een half jaar eerder.
Een demo bewijst dat het één keer werkte. Een regressietest bewijst dat het nog steeds werkt.
Waarom AI-evaluatie nu relevant is
Bij klassieke software verandert er niets tenzij jij iets verandert. Bij een AI-assistent schuiven drie lagen, en twee daarvan heb je maar half in de hand.
- Het model. Leveranciers updaten, vervangen en faseren modellen uit. Een nieuwere versie is gemiddeld vaak beter, maar niet per se op jullie vragen.
- De prompt. Eén extra zin (“antwoord kort”, “wees vriendelijker”) verandert gedrag op plekken waar je niet aan dacht.
- De bronnen. Documenten komen erbij, verouderen of staan dubbel. Daarover schreef ik eerder in wie eigenaar is van jullie AI-kennisbank.
Zonder vaste meetset zie je die verschuivingen pas als een klant of collega klaagt. Dan ben je te laat, en je weet niet hoe lang het al misgaat.
Het NIST AI Risk Management Framework (Core) zegt het vrij droog: AI-systemen horen getest te worden vóór ingebruikname en regelmatig tijdens gebruik. Onder de Measure-functie vraagt NIST om gedocumenteerde testsets en metrics (Measure 2.1), om prestaties te meten onder omstandigheden die lijken op de echte inzet (Measure 2.3) en om gedrag te blijven monitoren in productie (Measure 2.4). Het NIST AI RMF Playbook voor Measure werkt dat uit in concrete acties.
Dat klinkt als iets voor organisaties met een eigen compliance-afdeling. Het idee is juist klein: leg vast wat goed is, en kijk bij elke wijziging of je daar nog aan voldoet. Dat werkt voor een team van vijf en voor een afdeling van vijfhonderd.
Het is dezelfde les als bij AI-ROI meten zonder baseline: wat je niet vooraf vastlegt, kun je achteraf niet bewijzen.
Wat je nu kunt doen: AI-evaluatie in vijf stappen
Je hebt geen nieuw platform nodig om te beginnen. Wel een vaste gewoonte.
- Verzamel 30 tot 50 echte vragen. Uit tickets, mailbox of chatlogs, niet verzonnen. Neem de vaakst gestelde vragen, een paar lastige randgevallen en een paar vragen waarop het juiste antwoord “dat weet ik niet” is.
- Schrijf per vraag op wat een goed antwoord is. Geen perfecte modeltekst, wel de kern: welk feit moet erin, welke bron hoort erbij, wat mag er absoluut niet in staan. Laat dit doen door iemand die het vak kent, niet door de bouwer.
- Kies een simpele score. Goed, deels goed, fout. Of een paar criteria: klopt het feit, klopt de bron, is de toon acceptabel. Begin handmatig. Later kun je een deel automatiseren met een tweede model als beoordelaar, zolang je dat steekproefsgewijs blijft controleren.
- Leg de nulmeting vast. Draai de set op de huidige versie en bewaar de uitkomst met datum, modelversie, promptversie en bronnenstand. Dat is je referentie.
- Zet een gate vóór elke wijziging. Nieuw model, aangepaste prompt, nieuwe documenten: eerst de set draaien. Scoort hij slechter op vragen die eerder goed gingen, dan gaat de wijziging niet live tot je weet waarom.
Wat “goed genoeg” vandaag al is
Een gedeelde spreadsheet met vragen, verwachte antwoorden en scores per versie. Eén eigenaar die de set bijhoudt. Een vaste afspraak dat niemand prompt, model of bronnen aanpast zonder die set te draaien. Dat is al meer dan de meeste teams hebben.
Groeit het volume, dan helpen tools als Langfuse (evaluaties en datasets) om runs, scores en versies naast elkaar te zetten. Maar de tool is niet het werk. Het werk is bepalen wat een goed antwoord is, en dat doet geen tool voor je.
Voeg elke echte fout die in productie opduikt toe aan de set. Zo groeit hij mee met de plekken waar het werkelijk misgaat, in plaats van met wat je vooraf bedacht.
Wil je een model of prompt verbeteren zonder te gokken, dan begint AI-modeloptimalisatie bij precies zo’n meetset. Draaien jullie assistenten of agents liever beheerd, met evaluatie ingebouwd? Kijk dan naar managed AI-agents of plan een kort gesprek via contact.
Weet je of jullie AI-assistent vandaag beter antwoordt dan vorige maand?
We helpen teams een eerste golden set opzetten, een nulmeting draaien en een gate inbouwen vóór elke wijziging. Klein begonnen, wel meetbaar.