Few-Shot vs Zero-Shot Prompting Compared

Zero-Shot: Instructions Without Examples

Zero-shot prompting is the simplest approach: you describe the task and provide the input, and the model handles it based entirely on its training. "Classify the following customer email as either complaint, question, or praise: [email text]." The model has seen millions of classification tasks in its training data and can infer the expected behavior from the instruction alone. For well-defined tasks with clear categories, this works surprisingly well.

Zero-shot's advantage is speed and simplicity. There is no need to find, curate, or format examples. The prompt is shorter, which means lower token costs and faster processing. For prototyping, zero-shot lets you test whether a task is feasible before investing time in example selection. For tasks where the model already performs near the quality threshold you need, zero-shot is the most cost-effective choice.

Zero-shot fails when the task definition is ambiguous (what counts as a "complaint" versus a "question" is often subjective), when the expected output format is specific and not the model's default (a particular JSON schema, a specific labeling convention), or when the task requires domain-specific judgment that general instructions cannot convey. In these cases, examples communicate what words cannot.

Few-Shot: Teaching Through Demonstration

Few-shot prompting includes two to eight examples of correct input-output pairs before the actual task. Each example shows the model what a correct response looks like for a given input. The model pattern-matches on these examples and applies the same pattern to the new input. This is in-context learning: the model learns the task from the examples within its context window, without any weight updates or fine-tuning.

The power of few-shot is that examples communicate things that instructions struggle to express. Consider sentiment analysis with a specific rating scale. The instruction "Rate sentiment from 1 to 5, where 1 is very negative and 5 is very positive" is clear in theory, but different evaluators calibrate differently. One person's 3 is another person's 4. By showing examples with specific texts and their correct ratings, you calibrate the model to your scale, your edge cases, your judgment calls. The examples are the specification.

Few-shot is especially effective for: classification with nuanced categories, format-specific outputs (particular JSON structures, report templates, label schemas), domain-specific reasoning (legal analysis, medical triage, financial classification), and tasks where the boundary between categories is subjective and needs to be demonstrated rather than described.

How Many Examples to Use

The research and practical experience converge on a range of 3 to 8 examples for most tasks. Below 3 examples, the model does not have enough data points to reliably identify the pattern. Above 8 examples, the marginal improvement per additional example drops sharply while the token cost and context window usage increase linearly.

The exact number depends on task complexity. Simple classification with clear categories (spam / not spam) works well with 2 to 3 examples. Multi-class classification with overlapping categories needs 5 to 8 examples to cover the boundary cases. Structured extraction with a complex schema needs at least 3 examples to demonstrate the full schema, including optional fields and edge cases.

More examples are not always better. Studies have shown that adding low-quality examples, examples with errors or examples that are too similar to each other, can degrade performance compared to fewer high-quality examples. The quality of your examples matters more than the quantity. Each example should be correct, representative of a different aspect of the task, and clear enough that a human would agree with the labeled output.

There is also a context window cost. Each example consumes tokens that could be used for the actual task input. If your task inputs are long (multi-page documents, lengthy code blocks), you may need to use fewer examples to leave room for the input. This trade-off between example coverage and input capacity is one reason structuring the context window is a critical skill.

How to Select Good Examples

Example selection is the most underestimated skill in few-shot prompting. Random examples from your dataset will give mediocre results. Strategically selected examples will give excellent results. The difference can be 10 to 20 percentage points in accuracy.

Diversity over similarity. Your examples should cover the range of inputs the model will see. If your classification task has 5 categories, include at least one example from each category. If your extraction task handles different document formats, include examples of each format. Avoid using multiple examples that are too similar to each other, because the model may overfit to the specific pattern rather than learning the general task.

Include boundary cases. The most valuable examples are the ones near the decision boundary. An email that is clearly spam and one that is clearly not spam teach the model less than an email that could go either way. The boundary case shows the model how you resolve ambiguity, which is exactly where few-shot prompting adds the most value over zero-shot.

Match the difficulty distribution. If 80% of your real inputs are easy and 20% are hard, your examples should roughly reflect this. If all your examples are easy, the model may not handle hard cases well. If all your examples are hard, the model may overthink easy cases.

Order matters. Research shows that the order of examples affects model output. The most recent examples (closest to the actual input) have the strongest influence. Put your most representative, highest-quality example last. For classification tasks, avoid putting all examples of one class together; interleave classes to prevent the model from developing a positional bias.

Dynamic selection. For production applications, selecting examples dynamically based on the input produces the best results. Use embedding similarity to find examples in your dataset that are most similar to the current input, then include those as few-shot examples. This approach, sometimes called retrieval-augmented few-shot prompting, gives the model the most relevant demonstrations for each specific input. It connects naturally to vector search infrastructure you may already have.

When Few-Shot Hurts Performance

There are genuine cases where few-shot performs worse than zero-shot, and recognizing them prevents wasting tokens and degrading output quality.

Misleading examples are the most common cause. If your examples contain errors, inconsistencies, or edge cases that do not generalize, the model learns the wrong pattern. A single wrong example can override multiple correct ones, especially if the wrong example is positioned near the end of the example list.

Overly specific examples can cause the model to copy surface patterns rather than learning the underlying task. If all your few-shot examples for sentiment analysis are about restaurant reviews, the model may perform poorly on product reviews because it has learned "restaurant review analysis" instead of "sentiment analysis."

Instruction-following models in 2026 are significantly better at following natural language instructions than models from 2023. For tasks that are well-described by clear instructions, modern frontier models often perform as well on zero-shot as they do on few-shot, making the examples an unnecessary cost. Test zero-shot first, and only add examples if zero-shot results are insufficient.

Very long inputs create a practical problem: few-shot examples consume context window space that the input needs. If your input is a 10,000-token document and your context window is 32,000 tokens, five few-shot examples of 2,000 tokens each leave zero room for the document. In these cases, zero-shot with excellent instructions is the only viable option, or you need to switch to a model with a larger context window.

Combining Few-Shot with Other Techniques

Few-shot prompting combines powerfully with other techniques. Few-shot plus chain-of-thought means your examples include not just the input and output, but also the reasoning steps between them. This teaches the model both what to produce and how to think about producing it, which is the most effective combination for complex reasoning tasks.

Few-shot plus role prompting means your examples are presented in the context of a specific expertise domain. "You are a senior security analyst. Here are three examples of how you classify security incidents..." gives the model both the calibration from examples and the domain activation from the role.

Few-shot plus structured output means your examples demonstrate the exact schema you expect. This is more reliable than a schema description alone because the model sees exactly how each field should be populated, including how to handle optional fields, empty values, and edge cases in the data.