Few-Shot Example Generator & Structurer
In the rollout of language models to production environments, the consistency of prompt instructions forms the dividing line between robust software and unreliable output. One of the most effective methods for steering the behavior of a Large Language Model (LLM) without fine-tuning the model is providing demonstrations within the context window. Few-shot prompting introduces in-context examples of input and expected output directly in the prompt, letting the model learn the desired transformation through pattern recognition. Read the in-depth article on few-shot prompting in practice to study the theoretical underpinnings of in-context learning and pattern recognition in large language models.
The effectiveness of few-shot examples hinges on the syntactic and structural clarity with which these examples are presented to the model. When examples are placed as unstructured, loose text blocks in a system prompt, there's a risk that the model won't correctly interpret the separation between instructions, examples, and the actual user input. In practice, this leads to hallucinations, example values leaking into the final answer, or automated data flows breaking. See the anchor article on choosing a prompt technique on community.llmnet.nl to determine whether your specific use case benefits from few-shot examples or whether zero-shot or chain-of-thought is more suitable.
This article covers the architecture and application of the Few-Shot Example Generator & Structurer. This client-side tool converts loose input-output pairs into a standardized XML or JSON block. By enforcing a fixed syntactic structure, in-context examples become easier for the inference engine to parse, easier for development teams to maintain, and better isolated from the actual runtime input.
The Problem with Unstructured Few-Shot Examples
Developers who start with few-shot prompting often use a naive layout. Examples are separated by simple blank lines or plain text labels like "Input:" and "Output:". This approach doesn't scale as the application grows, or when the input and output data themselves contain punctuation, colons, or multiple paragraphs.
There are three primary failure modes when using unstructured examples in production environments:
- Instruction Leak and Boundary Bleed: The model gets confused about where an example ends and where the actual instruction begins. This happens when the structure of the example is identical to the structure of the final question. As a result, the model may reproduce elements from the examples instead of processing the actual input.
- Syntactic Ambiguity with Complex Data Types: When the input consists of code snippets, JSON objects, or unstructured emails, internal colons or punctuation cause the simple "Input:" separator to blur. The model's attention mechanisms then assign incorrect weights to the boundaries of the example.
- Maintainability and Version Control: Non-standardized examples scattered across source code files make it challenging to roll out prompt changes. When there's no consistent separator syntax, every extension of the example set requires a manual review of the entire system prompt.
Eliminating these failure modes requires explicit, machine-detectable boundaries. By casting examples into a recognizable syntactic structure, the model's tokenizer cleanly cuts the examples off from the rest of the context.
Syntactic Choices: XML Tags versus JSON Arrays
XML tags and JSON arrays are the two most commonly used standards for structuring few-shot examples within a prompt. Both formats offer strict separation, but they differ fundamentally in token efficiency, readability for the model, and processing by developers.
Structured output is the technique in which a model is forced to generate answers according to a predefined structure. Check out the article on enforcing structured output in prompts to understand how syntactic choices in the prompt affect the eventual parseability of the model's response.
XML Tags (Recommended for System Prompts)
XML tags such as <examples>, <example>, <input> and <output> are recognized excellently by virtually all modern language models. Since large models have been extensively trained on HTML and XML code, the attention layers understand the hierarchical relationship between opening and closing tags without requiring extra instructions for this.
The advantages of XML markup in few-shot blocks are:
- Robustness against unescaped characters: Within an XML element, quotation marks, braces, and commas can be used freely without breaking the structure of the block, provided special XML characters (such as ampersands and 'less than' signs) are properly escaped or placed in CDATA sections.
- Clear domain separation: Closing tags such as
</example>provide an unmistakable resting point for the model. This reduces the risk of logic from one example bleeding into the next example. - Flexibility in metadata: Attributes can be added to XML tags, such as
<example id="1" category="edge-case">, which is valuable when analyzing model behavior during A/B tests.
JSON Arrays
JSON is the standard for data exchange in web applications. Including a JSON array of objects in a prompt has the advantage that the examples can be read and serialized directly from a database or configuration file.
Implemented format constraints require clear instructions in the prompt context. See the guide on enforcing output formats when you place specific requirements on data exchange such as JSON schemas, XML validation, or CSV export.
The drawbacks of JSON as a few-shot structure within a prompt involve the increased token overhead and sensitivity to syntax errors. Quotation marks and newline characters within the input or output text must be strictly escaped (\" and \n). When a developer makes a manual edit and forgets an escape character, the model's or the application's parser breaks.
| Property | XML Markup | JSON Array |
|---|---|---|
| Token Efficiency | Medium to High | Lower (due to brackets and escapes) |
| Resilience to special characters | Excellent | Sensitive to quotation marks |
| Parseability by LLM | New and existing models: Very high | High |
| Human maintainability | Excellent (visually separated) | Moderate for long texts |
| Suitability for code generation | Excellent | Moderate (a lot of escape overhead) |
Architecture of the Client-Side Tool
The Few-Shot Example Generator & Structurer is designed as a lightweight, client-side browser application. The tool's goal is to automate the manual construction of XML and JSON prompt blocks and eliminate human formatting errors. Because processing happens entirely in the user's browser (via JavaScript), no entered examples or sensitive data are sent to an external server.
The tool performs the following core functions:
- Pair input management: A dynamic interface where developers can add, reorganize, and remove an unlimited number of input-output pairs.
- Syntax conversion: With a single click, the entered set is converted into a cleaned-up XML block or a valid JSON structure.
- Automatic Escaping: Dangerous characters that could break the prompt structure are automatically converted to their respective HTML entities or JSON escape sequences.
- Boundary Marking Injection: The tool automatically adds a placeholder for the actual runtime input (for example
<current_input>), so the boundary between the examples and the actual question remains explicitly guaranteed.
Below is the interactive Few-Shot Example Generator & Structurer.
Concrete Artifact: Standardized XML Few-Shot Prompt Block
A well-thought-out few-shot prompt block doesn't just contain the examples themselves, but wraps them with clear instructions on how the model should interpret the examples. The code below shows the standardized XML artifact as produced by the generator.
In this artifact, an explicit separation was chosen between the system instruction, the examples container (<examples>), individual examples (<example>), and the box for the actual query (<current_input>). Optionally, a <reasoning>tag can be included within an example to combine chain-of-thought with few-shot prompting.
<system_instructions>
Je bent een gespecialiseerde data-transformator. Je taak is het verwerken van ongestructureerde klantnotities naar een gestructureerd JSON-formaat.
Analyseer de onderstaande voorbeelden om het gewenste uitvoerformaat en de extractielogica te begrijpen.
Neem de voorbeelden niet over in je uiteindelijke antwoord; verwerk uitsluitend de data binnen de <current_input> tags.
</system_instructions>
<examples>
<example id="1">
<input>
Klant: Jan Jansen (ID: 4821). Wil graag zijn abonnement opzeggen per 1 oktober vanwege verhuizing naar het buitenland.
</input>
<reasoning>
De klant geeft expliciet een opzegging aan met een duidelijke reden en datum. Klant-ID is aanwezig.
</reasoning>
<output>
{
"customer_id": 4821,
"action": "CANCELLATION",
"effective_date": "2026-10-01",
"reason": "RELOCATION_ABROAD"
}
</output>
<example>
<example id="2">
<input>
Inkomend bericht: Pietersen t.a.v. factuur 2026-991. Bedrag klopt niet, er is 50 euro te veel gerekend.
</input>
<reasoning>
Geen klant-ID genoemd, wel een factuurnummer. De actie betreft een factuurdispuut.
</reasoning>
<output>
{
"customer_id": null,
"action": "INVOICE_DISPUTE",
"reference": "2026-991",
"reason": "OVERCHARGE_CLAIM"
}
</output>
</example>
</examples>
<current_input>
Klant: Maria Bakker. Vraagt om een overzicht van haar laatste drie betalingen voor de administratie.
</current_input>
<output>By having the prompt end with an opening <output>tag, the model is encouraged to start generating the desired output immediately, without introductory pleasantries or repeating the question (assumption: prefilling the start of the response reduces the chance of unwanted introductory text by more than 90%).
Order, Boundaries, and Token Management in Production
Generating a valid XML or JSON block is the first step. To successfully run few-shot examples in production, three additional factors need to be taken into account: the order of examples, boundary isolation, and the token budget.
1. Order of Examples and Recency Bias
Large language models suffer from 'recency bias': examples located near the end of the prompt exert a stronger influence on the generated answer than examples at the beginning of the system prompt. When assembling an example set, the following guidelines should be applied:
- Spreading variants: Don't place all complex or unusual examples (edge cases) at the bottom. Alternate standard cases and edge cases.
- Class balance: For classification tasks, the number of examples per class should be evenly distributed. If a few-shot block contains four positive examples and only one negative example, the model will show a strong tendency to predict the positive class (assumption: skewed example ratios introduce a measurable class bias).
- Increasing complexity: Rank examples from simple to complex when using in-context reasoning steps (chain-of-thought). This builds up the desired logic for the model.
2. Boundary Isolation and Security
A common problem with AI applications that process external user input is 'prompt injection'. If a user enters text that contains closing tags (such as </current_input> or </example>), this can disrupt the structure of the prompt.
The generator catches this by validating input texts. In a production environment, the application code should sanitize all input within <current_input> by matching any XML tags that correspond to the boundary tags and switching them to HTML entities (such as < and >).
3. Token Budget and Cost Management
Every example added to a prompt increases the number of input tokens used on every API call. For applications processing large numbers of requests, unnecessarily long few-shot blocks can lead to a significant rise in operational costs and higher latency.
Use the prompt token counter to calculate exactly how much additional context overhead your few-shot examples add to every API call.
Once the optimal balance between number of examples and accuracy has been established, these blocks should be managed centrally. Store validated and optimized example sets in the central prompt library so that different applications and microservices reuse exactly the same standardized prompt blocks.
Validation and Transition to APIs and Benchmarks
While structured few-shot examples in the prompt drastically increase the reliability of a language model, it's important to recognize the limits of prompt-based steering. When an application requires 100% guaranteed JSON output for integration with critical backend systems, prompt engineering alone doesn't always offer sufficient guarantees.
In those situations, combining a structured few-shot block with a hard-enforced API schema is the most robust architecture. Check out the guide on structured output via API calls on api.llmnet.nl if you want to move from prompt-based formatting to hard schema validation enforced by the inference platform.
Finally, the decision to add few-shot examples — and how many examples is optimal — should not be made based on gut feeling. Adding three extra examples can increase accuracy on a specific task, but for a different model type it can actually cause overfitting to the style of the examples.
Use the test environment for A/B testing prompts on benchmark.llmnet.nl to quantitatively validate whether adding a structured few-shot block statistically significantly improves the accuracy and parseability of your application.
