4.2 Few-Shot Prompting

Lesson 4.1 made your instructions explicit. But sometimes even careful, explicit instructions still produce inconsistent results — the format drifts, the judgment on tricky cases wobbles, or extraction misses information that's clearly present. Task Statement 4.2 introduces the single most effective tool for these problems: few-shot prompting, which means giving Claude a few worked EXAMPLES of input and the exact output you want.

It's the difference between describing a dance and demonstrating it. You can write paragraphs about the footwork, but one demonstration conveys what words can't — the timing, the feel, the exact form. Few-shot examples are that demonstration for Claude: instead of telling it what good output looks like, you SHOW it two to four times, and it picks up the pattern far more reliably than from instructions alone. When detailed instructions aren't getting you consistent, actionable output, few-shot is the upgrade.

Crucially, few-shot is THE most effective technique for consistency — more effective than adding yet more instructions, than confidence thresholds, or than fiddling with temperature. The exam tests that you reach for examples (not those other levers) when consistency is the problem. Let's cover when to use it and how to construct examples that actually teach.

How do you know it's time to reach for few-shot rather than another technique? Three symptoms signal it, and recognizing them is what the exam tests.

• 1.Inconsistent FORMATTING. Your detailed instructions are clear, yet the output's structure varies run to run. Examples pin down the exact format (the location/issue/severity/fix shape you want).
• 2.Inconsistent JUDGMENT on ambiguous cases. The model decides borderline cases differently each time — which tool to use for an ambiguous request, whether a subtle coverage gap counts. Examples show how to judge the ambiguous ones.
• 3.Empty/null extraction of info that EXISTS. The model returns nothing for a field whose value is actually present, just expressed unusually (a measurement buried in narrative text, a date in prose). Examples teach it to recognize the information in varied forms.

Not all examples are equally useful. The construction matters, and getting it right is the difference between examples that teach generalization and examples the model just copies superficially.

Three construction rules. First, use 2 to 4 TARGETED examples — enough to establish the pattern, focused on the scenarios that are actually failing (don't pad with easy cases). Second, and most important: each example should show the REASONING, not just the answer. An example that explains WHY one tool was chosen over a plausible alternative teaches the model to generalize the judgment to new cases; an example that shows only the final output invites surface pattern-matching. Third, cover the FAILING scenarios specifically — if extraction breaks on narrative-style documents, include a narrative-style example.

This is the deepest point in the lesson, and the exam tests it: few-shot examples are NOT about literal pattern-matching. Done well, they teach the model to GENERALIZE judgment to novel patterns it hasn't seen. That's why showing reasoning matters — you're teaching the decision process, not memorizing input-output pairs. The same mechanism reduces hallucination in extraction (show what real data looks like in varied forms) and reduces false positives (show what to flag AND what to deliberately ignore).

Domain 4 has several tools, and the exam loves to test whether you pick the RIGHT one for a symptom. Few-shot is powerful but not universal — here's how it slots in against the others you'll meet.

The discriminator: few-shot fixes CONSISTENCY and JUDGMENT problems. It is NOT the fix for guaranteed JSON structure (that's tool_use, 4.3), for stopping fabrication of absent data (nullable fields, 4.3), or for catching arithmetic errors (validation-retry, 4.4). When the symptom is 'it's inconsistent' or 'it judges ambiguous cases differently each time,' few-shot; when it's a structural or semantic guarantee, look to the next lessons.

The 4.2 traps test whether you reach for examples on consistency problems, and whether you understand examples teach generalization (not copying). The recurring distractor is 'add more instructions.'

• •More instructions for inconsistency. ✗ Adding yet another paragraph of detail when output is inconsistent. ✓ Provide 2–4 examples — they outperform more prose.
• •Confidence/temperature for consistency. ✗ Reaching for confidence thresholds or temperature to fix wobbling judgment. ✓ Few-shot examples showing how to decide.
• •Treating examples as literal patterns. ✗ Believing the model only matches the exact examples shown. ✓ Well-built examples (with reasoning) teach it to generalize to novel cases.
• •Few-shot for the wrong symptom. ✗ Using few-shot to guarantee JSON structure or stop fabrication. ✓ That's tool_use + nullable schema (4.3).

You now know when to use few-shot, the three triggers, how to construct examples that teach generalization, and how few-shot fits among the other Domain 4 techniques. The exercise has you fix each trigger with examples and prove that reasoning-rich examples generalize.

Few-shot makes output consistent by demonstration. The next lesson, 4.3, tackles a different guarantee: STRUCTURE — using tool_use and JSON schemas to make output reliably machine-parseable.