Promptversiebeheer

Wat is promptversiebeheer?

Promptversiebeheer is elke prompt in je AI-toepassing behandelen zoals code: elke wijziging krijgt een nummer, een datum, een reden en een naam, de vorige versie blijft bestaan, en je zet ze terug als de nieuwe slechter blijkt. Het gaat over system prompts, prompt templates, few-shot voorbeelden, toolbeschrijvingen en agent-instructiebestanden. Alles wat het model leest voor het antwoordt, is gedrag, en gedrag verdient een geschiedenis.

Een prompt is geen documentatie, het is het programma. Verander "vat de klacht samen" in "vat de klacht kort samen" en een deel van je output verandert mee, op een manier die je pas ziet als je gaat kijken. Niemand weet vrijdag nog wat er dinsdag aangepast is, en dezelfde prompt draait vaak op drie plaatsen tegelijk: in de chatbot, in de nachtelijke batchjob en in de Power Automate-flow waar een collega hem in geplakt heeft.

Het SRE-boek van Google maakte jaren geleden dezelfde redenering over configuratie. Een configuratiewijziging kan even goed instabiliteit veroorzaken als een codewijziging, dus hoort configuratie in de broncoderepository, met een strikte review. Een prompt is configuratie die toevallig in het Nederlands of het Engels geschreven is.

Wat zet je onder versiebeheer?

Een versie die alleen "v5" zegt zonder erbij te vertellen waarop ze getest is, helpt je niet vooruit als er iets misloopt. Bewaar bij de tekst:

• De variabelen: welke invulvelden de template verwacht en in welk formaat. Hernoem {{ticket}} naar {{ticket_text}} en elke aanroep breekt.

• Het model-ID waarop ze getest is, in de vastgepinde vorm. Anthropic schrijft dat elk Claude-model-ID een vastgepinde snapshot is, en OpenAI raadt aan om productietoepassingen op een specifieke modelsnapshot vast te pinnen zodat het gedrag gelijk blijft.

• De instellingen: parameters, outputschema, de tools die aanstonden. Anthropic heeft temperature afgevoerd vanaf Claude Opus 4.7, dus een prompt die daar nog een afwijkende temperature naartoe stuurt, krijgt een foutmelding terug.

• De evalscore, de testset waar ze vandaan komt, en wie de wijziging goedkeurde. Dat maakt van "ik denk dat het beter is" een "90 procent op dezelfde 120 gevallen waar v4 er 76 haalde".

Waar bewaar je de versies?

In de repository, naast de code. De prompt is een gewoon bestand, prompts/factuur-extractie/v5.md, en Git doet de rest: geschiedenis, diff, review, terugdraaien. OpenAI is in 2026 die richting uitgegaan. De herbruikbare promptobjecten worden vanaf 3 juni 2026 afgebouwd, het endpoint v1/prompts sluit op 30 november 2026, en het advies luidt om prompts in een kleine module te zetten bij de functie die ze bedient.

In een promptregistry in een observability- of gateway-tool. Langfuse, PromptLayer en Braintrust bewaren prompts als benoemde objecten met een versienummer en labels zoals production en staging. De toepassing haalt de prompt tijdens de run op naam en label op, dus terugdraaien is het label production een versie terugzetten, zonder deployment, en traces in de tool kunnen bijhouden welke versie een antwoord gemaakt heeft. Het addertje: de prompt verandert nu zonder codewijziging. Bij Langfuse en PromptLayer kan je een label beschermen, zodat enkel een beheerder of een goedkeuringsflow het nog verplaatst.

Passen enkel ontwikkelaars prompts aan, hou ze dan in Git. Past een vakexpert ze elke week aan, dan verdient een registry zijn plaats, op voorwaarde dat dat label beschermd is en elke wijziging eerst door de evalset gaat.

Van bewerking naar productie

1. Wijzig op een branch of als nieuwe conceptversie, nooit in de liveversie zelf.

2. Draai de evalset op hetzelfde vastgepinde model als de huidige versie. Anthropic raadt aan om eerst je succescriteria en een manier om erop te testen vast te leggen, en pas dan aan de prompt te sleutelen. Liever veel automatisch beoordeelde testgevallen dan een handvol die je met de hand nakijkt.

3. Vergelijk per veld, niet op de totaalscore. Een prompt die tien punten wint op één veld en er twee verliest op een ander, is een beslissing, geen winst.

