Prompten is dood, lang leve context? Ja én nee.

“Prompting is sowieso voorbij. Het gaat nu om context engineering.”, zei iemand laatst zeer stellig tegen mij.

Mwah, dacht ik en zei ik tegelijkertijd. Nieuwe woorden zijn altijd welkom natuurlijk, maar het lijkt me stug dat instructies opeens niet meer relevant zijn. 

Niet omdat ik specifiek gehecht ben aan prompting. Integendeel. Ik probeer mensen al enige tijd ervan te overtuigen dat je een effectieve AI-implementatie niet bij elkaar promptEen prompt is de instructie die je aan een AI-model geeft zoals bijvoorbeeld ChatGPT. Het is hoe je communiceert met het systeem: wat je vraagt, hoe je het vraagt en... Meer. 

Maar ik vermoedde ernstig dat er ergens een categoriefout zat in dit gesprek. Maar aan vermoeden hebben we niks, dus besloot ik er dit weekend in te duiken. 

Zet je duikbril maar op 

Oké, een paar dingen…

Wat is context engineering nou eigenlijk? De term wordt door Anthropic uitgelegd als volgt:

““Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.” 

Oftewel, context engineering gaat over het samenstellen en actueel houden van alles wat een (LL)model nodig heeft om tot een goede output te komen. 

We slaan het even plat. Maar niet te plat want wat er staat is wel interessant: Samenstellen én actueel houden door een context engineer.

Deze moeten we even uitpluizen. Want wie in de echte wereld, in een bedrijf werkt dat groter is dan 3 mensen (random aantal), ziet waarschijnlijk hier al een issue.

Een engineer (van wat voor type dan ook) kan niet zaken zoals de business rules actueel houden of de feitelijkheid van kennis bewaken. Een engineer moet dat ook niet doen overigens. 

Zij moet wel weten waar ze de business rules, juiste brondata, ontologie enz. Vandaan moet halen zodat het op het juiste moment kan worden aangeroepen. 

En ja, iedereen die meer dan 1 dag zakelijk met (Gen)AI bezig is, heeft inmiddels geleerd dat al die elementen (zoals: knowledge, business-, compliance-, legal- rules, ontology, styleguides enz) op orde moeten zijn om je implementatie te beste kans te geven om succesvol te zijn. 

De context engineer moet absoluut weten welke zaken van belang zijn, zodat ze die op de juiste plek kunnen plotten (aanroepen/inrichten/beschikbaar maken), maar het zijn anderen die ervoor moeten zorgen dat die zaken er zijn en actueel zijn.

En belangrijker: de prompt, oftewel de taakinstructies zijn hier onderdeel van. De prompt verdwijnt dus niet, maar is onderdeel van een groter geheel. En ja, dat wist je al, maar ik wil het toch even benadrukken. 

We gaan op reis, met een hond

We doen even een voorbeeld, want dat helpt vaak. Stel je bent een reisorganisatie en je wilt een LLM gebruiken om een klant antwoord te geven op haar vraag:

“Kan ik mijn hond meenemen naar het hotel dat ik heb geboekt? “

Wat moet er dan allemaal kloppen voordat dat antwoord goed kan zijn?

Om te beginnen moeten de feiten waarop het antwoord gebaseerd is, kloppen. Om exact te zijn: het moet kloppen op het moment dat je het gebruikt AKA feitelijk correct én actueel zijn.

Als het hotel sinds vorige maand geen huisdieren meer accepteert, heb je een probleem dat je niet oplost door die verouderde informatie slimmer aan het model te geven.

Verder moet de relatie tussen verschillende feiten ook duidelijk zijn. Misschien zijn huisdieren inderdaad toegestaan, maar alleen in appartementen en niet in hotelkamers. Dan zijn “dit hotel staat huisdieren toe” en “de klant heeft een tweepersoonskamer geboekt” allebei correcte feiten. Toch kan het model het verkeerde antwoord geven als niet duidelijk is hoe die twee feiten zich tot elkaar verhouden. 

Je moet ook nog weten in welke situatie deze feiten wel en niet van toepassing zijn. Misschien staat het hotel huisdieren toe en heeft de klant inderdaad een appartement geboekt, maar geldt dat alleen voor honden tot 20 kilo. Of zijn huisdieren alleen toegestaan als ze vooraf zijn aangemeld. Dan kunnen alle feiten op zichzelf kloppen en kan ook hun onderlinge relatie duidelijk zijn, maar moet je nog steeds weten onder welke voorwaarden ze gelden voor deze specifieke klant en situatie. 

Vervolgens moet je het model vertellen wat het moet doen. 

