Zero-shot vs few-shot prompting and in-context learning

The three names describe one axis: how many worked examples of the target task appear inside the prompt.

The terminology comes from the GPT-3 paper, Language Models are Few-Shot Learners (Brown et al., 2020), which named the regime and demonstrated that a sufficiently large decoder-only model could perform many tasks from in-prompt examples alone, with no gradient updates. That framing — "few-shot" means examples in the prompt, not a small training run — is the definition the NCA-GENL blueprint assumes, and it is the definition the exam will test.

A worked concrete instance makes the shapes unmistakable. Zero-shot:

Classify the sentiment of the review as positive, negative, or mixed.

Review: The battery lasts forever but the screen is unusable outdoors.
Sentiment:

One-shot:

Classify the sentiment of the review as positive, negative, or mixed.

Review: Shipping took three weeks and the box was crushed.
Sentiment: negative

Review: The battery lasts forever but the screen is unusable outdoors.
Sentiment:

Few-shot, with the label set exercised and the awkward case demonstrated:

Classify the sentiment of the review as positive, negative, or mixed.

Review: Shipping took three weeks and the box was crushed.
Sentiment: negative

Review: Setup took four minutes and it has not crashed once.
Sentiment: positive

Review: Beautiful build quality, but the software is a disaster.
Sentiment: mixed

Review: The battery lasts forever but the screen is unusable outdoors.
Sentiment:

The third prompt does three jobs the first cannot. It fixes the output vocabulary to exactly three lowercase strings. It fixes the output shape to a bare label with no preamble, no explanation, and no trailing period. And it demonstrates the decision boundary you care about — that "good hardware, bad software" is mixed and not negative — which is a judgement call your instruction never made explicit and probably could not have made explicit in fewer words than the example took.

That is the real function of few-shot prompting. It is not that the model does not understand sentiment. It is that your sentiment task has edges, and examples are a cheaper way to draw an edge than prose is.

L1 — Intuition: the examples are context, not curriculum

Picture the model as a fixed function that reads a sequence of tokens and produces a probability distribution over the next token. You cannot alter the function at inference time. The only lever you have is the sequence you hand it. A few-shot prompt uses that lever to make the continuation you want overwhelmingly the most probable one.

By the time the model reaches the final Sentiment: in the few-shot prompt above, it has just read three instances of the exact pattern Review: <text>\nSentiment: <one lowercase word>. Continuing that pattern is now the highest-probability behaviour available — far more probable than "Sure! Let me analyse this review for you." The examples did not teach sentiment. They made a format and a decision boundary into the locally obvious continuation.

L2 — Mechanism: attention over the prompt is the entire implementation

There is no separate machinery for in-context learning. It is a consequence of self-attention operating over a sequence that happens to contain demonstrations.

Concretely, per 04-01 and 04-04:

1. Your whole prompt — instruction, every example, the final input — is tokenised into one sequence.
2. That sequence goes through the transformer stack in the prefill pass. Every token attends to every earlier token, so the representation built at the final position has read your examples.
3. The model emits a distribution over the next token. The sampler in 04-05 picks from it.
4. Each generated token is appended and the process repeats, still attending to your examples.

Nothing in that loop writes to a weight. The examples influence the output through activations — the transient per-request state — and activations are discarded when the request finishes. This is why the following two statements are both true and are not in tension: few-shot prompting reliably improves task accuracy, and few-shot prompting is not training.

It is also why the cost model is what it is. Examples are tokens. Tokens occupy the context window (04-06), are billed at the input rate (12-09), and lengthen prefill, which is the dominant term in time-to-first-token (12-10). A 12-example prompt is not "a better prompt" for free. It is a prompt that costs roughly 12 example-lengths more on every single request, forever, which is the trade that makes fine-tuning eventually cheaper at high volume (11-08).

L3 — What is actually happening, stated with appropriate uncertainty

