Few-Shot Prompting
Few-shot examples are the most reliable way to get consistent formatting and judgement from Claude — often more effective than adding another paragraph of instructions.
Few-shot prompting means showing Claude a small number of worked examples inside the prompt before asking it to handle the real input. When detailed instructions still produce inconsistent results, examples usually outperform more prose, more thresholds, or temperature tweaks — because they demonstrate the target behaviour directly rather than describing it.
Three signals that you need examples
- Inconsistent formatting despite detailed instructions — output alternates between bullets, tables, and prose. Show 2-4 examples of the exact structure you want.
- Inconsistent judgement on ambiguous cases — similar inputs get classified or routed differently depending on phrasing. Examples with reasoning teach a stable decision rule.
- Empty or null fields for information that exists — data is present but embedded in narrative text or split across paragraphs. Examples showing extraction from that varied structure close the gap.
When thorough instructions still yield inconsistent output, the fix is few-shot examples — not another paragraph of rules.
Piling on more prose when detailed instructions already failed rarely moves consistency — the model still has to interpret the description.
"Always be consistent. Use the same format
every time. Really, be very consistent."Show 2-4 worked examples with reasoning so the model copies a demonstrated pattern and learns a transferable rule.
Input: "charged twice" -> Tool: get_customer
Reasoning: no order id; account-level billing,
so customer context is needed first.How many examples, and what goes in them
Use 2-4 targeted examples. Fewer than two does not establish a pattern; more than four spends tokens without proportional benefit. Critically, each example should include the reasoning behind the decision, not just an input-output pair. Reasoning teaches a generalizable principle so the model applies the rule to novel inputs instead of memorising the literal surface pattern.
[
{ "role": "user", "content": "check my order #12345" },
{
"role": "assistant",
"content": "Tool: lookup_order. Reasoning: the message includes an order number (#12345), so it needs order-specific data. Even though it reads like a general query, the identifier makes lookup_order correct over get_customer."
},
{ "role": "user", "content": "why was I charged twice?" },
{
"role": "assistant",
"content": "Tool: get_customer. Reasoning: no order identifier is present and the question is about account-level billing history, so customer context is needed first."
},
{ "role": "user", "content": "where is my package for order 88921?" }
]Pick examples that cover the cases that currently fail. If extraction works on tables but breaks on narrative paragraphs, include at least one narrative example. Covering both the passing and failing structures is what drives the measurable improvement.
Side benefits: fewer hallucinations and false positives
Examples that show the model handling structural variety — tables, headers, and prose — reduce the temptation to fabricate values when a field is hard to locate. Likewise, examples that show both acceptable and problematic patterns teach the model to distinguish genuine issues from benign ones, cutting false positives without lowering detection.
Few-shot versus other techniques
| Problem | Correct technique |
|---|---|
| Inconsistent output formatting | Few-shot examples |
| Malformed JSON output | Tool use with JSON schema |
| Fabricated values for missing fields | Optional/nullable schema fields |
| Wrong tool selection | Better tool descriptions, then few-shot |
| Model misses info in narrative text | Few-shot examples of narrative extraction |
| Extracted line items don't sum to total | Validation-retry loop |
Do not pick 'add more detailed instructions' when formatting is already inconsistent despite thorough prompts, and do not assume examples only teach literal pattern-matching — reasoning-in-examples teaches transferable decision rules.
Draw your few-shot examples from the exact document types that currently fail. The biggest accuracy gains show up on previously failing structures.
How the exam will try to trick you
The distractors below look right under time pressure — learn the tell.
- The trap
Output is still inconsistent, so add more detailed instructions to the prompt.
Correct answerDeploy 2-4 few-shot examples demonstrating the exact format you want.
Why: If thorough instructions already failed, more prose does not help — examples show the target behaviour directly.
- The trap
Assume few-shot examples only teach literal pattern-matching of the cases shown.
Correct answerInclude the reasoning in each example so the model generalises the decision rule to novel inputs.
Why: Reasoning-in-examples teaches a transferable principle, not just the surface pattern of one case.
- The trap
Fix inconsistent judgement on ambiguous cases with a confidence threshold.
Correct answerShow few-shot examples with the correct judgement for the ambiguous cases.
Why: Confidence scores are poorly calibrated and do not address the root cause; examples teach the decision directly.
Key takeaways
- Few-shot examples are the most reliable fix for inconsistent formatting and judgement.
- Use 2-4 examples: fewer than two sets no pattern, more than four wastes tokens.
- Include reasoning in each example so the model learns principles, not literal patterns.
- Choose examples that cover currently-failing structures, especially narrative text.
- Examples reduce hallucination and false positives as a side effect.
- Malformed JSON is a tool-use problem; missing-field fabrication is a schema problem — not few-shot.
Frequently asked questions
What is few-shot prompting?+
Few-shot prompting places a small number of worked input-output examples (ideally 2-4, each with reasoning) inside the prompt before the real task, so Claude learns the desired format and decision rule from demonstration rather than description.
How many few-shot examples should I use with Claude?+
Two to four targeted examples. Fewer than two fails to establish a pattern, and more than four adds token cost without proportional benefit. Prioritise examples that cover the input types your pipeline currently gets wrong.