In dit voorbeeld moet het model dus niet zomaar iets vertellen over het huisdierenbeleid van het hotel. Het moet de vraag van deze klant beantwoorden op basis van de informatie over het hotel én haar boeking. 

En als bijv. niet bekend is hoe zwaar haar hond is, terwijl dat nodig is om de vraag goed te beantwoorden, moet het model niet gokken dat het wel goed zit, maar om die informatie vragen.

Natuurlijk moet je dan ook nog weten hoe het antwoord moet worden vormgegeven. De conclusie kan bijvoorbeeld zijn: ja, de hond mag mee, mits hij onder de 20 kilo is en vooraf wordt aangemeld. Maar hoe je die conclusie uitdrukt, is weer een andere vraag. 

Welke toon gebruik je? Welke woorden wel of niet? Hoeveel uitleg geef je? In een chat wil je het misschien in twee korte zinnen zeggen, in een e-mail kan er iets meer uitleg bij en in een voice-interface wil je waarschijnlijk nog compacter formuleren.

Je ziet al dat dit zeer verschillende vragen zijn. En dat is van belang, want ze kunnen allemaal afzonderlijk misgaan op verschillende plekken.

We stoppen heel veel verschillende dingen in het woord ‘context’

En daar begon voor mij ook mijn probleem met context engineering.

Als je het technisch bedoelt, prima. Je bouwt mechanismen waarmee je dynamische context tijdens runtime ophaalt, selecteert, filtert en samenstelt. Retrieval, filtering, ranking, memory, state, tool outputs, context assembly. Daar kun je letterlijk aan engineeren.

Dat is voor mij context engineering: technisch regelen dat de juiste zaken op het juiste moment beschikbaar komen voor het model.

Maar die dingen zelf komen ergens vandaan. Een prompt of andere instructie is daar één van, net zoals source data, business rules, memory, gebruikersinformatie of tool output dat kunnen zijn. De prompt zit dus ín die context, maar het ontwerpen van de prompt is daarmee niet opeens hetzelfde vak als het technisch samenstellen van context. Net zo min als het beheren van brondata of business rules dat is.

En er zit wat mij betreft ook nog een laag boven. 

Iemand moet namelijk ook ontwerpen welke context het systeem überhaupt nodig heeft, waar die vandaan komt, wie eigenaar is, wanneer die relevant is en hoe al die onderdelen in de keten op elkaar ingrijpen. Laten we dat context design noemen. 

Dat alles bij elkaar engineeren zodat het tijdens runtime op de juiste plek samenkomt, bepaalt echter niet of de informatie die je ophaalt ook klopt.

En wat uiteindelijk bij het model terechtkomt, is niet één ding dat iemand heeft “ge-engineerd”. Het is het resultaat van een hele verzameling afhankelijkheden:  

De bron moet kloppen, de regels moeten kloppen, het moet duidelijk zijn wanneer die regels wel en niet van toepassing zijn, de juiste informatie moet worden opgehaald, de instructies moeten kloppen en vervolgens moet het antwoord ook nog op een manier worden uitgedrukt die past bij de situatie en het kanaal. Ja, langste zin ever, maar er moet ook veel goed gaan. 

En al die zaken hebben ook nog eens niet per se (en in enterprise omgevingen bijna nooit) dezelfde eigenaar of zitten vaak niet eens in dezelfde tak van het bedrijf of IN het bedrijf überhaupt.

Bij een reisorganisatie kan een hotel zelf verantwoordelijk zijn voor bepaalde accommodatiegegevens, kan een productteam bepalen hoe bepaalde voorwaarden worden toegepast, kan legal eigenaar zijn van juridische beperkingen, kan een technisch team retrieval en orchestration inrichten en kan content verantwoordelijk zijn voor de manier waarop uiteindelijk met de klant wordt gecommuniceerd. Geen van die mensen is daarmee automatisch eigenaar van “de context”.

En precies daar wordt het verschil tussen context engineering en wat ik hier context design noem belangrijk. Context engineering regelt technisch hoe relevante context bij het model terechtkomt. Context design kijkt naar de hele keten waaruit die context ontstaat.

Natuurlijk moet iemand technisch regelen dat de juiste informatie, regels, memory, state en instructies op het juiste moment bij het model terechtkomen. Maar die persoon engineered niet de hele AI-pipeline, maar is een “station” daarbinnen.

Maar breder: de data source, business rules, prompts en andere instructies etcetera moeten allemaal optimaal ingericht en beheerd worden voor (Gen)AI-gebruik. 

