The three cases that have names
- Zero-shot — instruction only, no example. "Categorise this email."
- One-shot — one sample. "Here is what a good categorisation looks like: …"
- Few-shot — several samples, typically three to five.
The counting is not for its own sake: the model does not learn a rule from examples, it picks up a pattern. From a single example it cannot yet tell what is essential and what is accidental. From several, it can.
When is it worth more than an instruction?
When the rule is harder to write down than it is to recognise.
- Tone. "Be friendly but not chummy" means five different things to five people. Two of your earlier emails are unambiguous.
- A fixed form. Describing a strict template takes half a page; one filled-in sample takes three lines.
- Edge cases. "What counts as urgent?" — one example of something urgent and one of something that nearly is says more than any definition.
- Your own vocabulary. What things are called at your company. It cannot guess this, only see it.
Where the rule can be stated precisely — "at most 150 words", "the date format is YYYY-MM-DD" — write it as a rule. That is shorter and more reliable than an example.
How many examples, and which?
The providers' own guidance says three to five. Fewer and the pattern does not form; more and you are spending context window faster than you are improving the result.
More important than the count is that they differ from each other. Include one easy case, one typical one, and one that has never gone well. A set of examples is good when it covers the range the real tasks move in.
The trap nobody talks about
The model picks up everything the examples have in common — including the things you did not know about.
If all four of your sample emails happen to be addressed to men, are short, and come from a Friday afternoon, the model treats those as pattern too. If every one is three paragraphs, do not be surprised that you never get four. If every one contains an apology, it will apologise even when nothing went wrong.
Two practical rules follow:
- Look at your examples and ask what they have in common that you did not put there on purpose. That takes five minutes and catches half the errors.
- Any trait present in all of them becomes a rule. If that is what you want, fine. If not, change one example.
Where should the examples go?
Separated from the instruction. If the examples blend into the text, the model may treat them as part of the task and try to answer the sample instead of following it.
The reliable solution is simple marking — a label, a separator line, or an XML-like tag:
<example>
Input: The delivery was three days late.
Output: category=shipping, urgency=2
</example>
This is covered in more depth by Delimiters and Sections, a separate article. The point here is only this: there should be a visible boundary between where the sample ends and the real task begins.
An example that shows the difference
The task: incoming emails have to be categorised into one line.
With instruction only:
Categorise the email. Possible categories: billing, shipping, complaint, other. Also give an urgency from 1 to 3.
This will work — roughly. In edge cases it will waver: is an angry email about a late delivery a complaint or a shipping issue? And what does your urgency scale actually mean?
With three examples:
[the same instruction]
<example> "This is the third time I'm asking for the February invoice." → billing, 2 </example> <example> "The parcel was three days late, but it arrived." → shipping, 1 </example> <example> "The delay cost us the event, I'm not letting this go." → complaint, 3 </example>
The third example is what made the whole thing worth it: it shows that the consequence decides, not the topic. That would have been hard to write down as a rule.
When examples are not enough either
If it will not hold the format reliably even with twenty examples, or if you have to supply so many examples per request that it gets expensive, you have outgrown prompting. That is when further training comes into play — Fine-tuning, RAG or a Better Prompt? tells you which case is yours.
What to take away
An example is not decoration, it is the shorter form of a specification. Three to five samples that differ from each other, separated from the instruction, and one check question to yourself: what do they have in common that I did not intend?