Prompt engineering voor productie: wat werkt en wat is mythe

Toen we voor het eerst een LLM in een productieomgeving bij een maakbedrijf uitrolden, duurde het drie weken voordat we begrepen waarom het model soms in het Engels antwoordde in plaats van het Nederlands, waarom het de opmaak negeerde en waarom het in één op de tien gevallen een getal uit de lucht verzon. Alle drie de problemen hadden dezelfde oplossing: een systematische aanpak van prompts — niet op gevoel, niet trial-and-error, maar een bewezen structuur.

Prompt engineering is tegenwoordig een van de meest genoemde, maar ook minst goed begrepen disciplines in AI-projecten. Als we technisch directeuren vragen wat ze ervan verwachten, zegt de meerderheid "betere antwoorden". Dat klopt — maar slechts tot op zekere hoogte. Dit artikel legt uit wat prompt engineering werkelijk kan, waar de grenzen liggen en wat thuishoort in een ander gereedschapskader.

Wat prompt engineering werkelijk is

Prompt engineering is het systematisch ontwerpen en versiebeheren van invoer voor een taalmodel, met als doel consistente, voorspelbare en meetbare uitvoer te produceren. Het sleutelwoord is consistent — niet "soms uitstekend".

In een productiesysteem is het niet voldoende dat een prompt in 80 % van de gevallen werkt. Als u hem inzet voor klantenservice, herinneren klanten zich die 20 % fouten. Als u hem inzet voor het verwerken van facturen, is 20 % fouten een ramp. Prompt engineering gaat dus minder over creativiteit en meer over ingenieursmatige discipline: documenteren, versiebeheer, testen, meten.

Wat werkt — bewezen patronen

1. Een duidelijke instructie met een expliciet uitvoerformaat

De grootste individuele invloed op de uitvoerkwaliteit is hoe precies het model weet wat het moet produceren. Een vage instructie als "vat dit document samen" geeft vage resultaten. Een specifieke instructie werkt dramatisch beter:

• Vertel het model wie het doelpubliek van de uitvoer is
• Definieer het precieze formaat: aantal opsommingspunten, maximale lengte, of de uitvoer een conclusie moet bevatten of niet
• Gebruik bij gestructureerde data altijd structured outputs en JSON mode — een model dat aan een schema gebonden is, hallucineert aanzienlijk minder dan een model met vrije tekstuitvoer

We hebben bij klanten gezien dat alleen al de overgang van "extraheer gegevens uit de factuur" naar "geef een JSON-object terug met velden: leverancier (string), BTW-nummer (string 8 tekens), bedrag (getal), datum (ISO 8601)" de extractiefout率 met tientallen procenten verminderde.

2. Few-shot voorbeelden — wanneer en hoe te gebruiken

Few-shot prompting (enkele invoer-uitvoervoorbeelden direct in de prompt) is een van de meest betrouwbare technieken, maar alleen als de voorbeelden representatief zijn. De regels:

1. 1.Voorbeelden moeten edge cases dekken, niet alleen het happy path
2. 2.De opmaak van de voorbeelden moet consistent zijn — als u de ene keer "Invoer:" schrijft en een andere keer "Input:", merkt het model dat
3. 3.Het aantal voorbeelden hangt af van de complexiteit van de taak — voor eenvoudige classificatie volstaan 2–3, voor meerstapsredenering 5–7
4. 4.Kies voorbeelden uit echte data, niet verzonnen — synthetische voorbeelden hebben vaak andere statistische eigenschappen dan productie-invoer

Few-shot is bijzonder krachtig bij opmaak en bij taken met een duidelijke voorbeeldstructuur. Het is minder effectief bij kennis waarvoor het model de domeincontext mist — daar is RAG of fine-tuning het antwoord.

3. Rol en persona

Het expliciet toewijzen van een rol werkt — niet omdat het model zou "geloven" dat het iemand anders is, maar omdat een rol de kansenverdeling van uitvoer verschuift naar relevantere patronen. "U bent een senior jurist gespecialiseerd in Nederlands arbeidsrecht" activeert andere taalpatronen dan "U bent een assistent".

