Few-Shot Prompting: LLMs Leren van Voorbeelden

Zero-shot prompts werken verrassend goed voor simpele taken. Maar zodra de output een specifiek formaat moet volgen of domeinkennis vereist, vallen ze door de mand. Het model raadt dan maar wat, en die gok is lang niet altijd goed.

Few-shot prompting lost dat op door het model concrete voorbeelden te geven. Niet uitleggen wát het moet doen — gewoon laten zíén.

Waarom Voorbeelden Beter Werken dan Instructies

Neem een classificatietaak. Een support ticket moet in een categorie: billing, technical, feature-request of other.

De zero-shot variant:

Classificeer het volgende support ticket in een van deze categorieën:
billing, technical, feature-request, other.

Ticket: "Mijn factuur klopt niet, er staat een dubbele charge op."

Werkt dit? Meestal wel. Maar de output is onvoorspelbaar. Soms komt er Billing uit, soms billing, soms een heel verhaal eromheen. In een pipeline die JSON verwacht, breekt dat meteen.

Met few-shot:

Classificeer support tickets. Geef alleen de categorie terug, lowercase.

Ticket: "Ik kan niet inloggen sinds de update"
Categorie: technical

Ticket: "Kunnen jullie dark mode toevoegen?"
Categorie: feature-request

Ticket: "Mijn factuur klopt niet, er staat een dubbele charge op."
Categorie:

Nu snapt het model het formaat. Geen uitleg nodig. De voorbeelden zéggen alles.

Het Juiste Aantal Voorbeelden

Meer voorbeelden is niet automatisch beter. Bij de meeste modellen geldt:

• 1-2 voorbeelden — genoeg voor simpele format-taken
• 3-5 voorbeelden — ideaal voor classificatie en extractie
• 5+ — zelden nodig, tenzij er subtiele edge cases zijn

Elk voorbeeld kost tokens. Bij GPT-4 of Claude tikt dat aan. Een prompt met twintig voorbeelden is duur én traag, terwijl vijf goed gekozen voorbeelden hetzelfde resultaat geven.

De kwaliteit van voorbeelden telt meer dan de kwantiteit. Twee slecht gekozen voorbeelden doen meer kwaad dan helemaal geen voorbeelden.

Structured Output Afdwingen

Few-shot helpt enorm, maar voor productiesystemen is het niet genoeg om te hopen dat het model het format volgt. Moderne APIs bieden tools om output structuur af te dwingen.

OpenAI's Response Format

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "ticket_classification",
            "schema": {
                "type": "object",
                "properties": {
                    "category": {
                        "type": "string",
                        "enum": ["billing", "technical",
                                 "feature-request", "other"]
                    },
                    "confidence": {
                        "type": "number"
                    }
                },
                "required": ["category", "confidence"]
            }
        }
    },
    messages=[
        {"role": "system", "content": "Classificeer support tickets."},
        {"role": "user", "content": "Mijn factuur klopt niet."}
    ]
)

De output is gegarandeerd valide JSON die het schema volgt. Geen parsing-hacks nodig, geen regex om de categorie eruit te vissen.

Anthropic's Tool Use als Structured Output

Bij Claude werkt hetzelfde principe via tool definitions:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=256,
    tools=[{
        "name": "classify_ticket",
        "description": "Classificeer een support ticket",
        "input_schema": {
            "type": "object",
            "properties": {
                "category": {
                    "type": "string",
                    "enum": ["billing", "technical",
                             "feature-request", "other"]
                },
                "confidence": {"type": "number"}
            },
            "required": ["category", "confidence"]
        }
    }],
    tool_choice={"type": "tool", "name": "classify_ticket"},
    messages=[
        {"role": "user",
         "content": "Classificeer: Mijn factuur klopt niet."}
    ]
)

Zelfde idee, andere API. Het model wordt gedwongen om via de tool te antwoorden, waardoor de output altijd het juiste schema volgt.

Few-Shot + Structured Output Combineren

De sweet spot zit in de combinatie. Few-shot voorbeelden in de system prompt leren het model de inhoudelijke regels. Structured output dwingt het formaat af.

system_prompt = """Classificeer support tickets.

Voorbeelden:
- "Kan niet inloggen" → technical, confidence 0.95
- "Factuur klopt niet" → billing, confidence 0.9
- "Graag dark mode" → feature-request, confidence 0.85
- "Jullie zijn geweldig!" → other, confidence 0.7

Let op: vage complimenten of feedback zonder actie = other.
Twijfelgevallen krijgen lagere confidence."""

De voorbeelden sturen de classificatie-logica. Het JSON schema voorkomt format-problemen. Twee lagen betrouwbaarheid.

Veelgemaakte Fouten

Voorbeelden die te veel op elkaar lijken. Als alle voorbeelden over facturen gaan, leert het model niets over de andere categorieën. Variatie is essentieel.

Tegengestelde voorbeelden. Eén voorbeeld dat "niet inloggen" als technical classificeert en een ander dat "login probleem" als billing bestempelt. Het model raakt in de war, en de output wordt willekeurig.

Te lange voorbeelden. Een voorbeeld van tien zinnen lang terwijl de echte input meestal twee zinnen is. Het model gaat dan ook lange outputs genereren. Hou voorbeelden representatief voor de werkelijke data.

Wanneer Few-Shot Niet Genoeg Is

Sommige taken zijn te complex voor prompt engineering alleen. Als de classificatie afhankelijk is van bedrijfsspecifieke kennis die niet in een paar voorbeelden past, of als de accuracy boven de 95% moet liggen, dan is fine-tuning een betere optie.

Maar voor 80% van de use cases? Few-shot met structured output is snel op te zetten, makkelijk te itereren, en goed genoeg. Het kost geen trainingsdata, geen GPU-tijd, en wijzigingen zijn een prompt-edit in plaats van een retrain.

Pragmatisch kiezen. Niet elke schroef heeft een voorhamer nodig.