Examples, and when they earn their cost
By the end: You can decide whether to include examples and choose good ones.
- Zero-shot and few-shot
- Choosing examples that carry information
- Where examples go in the message list
- What examples cost
New to prompting? A prompt is the text you send a model to tell it what you want: the task, examples of a good answer, the format to reply in, and what to do when it is unsure. It is closer to writing a brief for a capable new colleague than to typing a search query. The model will do what you asked, including the parts you never thought to specify. Why it matters
Few-shot prompting means showing the model a handful of worked cases rather than only describing what you want. It is the oldest trick here and it is not free, because those cases are re-sent with every request you ever make. This section is about deciding whether they earn that space, and about choosing ones that carry information instead of three variations on the same easy case.
Zero-shot first#
Zero-shot means describing the task with no examples. Few-shot means showing a handful of input and output pairs. Start with zero-shot: modern models are good at following a clear description, and examples cost tokens on every single call.
When examples help#
Add examples when the task is easier to show than to describe. An unusual output format, a subtle judgement call, a tone you cannot quite specify. If you find your instructions getting longer and vaguer, that is the signal to switch.
Input: "the button is broken"
Output: BUG | HIGH | UI
Input: "could you add dark mode"
Output: FEATURE | LOW | UI
Input: "charged twice this month"
Output: BILLING | HIGH | ACCOUNTChoose examples that carry information#
Three well-chosen examples beat ten similar ones. Each should teach something the others do not: a boundary case, an ambiguous input, the case where the answer is nothing.
- Include the empty or unknown case, or the model will never produce it.
- Include at least one genuinely ambiguous input, so the model learns which way to lean.
- Keep the format identical across every example. Any inconsistency will be copied.
- Order matters a little. Models weight the last example slightly more, so do not put your weirdest case last.
Your examples become the specification
The model will imitate whatever your examples actually do, including mistakes. A typo in an example becomes a typo in the output. Proofread them as carefully as the instructions.
Where they go#
Either inside the system prompt, or as alternating user and assistant messages that look like a real exchange. The second form usually works better, because it matches the shape of a conversation the model is trained on, and it keeps the system prompt stable for caching.
messages = [
{"role": "system", "content": TASK_DESCRIPTION},
{"role": "user", "content": "the button is broken"},
{"role": "assistant", "content": "BUG | HIGH | UI"},
{"role": "user", "content": "could you add dark mode"},
{"role": "assistant", "content": "FEATURE | LOW | UI"},
{"role": "user", "content": actual_input},
]Examples are input tokens on every request. Five long examples on a high-volume endpoint is a real line on the bill, so measure whether they are earning it.
Where people go wrong
Examples that are all the easy case. The model learns the easy case and has no idea what to do with the hard one, which is exactly the input you needed help with.
If this comes up in an interview
When would you use few-shot rather than zero-shot?
When the task is easier to demonstrate than describe: an unusual format, a subtle judgement, a tone. Start zero-shot, because examples cost tokens on every call, and add them when you can measure that they help.
How many examples should you use?
Usually three to five, chosen so each teaches something different. More similar examples add cost without adding information. Always include the empty or unknown case, or the model will never produce it.
What is a risk of few-shot prompting?
The model imitates the examples closely, including any inconsistency or mistake in them, and it can over-fit to their surface pattern. It can also bias the output distribution if all your examples share a property you did not intend to teach.
Build this: Build a classifier prompt with zero examples, measure it on twenty inputs, then add three examples chosen to cover the boundary cases and measure again. Report both the accuracy change and the token cost change.
Watch it explained
This is one section of Prompting, 10 hours across 3 sections. Read it in full to get the whole topic in order.
Stop 5 of 50 on the AI Engineer route
0 of 50 topics done · 0h behind you, 603h to go
What you have marked done is stored in this browser only. It does not reach a server, and clearing site data will clear it.