Loading lesson…
Prompt Engineering / Core Techniques
Instructions alone versus learning from examples.
Reviewed by Yuvaraj
Every prompt sits somewhere on a spectrum defined by how many worked examples you hand the model before asking it to perform. At one end is zero-shot prompting: you give an instruction and nothing else, trusting the model to already know the task from pretraining. At the other end is few-shot prompting: you include a small set of input-to-output demonstrations directly in the prompt, letting the model infer the pattern before it answers. Choosing where to sit on that spectrum is one of the highest-leverage decisions a prompt author makes, because it trades tokens and latency for reliability.
Zero-shot means instruction only. Few-shot means instruction plus a handful of demonstrations, usually two to eight (one demonstration is called one-shot). Nothing about the model changes between these modes. You are not teaching it a new skill; you are showing it, in the moment, exactly what a correct answer looks like so it can imitate the pattern.
Few-shot tends to help in three situations: when you need a strict, machine-parseable output format; when the task is ambiguous and the instruction alone leaves room for interpretation; and when the desired output has an unusual shape the model would not default to. The cost is real: every example is re-sent on every call, inflating token usage and latency, and poorly chosen examples can bias the output toward whatever they happen to share.
The mechanism behind few-shot is in-context learning. The demonstrations become part of the input sequence, so when the model predicts the next token it is conditioning on your instruction and on the examples it just read. The examples reshape the probability distribution over what comes next, steering it toward the format and label set you showed. Critically, no gradient step is taken and no weight is updated. The influence lasts only for this one request; the next call with an empty context behaves as if the examples never existed.
Take one concrete task: classify a product review as positive, negative, or . Here is a zero-shot prompt.
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
neutralClassify the sentiment of the product review below as
positive, negative, or neutral. Reply with one word only.
Review: "The battery lasts all day and it charges fast."
Sentiment:
Here is a two-shot version with two labeled demonstrations.
Classify the sentiment of each product review as
positive, negative, or neutral. Reply with one word only.
Review: "The screen cracked after a week. Total waste of money."
Sentiment: negative
Review: "It arrived on time and works exactly as described."
Sentiment: positive
Review: "The battery lasts all day and it charges fast."
Sentiment:
The few-shot version yields more consistent, parseable output for two reasons. First, the demonstrations pin the exact label vocabulary and casing (negative, not "Negative sentiment" or "The review is negative"), so a downstream parser can rely on a fixed set of one-word answers. Second, they resolve ambiguity: the examples show that a factual, on-time delivery counts as positive, nudging borderline reviews away from a lazy neutral. The zero-shot prompt can still work, but its output format is more likely to drift on edge cases.
Which examples you pick matters as much as how many. Good demonstrations are representative of real inputs, diverse across the cases you expect, and above all correctly labeled.
| Principle | What it means | Failure if ignored |
|---|---|---|
| Representative | Examples resemble true production inputs | Model overfits to a toy distribution |
| Diverse | Cover distinct cases, not near-duplicates | Narrow coverage, brittle on variety |
| Correctly labeled | Every demonstration answer is right | Wrong labels propagate into outputs |
| Label-balanced | Classes appear in roughly equal number | Predictions skew toward the frequent label |
| Ordering-aware | Vary or balance example order | Recency and majority-label bias creep in |
Ordering has a measurable effect: models are sensitive to which example comes last and to whether one label dominates the sequence. When outputs seem skewed, shuffle the order and balance the label counts before adding more examples.
For a curious beginner
The model copies the pattern it just saw. Show it two reviews with their sentiment labels, and it continues the pattern for the third, the way you would finish a worksheet after seeing a couple of solved rows.
How it is actually used
The examples go into the context window as ordinary tokens. They condition the next-token distribution for this single request, steering format and labels. No training happens, and the effect vanishes on the next call with a fresh context.
The underlying mechanism
Few-shot conditions the output on the demonstrations: the model estimates rather than . The parameters are fixed throughout; only the conditioning context changes.
Common mistakes