Zero-Shot vs Few-Shot Prompting: When to Use Each Technique

There's a pattern I've noticed with people new to working with language models. They spend hours crafting elaborate prompts with carefully constructed examples, testing and tweaking each one, when a single well-written instruction would have worked fine. And then there are the people who insist on giving zero context, just firing questions at the model and being frustrated when it misunderstands the task. Both camps are missing something.

The zero-shot vs. few-shot distinction isn't really a philosophical debate about AI capability. It's a practical engineering decision. Get it right and you save time and tokens. Get it wrong and you get bad outputs or waste expensive context window space on examples that didn't help.

The Actual Definitions (Without the Academic Jargon)

Zero-shot prompting is exactly what it sounds like. You give the model a task and zero examples of how to do it. Just the instruction, maybe some context, and the model figures out the rest.

Classify the sentiment of this review as positive, negative, or neutral:
"The battery life is decent but the keyboard feels cheap."

That's it. No examples needed. The model knows what "sentiment classification" means from its training.

Few-shot prompting means you include a small number of input-output examples before your actual task. These examples demonstrate the pattern you want the model to follow.

Classify the sentiment of each review:

Review: "Absolutely love this product, works perfectly!"
Sentiment: Positive

Review: "Stopped working after two weeks, very disappointed."
Sentiment: Negative

Review: "It's okay, nothing special but does the job."
Sentiment: Neutral

Review: "The battery life is decent but the keyboard feels cheap."
Sentiment:

The model now has three demonstrations of what you want before encountering the actual question.

There's also one-shot prompting — a single example — which sits between the two. Some people count it separately, some fold it into few-shot. It's worth knowing the term exists.

A Brief History of Why This Matters

These concepts took on new significance with the GPT-3 paper in 2020 (Brown et al., "Language Models are Few-Shot Learners"). Before that, getting a model to do a new task typically meant fine-tuning it — retraining on task-specific data. GPT-3 showed that a sufficiently large language model could adapt to new tasks just from examples in the prompt, without any weight updates. Zero-shot showed the model could often handle tasks with no examples at all.

This was a significant shift. Suddenly the quality of your prompt — not just the architecture of your model — became a major determinant of task performance. Prompt engineering as a discipline emerged partly from this realization.

Since 2020, models have gotten dramatically better at zero-shot tasks. What required few-shot examples with GPT-3 often works zero-shot with GPT-4 or Claude 3. This trend matters when you're deciding which approach to use.

When Zero-Shot Is the Right Call

Zero-shot works best for tasks that are:

• Common and well-defined — summarization, translation, simple Q&A, basic classification. The model has seen thousands of examples of these during training.
• Straightforward to describe — if you can write a clear one-sentence instruction, zero-shot often handles it.
• Low-stakes or exploratory — when you're iterating quickly and don't want to commit time to writing examples.
• Token-constrained — in applications where you're working near context limits, not spending tokens on examples matters.

A genuinely good zero-shot prompt is more than just a bare question. The best zero-shot prompts include clear task description, format instructions if relevant, and any necessary context. What they don't need is examples.

You are reviewing a customer support ticket. 
Categorize it into exactly one of these categories: 
Billing, Technical Issue, Feature Request, or General Inquiry.

Respond with only the category name, nothing else.

Ticket: "I can't seem to log into my account after the update yesterday. 
It keeps saying invalid credentials but my password hasn't changed."

No examples needed here. The task is clear, the categories are explicit, and the format requirement is stated. That's a solid zero-shot prompt.

When Few-Shot Makes a Real Difference

Few-shot becomes genuinely valuable in specific situations, and it's worth being precise about when.

Custom Output Formats

If you need output in a very specific format — particular JSON structure, specialized markdown, proprietary classification schemes — examples are often faster and more reliable than describing the format in words.

Extract the key information from each job posting:

Posting: "Senior Backend Engineer at Acme Corp. Remote. 
Requirements: 5+ years Python, AWS experience, strong system design skills. 
Salary: $150k-$180k."
Output: {"role": "Senior Backend Engineer", "company": "Acme Corp", 
"location": "Remote", "salary_range": "$150k-$180k", 
"key_skills": ["Python", "AWS", "system design"]}

Posting: "Junior Data Analyst at DataFlow Inc. NYC hybrid. 
Must know SQL and Excel, familiarity with Tableau a plus. $65k-$80k."
Output: {"role": "Junior Data Analyst", "company": "DataFlow Inc", 
"location": "NYC hybrid", "salary_range": "$65k-$80k", 
"key_skills": ["SQL", "Excel", "Tableau"]}

