Give a large language model three examples of turning a company name into a stock ticker, and it will handle the fourth — no fine-tuning, no gradient step, no weight touched. This is in-context learning, the strangest capability transformers have, and here is the claim I'll defend in its strong form: it locates a skill the model already has rather than acquiring a new one. Few-shot prompting is closer to retrieval and configuration than to teaching.
The distinction is not academic. The wrong mental model of ICL produces a specific, recurring category of production failure. If the "locating, not learning" reading is right — and I'll be honest about where it's contested — then ICL works beautifully for tasks near the pretraining distribution and fails silently off it. Which is exactly the failure pattern people keep hitting and misdiagnosing.
The phenomenon, stated precisely
Start with what is not in dispute. During inference, the model's parameters are frozen. When you paste few-shot examples into a prompt, no learning in the ordinary machine-learning sense occurs — there is no loss, no backward pass, no update. Whatever adaptation happens exists entirely inside the forward computation over that one context window, and it evaporates the instant the context does. Ask the same model the same question in a fresh session with no examples and you are back where you started.
So the puzzle is sharp. A system that has stopped learning, in the technical sense, behaves as if it just learned. Performance on a task can jump from near-chance to strong with a handful of demonstrations, and it generally improves as you add more examples up to a point. GPT-3's 2020 paper made this a headline property, but it named the behavior without explaining the mechanism. The explanations came later, from three fairly different research directions, and they don't fully agree.
Explanation one: implicit Bayesian inference
The cleanest account comes from Xie and collaborators at Stanford (2021), who framed ICL as implicit Bayesian inference. The intuition: pretraining data is not a uniform soup of tokens. It is generated by an enormous mixture of latent concepts, tasks, styles, and document structures. A cooking blog, a Python tutorial, a French-English phrasebook, a legal contract — each is produced by a different latent "author" with different statistics.
A large model, trained to predict the next token across all of it, implicitly learns this mixture. When you then supply a prompt, the model is doing something like conditioning: inferring which latent concept could have generated these tokens, and continuing under that inferred concept. The few-shot examples are evidence. Three name-to-ticker pairs sharply raise the posterior probability that the task in play is symbol lookup, and the model completes accordingly.
The important move here is that ICL becomes selection among skills the model already represents, not construction of a new one. The examples don't install a capability; they disambiguate which existing capability to run. And there is striking empirical support cutting in exactly this direction. Min and colleagues (2022) took few-shot prompts and randomized the labels — pairing inputs with wrong outputs — and found that on many classification tasks, performance barely dropped. What did matter was the format, the input distribution, and the label space being present at all. If the demonstrations were teaching an input-to-label mapping, corrupting the mapping should be devastating. It wasn't. The examples were specifying the task, not the answer key.
This is the strongest single piece of evidence for the "locating, not learning" view, which is why I lead with it.
Explanation two: induction heads
The Bayesian story is computational — it says what problem the model is solving without saying what circuitry solves it. The mechanistic interpretability line supplies the missing gears. The key finding is induction heads, from Olsson and colleagues at Anthropic (2022), building on earlier circuits work.
An induction head is an attention head that implements a concrete, almost embarrassingly simple algorithm: find an earlier occurrence of the current token, look at what came after it last time, and predict that token again. The pattern is [A][B] … [A] → [B]. If the sequence contained "Mehdi Sahraoui" earlier and the current token is "Mehdi," the head attends back and completes "Sahraoui." This is prefix matching plus copying, distributed across a couple of attention heads working in composition.
Two things make this more than a curiosity. First, induction heads appear abruptly during training, and their appearance coincides with a sudden jump in the model's in-context learning ability — a phase change you can watch happen. This connects directly to the emergence debate: whether a capability "emerges" can depend heavily on how you measure it, and induction heads are a case where a real internal reorganization has a visible, mechanistic signature rather than being an artifact of a thresholded metric. Second, the same copy-and-continue machinery that completes a repeated name is plausibly the substrate for completing a repeated pattern — which is what a few-shot prompt is. Input, output, input, output, input, and now continue the pattern.
Induction heads almost certainly don't explain all of ICL. The abstract, semantic few-shot tasks people care about go well beyond literal token copying, and later work has traced more sophisticated pattern-matching and "function vector" style mechanisms. But they give the phenomenon a real circuit-level toehold, which the Bayesian account alone does not.
Explanation three: an optimizer in the forward pass
The third line is the most provocative and the least settled. Several groups — Akyürek and colleagues (2022), von Oswald and colleagues (2023), Garg and colleagues (2022) — asked whether a transformer, in the course of a single forward pass, could be implementing a learning algorithm on the examples in its context. The claim is not metaphorical. It is that the forward computation can perform something equivalent to a step or several steps of gradient descent on a small model fitted to the in-context data.
The evidence comes mostly from controlled toy settings. Train a transformer on synthetic tasks — say, in-context linear regression, where each prompt is a set of (x, y) points from a fresh linear function and the model must predict y for a new x. The transformer learns to do this well, and its in-context predictions closely track what an actual least-squares or gradient-descent solver would produce. Von Oswald and colleagues went further and gave an explicit weight construction under which a linear self-attention layer provably computes one gradient-descent update on an implicit linear model. So in these clean regimes, "the transformer runs an optimizer in its forward pass" is not hand-waving — it's a constructive result.
The honest caveats are large. These results live mostly in linear or simple-function-class worlds. Whether frozen production LLMs doing messy natural-language ICL are genuinely running implicit gradient descent — versus something that merely resembles it on the tasks tested — is not established, and some follow-up work argues the equivalence is weaker or more setup-dependent than the headline suggests. This is the most interesting and the most speculative of the three, and I'll label it as such.
They're not three answers to one question
The instinct is to ask which explanation is right. That's the wrong frame, and seeing why is most of the payoff.
The three accounts largely live at different levels of description — close to David Marr's classic split into the computational, algorithmic, and implementation levels of a system.
| Account | Level | What it explains |
|---|---|---|
| Bayesian task-selection | Computational | What problem ICL solves: infer the latent task, condition on it |
| In-context gradient descent | Algorithmic | What procedure might solve it, at least for simple function classes |
| Induction heads | Implementation | What circuitry physically carries pattern completion |
A single behavior can be truthfully described as Bayesian selection at the top, as an optimization procedure in the middle, and as attention-head composition at the bottom — the way a chess engine is simultaneously "choosing good moves," "running minimax with pruning," and "flipping transistors." The accounts constrain each other rather than compete. What remains genuinely open is how much of real ICL in large models on real tasks each one captures. That apportioning is unsettled, and anyone who tells you it's solved is selling something.
But notice what all three share. Bayesian selection picks from concepts learned in pretraining. Induction heads complete patterns whose vocabulary and structure came from pretraining. Even the in-context optimizer is fitting a model whose hypothesis class — what counts as a plausible function — was fixed during pretraining. Every account routes the real capability back to what the weights already encode. The prompt steers; it does not build.
The consequence you can act on
Here the abstract question earns its keep. If ICL is fundamentally the selection and configuration of pretrained skills, then its competence is bounded by the pretraining distribution, and the boundary is invisible from the inside.
For any task that lives near what the model saw millions of times — reformatting, translating between common languages, classifying sentiment, following a familiar template, extracting fields — few-shot prompting works because you are helping the model find a skill it robustly has. Add examples, watch it lock on. This is the happy path, and it's most of what people do.
Off the distribution, the story inverts. For a task genuinely novel to the model — a bespoke labeling scheme with no analog in the training data, reasoning over a truly unfamiliar formalism, a domain the corpus never covered — examples in the prompt will not conjure the skill, because there is no latent skill to select. And the failure does not announce itself. The model still pattern-matches to the nearest thing it does know and produces a fluent, plausible, confident, wrong answer. No error bar, no "I haven't seen this." Just competent-looking output that happens to be off.
That is the trap. People read ICL's successes as evidence the model can learn anything from examples, deploy it on an off-distribution task, see coherent output in testing, and ship. The coherence was never a signal of correctness. It was the model doing the only thing it can — completing a pattern from priors — on an input where the priors don't apply. This is the concrete, mechanistic version of a point I've made more generally: fluent next-token prediction is not the same as understanding, and ICL is the sharpest place that gap draws blood, precisely because it looks the most like reasoning.
So the operating rule is simple. Treat few-shot examples as skill selection, not teaching. Before you add more examples to fix a bad output, ask the prior question: is this skill plausibly in the model at all? If yes, examples help you address it — invest there. If the task is truly novel to the model, no amount of in-context demonstration will install the missing capability; you need fine-tuning, retrieval that supplies the actual knowledge, tools that do the computation, or a different model. Adding examples to a model that lacks the underlying skill doesn't teach it. It just gives the confident wrong answer better formatting.
The magic was never that the model learns from your examples. It's that it already knew, and your examples told it which thing it knew to be.