In-Context Learning: Zero-Shot, One-Shot, and Few-Shot Prompting

In-context learning (ICL) is the adaptation of a model's output to a task by conditioning it on information placed inside the prompt, with the model's parameters completely unchanged before, during, and after the request. [GROUND TRUTH] (Sources/ncp-genl/domain-2-prompt-engineering.md): "In-context learning conditions the model on examples placed inside the prompt — no gradient updates occur."

That sentence is the entire mechanism, and the professional-level trap sits directly on top of it: the field's own vocabulary, "few-shot learning," borrows the word "learning" from a completely different process, supervised training, and the borrowed word invites exactly the confusion the exam is built to test.

Three named forms sit on one axis, distinguished only by how many worked examples of the target task travel inside the prompt. [GROUND TRUTH] (Sources/ncp-genl/domain-2-prompt-engineering.md): "Zero-shot: Instruction only — typical use: simple, well-known tasks. One-shot: One worked example — typical use: establishing format/pattern. Few-shot: Several exemplars — typical use: teaching a nuanced pattern from a handful of cases."

Read that framing carefully, because it already tells you what each form is for: zero-shot is a bet on the model's existing pretraining, one-shot is a format demonstration, and few-shot is where a pattern that would take a paragraph of prose to specify gets shown instead of stated.

The professional-level scope note for this domain names the trap directly: expect a question that offers "few-shot learning" as a description of a training process, or that describes examples in a prompt as producing a saved, reusable artifact. Neither is true. ⚠️ UNVERIFIED — no benchmark number in the source material states an exact accuracy delta for adding exemplars on any specific task, and this lesson will not manufacture one; what is well supported is the direction — few-shot generally improves task alignment over zero-shot — not a specific magnitude you should memorize.

L1 — Intuition: the prompt is the only lever you have at inference time

A deployed model is a fixed function. You cannot alter its weights between one request and the next without a training run, and a training run is not what is happening when you paste three examples into a prompt. The only thing you control at inference time is the sequence of tokens you hand the model, and in-context learning is what happens when that sequence includes worked examples of the task you want performed. The model does not update anything about itself in response to seeing those examples — it simply continues the pattern the examples established, because continuing an established pattern is the single most probable next-token behavior available to it once the pattern is visible in context.

L2 — Mechanism: the prefill pass is where the entire technique lives

Everything in-context learning does happens inside the forward pass, specifically during prefill — the single pass the model makes over your whole prompt before it emits its first output token. Every token in your instruction, every worked example, and the real input are tokenized into one sequence and processed together. Because attention in a causal decoder lets every position attend to everything before it, the representation the model builds at the position just before generation begins has "read" every exemplar you supplied. The distribution over the next token is then shaped by that reading. Nothing about this process reaches into the model's stored parameters and adjusts them; the examples influence output purely through transient, per-request activations that vanish the moment the request completes.

That mechanism is also the entire cost model, and this is the piece the associate-level treatment of the same topic does not need to carry as far as a professional-level treatment does. Every exemplar you add is tokens, and tokens processed during prefill are billed, latency-relevant work, on every single request, for as long as that prompt template is in production. There is no amortization. A ten-thousandth request pays for its five examples exactly as fully as the first request did. Contrast this with a trained adapter or a fine-tuned checkpoint, where the "examples" are paid for once, during training, and then cost nothing extra per request — that asymmetry is precisely why the professional decision between in-context learning and fine-tuning, covered fully in M2-05, turns on volume and stability rather than on which produces better output content.

L3 — The exam-relevant edge case: exemplar cost compounds with everything else that shares the context window

A specialized-domain deployment rarely has an empty prompt to fill with exemplars. A retrieved passage from a RAG pipeline, a system instruction, a conversation history, and your few-shot block all compete for the same fixed context window, and every token any of them consumes is a token unavailable to the others. This is where in-context learning stops being a purely qualitative choice ("should I add examples") and becomes a budgeting decision: exemplars you add for a specialized-domain task are exemplars subtracted from retrieved context, from conversation history, or from the ceiling on output length before a hard context limit is hit. A professional-level scenario question that names a context-window constraint alongside a few-shot prompt is testing exactly this competition, not just whether you know what few-shot means.

