Structure & format
Few-Shot Prompting
Few-shot prompting means including a handful of worked input–output examples in a prompt so the model infers the pattern and applies it to a new input. It is the fastest way to pin down format, tone and labelling rules that are hard to describe in words.
- Best for
- Locking down format, tone and labelling rules
- Difficulty
- Beginner
- Updated
What is Few-Shot Prompting?
“Zero-shot” is an instruction with no examples; “one-shot” is one example; “few-shot” is usually two to eight. The model is not being trained — its weights do not change. It is reading the examples as context and continuing the pattern, which researchers call in-context learning.
The surprising finding behind good practice: examples teach format and label space more than they teach correctness. Research found that even randomising the labels in classification examples often hurt accuracy only a little. So the job of your examples is to show the exact shape of a good answer and the range of inputs to expect — and to be correct anyway, because you don’t want to rely on that.
When to use it — and when not to
Use it when
- Output must match an exact format: a JSON shape, a CSV row, a house style for product descriptions.
- Classification or tagging where the categories have fuzzy edges (what counts as “urgent”?).
- Tone that is easier to show than to describe — your brand’s voice, a particular level of brevity.
- Turning messy inputs into clean, consistent outputs at scale.
Skip it when
- Open creative work where you want variety: examples pull every output towards them.
- When a clear instruction already does the job. Modern models follow well-written zero-shot instructions very well; add examples when you see inconsistency.
- When the only examples you have are unrepresentative — the model will copy their quirks.
Copyable template
[ONE-SENTENCE TASK DESCRIPTION]. Follow the format of the examples exactly. Output only the final line, nothing else. <example> Input: [EXAMPLE INPUT 1 — a typical case] Output: [EXAMPLE OUTPUT 1] </example> <example> Input: [EXAMPLE INPUT 2 — a clearly different case] Output: [EXAMPLE OUTPUT 2] </example> <example> Input: [EXAMPLE INPUT 3 — an awkward edge case] Output: [EXAMPLE OUTPUT 3] </example> Input: [NEW INPUT] Output:
Wrapping examples in tags keeps them clearly separate from your real input. Cover the range of cases, balance the labels, and vary the order so the last example is not always the same label.
Replace everything in [SQUARE BRACKETS] before you run it.
Worked example: Support ticket triage
A small SaaS team wants every incoming ticket tagged consistently so it can be routed automatically.
Triage each support ticket as: category | priority | one-line summary. Categories: billing, bug, account, feature-request. Priority: P1 (service down or money lost), P2 (blocked but has a workaround), P3 (everything else). Output only the line. <example> Input: I was charged twice for October, please refund one. Output: billing | P1 | Duplicate October charge, refund requested </example> <example> Input: Export to CSV hangs at 90% but PDF export works fine. Output: bug | P2 | CSV export hangs at 90%; PDF works as workaround </example> <example> Input: Would love a dark mode at some point! Output: feature-request | P3 | Requests dark mode </example> Input: Since resetting my password I can't log in to the desktop app. The web version works, but I have a client demo in an hour. Output:
account | P2 | Desktop app login fails after password reset; web app works; demo in an hour
Why it works: The instruction defines the rules; the three examples show the exact separator, the length of a summary and how the priority rules apply to real wording. One of each category type would make it more robust still.
Common mistakes
- All examples look alike. If every example is short and polite, a long angry ticket gets handled badly. Choose examples that span the real variety of inputs.
- Unbalanced or badly ordered labels. Models drift towards the label that appears most often in the examples, and towards the one that appears last. Balance them and vary the order.
- Examples that contradict the instruction. When they disagree, the examples usually win. Re-read them against your rules.
- Content leaking into outputs. The model may reuse names, numbers or phrases from your examples. Use clearly fictional details, or tell it the examples are illustrative only.
- Too many examples. Past a handful, gains shrink while cost and context use grow. Add examples only for failure cases you have actually seen.
Origin & sources
The term became standard with OpenAI’s GPT-3 paper (Brown et al., 2020), which showed that a large enough language model could perform new tasks from a few examples in its prompt, without any fine-tuning. Zhao et al. (2021) documented why results swing so much with example choice — majority-label and recency biases — and Min et al. (2022) showed that format and the distribution of inputs matter more than whether the example labels are correct.
- Brown et al. (2020), “Language Models are Few-Shot Learners”, NeurIPS 2020 — arXiv:2005.14165
- Zhao et al. (2021), “Calibrate Before Use: Improving Few-Shot Performance of Language Models”, ICML 2021 — arXiv:2102.09690
- Min et al. (2022), “Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?”, EMNLP 2022 — arXiv:2202.12837
Try it on The Prompt Index
Frequently asked questions
How many examples should a few-shot prompt have?
Usually two to five. Start with three that cover a typical case, a different case and an edge case, then add one only when you see a specific failure.
What is the difference between zero-shot, one-shot and few-shot prompting?
Zero-shot gives only an instruction, one-shot adds a single worked example, and few-shot adds several. More examples give more consistency but cost more tokens and can reduce variety.
Does few-shot prompting train the model?
No. The model’s weights do not change. It reads the examples as context for that one request, which is why the effect disappears in a new conversation.
Should I combine few-shot with chain-of-thought?
Yes, when the task needs reasoning. Write each example with its reasoning steps followed by the answer, and the model will reason in the same way on the new input.