Lesson 2.1: Examples: zero, one and few-shot prompting

Learn when examples beat instructions, how to choose and format them, and how to tell whether another example is worth its cost.

By the end of this lesson you will be able to tell zero-shot, one-shot and few-shot prompts apart, decide when an example will help more than another instruction, pick and lay out examples that teach the right lesson, and judge whether adding more examples is worth the extra cost. You will build a few-shot prompt for a real classification task, see what changes as examples are added, and learn why a test of twenty cases cannot tell you much about accuracy. You should have read Module 1, since examples are one more part of the prompt, the part the anatomy lesson called "show, do not only tell". No technical background is needed.

A sentence that describes a style is a weak teacher. A single example of that style is a strong one. People learn this early: an apprentice shown one finished piece of work grasps in a minute what a page of description would not convey. Language models respond to examples in the same way, and using them well is one of the highest-value skills in everyday prompting.

Three ways to ask

The names describe how many examples you include in the prompt.

Zero-shot: no examples, only instructions. "Classify this customer message as Billing, Fraud, Account or Other." One-shot: one example. The same instruction, plus one message and its correct label. Few-shot: several examples, usually between two and ten, each with its correct answer.

The word "shot" here means an example shown to the model. Nothing is retrained. The model does not learn permanently from your examples. It reads them as part of the prompt and continues the pattern, and when you start a new chat the examples are gone.

Predict first: you want an assistant to label customer messages with one of four categories. You write the instruction and nothing else. Which kinds of messages do you think the model will get wrong? Decide before reading on.

The easy messages will be right: "I was charged twice" is clearly Billing. The wrong ones will be the borderline cases, such as "My card was used in another city and I can't log in", which could be Fraud or Account, and messages that use your company's own terms, such as "my EMI mandate bounced", which an outsider may not map to Billing. Instructions describe the categories in the abstract. Examples show where you draw the lines, and the lines are exactly what an instruction struggles to convey.

When examples help most

Examples shine in four situations. Situation · Why an example helps · Typical caseA particular format · Showing the shape is easier than describing it · A table row, a subject-line style, a form of citation A particular tone or voice · Voice is hard to describe and easy to copy · Brand voice, a manager's email style Judgement calls · Examples mark where the boundary is · Classification, priority levels, tagging Unusual tasks · The model has little to go on from the name alone · Converting your internal codes, a house style for notes Examples help less when the task is simple and common, when the answer must be creative and varied, or when you cannot supply a correct example. In those cases a clear instruction is enough, and examples may cause harm by narrowing the output too much.

A worked example: labelling customer messages

Here is the task. A bank's support team receives free-text messages and needs each one tagged with a category. Start zero-shot.

text Classify the customer message into one of: Billing, Fraud, Account, Other. Reply with the category only.

Message: "My EMI mandate bounced and I got a penalty."

A reasonable model might answer "Billing", which is right, or "Account", which is plausible. The instruction does not say how to treat mandate failures. Now make it few-shot, with examples that mark the boundaries.

text Classify the customer message into one of: Billing, Fraud, Account, Other. Reply with the category only.

Message: "I was charged twice for the same purchase." Category: Billing

Message: "There is a transaction on my card that I did not make." Category: Fraud

Message: "I forgot my password and the OTP is not coming." Category: Account

Message: "My EMI mandate failed and I was charged a penalty." Category: Billing

Message: "What are your branch timings on Saturday?" Category: Other

Message: "My EMI mandate bounced and I got a penalty." Category:

Two features are worth noticing. The examples all have the same layout, so the model sees the pattern: the word "Message", then the text, then "Category". And the final line stops exactly where the answer should begin, so the natural continuation is a category. Examples do not need to be long, but they do need to be consistent.

What changes as you add examples

Add examples, and accuracy usually improves quickly and then levels off. Suppose you test the prompt on twenty messages for which you know the right label. A pattern you might plausibly see, and one worth keeping in mind as a shape, is the following. With no examples, 13 of 20 are right. With one example, 15. With three well-chosen examples that cover the borderline cases, 18. With eight examples, still 18, because the extra five repeat what the first three taught.

The lesson in the chart is the flat top. More examples are not always better. Beyond the point where you have covered the main categories and the tricky boundaries, extra examples add cost and clutter without adding information. The second lesson is more subtle: a test of twenty messages is too small to trust. If the true accuracy is 90 per cent, a test of 20 messages has a margin of error of about 13 points, because the margin for a proportion is 1.96 × √(0.9 × 0.1 ÷ 20) = 0.131. A result of 90 per cent on 20 messages is consistent with a true accuracy anywhere from about 77 to 100 per cent. To compare 75 and 90 per cent reliably you need a few hundred test messages. This is the same sampling arithmetic from the data course, and it is the reason serious prompt work uses a test set, a habit Module 5 develops.

