AI Prompting: how to ask an AI and get a useful answer
Few shot prompting: giving the AI examples that work
Why showing two or three examples beats describing what you want, how many to include, and the example mistakes that quietly teach the model the wrong pattern.
The short answer
- Showing two or three worked examples usually beats any amount of describing, because the model copies a pattern far more reliably than it follows a rule.
- Two to five examples is the sweet spot for most everyday tasks, and the gain per extra example drops sharply after that.
- Your examples must be written in the exact output format you want, because the model copies their shape as faithfully as their logic.
- Examples teach accidental lessons: if all of yours are short, or all land on the same answer, the model learns that instead of the rule you meant.
- Include one edge case and one example of the answer you consider wrong, so the boundary is visible rather than implied.
If you are struggling to explain what you want, stop explaining and show two examples instead. A language model is a pattern matching machine, and a worked example is a pattern it can copy directly, while a described rule is something it has to interpret first. This technique has a name, few shot prompting, and it is the highest value habit in prompting after simply supplying context. It is at its strongest when your task is repetitive, when the rule is fuzzy, or when the output must have an exact shape every time.
Where a description fails and two examples do not
Say you are sorting incoming customer messages into urgent and not urgent. The described version looks reasonable:
Sort each message as Urgent or Not urgent. Urgent means the customer is blocked or at risk of losing money.
Run 20 real messages through that and you get arguments. A message saying "I cannot log in" gets marked Urgent, even though the customer is idly checking a balance. A message saying "the payment went through twice, please call me before end of day" gets marked Not urgent because it is written politely. The rule is fine. Your mental version of it contains a hundred small judgments the sentence does not carry.
Now show it instead:
- Message: "Hi, I was charged twice this morning for the same order, 89 dollars each. Can someone call me today?" Label: Urgent
- Message: "Just wondering if you will restock the navy one at some point. No rush at all." Label: Not urgent
- Message: "Our whole team has been locked out since the update this morning and we cannot process orders." Label: Urgent
- Message: "The tracking page says delivered but it arrived yesterday, so your site is a day behind." Label: Not urgent
Four lines, and the boundary is suddenly legible: money at risk or work stopped, versus curiosity and cosmetic complaints. The examples also show the exact answer format, two words with no explanation attached, which saves you a separate instruction telling it not to editorialize.
How many examples, and what they should cover
For everyday tasks, two to five is the range that matters. One example is better than none but often gets copied too literally. The jump from one to three is large, the jump from three to five is modest, and beyond roughly eight you are mostly spending tokens for very little gain, which matters if you are paying per request or working near the limit of a context window.
What they cover matters more than how many there are. A useful set includes:
- One clearly typical case, so the central pattern is obvious.
- One case that leans the other way, so the model sees both labels or both styles.
- One edge case that you had to think about, with the answer you decided on.
- Where it helps, one example of a wrong answer marked as wrong, so the boundary has a visible far side.
Vary the surface features on purpose. Different lengths, different tones, different vocabulary, so the only consistent thing in your set is the actual rule.
Four ways examples teach the wrong lesson
This is the part that few guides mention, and it is where most few shot prompts quietly fail.
| The trap | What the model learns | The fix |
|---|---|---|
| All examples share an accidental trait, such as every one being two sentences long | Output should always be two sentences | Vary length and structure deliberately |
| Most examples land on the same label | That label is the safe default | Balance the labels, or match your real world mix |
| Examples are formatted loosely | Formatting is optional | Write every example exactly as you want the answer |
| Examples run to paragraphs each | Long is correct, and your context fills up | Trim each example to the shortest version that still shows the pattern |
The label bias one is worth dwelling on, because lopsided labels are also one of the doors bias walks through in a trained system. If four of your five examples are marked Urgent, the model has learned two things: your rule, and the fact that Urgent is usually right. When a genuinely ambiguous message arrives, the second lesson can win.
Building a five line few shot prompt
- Write one sentence naming the task and the allowed outputs. For example: label each message as Urgent or Not urgent, and reply with the label only.
- Collect three to five real cases you have already decided, including the one that was hard.
- Write each as a single line in one fixed shape: input, then a separator such as Label:, then the answer.
- Add the new item at the end in the same shape, with the answer left blank.
- Run it on ten cases you know the answers to, and check where it disagrees with you. Every disagreement is either a missing example or a rule you have not actually decided.
Step five is the one people skip, and it is the one that turns a prompt into something you can trust for repeated work. When it passes, save the whole thing, placeholders and all, in your prompt library so you are not rebuilding it next month.
When examples are the wrong tool
Few shot prompting helps with pattern, style and format. It does not add knowledge. If the model does not know your product line, three examples will not teach it; you need to paste the product list, or connect it to a source it can look things up in. It also will not fix a task that needs real reasoning across a long document, where splitting the work into stages does more.
And if all you want is a consistent shape rather than a consistent judgment, you may not need examples at all. A single clear instruction plus a template with placeholders is often enough, which is the approach covered in getting output in the format you need.
What to check first
Pick the task you repeat most this week, whether that is triaging messages, turning meeting notes into action items or rewriting product descriptions. Find three cases you have already handled well, paste them in as examples, and run the next ten through. If the output drifts, look at your examples before you rewrite the instruction, because the accidental pattern is nearly always hiding in them.
Common questions
What do few shot and zero shot actually mean?
Zero shot means you describe the task and give no examples. Few shot means you include a handful of worked examples inside the prompt itself. The word shot refers to the examples, not to attempts, so a three shot prompt contains three examples and is still sent once.
Does the model remember my examples for next time?
No. They only exist inside that prompt or that conversation, and they are resent with every turn. If you want the same examples every time, save the whole prompt somewhere you can paste it, or put it into a custom assistant.
Is it cheaper to describe the rule than to show examples?
Describing is cheaper per request because it is shorter, but examples usually need fewer rounds of correction, so the total is often lower. If you run the same task hundreds of times through an API, trim the examples to the shortest set that still works.
Can I use real customer data as examples?
Only if your workplace rules and your provider's data terms allow it. Safer practice is to invent representative examples or to strip names, account numbers and addresses first, because anything in a prompt leaves your device and may be retained.