Positive example
Show one or more outputs that represent the pattern you want. Choose real, representative cases.
Guide
Show what a good answer looks like
One good example can express tone, level of detail and structure more precisely than a paragraph of adjectives.
Contrast example
Show an unwanted result beside an improved one and explain the difference. Useful when the failure is otherwise hard to describe.
Edge case
Include a difficult case where the usual pattern breaks. This reduces surprises in production.
Examples are requirements, not decoration
A model may copy accidental details. Vary names, length and subject matter so the examples emphasise the rule you actually want it to learn. Keep the structure consistent when format consistency is the goal.
There is no universally optimal number. Vendors give different advice, and research indicates that correctness, coverage, order and similarity to the current task may matter more than the count. Start with no examples, or the smallest set that fixes a measured failure.
Task: classify the request as [sales, support, billing].
Example 1
Input: "Can I get a price for 25 users?"
Output: {"category":"sales","reason":"asks for a quote"}
Example 2
Input: "The amount on invoice 1042 is wrong."
Output: {"category":"billing","reason":"concerns a specific invoice"}
Now classify:
[new request]