Use examples
Some things are easier to show than to describe: a tone of voice, an output layout, where the line falls between two categories. A handful of worked examples in the prompt (often called few-shot prompting) teaches the model those things faster and more reliably than another paragraph of rules.
A quick illustration
Task: turn engineers’ commit messages into one-line release notes for customers.
Without examples, the instruction “rewrite for customers” yields lines that vary in length, tense and level of detail.
With three examples, the pattern is clear:
Rewrite each commit message as a one-line release note for customers.
<example>
<commit>fix(cart): null deref when coupon removed after currency switch</commit>
<note>Fixed an error that could appear when removing a coupon after changing currency.</note>
</example>
<example>
<commit>feat(export): add XLSX option to orders export, behind flag EXPORT_XLSX</commit>
<note>You can now export orders as an Excel file.</note>
</example>
<example>
<commit>chore: bump eslint to 9.12</commit>
<note>SKIP</note>
</example>The examples teach several rules at once without stating them: past tense for fixes, “You can now” for features, no internal names such as flags or modules, and SKIP for changes customers never notice.
How to choose examples
| Do | Avoid |
|---|---|
| Use real inputs from your data. | Invented, tidy inputs that are easier than reality. |
| Cover the hard cases: the borderline, the empty, the messy. | Three examples that all show the easy case. |
| Vary length, wording and topic. | Examples so similar that the model copies their surface (always three bullets, always the same opening word). |
| Include at least one “do nothing” or “not applicable” case if that outcome exists. | Only positive examples, which teach the model that every input needs action. |
| Keep the format of every example identical to the output you want. | Small inconsistencies (a trailing period here, none there), which the model will reproduce at random. |
Three to five examples are usually enough. Past that, each new example adds tokens but little accuracy, unless it covers a case the others do not.
Mark examples clearly
Wrap each example in tags so the model can tell examples from the real task, and so it does not mistake an example input for the input it should process:
<example>
<input>...</input>
<output>...</output>
</example>Then present the real input in the same <input> tag after the examples, and ask for the output alone.
Examples as conversation turns
Another layout puts each example as a user turn followed by an assistant turn, before the real request. This works well for chat-style tasks and keeps each example short:
import os
from openai import OpenAI
client = OpenAI(base_url="https://app.syntic.ai/v1", api_key=os.environ["SYNTIC_API_KEY"])
messages = [
{"role": "system", "content": "Rewrite commit messages as one-line customer release notes. Reply SKIP for changes customers will not notice."},
{"role": "user", "content": "fix(cart): null deref when coupon removed after currency switch"},
{"role": "assistant", "content": "Fixed an error that could appear when removing a coupon after changing currency."},
{"role": "user", "content": "chore: bump eslint to 9.12"},
{"role": "assistant", "content": "SKIP"},
{"role": "user", "content": "perf(search): cache facet counts per category for 60s"},
]
r = client.chat.completions.create(model="Amara Quick", stream=False, max_tokens=60, messages=messages)
print(r.choices[0].message.content) # e.g. "Search results with filters now load faster."The assistant turns are written by you; the model treats them as its own earlier replies and continues the pattern.
Explaining why an example is right
For judgement tasks (classification, grading, moderation), a short note on why the example output is correct helps the model transfer the reasoning to new cases:
<example>
<review>Arrived a day late but the coffee is the best I've had.</review>
<label>positive</label>
<why>The delay is mentioned but the overall verdict is clearly favourable.</why>
</example>Do not ask for a <why> in the real output unless you want one; the examples can carry it while the requested output omits it.
Finding examples that matter
Start with no examples, run your test set (see Test your prompts), and look at the failures. Each cluster of similar failures suggests one example. Add it, re-run, and keep the example only if the score improves. This keeps the prompt short and every example earns its tokens.
Examples sit at the start of every request. If they are the same each time, they are served from the prompt cache, so a few hundred tokens of examples cost little after the first call.
Related pages
- Classify text: examples added for confused label pairs.
- Format the output
- Write clear instructions