4.2 Few-Shot Prompting

What You Need to Know

Few-shot examples are the most effective technique for achieving consistent, well-formatted output from Claude. Not more instructions. Not confidence thresholds. Not temperature adjustments. When your output is inconsistent, few-shot examples are the first tool to reach for.

This is a direct exam principle. The exam presents scenarios where detailed instructions produce inconsistent results and tests whether you choose “add more instructions” or “add few-shot examples.” The correct answer is almost always the latter.

When to Deploy Few-Shot Examples

Three specific triggers tell you few-shot examples are needed:

1. Detailed instructions alone produce inconsistent formatting. You have written a thorough prompt specifying the output format, but the model produces different structures across invocations — sometimes a bulleted list, sometimes a table, sometimes prose. More instructions will not fix this. A few examples showing the exact format you want will.

2. The model makes inconsistent judgement calls on ambiguous cases. For a code review tool, the model flags variable shadowing as “critical” in one file and “minor” in another. For a tool selection agent, it routes “check my order” to different tools depending on phrasing. These ambiguous cases need examples demonstrating the correct judgement, with reasoning.

3. Extraction tasks produce empty/null fields for information that exists in the document. The information is present but in an unexpected format — embedded in narrative text rather than a structured table, or split across multiple paragraphs. Few-shot examples showing extraction from varied document structures resolve this.

How to Construct Effective Examples

The rules are tight:

Use 2-4 targeted examples. Fewer than 2 doesn’t establish a pattern. More than 4 wastes tokens without proportional benefit. Point your examples at the specific ambiguous scenarios causing problems.

Each example must show reasoning. Don’t just show input-output pairs. Show why one action was chosen over plausible alternatives. That teaches the model to generalise its judgement to novel patterns, not just match the specific 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 scenarios. If your extraction works on tables but fails on narrative text, your examples should show correct extraction from narrative text. If your code review is inconsistent on variable shadowing, your examples should classify variable shadowing scenarios at different severity levels with reasoning.

The Hallucination Reduction Effect

Few-shot examples have a useful side effect: they cut hallucination in extraction tasks. When the model sees examples of correct extraction from varied document structures — inline citations vs bibliographies, narrative descriptions vs structured tables, headers vs embedded text — it learns to handle structural variety without inventing data.

This matters most for documents with inconsistent formatting. A financial report might list expenses in a table on one page and bury them in a paragraph on the next. Without examples, the model often nails the table but returns empty fields for the narrative section, or worse, fabricates values. Show it both structures and extraction quality climbs.

Few-Shot for Reducing False Positives

In code review and analysis, few-shot examples pull double duty: they show both what to flag and what to ignore. Examples that separate acceptable code patterns from genuine issues cut false positives while still catching the 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, reducing false positives while preserving the ability to generalise to genuinely problematic shadowing cases.

Few-Shot vs Other Techniques

The exam tests whether you can distinguish when few-shot examples are the right solution versus when another technique applies:

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

Practice Scenario

Your extraction pipeline correctly identifies research data in structured tables but returns empty fields when the same information appears in narrative paragraphs. Detailed instructions already specify all required fields and their formats. What should you try first?

A. Add few-shot examples showing correct extraction from both structured tables and narrative paragraphs
B. Increase the model context window to process more of each document
C. Add a pre-processing step to convert all narrative text into structured tables before extraction
D. Add a post-processing retry that re-extracts any fields returned as empty

Answer & explanation

Correct: A

A — Few-shot examples demonstrating correct extraction from varied document structures directly address the inconsistency. The model needs to see what correct narrative extraction looks like.
B — The model already finds data in tables — context size is not the issue. The problem is inconsistent handling of different document structures, which a larger window will not fix.
C — This adds unnecessary infrastructure complexity. The model can handle varied formats when shown examples. Pre-processing creates maintenance burden and potential data loss.
D — Retrying without better guidance will produce the same empty results. The model needs examples of correct extraction from narrative text, not more attempts with the same prompt.

Sources

Claude Certified Architect Foundations Exam Guide — Task Statement 4.2 — Anthropic
Prompt Engineering Overview — Anthropic
Building with Claude API (Skilljar) — Anthropic

Exam Simulator

Six exam-style multiple-choice questions on Few-Shot Prompting. Pick an answer, then open the explanation.

Question 1

A. Increase the model’s context window to process more of each document
B. Add few-shot examples showing correct extraction from both structured tables and narrative paragraphs
C. Add a pre-processing step to convert all narrative text into structured tables before extraction
D. Add a post-processing retry that re-extracts any fields returned as empty

Answer & explanation

Correct: B