Belangrijk: een rol bepaalt toon en woordenschat, maar vervangt geen kennis. Een model met de rol "expert in ATEX-richtlijnen" kan nog steeds hallucинeren als het onvoldoende trainingsdata over ATEX-richtlijnen heeft. Een rol is een taalfilter, geen kennisdatabase.

4. Stappen koppelen (Chain-of-Thought)

Bij complexe analytische taken — vergelijken, meerstapsberekeningen, besluitvorming op basis van voorwaarden — verbetert de expliciete instructie "werk stap voor stap" of het opsplitsen in meerdere subprompts de betrouwbaarheid aanzienlijk. Modellen maken minder fouten als ze "hardop kunnen denken" voordat ze een eindantwoord geven.

In de praktijk betekent dit: vraag het model niet direct om een conclusie. Laat het eerst het probleem uiteenleggen, de relevante factoren identificeren en pas daarna een conclusie formuleren. Het resultaat is betrouwbaarder en bovendien gemakkelijker te controleren — u ziet hoe het model tot zijn conclusie is gekomen.

5. Negatieve instructies — wat niet te doen

De meeste prompts vertellen het model wat het moet doen. Even belangrijk is aangeven wat het niet moet doen. "Begin nooit een antwoord met de zin 'Natuurlijk!'", "Gebruik geen Engelse woorden waar een Nederlands equivalent bestaat", "Als u niet kunt antwoorden op basis van de aangeboden context, zeg dat dan expliciet — gok niet." Negatieve instructies verminderen het voorkomen van specifieke terugkerende fouten.

Wat niet werkt — mythen

Mythe 1: "Alstublieft" en beloningen verbeteren de resultaten

Kort antwoord: nee. Uitdrukkingen als "voor elk correct antwoord krijgt u 100 dollar" of het beleefde "alstublieft, help me met..." hebben geen meetbaar effect op de kwaliteit van productie-uitvoer. Het model reageert niet op sociale manipulatie of emoties — het reageert op statistische patronen in trainingsdata. Tijd besteed aan het "motiveren" van het model is verspilde tijd.

Mythe 2: Een langere prompt = een beter resultaat

Lengte en kwaliteit zijn twee verschillende dingen. We hebben systeemprompts met duizenden tokens gezien die slechter werkten dan een tekst van vijf regels. Het probleem is dat modellen de neiging hebben instructies te "verliezen" die midden in een zeer lange context staan — een effect dat "lost in the middle" wordt genoemd. Structuur en duidelijkheid zijn belangrijker dan volume. Als uw prompt groeit, is dat eerder een teken dat u probeert een probleem met een prompt op te lossen dat thuishoort in het systeemontwerp.

Mythe 3: Een goede prompt vervangt een eval

Dit is waarschijnlijk de gevaarlijkste mythe. Een prompt zonder evaluatie is een hypothese, geen oplossing. In de praktijk zien we teams die een week besteden aan het verfijnen van een prompt, hem in productie zetten en een maand later ontdekken dat 15 % van de uitvoer incorrect is — omdat ze nooit systematisch hebben gemeten.

Eval — geautomatiseerde beoordeling van uitvoer op een testset — is een voorwaarde voor productie-inzet, geen optionele aanvulling. Meer hierover in hoe u de kwaliteit van een LLM-applicatie meet.

Mythe 4: Prompt engineering is een permanente oplossing

Een prompt is een broos artefact. Wanneer een provider een nieuwe modelversie uitbrengt, kan uw prompt zich anders gedragen — ook al heeft u hem niet gewijzigd. We hebben gevallen gezien waarbij een modelupdate de algemene kwaliteit verbeterde, maar specifieke opmaakInstructies brak die waren "vastgekleefd" aan het gedrag van de oudere versie.

Prompt engineering is iteratief werk, geen eenmalige activiteit. Als u dat niet inziet vóór de inzet, komt u daar na de inzet achter.

Mythe 5: De systeemprompt is een veilige container voor gevoelige informatie

