Zero-Shot vs One-Shot vs Few-Shot Prompting

What they mean, when to use each, and why extra examples can flip the answer.

TABLE OF CONTENTS

1. Introduction

2. What a Prompt Actually Is

3. Why We Need Shots at All

4. Zero-Shot Prompting

5. One-Shot Prompting

6. Few-Shot Prompting

7. Why Extra Examples Vote

8. How to Build Shots That Don’t Lie

9. When to Use Which

10. Try This Yourself

11. Conclusion

Introduction

You may have heard the terms zero-shot, one-shot, and few-shot prompting. They sound technical, but they describe something simple: how many examples you put in a prompt.

A shot is one demonstration inside the prompt. Zero-shot means you give only the task. One-shot means you show one finished example alongside the task. Few-shot means you show a small set, usually three to five, so the model can pick up a rule you never wrote down.

It is important to know which one to use. This article walks through all three with two real tasks so you can see exactly what changes.

There is one important catch you need to know before we start. Adding more examples does not always make the answer better. Extra examples can pull the model toward the label you showed most often, or toward the last example you listed. We will cover that after the three techniques are clear.

By the end you will know what a prompt is, why shots exist, when to use each, and how to build examples that do not mislead the model.

What a Prompt Actually Is

A prompt is the text you send to an AI model to tell it what to do.

A useful prompt usually has four parts, even if you do not label them:

• the task: what to do

• the constraints: how to do it

• the output shape: what the answer should look like

• optional context: background the model needs

The image above shows how a prompt works. Your words go in and the model’s output comes out. The model never sees what you meant. It only sees what you wrote. The better you write the prompt, the better the answer you get.

Why We Need Shots at All

Large language models predict the next likely token based on what they have seen in training. They do not execute rules you have not written down. They do not look up your company policy by themselves.

When your instruction is vague, the model falls back on the most common pattern from its training data. That pattern is the internet’s average, not your standard.

Examples help because they do three things at once:

• they anchor what a finished answer looks like

• they narrow the number of ways the model can read the task

• they show the output shape without you having to describe it

That is all a shot is. One demonstration inside the prompt.

The diagram above shows zero-shot, one-shot, and few-shot side by side. The only difference is how many demonstrations you put in the prompt.

The table above compares the three approaches at a glance.

More shots give the model more guidance. They also cost more tokens and can introduce bias. Extra examples can pull the answer toward the ones you showed most often. We will get to that in section 7.

Zero-Shot Prompting

Zero-shot means you give the task and no examples. You are counting on the model having seen this kind of task enough times in training to handle it well.

Sentiment analysis, translation, short summaries, and basic facts all work well at zero-shot. The model knows these because the internet is full of them.

Here is Task A. This same note comes back in one-shot and few-shot so you can compare.

Classify the sentiment of the following text as Positive, Negative, or Neutral. Output only the label.

"The onboarding doc is clear. Nobody has assigned the Week 1 tickets."

Many models will say Negative.

The note is not only negative. The doc is praised and the process is stuck. Zero-shot still has to pick Positive, Negative, or Neutral.

Negative is a common guess. You might have wanted Mixed or Process gap instead. Those labels were not in the prompt.

The screenshot above shows ChatGPT labeling the onboarding note as Negative. Zero-shot had no way to know you wanted “Mixed” because you never showed what Mixed looks like.

Here is Task B. This same example comes back in one-shot and few-shot.

Give me a git branch name for this ticket.

Ticket: "Add retry on webhook timeout"Owner: "dev.singh"

The model will invent a format. You might get feature/add-retry-on-webhook-timeout or dev.singh/webhook-retry or something else. You did not show a format, so the model guesses from its training data.

The screenshot above shows the branch name the model invented. There was no example, so there was no format to follow.

When zero-shot is enough:

• facts that are widely known

• open creative writing where a unique voice is the goal

• simple summaries and translations

• spelling fixes and cleanup

When it starts to fail:

• you need a specific format, like a filename, a date, JSON, or CSV

• you have your own rule, and the model has no way to know it

• the tone has to match a brand or a legal rule

• you need a label like ‘Process gap’, which is not a common word

One-Shot Prompting

One-shot means you show one finished example alongside the task. That one example shows the format and the kind of answer you want.

