Een AI-demo kan overtuigend zijn. Vijf voorbeeldvragen gaan goed, de interface reageert snel en de leverancier toont een hoge score op een publieke benchmark. Daarna lijkt de stap naar een model, GPU-cluster of private inference omgeving logisch. Toch is dat precies het moment waarop veel organisaties te snel besluiten.
Een demo test meestal niet jouw documenten, jouw Nederlandse taalgebruik, jouw autorisatieregels, jouw piekbelasting of jouw privacy-eisen. Een publieke benchmark zegt ook weinig over de vraag of een model goed omgaat met interne terminologie, lange supporttickets, tenantdata of retrieval uit je eigen kennisbank. Zonder eigen evaluatiekader koop je vooral op gevoel.
In de eerdere artikelen ging het over public AI versus private AI, over private inference in de praktijk en over wanneer private inference geschikt is. Dit artikel gaat over de stap daarna: hoe bepaal je vóór aankoop of een model, prompt, RAG-opzet en infrastructuur goed genoeg zijn?
Een benchmark is geen aankoopbesluit
Publieke benchmarks zijn nuttig als startpunt. Ze geven een grove indruk van redeneervermogen, programmeertaken, algemene kennis of taalvaardigheid. Ze helpen ook om modellen uit te sluiten die duidelijk onder de maat presteren. Maar ze zijn geen vervanging voor een test op je eigen workload.
De meeste publieke benchmarks meten gestandaardiseerde taken. Jouw toepassing is vaak veel specifieker. Denk aan een chatbot voor Nederlandstalige polisvoorwaarden, een assistent voor supportmedewerkers, een samenvatter voor juridische documenten of een AI-feature in een SaaS-product. In die gevallen telt niet alleen of het model slim lijkt, maar vooral of het consequent het juiste antwoord geeft binnen de context, zonder informatie te verzinnen of data te lekken.
Gebruik publieke benchmarks daarom als baseline. Ze kunnen helpen bij een eerste shortlist van modellen. De echte beslissing neem je pas nadat je eigen testset is gedraaid op de modellen, prompts, parameters en infrastructuur die je daadwerkelijk overweegt.
Begin met een eigen golden dataset
Een goede evaluatie begint met een eigen testset. Vaak wordt dit een golden dataset genoemd: een set voorbeelden waarvan je vooraf weet wat een goed antwoord is, of in elk geval hoe een goed antwoord beoordeeld moet worden. Die dataset hoeft in het begin niet groot te zijn. Een zorgvuldig gekozen set van vijftig tot tweehonderd cases kan al veel meer zeggen dan een algemene modelscore.
Gebruik voorbeelden uit echte processen. Denk aan supportvragen, interne kennisbankartikelen, contractfragmenten, productdocumentatie, incidentrapporten, technische handleidingen, klantmails of SaaS-workflows. Neem niet alleen nette voorbeelden op. Juist de lastige gevallen zijn waardevol: incomplete vragen, dubbelzinnige formuleringen, verouderde documenten, tegenstrijdige context, gevoelige data en verzoeken die het systeem moet weigeren.
Leg per testvoorbeeld minimaal vast:
- de vraag of taak die de gebruiker stelt;
- de context, documenten of records die beschikbaar mogen zijn;
- het verwachte antwoord, of een rubric waarmee je het antwoord beoordeelt;
- de dataklasse, bijvoorbeeld openbaar, intern, vertrouwelijk of persoonsgegevens;
- het risico als het antwoord fout is;
- of de case must-pass is of alleen meetelt in de totaalscore.
Voor sommige taken is één exact antwoord mogelijk. Voor andere taken, zoals samenvatten of classificeren, werk je beter met beoordelingscriteria. Een samenvatting kan bijvoorbeeld goed zijn als alle hoofdpunten zijn genoemd, er geen nieuwe feiten zijn toegevoegd en de toon past bij het kanaal. Maak die criteria expliciet. Anders wordt de beoordeling achteraf een discussie over smaak.
Maak de test herhaalbaar met een harness
Een eval harness is de laag die je testset herhaalbaar uitvoert. Dat kan een bestaande tool zijn, een eigen script of een combinatie van notebooks, CI-jobs en dashboards. De vorm is minder belangrijk dan de discipline: dezelfde input moet onder dezelfde omstandigheden opnieuw te draaien zijn.
Een bruikbare harness legt per run vast welk model is gebruikt, welke modelversie, welke prompt, welke system prompt, welke parameters, welke datasetversie en welke infrastructuur. Parameters zoals temperature, top-p, max tokens en contextlengte horen in de runmetadata. Dat geldt ook voor RAG-instellingen zoals chunkgrootte, embeddingmodel, reranker, top-k en filters.
Bewaar daarnaast de ruwe outputs. Alleen een totaalscore is te beperkt. Je wilt kunnen terugzoeken waarom een model slechter scoorde, welke cases faalden en of een verandering vooral effect had op kwaliteit, latency of kosten. Voor serieuze besluitvorming heb je voorbeeldniveau-resultaten nodig: input, opgehaalde context, antwoord, score, latency, tokengebruik, foutmelding en eventuele reviewer-notities.
Met zo'n harness kun je meerdere modellen of backends naast elkaar zetten zonder telkens een nieuwe testmethode te bedenken. Je vergelijkt dan niet demo A met demo B, maar run A met run B op dezelfde set. Dat maakt gesprekken met leveranciers, interne teams en security concreter.
Test RAG in twee lagen
Bij retrieval augmented generation, meestal RAG genoemd, kan een fout op twee plekken ontstaan. Het systeem kan de verkeerde context ophalen, of het model kan slecht antwoorden op basis van goede context. Als je alleen het eindantwoord beoordeelt, weet je niet waar het probleem zit.
Test daarom eerst retrieval los. Worden de juiste documenten, passages of records opgehaald? Staat de relevante informatie hoog genoeg in de resultaten? Werken filters op klant, tenant, rol, taal, versie en documenttype goed? Metrics zoals context recall en context precision helpen hierbij. Context recall kijkt of de benodigde informatie is opgehaald. Context precision kijkt of de opgehaalde context vooral relevant is, in plaats van ruis.
Test daarna de antwoordkwaliteit. Een goed antwoord is niet alleen vloeiend. Het moet passen bij de vraag, gebaseerd zijn op de opgehaalde context en volledig genoeg zijn voor de taak. Let op faithfulness of groundedness: staat het antwoord in de context, of voegt het model eigen aannames toe? Meet ook answer relevance, completeness en correctness. Bij toepassingen met bronverwijzingen kun je daarnaast controleren of claims gekoppeld zijn aan de juiste passages.
Deze scheiding voorkomt verkeerde conclusies. Een beter taalmodel lost geen slechte retrieval op. En een betere zoeklaag helpt niet als het model daarna alsnog informatie verzint of beleid negeert.
Neem security en privacy mee vanaf dag één
Een model dat normale vragen goed beantwoordt, kan alsnog ongeschikt zijn voor productie. Zeker bij private inference draait het vaak om data die je niet zomaar naar een publieke dienst wilt sturen. Dan moet je ook testen of de oplossing zich goed gedraagt bij misbruik, fouten en randgevallen.
Neem security- en privacycases op in dezelfde evaluatieset. Test directe prompt injection, waarbij een gebruiker probeert instructies te overschrijven. Test indirecte prompt injection, waarbij schadelijke instructies in een document, webpagina of ticket staan. Test jailbreaks, system prompt leakage, PII leakage en het herhalen van vertrouwelijke informatie uit context. Als je werkt met meerdere klanten of tenants, test dan expliciet cross-tenant toegang: een gebruiker van klant A mag nooit context van klant B krijgen.
Gebruik je tools, agents of acties, test dan ook tool misuse. Mag het model een API-aanroep doen op basis van onvolledige informatie? Kan een gebruiker via een prompt een export, e-mail of wijziging starten die buiten zijn rechten valt? System prompts en modelinstructies zijn geen toegangscontrole. Autorisatie, filtering, logging en scheiding van data moeten buiten het model afdwingbaar zijn.
Dit raakt direct aan digitale soevereiniteit. Controle over locatie is nuttig, maar niet genoeg. Je wilt ook controle over toegang, verwerking, logging, modelgedrag en de manier waarop testdata wordt gebruikt.
Meet performance zoals gebruikers het merken
Gemiddelde latency zegt weinig. Gebruikers merken vooral de langzame gevallen, de wachtrij bij piekbelasting en de tijd voordat het eerste token verschijnt. Meet daarom p95- en p99-latency, time to first token, tokens per seconde, totale verwerkingstijd en foutpercentages. Doe dat niet alleen met één gebruiker, maar ook met de concurrency die je in productie verwacht.
Private inference heeft eigen performancevragen. Past het model in VRAM? Wat gebeurt er als meerdere gebruikers tegelijk lange context meesturen? Hoe gedraagt de KV-cache zich? Hoe groot wordt de queue? Zakt de output token throughput bij langere antwoorden? Welke batch-instellingen verbeteren throughput, en welke maken de interactie te traag?
Meet ook kosten op een manier die past bij je gebruik. Tokenprijs of GPU-uurtarief is maar één deel van het verhaal. Voor een praktische vergelijking kun je kijken naar cost per successful request: de infrastructuurkosten per uur gedeeld door het aantal succesvolle requests per uur binnen je SLO. Requests die falen, te traag zijn of opnieuw geprobeerd moeten worden, tellen dus niet mee als succes.
Daarmee voorkom je een scheef beeld. Een goedkoop model dat veel fouten maakt of veel retries nodig heeft, kan in de praktijk duurder zijn dan een zwaarder model dat vaker in één keer bruikbaar antwoord geeft.
Zet thresholds vast voordat je gaat vergelijken
Een evaluatie werkt alleen als je vooraf bepaalt wat goed genoeg is. Anders schuift de discussie na elke test. Dan wordt een tegenvallende securitytest ineens "acceptabel voor de pilot", of wordt een trage p95-latency weggewuifd omdat de gemiddelde latency er goed uitziet.
Maak daarom thresholds per categorie. Bijvoorbeeld: alle must-pass privacy- en securitycases moeten slagen. Er mag geen cross-tenant leakage zijn. Minimaal negentig procent van de must-pass kwaliteitscases moet correct zijn. Retrieval recall moet boven een afgesproken grens liggen. P95-latency moet passen bij de gebruikerservaring, bijvoorbeeld lager voor interactieve chat en ruimer voor batchverwerking. Cost per successful request moet binnen de businesscase vallen.
Die grenzen hoeven niet voor elke organisatie hetzelfde te zijn. Een interne assistent die conceptteksten maakt, heeft andere eisen dan een klantgerichte supportbot of een systeem dat juridische documenten samenvat. Het punt is dat je de grens vooraf kiest en die grens gebruikt om modellen, prompts, RAG-instellingen en infrastructuur eerlijk te vergelijken.
Gebruik je evaluatieset als regressietest
Een evaluatieset is niet alleen handig voor aankoop of PoC. De waarde wordt groter zodra je hem blijft gebruiken. Elke wijziging kan regressie veroorzaken: een nieuw model, een andere prompt, aangepaste chunking, een nieuw embeddingmodel, een reranker, andere quantization, een nieuwe serving backend of andere hardware.
Draai daarom dezelfde harness opnieuw bij elke relevante wijziging. Vergelijk niet alleen de totaalscore, maar kijk welke cases verbeteren en verslechteren. Soms levert een modelupdate betere algemene antwoorden op, maar slechtere weigeringen bij gevoelige data. Soms verlaagt quantization de kosten, maar raakt het model net de moeilijke Nederlandstalige cases kwijt. Soms verbetert een snellere backend de p50-latency, terwijl p99 onder piekbelasting verslechtert.
Door evals onderdeel te maken van beheer, voorkom je dat kwaliteit langzaam wegloopt. Je bouwt dan niet alleen een aankooptest, maar ook een manier om je AI-toepassing gecontroleerd te veranderen.
Wat dit betekent voor infrastructuur
Pas als workload, data, testset en acceptatiecriteria duidelijk zijn, kun je zinvol kiezen welke infrastructuur past. Misschien blijkt een publieke AI-dienst voldoende. Misschien past een hybride opzet beter. Misschien is private inference op dedicated of private cloud infrastructuur nodig vanwege data, compliance, latency of voorspelbare kosten.
Voor AI-infrastructuur is de volgorde belangrijk. Begin niet met de vraag welke GPU je nodig hebt. Begin met de vraag welke taken moeten slagen, welke data verwerkt wordt, welke risico's je niet accepteert en welke performance gebruikers nodig hebben. Daarna kun je pas onderbouwd kijken naar modelgrootte, serving stack, capaciteit, monitoring en beheer.
cloud.nl helpt AI-infrastructuur het liefst ontwerpen nadat die punten concreet zijn. Niet op basis van een demo, maar op basis van je workload, dataset, security-eisen, latencydoelen en kostenmodel. Dat maakt de keuze minder spannend en vooral beter toetsbaar.