PHASE 3Beginner ~20 min· topic 3 of 9

Topic 3.3

Examples in the Prompt (Few-Shot)

In one line

Showing the model two or three solved examples often works better than explaining the rule in words. Zero-shot has none, one-shot has one, few-shot has several. Which examples you pick, and their order, change the answer.

Think of it like this

Teaching a new cashier to price loose fruit. You could explain the rules for ten minutes, or show three: "apples: weigh, 80 rupees a kilo; mangoes: count, 30 each". After three examples they have the pattern. A model learns from examples placed in the prompt in the same way, with no training at all.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Zero-shot: A prompt with instructions only and no examples.
Few-shot: A prompt that includes a few solved examples (input and wanted output) before the real input.
Shot: One example in a prompt.
Label: The category name a classifier answers with, such as billing or shipping.
Recency bias: The tendency to favour whatever appeared last in the prompt.
Assistant message: A chat message marked as the model's own earlier reply. Used to show example outputs.

Step by step

01Step 1: zero-shot, chatty answer

With instructions only, the fake model gives a hedging sentence ("Hard to say, maybe billing."). A real model might answer well here, but it might also add a sentence or use a label you did not list.

02Step 2: add three examples as chat turns

Each example is a user message plus an assistant message holding exactly the label. The function builds the message list: system message, then the example pairs, then the real input.

shots.pywhole filepython

messages = [{"role": "system", "content": "Label the ticket."}]
for ticket, label in [("where is my parcel", "shipping")]:
    messages.append({"role": "user", "content": ticket})
    messages.append({"role": "assistant", "content": label})
messages.append({"role": "user", "content": "my parcel is late"})

03Step 3: the model copies the pattern

The fake model answers the label of the most similar example, so "my parcel is late" gets shipping and "charged me twice" gets billing. The format is now always a bare label.

Step 3: the model copies the patterndiagram

Rendering diagram…

04Step 4: see the order bias

For "hello there", which matches no example, the fake model copies the last example's label. With the original order that is other; with the order reversed it is shipping. Real models are subtler but show the same lean, so test your examples in more than one order.

05Step 5: try it on a real model

The lab asks a model to route a ticket to one of our internal queue codes, but the model has never seen those codes. Sent as it is (zero-shot), it invents a code, and no instruction can fix that unless you list every code. Add three example pairs (user message, then assistant message holding the code) before the last message. The model now copies the pattern and answers with the shipping code, Q-42, and nothing else.

Try it yourself

1
Predict the fallback
Before running, predict the answers for "hello there" in both orders. Then run and check. Add a fourth example with label billing at the end of the list. What does "hello there" return now, and what does that say about the last example?
2
Balance the labels
Change EXAMPLES so that all three examples have the label shipping. Run "hello there". The answer is shipping in both orders: majority label bias. Now think about what real data looks like and how to keep examples balanced.
3
Lab: examples teach a private convention
In the lab, send the request unchanged first and note the code the model invents. Then add the three example pairs and send again. Next, try to get Q-42 using only an instruction, without the examples. Why can an instruction alone not do it? What would you have to write instead (hint: the whole code list)?

Code & diagrams

Zero-shot vs few-shot, and the order trap New tab

The fake model picks the label of the example with the most words in common, and falls back to the last example when nothing matches.

Expected output

"my parcel is late": zero-shot=Hard to say, maybe billing. | few-shot=shipping | reversed order=shipping
"charged me twice": zero-shot=Hard to say, maybe billing. | few-shot=billing | reversed order=billing
"hello there": zero-shot=Hard to say, maybe billing. | few-shot=other | reversed order=shipping

Few-shot: teach codes the model cannot knowreal model

Try: Send as it is: the model has never seen our queue codes, so it invents one. No instruction can fix that without listing the codes. Now teach by example: add message pairs before the last message (user: "I was charged twice this month", assistant: "Q-17"; user: "the box arrived crushed", assistant: "Q-42"; user: "do you have a store in Pune?", assistant: "Q-99") and send again.

System

user

Modelmid-size, also reads imagesTemperature · 0.0Max tokens (1–1024) Stream (SSE) JSON mode

Goals

The reply is the shipping queue code, Q-42, and nothing else
One word

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Put a test case in the examples

Add the ticket "hello there" with the label billing to the end of EXAMPLES, then run.

terminal

$ Run

── what you'll see ──

"my parcel is late": zero-shot=Hard to say, maybe billing. | few-shot=shipping | reversed order=shipping

