ap.Abhishek Patel

Search

Search notes, essays, projects, the library and the AI course. Use arrow keys to choose and Enter to open.

Lesson 4 of 7 25 min

Zero-shot, one-shot and few-shot prompting

Teach a model your house rules with well-chosen examples, and prove the improvement by measuring zero-shot and few-shot prompts against a hand-labelled answer key.

Words in this lessonZero-shot prompting · One-shot prompting · Few-shot prompting · In-context learning · Parameters · Recency bias
Zero-shot prompting
Asking a model to do a task with instructions only, and no worked examples. Like handing a new colleague a list of categories and walking away.
One-shot prompting
Giving a model a single worked example before the real task. Like showing a trainee one finished order slip and hoping they guess which parts were important.
Few-shot prompting
Giving a model several worked examples in the prompt so it copies your pattern. Like tagging a dozen reviews side by side with a new colleague before letting them work alone.
In-context learning
A model picking up a pattern from examples inside its prompt, without any retraining. Like reading a cheat sheet before each task rather than actually memorising the material.
Parameters
The adjustable numbers inside a model, set during training, that decide what it outputs. Like the knobs on a sound mixing desk: the same desk sounds completely different depending on where the knobs sit.
Recency bias
The tendency of a model to lean towards the label or pattern of the last examples it saw. Like a judge who scores the last contestant highest because they are freshest in mind.
On this page
  1. Arjun tries to explain harder
  2. How Kavita learned, and how a model can too
  3. Following one smashed cake through three prompts
  4. Opening the hood: why examples work so well
  5. Building it in code, one step at a time
  6. Where it breaks
  7. Try it yourself
  8. Common mistakes
  9. Recap
  10. Go deeper

Meera had a clear request. “Every review should be tagged with one of our five categories: freshness, taste, packaging, delivery, service. Then each month I can see where we’re slipping, and who needs to fix it.”

The five categories were not random. Each one belonged to a team. Freshness went to the bakers, taste to the recipe team, packaging to the dispatch team who chose boxes, delivery to the logistics lead who managed the delivery partners, and service to the store managers.

Arjun wrote the prompt in two minutes and ran it on fifty recent reviews. The tags that came back included “quality”, “value for money”, “customer experience”, and, for one long review about a grandmother’s birthday, “emotional”. None of those were on Meera’s list.

He added “Use ONLY these five categories” in capital letters. The invented categories stopped. But one review, “Delivery guy dropped the box, cake was completely smashed”, came back as delivery. Meera frowned at it. “That’s packaging. We decided last year: if the cake arrives damaged, it’s on the dispatch team. They’re the ones who switched to the stronger boxes.”

“How was the model supposed to know that?” Arjun asked.

“It wasn’t,” said Priya. “Which is the problem.”

Important

The idea in one sentence: Zero-shot prompting gives the model instructions only, one-shot adds a single worked example, and few-shot adds several, and well-chosen examples are the fastest way to teach a model your private meanings, boundary rules and output format without any training.

Arjun tries to explain harder

Arjun’s next move was what most people do: describe each category in more detail. He wrote a paragraph per category, about 300 words in all:

- packaging: issues with boxes, containers, wrapping, presentation, or the
  physical state of the product caused by its container...
- delivery: issues with timing, delivery partners, wrong address, the driver's
  behaviour, or anything that happened in transit...
(and three more paragraphs)

To measure it properly, he asked Kavita, who had read Crumb’s reviews for three years, to hand-label the same fifty reviews. Her labels became the answer key. Then he scored each prompt against it:

Prompt Correct out of 50 Accuracy
Zero-shot, five category names 36 72%
Zero-shot, 300 words of definitions 39 78%

Better, but the smashed cake was still delivery. Read his definitions again and you can see why: “anything that happened in transit” covers a dropped box perfectly well. His descriptions were reasonable. They were not Crumb’s rule. And the more he wrote, the more chances there were for two definitions to overlap.

“I can’t write a definition for every weird case,” Arjun said.

Priya asked, “How did Kavita learn these categories? Did Meera give her a 300-word document?”

Arjun thought about it. “No. On her first day, she sat with Meera and they tagged a pile of reviews together. Kavita said what she thought, and Meera corrected her.”

“How many reviews before she got it?”

“She says about a dozen. After that she knew.”

“So stop describing. Start showing.”

