How many examples should you give an AI?
The honest answer is: as few as get the job done. Examples teach a model what you mean by 'correct' — the shape of a response, the register, where to stop. They do not add knowledge. Once you have covered the meaningful variation in your task, adding more examples tends to narrow the model's behaviour rather than improve it.
What do examples actually teach a model?
When you drop examples into a prompt, you are not training the model — you are narrowing its interpretation of your instruction. The model reads your examples and infers a pattern: roughly this length, roughly this tone, structured in roughly this way. That inference is useful when your instruction is ambiguous, and genuinely unhelpful when the instruction was already clear.
Examples are most valuable for three things: format (bullet list or prose paragraph?), register (formal or conversational?), and edge-case handling (what should the model say when it does not know?). They are least valuable for factual tasks where the answer is either right or wrong regardless of how it is presented.
- Format
- The physical shape of the output — length, structure, use of lists or tables. An example settles this faster than a paragraph of instruction.
- Register
- The social distance between writer and reader — formal, friendly, technical, plain. One well-chosen example sets this more precisely than adjectives like 'professional' or 'warm'.
- Edge-case handling
- What the model should do when the input is ambiguous, out of scope, or genuinely unanswerable. An example of a graceful refusal is worth several sentences of instruction.
- Scope
- The boundary of what the task covers. An example that sits just inside the boundary, and one that sits just outside it, together define the line more reliably than a rule alone.
Why does a model copy examples too literally?
A model treats your examples as evidence about what 'good' looks like. If all your examples use em-dashes, it will use em-dashes. If they all end with a question, it will end with a question. If they all happen to be about the same topic, it may quietly assume that topic is the domain and behave oddly when the real input differs.
This is not a bug — it is the mechanism working as intended. The problem arises when the examples you chose were convenient rather than representative. You grabbed three outputs you liked, and they happened to share a quirk. The model learned the quirk.
Order matters too. Models weight recent context more heavily, so the last example before the actual input has disproportionate influence. If your final example is your longest, your outputs will skew long. If it is your most hedged, the model will hedge more than you want.
How should you pick which examples to include?
Start by asking what varies in your real inputs. If tone is the only thing that varies, one example may be enough. If you have short inputs and long inputs, ambiguous inputs and clear ones, include one of each type — not to cover every case, but to show the model that variation exists and that the same output shape is expected across it.
Always include at least one example where the right answer is 'I don't know' or 'I can't help with that'. Without it, the model has no evidence that declining is acceptable, and it will tend to confabulate rather than admit a gap. The example does not need to be elaborate — a single input with a clean, honest refusal is enough.
Check your examples for accidental patterns before you use them. Read them as a set: do they all use the same sentence structure? Do they all happen to be positive in sentiment? Do they all avoid a certain word? If so, decide whether that pattern is intentional. If it is not, replace one example with something that breaks it.
| What varies | Example type to include | What it teaches |
|---|---|---|
| Output length | One short, one long input with matching outputs | That length should follow the input, not a fixed template |
| Certainty | One clear answer, one honest refusal | That declining is acceptable when the answer is not known |
| Register | One formal, one plain-language version of the same content | Where on the formality scale to sit for a given audience |
| Scope | One in-scope input, one out-of-scope input | Where the task boundary sits, without a rule that tries to define it |
| Edge case | One ambiguous or incomplete input with a clarifying response | That asking a question is sometimes the right output |
When is a simpler approach the better choice?
If your instruction is already precise and the output format is standard — a JSON object with defined fields, say, or a one-sentence summary — examples add friction without adding value. The model can follow a clear schema without being shown one. In those cases, examples introduce surface patterns that may conflict with the schema rather than reinforce it.
Examples are also less useful when your task requires the model to reason through something novel. An example of a previous reasoning chain can anchor the model to that chain's structure even when the new problem calls for a different approach. For genuinely open-ended reasoning, a clear goal and explicit constraints tend to outperform a set of worked examples.
If you find yourself writing more than a handful of examples to cover your task, that is usually a sign the task is under-specified rather than that more examples are needed. Clarify the instruction first, then check whether the examples are still necessary.
Common questions
How many examples should I include in a prompt?
Use as few as cover the meaningful variation in your task. One example can be enough if your task is consistent. Add examples only when they each teach something the others do not — a different format, a different edge case, a refusal. Beyond a small set, additional examples tend to narrow the model's behaviour rather than improve it.
Does the order of examples in a prompt matter?
Yes. Models weight recent context more heavily, so the last example before the actual input has the strongest influence on the output. If your final example is unusually long, hedged, or structured differently from the others, that quirk will show up in your results. Put your most representative example last.
Should I include an example where the model says 'I don't know'?
Yes, if there is any chance the real inputs will include questions the model cannot reliably answer. Without a refusal example, the model has no evidence that declining is acceptable and will tend to produce a plausible-sounding answer rather than admit uncertainty. A single clean refusal example is usually enough to establish that the behaviour is permitted.
Can too many examples make a model worse?
They can make it less flexible. A large set of examples teaches the model a narrow pattern, and inputs that sit outside that pattern may produce outputs that fit the pattern anyway rather than fitting the input. They also make prompts harder to maintain: when your task changes, you have to audit every example rather than update a single instruction.
If you want to test a prompt across varied inputs before it runs on real data, GROX lets you iterate in the same session with memory of what you have already tried.