Veel kmo’s met een innovatieve mindset, maar beperktere
AI-kennis, voelen zich door fear of missing out (FOMO) verplicht om mee te gaan
in de hype rond generatieve AI. Hierdoor worden systemen zoals ChatGPT Business
of Copilot for Microsoft 365 vaak wat te impulsief aangeschaft, zonder grondige
evaluatie of beredenering. Daarom creëren wij een evaluatiekader om
organisaties hierin te ondersteunen, zodat men doordacht een keuze kan maken.
Gaandeweg merkten we hoe evaluatie verloopt volgens
verschillende fases en vanuit verschillende perspectieven, en dat je het warm
water niet moet heruitvinden. We lichten hieronder 5 van onze inzichten toe.
1. Evaluatie gebeurt in verschillende fases
Evaluatie verloopt volgens ons kader in drie fases: (1) een geïsoleerde pre-evaluatie, (2) evaluatie tijdens het gebruik (bv. in een piloottest), en (3) post-evaluatie acties. Tijdens de pre-evaluatie bereid je je voor om de beste tool of het beste model te kiezen voor hetgeen je voor ogen hebt. Het GenAI-systeem wordt daarna effectief tijdens de ingebruikname geëvalueerd. Op basis van die evaluaties onderneem je acties om het systeem te verbeteren, om vervolgens de evaluatie iteratief te hernemen. We verdelen de evaluatie in deze drie fases omdat elke fase gekenmerkt wordt door specifieke vragen en bezorgdheden.
2. Evaluatie brengt verschillende perspectieven samen
Niet iedereen speelt dezelfde rol in de evaluatie van een GenAI-systeem. Er zijn namelijk bepaalde zaken die specifiek relevant zijn voor ontwikkelaars of technische profielen, terwijl andere zaken essentieel zijn voor niet-technische eindgebruikers van de GenAI-systemen. Uiteraard ontmoeten die aspecten elkaar en gebeurt de evaluatie door ontwikkelaars in tandem met die van eindgebruikers. Wanneer eindgebruikers echter een systeem aankopen waarover ze geen echt zeggenschap hebben (bv. Microsoft Copilot, ChatGPT…), valt het luik voor de ontwikkelaars weg en moet er op vlak van evaluatie enkel gekeken worden naar het luik voor de eindgebruiker.
3. Je moet het warm water niet heruitvinden
GenAI-systemen hebben specifieke eigenschappen, maar uiteindelijk blijven het ook nog altijd gewoon softwareproducten die een probleem van een eindgebruiker oplossen. Veel evaluatietechnieken die traditioneel al worden gebruikt om (onder andere) software te beoordelen (A/B-testing, klassieke tevredenheidsenquêtes, focusgroepen, User Acceptance Testing…) blijven dus erg relevant – ook al doet de hype ons soms geloven dat je GenAI-systemen moet testen en evalueren met allerlei nieuwe methodes. Deze traditionele evaluatietechnieken nemen we dus standaard op in ons evaluatiekader.
Er bestaan specifiek voor machine learning en Natural Language Processing (taaltechnologie) ook heel wat evaluatiemetrieken die aangeven of een model goed of slecht is in de taak die het moet uitvoeren. Zo heb je waarschijnlijk al eens iets gehoord over de “accuraatheid” van een model of dat een model op een bepaalde “test set” niet goed scoort. Hoewel het hier ook gaat over de evaluatie van AI-modellen, kunnen die metrieken helaas niet altijd makkelijk vertaald worden naar de evaluatie van open-ended output. Er is namelijk vaak geen éne perfecte uitkomst van je vraag aan een chatbot (golden standard) om het effectieve antwoord kwantitatief aan af te toetsen. Je kan wel een goed voorbeeld van een mail of stuk tekst hebben dat volledig naar jouw wensen is, maar dat wil niet zeggen dat elke nieuwe tekst die hier niet 100% mee overeenkomt meteen afgestraft hoeft te worden.
Bijgevolg ontstond de huidige trend om taalmodellen zélf de kwaliteit van de output van een andere taalmodel te laten beoordelen – de zogenaamde LLM-as-a-judge. Je laat bijvoorbeeld een GenAI-systeem een mail schrijven op basis van bepaalde parameters en stelt daarna (al dan niet manueel) een ander model de vraag of het een goede mail was, op basis van een aantal criteria. Dit opzetten zodat het automatisch verloopt, kan echter nog wat technisch zijn, en je loopt ook het gevaar om een slang te creëren die zijn eigen staart opeet. Daarnaast is het soms moeilijk om te bepalen wat nu juist de criteria zijn die de LLM-as-a-judge moet hanteren om de evaluatie uit te voeren.
4. Niet elk criterium is kritiek
Het scherpstellen van je evaluatiecriteria is net datgene waar ons evaluatiekader bij komt kijken. Tijdens halfopen interviews peilden we bij verschillende professionals naar de zaken die zij belangrijk vinden in een GenAI-toepassing voor hun usecase. De leidraad voor deze gesprekken waren de gekozen usecases die we tegelijkertijd uitwerkten en klaarmaakten voor evaluatie (zie ons eerdere artikel). We hielden hierbij rekening met de verschillende fases van evaluatie (zie boven).
Uit deze gesprekken konden we een voorlopige hiërarchische structuur opmaken.
1. Ambitie
Men gebruikt een GenAI-toepassing met een bepaald hoofddoel. Hierbij stel je jezelf de vraag “Wat is het grotere plaatje? Wat wil je bereiken met de GenAI-toepassing?”
2. Jobs to be done
Dit zijn de zijn de concrete deeltaken of subdoelen die de GenAI-toepassing moet ondersteunen. Er kunnen meerdere jobs to be done onder één ambitie vallen. Een job to be done kan gedefinieerd worden als: “Wanneer X zich voordoet (situatie), wil ik Y (motivatie), zodat ik Z (verwachte uitkomst)”. Bijvoorbeeld: “Wanneer ik een vraag stel aan een GenAI-chatbot, wil ik snel correcte antwoorden vinden op basis van onze bedrijfsdata, zodat ik minder fouten maak en sneller klanten kan helpen.”
3. Taakspecifieke succescriteria, zowel hard als zacht
Het is niet altijd eenvoudig om in te schatten wanneer jobs to be done succesvol zijn uitgevoerd. Vaak worden harde succescriteria gebruikt (bv. tijdswinst, meer klanten helpen per dag, minder fouten in je teksten), maar ook zachte criteria spelen een rol (bv. productiviteitsperceptie, algemene tevredenheid, appreciatie). Er kunnen meerdere taakspecifieke succescriteria onder één job to be done vallen.
Het is belangrijk om na te denken hoe je deze laatste succescriteria SMART (Specifiek, Meetbaar, Acceptabel en Realistisch) kunt opstellen, zeker in het geval van zachte criteria waarbij dit minder voor de hand ligt.
Niet alle criteria zijn van even groot belang, bleek ook uit onze interviews. Het kan helpen om ze te ranken in ‘Must have’, ‘Should have’ en ‘Nice to have’ categorieën. Wanneer er niet voldaan wordt aan de ‘Must have’ criteria, is een GenAI-toepassing niet geslaagd. Voor de ‘Should have’ en ‘Nice to have’ categorieën is het afhankelijk van de toepassing, maar ook van de persoon hoe hard deze moeten doorwegen. Ons kader moet dus de mogelijkheid hebben om zelf een puntenverdeling toe te kennen aan deze criteria.
5. Ook je evaluatiekader moet je evalueren
Om deze hiërarchie en weging te visualiseren en te toetsen aan de praktijk, maakten we een eenvoudige app waarmee je via een pipeline tot criteria kan komen en deze kan ranken, om vervolgens een puntenrapport van je GenAI-toepassing te verkrijgen. Door eindgebruikers met deze app te laten werken, zagen we snel waar onze interpretaties uit elkaar lopen: definities die te vaag zijn, criteria die dubbel tellen, of stappen die in de praktijk door elkaar worden gehaald. Zulke signalen gebruiken we om ons kader aan te scherpen, zodat het tegelijk strak genoeg is om consistent toe te passen en flexibel genoeg om te differentiëren per context en maturiteitsniveau.