This is the version you will reach for most often at work.

Task A again. Same onboarding note. This time you show one mixed update with the label you actually want.

Classify the note. Output only the label.

ExampleNote: "The design looks sharp. QA still has no owner."Label: Mixed

TaskNote: "The onboarding doc is clear. Nobody has assigned the Week 1 tickets."Label:

One example is enough to stop the model from defaulting to Negative. The model sees that a note with both good news and bad news gets the label Mixed.

The screenshot above shows the same onboarding note labeled as Mixed after one Mixed example. One demonstration changed the answer.

Task B again. Same webhook ticket. One finished branch name as the example.

Turn the ticket title and owner into a git branch name using the format shown below.

ExampleTicket: "Fix stale cache on checkout"Owner: "meera.k"Output: meera-k/fix-stale-cache-on-checkout

TaskTicket: "Add retry on webhook timeout"Owner: "dev.singh"Output:

From one example, the model copies the owner name, the slash, and the hyphenated title. You did not write a list of formatting rules. You showed one finished branch name.

The screenshot above shows the model copying the format from the example: dev-singh/add-retry-on-webhook-timeout.

When one-shot is the right choice:

• you need a specific format, like a filename, a date, JSON, or CSV

• the task is clear, but you need to show what the answer should look like

• you want the writing to match one good example

For most work tasks, one example is enough. If the task is only a format, and the answer is still wrong after one good example, the problem is usually the example. If the rule has more than one case, you need more examples. That is the next topic.

Few-Shot Prompting

Few-shot means several examples, usually three to five. The model is not just copying a format. It is learning a rule from those examples. Use this when the rule has more than one case.

Task A one more time. Same onboarding note. This time you set the labels yourself: Positive, Mixed, and Process gap. One example cannot show all three. A few examples can.

Classify each note. Use only these labels: Positive, Mixed, Process gap.Output only the label.

Note: "The new hire finished the setup guide and asked good questions."Label: Positive

Note: "Week 2 tickets are still sitting in the backlog. No owner."Label: Process gap

Note: "The runbook is clear. On-call still has no backup."Label: Mixed

Note: "The onboarding doc is clear. Nobody has assigned the Week 1 tickets."Label:

Zero-shot said Negative. We wanted Mixed. The note praises the doc and also says the process is stuck. That matches the Mixed example, not the Process gap example. Process gap is only for a stuck process with no praise.

The screenshot above shows the model returning Mixed. It followed the pattern we showed.

Task B one more time. Same webhook ticket. Three rows that teach the fix/ versus feat/ rule.

Turn the ticket title and owner into a git branch name.

Ticket: "Fix stale cache on checkout"Owner: "meera.k"Output: fix/meera-k/stale-cache-on-checkout

Ticket: "Add CSV export to billing"Owner: "amit.r"Output: feat/amit-r/add-csv-export-to-billing

Ticket: "Add a health check to payments"Owner: "priya.s"Output: feat/priya-s/add-a-health-check-to-payments

TaskTicket: "Add retry on webhook timeout"Owner: "dev.singh"Output:

One-shot gave you the owner slug and kebab-case. Few-shot adds the feat/ prefix because the model saw the pattern across three rows. Same ticket. New rule.

The screenshot above shows feat/dev-singh/add-retry-on-webhook-timeout. The model used feat/ because the examples showed that rule.

When few-shot is worth it:

• the task is uncommon, so one example is not enough

• the labels are close and easy to mix up

• the rule has more than one case, like bugs get fix/ and features get feat/

• you need N/A when the input is bad, instead of a made-up answer

What you pay for it:

• a longer prompt, higher cost, and a slower reply

• extra examples can pull the answer toward the ones you showed most often

That last one is the one that causes trouble. The next section explains how.

Why Extra Examples Can Create Bias in the Answer

More examples give the model more to work with. They can also pull the answer toward a label you did not want.

Researchers have measured this. Zhao et al. documented it in 2021 in Calibrate Before Use: Improving Few-Shot Performance of Language Models. They ran few-shot prompts on GPT-3 and found three patterns. Knowing them helps you write better prompts regardless of which model you use.

Here are the three patterns:

1. Majority label bias: the model leans toward the label that appears most often in the prompt.

