Zero-Shot, One-Shot and Few-Shot Prompting

Zero-shot: instructions only

Zero-shot prompting means giving a model a task with instructions only, without any worked example of the answer you want. Most everyday prompts are zero-shot, and for common tasks (summarize, translate, explain, draft) that is usually enough: the model has seen countless examples of such tasks during training.

Classify this Kestrel Energy ticket as Account, Billing, Network or Portal. Answer with the label only.

Ticket: Portal is unreachable from the hotel Wi-Fi; other websites work.

Zero-shot reaches its limits when the task depends on your own conventions. Is a portal that is unreachable from one network a Network ticket or a Portal ticket? Your team has an answer; the model can only guess, and the instructions would need a paragraph to explain the rule. One example often explains it faster.

One-shot: a single example

One-shot prompting adds exactly one worked example of input and desired output to the instructions. It is the quickest way to pin down a format: the layout of an internal note, the fields of a summary, the length of a reply.

Turn the engineer's notes into an internal ticket note in the format of the example.

<example>
Notes: called user, vpn 809 at hotel, tried hotspot works, closing
Ticket note:
INC-40188 · Symptom: VPN error 809 on hotel Wi-Fi. Action: user switched to phone hotspot; VPN connects. Next step: none, ticket resolved.
</example>

Notes: printer 3rd floor offline again, power cycled, back online, asked facilities to check socket
Ticket note:

The risk of a single example is that everything in it looks like a rule. If the one example is about VPN and ends with "ticket resolved", the model may lean toward VPN wording or toward closing tickets. One example shows the shape; it says nothing about what may vary.

Few-shot: several examples

Few-shot prompting gives several examples, typically three to five. With several examples the model can see what stays the same (the format, the label set, the tone) and what changes (the content), which is exactly what a single example cannot show.

The ability behind this is called in-context learning: a large language model picks up a task from the instructions and examples in its prompt, without any change to the model itself. The 2020 GPT-3 paper by Brown et al., "Language Models are Few-Shot Learners", made the idea widely known: a model with 175 billion parameters handled many tasks specified purely through text and a few demonstrations, without retraining. "Learning" is a loose word here. Nothing is stored; the next request without the examples gets zero-shot behavior again. Changing the model itself is fine-tuning, a much heavier tool.

Examples do not fence the model in, either. Microsoft's prompt engineering documentation shows a classification where the model answered with a label that none of the examples used. If only certain answers are allowed, list them explicitly in the instructions as well, and check the answers in code when a program uses them (see Structured Output).

What the vendors advise

The major vendors agree that examples help, but disagree on how much and when. Their published guidance as of October 2026:

The advice differs because the models differ, and because each vendor writes for its own newest models. The practical conclusion is the same everywhere: start simple, and add examples when your test cases show that the model misreads the format, the labels or the borderline cases.

Choosing good examples

Example selection is choosing which worked examples go into a prompt, and in what order, so that together they show the pattern you want. Because the model imitates them closely, the choice matters more than the number:

