Few-Shot Prompting: Teaching with Examples

Few-shot prompting is putting a few solved examples in the prompt so the model copies the pattern. When it works, how to choose them and what to do if it fails.

info Quick Definition

Few-shot prompting means including a few input and desired-output examples in the prompt so the model follows the same pattern on a new input. It does not change the model: the learning happens inside the request, from what it is shown.

What is it and where does it come from?

The term comes from OpenAI’s 2020 paper Language Models are Few-Shot Learners (Brown et al.), which introduced GPT-3, a model with 175 billion parameters. The authors showed that a large model could take on new tasks just by being given demonstrations in the input text, without updating its weights or retraining it. They distinguish three cases:

Case	What the model receives
Zero-shot	Only a natural-language instruction
One-shot	The instruction and one example
Few-shot	The instruction and a few examples

In that paper, the number of examples is typically between 10 and 100, because that is how many fit in a 2048-token context window. Today’s windows are much larger, but the idea has not changed: examples compete for space with the rest of the prompt. More on that limit in context window. The same paper acknowledges that few-shot still struggles on some datasets, so it is not a guarantee.

A simple case: to classify user comments as “complaint”, “suggestion” or “praise”, you include four comments with their labels. Then you write the new comment. The model answers in the same structure and, usually, with criteria similar to the ones you showed.

This article focuses on examples. For the full picture of instructions, context and structure, read prompt engineering for designers.

Why does this matter to a designer?

Because examples are the most direct way to define a quality standard that is hard to explain in words. Anthropic describes them as one of the most reliable ways to steer the format, tone and structure of the output.

Tone. Describing “warm but professional” is ambiguous. Two approved examples make it concrete.
Format. Showing what an answer should look like, with its sections, keeps it from changing on every call. If the format must be exact, also look at structured outputs.
Edge cases. An example of what should be rejected teaches the boundary better than an abstract rule.
Access to the process. A designer can write examples without coding, which makes them a real part of the team that defines the behavior.

How do you choose the examples?

The official guides agree on the essentials. Anthropic asks for relevant, varied examples wrapped in tags so they can be told apart from instructions, and suggests 3 to 5. OpenAI asks for a diverse range of inputs. Google asks for identical structure and formatting across examples, and warns that if you include too many, the model may overfit its response to them. A practical method based on that:

Pick representative cases, not the easiest ones. Include at least one of each category you will classify.
Vary the content of the examples so the model does not learn a pattern you did not intend, but keep the format identical (separators, capitalization, line breaks).
Try different orders. Lu et al. (2021) found that the order of the same examples can be the difference between a strong result and a near-random one, and that the best order does not carry over from one model to another. Zhao et al. (2021) attribute part of that instability to the model’s bias toward answers near the end of the prompt.
Keep the approved examples in a versioned file, with the reason each was selected.
Compare with and without examples on the same set of cases, to measure whether they really help.

A study that changes the intuition

A 2022 paper by Min and colleagues found that randomly replacing the labels of the examples reduced performance only slightly on several classification and multiple-choice tasks, and that this held across 12 models, including GPT-3. Their conclusion is that examples mainly teach the label space, the distribution of the input text and the overall format of the sequence.

The practical lesson is not that examples do not matter, but that much of their value is in showing the format and the type of case. The study covers classification and multiple-choice tasks; do not generalize it to tasks where the example defines a subtle criterion, such as a brand tone. There, a mislabeled example teaches the wrong criterion. Treat the study as a reason not to obsess over every label, not as permission to leave examples unreviewed.

When should you NOT use it?

When the task is simple and the model already does it well without examples: more examples only add token cost to every request.
When the examples take up most of the window and leave little room for the real information.
When the pattern changes a lot between cases, because the model may copy an example that does not apply.
When the problem is knowledge, not format. If the model lacks the data, examples will not supply it; use RAG.

If you have hundreds of examples and need stable behavior at high volume, evaluate fine-tuning.

What if the examples do not help?

Check in this order: first, that the format of the examples is identical; second, that they cover the cases where the model fails and not only the easy ones; third, that the order is not the problem; fourth, that the instruction does not contradict the examples. If there is still no improvement, the obstacle is probably not examples. For multi-step tasks, see chain of thought; to measure each change rigorously, what are evals.

Example

Illustrative example: a product team needs an assistant to turn meeting notes into tasks with an owner and a date. With zero examples, the format changes on every answer. With three approved examples, including one with no explicit date where the correct output is to ask for the date, the assistant stops inventing it. The team tests with 30 real notes, changes the order of the examples to see whether the result varies, and records the cases where it fails, adding examples only when a pattern repeats.

Common mistakes

Including examples the team did not review.
Using only easy cases, then being surprised by the hard ones.
Putting in dozens of examples without measuring whether they help.
Varying the format between examples and expecting a consistent output.
Forgetting that examples also cost tokens on every request.
Giving near-identical examples: the model may learn patterns you did not intend.
Mixing in examples with styles the product does not want to show.

Sources

Frequently asked questions

What is few-shot prompting?

It means including a few input and desired-output examples in the prompt so the model follows the same pattern on a new input, without retraining it.

How many examples should I include?

There is no fixed number. Anthropic recommends 3 to 5 relevant, varied examples; Google advises experimenting with the count because too many can make the model overfit to them. Test with your own cases.

Do the examples have to be correct?

They should be. A 2022 study (Min et al.) found that randomly changing the labels reduced performance only slightly on classification and multiple-choice tasks, because examples mainly provide format and type of case. That does not make them irrelevant: if you want to teach a criterion, the example must reflect it.

Does the order of the examples matter?

It can matter a lot. Lu et al. (2021) showed that reordering the same examples can move results from strong to near random, and that a good order for one model does not necessarily work for another.

Is few-shot better than fine-tuning?

For tasks with few cases and frequent changes, it is usually faster and cheaper. If you need stable behavior at high volume, fine-tuning may pay off.