Hoe meet je eigenlijk of een AI-agent goed werkt?

Stel je voor: je AI-assistent beantwoordt een vraag foutloos volgens elke test die je hem hebt voorgelegd, en toch loopt het in de praktijk mis zodra een echte gebruiker ermee aan de slag gaat. Hoe kan dat? En belangrijker nog: hoe voorkom je dat? Microsoft deelde onlangs een kijkje achter de schermen van hoe het team achter Copilot in OneDrive en SharePoint kwaliteit meet, niet met één simpele score, maar met een doorlopend proces dat blijft leren van échte gebruikers. Een verhaal dat elke organisatie die met AI-agents werkt, zou moeten kennen.

Waarom kwaliteit meten bij AI zoveel lastiger is dan bij gewone software

Bij traditionele software is de meetlat helder: een functie geeft de juiste waarde terug, of niet. Een dienst haalt zijn beloofde beschikbaarheid, of niet. Bij AI-systemen ligt dat wezenlijk anders. Een agent kan precies de juiste tools aanroepen en toch een antwoord geven dat subtiel maar overtuigend fout is. Een zoekresultaat kan technisch relevant zijn en toch niet raken aan waar de gebruiker écht naar op zoek was. Kwaliteit is bij AI geen ja-of-nee-vraag, maar iets dat continu verandert, afhankelijk van context en van wie de vraag stelt. En als je die kwaliteit moet waarborgen voor honderden miljoenen zakelijke gebruikers, dan is een losse steekproef of onderbuikgevoel niet genoeg. Dan heb je een systematische aanpak nodig.

Stap één: de snelle check

("Heb ik iets kapotgemaakt?")

Elk goed AI-ontwikkelproces begint met snelle feedback. Ontwikkelaars experimenteren voortdurend met prompts, modelversies en retrieval-pijplijnen, en willen binnen enkele minuten weten of een aanpassing iets verbetert of juist verslechtert. Daarvoor gebruikt Microsoft zogeheten unit-level evaluaties: een snelle innerlijke testcyclus waarbij een ontwikkelaar een systeemprompt aanpast, deze tegen een gerichte set testvragen aanhoudt en direct ziet of belangrijk gedrag behouden blijft. Het verschil met traditionele software-tests is subtiel maar belangrijk: waar een unit test in reguliere software een exact verwacht resultaat afdwingt, toetst deze aanpak juist gedragsmatige eigenschappen zoals samenhang, volledigheid en de juiste toolkeuze. De grens tussen slagen en falen is dus vager, maar het doel blijft hetzelfde: teams vertrouwen geven om snel te blijven verbeteren zonder bang te hoeven zijn voor stille regressies.

Stap twee: offline evaluatie

("Hoe goed is dit systeem eigenlijk écht?")

Snelle checks vertellen je alleen of er iets kapot is gegaan, niet hoe goed een systeem daadwerkelijk presteert. Daarvoor gebruikt Microsoft uitgebreide, zorgvuldig samengestelde benchmarks die realistische zakelijke scenario's nabootsen. Elk testgeval bestaat uit een script van dingen die een gebruiker zou kunnen vragen, gecombineerd met criteria die beschrijven wat een goed resultaat is, ingedeeld naar belang: kritiek, verwacht of wenselijk. Een taalmodel speelt daarbij de rol van gebruiker: het stuurt het product actief aan, reageert op vervolgvragen en bevestigt acties, precies zoals een echte persoon dat zou doen. Vervolgens beoordeelt een tweede model, de zogenaamde "LLM-as-a-judge"-aanpak, het resultaat, waarbij die beoordelingen worden afgezet tegen menselijke beoordelaars om betrouwbaar te blijven.

Een mooi voorbeeld is het onderzoek naar hoe je een AI-orchestrator het beste kunt informeren over de tools die het tot zijn beschikking heeft. Geef je vooraf de volledige beschrijving van elke tool mee, of laat je het model zelf beslissen wanneer het meer details nodig heeft via een korte samenvatting? Uit de tests bleek dat het volledig vooraf meegeven van alle toolbeschrijvingen weliswaar de hoogste kosten met zich meebracht, terwijl een hybride aanpak, de standaardmanier gecombineerd met gerichte semantische zoekfuncties, de beste balans opleverde tussen kwaliteit, snelheid en kosten, met een tokenreductie van meer dan 35% ten opzichte van de volledige beschrijvingen.

