Few-Shot zur Verringerung von Halluzinationen

When you ask Claude to extract data from a messy document, the biggest risk is hallucination: the model invents a plausible value to fill a field instead of admitting the value is absent.

This happens most when your instructions are vague, when the desired output format is ambiguous, or when edge cases (missing fields, conflicting numbers) aren't addressed. A vague prompt like "extract the invoice details" leaves the model guessing.

In this lesson you'll learn to ground extraction with concrete examples so the model copies real source values instead of fabricating them.

Few-shot prompting means giving Claude 2-4 targeted examples of input paired with the exact output you want. The model generalizes from these examples — it does not merely repeat them.

Few-shot is the recommended technique for four things: consistency, edge cases, output format, and reducing hallucination. Our focus today is the last one.

The key idea: a well-chosen example that shows how to behave when data is missing teaches the model far more reliably than a sentence of instruction.

Before adding examples, sharpen your instructions. Explicit criteria beat vague ones every time.

Vague: "be accurate" or "extract carefully." Explicit: "copy values exactly from the source; if a field does not appear, return null."

Examples then demonstrate that rule in action. Instructions tell; few-shot examples show. Together they leave the model almost no room to invent.

The single most powerful anti-hallucination example is one where a field is genuinely absent in the input and the expected output shows null.

Below, the source has no email. The example output models the correct behavior: leave it null rather than guess a domain.

Two or three such examples teach the model to prefer "not present" over a fabricated value.

Few-shot examples live in the messages array as alternating user/assistant turns, before the real input. Remember: the model keeps no state, so you send the full message list every request.

The shots prime the pattern; the final user turn is the document to extract.

Few-shot reduces hallucination; tool_use with a JSON Schema eliminates syntax errors and enforces required fields. Use them together.

Set tool_choice to "any" to guarantee the model returns structured output instead of prose. The examples still teach what to extract; the schema guarantees the shape.

A critical schema rule that directly fights hallucination: mark a field required only if it is always present.

If you require a field that may be absent, the model is forced to produce something — and it will fabricate a value to satisfy the schema. That is hallucination caused by your own schema.

Above, only name is required. email and phone are optional and nullable, so the model can faithfully report their absence.

Pick examples that target your specific ambiguities, not random documents. Two to four shots per ambiguity is the sweet spot.

For grounding extraction, useful shots include:

• A field that is missing → output null.
• An ambiguous value (e.g. two phone numbers) → show the disambiguation rule.
• A tricky format (date written three ways) → show the normalized output.

The model generalizes the underlying rule to unseen documents.

For numeric extraction, hallucination often hides in arithmetic. A strong pattern is to extract both the calculated_total and the stated_total, then compare them to detect discrepancies.

A few-shot example can demonstrate this dual-extraction so the model learns to surface mismatches instead of silently "fixing" the math.

Pair few-shot with retry-with-feedback for robustness, but know its limits.

Retry fixes format, structural, and arithmetic errors: resend the original document, the wrong output, and the exact validation error, and the model self-corrects.

Retry does NOT help when the information is simply absent from the source. No number of retries conjures a missing value — that's where your nullable schema and few-shot "null" examples do the real work.

Grounding isn't only about avoiding invented values — it's about being able to trace each claim to its source.

For extraction at scale, keep claim→source mappings (the quote, doc name, or location the value came from). A few-shot example can show the model attaching a short source snippet to each field, making fabricated values obvious because they'd have no supporting quote.

This provenance habit is what separates an auditable extraction pipeline from a black box.

Key takeaways for grounding extraction:

• Few-shot examples (2-4) teach the model to generalize, not just repeat — best for consistency, edge cases, format, and reducing hallucination.
• The strongest anti-hallucination shot shows a missing field mapped to null.
• Pair examples with explicit criteria: "copy exactly; absent → null; never infer."
• Use tool_use + JSON Schema for structure, with tool_choice: "any" to force it. Mark a field required only if always present — never require a possibly-absent field.
• Extract calculated vs stated totals to catch numeric errors; keep provenance for auditability.
• Retry-with-feedback fixes format and math errors — but never recovers data that is simply absent.