Few-Shot Prompting: Teaching AI by Example

The problem examples solve

Some requirements are easy to state. Length is a number. Sections are a list. Exclusions are a list of words.

Others are close to impossible to state. Try writing instructions that fully specify your company's tone of voice, or the exact level of technical detail your particular readers want, or how harsh a code review should be. You end up with three paragraphs of adjectives that a model resolves into something generic, because adjectives are exactly what it cannot pin down.

A single example carries all of that implicitly. The model extracts rhythm, register, hedging level, how much is explained versus assumed, where sentences break — dimensions you could not have enumerated because you were never consciously aware of them.

That is the whole case for few-shot prompting: it transmits tacit requirements, and most of the requirements that matter are tacit.

Zero-shot, one-shot, few-shot

The terminology is simply a count of examples, and each has a natural home.

• Zero-shot — no examples, description only. Correct for well-understood tasks with an easily stated output: summarise this, translate this, list the errors.
• One-shot — a single example. Enough when the pattern is obvious from one instance, typically a fixed format. Its weakness is that the model cannot tell which features of your example are the pattern and which are incidental to that one case.
• Few-shot — two to five examples. The sweet spot for anything involving judgement, voice or a format with variation. Multiple examples let the model see what stays constant and what changes, which is what a pattern actually is.
• Many-shot — dozens. Rarely worth it in a prompt: cost rises, and once a task needs that much demonstration you are usually better off with a template or a fine-tune.

How many examples: the practical answer

Two or three, in almost every case. Beyond that the returns fall away quickly while the cost and the risk both rise.

The reason two beats one is contrast. From a single example the model cannot distinguish the pattern from the particulars: was the answer short because short is the format, or because that question was simple? Two examples that differ in the right way make the invariant visible.

The reason three sometimes beats two is edge coverage — including one awkward case shows how the pattern bends under pressure. Beyond three, you are usually adding examples that repeat what the first three already established, paying for the tokens and increasing the chance one of them teaches something you did not intend.

Choosing examples: contrast is the whole game

The most common mistake is picking examples that are too similar to each other — usually because they were the first three to hand.

Three examples of the same easy case teach the model that the task is easy and narrow. It will handle the fourth easy case beautifully and fall apart on anything else, and you will not find out until it matters.

Choose examples that differ along the dimension you expect real inputs to vary on. If inputs vary in length, include a short one and a long one. If they vary in difficulty, include a straightforward one and a genuinely awkward one. If some inputs should produce a refusal or a caveat, one example must demonstrate that — otherwise you have taught the model that every input gets an answer.

• Include one typical case, so the default is right.
• Include one edge case, so the model sees how the pattern bends.
• Include one case where the correct response is "not enough information" or a caveat, if that ever happens in your real inputs.
• Avoid three near-identical examples — they narrow the model rather than teaching it.
• Use real examples from your actual work, not invented ones. Invented examples are cleaner than reality and teach a pattern that does not survive contact with it.

The failure mode nobody warns about: subject anchoring

This is the single most common way few-shot prompting goes wrong, and it is rarely mentioned.

The model does not know which aspects of your example you intended as the pattern. If all three examples are about billing, it reasonably infers that billing is part of what you are demonstrating. Give it a shipping question and you get an answer that keeps reaching back toward billing framing, billing vocabulary, billing analogies.

The fix is one sentence, and it is worth adding every time: state explicitly that the structure and voice transfer but the subject does not. "Match the format and tone of the examples above. The new item is on a different topic — do not carry over their subject matter."

A second version of the same problem is length anchoring: if every example is 80 words, the model will produce 80 words regardless of whether the new input warrants 30 or 200. If length should vary with the input, either vary it across your examples or state the rule directly.

Formatting examples so the boundaries are clear

Examples that blur into the instructions get treated as instructions, and instructions that blur into examples get treated as content. Explicit delimiters prevent both.

Any consistent marker works — the consistency matters more than the choice. Label the input and the output in each example so the mapping is unambiguous, and use the same labels in your actual request so the model recognises what it is being asked to complete.

On models that follow XML-style tags well, wrapping each example in tags is the cleanest option. With Markdown-oriented models, headers and horizontal rules do the same job.

