When to use examples
Few-shot prompting as boundary-drawing: which examples earn their token cost, how many you need, and the selection mistakes that backfire.
Adding worked examples to a prompt — few-shot prompting — is the highest-leverage technique in this course when it's warranted, and pure token waste when it isn't. The skill is knowing which situation you're in.
When examples earn their cost
- Boundary cases in classification. Your rules say what COMPLAINT and RETURN_REQUEST mean; an example of the ambiguous email between them teaches where the line actually sits. Rules define regions; examples pin borders.
- Format that's easier shown than described. Your exact summary style, your reply voice — one good example replaces a paragraph of adjectives.
- Consistent handling of recurring weirdness. Emails with no body, multi-issue emails, sarcasm ('great, ANOTHER broken bowl, love it') — one example each turns your incident history into training.
- Zero-shot already failed. The honest trigger: you ran it without examples (always try zero-shot first — modern models are strong), found a systematic miss, and now add the example that targets that miss.
How many, and which
- Two to five covers most tasks. Returns diminish fast; cost doesn't — every example rides along on every call, forever.
- Spend your slots on hard cases. An example the model already gets right is a wasted token budget; your misses list is your shopping list.
- Balance labels in classification. Three COMPLAINT examples and one INQUIRY quietly teaches 'when unsure, say COMPLAINT'. Models are frequency-sensitive — and order-sensitive too (the last example pulls hardest), so put the most representative case last.
- Keep examples real-shaped. Invented tidy examples teach the model to expect tidy inputs. Pull from real (redacted) traffic, mess and all.
<examples>
<example>
<email>Subject: cracked on arrival
Body: Bowl arrived cracked. Can you send a new one? Order HL-1088.</email>
<output>{"category":"COMPLAINT","urgency":"HIGH","confidence":"HIGH","order_id":"HL-1088","damage_mentioned":true,"summary":"Customer reports bowl arrived cracked and asks for replacement.","suggested_reply":"..."}</output>
<why>Damage present → COMPLAINT even though a replacement is requested. Damage rule outranks return language.</why>
</example>
</examples>Note the optional <why> line — a one-sentence rationale inside the example. It costs a few tokens and buys transfer: the model learns the rule the example demonstrates, not just its surface. Use it on boundary-case examples; skip it on format examples.
Module 1's precedence rule compounds: every example you add is another thing that can silently contradict a future rule change. Keep examples few, dated, and re-audited on every instruction edit — your Module 5 eval suite will make this automatic.