2. Recency bias: the model leans toward the label closest to the end of the prompt.

3. Common-token bias: the model prefers a label that appeared often in its training data. “Negative” is a common word. “Process gap” is not.

Majority label bias. Here is the setup I ran.

Classify as Positive or Process gap.Output only the label.

Note: "The new hire finished the setup guide."Label: Positive

Note: "The design review went well."Label: Positive

Note: "We shipped the copy today."Label: Positive

Note: "Week 2 tickets have no owner."Label: Process gap

Note: "QA still has no owner."Label:

The test line is about a missing owner. It is not praise. The prompt has three Positive examples and one Process gap.

The screenshot above shows that live run on the free ChatGPT default in 2026. The model returned Process gap. It followed the correct label. Three Positive examples did not pull it.

Recency bias. The model also gives extra weight to the label closest to the answer slot. If most examples are Positive but the last one is Negative, the model may return Negative. This is a practical reason to check what label is last before you send the prompt.

The diagram above shows the pattern. A prompt that is mostly Positive, with Negative last, pulled GPT-3 toward Negative.

The figure above is from Zhao et al., Figure 4. This is a GPT-3 2.7B result from 2021. In the PPPN order, three of four examples were Positive, yet the model predicted Negative 90% of the time. The last example outweighed the other three.

I ran the same test on the free ChatGPT default and both orders returned Positive. The flip Zhao et al. saw was on GPT-3 in 2021. Newer models handle it better. You may still see it on smaller models.

Common-token bias. The model also prefers labels that appeared often in its training data. When the answer could go either way, the familiar word may win. This matters more on smaller models or when your labels are unusual.

The most common label can bias the answer. The last label can bias the answer. The familiar word can bias the answer. On GPT-3 in 2021, all three showed up clearly.

On today’s default ChatGPT, our tests did not show that bias. On smaller models, you may still see it.

So why learn this?

There are still many places where we use older models. Even if the model is not old, it may be a smaller one, and smaller models can still have this problem. People use smaller models because they are faster and cheaper. Embedded AI is also growing. We want AI in every small device, and those devices have to run a small model. When you work with a model like that, this can still happen.

With bigger and smarter models, this is probably not the issue. It is still important to learn. It also shows how LLMs have improved over the years. That builds a fundamental idea, and it can help you in interviews and in other work.

How to Build Shots That Don’t Lie

Quality beats quantity. One bad example teaches a bad rule. Three clean examples beat ten noisy ones.

Balance the labels. If you have three labels, do not give four Positive examples and only one of the others. The model will lean toward Positive.

Use different phrasing. If all your examples sound the same, the model learns the phrasing, not the logic. Include at least one edge case.

Teach refusal. If the model should return N/A when there is no date in the document, show that. Otherwise it will invent a date.

Check the last row. After you balance the set, look at what label is last. If you need to end on a rare class, consider running the same prompt twice with the last two examples swapped. If the answer changes, the order is doing more work than the instruction.

Show instead of describing. A paragraph about “use kebab-case and an owner slug” is weaker than one finished branch name. Showing the answer is faster and more reliable than describing it.

When to Use Which

The table above shows when to use zero-shot, one-shot, and few-shot, and when to walk away.

If you remember one rule, remember this. Start with zero examples. If the format matters, add one example. Add more only when one example is not enough to show the rule. Keep the labels balanced, and check what label is last.

Conclusion

Zero-shot asks the model to use its training data. One-shot shows your rule once. Few-shot tries to teach a rule from a small set of examples.

Adding more examples is not always better. Zhao et al. showed on GPT-3 in 2021 that extra examples can pull the answer toward the label you showed most often, or toward the last example you listed. I ran the same kind of test on today’s default ChatGPT and did not see that bias. Stronger models today often follow the correct label instead. The finding is still worth knowing. It is part of the foundation of prompting, and it still comes up in interviews.

Write a clear task. Show one clean example if the format matters. Add more examples only when the rule has more than one case. Balance those examples. Try not to end on the odd case. If a few-shot answer looks off, swap the last two examples and check whether the label changes.

If you have any questions, please ask in the comments. I will answer them.

About Decode Lab X

I also write these articles at Decode Lab X. The idea is simple. I decode hard AI topics in plain language, so you can understand them easily.