There is a second, subtler professional-level consequence worth naming precisely: because the few-shot block is identical on every request that uses the same template, a serving stack that supports prefix caching can reuse the already-computed keys and values for that shared block across requests, paying its prefill cost once per cache lifetime rather than once per request — a direct consequence of the causal, append-only structure of attention that also underlies KV caching (M4-04). This does not make few-shot prompting free, and it does not change the underlying claim that no weights are touched; it changes how much of the recurring cost a well-engineered serving layer can actually recover, and it is the kind of detail that separates a production-aware answer from a purely conceptual one.

The row worth memorizing for a professional-tier scenario question is the first one. Any answer option describing zero-shot, one-shot, or few-shot prompting as modifying, training, or updating the model is wrong on its face, regardless of how plausible the surrounding scenario sounds. The distinguishing professional-level skill is not recognizing that fact in isolation — that is associate-level recognition — but applying the recurring-cost row correctly under a volume constraint, which is what section 4's worked example is built to test.

Constructed scenario: every number below is illustrative, built so the arithmetic is checkable, and none of it is a measured benchmark result for any real deployment.

A team is classifying inbound equipment-maintenance tickets into one of six specialized fault categories that are specific to their own machinery and do not correspond to anything the base model would have seen described the same way during pretraining. This is a textbook case for in-context learning over a small, curated set of examples rather than a full fine-tune. [GROUND TRUTH] (Sources/ncp-genl/domain-2-prompt-engineering.md): prompt learning fits "small datasets or specialized domains where fine-tuning is impractical."

Step 1 — establish the token cost of one exemplar. Each worked example is a two-sentence fault description plus a one-word category label, formatted identically to the live input:

Example ticket text:         ~48 tokens
"Category: <label>" line:     ~4 tokens
Per-exemplar cost:            ~52 tokens

Step 2 — price zero-shot, one-shot, and five-shot prompts. Assume a fixed instruction block of 120 tokens naming the six categories and the output format.

Zero-shot prompt:  120 tokens                          = 120 tokens
One-shot prompt:   120 + (1 x 52)                      = 172 tokens
Five-shot prompt:  120 + (5 x 52)                       = 380 tokens

Step 3 — scale to daily volume. The team serves 50,000 of these classification requests per day.

Zero-shot daily input tokens:  120 x 50,000  =  6,000,000 tokens/day
Five-shot daily input tokens:  380 x 50,000  = 19,000,000 tokens/day

Extra tokens from choosing five-shot over zero-shot:
19,000,000 - 6,000,000 = 13,000,000 extra input tokens/day, every day, forever

Step 4 — read the result as an engineer, not an arithmetician. Thirteen million extra tokens a day is not a one-time cost; it recurs on the same schedule as the traffic itself, and it recurs regardless of whether the five-shot prompt is actually earning its keep on this task. This is exactly the number a professional-level decision needs before choosing five-shot over one-shot or zero-shot: the accuracy gain from the extra exemplars has to be worth that recurring 13-million-token daily tax, not just "better" in an informal sense. If a frozen evaluation set shows the fifth exemplar contributes negligible additional accuracy over the third, the correct engineering decision is to drop it — not because five-shot is wrong in principle, but because the marginal exemplar is pure recurring cost with no measured return.

Step 5 — compare against the alternative the domain's own framing points to. Because this is a small, specialized-domain task — six categories specific to one company's machinery, unlikely to be well represented in general pretraining data — the choice is not really "zero-shot or five-shot," it is "in-context learning at some shot count, or a small supervised fine-tune." If the team already has several thousand historical, labeled tickets sitting in a maintenance log, that data volume crosses into the range where a fine-tune could remove the per-request exemplar cost entirely, trading a one-time training cost for zero recurring token tax. If they have only the twenty or thirty examples used to build the few-shot prompt itself, fine-tuning is not a realistic option yet — there is not enough labeled data to train on reliably — and in-context learning is not the "cheaper" choice, it is the only choice that is actually available. M2-05 gives the full decision framework for exactly this fork.