A is wrong because the model already finds data in tables — context size is not the issue. The problem is inconsistent handling of different document structures.
B is correct because few-shot examples demonstrating correct extraction from varied document structures directly address the inconsistency.
C is wrong because this adds unnecessary infrastructure complexity. The model can handle varied formats when shown examples.
D is wrong because retrying without better guidance produces the same empty results. The model needs examples of correct narrative extraction.

Question 2

Your code review tool flags variable shadowing as “critical” in one file and “minor” in another. The review instructions are detailed and specify severity criteria. What is the most effective fix?

A. Add more detailed severity criteria with longer descriptions
B. Add a confidence threshold and only report findings above 0.8
C. Increase the model temperature for more varied outputs and take the majority vote
D. Add 2-3 few-shot examples of variable shadowing at different severity levels

Answer & explanation

Correct: D

A is wrong because detailed instructions already exist. Adding more instructions will not fix inconsistent judgement calls — the model needs to see examples of correct classification.
B is wrong because confidence thresholds are poorly calibrated and do not address the root cause of inconsistent classification.
C is wrong because temperature increases randomness, and majority voting adds complexity without fixing the underlying judgement inconsistency.
D is correct because few-shot examples with reasoning teach the model consistent judgement for ambiguous cases. The reasoning helps generalise to novel shadowing scenarios.

Question 3

How many few-shot examples should you typically include for an ambiguous classification task?

A. 2-4 targeted examples covering the ambiguous scenarios only
B. 1 example to keep token usage minimal
C. 8-10 examples to comprehensively cover all possible cases
D. As many as will fit in the context window for maximum coverage

Answer & explanation

Correct: A

A is correct because 2-4 examples establish a pattern without wasting tokens. Target them at the specific ambiguous scenarios causing problems.
B is wrong because a single example does not establish a pattern. The model cannot generalise from one case.
C is wrong because more than 4 examples waste tokens without proportional benefit. Diminishing returns set in quickly.
D is wrong because filling the context with examples crowds out the actual task and reduces output quality.

Question 4

What is the critical difference between few-shot examples that teach pattern-matching versus those that teach generalisation?

A. Pattern-matching examples use structured data; generalisation examples use unstructured text
B. Pattern-matching examples use 2 examples; generalisation examples use 4 or more
C. Pattern-matching examples show input-output pairs, while generalisation examples add the reasoning
D. Pattern-matching examples are for extraction tasks; generalisation examples are for classification tasks

Answer & explanation

Correct: C

A is wrong because the data format does not determine whether the model learns to generalise.
B is wrong because the number of examples does not determine generalisation ability — the presence of reasoning does.
C is correct because examples without reasoning teach the model to match specific patterns (“order numbers go to lookup_order”). Examples with reasoning teach the general principle (“specific identifiers route to specific lookup tools”), enabling generalisation to novel patterns.
D is wrong because both extraction and classification tasks can benefit from either approach.

Question 5

Your extraction system produces malformed JSON (missing brackets, trailing commas) in approximately 5% of responses. Which technique should you apply?

A. Add few-shot examples showing correctly formatted JSON output
B. Use tool_use with JSON schemas to eliminate syntax errors entirely
C. Add a JSON validation step that retries on malformed output
D. Increase max_tokens to ensure the model has space for complete JSON

Answer & explanation

Correct: B

A is wrong because few-shot examples address consistency, not structural compliance. They reduce but do not eliminate JSON syntax errors.
B is correct because tool_use with JSON schemas eliminates JSON syntax errors entirely at the API level. This is the reliability hierarchy: tool_use for structure, few-shot for consistency.
C is wrong because retrying adds latency and cost. Preventing the error at the API level is superior.
D is wrong because truncation may contribute to some malformed output, but tool_use is the definitive fix for syntax errors.

Question 6

A financial report presents expenses in a table on page 1 and in a narrative paragraph on page 3. Without few-shot examples, the model extracts correctly from the table but fabricates values from the narrative section. What explains this behaviour?

A. The model’s context window cannot reach page 3
B. The model lacks training data for financial narrative extraction
C. The model prioritises table data and ignores narrative text by default
D. It fabricates instead of leaving fields empty

Answer & explanation

Correct: D

A is wrong because page 3 is typically within context window limits for standard documents.
B is wrong because the model has broad training data. The issue is task-specific guidance, not general capability.
C is wrong because the model does not have a built-in preference for tables. The inconsistency comes from lacking demonstration of correct narrative extraction.
D is correct because few-shot examples showing correct extraction from narrative text teach the model how to handle structural variety. Without them, the model may fabricate values rather than correctly extracting from unfamiliar formats.