Posting: "ML Engineer at StartupXYZ. San Francisco, on-site. 
Looking for PyTorch experience, NLP background, PhD preferred. $200k+."
Output:

Describing that JSON structure in words would be verbose and error-prone. The examples demonstrate it instantly.

Specialized or Domain-Specific Tasks

Legal document analysis, medical record summarization, code review in a specific style, tone-matching to a brand voice — these benefit from examples because the model needs to calibrate to your specific domain conventions, not just the general task type.

Edge Cases and Tricky Distinctions

If your task has subtle edge cases that a general model might get wrong, examples can demonstrate how to handle them.

Classify each statement as Fact, Opinion, or Speculation:

Statement: "The Eiffel Tower is 330 meters tall."
Classification: Fact (verifiable, specific measurement)

Statement: "The Eiffel Tower is ugly."
Classification: Opinion (subjective judgment)

Statement: "The Eiffel Tower might be torn down in 50 years."
Classification: Speculation (possible future event, no evidence given)

Statement: "Electric cars are better for the environment in the long run."
Classification:

That last one is tricky — it could be argued as Opinion or as a factual claim with evidence. Your example set trains the model on how you want to handle ambiguous cases.

Performance Comparison: What Research Shows

The data here is genuinely interesting. The improvements from few-shot over zero-shot aren't uniform — they depend heavily on task type and model size.

Source: Brown et al., "Language Models are Few-Shot Learners," NeurIPS 2020

The variance is striking. WebQs — which requires answering factual questions in a specific short format — jumped 27 points with few-shot. CoQA barely moved. The difference seems related to how format-sensitive the task is. Tasks where the expected output format is very specific benefit more from examples.

For modern models (2024-2026), the gap is often smaller because instruction following has improved dramatically. But for specialized or structured tasks, few-shot still tends to outperform.

Getting Few-Shot Examples Right

The selection and quality of your examples matters enormously. A few principles that hold up in practice:

Diversity beats volume. Three diverse, high-quality examples usually outperform eight similar ones. If all your examples are easy cases, the model won't know how to handle edge cases.

Examples should be representative, not cherry-picked. Include the kinds of cases you'll actually see in production. If your real data has unusual formatting, short inputs, or domain jargon — include that.

Order can matter. Research has shown that the order of few-shot examples can affect performance, with recency bias being a real thing (the last few examples influence the output more). For important applications, test different orderings.

Keep examples consistent in format and quality. Inconsistent examples can confuse the model more than help. If your examples have varying output formats, the model learns inconsistency.

For more on structuring prompts for reliability, check out the Prompt Engineering Cheatsheet — it has a quick-reference guide for both zero-shot and few-shot templates across common task types. The ChatGPT Tips Cheatsheet also has practical shorthand for the most common scenarios.

The Context Window Question

One practical constraint people run into with few-shot prompting is context length. Each example takes up tokens. Eight detailed examples might consume 800-2000 tokens before you even get to your actual question. For a model with a 4k context window, that's a significant chunk. For models with 100k+ context windows, it's negligible.

As context windows have expanded — most frontier models now handle 128k to 200k tokens — the practical cost of few-shot examples has dropped. But token cost is still real if you're making thousands of API calls.

A rough calculation: if you're running a classification task with 8 examples at ~150 tokens each, that's 1200 tokens per call. At 1000 calls, you've spent 1.2 million tokens just on examples. At GPT-4 pricing, that adds up. Sometimes zero-shot is the right call purely for economics.

Dynamic Few-Shot: The Better Approach for Production

For serious production applications, static few-shot examples aren't always optimal. Dynamic few-shot — where you select examples based on similarity to the current input — tends to work better. The idea is to retrieve the most relevant examples from a pool rather than using the same fixed examples every time.

This requires a bit more infrastructure: a vector store with your example set, a similarity search to retrieve relevant examples at query time. But the performance improvement on diverse real-world inputs can be substantial.

If you're building something like this, the LLM Concepts notes cover the embeddings and retrieval concepts you'd need. The Prompt Engineering course has a full module on dynamic prompting patterns.

For anyone wanting to test their understanding of these concepts in practice, the Prompt Basics Quiz covers zero-shot and few-shot fundamentals with hands-on scenarios. And if you're curious about how this connects to chain-of-thought approaches, that's covered in depth in the Advanced Prompting Quiz.

The bottom line is genuinely simple, even if applying it takes judgment: zero-shot for clear, general tasks; few-shot when format matters, the domain is specialized, or edge cases need explicit demonstration. Test both. The model doesn't care which philosophy you prefer — it just responds to what you give it.