4. Laat de diff nalezen door iemand die verantwoordelijk is voor het resultaat. Een promptdiff is kort en leesbaar, dus dit is de goedkoopste review in je hele stack.

5. Zet live en noteer één regel: wat er veranderd is, de scores, het model, wie goedgekeurd heeft. Hou de vorige versie bereikbaar.

Een versiebump, uitgewerkt

Een prompt haalt leverancier, datum, munt en totaal uit gescande facturen, op claude-haiku-4-5-20251001, tegen 120 echte facturen. Versie 4 zegt "Geef het totaalbedrag terug." Versie 5 zegt "Geef het totaalbedrag inclusief btw terug, als getal met twee decimalen, in de munt van de factuur."

Totaal gaat van 91 juist op 120 naar 108, dus van 76 naar 90 procent. Munt blijft op 118. Datum zakt van 112 naar 110, omdat twee facturen nu de vervaldatum teruggeven. Die achteruitgang komt in de changelog en krijgt een fix in versie 6:

2026-09-02  factuur-extractie v5
  Wijziging: totaal incl. btw, 2 decimalen, munt van de factuur.
  Eval (120 facturen): totaal 76% -> 90%, munt 98%, datum 93% -> 92%.
  Model: claude-haiku-4-5-20251001. Goedgekeurd: An (finance).

Als een klant zes maanden later vraagt waarom een factuur van maart met een verkeerde datum geboekt is, is die regel het hele onderzoek.

Promptversiebeheer versus prompt engineering

Allebei gaan ze over prompts aanpassen, dus ze lopen makkelijk door elkaar. Het verschil zit in wat ze opleveren. Prompt engineering levert nu een betere prompt op: je herformuleert, voegt een voorbeeld toe, structureert met XML-tags, en de output gaat vooruit. Promptversiebeheer levert een geschiedenis op die je kan terugdraaien, zodat je weet wat er veranderd is, wanneer, getest waarop, en hoe je het ongedaan maakt. Een team kan uitstekend zijn in het eerste en geen antwoord hebben op het tweede. Dat is het team dat van een klant hoort dat de slimme herschrijving van vorige maand de Franse facturen gebroken heeft.

Modelversiebeheer is het derde stuk. Anthropic engageert zich om minstens 60 dagen op voorhand te verwittigen voor een publiek uitgebracht model uit dienst gaat, en een prompt die 90 procent haalde op het oude model heeft op het nieuwe geen enkele score tot je de evals opnieuw draait. Behandel een modelupgrade als een versiebump met een lege diff.

Waar moet je op letten bij promptversiebeheer

De aanpassing in het leveranciersportaal die niemand genoteerd heeft. Iemand past om half zes de system prompt aan in de beheerpagina van de chatbotbouwer om één klacht op te lossen, en de volgende ochtend klinkt elk antwoord anders. Laat een tool prompts live bewerken, vergrendel dan dat scherm, of maak het de enige plaats waar prompts bewerkt worden, met een eigen geschiedenis.

De evalset die nooit draait. Een map met testgevallen is geen vangnet. Hang de eval aan dezelfde pipeline die de prompt uitrolt, zodat niets productie haalt zonder score ernaast.

Tien kopieën die uit elkaar groeien. Dezelfde triageprompt wordt geplakt in de chatbot, een Azure Function, twee Power Automate-flows en het notebook van een collega, en elk exemplaar wordt apart bijgewerkt. Hou één bron en laat elke afnemer hem op naam en versie ophalen. Let ook op met aliassen: op sommige platformen verwijst een alias naar een model-ID met datum, en die verwijzing verschuift zodra er een nieuwer model is.

De kmo-versie, zonder extra tool

Voor twee of drie AI-functies heb je niets nodig dat je nog niet hebt: een map prompts/ in de repository van de toepassing met één submap per prompt, een naamregel zoals <naam>/v<nummer>.md met het model-ID in een kop bovenaan, één evals.jsonl per prompt met dertig tot honderd echte gevallen en hun verwachte antwoord, en één changelogregel per wijziging in de vorm hierboven. Voeg een evalgeval toe telkens er iets misloopt in productie, en laat geen enkele prompt naar productie gaan zonder die regel en de initialen van een tweede persoon. Bij twintig prompts en vijf mensen die ze bewerken, verhuis je dezelfde map naar een registry. De geschiedenis gaat mee.