Contents · 8 sections↓
Few-shot prompting means putting a handful of worked examples in the prompt so the model copies the pattern. It is the fastest way to teach a house style or format that is hard to describe in words. This guide is for anyone whose instructions keep getting "interpreted" instead of followed. It covers when examples beat instructions, how to pick them, and the biases they bring, with a real release-notes prompt and the model's output with and without examples.
What is few-shot prompting?
Few-shot prompting gives the model two to five input-and-output examples before the real input. The model infers the pattern from the examples (length, tone, structure, what to leave out) and applies it. Zero-shot prompting gives instructions only. The term comes from Language Models are Few-Shot Learners (Brown et al., 2020), which showed that large models can pick up a task from examples in the prompt without any retraining.
Key takeaways:
Use examples for style and conventions, the things you'd struggle to describe.
For clear-cut tasks, zero-shot often works. Try it first.
Examples teach patterns, not rules. Pair them with a short instruction for anything that must always hold.
Vary your examples and keep their format identical; the model copies both content and quirks.
[02]
How few-shot prompting works
The model treats your examples as evidence of what a good answer looks like. Research on why this works found something surprising: Rethinking the Role of Demonstrations (Min et al., 2022) reported that the format and the range of labels in the examples mattered more than whether each example's label was correct. Examples mostly tell the model what kind of output you want.
They also bring biases. Calibrate Before Use (Zhao et al., 2021) found that models lean toward labels that appear often in the examples and toward the label of the last example. Newer models are less sensitive than the ones in those papers, but the lesson holds: balance and shuffle your examples.
[03]
Worked example: release notes in house style
A team turns its internal change list into customer-facing release notes. The input:
- LED-412 fix race condition in invoice numbering when two users save at once
- LED-418 add bulk export of invoices as CSV (Settings > Export)
- LED-420 bump pdf renderer to 3.2, fixes euro sign rendering in footer
- LED-425 reminder emails: allow custom send time per clientZero-shot
Write customer-facing release notes for these changes.
<changes>The output (trimmed):
Release notes — Recent updates
Highlights
- Improved reliability when creating invoices
- New bulk CSV export for invoices
…
Export — bulk export of invoices (LED-418)
- New: you can now export multiple invoices as a CSV file.
- Where to find it: Settings > Export
- Use cases: accounting, bulk imports, or offline review. The CSV includes key invoice fields (date, number, client, total, status, etc.).
…
- How to use: open a client’s settings and adjust the reminder send time (in the client’s reminder preferences).
If you have any questions or need help with these changes, contact our support team.About 270 words for four changes, internal ticket IDs left in, and two invented details: the CSV's columns and where the reminder setting lives. The instruction "customer-facing" left everything else to the model.
Few-shot
Turn internal change lists into customer-facing release notes in our house style. Follow the examples exactly.
Example input:
- LED-377 handle null client address in PDF export
- LED-380 new setting to hide the tax column on invoices
Example output:
New: You can hide the tax column on invoices (Settings > Invoices).
Fixed: Invoices for clients without an address now export to PDF.
Example input:
- LED-391 upgrade stripe sdk to v14
- LED-395 duplicate invoice button
Example output:
New: Duplicate any invoice with one click from the invoice menu.
Now the real input:
<changes>
Output:The output:
New: Export invoices in bulk as CSV (Settings > Export).
New: Set a custom send time for reminder emails per client.
Fixed: Invoice numbers no longer collide when two users save at once.
Fixed: Euro sign now renders correctly in PDF footers (PDF renderer updated to v3.2).Four lines, the house format, "New" before "Fixed", no ticket IDs, nothing invented. The examples carried rules nobody wrote down: one line per change, user-facing wording, and drop pure dependency upgrades (the second example silently omits the Stripe upgrade).
One slip: the model kept "(PDF renderer updated to v3.2)". The example dropped an upgrade that had no user effect; this one did have an effect, so the model kept both. If version numbers must never appear, say so in one line: "Never mention library names or versions." Examples show the pattern; instructions pin down the rules.
A case where zero-shot was enough
Six support messages labeled as bug, billing, feature request, praise or other: the zero-shot prompt and a few-shot prompt gave the same six labels. Only the formatting differed ("Feature request" versus feature_request). For clear categories, a precise instruction and an exact output format are often all you need. Add examples when the model gets the edge cases wrong, and make those edge cases your examples.
[04]
When to use few-shot prompting (and when not to)
Use it for:
House style and tone: release notes, product copy, replies in your brand voice.
Formats with conventions: how you write dates, which fields are optional, what to omit.
Labeling with fuzzy boundaries, where your team has its own rules for edge cases.
Skip it when:
The task is clear from instructions alone. Examples cost tokens on every call.
You need strict JSON. Use structured outputs instead.
You only have one example. A single example tends to be copied too literally; two or three varied ones generalize better.
[05]
How to pick good examples
Use real inputs, including the messy ones, not idealized ones.
Cover the edge cases you care about: a change with no user impact, a message with two topics.
Vary length and content so the model doesn't copy one example's length or wording.
Keep the format identical across examples, down to punctuation. Inconsistency is copied too.
Balance labels for classification, and don't always put the same label last.
Fence them clearly ("Example input:" / "Example output:") so the model doesn't confuse examples with the real input.
[06]
Common mistakes
Mistake | Why it fails | Fix |
|---|---|---|
Examples that are all alike | The model overfits to their length and wording | Vary topic and length; keep format identical |
Relying on examples for hard rules | Examples imply; the model may not generalize | Add a one-line rule for anything that must always hold |
Most examples share one label | The model leans toward that label | Balance and shuffle labels |
Examples copied into the output | Weak separation between examples and input | Clear markers and "Now the real input:" |
Ten examples where three would do | Cost and latency on every call, little gain | Start with two or three; add only for failures |
[07]
Frequently asked questions
How many examples should I use?
Two to five is a good default. Start with two or three, run the prompt on real inputs, and add an example only when you find a case the model gets wrong.
What is the difference between zero-shot, one-shot and few-shot?
Zero-shot gives instructions only, one-shot adds a single example, and few-shot adds several. More examples show the pattern more clearly but cost more tokens on every call.
Do the example outputs have to be perfect?
They should be what you want, because the model copies them closely. Research suggests format matters more than label correctness, but a sloppy example still teaches sloppy output.
Should examples go in the system prompt?
If they define the standard format for every request, yes. If they are specific to one task type, put them with that task. See system vs user prompts.
Can I choose examples automatically?
Yes. A common approach retrieves the most similar past examples for each new input. For a structured way to pick which examples to label, see active prompting.
[08]
Next steps
Previous: beginner eval loops, to test whether examples actually help.
Next in the path: role prompting.
Get strict structure instead: structured outputs.
Choose examples systematically: active prompting.
Back to the pillar: what is prompt engineering?