Esempi per formato e casi limite

Instructions tell Claude what to do. Examples show it exactly what the output should look like.

Few-shot prompting means dropping 2-4 targeted examples into your prompt. The model generalizes from them - it doesn't just copy them back. In this lesson we use examples for two jobs: pinning the output shape and clarifying tricky edge cases.

These two jobs are where few-shot earns its keep: consistency, output format, and reducing hallucination on the weird inputs.

Imagine you ask Claude to extract a date. Sometimes you get 2026-06-10, sometimes June 10, 2026, sometimes 10/06/2026. Every variation breaks the code that consumes the output.

A prose instruction like "return the date" is ambiguous. Vague guidance produces vague consistency. The fix is to show the exact shape you want instead of describing it.

Put a couple of input/output pairs in the system prompt. The model locks onto the format of the outputs and reproduces it for new inputs.

Notice each example pins the same structure: ISO date, uppercase status, no extra commentary.

Explicit criteria beat vague pleas. "Be more consistent" or "format it nicely" gives the model nothing to anchor on.

Compare two ways to ask for the same thing:

• Vague: "Return the status in a clean format."
• Concrete: show two outputs that are both {"status": "GO"} / {"status": "PENDING"}.

The concrete version removes the guesswork. The model sees the target and hits it.

Examples make the shape likely. A JSON Schema via tool_use makes it guaranteed - it eliminates syntax errors and enforces required fields.

Setting tool_choice to "any" forces the model to call some tool, which guarantees you get structured output instead of free text. Use few-shot examples to clarify the content, and the schema to lock the structure.

A schema is only safe if you mark fields correctly. The rule: mark a field required ONLY if it is always present.

If you require a field that may be absent from the source, the model will fabricate a value to satisfy the schema. That is a silent data-quality bug.

In the example above, date and status are always derivable, so they are required. status_detail may be missing, so it stays optional.

Now the second job: tricky boundaries. The default output covers the happy path. Edge-case examples teach the model what to do when the input is weird, incomplete, or doesn't fit.

Pick 2-4 examples that target the specific ambiguities you actually hit - not random samples. Each example should resolve one boundary the model would otherwise guess at.

The most common edge case: the answer simply isn't in the input. Distinguish a valid empty result (no data present) from an access failure (couldn't read the source).

Show an example where the field is absent and the model returns a sentinel like "OTHER" plus a detail - never an invented value.

Edge cases break rigid enums. An input that fits none of your categories forces the model to either fabricate a fit or crash the schema.

The extensible pattern: an enum plus an "other" value and a free-text detail field. This lets the model classify cleanly when it can, and gracefully overflow when the input is unexpected - without you re-deploying the schema.

A common mistake is treating few-shot like a lookup table - stuffing in 30 examples hoping to cover every input. The model generalizes from a few well-chosen pairs; it doesn't need an exhaustive list.

More examples also cost context, and long prompts suffer from lost-in-the-middle: the model attends most to the start and end, least to the middle. A bloated example block buries the very patterns you care about.

Keep it to 2-4 sharp, boundary-targeting examples.

Even with good examples, you may get a malformed result. Retry-with-feedback fixes format, structural, and arithmetic errors: resend the original input, the wrong output, and the exact validation error.

But know the limit: retry does not help when the information is simply absent from the source. No amount of re-prompting invents data that isn't there - that's an edge case your examples and schema should handle up front with an "OTHER"/empty path.

You are extracting invoices into JSON. Most invoices have a purchase_order number, but about 30% omit it. You add two few-shot examples to pin the output shape.

How should you handle the purchase_order field in your JSON Schema?

Key takeaways:

• Show, don't describe: 2-4 input/output pairs pin format far better than adjectives like "clean" or "consistent".
• Examples + schema: few-shot makes the shape likely; JSON Schema via tool_use (with tool_choice: "any") makes it guaranteed.
• Required only if always present: requiring a possibly-absent field forces fabrication.
• Use enum + "other" + detail for extensibility, and show an absent/empty example so the model never invents data.
• The model generalizes: a few sharp, boundary-targeting examples beat a bloated list that buries the pattern in the middle.
• Retry-with-feedback fixes malformed output, but not information that simply isn't in the source.