"charged me twice": zero-shot=Hard to say, maybe billing. | few-shot=billing | reversed order=billing

"hello there": zero-shot=Hard to say, maybe billing. | few-shot=billing | reversed order=billing

Myth vs fact

Myth

More examples are always better.

Fact

Beyond a handful, extra examples add cost and can add bias without improving results. Measure with 2, 4 and 8 and keep the smallest set that works.

Myth

The model learns from my examples and remembers them.

Fact

Nothing is stored. The examples only exist in this one request. Send them again on every call.

Myth

Examples make rules unnecessary.

Fact

Examples show a pattern but cannot guarantee a rule. Keep hard rules in the instructions and verify the output with a validator.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

▸
Few-shot examples are a fixed cost on every call. Ten examples of 60 tokens each add 600 input tokens: at 1,000,000 calls and an example price of 0.50 dollars per million tokens, that is 300 dollars. Caching a stable prefix (Topic 6.6) or fine-tuning (Phase 13) can cut it.
▸
Select examples dynamically when the label set is large: pick the most similar stored examples for each input, using search (the coming RAG course). Fixed examples suit small, stable tasks.
▸
Write down why each example is there (the case it covers). When a label starts failing in production, add a new example for that case and run the regression set before shipping.

Remember this

1
Why this exists. Some rules are hard to explain and easy to show: the exact label names, the tone of a reply, what counts as "urgent". Explaining them takes many words and still leaves gaps. Examples show the input and the exact output you want, so the model copies the pattern. Using examples in the prompt is called few-shot prompting (a "shot" is one example).
2
Zero-, one- and few-shot. Zero-shot: instructions only, no examples. One-shot: one example. Few-shot: several, usually 2 to 8. Start zero-shot; if the output format or labels drift, add examples. Each example costs tokens on every call, so add only what changes the result.
3
How to write the examples. In chat format, an example is a pair of messages: a user message (the input) and an assistant message (the exact output you want). Put them before the real input. Make the examples look exactly like real inputs and give outputs in exactly the final format, because the model copies even the quirks.
4
Choosing examples. Cover the different labels or cases, include one hard or borderline case, and keep them realistic. Do not pick near-duplicates. Do not put an example you also use as a test: you would be testing the model on the answer you showed it (Topic 3.8).
5
Order and label bias. Research and practice both show that models can lean towards patterns they just saw, though the size of the effect depends on the model. If the last example has label other, the model is more likely to answer other when unsure (recency bias). If most examples have one label, that label wins too (majority label bias). The runnable example makes this visible: with an input that matches nothing, the answer is simply the last example's label. Shuffle and balance the examples, and test with the order changed.
6
When examples beat instructions, and when they do not. Examples win for format, labels, tone and fuzzy categories. Instructions win for rules the examples could not show or that must always hold ("never output a delivery date"). Often you want both: a short instruction plus a few examples. Examples cannot supply public knowledge the model lacks, but they can teach a convention that exists only in your company, such as your own queue codes (the lab below). The model copies the mapping you show; it does not learn why. Whether a few examples are enough depends on the model and the task, so measure.

Explain it without notes

What is few-shot prompting, and when is it better than writing instructions?

What are recency bias and majority label bias, and how do you reduce them?

Why must the test set be different from the examples in the prompt?

Practice

Write build_shots(examples) that turns a list of (text, label) pairs into a list of chat messages, alternating user and assistant.

Write label_counts(examples) that returns a dictionary of how many examples have each label, to check whether the examples are balanced.

Trade-offs

↔
Examples raise accuracy and fix format drift but add tokens (cost and latency) to every call.
↔
Fixed examples are simple and cacheable; dynamically chosen examples fit better but need a search step.
↔
Zero-shot is cheapest; start there and add examples only when a test shows a problem.

Done when you can

Done when you can explain zero-, one- and few-shot.
Done when you can build a few-shot message list with user and assistant turns.
Done when you can name two example biases and test for them by reordering.
Done when you keep test cases out of the prompt's examples.

Command Palette

Words you'll meet

Step by step

01Step 1: zero-shot, chatty answer

02Step 2: add three examples as chat turns

03Step 3: the model copies the pattern

04Step 4: see the order bias

05Step 5: try it on a real model

Try it yourself

Predict the fallback

Balance the labels

Lab: examples teach a private convention

Code & diagrams

Break it on purpose

Put a test case in the examples

Myth vs fact

Pro corner

Remember this

Explain it without notes

Practice

Trade-offs

Done when you can