Toch kent offline evaluatie een fundamentele beperking: het is een momentopname, gebaseerd op wat teams vooraf dénken dat belangrijk zal zijn. Naarmate een product zich ontwikkelt en er echte gebruikspatronen ontstaan, kan de kloof tussen wat je test en wat er werkelijk toe doet, steeds groter worden.

Stap drie: het vliegwiel van gebruikersfeedback

Dit brengt ons bij wat Microsoft het "evals flywheel" noemt: een gesloten cyclus die echte ontevredenheid van gebruikers direct omzet in betere tests en dus betere systemen. Net zoals in softwareontwikkeling bugs uit productie worden omgezet in tests, gebruikt Microsoft feedback van gebruikers, met hun toestemming, om nieuwe evaluatiedata en gerichte verbeteringen te genereren.

Een treffend voorbeeld: een gebruiker uploadde een omvangrijk kwartaalrapport vol complexe tabellen en vroeg simpelweg wat de werkelijke uitgaven in het derde kwartaal waren. Het systeem antwoordde zelfverzekerd, maar haalde per ongeluk het budgetbedrag aan in plaats van het werkelijke bedrag. De oorzaak lag in de structuur van de tabel, met kopteksten die over meerdere kolommen liepen. In plaats van dit ene document te herstellen, bouwde het team een hele familie van testdocumenten die precies deze structuur nabootsen, inclusief bewust "verleidelijk foute" antwoorden. Dit zijn de waarden die een verwarde lezer al snel zou kiezen. Zo test je niet alleen of het systeem het juiste antwoord kan geven, maar ook of het dat antwoord echt begrijpt, en niet slechts giste.

Stap vier: telt het ook echt voor de gebruiker?

Een hogere score op een benchmark betekent niet automatisch een betere ervaring in de praktijk. Daarom kijkt Microsoft ook naar productiegegevens: hoe gedragen gebruikers zich écht met het systeem? Een treffend voorbeeld is een experiment waarbij het icoon van een toegangspunt tot de assistent werd aangepast. Dit leverde een fors hogere klikfrequentie op, maar zei niets over de kwaliteit van de AI zelf. Het loste vooral een bewustwordingsprobleem op. Om dichter bij écht gebruikerswaarde te komen, kijkt het team daarom ook naar de zogeheten "kept rate": het aandeel antwoorden waarbij de gebruiker iets doet dat aangeeft dat het antwoord de moeite waard was, zoals het kopiëren van een resultaat of het volgen van een bronverwijzing. Omdat dit signaal passief wordt verzameld, schaalt het naar elke interactie, in plaats van enkel de kleine groep die expliciet feedback achterlaat.

Kwaliteit, kosten en snelheid: een en dezelfde afweging

Tot slot benadrukt Microsoft dat kwaliteit nooit op zichzelf staat. Een razendsnel antwoord dat inhoudelijk niet klopt, helpt niemand. Maar een perfect antwoord dat te traag of te duur is, helpt evenmin. Door kwaliteit, kosten en snelheid samen in kaart te brengen als een soort kosten-kwaliteitcurve, wordt zichtbaar waar extra investering echt loont en waar je juist op een plafond van afnemende meerwaarde stuit. De vraag verschuift daarmee van "is dit goed genoeg om te lanceren?" naar "welk punt op deze curve past het beste bij dit scenario, gegeven budget en snelheidseisen?"

Conclusie

Wat dit verhaal vooral laat zien, is dat er geen enkele evaluatiemethode is die op zichzelf volstaat. Snelle checks vangen regressies op, maar zeggen niets over absolute kwaliteit. Offline benchmarks bieden houvast, maar verouderen. Gebruikersfeedback is waardevol, maar dekt alleen de gevallen waarin mensen daadwerkelijk feedback geven. En productiedata laat zien wát er gebeurt, zonder altijd te verklaren waaróm. Pas wanneer al deze lagen samenwerken, ontstaat een betrouwbaar beeld van hoe goed een AI-systeem echt is. Zo'n beeld blijft ook actueel naarmate het product en de gebruikers veranderen. Evaluatie is dan ook geen vinkje dat je voor de lancering afvinkt, maar een doorlopend proces dat meegroeit met je product.

Wil je weten hoe je de kwaliteit van AI-agents binnen jouw eigen Microsoft 365-omgeving kunt meten en verbeteren, en welke aanpak het beste past bij jouw organisatie? Neem gerust contact met ons op. We denken graag met je mee over hoe je AI op een betrouwbare en verantwoorde manier inzet binnen jouw organisatie.