Wat de prompt guide van OpenAI eigenlijk zegt over Astra

OpenAI publiceerde een promptinghandleiding voor GPT-4o Astra. De meeste mensen vlogen erover heen voor snelle tips. Wij lazen het als een foutrapport.

Dat is geen cynische lezing. Het is de eerlijke. Een promptinghandleiding bestaat alleen omdat het model zonder die handleiding iets fouts doet. Elke instructie in het document is een gedocumenteerde foutmodus vermomd als advies. Lees het zo en het wordt het nuttigste wat OpenAI in maanden heeft uitgebracht.

Voor bureaus die op deze modellen bouwen, is dit relevant. Niet omdat de fouten verrassend zijn, maar omdat de officiële documentatie je nu precies vertelt waar de grens ligt.

Wat de handleiding werkelijk zegt

De Astra-promptingdocumentatie behandelt een vertrouwde reeks aanbevelingen: wees specifiek, geef context, splits ingewikkelde taken in stappen, zeg het model welk formaat je wilt. Standaardspul. Niets wat iemand zou verrassen die serieus met deze systemen heeft gewerkt.

Maar neem even de tijd voor elke aanbeveling en vraag je af wat het impliceren.

"Zeg het model welk formaat je wilt" impliceert dat het model zelf een formaat zal kiezen en dat zal vaak fout zijn. "Split ingewikkelde taken in stappen" impliceert dat het model de samenhang verliest over lange meerdelige instructies. "Geef context over jouw publiek" impliceert dat het model naar een generiek publiek defaultt en zijn output op niemand in het bijzonder richt.

De handleiding doet goed dit advies te geven. Het advies klopt. Maar het is tegelijk een openhartige kaart van waar het model zonder expliciete ondersteuning instort.

Astra is een capabel model. Het is ook een model dat, aan zijn eigen defaults overgelaten, output produceert die voor het gemiddelde is gefocust, op niemand is gericht, en meer uit gewoonte dan opzet is gestructureerd.

Drie foutmodi die het noemen waard zijn

Uit de documentatie zijn drie patronen het waard om helder uit te spreken voor iedereen die productieworkflows bouwt.

Standaardformatering is een probleem. Zonder expliciete formateeringsinstructies bereikt het model de structuur die het meest vaak in trainingsdata heeft gezien. Dat betekent meestal markdown-koppen in contexten waar die niet nodig zijn, bullet points waar proza beter zou zijn, en een lengte gekalibreerd om grondig te lijken in plaats van nuttig te zijn. De handleiding adviseert format expliciet in te stellen. Dat is goed advies. Het betekent ook dat elke prompt die je zonder formateeringsinstructie uitstuurt, een prompt is waar het model gist.

Vage taken produceren middelmatig output. Het model is erg goed in iets produceren dat statistisch redelijk is. Het is veel zwakker in iets produceren dat specifiek goed is voor jouw context. Wanneer een taak ondergespecificeerd is, vult Astra de gat door te middelen over wat het weet. Het resultaat is niet verkeerd, precies gezegd. Het is gewoon niet van jou. De handleiding pakt dit aan door gebruikers naar meer context, meer voorbeelden, meer expliciete framing te duwen. Maar het onderliggende patroon is waard om te begrijpen: het model zal altijd output produceren, en die output zal altijd aanvaardbaar lijken. Aanvaardbaar is niet hetzelfde als correct.

Lange instructies verslechteren. Ingewikkelde, meerdelige prompts verliezen samenhang naar het eind toe. Het model volgt het begin goed en verliest precisie als instructies zich opstapelen. De handleiding adviseert taken in stadia op te splitsen. Wat het niet zegt, maar wat direct volgt, is dat de meeste productieprompts die mensen schrijven te lang en te ongedifferentieerd zijn. Eén prompt die vijf dingen doet is niet vijf keer zo capabel. Het is meestal een slechter versie van elk van de vijf.

Waarom bureaus dit anders moeten lezen dan iedereen anders

De meeste lezers van een promptinghandleiding optimaliseren voor hun eigen gebruik: ze willen betere output uit een tool die ze zelf gebruiken. Dat is een redelijk doel.

Bureaus hebben een ander probleem. Ze bouwen systemen die andere mensen zullen gebruiken, of systemen die zonder een mens in de loop draaien. De foutmodi van het model zijn geen persoonlijke ongemakken. Ze zijn productrisico's.

Als je outputpipeline ervan afhangt dat Astra een geschikt formaat kiest, heb je een variabele aanvaard die je niet controleert. Als je workflow een enkele lange prompt stuurt om een ingewikkelde meerdelige taak af te handelen, heb je fraggiliteit in je architectuur ingebouwd. Als je prompts niet zijn getest tegen de gedocumenteerde neiging van het model om output voor een generiek publiek in te zetten, ship je content die voor niemand is geoptimaliseerd.

Dit is de operationele lezing van de handleiding. Niet. hier is hoe je betere antwoorden krijgt. Maar: hier is een checklist van dingen die in productie stukgaan als je ze niet aanpakt.

Bij Studio Hyra kijken we naar de prompts voordat we naar de output kijken wanneer we een klants AI-workflow auditen. De output vertelt je wat er is gebeurd. De prompts vertellen je wat werd aangenomen. Meestal zit het echte probleem in de aannames.

De waarde van officiële documentatie

Er is een nuttige asymmetrie in hoe AI-bedrijven communiceren. De capabilityaankondigingen zijn marketing. De promptingdocumentatie is engineering. De ene zegt je wat het model kan doen onder ideale voorwaarden. De andere vertelt je welke voorwaarden het model daadwerkelijk nodig heeft.

OpenAI heeft nu genoeg richtlijnen gepubliceerd dat de foutpatronen niet moeilijk te zien zijn. Het model worstelt met ambiguïteit. Het heeft sterke defaults die actief moeten worden overschreven. Het presteert beter wanneer voorbeelden worden gegeven dan wanneer instructies abstract worden gesteld. Het heeft nodig dat format wordt ingesteld, publiek wordt benoemd, scope wordt begrensd.

Dit maakt Astra niet tot een slecht model. Het is een erg goed model. Maar zelfs goede modellen hebben plafonds, en de promptinghandleiding is eigenlijk een gepubliceerde kaart van waar die plafonds liggen.

Voor iedereen die serieus op deze systemen bouwt, zijn primaire bronnen waardevoller dan benchmarks. Benchmarks vertellen je hoe het model onder gecontroleerde voorwaarden presteert. De promptinghandleiding vertelt je welke voorwaarden het model nodig heeft om te presteren. Dat zijn verschillende vragen en de tweede matteert meer in productie.

Wat hier mee doen

Als je prompts in productie hebt draaien, check ze tegen de foutmodi in de documentatie. Voor elke prompt: specificeert het format? Grenst het scope af? Benoemt het het publiek? Splitst het de taak in stadia of vraagt het het model alles tegelijk vast te houden?

Als je een nieuwe workflow bouwt, lees de richtlijn voordat je de eerste prompt schrijft. Niet voor tips. Voor constraints. Ontwerp het systeem rond wat het model daadwerkelijk nodig heeft, niet rond wat je hoopt dat het kan afhandelen.

En als je een model voor een nieuw project evalueert, behandel de promptinghandleiding als onderdeel van de technische spec. De capabilitypagina zegt je wat de verkoper wil dat je gelooft. De promptinghandleiding zegt je wat de engineers weten.