Constructed scenario, illustrative only. The maintenance-ticket task in section 4 is a case where few-shot has real work to do — it encodes a specialized label boundary. Contrast it now with a task where few-shot has almost nothing to add over one-shot, so the two named alternatives — "add one demonstration" versus "add several" — can be compared directly rather than assumed.

The task. Reformat a free-text customer address into a fixed five-field record: street, city, region, postal code, country. There is no specialized label set and no ambiguous boundary case — the task is purely a matter of output shape.

One-shot attempt.

Instruction: Convert the address below into the fields shown.

Example:
Input: 44 Bridge Rd, Apt 3, Leeds, LS1 4HT, UK
Output: street=44 Bridge Rd Apt 3 | city=Leeds | region= | postal_code=LS1 4HT | country=UK

Input: 900 Rue de la Paix, 75008 Paris, France
Output:

Representative output: street=900 Rue de la Paix | city=Paris | region= | postal_code=75008 | country=France. Correct, and the single exemplar has already done the entire job: it fixed the field order, the delimiter, and the empty-field convention for a missing region. There is no boundary decision left for a second or third exemplar to teach, because the task never had one.

Five-shot attempt on the same input, adding four more worked examples covering different countries and formats. The representative output does not change: street=900 Rue de la Paix | city=Paris | region= | postal_code=75008 | country=France, identical to the one-shot result. The extra four exemplars added roughly 200 more tokens to every request in this template and changed nothing measurable on a frozen ten-item evaluation set built from the same distribution.

The reading. Section 4's task had a real decision boundary — which queue a name-mismatch ticket belongs to — that additional exemplars could keep teaching, one boundary case at a time, up to the point where the label set was fully covered. This task has no boundary at all, only a fixed mechanical transformation, and one demonstration transmitted the entire shape. The general rule the two examples together establish: shot count should track the number of distinct decisions the task actually contains, not a fixed habit of "more examples are safer." A pure reformatting task needs one exemplar; a task with six label boundaries may need one exemplar per boundary; neither needs more than that, and paying for more than that is the recurring-cost mistake section 4's arithmetic was built to catch.

The pattern underneath every row: shot count is a budget decision, not a quality dial you turn up indefinitely. More exemplars is not automatically better — the return flattens quickly on most tasks, and every exemplar past the point of flattening is paid for, every request, with nothing to show for it.

Prompt Engineering is objectives 2.1 through 2.5 and carries 13% of the blueprint, tied for third-largest domain — a high-value target for study time, and the source material calls it out explicitly as "a favorite for scenario questions." [GROUND TRUTH] (Sources/ncp-genl/domain-2-prompt-engineering.md): "At the professional level, expect questions that ask you to choose a prompting strategy under constraints (small dataset, specialized domain, strict output format) and to distinguish prompting from fine-tuning." In-context learning is objective 2.1, and it is the technique every later objective in this domain assumes you understand cold, because chain-of-thought, output constraints, and the fine-tuning decision are all variations on "what can a prompt buy without touching a weight."

Expect the question to arrive in one of a few recurring shapes:

1. Direct identification with a training-conflation distractor. "A team supplies three worked examples inside a prompt and observes improved accuracy, with no change to the model's parameters. What has occurred?" The keyed answer names in-context learning or few-shot prompting; a plausible-sounding wrong option calls this "fine-tuning on a few examples" or "few-shot learning" in the sense of a small training run.
2. A cost or scaling scenario. A prompt's exemplar count is described alongside a stated request volume or latency budget, and the question asks what the primary consequence of adding more exemplars is. The keyed answer is recurring token and prefill cost, not accuracy in isolation.
3. A small-data-versus-fine-tune fork. A scenario names a specialized task with a stated (small or large) amount of labeled data, and asks whether prompting or fine-tuning is the better first move. M2-05 develops the full rule; this lesson supplies the "few-shot as the appropriate choice under a genuine data shortage" half of it.

