Wanneer splits je nou je prompts? Op die vraag zit ik al een paar weken te kauwen. Want na vele discussies en denkrondjes over promptlengte (antwoord, mag best lang zijn) en taakcomplexiteit (antwoord, mag best complex zijn), had ik ‘m nog niet helemaal beet.
Toen ik net startte met prompt design, kreeg ik van alle kanten (goedbedoeld) advies: zorg dat je prompt geen tegengestelde instructies bevat, zorg dat je instructies kort, krachtig en voor een LLM-begrijpelijk formuleert (niet “korte zinnen”, wel “zinnen van max. 10 woorden”) en zorg dat je prompt niet te lang is.
Maar hoe meer prompts ik aan het bakken was, hoe meer ik me realiseerde dat een prompt niet per se kort of zelfs simpel hoeft te zijn.
En laat ik hier even stoppen en nog even goed benadrukken dat ik geen prompts maak voor mezelf alleen, maar voor Taak-inzet: meerdere mensen moeten de prompt kunnen gebruiken voor eenzelfde taak en mogen dan consistente output verwachten. Of dat nou handmatig is (copy/paste prompt in een LLM) of automagisch (een assistant die op een LLM draait om een specifieke taak uit te voeren, zoals bijv. vertalen).
Ik benadruk dat omdat je voor deze inzet van je prompts (ook) andere vragen moet beantwoorden dan wanneer je enkel voor jezelf prompt.
Maar wanneer splits je dan?
Ik sloeg er de documentatie van bijv. OpenAI of Anthropic op na, dat mij (impliciet)wees in de richting van de Taak als splitscriterium: schrijf een productpagina, is een andere taak dan schrijf een artikel en daarom heb je een nieuwe prompt nodig.
Maar in de praktijk kwam ik regelmatig tegen dat dat niet per se zo is. Eén prompt kan prima meerdere taken bevatten. En ja, natuurlijk moet je ook daar een balans in zien te trekken, maar sec gezien kan het gewoon en zie ik dat opdrachten nog steeds goed worden uitgevoerd.
Wat ik wel begon te zien, is dat een splitsing betere resultaten opleverde, wanneer de Rol veranderde. Dat werd vooral duidelijk als ik prompt-diagnoses aan het doen was van intuitieve prompts, gemaakt door mensen die niet de godganse dag bezig zijn met nadenken over prompten.
Wat ik zag waren dit soort instructies in 1 prompt:
- Vertaal deze medische tekst van Engels naar Nederlands
- Beoordeel of de medische terminologie correct is
- Herschrijf het voor patiënten in begrijpelijke taal
Maar voor elk van deze stappen, heb je een andere expertise nodig:
- Vertaal deze medische tekst van Engels naar Nederlands: vertaler
- Beoordeel of de medische terminologie correct is: medisch specialist
- Herschrijf het voor patiënten in begrijpelijke taal: (gezondheids)communicatie-expert
Dat betekent overigens niet dat als je alles in één prompt zet, dat de output volledig krankzinnig is, maar wel dat de outputconsistentie van je prompt gaat zweven. In een business setting, wil je dat niet. Je wilt werkende, herbruikbare prompts, die consistente output leveren.
Waarom schaadt rolwisseling binnen één prompt output-consistentie?
Conflicterende optimalisatie
Elke rol triggert een ander patroon van waarschijnlijk taalgebruik. Een vertaler optimaliseert voor letterlijkheid, een medisch specialist voor correctheid, een communicatie-expert voor begrijpelijkheid. Als je om alle drie tegelijk vraagt, moet het model die verschillende expertises mengen op een onvoorspelbare manier én constant kiezen tussen precisie en toegankelijkheid, tussen vakjargon en lekentaal. Bij de ene run domineert de medische correctheid, bij de andere de leesbaarheid. Bij gesplitste prompts heeft elk model één duidelijke focus, dat levert voorspelbaarder gedrag op.
Prioriteren wordt lastiger
“Vertaal, check medisch, en maak toegankelijk”. Maar wat als de medische check een fout vindt? Moet de vertaling worden aangepast of blijft die dan leidend? Moet de toegankelijke versie 100% medisch correct blijven, of mag er nuance verloren gaan voor begrijpelijkheid? Door rollen te splitsen, dwing je jezelf om deze prioriteiten expliciet te maken in de chain: eerst correct, dan toegankelijk. Of: eerst toegankelijk, dan medisch geverifieerd.
Voor de volledigheid: niet elke rolwisseling vraagt om een splitsing. Als de verandering vooral stilistisch of oppervlakkig is, zoals van copywriter naar editor, dan blijft de expertise die je vraagt, grotendeels hetzelfde. De LLM blijft dan namelijk binnen hetzelfde vakgebied (semantische domein) redeneren. Je kunt dan prima binnen één prompt blijven.
De gekozen rol, beïnvloedt de rest
Wanneer je ziet dat er een andere rol nodig is om een deeltaak goed uit te voeren, dan is dat dus een goed moment om je prompt te splitsen.
Doe je dat, dan kom je er algauw achter dat elke prompt ook potentieel net andere guidelines, guardrails, output instructions enz. nodig heeft. En wijst de praktijk daarmee uit, dat je inderdaad een goed splitsmoment hebt ontdekt.
Nu is dit waarschijnlijk voor jou geen verrassing. Als je prompt designer bent, dan ben je dit allang tegengekomen, vermoed ik.
Maar voor mij maakt het een plaatje af waar ik nog een beetje op zat te puzzelen. In de workshops die ik geef, leer ik mensen om:
- De taakprocesstappen in kaart te brengen (welke stappen zet je op weg naar een productpagina)
- Over elke stap een aantal vragen te beantwoorden, maar in elk geval de vraag: kan deze stap effectief worden uitgevoerd door een LLM?
- Als ja, maak hier een prompt bij (structured prompt a.u.b)
Dat werkt al prima, helpt al om prompts te scheiden, maar miste nog deze rol-nuance. Want 1 taakprocesstap, kan dan dus uit meerdere prompts (moeten) bestaan, als je wilt dat de stap goed wordt uitgevoerd door een LLM.
LLM’s als magie
In de praktijk stuit dit idee op wat weerstand. Het idee van de LLM als geest in de fles, die in één keer je wensen uitvoert, precies zoals jij het wil, is namelijk nogal hardnekkig.
Maar net zoals bij een geest in een fles, moet je goed nadenken over wat je vraagt, want die geesten hebben er een handje van om onduidelijke instructies, op een nare manier te interpreteren.
Dat deze overweging vaak meer prompts oplevert en in een handmatige setting (jij kopieert/plakt de prompt in Co-pilot), dus meer stappen vraagt of in een automatische setting, meer chaining vraagt, wordt niet altijd met evenveel enthousiasme ontvangen.
Maar in de praktijk merk ik toch, dat dat precies is wat nodig is voor die consistente en dus betere en dus minder iteraties nodig, output. Dit vraagt meer werk vooraf, maar levert betere output op (en dus minder nabewerking). Dat is het wat mij betreft waard.”
Ik ben het maar hoor, niet stressen.
I’ve spent over 25 years working in content strategy and digital transformation, which means I’ve seen enough technology hype cycles to be skeptical and enough genuine innovation to stay curious.
Want to talk shop? Do get in touch!
