# Prompts testen voordat ze live gaan

Deel:[𝕏](https://twitter.com/intent/tweet?url=https%3A//community.llmnet.nl/prompt-testen-voor-productie&text=Prompts%20testen%20voordat%20ze%20live%20gaan)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A//community.llmnet.nl/prompt-testen-voor-productie)[Reddit](https://www.reddit.com/submit?url=https%3A//community.llmnet.nl/prompt-testen-voor-productie&title=Prompts%20testen%20voordat%20ze%20live%20gaan)[Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A//community.llmnet.nl/prompt-testen-voor-productie)[Kopieer link](#)
 
 
# Prompts testen voordat ze live gaan

 
 
 
 Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

 Het aanpassen van een prompt voelt vaak verrassend eenvoudig: je voegt een regel toe, veranderd wat bewoordingen en in de playground van de API-leverancier ziet het antwoord er direct beter uit. Toch is dit een van de grootste valkuilen bij het ontwikkelen van AI-toepassingen. Een prompt die perfect werkt voor die ene testcasus, kan ongemerkt de verwerking van honderden andere gebruikersinvoeren verstoren.

 Software-engineering kent al decennia strikte procedures voor het testen van code voordat deze naar productie gaat. Voor prompt-engineering geldt exact dezelfde noodzaak. Wie instructies aan een Large Language Model (LLM) aanpast, wijzigt in feite de logica van de applicatie. In dit artikel behandelen we een gestructureerde werkwijze om promptwijzigingen te valideren, te meten en gecontroleerd uit te rollen.

 
## Waarom de playground niet volstaat

 Het handmatig uitproberen van een prompt in een interactieve playground geeft een vals gevoel van veiligheid. De voornaamste redenen waarom dit onvoldoende is voor productie-applicaties zijn:

 
 
- Steekproef van één: Een geslaagde test op één specifieke invoer zegt niets over de prestaties op de brede diversiteit aan invoer die echte gebruikers genereren.
 
- Cherrypicking: Als ontwikkelaar neig je er onbewust toe om invoer te kiezen waarvan je weet dat het model er goed mee omgaat, of pas je de testvraag subtiel aan tot de output klopt.
 
- Niet-determinisme: LLM's zijn stochastische systemen. Zelfs bij een temperatuurinstelling van 0.0 kan de uitvoer variëren door kleine updates aan de infrastructuur van de provider of afrondingsverschillen in de hardware. Eén geslaagde run biedt geen garantie voor de volgende honderd runs.
 

 Om onverwachte [prompt-fouten](/prompt-fouten) in productie te voorkomen, is een systematische benadering noodzakelijk. Voordat je aan testen toekomt, is het overigens essentieel dat je wijzigingen bijhoudt via strikt [prompt-versiebeheer](/prompt-versiebeheer).

 
## Een representatieve testset opbouwen

 Het fundament van een betrouwbaar testproces is een kwalitatieve testset (ook wel een evaluation dataset of golden dataset genoemd). Deze set moet een realistisch spiegelbeeld zijn van wat het systeem in de praktijk voor de kiezen krijgt.

 Een effectieve testset voor prompts bestaat uit drie categorieën gevallen:

 
 
- Standaardgevallen (Happy Path): Veelvoorkomende, representatieve vragen of opdrachten die het overgrote deel van het dagelijkse volume beslaan.
 
- Randgevallen (Edge Cases): Invoer met extreme lengtes, ontbrekende informatie, vreemde leestekens, spelfouten of meertalige fragmenten.
 
- Historische regressiegevallen: Specifieke voorbeelden van invoer die in het verleden tot foutieve uitvoer, hallucinaties of verkeerde formaten hebben geleid.
 

 
 Praktijktip: Bouw je testset continu uit op basis van geanonimiseerde productielogs. Zodra een gebruiker een foutmelding rapporteert of een antwoord als 'slecht' beoordeelt, voeg je die specifieke invoer toe aan de testset.

 

 
## Wat leg je vast per testgeval?

 Bij traditionele softwaretests vergelijk je de uitvoer vaak met een exacte verwachte waarde. Bij LLM's is dat zelden mogelijk of wenselijk, omdat het model hetzelfde concept op tientallen verschillende manieren kan formuleren. In plaats van een vastgesteld antwoord, leg je per testgeval het volgende vast:

 
 
- De exacte invoer: Alle variabelen die in de prompt worden ingevuld (bijvoorbeeld gebruikersvraag, systeemcontext, opgehaalde documenten).
 
- Verwachte eigenschappen van de uitvoer: Welke structurele of inhoudelijke elementen moeten aanwezig zijn? Denk aan het bevatten van specifieke sleutelwoorden, een bepaalde toon, of een maximaal aantal woorden.
 
- Kritieke uitsluitingen: Wat mag er absoluut niet in de uitvoer voorkomen (bijvoorbeeld interne jargontermen, gevoelige data of aannames die niet in de context staan)?
 

 
## Harde checks versus zachte oordelen

 Het beoordelen van de uitvoer van een prompt vereist een combinatie van geautomatiseerde, deterministische controles en meer kwalitatieve evaluaties.

 
 
 
 Type evaluatie | 
 Methode | 
 Voorbeelden van criteria | 
 

 
 
 
 Harde checks (Geautomatiseerd) | 
 Code-gebaseerde validatie (Python/TypeScript) | 
 Geldige JSON-structuur, aanwezigheid verplichte velden, lengterestricties, afwezigheid verboden woorden. | 
 

 
 Zachte oordelen (Kwalitatief) | 
 Model-as-a-Judge of menselijke steekproef | 
 Mate van relevantie, beleefdheid van de toon, juistheid van de samenvatting vergeleken met de bron tekst. | 
 

 
 

 
### Harde geautomatiseerde checks

 Harde checks worden uitgevoerd met standaard programmalogica. Ze zijn goedkoop, snel en draaien zonder enige twijfel. Als een prompt een antwoord in een specifiek formaat moet opleveren, helpt het om technieken voor [output-formaten afdwingen](/output-formaten-afdwingen) toe te passen. De test controleert vervolgens simpelweg of de output door een parser zoals JSON.parse() of een Pydantic-model komt.

 // Voorbeeld van een geautomatiseerde harde check op prompt-output
function valideerOutput(rawOutput) {
 try {
 const parsed = JSON.parse(rawOutput);
 
 // Check op verplichte velden
 if (!parsed.samenvatting || !parsed.categorie) {
 return { success: false, reason: "Verplichte velden ontbreken" };
 }
 
 // Check op lengterestrictie
 if (parsed.samenvatting.length > 500) {
 return { success: false, reason: "Samenvatting overschrijdt maximale lengte" };
 }

 return { success: true };
 } catch (e) {
 return { success: false, reason: "Ongeldige JSON structuur" };
 }
}

 
### Zachte kwalitatieve oordelen

 Voor zaken als 'helderheid' of 'correctheid' volstaan regelgebaseerde checks niet. Hier zet je vaak een sterker model in als beoordelaar (LLM-as-a-Judge) met een hele specifieke beoordelingsprompt, of laat je het team steekproefsgewijs beoordelen. Dit proces verloopt gestroomlijnder wanneer het team duidelijke afspraken heeft gemaakt over [prompts reviewen in het team](/prompts-reviewen-in-team).

 
## Omgaan met variantie: meerdere runs draaien

 Omdat een LLM niet-deterministisch is, geeft één enkele testronde over je testset een onvolledig beeld. Een prompt kan toevallig 100% scoren op de testset, maar bij een tweede poging op 15% van de gevallen falen vanwege licht afwijkende woordkeuzes.

 Laat kritieke testgevallen daarom altijd meerdere keren draaien (bijvoorbeeld 3 tot 5 keer per invoer). Bereken vervolgens het slagingspercentage per testgeval. Een testgeval slaagt pas wanneer het in minstens 80% of 90% van de runs aan alle harde checks voldoet. Dit brengt de zogenaamde 'flakiness' van je prompt helder aan het licht.

 
## A/B-testen: de nieuwe variant naast de oude zetten

 Beoordeel een nieuwe prompt nooit op zichzelf. De cruciale vraag is namelijk niet alleen: "Is de nieuwe prompt goed?", maar vooral: "Is de nieuwe prompt beter dan de versie die nu live staat, zonder dat we regressie veroorzaken?"

 Draai de volledige testset door zowel de huidige productieprompt (Variant A) als de voorgestelde prompt (Variant B). Vergelijk de resultaten direct naast elkaar op hetzelfde niveau van invoer. Binnen ons netwerk kun je hiervoor gebruikmaken van de interactieve prompt A/B-test tool op [https://benchmark.llmnet.nl/](https://benchmark.llmnet.nl/prompt-ab-test-tool) om twee varianten gestructureerd naast elkaar te scoren en prestatieverschillen in kaart te brengen.

 
## Het afspreken van een acceptatiedrempel

 Voordat je de testresultaten analyseert, moet het team een duidelijke acceptatiedrempel (threshold) hebben vastgesteld. Dit voorkomt dat discussies over het wel of niet live gaan gestuurd worden door onderbuikgevoelens.

 Een realistisch acceptatiekader bevat bijvoorbeeld de volgende regels:

 
 
- 0% tolerantie voor kritieke regressie: Gevallen die eerder een foutsituatie veroorzaakten en zijn opgelost, mogen onder geen beding opnieuw falen.
 
- >98% succes op harde checks: Formatfouten of ontbrekende verplichte velden mogen vrijwel niet meer voorkomen.
 
- Geen achteruitgang op de algemene score: De gemiddelde kwalitatieve score over de totale testset moet gelijk blijven of stijgen ten opzichte van de huidige productieversie.
 

 
## Gefaseerde uitrol en het terugrolplan

 Zelfs de meest uitgebreide testset deekt nooit 100% van de werkelijkheid af. Wanneer een promptwijziging de acceptatiedrempel haalt, is direct uitrollen naar 100% van de gebruikers nog steeds een risico.

 Pas daarom een gefaseerde uitrol (canary release) toe:

 
 
- Stuur eerst 5% tot 10% van het live verkeer naar de nieuwe promptversie.
 
- Monitor gedurende deze fase actief op foutmeldingen, verhoogde latency, of een piek in het aantal herkansingen (retries).
 
- Schaal bij een stabiel beeld geleidelijk op naar 25%, 50% en uiteindelijk 100%.
 

 
 Essentieel: Zorg dat je applicatiecode voorbereid is op een snelle 'rollback'. Omdat een prompt los van de applicatiecode versiebeheer moet kennen, moet je via een configuratiewijziging binnen enkele seconden kunnen terugschakelen naar de vorige promptversie zonder dat er een nieuwe code-deploy nodig is.

 

 
## Checklist voor de review van een promptwijziging

 Gebruik deze compacte checklist voordat een promptwijziging de status 'production ready' krijgt:

 
 
- [ ] Testset bijgewerkt: Zijn er eventuele nieuwe randgevallen toegevoegd aan de evaluatieset?
 
- [ ] Harde checks gedraaid: Voldoet de uitvoer 100% aan de verwachte formaten (JSON, schema's, velden)?
 
- [ ] Meerdere runs uitgevoerd: Is de testset minimaal 3 keer gedraaid om variantie/flakiness te testen?
 
- [ ] A/B-vergelijking voltooid: Presteert de nieuwe variant aantoonbaar beter dan de huidige productieprompt?
 
- [ ] Geen regressie: Werken alle eerder opgeloste randgevallen nog steeds correct?
 
- [ ] Acceptatiedrempel gehaald: Voldoet de geaggregeerde score aan de vooraf afgesproken normen?
 
- [ ] Terugrolplan gereed: Kan de applicatie met één knopdruk terug naar de vorige prompt-ID?