• Label both halves: "Input:" and "Output:", or "Question:" and "Answer:", consistently across every example.
• Separate examples visibly — a rule, a blank line pair, or a tag per example.
• Put the examples after the instructions and before the real input, so the request is the last thing read.
• Use the same labels for the real input, so the model is completing a pattern rather than starting something new.
• Keep the examples short. A 400-word example crowds everything else in the prompt.

Few-shot with reasoning: teaching your method

The most valuable variation is including the reasoning in each example, not just the input and the answer. This teaches how you get there rather than merely what comes out.

The shape is: input, then the working, then the answer. The model infers your approach — which factors you weigh, what order you consider them in, when you conclude there is not enough information — and applies it to the new case.

This is how you transmit professional judgement, and it is worth the extra tokens for exactly that reason. A junior analyst learns your method by watching you work through three cases; a model learns it the same way.

The caution is symmetrical: it copies flawed reasoning as faithfully as good reasoning. If an example skips a step because you happened to know the answer, the model learns to skip that step generally. Examples with reasoning need proofreading in a way that examples with just answers do not.

Where few-shot is the wrong tool

Examples cost tokens and add anchoring risk, so they should earn their place.

• Simple, well-understood tasks. Summarising, translating, fixing grammar — a description is sufficient and an example just costs money.
• When a rule is easier than a demonstration. If the format is "always exactly five bullets", say that. Do not make the model infer a number it could have been told.
• Genuinely creative work. Examples anchor, and anchoring is the opposite of what you want when you asked for something original. You will get variations on your examples.
• When your examples are inconsistent with each other. Contradictory demonstrations are worse than none — the model picks one arbitrarily, and you cannot tell which.
• When you have twenty examples. That is a template or a fine-tuning dataset, not a prompt.

Worked example: classification

Classification is where few-shot shines, because the boundary between categories is usually easier to demonstrate than to define.

Consider routing inbound support messages. Describing the difference between "billing" and "account" in prose takes a paragraph and still leaves ambiguity. Three examples settle it in a few lines — including, critically, one borderline case that shows which way you want the edge to fall.

The borderline example is doing most of the work. Anyone can classify the obvious cases; the value of the demonstration is entirely in showing where you draw the line, which is precisely the thing your prose description was failing to convey.

• Input: "My card was declined but I was still charged." → Category: Billing. Reason: money movement, not access.
• Input: "I cannot log in since the update." → Category: Technical. Reason: product behaviour, not credentials policy.
• Input: "I want to change the email on my account." → Category: Account. Reason: identity and settings, even though it arrived via a billing thread.
• Then: "Classify the following message using the same categories and the same reasoning style. Give the category and a one-line reason."

Worked example: matching a voice

The other place few-shot is close to irreplaceable is tone. Every attempt to describe a house voice in adjectives produces the same generic professional register.

Instead, paste two short pieces that genuinely sound like you — ideally ones you did not write for this purpose, so they are unselfconscious — and ask for the same voice on a new topic.

Then add the anchoring guard, because tone examples are the most likely of all to drag subject matter with them: "Match the voice, sentence rhythm and level of formality. Do not reuse the topics, the examples or the metaphors from these pieces."

One further refinement that improves results noticeably: also give a counter-example. "Here is something in the voice we want to avoid" defines the boundary from the other side, and models use both edges.

Testing whether your examples are doing anything

Examples feel effective, which is different from being effective. They are also the most expensive part of a prompt, so it is worth checking.

The test is straightforward: run the task with the examples and without, on the same input, and compare against criteria you wrote down first. If you cannot see a difference, the examples are costing tokens for nothing and your description was already sufficient.

The second test is more interesting: remove one example at a time. If dropping an example changes nothing, it was redundant with the others. This is how three examples become two, which is usually where they should have been.

How it fits with everything else

Few-shot is one component, and it interacts with the others in ways worth planning for.

• It partly replaces format instructions. When the examples demonstrate the format unambiguously, a long written format specification becomes redundant — keep the short version as a backstop.
• It competes with context for room. Examples consume the same budget as the source material. When both matter, shorten the examples first.
• It pairs with an explicit anchoring guard. Assume the anchor will happen and write the guard rather than discovering it later.
• It works inside a chain. One step of a multi-step flow can carry examples specific to that step, which is cleaner than one enormous prompt carrying examples for everything.
• It belongs in your template. Once a set of examples works, save them with the prompt — re-picking examples each time is the expensive part.

Where your examples should come from

