Stop met gissen, start met meten: een systematische promptverbeterings-workflow voor productie-AI-systemen

In veel gevallen ontwikkelen teams prompts op een informele manier, vergelijkbaar met het schrijven van een losse e-mail. Dit is een natuurlijk proces en er wordt niet veel nagedacht over structurele elementen. Deze informele aanpak is geschikt voor verkennende ontwikkeling of zelfs voor het snel bouwen van een prototype.

Maar wanneer je een functie die is gebouwd op een Large Language Model begint te gebruiken voor daadwerkelijke eindgebruikers, worden prompts een cruciaal aspect. Als prompts niet goed zijn ontworpen, kan dit leiden tot fouten: antwoorden zijn mogelijk niet consistent, belangrijke informatie kan ontbreken en de resultaten zijn wellicht niet betrouwbaar.

Daarnaast is debugging onverwacht complex wanneer er een probleem optreedt. Je moet vaak achterhalen of het probleem te maken heeft met het model, de invoer of de prompt zelf.

In dit artikel bespreken we het exacte proces dat we hebben ontwikkeld om prompts van 'waarschijnlijk goed genoeg' naar 'definitief klaar voor productie' te brengen met echte criteria, echte evaluatiedatasets en echte benchmarks over meerdere modellen. Geen magie. Gewoon gestructureerde engineering toegepast op prompts.

Waarom prompts meer zijn dan alleen instructies

Wanneer de meeste mensen aan een prompt denken, denken ze aan een eenvoudig verzoek, zoals: "Vat dit document samen" of "Extraheer entiteiten uit deze tekst." Maar in de praktijk is een prompt zoveel meer dan dat. Het is de fundamentele interface tussen jouw programma en het gedrag van het model. Een goede prompt creëert de persona voor het model, de omgangsregels, het outputformaat en de omgang met het onverwachte.

Het probleem met prompts is dat ze vaak niet grondig worden getest. Ze worden ontworpen, geïmplementeerd en vervolgens vluchtig gecontroleerd om te zien of ze werken. Je past hier iets aan en voegt daar een regel toe. Vervolgens hoop je maar dat het goed uitpakt. Soms werkt het. Meestal niet. En wanneer het misgaat, faalt het stilzwijgend. Je merkt het misschien niet eens op.

Wat maakt een prompt nu echt “goed”?

Een goede prompt is niet alleen duidelijk, hij is gestructureerd. Zie het als een API-contract tussen jou en het model. Het moet het volgende definiëren:

• Een rol of persona: Vanuit welke context moet het model werken?
• Instructies: Wat moet het precies doen?
• Beperkingen: Wat mag het absoluut nooit doen?
• Outputspecificatie: Welk formaat, welke structuur en welke lengte worden er verwacht?
• Contextuele ondersteuning: Welke achtergrondinformatie heeft het model nodig om te handelen zonder aannames te doen?
• Voorbeelden: Hoe ziet een goede output eruit?

Wanneer al deze elementen aanwezig zijn, heeft het model alles wat het nodig heeft om consistent, betrouwbaar en voorspelbaar te zijn over verschillende invoergegevens en zelfs over verschillende modelversies heen.

De werkelijke kosten van slecht gestructureerde prompts in productie

Dit is wat we hebben zien gebeuren bij slechte prompts in daadwerkelijke toepassingen:

Outputs die er juist uitzien, maar het niet zijn: Het model genereert een antwoord dat het juiste formaat lijkt te hebben, maar subtiele fouten bevat omdat de specificatie niet duidelijk was.

Fouten tussen verschillende modellen: De prompt werkt voor GPT-4, maar geeft inconsistente antwoorden bij Claude en OSS-modellen. Niemand heeft het voor de uitrol op meerdere modellen getest.

Stille regressies: Eén woord aanpassen om één probleem op te lossen veroorzaakt drie andere problemen die niemand opmerkt totdat er een klant klaagt.

Het probleem is altijd hetzelfde: niemand behandelde de prompt als iets dat getest en gevalideerd moet worden. We hebben dit proces gebouwd om dat op te lossen.

