What is the difference between zero-shot, one-shot and few-shot?

The difference is how many solved examples you put before the task: none, one, or a handful. That’s it. The name changes with the quantity, not with the technique, and each step buys something different: the first example fixes the output format, the next ones fix the boundary between similar categories, and past the fifth the cost grows faster than the gain.

Each mode has its own article with the mechanism in detail: zero-shot, one-shot and few-shot. This one is the comparison, and it exists because the question people actually ask isn’t “what is few-shot”, it’s “is it worth what I’m about to pay for it”.

Short answer: start at zero-shot almost every time and climb one step at a time, guided by the kind of error you’re seeing. The long answer has a table and some measured numbers.

The three, side by side

The same task, converting a weight to grams, written three ways.

Zero-shot:

Convert the weight to grams. Answer with the integer only.

Weight: “1.5 kg”

One-shot:

Convert the weight to grams.

Weight: “800 g” → 800 Weight: “1.5 kg” →

Few-shot:

Convert the weight to grams.

Weight: “800 g” → 800 Weight: “2 lb” → 907 Weight: “half a kilo” → 500 Weight: “not stated” → null Weight: “1.5 kg” →

Notice what each version bought. Zero-shot needed a whole sentence about format and still said nothing about pounds or about a missing weight. One-shot dropped the format sentence. Few-shot settled the foreign unit, the natural-language quantity and the empty case, and each of those three cost exactly one line.

The table

Two rows in that table tend to surprise people. The bias row: with a single example, the model’s pull toward the label it saw is at its maximum, because there’s no second case balancing it. A 2021 paper measured this class of bias and showed that calibrating the output against a content-free input recovers up to 30 absolute points of average accuracy¹.

And the order row: it only exists from few-shot onward, and it isn’t a detail. A study from the same year found permutations of the same examples ranging from near state of the art to near random guessing, with the effect present at every model size tested and no transfer between models². Climbing to few-shot buys you the boundary and inherits a new variable to control.

One column the table deliberately doesn’t have is accuracy. There’s no honest number to put there that isn’t bound to a specific task, model and date, and any comparison that shows one is quoting a benchmark as though it were a property of the technique. The measured numbers in the next section come with all three of those attached, which is why they’re usable.

What the numbers show

The GPT-3 paper is the only primary source that measures all three modes on the same model, the same task and the same protocol. With the 175B model and 64 examples, WebQuestions went 14.4%, 25.3%, 41.5%; TriviaQA went 64.3%, 68.0%, 71.2%; Winograd sat at 88.3%, 89.7% and 88.6%³.

Three readings come out of that, and all three still hold six years later.

There is no average gain. The same change nearly tripled one task and didn’t move another. Any claim of the form “few-shot improves things by X%” is hiding a spread of that size.

The biggest gain per example is the first one. On WebQuestions, one example was worth 11 points; the next 63, together, were worth 16. The first example was worth nearly as much as all the others combined.

Some tasks have nothing to buy. Winograd moved within a point and a half across all three modes. There was no format to pin and no boundary to show, so there was nothing an example could sell.

The mandatory caveat: these are 2020 numbers from a model nobody runs anymore. The absolute values are no reference today, and instruction tuning has narrowed the gap between modes considerably. What ages well is the shape of the result — the spread across tasks, not the average over them.

What each step actually buys

It’s worth separating what each step buys, because the common intuition is wrong on one specific point.

Zero to one: the format. The example shows the structure of the output without you describing it. That covers things descriptions routinely get wrong: whether there’s a code fence around the JSON, whether the number uses a point or a comma, whether the answer starts directly or with a lead-in sentence.

One to several: the boundary. One example shows a point in the space. The line separating two similar categories needs cases on both sides, which is why “I added another good example” tends not to fix category confusion.

Where intuition goes wrong is in assuming examples teach the mapping from input to output. A 2022 paper replaced the labels with random ones across 12 models and measured only a small drop; what carries the result is the set of possible labels, what the inputs look like, and the format of the sequence⁴. In practice that makes the one-shot versus few-shot decision a question of covering the space, not of demonstrating correctness.

There’s a third step most teams don’t notice they’ve taken: from fixed examples to selected examples. When the examples are always the same, they live in the stable prefix of the request and prompt caching charges a fraction for them. Once you start picking the examples closest to each input, you gain relevance and lose the cache entirely, because the prefix changes on every call. Same number of examples, completely different bill.

How to choose

Two variables decide almost everything: how rigid the output format has to be, and how much context you can afford per call.

