Few-shot prompting is useful when examples show the model a pattern that would be cumbersome, ambiguous, or fragile to specify with instructions alone. It tends to help especially with classification, transformation, extraction, and generation tasks that require a very specific output pattern. But examples are not an automatic improvement: when they repeat what the instruction already makes clear, cover unrepresentative cases, conflict with one another, or consume too much context, they can add noise instead of signal.
What changes when a prompt includes examples
In a zero-shot prompt, the model receives the task and must infer on its own how to perform it and format the answer. In a few-shot prompt, a small set of input-output pairs concretely demonstrates the expected behavior. OpenAI documentation describes few-shot as using a handful of examples to steer a model toward a new task, while Google notes that examples help regulate formatting, scope, and general response patterns. Anthropic recommends examples that are relevant, diverse, and structured.
The practical effect does not come from the number of examples alone. Each example adds clues about which features matter, how ambiguities should be handled, and what output form should be imitated. One strong example can therefore remove an ambiguity that would otherwise require several lines of instruction, while many weak examples can teach accidental patterns.
When few-shot usually helps
1. When the desired format is hard to describe precisely
If the output must follow a specific convention, such as an exact label, a short structure, a textual schema, or a consistent transformation, a correct example can make the rule more concrete. This is especially useful when small variations in style or structure already count as errors.
2. When the task depends on subtle distinctions
Classifying messages into nearby categories, deciding whether a passage belongs to one class or another, or applying tone criteria can require boundaries that are not fully clear from an abstract definition. Examples close to those boundaries help show what belongs and what does not.
3. When recurring edge cases exist
An example set can include situations that historically cause errors. In this case, the goal is not to repeat obvious cases but to demonstrate what to do with unusual, incomplete, or ambiguous inputs.
4. When the instruction is short but the expected behavior has many details
For some tasks, writing every rule in prose makes the prompt long and difficult to maintain. Well-selected examples can act as an executable specification of behavior. Even so, they should complement rather than contradict the main instruction.
When examples only add noise
Redundant examples
If three or four examples demonstrate exactly the same simple pattern, the marginal gain may be small. OpenAI's current model guidance recommends leaner prompts and suggests removing repeated instructions and examples one group at a time while measuring results. The practical principle is to keep examples when they encode a real requirement or correct an observed failure.
Inconsistent examples
If two examples apply different criteria to similar inputs, the model receives competing signals. This can appear as conflicting labels, different levels of detail, divergent formats, or unexplained exceptions. Before increasing the count, check whether all examples follow the same rule.
Unrepresentative examples
A set made only of easy cases can create the false impression that the prompt is robust. Google recommends specific and varied examples and warns that too many examples can make the model overfit to the patterns shown. Anthropic similarly emphasizes relevance and diversity so the model does not learn accidental traits.
Too much context for a simple task
Every example occupies context and increases the number of tokens processed. For tasks already solved by a clear instruction, demonstrations can raise cost, latency, and maintenance complexity without producing measurable improvement. In long prompts, useful information may also compete for attention with redundant material.
How to decide: test zero-shot against few-shot
The most reliable decision is experimental. Instead of assuming that examples help, create a small representative test suite and compare variants of the same prompt. OpenAI documentation recommends working with evaluations, measuring a baseline, and repeating the cycle after each change.
| Variant | What it contains | Test objective |
|---|---|---|
| A | Clear instruction, no examples | Establish a zero-shot baseline |
| B | Same instruction + 1 or 2 strong examples | Measure whether the required pattern appears with few examples |
| C | Same instruction + varied examples and edge cases | Test robustness on difficult situations |
| D | Lean version with redundant examples removed | Check whether quality holds with less context |
Build a test set that can expose differences
A useful test should not contain only inputs that resemble the examples in the prompt. Separate common cases, edge cases, ambiguous inputs, and items that change only one relevant detail. For a classification task, for example, include items that clearly belong to each class and items near the decision boundary. For text transformation, vary length, order, tone, and the presence of optional fields.
Also define what success means before running the test. Depending on the task, criteria may include label accuracy, valid formatting, presence of required fields, absence of extra text, fidelity to the source, or human evaluation. Without fixed criteria, it is easy to prefer one variant simply because a single answer looks better.
A practical process for selecting examples
- Start with the clearest possible instruction and measure performance without examples.
- List the real error types that appear in that baseline.
- Add examples that represent those errors or boundaries, avoiding cases that merely repeat the obvious.
- Keep example formatting consistent so you do not introduce conflicting signals.
- Include enough diversity so the model does not associate the rule with an irrelevant detail.
- Run the same test set again and compare metrics and errors, not just impressions.
- Remove one group of examples at a time and verify whether quality falls. If it does not, that group was probably unnecessary.
Few-shot does not replace a poor instruction
Examples can demonstrate behavior, but they do not automatically repair an ill-defined task. If the objective, constraints, or success criteria are vague, the model may imitate the examples without understanding which rule should generalize to new cases. First make clear what must be done; then use examples to show how that rule appears in practice.
The ideal number depends on the task
There is no universal number of examples that maximizes quality. Anthropic recommends a small set of well-chosen examples and currently cites three to five as a useful reference, while Google notes that the optimal number needs experimentation and that too many examples can lead to overfitting to the demonstrated pattern. For another model, task, or input distribution, the balance can change.
In practice, the best policy is to use the smallest set that solves a measured failure. If zero-shot already meets the criteria, there is no obligation to add few-shot examples. If two examples fix the problem, ten examples need to justify their added cost with better results.
Operational rule
Use few-shot when each example contributes information that the instruction alone does not convey as clearly, such as a decision boundary, an edge case, or a difficult format. Remove examples when they only repeat the rule, introduce unintended exceptions, or fail to improve the test set. The goal is not to make a fuller prompt, but to make one that generalizes better across real inputs.
