Few-Shot Examples for Ambiguous Cases and Reliable Extraction

1.Resolving ambiguous choices with examples

Formatting is the easy case. The harder one is a request that could reasonably go two ways. The model has to decide something, and the right decision depends on context the instructions don't spell out. Anthropic's context-engineering post puts the bar plainly: if a human engineer can't say for certain which tool should be used, an agent can't be expected to do better.

Anthropic's advanced tool use post names this situation as one where examples help most: similar tools where examples clarify which one to use, such as create_ticket vs create_incident. Its advice on writing those examples is just as pointed: focus on ambiguity, and only add examples where correct usage isn't obvious from the schema. A schema can say what is valid. It can't say which of two valid choices fits a borderline request. The post warns that these gaps lead to malformed tool calls and inconsistent parameter usage.

The prompting guide's diversity rule applies here as well. If every example is an easy, unambiguous request, Claude learns nothing about the borderline. The example set should be built around the requests that actually split between the two tools.

Sources12

2.Examples that show why, not just what

An example that shows only the final choice teaches what to do. An example that also shows why this action beat a plausible alternative teaches the rule for deciding, and Claude can carry that rule to cases you didn't write. The prompting guide supports both halves. It says multishot examples work with thinking, so an example can include its reasoning and not just its answer. It also says that explaining why a behaviour matters helps Claude understand your goals and give more targeted responses.

How many examples? The exam guide's working number is two to four targeted examples. The sources give ranges in the same spirit rather than a single figure. The blog says to start with one example and add more only if needed. The tool-examples post suggests one to five per tool and says to aim them at ambiguity. The context-engineering post says to prefer a curated canonical set to an exhaustive list. In practice, each example should cover a different ambiguity and briefly state why the alternative was rejected.

This works for any judgement call, not only tool selection. Take a test-coverage reviewer that keeps missing untested branches. Show it an example where a function's tests cover the main path but skip one conditional branch, with reasoning that explains why that gap counts and a covered branch doesn't. That is an application of the principle. The sources don't discuss test coverage specifically.

Sources1

3.Separating acceptable patterns from genuine issues

Automated reviewers lose trust through false positives. A rule like 'flag pattern X' fires on every instance of X, including the many places where X is deliberate and correct. Writing more rules rarely helps, because what makes an instance acceptable is context that's hard to put into words.

Paired examples deal with this directly. Show one instance of the pattern that is acceptable, with a short reason, and one that is a genuine issue, with a short reason. The pair teaches the boundary between them, not the surface syntax. This is the diversity requirement in practice: vary the examples enough that Claude doesn't learn the unintended shortcut that this syntax always means a bug. Because Claude generalises from examples, the distinction carries over to code that looks nothing like the examples. That gives you fewer false positives without losing real findings.

Sources1

4.Extraction: showing the honest answer for vague input

In extraction, the expensive failure is fabrication: a confident, precise value where the source is vague or silent. Anthropic's guide to reducing hallucinations starts with letting Claude say it doesn't know. It describes explicitly giving Claude permission to admit uncertainty as a simple technique that can drastically reduce false information. The prompt-engineering blog says the same: give explicit permission to express uncertainty instead of guessing.

Permission tells Claude that an honest non-answer is allowed. An example shows what that non-answer looks like in your format, which is the job few-shot prompting does best. The summarization cookbook's output has this pattern. Where the lease didn't address utilities or maintenance, the summary records 'Not explicitly specified' rather than inventing terms or dropping the field.

The sources don't discuss informal measurements, such as a vague quantity in a free-text note. The principle carries over, though. Include an example in which the vague input is recorded faithfully, with the informal wording kept or uncertainty marked, rather than turned into a made-up number. That keeps usable information and blocks the fabrication.

Sources34

5.Varied document structures and empty required fields

The opposite failure is a required field that comes back empty or null even though the information is in the document. Usually it sits somewhere unexpected. A citation may appear inline instead of in a bibliography, or methodology may be woven into other sections instead of having its own heading. If every example in the prompt uses the 'standard' layout, Claude has only ever seen the field in one place.

The sources don't discuss citations or methodology sections specifically. The guidance that applies is the guide's first two properties. Relevant means the examples mirror the documents you really process. Diverse means they cover the edge cases. In practice, include an example of each structural variant you meet, with the required field correctly extracted from wherever it appears. The tool-examples post makes the matching point about variety: show minimal, partial and full specification patterns. Its create_ticket set includes a call with a title only, which teaches that a sparse but correct answer is valid.

      {
        "title": "Add dark mode support",
        "labels": ["feature-request", "ui"],
        "reporter": {
          "id": "USR-67890",
          "name": "Alex Chen"
        }
      },
      {
        "title": "Update API documentation"
      }

Taken together with the previous section, this gives a balanced example set. Some examples show a field found in an unusual place, which fixes false nulls. Others show a field truly absent and recorded honestly, which prevents fabrication. Wrap each one in its own <example> tag so Claude can tell the examples apart from the instructions.

Sources12

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.To eliminate empty fields, instruct the extractor that every field must always contain a value.Why is that wrong?

   Forcing a value where the source is vague pushes Claude to guess. The guidance is to allow uncertainty and show, by example, how to record it.

   Covered in Extraction: showing the honest answer for vague input

2. 2.Examples should cover the clear, typical requests for each tool so Claude learns the basics.Why is that wrong?

   Examples are most useful where the correct choice isn't obvious. A set made only of clear-cut cases teaches nothing about the borderline.

   Covered in Resolving ambiguous choices with examples