Fouten kunnen namelijk op verschillende plekken in de keten ontstaan. Een bron kan fout zijn terwijl retrieval perfect werkt. Retrieval kan de verkeerde informatie ophalen terwijl de bron zelf prima is. De juiste informatie kan worden opgehaald en vervolgens verkeerd worden toegepast. Alles kan inhoudelijk kloppen en de prompt kan het model alsnog de verkeerde opdracht geven. Het antwoord kan correct zijn en vervolgens zo worden geformuleerd dat de klant iets anders begrijpt.

De kwaliteit van de uiteindelijke AI-output leeft dus niet op één plek en je moet de afzonderlijke afhankelijkheden waaruit de context ontstaat kunnen begrijpen, beheren en controleren.

We konden een tijdje doen alsof het systeem eromheen niet bestond

Dat is misschien wel het bijzondere aan LLM’s.

Bij traditionele automatisering kom je meestal vrij snel in de problemen als je input niet klopt, je regels niet expliciet zijn of je processen niet goed zijn ingericht. De meeste systemen zijn notoir slecht in raden wat Sandra bedoelde toen ze drie jaar geleden besloot dat een uitzondering in “dit soort gevallen” meestal wel mocht.

Een LLM kan dat soms wel.

Of beter gezegd: het kan iets produceren dat voldoende overtuigend klinkt om je het idee te geven dat het dat kan.

En daardoor dachten we, dit gaat lekker, hoewel processen die niet goed waren uitgewerkt, informatie niet geweldig was gestructureerd en regels deels in documenten en deels in de hoofden van mensen zaten.

Stop gewoon genoeg uitleg in de prompt en voila, it’s magic.

En ja, dat levert óók weleens indrukwekkende resultaten op. Wat het dan weer ontzettend verleidelijk maakt om te denken dat we een shortcut te pakken hebben.

Maar de complexiteit is er natuurlijk gewoon nog. We hebben de plek waar het leeft enkel verschoven.

Scale lifts the veil

Dat issue wordt zeer zichtbaar zodra je probeert op te schalen. Prompts worden steeds groter en groter omdat ze informatie moeten dragen die eigenlijk ergens anders beheerd hoort te worden. Teams bouwen hun eigen versies van dezelfde regels. Uitzonderingen worden in prompts opgelost omdat niemand het onderliggende proces aanpast. 

En ja, de demo werkt soms best goed, maar zodra je het systeem op duizenden (tienduizenden, honderdduizenden) verschillende situaties loslaat, komen de gaten vanzelf tevoorschijn.

En als je dan niet weet welke combinatie van factoren de output hebben gegenereerd, dan heb je ook geen idee wat je moet repareren.

De bron? Retrieval? De business rule? De prompt? Het model? Processen? Piet van JZ? De tone of voice?

En het is correct dat dat geen promptprobleem is. Maar het is óók geen context-engineeringprobleem. Het is een systeemprobleem.

Want de kwaliteit van AI-output ontstaat dus in de cumulatieve keten. Want alle onderdelen van die keten moeten op elkaar aansluiten.

• Wat moet op dit punt in de keten aantoonbaar juist of beschikbaar zijn?
  Wat moet er minimaal kloppen voordat de volgende stap erop mag vertrouwen?
• Wie is daar eigenaar van?
  Eigenaarschap betekent niet alleen dat er ergens een naam staat. De eigenaar moet ervoor zorgen dat processen en governance zijn ingericht waardoor dit onderdeel correct, actueel en bruikbaar is én blijft.
• Welke failure modes horen bij deze stap?
  Daarmee leg je vooraf vast op welke manieren deze stap kan falen, hoe je die fouten kunt herkennen en waar je moet kijken als ze optreden. Dat vraagt kennis van de lokale owner, maar ook overzicht over de hele keten: een fout wordt immers soms pas twee stappen verder zichtbaar.
• Welke downstream stappen zijn hiervan afhankelijk?
  Daarmee weet je wat er verderop geraakt kan worden als hier iets verandert of fout gaat. Een wijziging is dan niet alleen een lokale wijziging; je kunt bepalen welke andere onderdelen opnieuw gecontroleerd moeten worden.

Je ziet het waarschijnlijk al: iemand moet verantwoordelijk zijn voor het functioneren van de keten als geheel. 

Niet door eigenaar te worden van ieder onderdeel, maar door ervoor te zorgen dat voor ieder onderdeel duidelijk is wat de requirements en failure modes zijn, wie er eigenaar van is en hoe veranderingen en fouten doorwerken in de rest van het systeem. 

Die persoon hoeft de business rules niet te onderhouden en hoeft retrieval niet te bouwen. Maar als de output niet goed is, moet zij wel kunnen achterhalen waar in de keten het probleem ontstaat en de eigenaar van dat onderdeel kunnen aanspreken. En dat is precies de functie die ik eerder context design noemde.