Choosing good examples

An example teaches by what it contains, so careless examples teach careless lessons. A handful of rules covers most of the quality.

Cover the categories and the edges. Include at least one example for each outcome, and spend extra examples on the borderline cases where you expect confusion, not on easy ones. Make them correct. A wrong label in an example is worse than no example, because the model will follow it. Check every answer. Keep the layout identical. Same labels, same order, same punctuation. Differences in format are copied or confuse. Make them representative. Use real messages, with their typos and abbreviations, if that is what the model will see. Vary the surface features. If every example for "Fraud" mentions a card, the model may learn that "card" means fraud. Include a fraud example that mentions UPI or net banking. Balance the labels. If seven of eight examples are Billing, the model leans towards Billing. Mix them, or reflect the true mix deliberately. Mind the order. Models often give extra weight to the last example. Do not end on an odd one, and try shuffling the order to see whether results change. Weak example set · Better example setFive easy Billing messages and one Fraud · Two or three per category, including borderline cases All examples about cards · A mix of card, UPI, net banking and mandate cases Examples in different layouts · One identical layout throughout An example whose label you are unsure of · Only examples whose labels you have checked Every example is the same length · A mix of short and long messages ### Examples can be copied too literally

Because the model continues the pattern, it can copy the surface of an example, such as its length, its opening phrase or its exact words, instead of its underlying idea. If you ask for a product description and give one example that begins "Imagine a world where...", you will get a lot of descriptions that begin the same way. Two defences work. Give two or three examples that differ in structure, so the common thread is the quality and not the wording. And say what to take from them: "These examples show the tone and length I want. Do not reuse their phrases or structure."

Examples for tone, format and judgement

Few-shot is not only for labels. To fix a voice, paste two short pieces you like and say "match the tone of these". To fix a format, show one complete row of a table and say "produce the rest in exactly this format". To teach a judgement call, such as how urgent a ticket is, show several tickets with their priorities and a one-line reason for each. The reason often matters as much as the label, because it tells the model how you think.

text Ticket: "The payments page shows an error for all users." Priority: High Reason: Affects every customer and blocks payments.

Ticket: "The logo on the invoice looks slightly blurry." Priority: Low Reason: Cosmetic and does not stop anyone from using the product.

Positive and negative examples

You can also show what not to do, as long as you label it clearly. "Bad reply: 'We value your feedback. Your call is important to us.' Good reply: 'I'm sorry your payment failed. I've asked the team to check it and will update you by 5 pm today.'" Contrasting a weak and a strong version is a very efficient way to show a quality bar. The risk is that the model copies the bad example, so mark it unmistakably as a thing to avoid, and always show the good one beside it.

Are examples worth the cost?

Every example adds tokens, and tokens cost money and time when you send many requests. For personal use, ignore this. For a team making tens of thousands of calls a month, weigh the cost of the extra tokens against the value of the errors it prevents. Take 50,000 messages a month. Three examples of about 120 tokens each add 360 tokens per request, which is 18 million tokens a month. At an example price of ₹200 per million tokens that is ₹3,600. If those examples lift accuracy from 75 to 90 per cent, they prevent 7,500 errors, and if each error costs ₹20 of someone's time to fix, they save ₹1,50,000. The examples are very worth it here. If instead they lifted accuracy by one point, the saving would be ₹10,000 and the cost still ₹3,600, a much closer call.

Keeping an example bank

Good examples are valuable and take effort to build, so treat them as an asset, not as something you rewrite for each prompt. Keep a simple example bank: a document or spreadsheet with one row per example, containing the input, the correct output, the category it covers and a note on why it was chosen. A bank of thirty or forty examples is plenty for most tasks. Each time the assistant gets a case wrong, add it to the bank with the correct answer, and consider promoting it into the prompt if it exposes a gap. This is one of the most dependable ways to improve a prompt, because every mistake becomes a lesson that stays.

The bank also separates two jobs that beginners mix up. The examples in the prompt teach the model. The test set measures it. They must never overlap. If you test on the same messages you used as examples, the score looks wonderful, because the model has seen the answers, and it tells you nothing about new messages. Keep a separate group of cases that you never show in the prompt, and use only those to compare versions.