• Relevant: real cases like the ones the prompt will meet, not textbook ones.
• Varied: different wording, lengths and subjects, so the only thing they share is the pattern.
• Borderline cases first: spend your examples where your conventions are not obvious ("portal slow, but only over the VPN" is Network for Kestrel's service desk).
• Balanced: for a classification, one example per label, so no label looks like the default.
• Consistent format: every example laid out the same way, and the same way you want the answer.
• Marked off: inside <example> tags or a clearly labeled section, so the model does not mistake an example for the task.

For tasks that need reasoning, such as deciding whether a change conflicts with a maintenance window, an example can show the method as well as the answer: the facts, the check that was made, and the conclusion. The model then copies the way of working rather than only the format of the result.

Categorize these Kestrel Energy tickets:
1. Customer portal times out, but only when the user is on the company VPN.
2. Customer was charged twice for September.
3. Password reset email never arrives.
4. The meter readings page in the portal only shows yesterday's data.
5. Field engineer's laptop cannot reach the portal from a substation network; other sites load.

Categorize Kestrel Energy tickets. Use exactly one of these labels: Network, Account, Portal, Billing. Answer with the ticket number and the label only, one per line.

<examples>
<example>Ticket: Portal unreachable from the hotel Wi-Fi; other websites work.
Label: Network</example>
<example>Ticket: Reading form in the portal shows a blank page after login.
Label: Portal</example>
<example>Ticket: Invoice PDF shows the old billing address.
Label: Billing</example>
</examples>

Tickets:
1. Customer portal times out, but only when the user is on the company VPN.
2. Customer was charged twice for September.
3. Password reset email never arrives.
4. The meter readings page in the portal only shows yesterday's data.
5. Field engineer's laptop cannot reach the portal from a substation network; other sites load.

Results vary between runs and assistants; run each prompt twice before drawing conclusions.

When examples are copied

Example overfitting is when a model copies incidental features of the examples in a prompt (their length, phrases, names, subjects or label distribution) instead of only the pattern they were meant to show. The name borrows from overfitting in machine learning, but nothing is trained here; the effect comes entirely from the prompt. Typical symptoms:

• All example replies start with "Thank you for contacting Kestrel Energy", so every answer does too, even internal notes.
• All examples are short, so a complex case gets a short, thin answer.
• Two of three examples are labeled Portal, so unclear tickets become Portal.
• An example mentions server web-03, and the model mentions web-03 in an answer about a different server.

The fixes follow from the cause: vary the examples so that the unintended features differ between them, balance the labels, and say what the examples are for.

The examples below show the format and the level of detail of a handover note. Their content is unrelated to the current ticket: do not reuse names, servers or actions from them.

Examples in applications

When a prompt runs in an application, examples come from a list the team maintains, and code assembles the prompt. The example picks one example per label, the first listed for each, so every label is represented once, and builds the prompt with <example> tags. It also checks something easy to get wrong: whether any example also appears in the set of tickets used to test the prompt. A test ticket that is also an example only measures whether the model can copy, the prompt version of data leakage.

# Labeled tickets the team agreed on: (ticket id, summary, label).
labeled = [
    ("INC-40102", "Portal shows error 500 after login", "Portal"),
    ("INC-40107", "Invoice amount doubled this month", "Billing"),
    ("INC-40111", "Portal is slow, but only over the VPN", "Network"),
    ("INC-40115", "Account locked after password change", "Account"),
    ("INC-40118", "Cannot download invoice PDF from the portal", "Portal"),
    ("INC-40124", "Direct debit taken twice", "Billing"),
]

# Tickets we will use to TEST the prompt.
test_set = [
    ("INC-40211", "MFA code not accepted on new phone"),
    ("INC-40111", "Portal is slow, but only over the VPN"),
    ("INC-40230", "Meter reading form gives a blank page"),
]


def pick_examples(rows):
    """One example per label (the first one listed), labels in sorted order."""
    chosen = {}
    for ticket_id, summary, label in rows:
        chosen.setdefault(label, (ticket_id, summary, label))
    return [chosen[label] for label in sorted(chosen)]


examples = pick_examples(labeled)
labels = ", ".join(label for _, _, label in examples)

lines = [f"Classify the ticket as one of: {labels}. Answer with the label only.",
         "<examples>"]
for _, summary, label in examples:
    lines.append(f"<example>Ticket: {summary}\nLabel: {label}</example>")
lines.append("</examples>")
print("\n".join(lines))

# A test ticket that is also an example measures copying, not skill.
overlap = sorted({t for t, *_ in examples} & {t for t, _ in test_set})
print()
print("Examples that also appear in the test set:", overlap or "none")

Classify the ticket as one of: Account, Billing, Network, Portal. Answer with the label only.
<examples>
<example>Ticket: Account locked after password change
Label: Account</example>
<example>Ticket: Invoice amount doubled this month
Label: Billing</example>
<example>Ticket: Portal is slow, but only over the VPN
Label: Network</example>
<example>Ticket: Portal shows error 500 after login
Label: Portal</example>
</examples>

Examples that also appear in the test set: ['INC-40111']

Ticket INC-40111 should be removed from the test set (or replaced by another example), otherwise the test overstates how well the prompt handles VPN-related portal problems.

In chat APIs, examples can also be sent as a fake conversation: each example input as a user message and each desired output as an assistant message, before the real question. Microsoft's documentation describes this layout. The shape below is generic; some APIs, such as Anthropic's, put the system prompt in a separate field instead of a system message.

[
  {"role": "system", "content": "Classify Kestrel Energy tickets as Account, Billing, Network or Portal. Answer with the label only."},
  {"role": "user", "content": "Portal unreachable from the hotel Wi-Fi; other websites work."},
  {"role": "assistant", "content": "Network"},
  {"role": "user", "content": "Invoice PDF shows the old billing address."},
  {"role": "assistant", "content": "Billing"},
  {"role": "user", "content": "Password reset email never arrives."}
]

Cost and limits

Examples are sent with every request, so they are paid for every time: five examples can easily triple the input of a short classification prompt (the cost calculation shows this). They are worth it when they measurably improve the answers on your test cases, and not otherwise. Run the same test set with zero, one and three examples and compare; see Iterating and Testing Prompts.

Examples also stop helping at some point. If a task needs dozens of examples to work, the instructions are probably unclear (see Clear and Specific Instructions), the task may be too large for one prompt (see Breaking Down Tasks: Prompt Chaining), or the model lacks knowledge that examples cannot supply. And examples teach a pattern, not facts: a perfectly formatted answer can still be wrong.