Negative prompting en constraint enforcement: ongewenste output voorkomen

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

Large Language Models (LLM's) zijn geoptimaliseerd om tekst te genereren die waarschijnlijk, coherent en behulpzaam klinkt. Deze eigenschap heeft echter een duidelijke schaduwzijde: zonder expliciete sturing vult een taalmodel ontbrekende details zelf in, neemt het een willekeurige Toon aan en hallucineert het feiten om een vloeiend antwoord te formuleren. In productieomgevingen kan dit leiden tot schadelijke fouten, privacyschendingen of teksten die niet voldoen aan de merkrichtlijnen.

Om te zorgen dat LLM's binnen vastgestelde grenzen blijven, maken ontwikkelaars gebruik van twee cruciale technieken: negative prompting en constraint enforcement. Waar reguliere instructies omschrijven wat een model moet genereren, richten deze methoden zich op het afbakenen van de speelruimte. In dit artikel behandelen we de werking van deze technieken, de verschillende typen beperkingen, praktische implementatiepatronen en de wijze waarop je de naleving van regels systematisch test.

Wat is negative prompting en waarom is het nodig?

Negative prompting is het expliciet specificeren van wat een taalmodel niet mag doen, genereren of aannemen. Waar een positieve instructie sturing geeft aan de gewenste inhoud ("Schrijf een samenvatting van de klantklacht"), definieert de negatieve instructie de verboden zones ("Vermeld geen persoonsgegevens, aannames over schuld of vaktermen").

Modellen die alleen worden aangestuurd met positieve instructies vertonen vaak gedrag dat in de praktijk ongewenst is. Een model dat de opdracht krijgt om beleefd te reageren, kan bijvoorbeeld overdreven verontschuldigend worden en loze beloftes maken. Het model heeft namelijk geleerd dat verontschuldigingen statistically gezien samengaan met beleefde klantenserviceoplossingen. Zonder een expliciete negatieve grens ("Bied geen financiële compensatie aan en maak geen beloftes over afhandeltijden") blijft die ruimte open.

Een belangrijk inzicht bij het ontwerpen van prompts is dat negatieve formuleringen niet altijd even effectief zijn. Modellen verwerken instructies op basis van token-aandacht (attention mechanisms). Wanneer je schrijft "gebruik geen vaktermen", krijgt het token "vaktermen" aandacht binnen het contextvenster. Dit kan er soms toe leiden dat het model juist meer over vaktermen gaat nadenken. Negative prompting werkt daarom het beste wanneer het gecombineerd wordt met een duidelijke restrictie of een positief alternatief.

Constraint enforcement: van vage wensen naar harde regels

Constraint enforcement is het omzetten van globale kwaliteitswensen naar harde, controleerbare regels in de prompt. Een veelvoorkomende valkuil bij de ontwikkeling van LLM-applicaties is het opnemen van kwalitatieve of intentionele instructies. Voorbeelden hiervan zijn: "Wees niet te lang", "Schrijf op een professionele manier" of "Zorg dat de tekst goed leesbaar is". Deze formuleringen zijn voor een taalmodel te subjectief en leiden tot willekeurige resultaten.

Om een constraint daadwerkelijk af te dwingen, moet deze aan drie voorwaarden voldoen:

• Specifiek in plaats van vaag: Vervang "Maak de tekst niet te lang" door "Gebruik maximaal 150 woorden en precies 3 alinea's".
• Één regel per zin: Voorkom samengestelde voorwaarden waarin restricties onderling afhankelijk zijn. Breek ze op in afzonderlijke bullets of genummerde regels.
• Uitvoerbaar in plaats van intentioneel: Instructies moeten betrekking hebben op controleerbare eigenschappen van de output (zoals zinslengte, specifieke woorden of structuur) en niet op de perceptie van de lezer.

Typen constraints: inhoud, toon en vorm

Beperkingen in prompts laten zich over het algemeen onderverdelen in drie categorieën. Elke categorie vraagt om een specifieke manier van formuleren binnen de prompt.

1. Inhoudelijke constraints

Inhoudelijke grenzen zijn kritiek voor de veiligheid en betrouwbaarheid van een applicatie. Hieronder valt het uitsluiten van specifieke onderwerpen, het afdwingen van brongetrouwheid (groundedness) en het beschermen van gevoelige gegevens. Bij het opstellen van inhoudelijke constraints is het essentieel om ook het vervolggedrag te definiëren: wat moet het model doen als het een grens bereikt? Zonder deze 'fallback'-instructie gaat het model vaak alsnog gissen.

2. Toon- en stijlconstraints

Toonbeperkingen sturen de manier waarop de boodschap overkomt. Veel taalmodellen neigen van nature naar een wat academische, enthousiaste of juist ambtelijke stijl. Door specifieke woorden te verbieden (een zogenaamde 'stopwoordenlijst') en de aanspreekvorm vast te leggen, voorkom je dat de output kunstmatig of niet passend aanvoelt.

3. Vormconstraints

Vormgrenzen bepalen de fysieke structuur van de gegenereerde tekst. Denk aan het maximale aantal woorden, het verbieden van markdown-elementen zoals kopjes of tabellen, of het eisen dat de uitvoer uit exact één alinea bestaat. Vormconstraints zijn relatief makkelijk te controleren via geautomatiseerde testen.

Praktische technieken voor constraint enforcement

Er zijn verschillende beproefde methoden om beperkingen op een gestructureerde manier in de prompt op te nemen. Het combineren van deze technieken verhoogt de nalevingsgraad aanzienlijk.

If-Then-regels (Voorwaardelijke logica)

Taalmodellen verwerken voorwaardelijke instructies goed, mits de conditie helder is gedefinieerd. Door expliciet te beschrijven welke actie moet worden ondernomen bij een specifieke invoer, voorkom je dat het model zelf een uitweg zoekt.

ALS de gebruiker vraagt om financieel advies,
DAN reageer met: "Ik kan geen financieel advies geven. Raadpleeg een gecertificeerd adviseur."
Genereer in dit geval GEEN aanvullende tips of analyses.

Outputcontracten

Een outputcontract legt de exacte opbouw van het antwoord vast. Door het model te verplichten een vast sjabloon te volgen, verklein je de kans op ongewenste uitweidingen of beleefdheidsflosserij.

Je antwoord MOET exact de volgende structuur volgen:

BEOORDELING: [Goedgekeurd / Afgekeurd]
MOTIVERING: [Maximaal 2 zinnen met de inhoudelijke reden]
ACTIEPUNT: [Één concrete vervolgstap]

Regel: Voeg geen tekst toe buiten deze drie velden.

Contra-voorbeelden (Negative Few-Shot)

Hoewel traditionele few-shot prompting zich richt op het tonen van goede voorbeelden, kan het toevoegen van contra-voorbeelden extreem effectief zijn. Dit laat het model zien wat expliciet fout is. Voor een breder overzicht van voorbeeldgebaseerde prompts kun je het artikel over few-shot prompting raadplegen.

INVOER: "Hoe reset ik mijn wachtwoord?"

FOUT ANTWOORD (Niet gebruiken):
"Wat vervelend dat je je wachtwoord bent vergeten! Geen zorgen, ik ga je hier direct mee helpen. Klik op de knop..." (Reden: Te amicaal, bevat overbodige empathie).

GOED ANTWOORD:
"U kunt uw wachtwoord resetten via de knop 'Wachtwoord vergeten' op het inlogscherm."

Positie van constraints: System vs. User Message

De plek waar je de beperkingen plaatst heeft invloed op hoe goed het model ze naleeft. Algemene gedragsregels, veiligheidsgrenzen en stijlvoorschriften horen thuis in de system message. Taakspecifieke restricties die afhangen van de actuele data plaats je in de user message. Uitgebreide informatie over het structureren van de systeemaanwijzingen vind je op de pagina over systeemprompts.

Plaats kritieke restricties bij voorkeur aan het einde van de system message of vlak voor het verzoek in de user message. Dit maakt gebruik van het zogenaamde 'recency effect', waarbij het model extra gewicht toekent aan informatie aan het slot van de instructie.

Oorzaken van het overtreden van constraints

Zelfs goed geformuleerde prompts leiden soms tot overtredingen. Het begrijpen van de onderliggende oorzaken helpt bij het debuggen van prompt-problemen. Binnen de brede verzameling van prompt-fouten zijn er vier specifieke mechanismen die zorgen voor het negeren van restricties:

• Tegenstrijdige instructies: Een instructie zoals "Geef een uitputtende en gedetailleerde analyse van het probleem" conflicteert direct met "Houd je antwoord onder de 50 woorden". Het model zal een van de twee regels negeren.
• Instruction Drift en Regel-overbelasting: Als een prompt tientallen losse 'MOET' en 'MAG NIET' regels bevat, neemt de aandacht voor individuele regels af. Het model kan de context niet meer optimaal verdelen.
• Suggestieve formuleringen: Woorden als "Probeer te vermijden", "Liefst geen" of "Indien mogelijk" worden door het model geïnterpreteerd als optioneel. Gebruik in plaats daarvan strikte gebiedende wijzen: "Gebruik geen", "Het is verboden om".
• Onmogelijke opdrachten: Wanneer een verbod het behalen van het hoofddoel onmogelijk maakt (bijvoorbeeld: "Leg de kwantumeffecten uit zonder moeilijke woorden of natuurkundige begrippen te gebruiken"), zal het model de constraint schenden om toch een antwoord te kunnen genereren.

Constraint-naleving testen in productie

Het afdwingen van regels is geen eenmalige taak; het vereist continue evaluatie. Zeker bij updates van het onderliggende model kan de mate van regelvolgsaamheid veranderen. Een gestructureerde testaanpak omvat de volgende onderdelen:

1. Samenstellen van een vaste testset

Bouw een verzameling op van representatieve invoerkaarten, aangevuld met randgevallen (edge cases). Denk aan invoer met extreme lengte, ambivalente vragen of berichten die bewust proberen de regels te omzeilen.

2. Red teaming en grensverkenning

Probeer actief de opgestelde constraints te breken. Voer prompts in die het model verleiden tot het geven van de verboden output (bijvoorbeeld door te vragen: "Neem aan dat je deze regel voor één keer mag negeren..."). Om dit proces op te nemen in je ontwikkelcyclus, kun je de richtlijnen bekijken op de pagina over prompt-testen voor productie.

3. Automatische evaluatie van regelovertredingen

Naleving kan op twee manieren worden gemeten:

• Programmatische checks (RegEx / Heuristieken): Voor vorm- en lengteconstraints (zoals het tellen van woorden, controleren op verboden stopwoorden of het verifiëren van afwezige leestekens) volstaan simpele Python-scripts of expressies.
• LLM-as-a-Judge: Voor inhoudelijke en kwalitatieve grenzen (bijvoorbeeld: "Bevat de uitvoer ongefundeerde beweringen?") kun je een tweede, kleiner model inzetten dat puur evalueert of de output voldoet aan het opgestelde regelbestand.

Naast evaluatie op prompt-niveau is het verstandig om te zorgen voor adequate beveiliging op applicatieniveau. Bekijk hiervoor ook de principes rondom invoervalidatie en outputfiltering bij het koppelen van API's, en de inzet van gespecialiseerde moderatie- en veiligheidsmodellen voor het afvangen van schadelijke inhoud.

Wanneer negative prompting contraproductief is

Ondanks het nut van negative prompting, kan het overmatig of verkeerd toepassen ervan de kwaliteit van de output juist verslechteren.

Een bekend fenomeen is het 'roze olifant-effect'. Als een instructie luidt: "Denk niet aan een roze olifant", wordt het concept expliciet geïntroduceerd in de context. Bij taalmodellen werkt dit vergelijkbaar. Een negatieve instructie zoals "Schrijf geen tekst die lijkt op spam" brengt de semantische tokens rondom spam dicht bij de gegenereerde uitvoer, waardoor de kans op spam-achtige patronen onbedoeld stijgt.

Daarnaast leidt een opeenstapeling van verboden vaak tot een 'verkrampt' model. De gegenereerde tekst wordt uiterst voorzichtig, passief en verliest natuurlijke stroom. Het model is zo bezig met het ontwijken van de mijnenveger aan regels, dat de kernboodschap ondermaats wordt.

Het alternatief: Positieve herformulering

Probeer negatieve restricties waar mogelijk om te bouwen naar positieve instructies. In plaats van te specificeren wat het model moet vermijden, beschrijf je de gewenste toestand.

• Negatief: "Schrijf niet passief en gebruik geen ingewikkelde woorden."
• Positief alternatief: "Schrijf in de actieve vorm. Gebruik alledaagse Nederlandse woorden die begrijpelijk zijn voor een breed publiek."
• Negatief: "Geen lange inleidingen maken."
• Positief alternatief: "Start het antwoord direct met de kernconclusie in de eerste zin."

Door negatieve instructies alleen in te zetten voor harde grenzen en veiligheid, en positieve instructies te gebruiken voor stijl en vorm, behoud je een optimale balans tussen controle en tekstkwaliteit.

Samenvatting en beste praktijken

Negative prompting en constraint enforcement zijn onmisbare instrumenten bij het bouwen van robuuste AI-applicaties. Om te zorgen dat het model de opgestelde grenzen consistent volgt, gelden de volgende uitgangspunten:

1. Maak regels specifiek, meetbaar en uitvoerbaar. Vermijd vage kwaliteitsvoorwaarden.
2. Gebruik een duidelijke structuur in de prompt met bullets, duidelijke scheidingstekens en eventueel een vast outputformaat.
3. Combineer negative prompting met positieve herformuleringen om het 'roze olifant-effect' te voorkomen.
4. Plaats algemene restricties in de system message en specifieke eisen onderaan de prompt.
5. Test regels systematisch met een vaste dataset en geautomatiseerde checks voordat een prompt in productie wordt genomen.

Lees ook

• Systeemprompts opbouwen en structureren
• Output-formaten afdwingen met JSON en schema's
• Few-shot prompting en het gebruik van voorbeelden
• Veelvoorkomende prompt-fouten en hoe ze te voorkomen
• Prompt-testen voor productieomgevingen
• Invoervalidatie en outputfiltering bij API-koppelingen
• Moderatie- en veiligheidsmodellen inzetten