Why a sentence of reasoning can help

For judgement calls, an example with a short reason teaches more than a bare label. Compare two ways of showing the same case.

text Message: "I got a call asking for my OTP." Category: Fraud

text Message: "I got a call asking for my OTP." Category: Fraud Reason: Someone is trying to obtain a one-time password, which is a common sign of fraud, even though no money has been taken yet.

The second tells the model how to treat similar messages that do not match the exact wording: a request for a password, a suspicious link, a message claiming to be from the bank. The reason generalises the example. It also gives you something to check: if the model's labels contradict your stated reasons, you can see where its logic went wrong, and you can edit the reason, not guess at what happened. Keep reasons short, since each one costs tokens, and write them in the same plain style throughout.

Examples for the builder: choosing them on the fly

If you build a tool that handles many kinds of requests, a fixed set of examples may not suit every input. A support message about cards may be best served by card examples, and one about loans by loan examples. Builders therefore sometimes select the examples for each request from a larger bank, picking the ones most similar to the new input. This keeps the prompt short and the examples relevant, and it is a standard pattern in applications built on models. You do not need to build it to benefit from the idea: when you work by hand, choose the three examples from your bank that look most like the case in front of you. The retrieval techniques behind automatic selection are covered in the AI Engineering track.

Common mistakes

Adding examples to a task that did not need them. A clear instruction often suffices, and examples can narrow the output too much. Examples that disagree with your instruction. If the text says "reply in one word" and an example uses a sentence, the model follows the example. Wrong or doubtful labels. The model repeats what it is shown. Examples that all look alike. The model learns the surface and misses the idea. Vary them. Unbalanced labels. Too many of one kind pulls the answers towards it. Judging a prompt on a handful of tests. Twenty cases cannot separate prompts. Use more. Forgetting that examples are not permanent. In a new chat they are gone, so keep them in a saved template.

Key takeaways

Zero-shot means instructions only, one-shot adds one example and few-shot adds several. Examples are read as part of the prompt and are not learned permanently. Examples help most for formats, tone, judgement calls and unusual tasks, where describing the target is harder than showing it. Choose examples that cover every outcome and the borderline cases, are correct, share one layout and vary in surface features. Accuracy usually rises quickly with the first few examples and then flattens, so more is not always better. A small test cannot tell prompts apart. With 20 messages at 90 per cent, the true accuracy could be anywhere from about 77 to 100 per cent. Weigh extra tokens against the errors they prevent, and tell the model what to take from an example so it does not copy the wording.

Check yourself

1. What is the difference between one-shot and few-shot? One-shot includes one worked example, few-shot includes several, usually two to ten. 2. Why include borderline cases in your examples? Easy cases are handled without help. Borderline cases show where you draw the line, which is what the model cannot guess. 3. Why might a model copy the opening phrase of your only example? It continues the pattern in the prompt and may copy surface features. Give varied examples and say not to reuse their phrases. 4. A test of 50 messages shows 80 per cent accuracy. What is the approximate margin of error? 1.96 × √(0.8 × 0.2 ÷ 50) = 0.111, about 11 points. 5. Examples add 300 tokens to 20,000 requests a month at 200 per million tokens. What is the extra cost? 6 million tokens × 200 per million = 1,200 a month.

Try this

You need an assistant and about forty-five minutes.

1. Choose a sorting task from your work, such as tagging emails, rating priority or labelling feedback. Collect 30 real examples and label them yourself, carefully. Set aside 20 as a test set, and keep 10 for examples. 2. Run the zero-shot prompt on the 20 test cases and record how many are right. 3. Choose one example from your 10, covering a category, and rerun. Then choose three examples that cover the categories and at least one borderline case, and rerun. Record each score. 4. Shuffle the order of your three examples and rerun. Note whether the score changes. 5. Use the trust simulator to find the margin of error for your results, and say whether the differences between prompts are bigger than the noise. 6. Use the cost simulator with your own volume to estimate whether the examples pay for themselves. 7. Fill in this table. Prompt · Correct out of 20 · Margin of error · NotesZero-shot · · · One example · · · Three examples · · · Three, shuffled · · · A good result is a table that shows how accuracy moved as examples were added, an honest note on whether the differences exceed the noise, and a saved few-shot template for the task. In the next lesson we turn from examples to the other main ingredient you supply: context and reference material.

Tags: Prompt Engineering Few-shot prompting Examples Classification Beginner