Almost every guide tells you to include good examples and stops there, which leaves the hardest part unanswered: where do you get them. Written from scratch, examples tend to be idealised — cleaner inputs and tidier outputs than anything the prompt will actually meet — and a model taught on idealised cases handles messy reality badly.

The best source is work you have already done. Your existing outputs are, by definition, in your voice, at your standard, and matched to inputs that really occurred. Extracting three of them costs ten minutes and beats an hour of invention.

The second-best source is failure. Every time the prompt produces something wrong, you have a real input paired with a corrected output — which is exactly the shape of a training example, and it targets a mistake you know the model makes.

• Mine your archive first: past emails, past summaries, past tickets, past product pages. Pick the ones a colleague would call representative rather than the ones you are proudest of.
• Keep a corrections file. When you edit an output heavily, save the original input and your edited version. After a fortnight you have a set of examples aimed precisely at your recurring failures.
• Include one genuinely awkward input — the ambiguous one, the one with missing fields, the one that arrived badly formatted. It teaches the model how to behave when reality is untidy.
• Do not clean up your inputs before using them as examples. If real inputs contain typos and inconsistent formatting, the examples should too, or the prompt will only work on inputs you have pre-tidied.
• Rotate examples when the task drifts. Examples encode a moment in time, and one describing a feature you removed is actively teaching the model something false.

Few-shot and context: what the examples cost you

Examples are the most expensive thing in a prompt. A worked example with realistic input and output can run to several hundred tokens, and four of them can outweigh the actual task by an order of magnitude — on every single call, forever.

For a one-off this is irrelevant. In production it is often the largest line on the bill, and it is worth knowing that the marginal example is usually the one that stops paying for itself. Two well-chosen examples typically capture most of the available gain; the fifth and sixth rarely earn their tokens.

There is also a subtler cost. Examples occupy the same context as your instructions and your input, and long example blocks push the actual task further from where the model is attending. A prompt that has become mostly examples is often performing worse than a shorter one, not better.

• Measure before you keep. Run the prompt with and without each example on the same test inputs and drop any that does not change the output.
• Trim the examples themselves. An example input rarely needs to be full length — enough to establish shape and difficulty is enough.
• If your provider supports prompt caching, a stable example block is exactly the kind of prefix that benefits from it. Keep the examples fixed at the front and the variable input at the end.
• Where the same examples serve many calls, consider whether the pattern is stable enough to be described in a rule instead. A clear rule costs twenty tokens; four examples demonstrating it cost six hundred.
• Watch the total. If examples are more than half your prompt and the task is not genuinely hard to describe, you are probably paying for reassurance rather than accuracy.

Dynamic few-shot: choosing examples per request

Everything above assumes a fixed set of examples baked into the prompt. There is a more powerful version used in production systems: pick the examples at request time, based on what the input actually is.

The mechanism is straightforward. Keep a library of input-output pairs. When a request arrives, find the two or three most similar past inputs — by embedding similarity, by category, or by any rule that fits your data — and insert those as the examples. A support ticket about billing gets billing examples; one about integrations gets integration examples.

This solves the fixed-example dilemma directly. A static set has to cover every case, so it either grows expensive or fails on the ones it does not cover. A dynamic set is always small and always relevant, which usually beats a larger static set on both accuracy and cost.

• Start simple. Selecting examples by an existing category label captures most of the benefit without any embedding infrastructure, and is worth trying before anything more elaborate.
• Keep one or two fixed examples alongside the dynamic ones to anchor format and tone, which are the same regardless of subject.
• Guard against a bad neighbour. If the closest match in your library is a poor output, you have just taught the model to reproduce it — so curate what goes into the library rather than adding everything.
• Log which examples were selected for each request. When an output is wrong, the first question is whether the examples chosen were sensible, and you cannot answer it without the log.
• Note the trade-off: dynamic examples break prompt caching, since the prefix changes every call. For high-volume, low-variance workloads a cached static block may still be cheaper overall.

The short version

Use two or three real examples, chosen to differ along the dimension your inputs actually vary on, with at least one awkward case among them.

Label the input and output halves consistently, put the examples between the instructions and the real request, and always add the sentence telling the model that the pattern transfers but the subject does not.

Then test whether they help at all, and drop the ones that do not. Examples are the most powerful thing you can put in a prompt and the most expensive — they should have to earn the space.

Related articles