Few-Shot Prompting: Practical Guide with Before/After Examples

Few-shot prompting is one of the most effective techniques in practical prompt engineering, and also one of the most misunderstood. Most guides treat it as a formatting exercise: write three clean input/output pairs, paste them in, collect better results. The part they skip is that example order often matters more than example quality, and a single poorly placed final example can pull your outputs in the wrong direction regardless of what came before it. This guide covers the mechanics, real before/after cases, and the ordering behavior that most practitioners never test but should.

What Few-Shot Prompting Actually Does (and When to Skip It)

Few-shot prompting works by including labeled examples directly in the prompt, letting the model infer the task pattern without any weight updates or fine-tuning. A few input/output pairs are enough for the model to pick up format, tone, classification logic, or stylistic conventions that are genuinely hard to describe in plain instructions.

Anthropic's documentation on prompt engineering frames this as "show rather than tell," which is accurate. Examples clarify subtle requirements that instructions alone leave ambiguous, like the difference between a confident brand tone and an aggressive one, or between a transactional search intent and a navigational one.

That said, few-shot is not always the right starting point. OpenAI's guidance for its o-series reasoning models recommends zero-shot first, because more capable reasoning models often generalize well without examples. The practical decision tree looks like this: if your task involves a specific format that is easier to demonstrate than describe, or if you have tried clear instructions and the output is still inconsistent, add examples. Start with one (one-shot), and only add more if outputs still miss the target.

One cost consideration worth noting: each example block is tokenized and billed as input on every API call. With Anthropic's prompt caching (available since August 2024), a static example block placed at the top of a prompt qualifies for caching discounts, which makes few-shot prompting significantly cheaper at scale if you keep the example set stable across requests. This is worth structuring for from the beginning if you are running any volume.

Before/After: What Changes When You Add Examples

Zero-shot vs. few-shot differences are most visible in tasks with constrained output formats or specific tone requirements. Here is a concrete case in e-commerce search intent classification.

Zero-shot prompt:

Classify the following search query as transactional, informational, or navigational.

Query: best trail shoes for wide feet

Typical output: a paragraph explaining what the query probably means, hedged language, sometimes the wrong category.

Few-shot prompt:

Classify each query as transactional, informational, or navigational.

Query: cheap running shoes sale
Intent: transactional

Query: how to clean suede trainers
Intent: informational

Query: zalando returns login
Intent: navigational

Query: best trail shoes for wide feet
Intent:

Typical output: transactional or informational, cleanly, without hedging. The format is no longer ambiguous because you demonstrated it three times.

The arXiv preprint on retrieval-augmented few-shot prompting puts numbers on this directionally. In structured prediction tasks, zero-shot prompting reached an F1 score of 36.35%. At 10 shots, that climbed to 71.43%. At 20 shots, 74.05%. The gap between zero and few-shot is large; the gap between 10 and 20 shots is smaller, which suggests diminishing returns set in quickly. For most production use cases, three to five examples is the practical ceiling before you are mostly paying tokens without gaining accuracy.

Anthropic's documentation recommends wrapping examples in XML tags so the model can distinguish them from instructions cleanly:

<examples>
<example>
<input>cheap running shoes sale</input>
<output>transactional</output>
</example>
</examples>

This is not decoration. For Claude specifically, structured tagging reduces the chance of the model treating example content as live instructions rather than demonstrations.

The Last-Example Effect: Why Example Order Is a Legitimate Debugging Step

This is the part most guides skip entirely, and it is the most operationally useful thing to understand about few-shot prompting.

Research from Liu et al. and Min et al. on in-context learning has documented that LLMs are disproportionately influenced by the final example in a few-shot sequence. The mechanism is recency bias: attention in transformer models weights recent tokens more heavily, so the last demonstration is the one the model "leans on" most when generating its response. Two well-crafted examples earlier in the sequence can be partially overridden by a weaker or misaligned final example.

The practical consequence is directly testable. In Claude and GPT-4, take a few-shot prompt for a task like product description writing or sentiment classification. Keep the examples identical and swap only their order. Output tone, format, and classification tendency will visibly shift based on which example lands last.

A specific case: if you are writing ad copy with three examples, two showing strong brand voice and one showing neutral informational copy, placing the neutral example last consistently pulls outputs toward neutral even though it is outnumbered two-to-one. The majority does not win here.