How Kavita learned, and how a model can too

Priya listed three ways to train a new person on the whiteboard:

  • Hand them the list of five categories and walk away. That is zero-shot: instructions only, no examples.
  • Tag one review in front of them. That is one-shot: a single example.
  • Sit with them and tag six reviews together, deliberately including the tricky ones. That is few-shot: several examples.

“Shot” is borrowed from research jargon, where one example is called a shot. The surprising part is that a model learns from examples in the prompt itself. Nobody retrains it. This ability is called in-context learning: the model picks up a pattern from examples in its input and applies it to the next item, all within one call.

“So the model gets permanently better at our categories?” Arjun asked.

“No. That’s the most common misunderstanding. The model’s parameters, the billions of numbers it learned in training, don’t change at all. The examples work for this one call. The next call starts from zero unless you send the examples again. It’s less like teaching Kavita and more like handing her a cheat sheet she reads before each review.”

Following one smashed cake through three prompts

Here is the review they traced, step by step:

“Delivery guy dropped the box, cake was completely smashed.”

Zero-shot. The prompt:

Classify the Crumb review into exactly one category:
freshness, taste, packaging, delivery, service.
Reply with only the category name.

Review: "Delivery guy dropped the box, cake was completely smashed."

Answer: delivery. Reasonable, and wrong for Crumb. The words “delivery guy” pull strongly towards delivery.

One-shot. Arjun added a single example of Crumb’s house rule:

Classify the Crumb review into exactly one category:
freshness, taste, packaging, delivery, service.

Review: "Box was crushed and the cream was all over the lid."
Category: packaging

Review: "Delivery guy dropped the box, cake was completely smashed."
Category:

Answer: packaging. Correct. Then he ran the one-shot prompt on all fifty reviews and got 40 right, 80%. But something odd appeared: “Arrived 3 hours late but tasted great” came back as packaging too. So did two other delivery-time complaints that happened to mention a box.

Note

Pause and think. The one-shot example was about a crushed box. Why might it have pulled a clearly late delivery towards packaging?

Show the answer

With only one example, the model cannot tell which features of it matter. Was the lesson “damaged product means packaging”? Or “anything mentioning a box means packaging”? Or even “the answer is usually packaging”? A single example is a very strong signal with no way to separate the point from the coincidence. Several varied examples fix this: when delivery examples also mention boxes, the model learns that the box is not what decides the category.

Few-shot. They chose six examples on purpose: at least one per category, plus the two boundary cases the team had argued about.

Classify each Crumb review into exactly one category:
freshness, taste, packaging, delivery, service.
If a review covers several, pick the team that needs to act.

Review: "Box was crushed and the cream was all over the lid."
Category: packaging

Review: "Arrived an hour after the slot, but the cake in the box was perfect."
Category: delivery

Review: "Bread was dry and hard the next morning."
Category: freshness

Review: "Too sweet for us, the icing overpowered everything."
Category: taste

Review: "The staff at Aundh store were so patient with my mum."
Category: service

Review: "Driver dropped the hamper on the stairs, two jars broke."
Category: packaging

Review: "Delivery guy dropped the box, cake was completely smashed."
Category:

Answer: packaging. And across all fifty reviews: 47 correct, 94%. The late-delivery reviews went back to delivery, because one delivery example now mentions a box too.

The cost. The six examples add about 180 tokens to each call. Crumb tags about 9,000 reviews a month, so that is 1.6 million extra input tokens. At an illustrative small-model price of 0.40, about ₹36 a month, for going from 72% to 94%. The three remaining mistakes were reviews Kavita herself called “honestly a coin toss”.

Opening the hood: why examples work so well

Remember what the model does: it continues text. Few-shot prompting turns your task into a pattern-completion puzzle. After six blocks of Review: ... / Category: ..., the most natural continuation of the seventh Category: is a single word from the same five, chosen the same way the examples chose.

You can see this in the probabilities. These numbers are illustrative, but they show the shape of what happens to the model’s choice of next token after Category: for the smashed-cake review:

Prompt P(delivery) P(packaging) Other
Zero-shot 0.61 0.30 0.09
One-shot 0.22 0.71 0.07
Few-shot 0.09 0.86 0.05

The examples do not add knowledge. The model already knew what boxes, drivers and delivery are. They shift the odds towards your way of drawing the lines.

