Few-Shot Prompting: How to Use Examples in a Prompt

Few-shot prompting means including a small number of worked examples, each an input paired with the output you want, inside the prompt so the model can infer the pattern and apply it to a new input. It is most useful when the result has to match a format, label set or style that is easier to show than to describe. A handful of varied, consistently formatted examples is usually enough; the selection matters more than the count.

Zero-shot, one-shot, few-shot

• Zero-shot: instructions only, no examples.
• One-shot: a single example.
• Few-shot (Anthropic's documentation uses "multishot"): several examples.

The "shots" are demonstrations inside the prompt. Nothing is retrained; the model reads the examples as part of its input and continues the pattern. Remove them and the behavior goes with them.

All three vendor guides endorse the technique. Google's prompting documentation goes furthest, recommending that prompts include few-shot examples as a general rule and describing prompts without them as likely to be less effective. Anthropic's suggests three to five examples as a typical starting point, and OpenAI's lists examples alongside instructions as a standard way to steer output.

When examples earn their place

Examples help most when:

• The output has a strict shape. A fixed JSON structure, a specific citation style, a house format for release notes.
• Labels need calibrating. What counts as "urgent" or "mixed sentiment" in your data is hard to define and easy to show.
• Tone is the requirement. Three sample product blurbs convey a voice better than a paragraph of adjectives.
• Instructions alone have already failed. If a clear zero-shot prompt keeps missing in the same way, an example of the correct handling is often the shortest fix.

They help less, or get in the way, when the task is open-ended and you want range, since the model will tend to stay close to what it was shown, or when a plain instruction already works. Start zero-shot and add examples when you see a reason.

Anatomy of a few-shot prompt

Classify each support message with one label: billing, bug,
how-to, or other. Reply with the label only.

<examples>
<example>
Message: I was charged twice for March.
Label: billing
</example>
<example>
Message: Where do I change the export date format?
Label: how-to
</example>
<example>
Message: The export button does nothing since yesterday's update.
Label: bug
</example>
<example>
Message: Do you have an office in Lisbon?
Label: other
</example>
</examples>

Message: I can't find the invoice for my last payment.
Label:

Four things to notice:

1. An instruction still comes first. Examples refine an instruction; they do not replace it.
2. Every example uses identical field names, order and punctuation.
3. The examples are wrapped and separated from the real input, here with tags, so the model can tell demonstration from task. Anthropic's guidance recommends this explicitly.
4. The prompt ends with the same prefix the examples use (Label:), which signals where the answer begins. Google's documentation describes this kind of output prefix as a way to cue the expected format.

In chat-style APIs, examples can alternatively be supplied as prior user and assistant turns. Both layouts work; keeping them in one delimited block is easier to maintain.

Choosing examples

Make them relevant

Use cases that resemble the real inputs in length, vocabulary and messiness. Tidy textbook examples teach the model to handle tidy textbook input.

Make them varied

This is the point most often missed. The model picks up on every regularity in your examples, including ones you did not intend. If all your examples are short, outputs will be short. If three of four share a label, that label will be over-predicted. If every sample summary opens with "This article", so will every output. Anthropic's documentation warns specifically about models latching on to unintended patterns and recommends diversity as the remedy.

Vary on purpose:

• Cover each label or output type at least once, in roughly balanced numbers.
• Mix lengths and phrasings.
• Change surface features that should not matter, such as topic or names.

Include the hard case

One borderline example with the correct handling teaches more than three obvious ones. If messages that mention both a charge and a crash should be labeled bug, show one.

Show what to do

Google's guidance advises demonstrating the pattern to follow and avoiding examples of what not to do. A "bad example" still puts the unwanted pattern in front of the model. If you need to rule something out, do it in the instruction.

Keep formatting exact

Inconsistent spacing, a missing field or a stray capital in one example is an invitation to produce inconsistent output. Treat the examples as a specification.

How many

There is no fixed number. A reasonable approach:

1. Start with two or three.
2. Run the prompt on inputs that are not among the examples.
3. Where it fails, add an example that covers that failure, and re-run everything.

Google's documentation notes that too many examples can lead a model to overfit to them, and every example adds to prompt length and cost. Stop adding when new examples stop changing results.

Examples for style, not only for labels

Few-shot works for generative tasks as well. To match a voice:

Write a product blurb in the same voice as the samples.
Match their length and sentence rhythm, not their content.

<samples>
<sample>Steel all the way through. No coating to chip, nothing
to replace. Hand wash if you like it; dishwasher if you don't.</sample>
<sample>A kettle that pours where you point it. Balanced handle,
quiet boil, off when it's done.</sample>
</samples>

Product: canvas tool roll, 12 pockets, waxed, brass buckle.

The line "not their content" matters. Without it, details from the samples can reappear in the output. Say plainly which aspects of the examples to imitate.

Combining with reasoning

For tasks that need analysis before an answer, examples can include the reasoning as well as the result, so the model sees how to get there. Keep the reasoning in a clearly marked section, separate from the final answer, so the answer remains easy to extract. With models that have a built-in reasoning mode, check the vendor's guidance first; demonstrated reasoning may be unnecessary there.

Failure modes and fixes

• Outputs echo an example's wording. Add variety; state that examples are illustrative.
• One label dominates. Rebalance the examples and shuffle their order.
• Format drifts on long inputs. Add one long example.
• Good on your examples, poor on new input. You are testing on what the model has seen. Keep a separate set of held-back inputs, as described in how to test AI prompts.
• Prompt has become very long. Consider whether a tighter instruction could replace some examples, or whether the task should be split; see prompt chaining.

Where to put them in a product

In an application, examples usually sit in the system prompt so they apply to every request, with only the new input arriving in the user turn. The division of content between the two is covered in how to use system prompts. For tasks in this library that benefit from supplied examples, see the brand voice prompt, which works from writing samples, and the customer review analysis prompt, where consistent labeling is the point.