# How many examples to give a model

> Learn when to prompt a model with no examples and when to add a few, plus a simple workflow for picking the right approach for each task.

- Type: guide
- Access: free, no account needed
- Category: Prompt Engineering
- Tags: Prompt Engineering
- Added: 2026-11-08

Every prompt sits somewhere on a line between no examples at all and a handful of them. At one end you describe the task and trust the model to infer what you want. At the other you show it two or three finished samples and let it copy the shape. The choice changes accuracy, cost and consistency more than most people expect.

A prompt with no samples is a zero-shot prompt. You state the job and the output format and let the model rely on what it already knows. A prompt with samples is a few-shot prompt. You include a small set of input and output pairs so the model can see the pattern instead of guessing it.

## When to use each

Start with zero examples for common, well-defined tasks. Summarising text, translating a sentence, sorting items into obvious groups and answering direct questions all fall here. Modern models handle these with a clear instruction, and extra samples add length without adding much.

Reach for samples when the task has a shape the model cannot guess. That covers unusual formatting, a house style, borderline categories, or a judgment call where two answers are both plausible. If you have written the same correction twice, that correction is a sample waiting to be included.

Samples also help when you need consistency across many runs. The model anchors to your examples, so outputs drift less from call to call.

## How to build it

1. Write the instruction first, with no samples. Test it on five real inputs and note where it fails.
2. If the failures share a pattern, write two or three examples that show the correct handling of exactly that pattern.
3. Keep each example short. Trim anything that does not teach the model something it needs.
4. Put the examples in the same format as the real input, then end with a fresh input and a clear cue that an answer comes next.
5. Test again on the same five inputs, then on five new ones. Compare against your first run.
6. Stop adding samples once accuracy levels off. Two good examples usually beat six mediocre ones.

## A worked example

Suppose you sort support tickets into teams. A zero-shot instruction like "label each ticket as billing, technical or account" works for clear cases. Then you notice that refund requests keep landing in technical because the word "charge" appears in them.

Add one sample: input "I was charged twice this month and want the extra payment back", output "billing". Add a second for a genuine technical issue that mentions a charge, so the model learns the difference. Now the instruction carries the rule and the examples carry the edge cases.

A good result looks boring. The model returns the same label for the same kind of ticket every time, matches your format exactly, and handles the tricky cases without a special rule for each one. If you still need to explain a case in prose, turn that explanation into an example instead.

HTML version: https://websitespa.net/library/how-many-examples-to-give-a-model