This also explains three quirks that experienced engineers watch for:

  • Format is copied faithfully. If examples answer in lowercase single words, so will the model. This is the cheapest way to control format.
  • Label balance matters. If four of six examples say taste, the model leans towards taste on unclear reviews. It is learning “most answers are taste” along with everything else.
  • Recency bias. The last example or two have extra pull. If they share a label, borderline cases drift towards it. Shuffle the order, and avoid ending on a run of one label.

Warning

Never put a review from your answer key into the prompt as an example and then measure accuracy on that same review. The model will get it right because you handed it the answer, and your accuracy number becomes a lie. Keep the labelled test set completely separate from your example bank.

Building it in code, one step at a time

Step 1: a measuring stick before anything else. Store Kavita’s fifty labels in a CSV file (review,label) and write a tiny evaluation function. Without this, “it seems better” is a feeling, not a fact.

import csv

def load_labelled(path: str) -> list[tuple[str, str]]:
    with open(path) as f:
        return [(row["review"], row["label"]) for row in csv.DictReader(f)]

def accuracy(classify, labelled) -> float:
    correct = sum(classify(text) == label for text, label in labelled)
    return correct / len(labelled)

TEST_SET = load_labelled("labelled_reviews.csv")   # Kavita's 50; never used as examples

Step 2: the zero-shot baseline.

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI()
MODEL = os.getenv("OPENAI_MODEL", "gpt-5-mini")  # model names change; see the provider's models page

INSTRUCTIONS = ("Classify Crumb bakery reviews into exactly one of: freshness, taste, "
                "packaging, delivery, service. If several apply, pick the team that "
                "needs to act. Reply with the category only, lowercase.")

def classify_zero_shot(review: str) -> str:
    resp = client.chat.completions.create(model=MODEL, messages=[
        {"role": "system", "content": INSTRUCTIONS},
        {"role": "user", "content": review},
    ])
    return resp.choices[0].message.content.strip().lower()

print(f"zero-shot: {accuracy(classify_zero_shot, TEST_SET):.0%}")

Arjun saw zero-shot: 74% with the improved instructions, close to his earlier result.

Step 3: few-shot as fake conversation turns. With chat APIs, a neat way to give examples is as earlier user and assistant messages. The model sees itself “already having answered” several reviews the right way:

EXAMPLES = [   # chosen by hand: every label, plus the boundary cases
    ("Box was crushed and the cream was all over the lid.", "packaging"),
    ("Arrived an hour after the slot, but the cake in the box was perfect.", "delivery"),
    ("Bread was dry and hard the next morning.", "freshness"),
    ("Too sweet for us, the icing overpowered everything.", "taste"),
    ("The staff at Aundh store were so patient with my mum.", "service"),
    ("Driver dropped the hamper on the stairs, two jars broke.", "packaging"),
]

def classify_few_shot(review: str) -> str:
    messages = [{"role": "system", "content": INSTRUCTIONS}]
    for text, label in EXAMPLES:                       # each example is a user/assistant pair
        messages.append({"role": "user", "content": text})
        messages.append({"role": "assistant", "content": label})
    messages.append({"role": "user", "content": review})
    resp = client.chat.completions.create(model=MODEL, messages=messages)
    return resp.choices[0].message.content.strip().lower()

print(f"few-shot: {accuracy(classify_few_shot, TEST_SET):.0%}")

You should see a clear jump. Arjun’s run printed few-shot: 94%.

Step 4: look at the mistakes, not only the score. Print every disagreement:

for text, label in TEST_SET:
    guess = classify_few_shot(text)
    if guess != label:
        print(f"expected {label:10} got {guess:10} | {text[:70]}")

The three misses told Arjun more than the 94% did. One was a Hinglish review, “cake mast tha but dabba toota hua tha” (“the cake was great but the box was broken”), labelled taste. None of his examples were in Hinglish. He added one Hinglish example, reran, and got 48 out of 50.

Where it breaks

Few-shot prompting is powerful and cheap, which makes it easy to overuse or misuse. Here is what Arjun ran into over the following months.

Examples that contradict the instructions. When Meera added a rule, “reviews about price go under service”, Arjun updated the instructions but not the examples. One example still tagged a price complaint as taste. The model followed the example. Examples speak louder than instructions; keep them in sync.

