# Systeemprompt-drift herkennen en corrigeren | llmnet.nl

Deel:[𝕏](https://twitter.com/intent/tweet?url=https%3A//community.llmnet.nl/system-prompt-drift-identificatie&text=Systeemprompt-drift%20herkennen%20en%20corrigeren)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A//community.llmnet.nl/system-prompt-drift-identificatie)[Reddit](https://www.reddit.com/submit?url=https%3A//community.llmnet.nl/system-prompt-drift-identificatie&title=Systeemprompt-drift%20herkennen%20en%20corrigeren)[Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A//community.llmnet.nl/system-prompt-drift-identificatie)[Kopieer link](#)

# Systeemprompt-drift herkennen en corrigeren

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

Wanneer een applicatie gebaseerd op een Large Language Model (LLM) al langere tijd in productie draait, kan er een fenomeen optreden dat ontwikkelaars vaak verrast: de output van het systeem verandert, terwijl de broncode en de tekst van de systeemprompt volstrekt ongewijzigd zijn gebleven. Formaten breken, de toonzetting verschuift of uitzonderingen worden plotseling anders afgehandeld. Dit verschijnsel noemt men systeemprompt-drift.

Waar de basisprincipes van [systeemprompts](https://community.llmnet.nl/systeemprompts) zich richten op het formuleren van de initiële instructies, gaat dit artikel over wat er gebeurt in de periode daarna. Het tijdig onderkennen van drift en het isoleren van de precieze oorzaak is noodzakelijk om een softwaretoepassing stabiel te houden. Omdat gedragswijzigingen verschillende oorzaken kunnen hebben, leidt een foutieve diagnose vaak tot een verergering van het probleem.

Definitie: Systeemprompt-drift is het verschijnsel waarbij de effectieve werking van een systeemprompt in een LLM-toepassing in de loop van de tijd verandert, zonder dat de ontwikkelaar de instructie expliciet heeft aangepast.

## De vier bronnen van gedragsdrift

Om drift doeltreffend aan te pakken, moet je eerst vaststellen waar de verandering ontstaat. Gedragsveranderingen in LLM-toepassingen worden veroorzaakt door vier afzonderlijke factoren. Het is essentieel om deze bronnen van elkaar te scheiden, aangezien elke bron een volstrekt andere correctiestrategie vereist.

### 1. Het model achter de alias is stilzwijgend vervangen

Veel API-providers bieden generieke model-aliassen aan, zoals gpt-4o of claude-3-5-sonnet. Deze aliassen wijzen op de achtergrond niet naar een gefixeerde verzameling gewichten, maar naar een dynamische pointer die door de provider regelmatig wordt bijgewerkt. Wanneer een provider een kleine update doorvoert (bijvoorbeeld een aanpassing in de alignment, RLHF-fase of kwantisering), kan het model anders reageren op dezelfde instructies.

De subtiele verandering in de attentie-gewichten van het model kan ervoor zorgen dat specifieke randgevallen, die voorheen correct werden afgehandeld, ineens buiten de boot vallen. Zie voor een gedetailleerde analyse van dit mechanisme het artikel over [modelversies en deprecatie](https://hub.llmnet.nl/modelversies-en-deprecatie).

### 2. Systeemprompt-accumulatie (promptbloat)

In veel ontwikkelteams groeit een systeemprompt organisch. Zodra een gebruiker een foutieve reactie meldt, voegt een ontwikkelaar een extra regel instructie toe om die specifieke uitzondering af te vangen. Over een periode van maanden leidt deze aanpak tot een enorme tekstmassa. De prompt bevat dan tientallen regels met "Doe nooit X" of "Zorg dat Y altijd Z is". Deze opeenstapeling veroorzaakt onderlinge tegenstrijdigheden, waardoor het gedrag van het model onvoorspelbaar wordt.

### 3. Verandering in de omringende context (RAG en geschiedenis)

De systeemprompt staat nooit op zichzelf; hij maakt deel uit van de totale contextwindow die naar het model wordt gestuurd. Als de toepassingsarchitectuur gebruikmaakt van Retrieval-Augmented Generation (RAG), verandert de inhoud van de opgehaalde documenten voortdurend. Wanneer de opgehaalde documenten langer, chaotischer of anders gestructureerd worden, claimen zij een groter deel van de attentie van het model. Ook een langer wordende gespreksgeschiedenis oefent invloed uit op de mate waarin het model de oorspronkelijke systeemprompt volgt.

### 4. Verschuiving in het profiel van de gebruikersinvoer

Naarmate een applicatie langer live staat, veranderen het type gebruikers en hun query-patronen (distribution drift). Gebruikers ontdekken randgevallen, voeren kortere of juist langere vragen in, of gebruiken ander jargon. Een systeemprompt die uitstekend werkte voor de korte, gestructureerde vragen tijdens de testfase, kan bezwijken onder de complexe of dubbelzinnige invoer van een bredere gebruikersgroep.

Bron van drift | 
Symptoom in productie | 
Oorzaak | 
Primaire oplossing | 

Model-alias update | 
Plotselinge gedragsverandering zonder code-commit | 
Provider heeft de alias omnummerd naar een nieuw model-snapshot | 
Pin de exacte modelversie in de API-call | 

Promptbloat | 
Model negeert willekeurig regels of spreekt zichzelf tegen | 
Te veel losse regels en instructies verzameld over tijd | 
Prompt herbalanceren en uitzonderingen naar code verplaatsen | 

Contextverschuiving | 
Systeemprompt werkt slecht bij specifieke RAG-resultaten | 
Opgehaalde documenten domineren het attentiemechanisme | 
RAG-chunking aanpassen en context strikter scheiden | 

Invoerverschuiving | 
Toename van foutmeldingen bij nieuwe gebruikersgroepen | 
Gebruikersinvoer valt buiten de aannames van het ontwerp | 
Input-pre-processing toevoegen en toetsset uitbreiden | 

## De anatomie van promptbloat: het sluipende proces

Van de vier genoemde bronnen is promptbloat de meest voorkomende oorzaak die door het eigen team veroorzaakt wordt. Het proces verloopt bijna altijd volgens hetzelfde patroon. Een applicatie gaat live met een beknopte, heldere systeemprompt van 150 woorden. Binnen enkele weken stuiten gebruikers op een randgeval: het model genereert bijvoorbeeld Markdown-tabellen terwijl de frontend alleen platte tekst ondersteunt.

De snelste oplossing lijkt het toevoegen van een instructie: "Gebruik nooit Markdown-tabellen." Een week later stelt een gebruiker een vraag in het Frans, waarop het model in het Frans antwoordt, terwijl de applicatie uitsluitend Nederlands ondersteunt. De ontwikkelaar voegt toe: "Antwoord altijd strikt in het Nederlands."

Na verloop van tijd bestaat de systeemprompt uit tientallen ad-hoc regels. Het probleem van deze werkwijze is dat een LLM instructies verwerkt via waarschijnlijkheidsverdelingen en attentievectoren, niet via een klassieke 'if-then-else'-logica. Wanneer instructies beginnen te schuren, zoals "Wees uiterst beknopt" versus "Leg alle juridische nuances uit uit de meegeleverde context", kan het model niet beide regels voor honderd procent naleven. Het kiest op basis van de token-context willekeurig welke regel prioriteit krijgt. Dit leidt tot inconsistent gedrag dat door ontwikkelaars ten onrechte wordt aangezien voor onvoorspelbaarheid van het model zelf.

## Aandachtsverdeling en positie-effecten in lange prompts

Bij het analyseren van een te lange systeemprompt moet rekening worden gehouden met de manier waarop de Transformer-architectuur tokens verwerkt. Niet elke positie in de contextwindow krijgt evenveel attentie. Twee bekende verschijnselen spelen hierbij een rol:

- Primacy-effect: Instructies die helemaal aan het begin van de systeemprompt staan, hebben een sterke invloed op de algemene rol, de identiteit en de kaders van de reactie.

- Recency-effect: Instructies die aan het einde van de prompt staan (vlak voor de gebruikersinvoer of context), worden relatief goed onthouden bij het genereren van de eerste output-tokens. Dit is de beste plek voor harde opmaakeisen, zoals output-formaten (JSON of XML).

- Lost in the Middle: Informatie en instructies die in het midden van een lange prompt zijn weggestopt, ondervinden een lagere attentiedichtheid. Wanneer een systeemprompt meer dan enkele honderden tokens beslaat, verwateren de regels die zich in dit middengebied bevinden.

Wanneer ontwikkelaars bij elk incident simpelweg een nieuwe regel onderaan het middenstuk plakken, drukken zij bestaande regels dieper het "moeras" van het middengebied in. Een regel die voorheen goed werkte omdat hij onderaan stond, verliest aan effectiviteit zodra er vijf nieuwe regels onder geplaatst worden.

## Drift zichtbaar maken voor productie

Om te voorkomen dat gedragsveranderingen pas worden opgemerkt via klachten van gebruikers, moet drift meetbaar worden gemaakt. Dit vereist een geautomatiseerde monitoringsaanpak die continu meeloopt. Voor de technische inrichting van deze monitoring verwijzen we naar het artikel over [observability en logging](https://api.llmnet.nl/observability-en-logging).

### 1. Een vaste, representatieve toetsset

Het bouwen van een vaste set van bijvoorbeeld 50 tot 100 representatieve prompts is de meest effectieve manier om drift te detecteren. Deze dataset bevat een mix van standaardvragen, complexe vragen en bekende randgevallen. Bij elke beoogde wijziging in de prompt, maar ook via een periodieke geautomatiseerde test (bijvoorbeeld nachtelijk), wordt deze dataset afgevoerd naar het model.

Voor de inhoudelijke opzet van dergelijke testruns kun je gebruikmaken van de principes beschreven in [regressietesten voor prompts](https://benchmark.llmnet.nl/regressietesten-prompts) en de methodiek voor [prompts testen voor productie](https://community.llmnet.nl/prompt-testen-voor-productie).

### 2. Monitoring van stabiele indicatoren

Naast inhoudelijke evaluatie (die vaak een tweede LLM als beoordelaar vereist) zijn er vier kwantitatieve indicatoren die direct wijzen op drift:

- Formaatgeldigheid (Format Validity): Het percentage antwoorden dat correct kan worden geparsed door de applicatie (bijvoorbeeld valide JSON-structuur of het aanwezig zijn van verplichte tags). Een daling in deze score wijst op opmaakdrift.

- Lengteverdeling van de output: Houd het gemiddelde aantal gegenereerde tokens en de standaarddeviatie bij. Een plotselinge stijging of daling in de gemiddelde antwoordlengte is een betrouwbare indicator van veranderd gedrag.

- Weigerpercentage (Refusal Rate): Het percentage antwoorden waarin het model weigert de opdracht uit te voeren (bijvoorbeeld door overmatige veiligheidstriggers na een model-update).

- Parser-pass-rate: Het percentage waarin de downstream-code zonder foutmeldingen of retries de output van het LLM verwerkt.

### 3. Steekproeven uit de productiestroom

Nachtelijke testen op een vaste toetsset vangen veranderingen in het model op, maar signaleren geen verandering in het gedrag van de gebruikers. Neem daarom dagelijks een geanonimiseerde steekproef van de werkelijke productie-inputs en draai daar kwaliteitscontroles op. Dit maakt de verschuiving in het gebruikersprofiel (distribution drift) inzichtelijk.

## Modelversies vastleggen en prompts als code beheren

Om drift als gevolg van externe factoren uit te sluiten, moet de infrastructuur rondom de LLM-aanroepen op orde zijn. Dit begint met het hanteren van de juiste referenties naar het model.

### Geen aliassen in productie

Gebruik in een productie-omgeving nooit algemene modelnamen zoals gpt-4o of claude-3-5-sonnet. Gebruik altijd de specifieke, gedateerde snapshot-versie, zoals gpt-4o-2024-08-06. Hiermee voorkom je dat de provider op de achtergrond de gewichten en het gedrag van de API aanpast. Pas wanneer het team bewust besluit te migreren naar een nieuwere snapshot, wordt deze versie-string na grondige regressietesten aangepast.

Sla bij elke API-call niet alleen de invoer en de uitvoer op, maar ook de exacte model-string, de temperatuur-instelling, de top-p waarde en de gebruikte prompt-versie. Als er gedragsverandering optreedt, kan met behulp van deze logboeken direct worden gereconstrueerd welke variabele is gewijzigd.

### Versiebeheer voor prompts

Een systeemprompt is geen losse tekst in een cms of een hardcoded string in een applicatielaag, maar een kritiek onderdeel van de logica. Behandel de prompt daarom op exact dezelfde wijze als broncode. Hoe je dit opzet in een teamomgeving lees je in het artikel over [prompt-versiebeheer](https://community.llmnet.nl/prompt-versiebeheer).

Belangrijke uitgangspunten hierbij zijn:

- Elke aanpassing aan de systeemprompt wordt doorgevoerd via een afzonderlijke commit in het versiebeheersysteem (Git).

- Pas slechts één instructie of regel tegelijk aan per commit. Wijzig nooit de opbouw, de toon én de randgevallen in één enkele bewerking.

- Documenteer bij elke regel in de prompt of in de commit-message *waarom* deze regel bestaat, inclusief een verwijzing naar het specifieke incident dat aanleiding was voor de toevoeging.

## Corrigeren zonder de prompt te laten groeien

Wanneer is vastgesteld dat een systeemprompt is aangetast door promptbloat, is de reflex van veel ontwikkelaars om nóg een regel toe te voegen om de correctie af te dwingen. Dit verergert de instabiliteit. Een duurzame correctie vereist juist het opschonen en herbalanceren van de bestaande tekst.

### Stap 1: Tegenstrijdigheden verwijderen

Lijn alle regels uit de systeemprompt onder elkaar op en groepeer ze per categorie (bijvoorbeeld: Rol, Toon, Opmaak, Randgevallen). Zoek naar instructies die elkaar logisch of praktisch dwarsbomen. Bepaal welke regel primair is en verwijder de ondergeschikte of dubbelzinnige instructie.

### Stap 2: Regels samenvoegen tot principes

Vervang een lange lijst met specifieke verbodsbepalingen door één overkoepelend principe. LLM's reageren vaak Beter op een positief geformuleerd kader dan op een reeks losse negatieve restricties.

Slecht voorbeeld (opgesplitst en doorgeschoten):

- Noem nooit de interne ID van de klant.
- Laat de databasestructuur niet zien.
- Geef geen SQL-foutmeldingen terug aan de gebruiker.
- Toon geen interne API-sleutels of endpoints.

Beter voorbeeld (geconsolideerd principe):

- Veiligheid: Geef uitsluitend informatie die bedoeld is voor de eindgebruiker. Bepalende technische details, zoals database-schema's, systeem-ID's en foutmeldingen, worden strikt weggelaten uit het antwoord.

### Stap 3: Uitzonderingen verplaatsen naar code

Probeer niet alle randgevallen op te lossen in natuurlijke taal. Een LLM is uitstekend in staat om een conceptueel antwoord te formuleren, maar presteert wisselvallig bij het strikt handhaven van deterministische regels. Verplaats deterministische controle- en correctiemechanismen naar de software-architectuur rondom het model.

- Opmaak afdwingen: Gebruik de native response_format opties van de API (zoals JSON Mode of Structured Outputs met Pydantic / Zod schemas) in plaats van in de systeemprompt uit te leggen hoe een JSON-object moet worden opgebouwd.

- Invoerfoutafhandeling: Valideer de lengte en het formaat van de gebruikersinvoer in de backend vóórdat deze naar het model wordt gestuurd. Het model hoeft een lege of te lange invoer dan niet meer te herkennen.

- Post-processing: Als bepaalde woorden of termen nooit mogen voorkomen, filter deze dan met een reguliere expressie (regex) of een dedicated string-vervanger uit de gegenereerde output, in plaats van de prompt te belasten met een lijst van verboden woorden.

## Wanneer de oplossing buiten de prompt ligt

Soms leidt een grondige analyse van drift tot de conclusie dat de systeemprompt de gevraagde taak simpelweg niet meer kan dragen. De omvang van de instructies, de variëteit aan randgevallen en de omvang van de meegeleverde RAG-context eisen te veel attentie op van één enkel inference-moment.

In dat geval moet je accepteren dat de oorzaak buiten de prompt ligt. De juiste oplossing is dan een aanpassing van de applicatie-architectuur:

- Opsplitsing in meerdere agentische stappen: In plaats van één lange systeemprompt die de analyse, het schrijven en de opmaakcontrole tegelijk uitvoert, deel je de keten op. De eerste stap analyseert de invoer en haalt data op, de tweede stap genereert de inhoud, en een derde lichte stap (of code-validatie) controleert het formaat.

- Dynamische systeemprompts: Bouw de systeemprompt op op basis van de specifieke context van de gebruiker. Als een gebruiker vragen stelt over facturen, hoeven de instructies voor de afhandeling van technische storingen niet te worden meegestuurd in de contextwindow.

Door de systeemprompt beknopt, gefocust en vrij van opgespaarde uitzonderingen te houden, blijft het gedrag van het model voorspelbaar. Drift wordt hiermee geen onontkoombaar mysterie, maar een beheersbaar technisch vraagstuk dat met de juiste bewaking en refactoring-methoden kan worden opgelost.

## Lees ook

- [Systeemprompts opbouwen en structureren](https://community.llmnet.nl/systeemprompts)

- [Prompt-versiebeheer in productieomgevingen](https://community.llmnet.nl/prompt-versiebeheer)

- [Prompts testen voor productie](https://community.llmnet.nl/prompt-testen-voor-productie)

- [Regressietesten voor prompts inrichten](https://benchmark.llmnet.nl/regressietesten-prompts)

- [Modelversies en deprecatie bij API-providers](https://hub.llmnet.nl/modelversies-en-deprecatie)

- [Observability en logging voor LLM-applicaties](https://api.llmnet.nl/observability-en-logging)

llmnet.nl - prompt-engineering en developer-community