Why a frozen network can adapt its behaviour from in-prompt examples is an open research question, not a settled mechanism. Published work proposes several accounts — that attention over demonstrations implements something functionally analogous to a gradient step on a small implicit model, that the demonstrations mainly locate a task the model already learned during pretraining rather than teaching anything new, and that the format and label space carry more of the benefit than the correctness of the individual examples. These are competing explanations with supporting evidence, not a consensus, and the NCA-GENL exam is calibrated at general level [FIELD] — it will not ask you to adjudicate between them.

What you should carry into the exam room is the operational summary, which is well supported and not controversial:

• In-context learning requires no weight update and produces no artifact.
• Its effect is bounded by the context window and paid for on every request.
• It is strongest at fixing format, label space, and tone, and weakest at installing knowledge the model does not have.
• It is sensitive to surface details — example order, label distribution, and the exact delimiter and label strings — in ways a real training run is not.

That last property is the practical tell that you are not training. A model trained on 500 examples does not care which order the examples were in. A few-shot prompt does. Published work on few-shot calibration reports systematic biases in exactly this area — a tendency to be pulled toward labels that appeared most often in the demonstrations, toward the label of the most recent demonstration, and toward tokens that are common in general text. Treat the direction of these findings as reliable and any specific magnitude as model-dependent; do not memorise a number.

This is the highest-value table in the lesson, because the exam's favourite distractor family in this area is "which of these changes the model's weights?"

Two readings of that table matter for the exam.

First, the customization ladder runs prompt → RAG → prompt learning → PEFT/LoRA → full fine-tune → alignment, in increasing order of cost, data requirement, and commitment. Rungs one and two change nothing about the model. Rung three trains something new while leaving the base model frozen. Rungs four through six produce weights. If a question asks for the cheapest intervention that could fix a described problem, the keyed answer is almost always the lowest rung that can actually address it — and prompting is the lowest rung.

Second, note where prompt tuning sits, because "prompt" appears in its name and it is not prompting. Prompt tuning and p-tuning learn continuous vectors by gradient descent against a dataset. They are a training method with a saved artifact. Few-shot prompting is a string you paste. Any answer option that describes "few-shot prompting" as producing a reusable trained artifact is wrong, and any option that describes "prompt tuning" as requiring no training data is also wrong. 11-08 and 11-09 take the full ladder apart under real constraints.

Here is the loop as it actually runs. The scenario, the tickets, and the outputs below are a constructed illustrative example built to show the failure modes in order — they are not measured results from a benchmark run.

Task. Route inbound support tickets to one of four queues: billing, bug, how-to, account-security. Output must be exactly the queue name, because a downstream service does a dictionary lookup on it.

Attempt 1 — zero-shot, loosely worded.

What kind of ticket is this?

"I was charged twice for March and the second charge is still pending."

A plausible output:

This appears to be a billing-related issue. The customer is reporting a
duplicate charge, which typically falls under billing disputes...

Correct in substance, useless in practice. The downstream lookup fails on the whole paragraph. The defect is not the model's reasoning; it is that the prompt never stated the output contract.

Attempt 2 — zero-shot with an explicit label space and format rule.

Route the support ticket to exactly one queue.
Allowed queues: billing, bug, how-to, account-security
Reply with the queue name only. No punctuation, no explanation.

Ticket: "I was charged twice for March and the second charge is still pending."
Queue:

Output: billing. This is the first lesson of prompt engineering restated: most "the model can't do this" problems are actually "I never said what I wanted" problems, and a tightened zero-shot prompt fixes a surprising share of them at zero extra token cost. Do not skip this step. Reaching for examples before you have written a precise instruction is how prompts become bloated for no measured gain.

Attempt 3 — where zero-shot genuinely fails. Now a harder ticket:

Ticket: "Someone else's name is showing on my invoice."
Queue:

Output: billing. Defensible — the word "invoice" is right there. But your organisation has decided this is account-security, because a wrong name on an invoice usually means a merged or hijacked account, and the security queue triages that first. No amount of instruction rewording reliably transmits that policy, because the policy is not derivable from the words; it is a business convention.

Attempt 4 — few-shot, with the examples chosen to carry the policy.

