Few-Shot Prompting and Examples
The concept
"Few-shot" prompting means showing the model one or more examples of exactly the input-to-output pattern you want, before you give it the real task. The term comes from "zero-shot" (no examples, just instructions), "one-shot" (a single example), and "few-shot" (a handful of examples) — and in practice, few-shot is often far more reliable than describing the desired format in words alone, especially for tasks involving tone, structure, classification, or any pattern that's easier to show than to explain.
The reason this works so well connects directly back to how LLMs generate text: they're predicting what comes next based on patterns. If you only describe the pattern you want ("respond formally, keep it under 50 words, use a bulleted list"), the model has to interpret your description and guess at the specifics. If you instead show two or three real examples of input paired with the exact output you want, the model can directly match the new input against that established pattern — there's far less room for misinterpretation, because you've demonstrated rather than described.
This is especially powerful for tasks where "good" is hard to put into words but easy to recognize — matching a specific brand voice, classifying items into categories with fuzzy boundaries, or converting messy input into a very particular clean format. Instructions alone often produce inconsistent results on these tasks because tone and judgment calls are hard to fully specify in prose; two or three labeled examples anchor the output far more tightly than any amount of additional descriptive instruction would.
A few practical guidelines make few-shot prompting work better: keep examples genuinely representative of the range of inputs you expect (including at least one edge case, not just the easy ones), keep the formatting of each example completely consistent (same structure, same labels, same punctuation), and generally three to five examples is the sweet spot — one example can accidentally over-anchor the model to that single case, while a dozen examples start eating into your context window for little additional benefit. If you notice the model copying incidental details from your examples (like reusing a name or number from an example in its real answer), that's a sign your examples need more variety.
Worked example
Imagine building a prompt to classify customer support tickets as "urgent" or "not urgent." With zero examples — just the instruction "Classify this ticket as urgent or not urgent" — results tend to be inconsistent: the model might flag a mildly annoyed customer as urgent one time and a genuinely broken-service complaint as not urgent the next, because "urgent" is subjective without more guidance.
Now add three labeled examples before the real ticket:
- "My password reset isn't working, I can't log in before my 2pm meeting." → Urgent
- "Loving the new dashboard design, just wanted to say thanks!" → Not urgent
- "The checkout page has been throwing errors for an hour, we're losing sales." → Urgent
With these three examples in place, the model has a much clearer, demonstrated sense of what "urgent" means in this specific context (business impact, time pressure) versus what doesn't qualify — and ticket classification becomes dramatically more consistent, because the examples did the defining work that abstract instructions couldn't.
Now consider a trickier edge case ticket: "I've emailed twice about my billing issue and haven't heard back, this is getting frustrating." A zero-shot prompt might misclassify this as not urgent (no system is broken). But because the three examples above establish that business impact and customer frustration both matter, a well-chosen fourth example — "I've emailed twice with no response and I'm considering canceling." → Urgent — would sharpen the model's handling of exactly this kind of ambiguous, relationship-risk case.
Exercise
Identify a repetitive writing task from your own job — turning rough meeting notes into polished email replies, converting bullet points into a LinkedIn post, or triaging incoming requests. Write two or three example input/output pairs showing exactly what "good" looks like for that task, making sure at least one example covers a trickier or less obvious case. Feed those examples to an AI assistant, followed by a new, real input. Then run the same new input through the assistant with zero examples, just a plain instruction.
Compare the two outputs for consistency, tone match, and how much editing each would need. As a final check, run a second new input through both versions and see whether the few-shot version stays consistent across two different real inputs, not just one — consistency across multiple inputs is the real test of whether your examples anchored the pattern.
Recap
- Few-shot prompting means demonstrating the pattern with 3–5 labeled examples instead of only describing it, including at least one edge case.
- It works because examples anchor the model's output more tightly than instructions alone, especially for tone, structure, and classification tasks.
- When instructions alone produce inconsistent results, adding a few concrete, varied examples of exactly what "good" looks like is usually the fastest, most reliable fix.
Resources
- Anthropic: "Use examples (multishot prompting)" — https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
- OpenAI Cookbook: prompting examples — https://cookbook.openai.com/
- Prompting Guide: "Few-shot prompting" — https://www.promptingguide.ai/techniques/fewshot