In-Context Learning

In-context learning is the model’s ability to infer a task pattern from examples in the prompt. It is a prompting technique, not weight training. Compared with fine tuning versus RAG, it is fast to change but limited by context construction. It is useful when a task can be demonstrated with a few representative examples and the examples fit in context.

Conditioning on examples

A prompt supplies examples followed by a new input . The model conditions on the whole sequence and estimates . Example order, label balance, and decoding settings from temperature and determinism can change the result.

In-context examples work partly by showing format and partly by showing decision boundaries. If the examples demonstrate only easy cases, the model may still fail on ambiguous or high-impact cases.

Worked example

Few-shot examples teach a pattern only if they disambiguate the input space:

Example inputLabelSignal
invoice overduebillinginvoice points to billing.
refund statussupportrefund points to support.
rain tomorrowweatherWeather is clearly separate.
New input: refund invoice?Contains one cue for each of two labels.

The new input is ambiguous because it combines refund and invoice. A model may choose either label depending on example order, wording, and prior knowledge. Better in-context examples would include refund invoices explicitly, or the prompt should ask a clarifying question when examples conflict.

Prompt design leverWhy it matters
Balanced labelsPrevents the model from overusing the majority example.
Boundary examplesShows what to do when cues conflict.
Output format examplesTeaches stable structure without fine-tuning.
Fallback instructionReduces confident guesses on ambiguous inputs.

Example selection

Good few-shot examples are not random examples. They should cover:

  • the normal case;
  • a boundary case where labels or actions are easy to confuse;
  • a negative or abstention case;
  • the exact output format expected downstream;
  • domain vocabulary that the model may otherwise misread.

For extraction tasks, examples should include missing fields and malformed inputs. For classification tasks, examples should include near-boundary items. For tool-routing tasks, examples should include requests that should not call a tool.

When to move beyond examples

In-context learning is a good first lever because it is cheap and reversible. Move to structured output, retrieval, or fine-tuning when examples become too many, the prompt becomes brittle, latency/cost grows, or behavior must remain stable across many tasks. If a dozen examples are required for every request, the system may need training data, a rules layer, or a narrower task definition.

Caveats

Examples can teach the wrong pattern, leak sensitive labels, or crowd out retrieved evidence. They can also create position bias: the model may over-weight recent examples or copy labels from the demonstration distribution. Regression tests should pin the exact prompt and include shuffled-example or alternative-order checks for fragile tasks.

References