Zero-shot and few-shot

A zero-shot prompt gives the instruction and the new input only. A few-shot prompt adds a small set of worked pairs first.

The pairs demonstrate format, labels, and edge handling. The model still generalizes from them, with success that varies by model and task.

What examples change

Examples pin down label names and output format, and show how to treat boundary inputs. They can steer a naming-convention guess, but reset polarity must come from the code or interface contract.

The transcript below is schematic, not a real reply from any system. It shows examples steering a naming-convention guess, which still needs confirming from the code.

1
2
3
4
5

schematic transcript, invented for illustration
USER (zero-shot): Classify reset polarity: signal reset_n, asserted.
MODEL (schematic): active-high. Reason: the name without the suffix pattern shown.
USER (few-shot, two pairs shown first): rst asserted -> active-high; rst_n asserted -> active-low. Now: reset_n, asserted.
MODEL (schematic): active-low. Reason: follows the suffix pattern in the pairs.

The program below compares an always-active-high rule with an exact lookup. Every test entry also appears in the lookup table, so its result demonstrates memorisation only, not few-shot generalisation or a real model's performance. Signal suffixes are conventions, not specifications: determine polarity from the interface contract or code before assigning a label.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

import sys

def zero_shot(text):
    return "active-high"

EXAMPLES = [
    ("rst asserted", "active-high"),
    ("rst_n asserted", "active-low"),
    ("reset asserted", "active-high"),
    ("reset_n asserted", "active-low"),
]

def few_shot(text):
    for pattern, label in EXAMPLES:
        if pattern == text:
            return label
    return "active-high"

CASES = [
    ("rst asserted", "active-high"),
    ("rst_n asserted", "active-low"),
    ("reset asserted", "active-high"),
    ("reset_n asserted", "active-low"),
]

zero_ok = 0
few_ok = 0
for text, want in CASES:
    if zero_shot(text) == want:
        zero_ok = zero_ok + 1
    if few_shot(text) == want:
        few_ok = few_ok + 1

if zero_ok == 2:
    pass
else:
    print("FAIL: zero-shot count changed")
    sys.exit(1)
if few_ok == 4:
    pass
else:
    print("FAIL: few-shot count changed")
    sys.exit(1)
print("PASS: lookup mechanics match 4 stored entries; constant rule matches 2; no AI performance measured")

Try an unseen engineering case

Use an approved assistant with two public examples whose reset polarity is explicitly stated in code, not inferred from a name. Reserve different examples for evaluation: a signal named reset_n used in if (reset_n), a parameter-selected reset polarity, and a snippet with no reset logic. Ask for polarity, supporting line and uncertainty. Compare instruction-only and example-assisted requests on the same cases; keep failures as well as successes. Offline learners can work out the reference answers without calling a model.

Cost of examples

Examples ride along on every request, so they multiply input tokens. Output length stays about the same when the answer shape is fixed.

The arithmetic below uses clearly labelled EXAMPLE prices. It shows the formula, the substitution, and the result in units.

1
2
3
4
5
6
7
8
9
10

EXAMPLE prices: 1M input tokens cost 3 units, 1M output tokens cost 9 units
requests = 10000
zero-shot input = 200 tokens, few-shot input = 900 tokens, answer = 100 tokens
zero-shot input tokens = 200 x 10000 = 2000000 = 2M -> 2 x 3 = 6 units
zero-shot output tokens = 100 x 10000 = 1000000 = 1M -> 1 x 9 = 9 units
zero-shot total = 6 + 9 = 15 units
few-shot input tokens = 900 x 10000 = 9000000 = 9M -> 9 x 3 = 27 units
few-shot output tokens = 9 units (same answers)
few-shot total = 27 + 9 = 36 units
extra for examples = 36 - 15 = 21 units

Common mistakes

More examples are not automatically better. Stale or inconsistent pairs teach the wrong convention.

Related topics

• Choosing and ordering examples

• Anatomy of a prompt

• Muxes, decoders and encoders