Onze promptverbeterings-workflow: stap voor stap

De workflow bestaat uit vijf stappen. Elke stap bouwt voort op de vorige. Sla er één over en de resultaten worden snel onbetrouwbaar. Zo werkt het van begin tot eind.

Stap 1 - De prompt evalueren

Voordat we wijzigingen aanbrengen, willen we weten wat er mis is. We gebruiken een gestructureerde evaluatie-engine die op elke prompt draait, deze scoort op vijf verschillende dimensies en een algehele kwaliteitsscore geeft van 0 tot 100.

We gebruiken geen subjectieve beoordeling. We hanteren duidelijke criteria voor alle dimensies en harde beperkingen. Als er bijvoorbeeld geen outputspecificatie in de prompt staat, geldt er een maximale score voor outputspecificatie. De totale score kan hoog zijn, zelfs als de instructies in de prompt goed geschreven zijn. Als de score lager is dan 75, is de prompt niet geschikt voor productie. Is de score hoger dan 90, dan is hij op alle dimensies solide.

Stap 2 - Aanbevelingen genereren op basis van 5 criteria

Dit is de diagnostische engine van de workflow. Elke prompt krijgt een score van 0 tot 100 op basis van vijf specifieke criteria. De algehele score is het rekenkundig gemiddelde van alle vijf. Dit is wat elk criterium meet en waarom het belangrijk is:

1. Duidelijkheid en specificiteit

Zijn de instructies zo duidelijk dat twee verschillende modellen ze op exact dezelfde manier interpreteren? Vage instructies veroorzaken vaker inconsistenties dan welke andere factor ook. Als je er niet zeker van bent hoe een mens je prompt zou interpreteren, weet je waarschijnlijk ook niet hoe een model deze zal interpreteren. Als een mens de prompt op meerdere manieren kan uitleggen, kan een model dat ook — juist of onjuist.

2. Structuur en organisatie

Stroomt de prompt logisch van context → instructies → beperkingen → outputformaat? Een ongeorganiseerde prompt dwingt het model om zelf te bepalen wat belangrijk is en in welke volgorde. Een goede structuur maakt het werk van het model eenvoudiger en jouw outputs betrouwbaarder.

3. Outputspecificatie

Zijn het verwachte outputformaat, de structuur en de lengte goed gedefinieerd? Als de output door een vervolg-parser moet worden verwerkt, zijn er dan geen onduidelijkheden over hoe de output eruitziet? Dit controleert de meest voorkomende fout: outputs die er goed uitzien, maar niet verwerkt kunnen worden.

4. Contextuele ondersteuning

Biedt deze prompt het model voldoende context om te presteren zonder aannames te hoeven doen? Modellen die aannames moeten doen, zullen uiteindelijk verkeerde aannames doen. Context zoals vakterminologie, randvoorwaarden en achtergrondinformatie elimineert dit type fouten volledig.

5. Foutafhandeling

Worden randgevallen (edge cases) afgedekt? Geeft deze prompt aan wat er moet gebeuren als de invoer ambigu, onvolledig of buiten de kaders is? Dit wordt het vaakst over het hoofd gezien en veroorzaakt de meeste problemen in productie. Hallucinaties, onverwachte invoerformaten, ontbrekende informatie – dit alles moet in de prompt worden afgevangen.

Scoreschaal: 90–100 is klaar voor productie. 75–89 bevat tekortkomingen, maar is functioneel. 50–74 werkt, maar is onbetrouwbaar. Onder de 50 betekent significante structurele problemen die moeten worden opgelost voordat de prompt live gaat.

Stap 3 - De aanbevelingen toepassen

We hebben de scores en toelichtingen voor elk criterium. Vervolgens genereren we een concrete versie van de verbeterde prompt. De aanbevelingen zijn geen abstracte ideeën; ze komen overeen met daadwerkelijke wijzigingen in de structuur van de prompt. Denk hierbij aan het toevoegen van ontbrekende outputspecificaties, het verduidelijken van vage instructies, het scheiden van inhoudelijke en opmaakgerelateerde kwesties, en het expliciet maken van terugvalopties voor randgevallen.

