Few-Shot Examples and XML Structuring

Two techniques do more to improve output consistency than any other: showing examples of the desired output, and wrapping the parts of a prompt in XML tags so that instructions, data and examples cannot be confused with one another. They are cheap, model-agnostic and compound well with every other technique. The exam tests how to construct examples that help rather than mislead, and how XML tags make prompts robust.

Why examples work

A description of a format is ambiguous in ways the writer cannot see. An example is not. Three to five well-chosen examples (sometimes called multishot or few-shot prompting) communicate tone, length, structure, edge-case handling and the boundary between acceptable and unacceptable output far more precisely than prose. They are particularly effective for classification, extraction, rewriting in a house style and any output that must be machine-parsed.

Constructing good examples

• Relevant. Examples should resemble real inputs in domain, length and difficulty. A toy example teaches the model to expect toy inputs.
• Diverse. Cover the variations that matter: a positive and a negative case, a short and a long input, an edge case where the rules bite. If every example is a happy path, the model learns the happy path.
• Consistent. All examples must follow the exact format you want, including whitespace and punctuation. The model copies what it sees, including mistakes.
• Labelled. Wrap each in tags so the model knows where an example starts and stops, and whether it is an input, an output or a counter-example.
• Few. Beyond a handful, additional examples cost tokens and can anchor the model on surface features. Add an example to fix a specific observed failure, not speculatively.

Counter-examples ("here is a bad output and why") are useful when the model keeps making one mistake, but keep them clearly marked; an unlabelled bad example will be copied.

XML tags as structure

Claude is trained to pay attention to XML-style tags, and the Anthropic guidance recommends them for separating prompt components. Tag names are free-form; what matters is that they are consistent and descriptive.

<instructions>
Classify each support ticket into exactly one category from <categories>.
Respond with the category name only.
</instructions>

<categories>
billing, bug, feature_request, account_access, other
</categories>

<examples>
<example>
<ticket>I was charged twice this month.</ticket>
<category>billing</category>
</example>
<example>
<ticket>Can you add dark mode?</ticket>
<category>feature_request</category>
</example>
</examples>

<ticket>
{{TICKET_TEXT}}
</ticket>

Tags solve three problems. They stop the model from treating a pasted document as instructions, because the document is visibly inside <document> and the instructions are elsewhere. They let instructions refer to parts of the prompt unambiguously ("use the terms in <glossary>"). And they make it easy to ask for structured output ("put your reasoning in <thinking> and the answer in <answer>"), which can then be extracted with a trivial parser or cut off with a stop sequence.

Nesting is fine (<examples><example>...), and tags can be combined with Markdown inside their content. Avoid tag names that collide with words in the content or with tags the model uses itself in output.

Examples, tags and caching

Examples are usually static. Put them in the system prompt or at the start of the first user turn, before any cache_control breakpoint, so they are cached and paid for once. The variable input goes last, after the breakpoint.

Long documents

When the prompt includes long documents, place them at the top, before the instructions and the question, and wrap each in tags with metadata:

<documents>
<document index="1">
<source>contract_2024.pdf</source>
<document_content>...</document_content>
</document>
</documents>

Using only the documents above, answer: {{QUESTION}}

Asking the model to first extract relevant quotes into <quotes> and then answer in <answer> grounds the response and makes it verifiable. Document blocks in the API with citations enabled formalise this pattern.

When examples hurt

Examples can over-constrain. If the task is genuinely creative or the input space is wide, a rigid set of examples narrows the output and the model may force inputs into the nearest example's shape. Examples can also leak: a model shown five examples about one customer may mention that customer. Review examples for sensitive data and for unintended patterns, such as every example answer being roughly the same length.

Exam focus

• Few-shot examples communicate format and edge-case handling more precisely than descriptions; three to five relevant, diverse and consistent examples is the usual range.
• The model copies what it sees, so every example must be in the exact target format; counter-examples must be clearly labelled.
• XML tags separate instructions, data and examples, prevent pasted content being read as instructions and make output extraction trivial.
• Tag names are arbitrary but should be consistent and referenced by name in the instructions.
• Static examples belong before the cache breakpoint; variable input goes last.
• Long documents go at the top, wrapped in tags with metadata; quote-then-answer grounds the response.