Route the support ticket to exactly one queue.
Allowed queues: billing, bug, how-to, account-security
Reply with the queue name only.

Ticket: "I was charged twice for March."
Queue: billing

Ticket: "The export button does nothing on Firefox."
Queue: bug

Ticket: "Where do I change my team's timezone?"
Queue: how-to

Ticket: "My invoice shows a company I have never worked for."
Queue: account-security

Ticket: "Someone else's name is showing on my invoice."
Queue:

Output: account-security.

The fourth demonstration is the entire point. It is not there to teach classification; it is there to encode one policy decision that prose could not encode cheaply. Notice what a good example set does:

• Covers the full label space. All four queues appear, so no label is starved. An unrepresented label is systematically under-predicted.
• Spends its examples on the boundaries, not the easy middle. A demonstration of an obvious bug ticket teaches almost nothing. The invoice/security demonstration teaches the one thing you needed.
• Is formatted identically to the real input, right down to the Ticket: / Queue: labels, the quoting, and the blank lines. Any drift between the demonstration format and the live format weakens the pattern you are trying to establish.
• Is balanced. Four labels, one example each. Stacking three billing examples and one of everything else biases the model toward billing, and that bias is a documented behaviour of few-shot prompting rather than a quirk of one model.

Attempt 5 — the version you actually ship. Add the escape hatch, because the label space is a closed set and reality is not:

Route the support ticket to exactly one queue.
Allowed queues: billing, bug, how-to, account-security
If the ticket fits none of these, reply: unknown
Reply with the queue name only.

Without unknown, a closed label set forces a wrong answer on out-of-scope input — the model will pick the least-bad queue rather than decline, because declining was never an available continuation. A named escape label converts a silent misroute into a visible one you can count. This is a general principle, not a classification trick: every constrained output format needs a legal way to say "not applicable."

Finally, the step people skip: this whole sequence — five prompt variants and their outputs — is worth nothing unless you ran all five against the same fixed set of tickets and compared scores. You built exactly that instrument in 01-08. Prompt engineering without a frozen eval set is not engineering; it is anecdote collection, and it is how teams end up with a 900-token prompt where no one can say which clause is load-bearing. 05-04 turns this into a repeatable process.

Examples are not free and they are not always better. Use this to decide before you paste.

The recurring pattern: few-shot is the tool for form, not for facts. Format, label space, tone, and boundary policy are what demonstrations transmit. Missing knowledge, staleness, and provenance are retrieval problems. Sustained high-volume behaviour change with a token-cost floor is a fine-tuning problem. Getting those three assignments right is most of what 05-06 and 11-08 are testing.

One more calibration: there is a diminishing-returns curve on example count. The move from zero to one, and one to three, is typically where most of the benefit lands; adding a twentieth example rarely earns its tokens on a simple task. Treat that shape as a well-supported direction of effect and the exact turning point as something you measure on your own eval set, not something you memorise.

Objective 1.9 — "Use prompt engineering principles to create prompts to achieve desired results" names prompt engineering as an examined skill outright, and this lesson's contrast is the first item on the must-know list for it: zero-/one-/few-shot. Objective 1.3 (build LLM use cases such as RAG, chatbots, summarizers) reaches it from the other direction, since choosing between examples and retrieval is a use-case design decision. Objective 1.1 and the customization-ladder material touch it again, because "which technique changes the weights" is a scalability and cost question.

Prompt engineering also sits in the Tier 1 (highest-frequency) band in this course's calibration [FIELD], alongside transformer architecture, tokenization, NVIDIA NIM, and text-generation parameters. Combine that with the reported finding that questions are pitched at general level rather than deep-technical [FIELD], and the shape of what to prepare is clear: crisp identity statements and confident when-to-use rules, not research-level mechanism.

Question phrasings that recur in this territory:

