Skip to content
AIMODELRACE

Module 2 of 11 · Advanced · 9 min read

Few-shot prompting and examples

How examples teach format, style and judgement, how to choose them, and when to leave them out.

Key takeaways
  • 1Examples are the most reliable way to show a format or style that is hard to describe.
  • 2Use a handful of diverse, realistic examples, including an edge case.
  • 3Models copy examples closely, so vary them or outputs become clones.
  • 4For open-ended reasoning, describing the goal often beats examples.

01What examples actually teach

Few-shot prompting means including a few input and output pairs before the real input. The idea was popularised by the GPT-3 paper (Brown et al., 2020), which showed that large models can pick up a task from a handful of demonstrations without any retraining.

Examples communicate things that are tedious or impossible to spell out: the exact output shape, the tone, how much detail, how to handle ambiguous cases, and which distinctions matter. One good example often replaces a paragraph of instructions.

02Choosing good examples

Your examples are a miniature training set, so pick them like one.

  • Representative: drawn from the real inputs the prompt will see, not idealised ones.
  • Diverse: different lengths, topics and phrasings, so the model learns the pattern rather than the surface.
  • Include an edge case: an ambiguous input, an empty field, or a case where the right answer is 'none' or 'unknown'.
  • Consistent: the same format in every example, because inconsistencies get copied.
  • Balanced: for classification, do not show four positives and one negative unless that matches reality.

03Formatting examples so they work

Wrap each example in tags so the model can see where one ends and the next begins, and so it does not confuse examples with the real input. Put the real input last, in the same format, and leave the output for the model to complete.

Example
Classify each support ticket. Reply with JSON only. <example> <ticket>I was charged twice this month.</ticket> <output>{"category": "billing", "urgency": "high", "needs_human": true}</output> </example> <example> <ticket>How do I change my profile photo?</ticket> <output>{"category": "how-to", "urgency": "low", "needs_human": false}</output> </example> <example> <ticket>asdf test</ticket> <output>{"category": "unclear", "urgency": "low", "needs_human": false}</output> </example> <ticket>{{ticket}}</ticket>

04Contrastive examples: show bad and good

For style and judgement, a pair of examples with a short explanation of the difference teaches more than either alone. Label which is which and say what makes the good one better. This is especially useful for writing voice, code review comments and feedback tone.

Example
<weak>Our innovative solution leverages AI to empower your team.</weak> <strong>Your team answers customer emails in half the time, because drafts are ready when they open the ticket.</strong> The strong version names a concrete outcome for the reader and drops the buzzwords. Write the product description below in the strong style, using only claims supported by the notes. <product>{{product notes}}</product>

05Pitfalls

Examples are powerful precisely because models imitate them, which cuts both ways.

  • Cloning: if every example opens with the same phrase, so will every output. Vary openings and structure.
  • Leaking content: the model may reuse names, numbers or facts from examples in the real answer. Use clearly fictional details.
  • Order effects: the last example can have outsized influence. Shuffle or rotate examples when testing.
  • Too many: long example lists cost tokens and can crowd out instructions. Start with two or three and add only when tests show a gap.
  • Examples that contradict your instructions: the examples usually win. Make them agree.

06When to leave examples out

For open-ended creative work, examples can anchor the model to one style when you wanted range. For complex reasoning with modern reasoning models, a clear description of the goal and criteria often works better than worked examples, which can push the model towards a fixed method.

A good rule: start zero-shot with clear instructions, and add examples when tests show the format, style or edge-case handling is off.

Tip
If you need a specific format and your API supports structured output, use a schema for the shape and examples only for the judgement calls.

Finished reading?

Mark it complete to track your progress, then test yourself with the Advanced Prompting quiz.