Few-shot prompting: leren met voorbeelden

Bij het ontwikkelen van applicaties met Large Language Models (LLM's) loop je vroeg of laat tegen de beperkingen van standaard zero-shot prompting aan. Je stuurt een instructie mee, maar het model mist net dat stukje context of specifieke outputformaat dat cruciaal is voor je productie-omgeving. Hier komt few-shot prompting om de hoek kijken: een techniek waarbij je het model expliciet voedt met een aantal input-outputvoorbeelden voordat je de eigenlijke vraag stelt.

In deze gids duiken we diep in hoe je few-shot prompting optimaal inzet, waar je op moet letten bij het selecteren van voorbeelden, hoeveel voorbeelden je nodig hebt en welke valkuilen je als developer moet vermijden.

Wat is Few-shot Prompting precies?

Few-shot prompting is gebaseerd op het principe van in-context learning. In plaats van het model te hertrainen of fine-tunen (wat tijdrovend en duur is), demonstreer je direct in je prompt wat je verwacht. Je toont het model een patroon aan de hand van concrete gevallen.

Een standaard prompt geeft enkel een taakomschrijving. Een few-shot prompt voegt daar representatieve paren van invoer en verwachte uitvoer aan toe. Het model herkent het onderliggende format en past dit direct toe op de uiteindelijke vraag.

Hoe kies je kwalitatieve voorbeelden?

De kwaliteit van je output hangt direct af van de kwaliteit van je voorbeelden. Willekeurige voorbeelden werken vaak averechts. Houd rekening met de volgende richtlijnen:

• Dek de randgevallen (edge cases): Zorg dat je niet alleen simpele 'happy flow' voorbeelden opneemt, maar ook toont hoe het model moet reageren op onvolledige data, spelfouten of vreemde invoer.
• Hanteer een consistent formaat: Gebruik exact dezelfde scheidingstekens (zoals Input: en Output:, of Markdown codeblokken) in al je voorbeelden en in de uiteindelijke vraag.
• Wees realistisch: Gebruik data die sterk lijkt op de echte gebruikersdata die je applicatie straks gaat verwerken.

Classificeer de sentimenten:
- Dit product is geweldig! -> Positief
- Meh, kan ermee door.
- Slechte rommel.

Classificeer het sentiment van de onderstaande productreview als [Positief, Neutraal, Negatief]. Geef uitsluitend het label terug.

Voorbeeld 1:
Review: "De batterijduur valt me enorm tegen, na een dag al leeg."
Label: Negatief

Voorbeeld 2:
Review: "Doet wat het moet doen, geen poespas."
Label: Neutraal

Voorbeeld 3:
Review: "Fantastische klantenservice en supersnelle levering!"
Label: Positief

Huidige taak:
Review: "Verpakking was beschadigd, maar het apparaat werkt gelukkig prima."
Label:

Hoeveel voorbeelden heb je nodig?

De heilige graal bestaat niet, maar voor de meeste LLM's geldt een sweet spot van 3 tot 5 voorbeelden.

• 1 tot 2 voorbeelden (1-shot / 2-shot): Voldoende voor zeer simpele format-aanpassingen (bijv. "Zet deze datum om naar ISO-formaat").
• 3 tot 5 voorbeelden (Few-shot): Optimaal voor complexe classificaties, sentimentanalyse, data-extractie of specifieke tone-of-voice stijlen.
• Meer dan 10 voorbeelden: Vaak af te raden. Je loopt het risico op het recency-effect (waarbij het model te veel leunt op het laatste voorbeeld) en je verspilt kostbare context window tokens. Als je meer dan 10 voorbeelden nodig hebt, kun je beter overwegen om te fine-tunen of te werken met dynamic few-shot retrieval (RAG).

Veelgemaakte valkuilen

Zelfs ervaren developers trappen soms in deze klassieke valkuilen bij few-shot prompting:

1. Verontreiniging van de instructie: Het onduidelijk scheiden van de voorbeelden en de daadwerkelijke vraag. Gebruik duidelijke sectie-headers zoals ### Voorbeelden en ### Vraag.
2. Te complexe voorbeelden: Voorbeelden die zelf weer sub-uitleg of uitzonderingen bevatten, verwarren het model. Houd elk voorbeeld kort en atomair.
3. Token-verspilling: Extreem lange lappen tekst in je voorbeelden opnemen terwijl een bondige samenvatting volstaat. Dit vertraagt de inferentietijd en jaagt je kosten onnodig omhoog.