Few-Shot Examples — When and How Many

One example beats five adjectives

A worked example is a contract you can point at. "Match this shape" with a real input/output pair tells the model more than a paragraph of description. This is why few-shot prompting survived from the GPT-3 era — examples bypass the model's interpretation of your adjectives and show it the target distribution directly.

How many examples

Zero — fine for a frontier model on a familiar task with a clear schema.
One — best for new shapes or specific tones. The cheapest, highest-leverage step.
Two to five — when the task has shape variance you want the model to span (e.g., short and long inputs).
Six or more — pay for context tokens, get diminishing returns. Reserve for cases where the schema is genuinely hard.

Example design rules

Examples should cover the edges of the input space, not the average. Pick one short and one long, one happy-path and one failure case.
Tag the example with explicit boundaries (XML, JSON, fenced sections) so the model doesn't blur it into the user input.
If you ask for chain-of-thought, include reasoning in the example output. Otherwise omit it.
Wrong examples are worse than no examples — they pin the model to the wrong shape.

Code

Few-shot with explicit boundaries·xml

<task>Classify customer messages into one of: refund, complaint, feature_request, other.</task>

<example>
  <input>The shipping took 3 weeks and arrived dented. I want my money back.</input>
  <output>{"category": "refund", "reason": "damaged_late"}</output>
</example>

<example>
  <input>It would be great if you supported dark mode in the iOS app.</input>
  <output>{"category": "feature_request", "reason": "ui_dark_mode"}</output>
</example>

<input>{{user_message}}</input>

Few-Shot Examples — When and How Many

One example beats five adjectives

How many examples

Example design rules

Code

External links

Exercise

Progress

Comments 0