De systeemprompt is voor het model een instructie, geen kluis. Prompt extraction (het extraheren van de inhoud van de systeemprompt) is een goed gedocumenteerde aanval — er bestaan technieken waarmee een aanvaller de inhoud van de systeemprompt via de normale gebruikersinterface uit het model kan trekken. In de systeemprompt horen nooit thuis: wachtwoorden, API-sleutels, interne prijslijsten, persoonsgegevens van medewerkers of welke informatie dan ook waarvan een lek een probleem zou zijn. In de systeemprompt horen gedragsinstructies, geen geheimen.

Prompt als code — versiebeheer en beheer

In teams waarmee we werken, duikt steeds hetzelfde probleem op: de prompt staat als hardcoded string in de code, niemand weet wie hem voor het laatst heeft gewijzigd en waarom, en als er iets misgaat is er geen geschiedenis om op terug te vallen.

Een prompt is code. Dezelfde principes gelden:

• Versiebeheer in git — elke wijziging aan een prompt is een commit met een betekenisvolle commit message
• Semantische versiebeheer — major versie bij een wijziging die het uitvoergedrag verandert; minor bij aanvulling; patch bij spellingscorrectie
• Testset — bij elke versie van de prompt bestaat een set testgevallen met verwachte uitvoer; een promptwijziging slaagt alleen als de tests groen zijn
• Promptregister — een centrale plek (kan een eenvoudig YAML-bestand in de repo zijn, of een tool zoals Langfuse) waar zichtbaar is welke prompt waar is ingezet, in welke versie en wie de eigenaar is

Tools zoals Promptfoo maken automatisch testen van prompts in een CI/CD-pipeline mogelijk — elke pull request met een promptaanpassing start automatisch de testset vóór de merge. Dit is een praktijk die we aanbevelen aan elk team dat meer dan één actieve prompt in productie heeft.

Wanneer een prompt niet volstaat — en wat dan

Prompt engineering is een krachtig gereedschap binnen een beperkt probleemdomein. Het schiet tekort waar:

Kennis ontbreekt — het model weet niet wat het moet weten, omdat dat niet in de trainingsdata staat. Een prompt kan geen kennis toevoegen. Oplossing: RAG (retrieval-augmented generation) voor feitelijke ondersteuning, of fine-tuning voor diepe domeinadaptatie.

Een consistent formaat ontbreekt — de uitvoer moet altijd een exact schema volgen. Een prompt kan helpen, maar de betrouwbaardere oplossing is structured outputs (JSON schema gebonden aan het model). Meer in het artikel over structured outputs en JSON mode.

Beveiliging ontbreekt — als het systeem niet-vertrouwde invoer verwerkt (bijv. klantenberichten, externe documenten), is prompt injection een reëel risico. Een prompt kan zijn eigen overschrijving niet voorkomen. U heeft architecturale guardrails nodig — validatie van invoer, allowlists voor acties, sandboxing. Meer detail in het artikel over prompt injection en jailbreaks.

Meting ontbreekt — als u niet weet of de prompt werkt, is prompt engineering slechts gissen. Vertrouw zelfs een uitstekende prompt niet zonder eval.

Praktisch versiebeheer van prompts — hoe te beginnen

Voor teams die nog geen systematisch promptbeheer hebben, raden we een eenvoudige aanpak aan:

1. 1.Maak een map prompts/ aan in de repository met één YAML-bestand per prompt
2. 2.Elk YAML-bestand bevat: name, version, description, system_prompt, user_prompt_template, model, temperature, test_cases
3. 3.Wijzigingen via pull request — review van de prompt net als review van code
4. 4.Vóór het inzetten van een nieuwe versie: voer de testset uit op de huidige én de nieuwe versie en vergelijk de metrics
5. 5.Na inzet: monitor de resultaten in productie; anomalieën (plotselinge toename van fouten, gewijzigde uitvoerlengte) zijn een teken van regressie

Dit is geen overkill — het is het minimum. Teams die dit niet doen, ontdekken problemen in productie in plaats van tijdens het testen.

Prompt engineering en modellen — wat verandert met het model

Een belangrijk aspect dat we vaak genegeerd zien: verschillende modellen reageren anders op dezelfde prompt. Een prompt die geoptimaliseerd is voor één model kan aanzienlijk slechter werken op een ander. Een paar concrete patronen:

• Instruction following: nieuwere frontier-modellen (Claude, GPT-4-klasse) volgen expliciete instructies aanzienlijk beter op dan oudere of kleinere modellen
• Few-shot gevoeligheid: sommige modellen reageren sterk op few-shot voorbeelden, andere minder — afhankelijk van grootte en trainingsproces
• Taalkwaliteit: Nederlands is een relatief goed vertegenwoordigde taal; frontier-modellen verwerken hem goed, kleinere open-weight modellen kunnen degraderen — test altijd in de doeltaal
• Temperature: stel bij deterministische taken (extractie, classificatie) temperature=0 in of zeer laag — de uitvoer wordt consistenter; bij generatieve taken (schrijven) iets hoger

Wanneer u van model wisselt, voer dan altijd de bestaande testset uit. Ga er niet vanuit dat de prompt "hetzelfde werkt".

Veelgestelde vragen

Is het de moeite waard om tijd te investeren in prompt engineering, of kan ik beter meteen fine-tunen?

Prompt engineering is de eerste stap, fine-tuning is de volgende — geen alternatief. Als u een goed ontworpen prompt heeft en nog steeds niet tevreden bent met de resultaten ondanks few-shot voorbeelden en structuur, onderzoek dan of het probleem niet ligt in ontbrekende domeinkennis (oplossing: RAG) of in de consistentie van de uitvoerstijl (oplossing: fine-tuning). Fine-tuning zonder een goed ontworpen prompt en zonder eval is verspilde tijd en geld.

Kan ik prompt engineering gebruiken om te garanderen dat het model nooit op bepaalde onderwerpen antwoordt?

Niet betrouwbaar. Prompt-only-verdedigingen (instructie "antwoord nooit op X") zijn te omzeilen — dat is de belangrijkste conclusie van onderzoek naar prompt injection en jailbreaking. Voor productiesystemen zijn architecturale maatregelen onmisbaar: filteren van invoer vóór doorgave aan het model, validatie van uitvoer vóór weergave, monitoring. De instructie in de prompt is de eerste laag, niet de enige.

Hoe weet ik of mijn prompt goed is?

Alleen via meting. Definieer een testset van gevallen (minimaal 20–50 voor een eenvoudige taak, meer voor complexe) met verwachte uitvoer of beoordelingscriteria. Voer de prompt op de testset uit en meet de relevante metric (nauwkeurigheid, opmaak, taalcorrectheid, feitelijke juistheid). Zonder een getal is "een goede prompt" slechts een gevoel.

Hoeveel tokens zou de systeemprompt moeten bevatten?

Er is geen universeel antwoord, maar in de praktijk zien we dat effectieve systeemprompts doorgaans in de range van 200–800 tokens liggen. Kortere zijn onvoldoende specifiek, langere beginnen last te krijgen van het "lost in the middle"-effect — het model verliest het spoor van instructies die midden in de context staan. Als uw prompt de duizend tokens overschrijdt zonder duidelijke reden, is het tijd om hem te refactoren of na te denken of sommige informatie niet thuishoort in de RAG-context in plaats van de systeemprompt.

Gelden dezelfde principes voor lokaal uitgereden open-weight modellen?

De meeste principes gelden, maar met een belangrijke kanttekening: kleinere open-weight modellen (7B–13B parameters) zijn minder robuust in het opvolgen van instructies dan frontier-modellen. Few-shot voorbeelden zijn belangrijker, de opmaak van de prompt moet nauwkeuriger zijn en de testset moet worden aangepast aan de specifieke modelfamilie. Een prompt ontworpen voor frontier-modellen werkt mogelijk niet hetzelfde op Mistral 7B of vergelijkbaar grote open-weight modellen — ook niet na zorgvuldige optimalisatie. Bovendien vormt de doeltaal een extra uitdaging voor kleinere modellen — test altijd in de productietaal.

*Prompt engineering is een ambacht, geen magie — en zoals elk ambacht is het te leren, te systematiseren en te meten. Als u LLM-inzet in productie aanpakt en niet zeker weet waar u moet beginnen, beoordelen we graag uw concrete geval en helpen we de basis te leggen waarop verder gebouwd kan worden.*