Want de context engineer is verantwoordelijk voor een deel van een keten: de technische mechanismen waarmee relevante context wordt opgehaald. Terwijl de context designer/architect/final boss verantwoordelijk is voor het functioneren van de hele keten en kan duwen op elk station erbinnen. 

Wie is u precies?

En dan kom ik vanzelf bij de volgende vraag: wie doet dit context design eigenlijk?

Die functie bestaat een soort van, maar er is nog geen eenduidige rol voor. Afhankelijk van de organisatie kom je delen ervan tegen bij een AI Product Owner, AI System Owner, AI Systems Architect, governance lead of andere rollen.

Je ziet aan die titels al dat het zwaartepunt vaak óf op techniek óf op governance ligt. Terwijl wat ik hier bedoel daar tussendoor loopt.

De context designer (ik gebruik die naam nu maar even) hoeft niet eigenaar te zijn van alle onderdelen van de keten. Ze hoeft de business rules niet te onderhouden, retrieval niet zelf te bouwen en de prompts niet allemaal te schrijven. Maar ze moet wel de hele kaart kunnen overzien: welke onderdelen zijn nodig, wie is eigenaar, welke afhankelijkheden bestaan er, waar kunnen dingen misgaan en wat raakt er verderop als ergens iets verandert?

Haar rol is dus meer “big picture”. Ze zorgt dat de juiste mensen met elkaar praten en blijven praten, maakt gaten in ownership zichtbaar en weet bij problemen waar in de keten de oorzaak waarschijnlijk zit en hoe die ketenbreed uitwerkt.

Of dit uiteindelijk context design, context architecture, AI system ownership of iets anders gaat heten, boeit me eigenlijk minder. Wat mij vooral interesseert is dát die functie er is.

Maarrrrrrrrrrr ook die rol vervangt prompten niet. Ik blijf het gewoon zeggen.

Dus ja, context engineering

Luister, prima dat die term bestaat. Áls we daarmee bedoelen dat we veel bewuster moeten nadenken over wat een LLM tijdens runtime meekrijgt, dan yasss, slay.

Maar laten we dan wel onderscheid maken tussen het technisch samenstellen van context, het zinnig ontwerpen van instructies én het ontwerpen van de keten waaruit context ontstaat. Het eerste is context engineering, het tweede prompt engineering(/of design) en het laatste noem ik hier dus context design.

Wil je stellen dat prompten dood is om duidelijk te maken dat een prompt alleen niet genoeg is: ook prima. Want dat is grenzeloos waar.

Alleen zou ik oppassen dat we niet opnieuw de fout maken door te zoeken naar de One knop(ingreep, deel van de keten) to rule them all.

Eerst deden we alsof de prompt dat was.

Nu moeten we niet doen alsof context het is.

Want een betrouwbaar AI-systeem ontstaat niet doordat één iemand heel goed ‘de context’ engineert. Het ontstaat doordat verschillende afhankelijkheden goed genoeg zijn ingericht, iemand daadwerkelijk eigenaar is van de dingen die moeten kloppen en je kunt zien wat er onderweg gebeurt en hoe dat op de verschillende “stations” ingrijpt.

Misschien is dat uiteindelijk wel de minder sexy boodschap waar we steeds weer bij uitkomen.

Enkel een sterk model is niet genoeg.

Alleen een goede prompt is niet genoeg.

Enkel een volledige context is niet het hele verhaal.

Je moet de volledige flow, inclusief alle vertakkingen, kunnen overzien en goed inrichten.

I know, alweer geen magie. Meh.

En dan nog even terug naar waar dit verhaal begon

Nog even terug naar waar dit allemaal begon. 

Je kunt vinden dat prompt engineering als hype te groot is gemaakt. Je kunt vinden dat iedereen en z’n idiote achterneef zichzelf tegenwoordig prompt engineer noemt. Je kunt zeggen dat een goede prompt nooit genoeg is om een betrouwbaar AI-systeem te bouwen. Je kunt prompt design onder een bredere definitie van context engineering hangen. Allemaal prima en veelal kloppend.

Maar zeggen dat prompting voorbij is, is gewoon feitelijk onjuist.

Zolang een LLM instructies nodig heeft over wat het moet doen, hoe het informatie moet gebruiken, welke grenzen gelden en wat het moet doen als het ergens niet uitkomt, moet iemand die instructies ontwerpen.

Dat werk is niet verdwenen.

We zijn er alleen blijkbaar wel achter dat het niet het enige werk is en niet eens het belangrijkste. Het is één van de schakels, maar wel eentje die gewoon blijft bestaan.