What You Need to Know
Few-shot prompting means that you put a few worked examples in the prompt. Each example is an input and the output that you want, ideally with the reasoning for that output. Few-shot examples are the most effective technique for consistent, well-formatted output from Claude. More instructions, confidence thresholds and temperature adjustments all do less. When output is inconsistent, use few-shot examples first.
This lesson uses one made-up example throughout: an online bookshop that uses Claude in three places. A support agent answers customers, a code review tool checks the developers' pull requests, and a pipeline reads supplier invoices.
When to Deploy Few-Shot Examples
1. Detailed instructions alone produce inconsistent formatting. The prompt specifies the format in detail, yet the structure changes between runs: a bulleted list, then a table, then prose. More instructions rarely fix this problem. A few examples that show the exact format are the most effective fix. Two order-status replies in the bookshop's layout show the model what to copy.
2. The model makes inconsistent judgement calls on ambiguous cases. The bookshop's code review tool flags variable shadowing as "critical" in one file and "minor" in another. Its support agent routes "check my order" to different tools depending on the phrasing. These ambiguous cases need examples that show the correct judgement, with reasoning.
3. Extraction tasks return empty or null fields for information the document contains. The information is in the document, but in an unexpected format: inside narrative text instead of a structured table, or split across several paragraphs. Few-shot examples that show extraction from varied document structures address this problem. One publisher that supplies the bookshop writes "forty copies at six pounds each" in a sentence. For that publisher's invoices, Claude returns the price field empty.
How to Construct Effective Examples
Use 2 to 4 targeted examples. Fewer than 2 examples do not establish a pattern. Many more than 4 add tokens without proportional benefit. Current state (checked 29 October 2026): Anthropic's prompting best practices now say 3 to 5 examples. Exam guide v1.0 says 2 to 4, and that is the exam answer. Choose examples that cover the specific ambiguous cases that cause problems.
Each example must show reasoning. Beyond the input and output, it says why one action was chosen over plausible alternatives. The reasoning teaches the model to generalise its judgement to novel patterns, instead of only matching the cases in your examples.
Example: Tool selection for "check my order #12345" Input: "check my order #12345" Selected tool: lookup_order Reasoning: The user provides an order number (#12345), indicating they want order-specific information. Even though this could be interpreted as a general customer query, the specific order identifier makes lookup_order the correct choice over get_customer.
Without the reasoning, the model learns only "queries mentioning order numbers go to lookup_order." With the reasoning, the model learns the general principle: specific identifiers route to specific lookup tools.
Cover the failing cases. If extraction works on tables but fails on narrative text, show correct extraction from narrative text. If code review is inconsistent on variable shadowing, classify shadowing cases at different severity levels, with reasoning.
The Hallucination Reduction Effect
Few-shot examples also reduce hallucination in extraction tasks. The model sees correct extraction from varied structures: inline citations and bibliographies, narrative descriptions and structured tables, headers and embedded text. From those examples, it learns to handle structural variety without inventing data.
This effect matters most for documents with inconsistent formatting. A supplier invoice might list books in a table on one page and in a paragraph on the next. Without examples, the model often extracts the table correctly but returns empty fields for the narrative section, or fabricates values. If you show the model both structures, extraction quality improves. The bookshop's invoice pipeline needs an example of each kind.
Few-Shot for Reducing False Positives
In code review and analysis, few-shot examples show what to flag and what to ignore. Examples that separate acceptable patterns from genuine issues reduce false positives and still catch real problems.
Example: Variable shadowing assessment
Code: function process(items) {
const result = items.map(item => {
const result = transform(item); // shadows outer 'result'
return result;
});
return result;
}
Severity: minor
Reasoning: The inner 'result' shadows the outer variable but
within a limited scope (arrow function). The code is still readable
and the shadow does not cause a bug. This is a style preference,
not a defect. Flag as minor only if style consistency is in scope.
This example teaches the model to distinguish genuine bugs from benign patterns. False positives fall, and the model can still generalise to shadowing that is a real problem.
Key Concept
Few-shot examples are the most effective technique for consistency. Use 2 to 4 targeted examples, with reasoning, when instructions alone give inconsistent results, ambiguous judgements, or empty fields for data that exists.
In the exam
The exam presents scenarios where detailed instructions produce inconsistent results. It asks whether you would "add more instructions" or "add few-shot examples." The answer is almost always to add few-shot examples. The exam also tests whether you can recognise when another technique applies instead:
| Problem | Correct Technique |
|---|---|
| Inconsistent output formatting | Few-shot examples |
| Malformed JSON output | tool_use with JSON schemas |
| Fabricated values for missing fields | Optional/nullable schema fields |
| Wrong tool selection | Better tool descriptions (first), then few-shot |
| Model misses information in narrative text | Few-shot examples showing narrative extraction |
| Extraction sum does not match total | Validation-retry loop |
Exam Traps
Choosing 'add more detailed instructions' when output formatting is inconsistent
Instructions describe the format again, while examples show the target format. More instructions rarely fix inconsistent output; a few examples of the exact format are the most effective fix.
Adding many examples to cover every case and variant
The exam guide says 2 to 4 targeted examples with reasoning. Current docs (October 2026) suggest 3 to 5. Many more waste tokens without proportional benefit; the reasoning in each example is what teaches the model to generalise.
Using confidence thresholds to fix inconsistent judgement calls
Confidence thresholds are poorly calibrated and do not address the root cause. Few-shot examples showing the correct judgement for ambiguous cases directly teach consistent decision-making.
Practice Scenario
An extraction pipeline finds data in structured tables but returns empty fields when the same information sits in narrative paragraphs. The prompt already lists every required field, and documents must reach the model as they are. What should you try first?
Build Exercise
Build a Few-Shot Enhanced Extraction Prompt
What you'll learn
- Identify the three triggers for deploying few-shot examples: inconsistent formatting, ambiguous judgement calls, and empty fields for existing data
- Construct effective few-shot examples with reasoning, not just input-output pairs
- Use 2-4 targeted examples covering the specific failing scenarios
- Distinguish when few-shot examples are the right technique versus schema changes or validation loops
- Measure the impact of few-shot examples on empty field rates and format consistency
- Create a base extraction prompt with detailed instructions but no examples and test it against 10 documents with varied structures: tables, narrative paragraphs, mixed formats
Why: Establishing a baseline without examples demonstrates the consistency problem the exam tests. Detailed instructions alone produce inconsistent output across varied document structures, which is the exact trigger for deploying few-shot examples.
You should see: Inconsistent extraction results across the 10 documents: fields extracted correctly from tables but empty or wrong from narrative paragraphs, different output formats across runs, and inconsistent handling of edge cases.
- Record which fields are consistently empty or inconsistent across document structures
Why: Identifying the specific failure patterns tells you exactly what your few-shot examples need to demonstrate. The exam tests whether you can diagnose the problem before prescribing the solution.
You should see: A table or log showing which fields fail on which document types. Typical pattern: dates extracted correctly from tables but missed in narrative text, amounts inconsistent when written in words rather than digits, line items empty when embedded in paragraphs.
- Create 3 few-shot examples targeting the failing patterns — each must include reasoning explaining why the extraction was done that way
Why: Examples with reasoning teach the model to generalise to novel patterns, not just match specific cases. Without reasoning, the model learns only surface-level pattern matching. The exam specifically tests that reasoning-included examples outperform input-output pairs.
You should see: Three examples, each showing a different document structure (table, narrative, mixed), with the correct extraction AND a reasoning section explaining how the data was located and why the extraction decisions were made.
- Re-run the same 10 documents with the few-shot enhanced prompt and compare: empty field rate, format consistency, and extraction accuracy
Why: Quantifying the improvement demonstrates the effectiveness of few-shot examples as the first-choice technique for consistency problems. The exam expects you to know that few-shot examples outperform additional instructions for this class of problem.
You should see: A measurable reduction in empty fields (especially on narrative documents), improved format consistency across document types, and higher overall extraction accuracy. The improvement should be most dramatic on the document types that previously failed.
- Document which structural patterns benefit most from few-shot examples and which require different techniques like schema changes
Why: The exam tests whether you can match the right technique to the right problem. Few-shot examples fix consistency and structural variety issues, but malformed JSON needs tool_use, fabricated values need nullable schemas, and sum discrepancies need validation loops.
You should see: A decision matrix showing which problem types improved with few-shot examples and which still need other interventions. Narrative extraction and format consistency should improve. Fabrication of missing data should not improve and needs schema changes instead.
Sources
- Claude Certified Architect Foundations Exam Guide — Task Statement 4.2 — Anthropic
- Prompt Engineering Overview — Anthropic
- Prompting best practices — Anthropic
- Building with the Claude API: Providing examples (Claude Academy) — Anthropic
- CCAR-F Exam Guide v1.0: Task Statement 4.2 — Anthropic