예시 2~4개가 효과적인 이유

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Scenario question — pick the best answer.

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.