# Acceptatietests voor niet-deterministische AI-output [Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Facceptatietests-inrichten-voor-niet-deterministische-output&text=Acceptatietests%20voor%20niet-deterministische%20AI-output)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Facceptatietests-inrichten-voor-niet-deterministische-output)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Facceptatietests-inrichten-voor-niet-deterministische-output&title=Acceptatietests%20voor%20niet-deterministische%20AI-output)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Facceptatietests-inrichten-voor-niet-deterministische-output&text=Acceptatietests%20voor%20niet-deterministische%20AI-output)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Facceptatietests-inrichten-voor-niet-deterministische-output)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Facceptatietests-inrichten-voor-niet-deterministische-output&title=Acceptatietests%20voor%20niet-deterministische%20AI-output)[](#) # Acceptatietests inrichten voor niet-deterministische output Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) Softwareontwikkeling leunt van oudsher op determinisme: dezelfde invoer resulteert onder identieke omstandigheden altijd in exact dezelfde binaire uitvoer. Traditionele testsuites controleren of een variabele de waarde true oplevert, of een databasequery precies zeven rijen retourneert en of een API-eindpunt statuscode 200 geeft. Zodra generatieve AI-systemen of grote taalmodellen onderdeel worden van de applicatielogica, verdwijnt deze zekerheid. Een model formuleert antwoorden telkens net iets anders, kiest wisselende synoniemen en vertoont subtiele variatie in zinsbouw, zelfs wanneer de onderliggende parameters strikt zijn ingesteld. Wie acceptatietests probeert in te richten volgens klassieke asserties loopt vast op broze tests die willekeurig falen of juist schijnzekerheid bieden. Het operationaliseren van taalmodellen vereist een fundamentele verschuiving van binaire controles naar statistische, heuristische en semantische kwaliteitsmetingen. In dit artikel behandelen we hoe een robuust acceptatiekader wordt opgezet waarmee niet-deterministische output controleerbaar, toetsbaar en betrouwbaar naar productie kan worden gebracht. ## Waarom klassieke unittests falen bij taalmodellen In klassieke testautomatisering werkt een test meestal met een exacte stringvergelijking: assert response.body == expected_output. Bij taalmodellen faalt dit principe direct. Zelfs wanneer een systeeminstructie vraagt om een beknopte samenvatting van een polisdocument, kan de ene aanroep beginnen met "De verzekerde heeft recht op..." en de volgende met "Uit de voorwaarden blijkt dat de dekking geldt voor...". Beide antwoorden zijn inhoudelijk correct, maar een exacte stringvergelijking faalt onmiddellijk. Het verlagen van de willekeur via parameters biedt slechts beperkt soelaas. Voor een dieper begrip van hoe modelvariabelen zoals temperature en top-p werken, helpt de uitleg over [sampling-parameters en de invloed daarvan op tokenkeuze](https://leren.llmnet.nl/sampling-parameters). Zelfs met een temperatuur van nul blijft een model niet-deterministisch over verschillende hardwareclusters, modelversies of geoptimaliseerde floating-point-implementaties. Acceptatietests moeten daarom niet toetsen op de exacte letters, maar op de structurele geldigheid, feitelijke consistentie en semantische betekenis van de gegenereerde tekst. ## De drie niveaus van acceptatie: deterministisch, heuristisch en semantisch Een doeltreffende teststrategie splitst kwaliteitscontroles op in drie opeenvolgende lagen. Door tests van goedkoop en hard naar duurder en probabilistisch te rangschikken, voorkom je overbodige evaluatiekosten en blijft de testsuite snel. De eerste laag is deterministische validatie. Hierbij wordt getoetst of de uitvoer voldoet aan strikte structurele eisen, zoals een valide JSON-structuur, de aanwezigheid van verplichte velden of het niet overschrijden van een maximale lengte. Lees meer over het afdwingen van machineleesbare antwoorden in het artikel over [structured output en JSON-schema-handhaving](https://api.llmnet.nl/structured-output). Om geautomatiseerde validatieregels vooraf te testen in een browseromgeving, biedt de [JSON Schema output validator en benchmark tool](https://benchmark.llmnet.nl/tool-json-schema-validator) een directe verificatie van schemaconformiteit. Als een model geen geldige JSON oplevert terwijl het systeem dat vereist, hoeft er geen verdere inhoudelijke evaluatie plaats te vinden: de test faalt direct. De tweede laag bestaat uit heuristische controles. Dit zijn snelle, op regels gebaseerde tests die controleren op bekende patronen. Denk aan reguliere expressies (regex) om te verifiëren dat burgerservicenummers, creditcardgegevens of ongepaste termen ontbreken. Ook het meten van het aandeel overlap in sleutelwoorden tussen het bronbestand en het gegenereerde antwoord valt onder deze categorie. De derde laag is semantische evaluatie. Hierbij toetst het testsysteem de feitelijke correctheid, toon en relevantie van het antwoord ten opzichte van een gouden standaard of referentiecontext. Omdat dit niet met vaste regels kan, gebeurt dit via embedding-afstanden of een secundair evaluatiemodel. Testniveau | Methode | Snelheid & Kosten | Typische toepassing | 1. Deterministisch | JSON Schema, regex, type checking | < 1 ms (geen API-kosten) | Payload-validatie, formaatcontrole | 2. Heuristisch | Lengtelimieten, keyword matching, blacklist-checks | < 5 ms (geen API-kosten) | PII-detectie, ontbrekende disclaimers | 3. Semantisch | Embeddings (cosinus-gelijkheid), LLM-as-a-Judge | 200 ms – 2000 ms (API-kosten) | Feitelijke accuraatheid, hallucinatie-detectie | ## Vaste testsamples en gouden datasets samenstellen Geen enkele probabilistische testsuite kan functioneren zonder een representatieve referentiecollectie, vaak aangeduid als een golden dataset. Zo'n dataset bestaat uit minimaal vijftig tot enkele honderden zorgvuldig geselecteerde invoervarianten met bijbehorende referentieantwoorden, acceptatiecriteria en bekende randgevallen. Het samenstellen van deze dataset begint bij domeinexperts. Zij bepalen welke vragen cruciaal zijn voor de bedrijfsvoering en welke fouten onacceptabel zijn. Een goede dataset bevat vier typen testgevallen: - Standaardscenario's (happy path): Veelvoorkomende prompts met eenduidige context en heldere antwoorden. - Randgevallen (edge cases): Complexe, ambigue of tegenstrijdige documenten waarbij het model moet toegeven dat informatie ontbreekt. - Adversariële prompts: Pogingen tot prompt-injectie, vragen buiten het domein of pogingen om interne systeeminstructies te achterhalen. - Formaatextremen: Zeer korte invoer, uitzonderlijk lange invoer en invoer met typefouten of afwijkende opmaak. De kwaliteit van de testsuite hangt direct af van de kwaliteit van de onderliggende data. Voor een overzicht van hoe databronnen worden geschoond en voorbereid, zie het artikel over [datakwaliteit voor AI en het voorkomen van mislukte pilots](https://consultancy.llmnet.nl/datakwaliteit-voor-ai). Zonder schone brondata test je immers ruis tegen ruis. ## LLM-as-a-Judge: patronen, valkuilen en kalibratie Voor semantische acceptatiecriteria — zoals "is het antwoord feitelijk onderbouwd door de meegestuurde bron?" of "is de toon professioneel en neutraal?" — wordt steeds vaker een geavanceerd taalmodel ingezet als beoordelaar (het zogeheten LLM-as-a-Judge-patroon). Hierbij krijgt het evaluatiemodel een strikte rubric en beoordelingsinstructie mee. { "evaluatie_instructie": "Beoordeel of de gegenereerde samenvatting uitsluitend feiten bevat uit de brontekst.", "criteria": { "volledigheid": "Score 1-5: Bevat de tekst alle hoofdpunten?", "feitelijkheid": "Score 1-5: Bevat de tekst beweringen die NIET in de bron staan?", "beknoptheid": "Score 1-5: Is de tekst vrij van overtollige herhaling?" }, "uitvoerformaat": { "type": "object", "properties": { "score": { "type": "integer" }, "motivering": { "type": "string" }, "bevat_hallucinatie": { "type": "boolean" } }, "required": ["score", "motivering", "bevat_hallucinatie"] } } Hoewel dit patroon schaalbare kwaliteitscontroles mogelijk maakt, kent het aanzienlijke valkuilen. Evaluatiemodellen hebben een ingebouwde voorkeur voor langere teksten (verbosity bias), trekken vaker partij voor antwoorden die door hetzelfde model zijn gegenereerd (self-enhancement bias) en hebben moeite met consistente scoring bij subtiele semantische nuances. Om deze methode betrouwbaar te maken voor een acceptatietest, is kalibratie tegen menselijke beoordelaars verplicht. Neem een steekproef van minstens honderd evaluaties en vergelijk het oordeel van het model met dat van twee menselijke experts. Pas de prompts en scoringsrubrieken net zo lang aan tot de correlatie (bijvoorbeeld gemeten via Cohen's kappa) minimaal 0,80 bedraagt. Pas wanneer die drempel is behaald, mag het evaluatiemodel zelfstandig beslissen over een acceptatiepoort. ## Statistische drempelwaarden en metrieken: pass@k en semantische overlap Omdat één enkele uitvoering van een testcase door willekeur kan slagen of falen, moet acceptatie statistisch worden benaderd. In plaats van een binaire "slaagt / faalt"-uitkomst per testcase, draait de testsuite meervoudige iteraties per prompt en berekent een slaagpercentage over de gehele golden dataset. Veelgebruikte metrieken binnen dit kader zijn: - Pass@k: Het percentage testcases waarbij ten minste één van de k gegenereerde antwoorden volledig aan de acceptatiecriteria voldoet. Voor bedrijfskritische processen waar geen menselijke controle tussen zit, hanteren teams juist Pass^k (alle k pogingen moeten slagen om te bewijzen dat het systeem consistent stabiel is). - Embedding Cosinus-Gelijkheid: De vectorafstand tussen het gegenereerde antwoord en het ideale referentieantwoord. Een drempelwaarde van 0,88 tot 0,92 duidt doorgaans op sterke semantische overeenstemming, mits het embeddingmodel gevoelig is voor ontkenningen. - RAG Triad Metrieken: Context Relevance (is de opgehaalde documentatie relevant voor de vraag?), Groundedness (is het antwoord herleidbaar tot de context?) en Answer Relevance (beantwoordt de output de daadwerkelijke gebruikersvraag?). Voorafgaand aan een uitrol naar productie bepalen de producteigenaar en het auditteam de minimale grenswaarden. Bij de formele overgang van een proefopstelling naar een live-omgeving helpt het stappenplan over [een PoC evalueren met duidelijke criteria voor go/no-go](https://consultancy.llmnet.nl/een-poc-evalueren-criteria-voor-go-no-go) om deze harde drempelwaarden contractueel vast te leggen. ## Regressietests en geautomatiseerde CI/CD-integratie Een cruciaal doel van acceptatietests is het voorkomen van kwaliteitsregressie. Regressie treedt bij LLM-systemen niet alleen op bij codewijzigingen in de applicatie, maar ook wanneer de modelleverancier een update uitrolt, wanneer de systeem-prompt wordt aangescherpt of wanneer de chunking-strategie van een vectordatabase wijzigt. Een effectieve regressiepijplijn in continuous integration (CI) draait in fasen: - Snelle pre-commit suite (deterministisch & heuristisch): 50 synthetische tests controleren binnen enkele seconden op JSON-schema's, regex-validering en latentie op een lokale mock of snelle modelvariant. - Nachtelijke evaluatiesuite (semantisch & golden dataset): De volledige golden dataset wordt door het doelsysteem gehaald. Evaluatiemodellen berekenen scores en vergelijken de geaggregeerde resultaten met de basislijn (baseline) van de vorige release. - Diff-analyse: Als de algehele accuraatheid gelijk blijft (bijvoorbeeld 94%), maar specifieke edge cases die gisteren slaagden vandaag plotseling falen, markeert het systeem een silent regression en wordt de build geblokkeerd. Het systematisch inrichten van zulke evaluaties vormt het fundament van een betrouwbaar releasemanagement. Hoe dit past binnen de totale levenscyclus van software-implementaties lees je in het overzicht over [van pilot naar productie: valkuilen vermijden bij AI-projecten](https://consultancy.llmnet.nl/pilot-naar-productie). ## Falende tests analyseren en categoriseren (foutanalyse-matrix) Wanneer een niet-deterministische test faalt, is de oorzaak zelden eenduidig. Ligt het aan een haperende retrieval-stap, een hallucinatie van het model, een te strenge evaluatieprompt of een verouderd referentieantwoord in de testsuite? Zonder gestructureerde categorisering verzanden teams in oeverloze discussies over individuele testgevallen. Foutcategorie | Symptoom | Oorzaak | Oplossing | Retrieval-fout | Groundedness is laag; model geeft generiek antwoord | Relevante brondocumenten ontbreken in de top-k zoekresultaten | Chunking aanpassen, hybride zoeken (BM25 + vector) toevoegen | Model-hallucinatie | Groundedness is laag; antwoord bevat verzonnen details | Model negeert context bij gebrek aan duidelijke instructie | Systeemprompt aanscherpen met negatieve restricties | Formaatfout | JSON parsing faalt; markdown-tags in payload | Model verliest structuur bij lange context of speciale tekens | JSON-mode / response_format forceren via API-parameters | Evaluator-bias | Mens keurt goed, LLM-Judge keurt af (of vice versa) | Evaluatierubric is te vaag of model heeft lengtevoorkeur | Rubric verfijnen met few-shot voorbeelden; recalibreren | Verouderde benchmark | Model geeft correct nieuw beleid, test verwacht oud beleid | Golden dataset is niet bijgewerkt na beleidswijziging | Datasetversiebeheer koppelen aan releases van bedrijfsdocumenten | ## Governance en auditering van testresultaten Acceptatietesten dienen niet alleen om ontwikkelaars gerust te stellen, maar vormen ook een wettelijke en interne verantwoording. Binnen gereguleerde sectoren moet een organisatie kunnen aantonen dat een AI-systeem vóór ingebruikname systematisch is gecontroleerd op accuraatheid en bias. Raadpleeg voor de beleidsmatige randvoorwaarden het overzicht over [AI-governance voor het MKB en verantwoord implementeren zonder bureaucratie](https://consultancy.llmnet.nl/ai-governance-mkb). ## Continue kwaliteitsmonitoring in productie Acceptatietests stoppen niet op het moment dat een release naar productie wordt gepusht. Doordat gebruikersvragen in de echte wereld dynamisch veranderen en modellen onderhevig zijn aan verschuivingen in context, is continue monitoring op productiedata noodzakelijk. Omdat het te kostbaar is om elke live-interactie door een zwaar evaluatiemodel te halen, werken productie-architecturen met statistische steekproeven. Een vast percentage van de interacties (bijvoorbeeld 2% tot 5%) wordt asynchroon doorgestuurd naar een evaluatiequeue. Hierop draaien dezelfde semantische checks als in de CI/CD-testsuite. Wijkt de trend over een periode van 24 uur significant af van de acceptatiewaarden, dan genereert het monitoringsysteem een waarschuwing. Voor een gedetailleerde toewijzing van taken en eigenaarschap rond deze kwaliteitsbewaking na livegang, zie het dossier over [beheer na go-live en operationeel eigenaarschap van AI-systemen](https://consultancy.llmnet.nl/beheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie). ## Een praktisch acceptatieraamwerk voor deployment Om te bepalen of een modelconfiguratie of promptwijziging klaar is voor deployment, kan de onderstaande beslisboom worden doorlopen. Elk niveau fungeert als een harde poort: pas wanneer een niveau slaagt, wordt het volgende niveau geëvalueerd. - Niveau 1: Formaat & Veiligheid (100% vereist) Voldoet 100% van de testgevallen aan het JSON-schema of de vastgelegde structuur? - Is alle output 100% vrij van gedetecteerde PII en blokkerende termen via regex/heuristiek? - Niveau 2: Statistische Semantische Drempels (Dataset-breed) Haalt de golden dataset de minimale drempel voor Groundedness (bijvoorbeeld ≥ 95%)? - Ligt de gemiddelde embedding-cosinusovereenkomst boven de gestelde baseline (≥ 0,90)? - Is er geen sprake van regressie op kritieke edge cases ten opzichte van de vorige release? - Niveau 3: Prestatie- en Kostengrenzen Blijft de p95-latentie binnen het afgesproken serviceniveau (bijvoorbeeld < 2,5 seconden)? - Blijft het tokenverbruik per transactie binnen het gebudgetteerde maximum? Door deze drietrapsacceptatie te automatiseren en vast te leggen in code, transformeer je de onvoorspelbaarheid van taalmodellen naar een beheersbaar, meetbaar en auditeerbaar software-engineeringproces. Daarmee wordt niet-deterministische output net zo betrouwbaar voor bedrijfskritische toepassingen als traditionele deterministische software.