Few-shot: learning by example

Show, don’t describe

Sofia spends twenty minutes describing her brand's tone: "dynamic but not aggressive, accessible but credible, warm but professional"... The result never looks like what she imagines. No wonder: those adjectives are subjective, and the model has an average interpretation of them that isn't hers.

The solution comes down to one principle: show, don't describe. Rather than explaining a style, give 2-3 input → output pairs that illustrate it. The model is a machine for spotting and extending patterns: concrete examples convey the format, tone, level of detail and implicit choices far better than any abstract instruction. This is called few-shot prompting: "few shots" = a few examples.

Turn features into benefits. Examples:
Feature: "5000 mAh battery" → Benefit: "2 days without recharging"
Feature: "end-to-end encryption" → Benefit: "nobody reads your messages, not even us"
Now: "8-core processor" →

Notice what the examples convey without it being written anywhere: the target length (short), the register (spoken, concrete), the structure (outcome for the user, not technical feat), and even the "not even us" trick that sets the tone. Describing all that would have taken a paragraph — and would have worked less well.

Zero-shot, one-shot, few-shot: three regimes

The vocabulary is simple. Zero-shot: you ask without any example — it's the default regime, sufficient for common tasks the model knows well. One-shot: a single example, useful for anchoring a simple format. Few-shot: 2 to 5 examples, the regime of choice as soon as the format or tone is specific to your use case.

Few-shot has a cost: your examples consume space in the context window and writing time. Good practice is therefore progressive: start zero-shot; if the output is fine, no need to do more. If the format or tone drifts, add examples. It's an escalation, not a systematic reflex.

How many examples? The 2-to-5 rule

2 to 5 examples are enough in the vast majority of cases. Below 2, the model can't distinguish the pattern from the accident (is this output short because it MUST be short, or by chance?). Beyond 5, the gains become marginal: you eat context and time with no measurable improvement.

More important than the number: diversity. Choose examples that cover the different cases the task will encounter — an easy case, a tricky case, an edge case — rather than five variations of the same comfortable case. If Sofia only shows technical smartphone features, the model will stumble on "2-year warranty". One non-technical example in the mix solves the problem in advance.

Also think about order: the model gives slightly more weight to the last examples. Put the one most similar to the inputs you're going to process last. And keep a strictly identical format from one example to the next: same separator, same punctuation, same casing.

Pattern consistency: your implicit contract

Your examples form an implicit contract: everything constant across your examples will be interpreted as a rule; everything that varies will be interpreted as free. If two of your examples end with a period and the third doesn't, you're sending a contradictory signal — and the output will be inconsistent in turn.

This is the number one cause of failed few-shots: not too few examples, but examples that contradict each other on a detail you didn't notice. Before blaming the model, reread your examples like a proofreader: comparable lengths? identical structure? consistent tone? same grammatical person? The devil is in those details.

flowchart LR
  E1["Example 1: input → output"] --> P["Pattern spotted: format, tone, length"]
  E2["Example 2: input → output"] --> P
  E3["Example 3: edge case → output"] --> P
  P --> N["New input"]
  N --> S["Output that follows the pattern"]
  E2 -.->|"Inconsistent example"| X["Blurred pattern → unpredictable output"]

Before/after: Sofia's brand tone

Descriptive version (the one that fails):

Rewrite this product description with a dynamic but not aggressive, accessible but credible tone: "Our software optimizes your teams' schedule management."

The result systematically falls back into generic marketing: "Boost your teams with an innovative solution...". Few-shot version (the one that works):

Rewrite product descriptions in our brand tone. Examples:

Before: "Our HR module automates leave tracking."
After: "Leave requests? Approved in 30 seconds, no spreadsheet, no lost email."

Before: "Our dashboard centralizes your metrics."
After: "All your numbers in one place. You open it, you know, you decide."

Now:
Before: "Our software optimizes your teams' schedule management."
After:

Why it works: the examples show the short sentences, the three-beat rhythm, the direct address to the reader, the concrete quantified benefit — everything that "dynamic but not aggressive" failed to convey. Sofia never described her tone again: she shows it.

When few-shot shines (and when it fails)

Few-shot excels on tasks with a precise, repetitive format: rephrasing product descriptions, classifying messages into categories, extracting information into a fixed template, generating homogeneous variants, imitating a brand tone. Wherever you can say "do it like this", it beats the abstract instruction.

It is however not very useful, even counterproductive, elsewhere. On complex reasoning tasks, examples of final answers teach nothing about the path to get there (we'll see better in chapter 3). On open creative tasks, too many examples lock the model into your cases and impoverish variety. And on tasks the model already masters perfectly, it's wasted effort.