Few-shot prompting provides several examples (typically 2-5+) before the actual task — the most reliable way to lock in a consistent output format or demonstrate variation the model should generalize from.
Example
Prompt:
"Classify each review's sentiment as Positive, Negative, or Mixed.
Review: 'Amazing product, exceeded my expectations!'
Sentiment: Positive
Review: 'Broke after two days, complete waste of money.'
Sentiment: Negative
Review: 'Good quality but way overpriced for what it is.'
Sentiment: Mixed
Review: 'Fast shipping, decent build quality, would buy again.'
Sentiment:"The three examples establish both the exact label vocabulary (Positive/Negative/Mixed, not other synonyms) and demonstrate the "Mixed" category with a genuinely nuanced example — something a zero-shot instruction alone might not reliably convey.
Why Few-Shot Often Outperforms Zero-Shot on Format-Sensitive Tasks
| Zero-Shot | Few-Shot | |
|---|---|---|
| Output format consistency | Can vary across runs/inputs | Generally more consistent — the model follows the demonstrated pattern |
| Handles edge cases/ambiguity | Depends entirely on instruction clarity | Can be explicitly demonstrated via a well-chosen example |
| Token cost | Lowest | Higher — examples consume real context budget |
Choosing Good Examples
- Representative, not edge cases — unless you specifically want to demonstrate how to handle an edge case
- Cover real variation — if the task has multiple output categories, include an example of each
- Consistent formatting across all examples — inconsistency in the examples themselves teaches inconsistency
Practical Use Case
Structured classification, extraction, and format-transformation tasks in production systems very commonly use few-shot prompting specifically because output consistency matters for downstream code that parses the result.
Common Mistakes
- Using too many examples, unnecessarily inflating token cost when 2-3 well-chosen ones would work as well
- All examples following the exact same simple pattern, giving the model no signal for handling variation or edge cases it will actually encounter
- Inconsistent formatting between examples, which the model may faithfully (and unhelpfully) replicate
Interview Relevance
"How many few-shot examples is 'enough'?" — there's no universal number; the practical answer is to test empirically, starting with 2-3 well-chosen, representative examples covering key variation, and evaluating whether output consistency is sufficient.
Practice Question
Design a 3-example few-shot prompt for extracting (product name, issue, requested action) from customer emails, choosing examples that cover different request types.
