Zero-Shot vs Few-Shot Prompting: When Should You Give AI Examples?
Examples aren't free, they cost tokens and effort to write. Here's the actual decision behind when that cost is worth it, and when it just adds noise.
The anatomy of a good prompt listed Examples as one of six ingredients, without saying when that ingredient actually earns its place. This is that decision, in full: when a couple of examples measurably improve the output, and when they're just extra tokens with nothing to show for them.
Zero-shot
User → Instruction → Model
Few-shot
User → Instruction
↓
Example 1
Example 2
Example 3
↓
ModelZero-Shot: No Examples, Just the Instruction
You ask directly, with no demonstration of what a correct answer looks like, and rely on the model's training to fill the gap sensibly. This works well specifically when the gap is small.
Where zero-shot genuinely holds up
General knowledge questions, brainstorming, well-known and common formats ("write this as a table," "summarise this in three bullet points"), and any one-off task where a slightly different interpretation wouldn't actually matter. Adding examples here is pure overhead, more tokens spent for a gap that was never going to cause a problem.
Few-Shot: A Handful of Examples First
You show one or more input-output pairs before the actual request, and the model treats those examples as the pattern to continue, not just as helpful context. Current prompting guidance specifically recommends this for controlling format, scope, and pattern, the three things zero-shot leaves most exposed to interpretation.
Format: an unusual or specific structure the model has no reason to guess correctly on its own.
Scope: where the boundary of "correct" actually sits, especially when that boundary isn't obvious from the instruction alone.
Pattern: a consistent way of transforming many similar items, where the first couple of examples establish the rule the rest should follow.
A Worked Comparison
Task: categorise Intune sync error codes as Network, Certificate, or Policy Conflict.
Zero-shot attempt
"Categorise these Intune error codes as Network, Certificate, or Policy Conflict: 0x87D1FDE8, 0x80190190, 0x87D13B92." The model has to guess what distinguishes these three categories in your specific taxonomy, and a genuinely ambiguous code (one that could plausibly be read as either a certificate issue or a policy conflict) gets categorised inconsistently between runs.
Few-shot attempt
Same instruction, preceded by: "0x80072EE7 → Network (DNS resolution failure). 0x8013150A → Certificate (client certificate expired). 0x87D13B92 → Policy Conflict (conflicting configuration profiles assigned)." Now the model has seen exactly what distinguishes the three categories in practice, not just their names, and applies that same distinction to the new codes consistently.
The zero-shot version isn't wrong, it's just unanchored
Nothing about the zero-shot prompt was a mistake. It simply never told the model what actually separates these three categories in your specific context, so the model applied its own best guess, which may not match the distinction you actually had in mind.
How Many Examples Is Enough
Zero examples: zero-shot
Fine when the task is common and the format is unambiguous.
One example: one-shot
Better than nothing, but risky on its own, the model can latch onto an incidental detail of that single example (a specific phrase, an unusual length) as if it were part of the required pattern, rather than the actual rule you meant to demonstrate.
Two to three examples: the practical sweet spot
Enough to show the model what varies between cases and what stays constant, which is what actually communicates a pattern rather than a single fixed template.
Five or more: diminishing returns, real token cost
Past three or four well-chosen examples, additional ones rarely sharpen the pattern further, they mostly just add length, and therefore cost, to every single request.
Pick examples that show the edges, not just the easy cases
Three examples that are all straightforward tells the model less than two examples plus one deliberately tricky edge case. If ambiguous inputs are the actual problem you're trying to solve, at least one example should be ambiguous, not just clean.
The Decision, as a Checklist
| Question | If yes |
|---|---|
| Is the output format unusual or specific to your context? | Few-shot |
| Does "correct" have a boundary that isn't obvious from the instruction alone? | Few-shot |
| Are you processing many similar items that need the same consistent treatment? | Few-shot |
| Is this a common, well-understood format or a one-off general question? | Zero-shot |
| Are you optimising for the shortest, cheapest possible prompt? | Zero-shot, unless the output quality genuinely requires otherwise |
Summary
The actual trade-off
Zero-shot is cheaper and faster to write, and it's the right default for anything common enough that the model's own training already encodes the pattern you want. Few-shot costs more tokens and more effort to construct, and it earns that cost back specifically when format, scope, or pattern would otherwise be left to guesswork. Neither is universally better, the question is whether this specific task has a gap worth anchoring.
Have you had a task where even three or four examples still didn't produce consistent output? That's usually a sign the underlying instruction itself is ambiguous, not that few-shot failed, examples anchor a pattern, they can't invent one that was never actually defined. Drop a comment with what you ran into.
Written by
Chetan Yamger
Cloud Engineer · AI Automation Architect · Modern Workplace Consultant
Cloud Engineer, AI Automation Architect, and Modern Workplace Consultant based in Amsterdam, Netherlands. Specializing in scalable, secure enterprise solutions with Microsoft Azure, Intune, PowerShell, and AI-driven automation using ChatGPT, Gemini, and modern LLM technologies.
Stay in the loop.
New articles, straight to you.
Deep-dive technical articles on Intune, PowerShell, and AI — no noise, no spam.
Discussion
Share your thoughts — your email stays private
Leave a comment