The implication for production prompting is direct. Your strongest, most representative example belongs last, not first. If your output quality is inconsistent and you have not rotated example order as a diagnostic step, you are skipping one of the cheapest debugging moves available. Change the order before you rewrite the examples or add more of them.

This also interacts with chain-of-thought prompting: if your examples include reasoning steps, the quality and style of reasoning in the final example has an outsized effect on how the model approaches the task in subsequent outputs.

Recency Bias in Practice: A Before/After on Tone

Here is a concrete before/after that illustrates the ordering effect for a product description task.

Setup: Three examples for generating short product descriptions. Examples A and B use confident, specific brand voice ("Built for high-mileage runners who need reliable cushioning without added weight"). Example C is neutral and generic ("This is a running shoe with cushioning features").

Order 1 (C last):

<example>Input: trail shoe / Output: [Example A — strong voice]</example>
<example>Input: road shoe / Output: [Example B — strong voice]</example>
<example>Input: casual sneaker / Output: [Example C — neutral]</example>

Input: waterproof hiking boot
Output:

Result: flat, informational copy with minimal brand voice. The model approximates the last example's register.

Order 2 (A last):

<example>Input: casual sneaker / Output: [Example C — neutral]</example>
<example>Input: road shoe / Output: [Example B — strong voice]</example>
<example>Input: trail shoe / Output: [Example A — strong voice]</example>

Input: waterproof hiking boot
Output:

Result: specific, confident copy matching the brand voice of Examples A and B. Same three examples, different order, meaningfully different output.

Testing this takes under ten minutes, and if you work with any volume of product copy or classified content, the ordering question should be part of how you evaluate your prompt before assuming the instruction layer is the problem.

From My Experience

In my work managing product catalogs across e-commerce platforms, the format-consistency problem shows up constantly. Attribute extraction from supplier data, generating short descriptions at scale, classifying customer queries into intent buckets for search ranking: all of these are tasks where zero-shot instructions produce output that is directionally correct but inconsistently formatted, which creates downstream problems in Snowflake pipelines or VTEX catalog imports that expect clean, predictable fields.

Adding two or three well-ordered examples is usually enough to fix the format issue without touching anything else in the prompt. The order detail genuinely matters in these contexts: when I use a weaker or more generic example as the final one (often because it was the easiest to write), outputs drift toward that register. Moving the best example to the final position is a reliable corrective step that requires no rewriting.

FAQ

How many examples do I actually need for few-shot prompting?

Start with one. Anthropic's guidance recommends beginning with one-shot and adding examples only if outputs remain inconsistent. Research on retrieval-augmented few-shot scenarios suggests diminishing returns after roughly 10 examples, and for most formatting or classification tasks, three to five is sufficient. More examples also means more tokens billed per call, so the cost scales linearly unless you use prompt caching.

Does few-shot prompting work differently on Claude versus GPT-4?

The general mechanics are the same: both models pick up patterns from in-context examples. Claude's documentation specifically advises using XML tags to separate examples from instructions, which the model responds well to. For GPT-4 and the o-series models, OpenAI's guidance suggests trying zero-shot first with reasoning models since they generalize more readily. The recency bias on final examples appears to affect both model families, based on the underlying research on transformer attention.

When should I use fine-tuning instead of few-shot prompting?

Few-shot is the right starting point for most production use cases because it requires no training infrastructure, is easy to adjust, and works well for format and style tasks. Fine-tuning makes sense when you have hundreds of high-quality labeled examples, the task is highly specialized and consistent, or you need to reduce token costs at very high volume. For most teams, few-shot with prompt caching covers the practical range before fine-tuning becomes worth the overhead. Anthropic's documentation covers prompt caching specifics for anyone optimizing at scale.

Can example order really override example quality?

In practice, yes, within limits. A truly terrible final example will hurt regardless of what came before it, but a mediocre final example can pull outputs away from the pattern established by stronger earlier examples. The effect is most visible in tasks where the model has to calibrate tone or style rather than follow strict logical rules. Swapping order costs nothing and takes one minute, so it should always be tested before rewriting examples or adding more of them.

Few-shot prompting is less about having the right examples and more about knowing which example the model will actually follow. It follows the last one most, and most practitioners never test that.