Few-shot prompting: guide AI with concrete examples
Few-shot prompting means adding two to five examples of what you expect to your request, so the AI reproduces the format, tone and logic. Where an instruction describes, an example shows, and a model usually imitates better than it interprets. This article explains when the technique is worth it, how to set it up and where it goes wrong. It extends our prompt engineering guide for SMEs.
Few-shot vs zero-shot: what is the difference?
A zero-shot prompt contains no example, a few-shot prompt contains a handful. In the first case you describe the task and the model relies on what it has learned. In the second, you add "input / expected output" pairs before asking your real question.
A simple case. Zero-shot: "Classify this customer review as positive, neutral or negative." The model will answer, sometimes with an explanation you did not ask for. Few-shot: you provide three reviews already classified, each followed by a single label. The model now understands the exact format: one word, no comment.
The term comes from large language model research: the 2020 GPT-3 paper ("Language Models are Few-Shot Learners") popularised the idea that an LLM can pick up a task from a few examples given in the conversation, without retraining. [To verify before sending: exact publication reference]
When few-shot helps (and when it does not)
Few-shot is most useful when the output must follow a precise format, a house tone or a rule that is hard to put into words. If the task is simple and the model handles it well (translating a sentence, summarising a paragraph), a good zero-shot prompt is enough and examples only add weight.
Situations where examples make the difference:
- A strict output format, such as a four-field product sheet or JSON for an automation tool.
- A company-specific tone that is hard to describe ("warm but not casual").
- A classification with edge cases: an ambiguous review, a support ticket sitting between two categories.
- Data extraction from documents that do not quite look alike.
Conversely, avoid few-shot when you have no reliable example at hand. A bad example is worse than none, because the model will copy it faithfully.
How to write a few-shot prompt in 5 steps
The method has five steps: frame the task, pick the examples, structure them, separate them from the real request, then test.
- Frame the task in one sentence. It is the same work as for any prompt, covered in our article on the anatomy of a good prompt: role, context, task, constraints, format.
- Pick two to five examples. This is a common starting rule, not a law. Three well-chosen examples beat ten redundant ones.
- Structure every example the same way. Same labels, same order, same punctuation. The model spots the pattern and extends it.
- Clearly separate examples from the real request. An "Examples" heading followed by a "To process" heading stops the model from mixing the two.
- Test on cases you already know. Run the prompt on five items whose right answer you know, and fix the examples if the output drifts.
Example 1: sorting support requests
To sort incoming emails, three examples covering different categories are enough to fix the answer format.
Here is a prompt ready to adapt (the requests are fictional):
You sort emails received by an SME's support team. Answer only with the category: BILLING, TECHNICAL or SALES.
Email: "I did not receive my September invoice." -> BILLING Email: "The app crashes when I open the planner." -> TECHNICAL Email: "Can you send me a quote for 12 seats?" -> SALES
Email to classify: "The price on your quote does not match your website."
The final case is deliberately ambiguous (sales or billing?). This is where few-shot shows its limit: if you have an internal rule, add an example that embodies it. Otherwise the model will decide in its own way, and you need to know that before automating.
Example 2: keeping your brand tone
For a house tone, paste two or three texts you have actually approved, and ask the model to take inspiration without copying them.
Take a nonprofit that publishes a monthly newsletter. Instead of writing "warm, sober, no jargon", it pastes two past paragraphs it considers successful and asks: "Write the introduction of the November newsletter in the same register. Do not reuse any sentence from the examples."
That precaution matters. Without it, the model sometimes recycles whole phrases. And always proofread: an imitated tone is not an understood tone, and some expressions will sound off as soon as the topic changes.
Example 3: extracting data from uneven documents
To extract information from documents that differ from one supplier to the next, show one easy case and one hard case.
An accounting firm wants to pull the supplier name, the net amount and the date from invoices. First example: a clean invoice, everything readable. Second example: an invoice where the net amount sits in a table and the date in the header, with the correct answer. The model learns that the information is not always in the same place.
For any automated processing, enforce a strict format (for example JSON with three fields) and provide an "unknown" value when data is missing. Otherwise the model may invent a plausible value, which is a form of hallucination. And never paste personal data into an unapproved tool: see our article on data confidentiality with AI.
Common few-shot mistakes
Most failures come from the examples themselves: too similar, poorly chosen or inconsistent with each other.
| Mistake | Observed effect | Fix |
|---|---|---|
| All examples identical | The model assumes everything looks like that | Vary the cases, include an edge case |
| Inconsistent labels | Inconsistent answers | Proofread examples like an editor |
| Only one type of answer | Bias toward that answer | Balance the categories |
| Examples too long | Diluted instruction, higher cost | Keep examples short |
| No testing | Errors found in production | Validate on 5 to 10 known cases |
One often overlooked point: the order of examples can influence the answer, especially the last one. If your results always lean the same way, change the order before rewriting the whole prompt.
Few-shot, system prompt and automation
In a business tool, examples generally go in the system prompt, so every user benefits without retyping them. If you build an internal assistant or a custom GPT, the difference between system prompt and user prompt is worth knowing: stable examples go in the first, the day's data in the second.
In an automation scenario, examples also lock the output format, so a badly named field does not break the rest of the workflow. Version them like any other part of your tool: a modified example changes the behaviour of the whole assistant.
On compliance, Article 4 of EU Regulation 2024/1689 (the AI Act) asks organisations using AI systems to ensure a sufficient level of AI literacy among their staff. Our article on the Article 4 training obligation covers it in detail. [To verify before sending: exact wording of Article 4 on eur-lex.europa.eu]
How GrowthPerf supports your teams
GrowthPerf teaches your teams to build few-shot prompts from their own documents, not from generic examples. We are a Qualiopi-certified training body, which in principle opens the possibility of OPCO funding depending on your situation (eligibility to be confirmed case by case).
In a workshop, each participant picks a task they repeat every week (email sorting, meeting notes, product sheets), assembles three examples from their own work, tests the result and saves it in a shared library. The programme is described in our prompt engineering training. If you mostly use ChatGPT, see also ChatGPT training for business, and for small structures AI training for micro-businesses.
To find out where examples would save you time, book a free 30-minute AI training audit. You will then find the whole approach in the prompt engineering guide.
Frequently asked questions
How many examples should I give the AI? Two to five to start. Beyond that, the gain often shrinks and the prompt costs more to process. Add an example only if it covers a case the others do not.
What is the difference between one-shot and few-shot? One-shot gives a single example, few-shot gives several. One example is enough to fix a simple format, but several are needed as soon as you must show variations.
Does few-shot work with ChatGPT, Claude and Gemini? Yes, the principle is the same on these tools. Results vary from one model to another, so test on the tool your teams actually use.
Does few-shot eliminate hallucinations? No. It frames format and tone, but the model can still invent content. Provide source data, include an "unknown" value and proofread.
Should I use real customer documents as examples? Only if the tool is approved by your organisation and GDPR allows it. Otherwise anonymise, or invent fictional cases close to reality.
Does few-shot replace fine-tuning? For most SME uses, in practice yes: a few examples in the prompt cost far less than retraining. Fine-tuning makes sense for very large volumes or very specific needs. [To verify before sending]
Where should I store examples so the whole team benefits? In the system prompt of a shared assistant, or in a documented prompt library, with an owner who approves changes.