What the distractors typically look like

The house style in this domain's distractors is a real, nameable technique attached to the wrong mechanism. The standard traps are: describing few-shot prompting as training a model on the supplied examples; describing exemplar effects as persisting into later, unrelated requests; and asserting that adding exemplars "has no cost" because no training run occurs — every exemplar is still tokens, billed and processed on every single call.

Few-shot prompting places worked examples inside a single prompt's context window at inference time, and produces no artifact — remove the examples from the next request and the model's behavior reverts immediately, because nothing was saved. Few-shot fine-tuning (a small supervised training run on a handful of labeled pairs) computes gradients and updates weights or trains an adapter, producing a persistent artifact that changes the model's behavior on every future request with no examples required in the prompt at all. The two share a superficial resemblance — a small number of examples — but one is a string you paste and the other is a training job you run, and mixing them up is the domain's single most-cited exam trap for this objective.

No, and treating shot count as a dial you can turn up indefinitely is a measurable mistake rather than a stylistic one. The benefit of additional exemplars is well supported as a direction — few-shot generally improves alignment with the target task over zero-shot — but it is not unbounded, and every additional exemplar is paid for in full, on every request, for as long as the template stays in production. ⚠️ UNVERIFIED: no specific number of exemplars past which returns flatten is stated in the source material for this domain, and this lesson will not invent one; the professional-level discipline is to measure the marginal gain per additional exemplar on a frozen evaluation set for your specific task, and stop adding exemplars once that measured gain no longer clears the recurring cost you computed in section 4.

Sometimes, and the deciding factor is data volume and request volume, not a preference for one technique over the other. When a specialized task has only a small number of labeled examples available, in-context learning is not merely cheaper than fine-tuning — it is often the only adaptation option that is actually usable, because a reliable fine-tune needs far more labeled data than a few-shot prompt does. When the same specialized task has hundreds to thousands of labeled examples and runs at high, steady volume, the calculus reverses: the recurring per-request cost of carrying those examples in every prompt, computed in section 4, can exceed the one-time cost of training a small adapter that removes the need for exemplars entirely. M2-05 builds the complete decision framework across this and the knowledge-versus-behavior axis that governs the choice between prompting, RAG, and fine-tuning.

⭐ THE EARNED INSIGHT The word "learning" in "few-shot learning" describes what the technique looks like from the outside — a model that appears to get better at your task after seeing examples — not what happens mechanically inside it. Nothing is trained, nothing is saved, and nothing carries forward to the next request; the entire effect lives in the activations computed during one forward pass over tokens you paid to include, and every one of those tokens is a recurring bill you keep paying for as long as the prompt template stays in production, whether or not the exemplar is still earning its place.

• No gradient update ever occurs. Zero-shot, one-shot, and few-shot prompting all condition a frozen model through its context window; the effect vanishes the moment the request ends.
• "Few-shot learning" is not fine-tuning, despite the shared vocabulary — this is the domain's single most-tested confusion at every certification tier.
• Every exemplar is a recurring cost, paid in prefill tokens and latency on every request, forever, unlike a one-time training cost.
• Shot count is a budget decision. More exemplars is not automatically better; measure marginal gain against recurring cost on a frozen evaluation set.
• In-context learning is the right tool for small or specialized datasets where a fine-tune is not yet feasible — and the wrong tool for installing knowledge the model was never shown.
• Exemplars, retrieved context, and conversation history all draw from one fixed context window — a shot-count decision cannot be made in isolation from what else shares that budget.

Zero-shot, one-shot, and few-shot prompting all condition the model on what the task looks like. None of them give the model anywhere to work through a task that has several dependent steps — and asking for the final answer immediately, with no room to reason, is exactly the failure mode a multi-step task produces even with a perfectly chosen set of exemplars. Next: M2-02 covers chain-of-thought prompting and prompt templates for small or specialized data — when eliciting intermediate reasoning steps earns its extra tokens, when it is pure waste on a task that never needed reasoning at all, and how a structured template does for a specialized domain what an exemplar alone cannot.