What is the difference between zero-shot, one-shot and few-shot prompting?

Zero-shot gives instructions only. One-shot gives a single worked example. Few-shot gives several, conventionally two to five. The largest quality jump is from zero to one, because one example fixes format, length and register at once.

Does few-shot prompting train the model?

No. Nothing about the model changes. The examples are ordinary text in the prompt, read fresh each time and forgotten afterwards. Fine-tuning changes the model; few-shot prompting does not.

How many examples is too many?

Past five or six, added examples rarely change output much while consuming context and cost. If you need dozens to get consistent behaviour, that is a signal the task needs fine-tuning or decomposition, not more examples.

Should examples be perfect or realistic?

Realistic. Examples made only of clean, ideal input produce a prompt that handles only clean, ideal input. Include at least one example resembling the messiest thing you actually expect to send.

Can few-shot examples make output worse?

Yes, in two ways. Inconsistent examples teach the model that consistency is optional. And accidental patterns — all examples on one topic, or all with short answers — get inferred as rules you never intended.

Few-shot prompting

Published 2026-07-26

Few-shot prompting is giving a model several worked examples inside the prompt so it can infer the pattern and apply it to new input. Two to five examples is the usual range. It works because an example communicates format, length, register and depth simultaneously — all things that stay ambiguous when described in prose.

What is few-shot prompting?

Few-shot prompting is giving a model several completed examples of a task before asking it to perform that task on new input. The examples are part of the prompt itself, not training data — nothing about the model changes, it simply has a pattern in front of it to continue.

The names follow the count. Zero-shot means instructions only. One-shot means a single example. Few-shot conventionally means two to five. Beyond about five, returns diminish while context fills up.

Why do examples work better than instructions?

Because an example carries several specifications at once, and every one of them is exact.

Describing an output in prose means describing its format, its length, its register, its depth, and its structure — and every one of those descriptions is open to interpretation. "Keep it brief and professional" leaves both properties undefined. A single example fixes all of them simultaneously, without a word of description.

This is pattern matching, and it is one of the strongest behaviours a language model has. The model continues the structure it has been shown, which is enormously useful when the structure is deliberate — and a liability when it is accidental.

How many examples should you use?

Count	When it fits	Watch for
0	Common tasks with an obvious output shape: summarise, translate, answer.	Format drifts between runs.
1	Any task with a specific format or house style.	The model may treat incidental details of that one example as rules.
2–3	Most classification, extraction and formatting work.	Examples must be consistent with each other.
4–5	Tasks with genuine edge cases the model needs to see handled.	Context cost starts to matter.
6+	Rarely worth it.	Diminishing returns; consider fine-tuning instead.

The jump from zero to one is by far the largest. If you add nothing else to a weak prompt, add one example.

What makes a good example?

Four properties, in rough order of importance.

Consistent with each other. Every example must use identical formatting, identical field order, identical punctuation. A single inconsistency teaches the model that formatting is optional.
Representative of the real range. If a third of your real inputs are messy, one example should be messy. Examples made of tidy, ideal input produce a prompt that only handles tidy, ideal input.
Correct in every detail. The model imitates everything, including your mistakes. A typo in an example becomes a licensed typo.
Free of accidental patterns. If all three of your examples happen to be about finance, the model may infer that finance is part of the task.

The accidental-pattern trap is the subtle one. Three examples that all happen to have short answers will teach the model that answers are short, even though you never said so and did not mean it.

Should you include examples of edge cases?

Yes, and this is where few-shot prompting earns its keep. Describing what to do with a missing field takes a paragraph and is still ambiguous. Showing it takes three lines and is exact.

<example>
<input>ACME LTD
INV-4471
2026-03-02
£1,240.00</input>
<output>{"vendor":"ACME LTD","invoice":"INV-4471","date":"2026-03-02","total":"1240.00"}</output>
</example>

<example>
<input>Handwritten receipt, vendor illegible
2026-03-08
£42</input>
<output>{"vendor":null,"invoice":null,"date":"2026-03-08","total":"42.00"}</output>
</example>

The second example does more work than a paragraph of instructions could. It demonstrates that missing values become null rather than an empty string or a guess, that dates survive when other fields do not, and that currency symbols are stripped — three rules, shown rather than argued.

How should examples be formatted in a prompt?

Delimit them clearly and label the parts. The model needs to see where each example begins and ends, and which part is input and which is output.

For Claude, nested XML tags are the most reliable: an <examples> block containing <example> elements, each with <input> and <output>. For ChatGPT and Gemini, a markdown heading per example with bolded Input: and Output: labels works well. What matters is consistency, not the specific choice.

Place examples after the context and before the task for most work. The exception is extraction: put the output schema first, then examples, then the source material, so the model reads the target shape before the content it has to fit into it.

When does few-shot prompting not help?

When you want variety. Examples cause imitation. For brainstorming, examples narrow the output toward what you showed.
When the task is genuinely open-ended. A long-form essay has no compact example, and a truncated one teaches truncation.
When examples would consume context you need. With a large source document, the material matters more than the demonstration.
With reasoning models. Extended-deliberation models often do better with a clear specification than with examples that constrain their approach.

Common questions

What is the difference between zero-shot, one-shot and few-shot prompting?: Zero-shot gives instructions only. One-shot gives a single worked example. Few-shot gives several, conventionally two to five. The largest quality jump is from zero to one, because one example fixes format, length and register at once.
Does few-shot prompting train the model?: No. Nothing about the model changes. The examples are ordinary text in the prompt, read fresh each time and forgotten afterwards. Fine-tuning changes the model; few-shot prompting does not.
How many examples is too many?: Past five or six, added examples rarely change output much while consuming context and cost. If you need dozens to get consistent behaviour, that is a signal the task needs fine-tuning or decomposition, not more examples.
Should examples be perfect or realistic?: Realistic. Examples made only of clean, ideal input produce a prompt that handles only clean, ideal input. Include at least one example resembling the messiest thing you actually expect to send.
Can few-shot examples make output worse?: Yes, in two ways. Inconsistent examples teach the model that consistency is optional. And accidental patterns — all examples on one topic, or all with short answers — get inferred as rules you never intended.
Where should examples go in the prompt?: After the context and before the task, for most work. For extraction, put the output schema first, then examples, then the source material, so the model knows the target shape before reading the content.