De belangrijkste regel die we hanteren is het behoud van de oorspronkelijke intentie. Met andere woorden: we herschrijven de prompt niet volledig. We vullen de hiaten op die uit de evaluatie naar voren kwamen, terwijl het oorspronkelijke doel en het domein behouden blijven.

Stap 4 - Testen op evaluatiedatasets

De verbeterde prompt wordt pas in gebruik genomen nadat deze uitvoerig is getest. Deze test wordt uitgevoerd met een benchmarkdataset die representatief is voor alle mogelijke scenario's en fouten binnen de toepassing.

Dit proces is noodzakelijk omdat het aanpassen van prompts – hoe gunstig dat in theorie ook lijkt – onbedoelde problemen kan veroorzaken in de praktijk. Het strakker maken van een outputspecificatie kan bijvoorbeeld wrijving opleveren bij specifieke invoertypen als het model te veel in zijn flexibiliteit wordt beperkt.

Stap 5 - Prestaties vergelijken over metrieken en modellen

De laatste stap is benchmarking. We vergelijken de originele en de verbeterde prompt op twee dimensies:

• Metrieken:

• Algemene kwaliteit: duidelijkheid, volledigheid, nauwkeurigheid, beknoptheid, professionele toon
• Guardrails / Classificatie: naleving van outputformaat, vermijden van hallucinaties
• Conversatie: relevantie van het antwoord, opvolgen van prompt-instructies, empathie & toon

De algehele score is het rekenkundig gemiddelde van de geselecteerde metrieken; gebruikers kunnen voorafgaand aan de evaluatie relevante metrieken kiezen.

• Modellen: Gemini, GPT-5, Claude en open-source modellen. Hoewel een prompt voor één model is geoptimaliseerd, kan deze bij een ander model falen — niet omdat de prompt verkeerd is, maar omdat modellen verschillen in hoe goed ze instructies opvolgen, hoeveel structuur ze verdragen en wat ze aannemen bij onduidelijke invoer.

De vergelijkingsweergave laat zien waar de verbetering echt is, waar deze modelspecifiek is en waar verdere iteratie nodig is voordat de prompt als overdraagbaar tussen verschillende providers kan worden beschouwd.

Stap 6 - Suggesties toepassen & verfijnen

Vervolgens scoort de LLM Judge beide prompts en worden er verbeteringssuggesties gegeven op prioriteit (HOOG, GEMIDDELD en LAAG), gebaseerd op de punten waar het scoreverschil tussen het origineel en de verbeterde versie het kleinst was.

Je selecteert welke suggesties je wilt toepassen, waarna het systeem deze terugstuurt door dezelfde verbeteringspijplijn om een verfijnde, verbeterde prompt te genereren. Deze feedbackloop verbetert de prompt continu door deze opnieuw te evalueren en aan te scherpen.

Dit zijn geen algemene suggesties; ze zijn specifiek afgestemd op de testgevallen. De reden hiervoor is dat het Evaluator-model beoordeelt hoe goed jouw originele en verbeterde prompts presteerden in jouw specifieke testcases. De suggesties die je ziet, hebben rechtstreeks betrekking op wat er ontbrak tijdens de evaluatie van de testcases. Als je extra testcases aan deze evaluatie zou toevoegen, zie je mogelijk andere suggesties.

Je kunt dit proces zo vaak herhalen als nodig is. Elke cyclus gebruikt de eerder verbeterde prompt als de nieuwe basislijn, waardoor verbeteringen zich opstapelen. De uiteindelijke verfijnde prompt kan direct vanuit de UI worden gedownload en uitgerold met de TrueFoundry Gateway.

Waarom dezelfde prompt zich anders gedraagt per model

Wanneer we het over engineering hebben, is er iets waar we vaak niet bij stilstaan: modellen zoals Gemini, GPT-5, Claude en LLaMA begrijpen zaken niet op dezelfde manier. Dit komt doordat ze allemaal anders zijn getraind, hebben geleerd van verschillende datasets en zijn geoptimaliseerd voor uiteenlopende taken. Dus wanneer we hun iets vragen, kunnen ze ons verschillende antwoorden geven. Dit ligt niet aan een slechte vraag, maar aan het feit dat elk model zijn eigen manier van werken heeft.

