Pourquoi 2 à 4 exemples fonctionnent
C’est suffisant pour établir un modèle, tout en restant assez peu nombreux pour conserver sa généralité.
Pourquoi 2 à 4 exemples fonctionnent est une leçon Claude Architect gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Claude Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Claude Architect comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
The Core Idea
Few-shot prompting works because Claude generalizes from examples — it doesn't just memorize and repeat them. The exam fact sheet is precise about the dose: use 2-4 targeted examples per ambiguity.
That range is not arbitrary. It is enough to set a pattern, yet few enough to keep the model general. This lesson explains why that sweet spot holds for production work.
Examples Teach a Rule, Not a Lookup Table
When you show Claude 2-4 examples, you are demonstrating a rule: this input shape maps to that output shape. The model infers the underlying pattern and applies it to new, unseen inputs.
This is why few-shot is the go-to tool for consistency, edge cases, output format, and reducing hallucination — all areas where a vague instruction leaves too much room for drift.
system = (
"Classify each support message as: billing, technical, or other.\n"
"Examples:\n"
"Message: 'My card was charged twice' -> billing\n"
"Message: 'The app crashes on login' -> technical\n"
"Message: 'Do you have a dark mode?' -> other"
)
# 3 examples set the mapping rule; Claude generalizes to new messages.Why Not Zero Examples?
Zero-shot relies entirely on your instruction wording. For genuinely ambiguous tasks, words alone under-specify the boundary. The fact sheet stresses that explicit criteria beat vague guidance — but even sharp criteria sometimes need a concrete demonstration to lock in.
A single well-chosen example resolves ambiguity that a paragraph of prose cannot. That is the floor of the 2-4 range: at least a couple of demonstrations per ambiguous decision.
Why Not One Example?
One example is risky: the model can over-fit to its surface features — a specific phrasing, length, or coincidental detail — and treat that accident as part of the rule.
A second and third example let Claude triangulate what actually varies versus what stays constant. The shared structure becomes the signal; the incidental differences become noise to ignore.
# One example: model may copy the exact tone/length.
# Two+ examples reveal what is INVARIANT (the JSON shape)
# versus INCIDENTAL (the specific values).
examples = [
{"review": "Loved it, fast shipping!", "out": {"sentiment": "positive"}},
{"review": "Broke after a day.", "out": {"sentiment": "negative"}},
]
# The constant is the {"sentiment": ...} schema, not the wording.Why Not 20 Examples?
If a few examples are good, why not flood the prompt? Two reasons.
- Over-specialization: with too many examples, Claude can start mirroring their exact style and stop generalizing — it narrows to the training set instead of the rule.
- Context cost: long example blocks eat the context window and worsen lost-in-the-middle, where the model attends less to content buried in the middle.
2-4 keeps the demonstration sharp and the prompt lean.
Stay General: Cover the Decision, Not Every Case
The goal of few-shot is to set a pattern, not to enumerate the world. If you find yourself adding a 10th example to handle one more case, that is a signal: the task probably needs clearer criteria or a structured output schema, not more examples.
Examples that disagree with each other or pile up only confuse the rule and dilute attention. Keep each demonstration earning its place.
One Set Per Ambiguity
Read the fact sheet phrasing carefully: 2-4 examples per ambiguity. The budget is scoped to each distinct point of confusion, not the whole prompt.
If a task has two separate ambiguous decisions — say, how to classify and how to format the date — give a small targeted set for each. You are not capped at four examples total; you are capped at a focused few per decision you are disambiguating.
# Ambiguity 1: category boundary (3 examples)
# Ambiguity 2: date normalization (2 examples)
# Each ambiguity gets its own small, targeted set.
prompt = f"""
Category examples:
'refund my order' -> billing
'page is blank' -> technical
'how do I export' -> other
Date examples:
'next Tuesday' -> 2026-06-16
'06/10' -> 2026-06-10
Now process: {user_message}
"""Choose Examples That Mark the Boundary
Quality beats quantity. Two examples that sit right on the decision boundary teach more than ten obvious ones. Pick cases that are easy to get wrong: the near-miss, the edge case, the input that looks like one category but belongs to another.
This is exactly why the fact sheet ties few-shot to edge cases — a couple of well-placed contrast pairs define the rule far better than a heap of central, unambiguous samples.
Few-Shot Plus Structured Output
For output shape, pair a couple of examples with a JSON Schema via tool_use. The schema enforces required fields and eliminates syntax errors; the 2-4 examples teach the judgment the schema can't express — which value belongs in which field on a tricky input.
Remember the schema rule: mark a field required only if it is always present. Never require a possibly-absent field, or the model will fabricate one.
tools = [{
"name": "record_ticket",
"description": "Save a classified support ticket.",
"input_schema": {
"type": "object",
"properties": {
"category": {"enum": ["billing", "technical", "other"]},
"priority": {"enum": ["low", "high"]},
},
"required": ["category"], # priority may be absent -> not required
},
}]
# tool_choice="any" guarantees a structured call; examples teach the judgment.Few-Shot vs. Retry-With-Feedback
Don't confuse the two. Few-shot sets the pattern up front so the first response is right. Retry-with-feedback fixes a specific bad response after the fact by resending the original input, the wrong output, and the exact validation error.
Adding more examples won't fix a missing-information failure — retry can't recover info that is simply absent from the source either. Use examples to shape behavior; use retry to repair format/arithmetic slips.
A Practical Recipe
For any ambiguous prompt:
- Write explicit criteria first (vague instructions are the weak baseline).
- Add 2-4 examples per remaining ambiguity, chosen on the decision boundary.
- Reach for a schema when the gap is output shape, not judgment.
- If you keep adding examples, stop — fix the criteria or the schema instead.
Enough to set a pattern; few enough to stay general.
system = """Flag a code comment ONLY when it contradicts the code.
Examples:
Code: x = a + b Comment: 'subtract b' -> FLAG (contradicts)
Code: x = a + b Comment: 'sum a and b' -> OK
Code: retry(3) Comment: 'retry twice' -> FLAG (count wrong)
"""
# Explicit criterion + 3 boundary examples = consistent, general behavior.Checkpoint: Choosing the Example Count
Scenario question — pick the best answer.
Recap
Key takeaways:
- 2-4 examples per ambiguity is the sweet spot — Claude generalizes from them, it doesn't just repeat them.
- Too few (0-1) under-specifies or over-fits to surface detail; too many over-specializes and wastes context, hurting attention to the middle.
- Pick examples on the decision boundary; quality beats quantity.
- Pair examples with explicit criteria and, for output shape, a JSON Schema — and never require a possibly-absent field.
- If you keep adding examples, fix the criteria or schema instead.
Questions Fréquemment Posées
La leçon « Pourquoi 2 à 4 exemples fonctionnent » est-elle gratuite ?
Oui — le texte complet de « Pourquoi 2 à 4 exemples fonctionnent » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Claude Architect, passe à CoddyKit PRO. Le cours Claude Architect comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Pourquoi 2 à 4 exemples fonctionnent » ?
C’est suffisant pour établir un modèle, tout en restant assez peu nombreux pour conserver sa généralité. Tu pratiques Claude Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Claude Architect ?
Aucune expérience préalable n'est requise. Claude Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.
Combien de temps prend la leçon « Pourquoi 2 à 4 exemples fonctionnent » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Claude Architect ?
Oui. Chaque leçon Claude Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Pourquoi 2 à 4 exemples fonctionnent
- Exemples de format et de cas particuliers
- Généralisation ou répétition
- Few-shot pour réduire les hallucinations