The surface trap. All his early examples were one short sentence. Long, rambling reviews, the ones about family occasions, were classified worse, because nothing in the examples looked like them. Vary length, language and mood in your examples, not only the labels.

The new product. When Crumb launched cold coffee, reviews like “too much ice, felt watery” had no obvious home. The model picked taste or freshness almost at random. Few-shot teaches the boundaries you have shown it. When the world changes, your examples must change too.

Too many examples. Inspired, Arjun tried forty examples. Accuracy went from 96% to 96%, and every call got six times longer. Most tasks plateau somewhere between three and ten good examples.

Note

Pause and think. Crumb now has 1,000 reviews hand-labelled by Kavita. Should Arjun put all 1,000 in the prompt as examples? If not, what are his options?

Show the answer

No. A thousand examples would be roughly 30,000 tokens per call, slow and expensive, with little accuracy gain past ten or so. Better options: keep a small, hand-picked set of six to ten examples; or pick examples dynamically, choosing the few labelled reviews most similar to each new one (you will learn how to measure similarity with embeddings in Module 07); or, with thousands of labels, train a small dedicated classifier (Module 11) or fine-tune a model (Module 33), which bakes the pattern into the parameters so you stop paying for examples on every call.

Try it yourself

Crumb’s WhatsApp line needs messages tagged as new-order, change-order, complaint or question. The house rule: tag by the action the customer wants, not their mood.

  1. Write ten test messages yourself and label them, including at least three tricky ones, like “can I change my order? the last one was terrible”.
  2. Write a zero-shot prompt and measure it on your ten.
  3. Write a few-shot prompt with four to six examples (not from your test set) and measure again.
Show the answer

There is no single right answer, but a strong few-shot set:

  • Has at least one example per label.
  • Includes a boundary case with the house rule applied, for example “can I change tomorrow’s order to eggless? last time the cake was dry” → change-order, because the customer wants a change, even though they also complain.
  • Mixes English, Hinglish, short and long messages.
  • Is shuffled, not grouped by label.

Expect zero-shot to wobble on mixed messages (calling the example above a complaint) and few-shot to follow your rule. If both score ten out of ten, your test messages are too easy: write harder ones until zero-shot fails, then see whether examples fix it.

Common mistakes

  • Skipping zero-shot. Try instructions alone first. If they are good enough, you saved tokens and complexity.
  • No answer key. Without a labelled test set, you cannot tell whether a change helped. Fifty labelled items is enough to start.
  • Unbalanced or same-looking examples. Cover every label, vary style and length, shuffle the order.
  • Testing on your examples. Keep the test set and the example bank strictly separate.
  • Examples out of sync with the instructions. When a rule changes, update both.
  • Assuming the model learned permanently. In-context learning lasts for one call. Send the examples every time, or fine-tune.

Recap

  • Zero-shot is instructions only; try it first and measure it.
  • One-shot teaches format well but can be over-copied, because the model cannot tell which features of a single example matter.
  • Few-shot, usually three to ten deliberate examples, teaches your house rules and boundary cases far better than long definitions.
  • In-context learning shifts the model’s odds for this call only; its parameters never change.
  • Choose examples to cover every label and the hard cases, vary their style, shuffle them, and keep them separate from your test set.

At the end of the month, Meera’s dashboard showed packaging complaints down by a third since the new boxes. “So how did you get it to understand our categories?” she asked.

“The same way Kavita learned,” Arjun said. “I stopped writing long explanations and showed it six reviews we’d already tagged, including the arguments, like the dropped cake. It copies the pattern. It doesn’t remember between calls, so we send the examples every time, but that costs about thirty-six rupees a month. And I measure it against fifty reviews Kavita tagged, so I know it’s 96%, not ‘seems fine’.”

Meera tapped the screen. “Good. Now a harder one. If I offer 15% off Diwali hampers over ₹2,000, but loyalty members already get 10% off and the discounts don’t stack, what does a loyalty member pay for a ₹2,400 hamper and a box of nankhatai?” Arjun typed it into the model. It answered instantly, confidently, and wrong.

Go deeper

Check your understanding

3 quick questions
1. After a few-shot prompt improves accuracy from 72% to 94%, what has happened to the model?
2. A one-shot example about a crushed box starts pulling clearly late deliveries towards "packaging". What is the most likely cause?
3. Which practice makes your accuracy number meaningless?