Module 03 · Few-Shot and Example-Driven Prompting
Zero-Shot vs. Few-Shot: When Examples Actually Help
Open lesson + course map
On this lesson
Course outline
Module 1 · Structural Prompt Frameworks
Module 2 · Reasoning Patterns
Module 3 · Few-Shot and Example-Driven Prompting
Module 4 · Reusable Instruction Systems
Zero-shot prompting gives a model instructions but no demonstrations. Few-shot prompting adds a small set of input-output examples so the model can infer the pattern you want. Examples are especially useful when a format, label boundary, or writing style is easier to show than describe.
Examples do not supply missing business knowledge, verify facts, or guarantee a better answer. By the end of this lesson, you will have tested one WhatsApp-message classification task zero-shot and two-shot, scored both versions with the same rubric, and written a comparison note.
// concept
What Changes When You Add Examples
A zero-shot prompt asks the model to apply written rules directly. Start there when the task is familiar, labels are clear, and the output is easy to specify. It also leaves more context space for the real input.
A few-shot prompt contains the same instructions plus demonstrations. One example is one shot; two examples are two-shot. Examples can anchor:
- Format: exact field order, JSON shape, table columns, or answer length.
- Style: concise support language, formal client email, or controlled Roman Urdu.
- Decision boundaries: what counts as
RETURNrather thanPRODUCT_QUERY. - Edge handling: how to label an ambiguous or out-of-scope input.
They cannot repair missing information. If a message says “mera order?” without an order ID, demonstrations cannot reveal it. Examples also consume tokens and create anchoring bias when the model copies a name, product, or assumption into a new case.
| Situation | Start with | Reason |
|---|---|---|
| Clear summary or extraction | Zero-shot | Instructions define success |
| Model keeps renaming fixed labels | Few-shot | Demonstrations anchor labels |
| Hard-to-describe brand voice | Few-shot | Examples show the style |
| Recent facts or company policy | Neither alone | Supply an authorized source |
| Little context space remains | Zero-shot | Preserve source material |
| Only one narrow example exists | Zero-shot first | It may bias the result |
// concept
Run a Fair A/B Test
Version B should be Version A plus examples—nothing else. Use the same model, input, source, and settings in fresh chats. Because outputs vary, repeat both versions on the same small test set before regular use.
BAD prompt
Sort this WhatsApp message and tell me what to do:
"Parcel kal chahiye tha, tracking 2 din se same hai. COD hai. Please check."“Sort” has no allowed labels, urgency rule, or output format.
GOOD test contract used in both versions
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Label | Invented/wrong | Plausible but not exact | Exactly one allowed label |
| Urgency | Unsupported | Plausible but inconsistent | Applies the stated rule |
| Format | Fields missing | All fields, wrong order | Exact four-line schema |
| Fidelity | Adds customer/order facts | Marks some gaps | Adds no facts; names missing data |
The maximum is 8. Copied example content is an automatic fidelity failure.
// concept
Add Examples When… Skip Them When…
Add examples when: the model changes field order; label boundaries remain ambiguous; a style is difficult to describe; or an edge case needs demonstration.
Skip examples when: zero-shot already passes; examples would crowd out sources; your example is unrepresentative; the task needs current knowledge; or client data cannot be reused safely.
Keep examples short and complete. Vary surface details so they do not look like rules; demonstrations should teach the invariant pattern.
// worked_example
Worked Example
This hypothetical support workflow uses constructed samples, not real customer records or claims about a model.
The labels are ORDER_STATUS, PRODUCT_QUERY, RETURN_EXCHANGE, and OTHER. The prompts define when urgency becomes HIGH.
Version A: zero-shot
Classify one customer WhatsApp message for a human support queue.
Allowed labels: ORDER_STATUS, PRODUCT_QUERY, RETURN_EXCHANGE, OTHER.
Urgency rule: HIGH only if the message explicitly states a missed delivery date,
an unusable delivered item, or a payment charged without confirmation. Otherwise NORMAL.
Return exactly four lines in this order:
LABEL: <allowed label>
URGENCY: <HIGH or NORMAL>
KNOWN: <facts stated in the message; "none" if absent>
MISSING: <information needed for the next action; "none" if absent>
Do not draft a reply. Do not infer an order number, date, location, or customer name.
MESSAGE:
Parcel kal chahiye tha, tracking 2 din se same hai. COD hai. Please check.Constructed sample output A
LABEL: ORDER_STATUS
URGENCY: HIGH
KNOWN: Expected delivery was yesterday; tracking has not changed for two days; payment is COD.
MISSING: Order number or tracking ID.This constructed output scores 8/8. If repeated tests pass, examples add no measured value.
Version B: the same prompt plus two shots
Classify one customer WhatsApp message for a human support queue.
Allowed labels: ORDER_STATUS, PRODUCT_QUERY, RETURN_EXCHANGE, OTHER.
Urgency rule: HIGH only if the message explicitly states a missed delivery date,
an unusable delivered item, or a payment charged without confirmation. Otherwise NORMAL.
Return exactly four lines in this order:
LABEL: <allowed label>
URGENCY: <HIGH or NORMAL>
KNOWN: <facts stated in the message; "none" if absent>
MISSING: <information needed for the next action; "none" if absent>
Do not draft a reply. Do not infer an order number, date, location, or customer name.
EXAMPLE 1 INPUT:
Blue kurta medium aya hai, mujhe large exchange karna hai. Tags lage hue hain.
EXAMPLE 1 OUTPUT:
LABEL: RETURN_EXCHANGE
URGENCY: NORMAL
KNOWN: Blue kurta in medium received; large requested; tags remain attached.
MISSING: Order number and exchange eligibility under the seller's policy.
EXAMPLE 2 INPUT:
Is bag ka black colour available hai aur laptop 15 inch fit hoga?
EXAMPLE 2 OUTPUT:
LABEL: PRODUCT_QUERY
URGENCY: NORMAL
KNOWN: Customer asks about black availability and 15-inch laptop fit.
MISSING: Product identifier.
MESSAGE:
Parcel kal chahiye tha, tracking 2 din se same hai. COD hai. Please check.Constructed sample output B
LABEL: ORDER_STATUS
URGENCY: HIGH
KNOWN: Expected delivery was yesterday; tracking has not changed for two days; payment is COD.
MISSING: Order number or tracking ID.Version B also scores 8/8. Comparison note: “Examples did not improve this case. Keep Version A unless wider tests reveal format or boundary failures.”
Suppose both demonstrations used “Ayesha” and a Lahore branch. Outputting KNOWN: Ayesha is waiting for Lahore delivery when neither fact appears in the target is content anchoring.
Fix it by removing irrelevant names, varying surface content, and retaining only the label boundary and output pattern. Re-run the same target; copied details earn 0 for fidelity.
// failure_cases
Failure Cases to Diagnose
6 cases to diagnose
Version B has better instructions as well as examples.
Restore the same instruction block; examples must be the only variable.
The model copies “Lahore,” a name, or a product.
Diversify the shots and score copied content as a fidelity failure.
Two examples contradict the label rules.
Correct or delete them. Demonstrations can overpower prose, so every example output must satisfy the rubric.
Zero-shot is judged on one easy case.
Add boundary, mixed Urdu/English, and missing-information cases.
Few-shot fixes format but invents facts.
Track format and fidelity separately; fabricated content still fails.
Examples contain real phone numbers, addresses, or order IDs.
Replace them with clearly synthetic placeholders before sending them to any AI service.
// pakistan_angle
Pakistan Angle
Pakistani WhatsApp commerce mixes English, Urdu, and Roman Urdu with terms such as COD, rider, parcel, and exchange. Test mixed-language spellings without treating Urdu as lower quality or urgency. Daraz sellers and independent shops may have different policies, so supply the seller’s authorized policy when a decision depends on it.
Messages can contain phone numbers, addresses, CNIC images, JazzCash/easypaisa references, or order IDs. Replace them with [PHONE] and [ORDER_ID]. During load-shedding, save prompts and the scorecard offline, then run text-only tests when connected. Free-tier limits and data controls change; check official vendor pages before using client material.
// hands_on
Hands-On Exercise
6 steps
Build the artifact: one task tested zero-shot versus two-shot, plus a comparison note.
Choose a low-risk recurring task with a checkable output.
Write four scoring criteria with 0–2 point descriptions. Include a criterion that catches invented or copied content.
Create Version A with clear instructions, allowed outputs, and one sample input.
Duplicate it as Version B and add exactly two short input-output demonstrations. Change nothing else.
Run both in fresh chats with the same model and input. Save and score the raw outputs.
Check Version B for copied details. Note the score difference, defect difference, and version to keep.
// completion_rubric
Completion Rubric
5 checks — tick as you verify
// sources
Sources
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: “Version B has better instructions as well as examples.” What does the lesson tell you to do about it?