Sommige modellen zijn erg goed in het volgen van regels en doen exact wat er gevraagd wordt. GPT-4-modellen kunnen bijvoorbeeld erg letterlijk zijn. LLaMA-modellen zijn mogelijk meer generatief en proberen hiaten op te vullen. Claude-modellen zijn vaak sterk in het verwerken van ingewikkelde vragen, terwijl andere modellen weer beter presteren bij eenvoudige verzoeken.

De enige manier om te weten hoe een prompt zich gedraagt over verschillende modellen heen, is door deze te testen. En de enige manier om dat testen systematisch te maken, is door een evaluatieworkflow zoals deze te gebruiken.

Promptversies beheren in productie met TrueFoundry Gateway

Zodra je prompt is geëvalueerd, verbeterd en getest, heb je een systeem nodig om deze in de loop van de tijd te beheren: versiebeheer, omgevingsspecifieke uitrol en de mogelijkheid om slechte wijzigingen terug te draaien zonder je hele applicatie opnieuw te hoeven deployen.

Dit is waar TrueFoundry's AI Gateway om de hoek komt kijken. TrueFoundry biedt een gecentraliseerd promptbeheersysteem met ingebouwd versiebeheer: elke wijziging aan een prompt wordt bijgehouden en je kunt naar specifieke versies verwijzen met behulp van goed leesbare aliassen zoals v1-prod of v2-staging. De Gateway bepaalt de promptversie tijdens runtime, wat betekent dat prompt-updates geen nieuwe codedeployments meer vereisen.

Geleerde lessen en best practices

Door de workflow toe te passen op uiteenlopende prompts en projecten zijn verschillende belangrijke inzichten naar voren gekomen:

1. Het is essentieel om altijd te zorgen dat diagnostische scores worden verzameld vóór het bewerken. De natuurlijke reactie op een probleem is om direct wijzigingen aan te brengen zodra het probleem wordt opgemerkt. Vermijd dit. Leg de diagnostische gegevens vast voordat je iets aanpast. Het hoofdvraagstuk bevindt zich vaak op een plek die aanvankelijk niet werd vermoed.
2. Scheid de outputstijl van de inhoud. Het combineren hiervan creëert ambiguïteit die de consistentie subtiel aantast. Maak de inhoud en de outputstijl als afzonderlijke onderdelen duidelijk voor het model.
3. Sla foutafhandeling niet over. De extra inspanning bewijst zichzelf pas wanneer onverwachte invoer tot ongewenst gedrag leidt. Definieer paden voor foutafhandeling om kostenefficiëntie te waarborgen.
4. Behandel prompts als code. Implementeer versiebeheer en voer reviews uit vóór de release met behulp van de huidige toolset.
5. Integreer cross-model testing in een vroeg stadium. Pas na een wijziging ontdekken dat een prompt wel werkt voor het ene model maar niet voor het andere, is niet ideaal. Maak cross-model testen een vast onderdeel van de standaard workflow.

De volgende stap: Prompt Engineering als systeem

Het doel waar we naartoe werken is om promptkwaliteit net zo meetbaar en auditeerbaar te maken als elk ander onderdeel van je softwarestack. Dat betekent geautomatiseerde regressietesten voor prompts wanneer de onderliggende modelversie verandert, promptversiebeheer geïntegreerd in je deployment-pijplijn en evaluatiedashboards die inzicht geven in promptprestaties door de tijd heen.

Prompt engineering wordt niet langer gezien als een ambacht, maar als een wetenschap. Organisaties die het als zodanig behandelen en een formeel proces voor evaluatie, iteratie en testen implementeren, zullen beter gepositioneerd zijn om betrouwbaardere AI-systemen te bouwen dan organisaties die dat niet doen. Het proces dat in deze workflow wordt beschreven, is een stap in die richting.