Iteratieve verfijning met voorbeelden

Een effectief few-shot-voorbeeld bestaat uit een gekoppelde invoer en de exacte uitvoer die je terug wilt krijgen. De uitvoer moet overeenkomen met het echte schema of de echte structuur die je in productie gebruikt — dezelfde velden, dezelfde hoofdlettergebruik en dezelfde structuur.

Hieronder toont elk voorbeeld een invoeropmerking plus het precieze oordeel. Het model leert de grens: markeer alleen echte tegenstrijdigheden, niet kleine stijlopmerkingen.

Voorbeelden en expliciete criteria vullen elkaar aan; ze zijn geen alternatieven. Criteria formuleren de regel; voorbeelden kalibreren het grijze gebied dat de regel niet volledig in proza kan vatten.

Een veelgemaakte fout van architecten is voorbeelden geven zonder een sturende instructie. Het model past zich dan te sterk aan oppervlakkige kenmerken van de voorbeelden aan. Begin altijd met een scherp criterium — "markeer alleen wanneer X Y tegenspreekt" — en laat 2-4 voorbeelden vervolgens verduidelijken waar X en Y door elkaar gaan lopen.

Vuistregel: als je het criterium niet in één zin kunt formuleren, is je taak nog steeds onvoldoende gespecificeerd en lossen meer voorbeelden dat niet op.

Iteratieve verfijning is testgestuurd. Stel voordat je de prompt afstemt een kleine gelabelde verzameling representatieve invoer met bekende, correcte uitvoer samen. Dit is je grondwaarheid — elke wijziging aan de prompt wordt hieraan getoetst, niet aan een onderbuikgevoel.

Houd de testset gescheiden van je few-shot-voorbeelden. Als je afstemt op dezelfde gevallen waarmee je het model onderwijst, is het aan het memoriseren in plaats van aan het generaliseren.

De verfijningslus is mechanisch en herhaalbaar:

• Voer uit de prompt op elk testgeval
• Vergelijk de uitvoer met het verwachte label
• Inspecteer de fouten — welke grens heeft het model gemist?
• Voeg één voorbeeld toe of scherp er één aan (of doe hetzelfde met één criterium) dat zich op die fout richt
• Voer de volledige set opnieuw uit en controleer of er niets is verslechterd

Verander één ding per iteratie. Wijzigingen in batches maken het onmogelijk om te weten welke aanpassing heeft geholpen of juist schade heeft veroorzaakt.

Automatiseer de vergelijking zodat itereren snel gaat. Een kleine testomgeving voert elk geval uit, scoort het en toont de missers. Met gestructureerde uitvoer kun je velden rechtstreeks vergelijken in plaats van proza te parseren.

Let hieronder op tool_choice: door een toolaanroep af te dwingen, zorg je ervoor dat het model elke keer JSON teruggeeft die aan het schema voldoet, zodat je scorer niet struikelt over vrije tekst.

Vraag jezelf bij het lezen van een misser af: welke onduidelijkheid heeft dit veroorzaakt? Voeg vervolgens een voorbeeld toe dat precies op die grens ligt — geen willekeurig nieuw geval. Eén scherp voorbeeld per fouttype generaliseert veel beter dan tien algemene voorbeelden.

Stel dat het model ten onrechte een opmerking markeert die de code parafraseert. Dan voeg je een gekoppeld voorbeeld toe dat laat zien: parafrase = geen tegenstrijdigheid. Het model past zijn interne grens aan en de hele klasse van vergelijkbare missers verdwijnt.

Weersta de neiging om steeds meer voorbeelden toe te voegen. Bij meer dan ongeveer 4 per onduidelijkheid maak je de context onnodig groot en loop je het risico op lost-in-the-middle, waarbij het model minder aandacht besteedt aan het midden van een lange prompt.

Sommige fouten zijn opmaak- of structurele fouten, geen redeneerfouten — bijvoorbeeld een ongeldig veld, een verkeerd rekenkundig totaal of een ontbrekende haak. Hiervoor is opnieuw proberen met feedback de oplossing: stuur de oorspronkelijke invoer, de verkeerde uitvoer en de exacte validatiefout terug.

Belangrijke beperking: opnieuw proberen helpt wanneer het model het juiste antwoord kan geven, maar een fout heeft gemaakt. Het helpt niet wanneer de benodigde informatie simpelweg ontbreekt in de bron — hoe vaak je het ook opnieuw probeert, je kunt geen gegevens verzinnen die er niet zijn.

Zodra voorbeelden het gedrag hebben gevormd, leg je de structuur vast met een JSON Schema via toolgebruik. Dit voorkomt syntaxisfouten en dwingt vereiste velden af. Eén regel is het belangrijkst: markeer een veld alleen als vereist wanneer het altijd aanwezig is.

Maak nooit een veld vereist dat kan ontbreken — het model zal een waarde verzinnen om aan het schema te voldoen. Gebruik voor optionele of open gegevens een enum met een waarde "other" plus een vrij tekstveld voor details. Zo blijft het contract uitbreidbaar zonder hallucinaties af te dwingen.

Voordat je de verfijnde prompt vertrouwt, valideer je die met een onafhankelijke, nieuwe instantie — niet met dezelfde sessie die de uitvoer heeft geproduceerd. Een zelfbeoordeling binnen dezelfde sessie is bevooroordeeld: de auteur behoudt zijn eigen redeneerlijn en zal zichzelf niet kritisch bevragen.

Vertrouw ook niet alleen op een totaalscore. Een kop als 97% nauwkeurigheid kan verbergen dat een bepaald veld of invoertype ernstig faalt. Gebruik gestratificeerde steekproeven en vertrouwen op veldniveau, gekalibreerd op een gelabelde validatieset, voordat je automatiseert. De verfijning is niet klaar wanneer het gemiddelde er goed uitziet — ze is klaar wanneer elk segment de norm haalt.

Belangrijkste punten:

• Voorbeelden zijn beter dan bijvoeglijke naamwoorden. Expliciete criteria plus 2-4 gerichte voorbeelden presteren beter dan vage instructies zoals 'wees preciezer'.
• Het model generaliseert vanuit few-shot-voorbeelden — vooral geschikt voor consistentie, randgevallen, uitvoerindeling en het verminderen van hallucinaties.
• Werk testgestuurd: bouw een gelabelde set, scoor die, voeg per fouttype één grensgeval toe, voer opnieuw uit en verander steeds één ding.
• Opnieuw proberen met feedback verhelpt opmaakfouten (stuur de oorspronkelijke invoer + verkeerde uitvoer + exacte fout) — maar geen gegevens die in de bron ontbreken.
• Leg de structuur vast met een JSON Schema; maak alleen altijd aanwezige velden vereist; gebruik enum + 'other' + details voor uitbreidbaarheid.
• Valideer onafhankelijk: beoordeling door een nieuwe instantie is beter dan zelfbeoordeling in dezelfde sessie, en gestratificeerde controles op veldniveau zijn beter dan alleen een geaggregeerde nauwkeurigheid.