Free format with tight context gives zero-shot, and there’s nothing to discuss. Exact format with tight context gives one-shot: you buy the most expensive thing per token, which is pinning the format, with the minimum number of examples. Exact format with context to spare gives few-shot, which is where boundaries and edge cases fit.

The interesting quadrant is the top left: free format with plenty of context. That’s where most teams spend without needing to. Having window available isn’t a reason to fill it, and every example still gets billed on every call even when it solves nothing.

There’s a third variable the matrix doesn’t show, and it settles the hard cases: how many boundaries your task has. A binary classification with a sharp boundary fits in one-shot. A twelve-category taxonomy where four pairs get confused needs eight examples just to show the confusions, and at that point the question stops being “few-shot or not”. It becomes whether the taxonomy should have twelve categories. Shrinking the label space usually pays more than any prompt edit, and it’s the change nobody proposes because it touches the product instead of the text.

What the difference costs

Order of magnitude, using the weight task as the base. One example of that task is short, around 20 tokens. On real tasks, with the full source sentence attached, an example is closer to 60.

At 60 tokens per example, a zero-shot instruction around 80 tokens and a volume of 500,000 calls a month, the input bill looks like this: zero-shot, 40 million tokens; one-shot, 70 million; five-shot, 190 million. Choosing the last over the first multiplies by nearly five the part of the invoice you control by writing text.

Two factors bend that and usually get left out. Prompt caching cuts the price of the reused span when the examples are fixed and live in the prefix, which pushes the decision toward few-shot. Dynamic example selection does the opposite: it improves quality and hands back the full price, because there’s no stable prefix left to reuse.

The part nobody counts is latency. Every example is more context to process before the first token comes back, and in a synchronous interface that shows up before it shows up on the invoice.

Where each one breaks

Zero-shot breaks when the correct answer depends on a convention of yours. The internal name of a category, the boundary defined in your SLA, the exact format your parser expects. None of that is deducible from the world.

One-shot breaks when the single example is exceptional. If it shows an edge case, the model starts treating everything as an edge case. And being a single case, it carries label bias at its maximum.

Few-shot breaks by accumulation. Unbalanced examples push the model toward whichever category dominates the block, stale examples hide newer categories, and the ordering becomes a variable nobody is versioning.

None of the three survives a model swap intact. The choice was made against one specific behaviour, and behaviour shifts from version to version. A task that demanded five-shot on last year’s model may be solved zero-shot on the current one, and the only way to know is to run the test set on both. A prompt that survives three model changes without re-evaluation is usually paying for examples that stopped mattering.

All three fail the same way in one situation: when the problem is missing knowledge. If the answer depends on a document the model has never seen, no quantity of examples helps, because examples show shape, not content.

And many-shot?

There’s a fourth point on the ruler that large windows made viable: hundreds or thousands of examples. A 2024 paper measured that regime and found consistent gains across generative and discriminative tasks, plus something few-shot can’t do: overriding biases inherited from pretraining. The authors note that inference cost grows linearly⁵.

It’s a real regime and an expensive one. From there on, the honest comparison stops being with few-shot and becomes one with training a model, which changes the nature of the decision entirely.

Where to start

1. Build the test set before choosing the mode. Thirty real inputs with the expected output beside each. Without it, comparing the three is opinion.
2. Run zero-shot and count. That’s the baseline everything else is measured against.
3. Sort the errors by type. Format, boundary, knowledge. Only the first two are fixable with examples.
4. Climb one step and run again. One example for format. A pair on each side for every boundary being got wrong.
5. Stop at the step where the gain stops. If the fifth example didn’t move your 30 cases, the sixth won’t either.

Step 3 prevents the wrong choice more often than anything else. Treating a knowledge error with more examples is the most common way to spend context and improve nothing.

Footnotes

1. Zhao et al. (2021) measured the model’s bias toward certain answers and recovered up to 30 absolute points of average accuracy by calibrating with a content-free input. ↩

2. Lu et al. (2021) found permutations of the same examples ranging from near state of the art to near random guessing, present at every model size tested and not transferring between models. ↩

3. Brown et al. (2020) report, with the 175B model and 64 examples: 14.4%, 25.3% and 41.5% on WebQuestions; 64.3%, 68.0% and 71.2% on TriviaQA; and 88.3%, 89.7% and 88.6% on Winograd, across zero-shot, one-shot and few-shot. ↩

4. Min et al. (2022) replaced correct labels with random ones across 12 models and measured only a small drop, pointing at the label space, the input distribution and the format as what carries the result. ↩

5. Agarwal et al. (2024) measured the hundreds-to-thousands regime, with consistent gains, the ability to override pretraining biases, and linear inference cost. ↩