What is a zero-shot prompt? Give an example.

What you need to know

The word shot means a worked example inside the prompt. Zero-shot means none, one-shot means one, few-shot means a handful.

Zero-shot works because large models have already seen millions of examples of common tasks — sentiment, summarising, translation, classification — during training. The instruction only needs to name the task and the output shape.

What makes a zero-shot prompt strong

• Name the task precisely. "Classify" with a closed list of labels, not "what is this about?"
• Define each label when your meaning is not the obvious one. This is where most zero-shot failures come from.
• Fix the output format. "Return only the label" or a JSON schema.
• Give the fallback. What to output when nothing fits.

Where zero-shot struggles

• Your definitions differ from common sense. Is "I was charged twice" a billing ticket or a refund ticket? The model guesses; your business has a rule.
• Unusual output formats the model rarely saw in training.
• Subtle judgement where your standard is stricter or looser than typical — for example what counts as "urgent".

In 2026 the gap between zero-shot and few-shot is smaller than it was in 2022. On current models, a zero-shot prompt with clear label definitions often matches a few-shot prompt, and it costs fewer tokens on every call.

A real-life example

A food-delivery company routes 40,000 support tickets a day. The first zero-shot prompt:

Classify this ticket as billing, delivery, refund or other.Ticket: "Paid via UPI, money debited, but the app shows payment failed."

The model answers "billing" in some runs and "refund" in others, and sometimes writes a sentence of explanation. On a 300-ticket test set it scores 81% accuracy. The improved zero-shot prompt adds definitions and a strict format:

Classify the support ticket into exactly one label.Labels:- billing: payment failed, double charge, wrong amount, UPI debit issues- delivery: late, missing or damaged order- refund: customer asks for money back for a completed order- other: anything elseReturn only the label, in lowercase, with no other text.Ticket: "Paid via UPI, money debited, but the app shows payment failed."

The answer is now billing every time, and accuracy on the same 300 tickets rises to 92%. No examples were needed — the fix was the definitions.

Follow-up questions to expect

• "When do you move from zero-shot to few-shot?" — When errors cluster on a pattern that definitions cannot express, such as a tone, a format, or borderline cases. I add a few examples targeted at those failures and re-run the evaluation.
• "Is zero-shot chain of thought the same thing?" — It is zero-shot plus "think step by step". On reasoning models that think by default, that phrase adds little; you control depth with the API's effort setting instead.
• "Why not always use examples?" — They cost tokens on every call, and the model copies them closely, which can narrow its output.