• "A team adds three solved examples to a prompt. What is this called, and does it modify the model?" — few-shot / in-context learning, and no.
• "Which technique adapts model behaviour without updating weights?" — prompting and RAG. Distractors will offer LoRA, full fine-tuning, or RLHF.
• "A prompt returns correct content in the wrong format. Cheapest fix?" — tighten the instruction and add one or two format demonstrations. Distractors propose fine-tuning or a bigger model.
• "The model does not know your internal product names at all. Best fix?" — retrieval or fine-tuning, not few-shot examples. This is the most valuable discrimination in the lesson.
• "One-shot prompting means…" — exactly one example in the prompt. Distractors define it as one training epoch, one turn of conversation, or one output token.

Distractor families worth naming, since recognising the family is faster than reasoning from scratch:

No. Nothing about the model changes. The examples are tokens in the input sequence; they influence the output through attention and activations, both of which are per-request state that is discarded when the response completes. There is no gradient computed, no optimiser step taken, and no artifact produced that you could save, version, or ship. Issue the same request with the examples removed and you get the untouched base behaviour back immediately — which is itself the cleanest demonstration that no learning was persisted.

The confusion is understandable and worth naming precisely, because the exam exploits it. "Learning" in "in-context learning" describes the appearance of the behaviour from the outside — the model gets better at your task after seeing examples — not the mechanism producing it. Fine-tuning changes the function. In-context learning changes the input to a fixed function.

Start at zero, and only add examples that a measurement says earned their place. As a practical starting range, one to five examples covers most classification and formatting tasks; going beyond about eight tends to buy little unless the label space is large or the boundaries are genuinely numerous.

Three constraints set the real ceiling. First, budget: examples share the context window with system instructions, conversation history, and retrieved passages, and the window is a fixed ceiling (04-06). Second, latency and cost: examples lengthen prefill on every request, so a long prompt is a permanent tax on TTFT and per-token spend (12-09, 12-10). Third, diminishing returns: the curve flattens, and past the flattening point you are paying tokens for noise.

What matters more than count is which examples. Balanced across labels, drawn from real decision boundaries, formatted exactly like the live input, and free of errors — four well-chosen examples routinely beat twelve arbitrary ones.

Not durably, and not in the way you want. An example can carry a fact incidentally — if a demonstration mentions that your enterprise tier is called "Summit," the model can use that string within the same request. But that is not knowledge acquisition; it is the model reading a fact off the page in front of it. It ends with the request, it does not generalise to related facts you did not paste, and it does not scale: you cannot fit a knowledge base into a demonstration block.

When the gap is missing, changing, or proprietary knowledge, the correct tool is retrieval (07-09), which fetches the relevant facts per query and can cite them. When the gap is a durable behaviour, format, or style change at high volume, the tool is fine-tuning (11-02). The reliable one-line rule: examples for form, retrieval for facts, fine-tuning for sustained behaviour. 05-06 gives you a first decision rule built on exactly this split, and states its own error bars.

1. Zero-shot = instructions only. One-shot = one example. Few-shot = a handful. All three are in-context learning.
2. In-context learning changes no weights and persists nothing. It conditions a frozen model through the context window, per request.
3. Tighten the instruction before adding examples. A large share of apparent capability failures are unstated-requirement failures, and fixing those costs no tokens.
4. Examples transmit form: format, label space, tone, boundary policy. They do not install knowledge.
5. Examples are paid on every request — context budget, input tokens, prefill latency. That recurring cost is what eventually makes fine-tuning cheaper at volume.
6. Composition beats count. Balance labels, target boundaries, mirror the live format exactly, and give a closed label set an escape hatch.
7. Know the ladder cold. Prompting and RAG change nothing; prompt tuning trains a small frozen-base artifact; LoRA/PEFT, full fine-tuning, and alignment produce weights.
8. Measure or you are guessing. Every variant in this lesson only counts as an improvement if the frozen eval set from 01-08 says so.

You now know how many examples to include and what they can and cannot do. What you do not yet have is a reliable layout for everything around the examples — where the instruction goes, how to fence off untrusted context so the model does not read data as commands, whether the role belongs in a system prompt, and how to state an output contract that survives contact with real input. Next: 05-02 gives you the instruction / context / format skeleton, the delimiter discipline that makes it robust, and the ordering rules that decide whether your careful examples are even read.