Show Examples

Use a few worked examples to show a model the exact format, tone and judgment you want, and pick examples that teach the right pattern.

14 minLesson 3 of 8
On this page
  1. Why examples work so well
  2. Before and after
  3. Choosing good examples
  4. Keep examples as data
  5. Try it yourself
  6. Common mistakes
  7. Check yourself
  8. What to practise next

A new teammate asks how your team writes commit messages. You could explain the rules: verb first, under 60 characters, ticket number in brackets at the end, no full stop. Or you could paste three good ones from last week. Most people get it faster from the three examples, and they also pick up rules you forgot to mention.

Models work the same way. When the thing you want is easier to recognise than to describe, such as a format, a tone or a labelling style, show it.

Why examples work so well

A language model writes by continuing text in the most likely way, as What Is an LLM describes. If your prompt contains three pairs of input and output, and then a fourth input with the output left blank, the most likely continuation is an output that matches the pattern of the first three.

So one example carries a lot of information. It shows the format, the length, the vocabulary and how to judge a borderline case, without a single extra rule. Using examples this way is often called few-shot prompting; a prompt with no examples is zero-shot.

Instruction Tag each review. Use these topics: … Example 1 input Example 1 output Example 2 input Example 2 output Example 3 input Example 3 output Your real input model writes this The blank is filled to match the pattern above it.
A few-shot prompt: an instruction, a handful of worked examples, then the real input with its output left for the model to write.

Before and after

Say you want to tag app store reviews so you can count them in a spreadsheet. Here is the zero-shot version.

No examplesIllustrative example. Real replies vary.
You
Tag each review with its topic and sentiment. 1. "Love the new dark mode, but the app logs me out every day." 2. "Battery drain is terrible since the update." 3. "Five stars, does exactly what I need."
Model
1. Topics: UI/Design, Authentication. Sentiment: Mixed. The user likes the dark mode but is frustrated by frequent logouts. 2. Topic: Performance (battery). Sentiment: Negative. 3. Sentiment: Very positive! Topic: General satisfaction.

Every line is a reasonable answer, and none of them can go in a spreadsheet. The order of fields changes, topics are invented on the fly, one line has two topics, and one has a commentary. Now the same request with three examples.

Three examplesIllustrative example. Real replies vary.
You
Tag each review with one topic and one sentiment. Copy the format of the examples exactly. <example> Review: "Search is fast now, finally." Tags: topic=performance; sentiment=positive </example> <example> Review: "Can't attach photos to messages anymore. Please fix." Tags: topic=bug; sentiment=negative </example> <example> Review: "Nice design. Wish it had a home screen widget." Tags: topic=feature-request; sentiment=mixed </example> Reviews to tag: 1. "Love the new dark mode, but the app logs me out every day." 2. "Battery drain is terrible since the update." 3. "Five stars, does exactly what I need."
Model
1. Tags: topic=bug; sentiment=mixed 2. Tags: topic=performance; sentiment=negative 3. Tags: topic=general; sentiment=positive

The format is now identical on every line, and it picked up details nobody wrote as rules: lowercase, hyphens in multi-word topics, exactly one topic each. The examples also showed how to handle a mixed review.

Look at line 3, though. general was never in an example. With no topic that fit, the model made one up in the right format. Examples show the pattern; they do not set its limits. If only certain values are allowed, list them in the instruction too: "Topics: performance, bug, feature-request, other."

Choosing good examples

The model learns from everything your examples have in common, including things you did not mean to teach. So pick them on purpose:

  • Vary them. Different lengths, different topics, different answers. If all three example reviews are negative, the model leans negative.
  • Include a tricky case. One example that shows the edge, like a mixed review or an input that fits no category, teaches more than three easy ones.
  • Keep them clearly separate. Wrap each in tags like <example> so the model does not mistake an example for the real input.
  • Use a few. Two to five is usually enough. Past that, each new example adds little and makes the prompt longer to read and to run.

Keep examples as data

When you use the same prompt in a program, store the examples as data and build the prompt from them. Adding or swapping an example then means changing one list entry, and every example gets exactly the same formatting.

function buildFewShotPrompt(instruction, examples, newInput) {
  const parts = [instruction, ""];
  for (const ex of examples) {
    parts.push("<example>");
    parts.push(`Review: "${ex.input}"`);
    parts.push(`Tags: ${ex.output}`);
    parts.push("</example>");
  }
  parts.push("", `Review: "${newInput}"`, "Tags:");
  return parts.join("\n");
}
 
const examples = [
  { input: "Search is fast now, finally.", output: "topic=performance; sentiment=positive" },
  { input: "Can't attach photos anymore.", output: "topic=bug; sentiment=negative" },
];
console.log(buildFewShotPrompt("Tag the review. Copy the format exactly.",
  examples, "Battery drain is terrible."));
def build_few_shot_prompt(instruction, examples, new_input):
    parts = [instruction, ""]
    for ex in examples:
        parts.append("<example>")
        parts.append(f'Review: "{ex["input"]}"')
        parts.append(f'Tags: {ex["output"]}')
        parts.append("</example>")
    parts += ["", f'Review: "{new_input}"', "Tags:"]
    return "\n".join(parts)
 
examples = [
    {"input": "Search is fast now, finally.", "output": "topic=performance; sentiment=positive"},
    {"input": "Can't attach photos anymore.", "output": "topic=bug; sentiment=negative"},
]
print(build_few_shot_prompt("Tag the review. Copy the format exactly.",
                            examples, "Battery drain is terrible."))

The prompt ends with Tags: and nothing after it. That last line is the blank in the figure: the natural thing to write next is one line of tags in the same shape.

Try it yourself

Try it: Fix the lopsided examples

This prompt has examples, but it keeps labelling messages as billing, even obvious bug reports. Find the problem with the examples and rewrite the prompt.

Show a sample answer

All three examples have the same answer, so the strongest pattern in the prompt is "the answer is billing". The model also never sees what the other labels look like, or that other labels exist.

Rewritten promptIllustrative example. Real replies vary.
You
Classify the support message as exactly one of: billing, bug, feature-request, other. Reply with the label only. <example> Message: "I was charged twice this month." Label: billing </example> <example> Message: "The app crashes when I open settings." Label: bug </example> <example> Message: "Could you add a way to export to PDF?" Label: feature-request </example> <example> Message: "Do you have an office in Lisbon?" Label: other </example> Message: "The export button does nothing when I click it." Label:

Why it works: one example per label, so no answer is favoured. The "other" example shows what to do with messages that fit nowhere. The instruction lists the allowed labels, so the model cannot invent a fifth. The feature-request example mentions exporting on purpose: it teaches that the topic alone does not decide the label; whether something is broken or missing does.

Common mistakes

Check yourself

Quick check

Why does adding input and output examples change the format of a model's reply?

Your examples are all negative reviews. What is the likely side effect?

With good examples, the model still invented a new topic, general. What is the best fix?

What to practise next

Examples fix the shape of an answer. When the answer depends on working something out, the shape is not enough: continue with Give the Model Room to Think. If you need replies a program can read, Structured Output builds on the formatting ideas here.