What few-shot prompting is
Few-shot prompting is the practice of putting a small number of worked examples — pairs of input and the output you want — directly into your prompt before the real request. The model reads those examples and infers the pattern: the format, the tone, the decision rule, the level of detail. This is called in-context learning because the model “learns” the task from the context of the prompt itself, without any training or fine-tuning. It is one of the most practical techniques in prompt engineering because it turns a vague instruction into a concrete demonstration — and demonstration is often far more effective than description for getting reliable, consistently formatted output.
How to construct good examples
The quality of your examples matters more than their quantity. Good few-shot examples are:
- Correct — a wrong example teaches the model to be wrong.
- Consistent — identical structure, delimiters, and field names across every example and the real query.
- Diverse — cover the range of cases you care about, including edge cases, so the model does not overfit to one pattern.
- Balanced — for classification, include more than one class, or the model may just repeat the only label it saw.
A clean format looks like this:
Text: "The delivery was late and the box was crushed." -> Sentiment: negative
Text: "Arrived early, works perfectly!" -> Sentiment: positive
Text: "It's fine, nothing special." -> Sentiment: neutral
Text: "The app keeps crashing on launch." -> Sentiment:The model completes the final line in the same shape, returning negative.
How many examples and where they help most
Two to five examples is the usual sweet spot. One-shot (a single example) often suffices for simple formatting; richer or more nuanced tasks justify more; beyond about five, you pay tokens for diminishing returns. Few-shot shines in specific situations: enforcing a rigid output format (a particular JSON shape, a fixed label set), locking in a consistent tone or style for writing tasks, teaching a non-obvious decision rule that is hard to describe in words, and rescuing tasks where plain zero-shot instructions give inconsistent results. The general principle: examples are most valuable exactly when an instruction alone is ambiguous. When the task is simple and the model already does it well, stay zero-shot — it is cheaper and shorter.
Common pitfalls and the fine-tuning boundary
A few traps recur. Inconsistent formatting between examples and the query confuses the model — keep delimiters and structure identical. Skewed examples (all the same class, or only easy cases) bias the output; mix it up. Stale or wrong examples silently degrade quality, so review them as your task evolves. And watch the token cost: every example is sent on every call, so heavy few-shot prompts add up at scale. Finally, treat few-shot as a signal about the right tool. If you need many examples to get acceptable reliability, or the same examples are sent on millions of calls, fine-tuning the model on those examples is usually cheaper and more robust than carrying them in every prompt. Few-shot is the fast, flexible first move; fine-tuning is the durable answer when the task is high-volume and well-defined.