Formatting Examples in Few-Shot Prompts

Why Example Formatting Matters Choosing good examples (Lesson 28) decides what the model learns. Formatting decides whether the model can see the pattern clearly.

A few-shot prompt only works if the model can answer three questions from the layout alone:

Where does each example start and end? Which part of each example is the input, and which part is the output? Where is the real input, and where should the answer begin? If the formatting leaves any of these unclear, the model may merge examples, treat an example as the real task, copy example inputs into its answer, or continue writing more examples instead of answering.

Example of Poor Formatting Classify sentiment. Great course! positive The audio was bad, negative It covers the basics → neutral Projects were really useful Different separators (space, ,, →), inconsistent capitalization, and no line breaks make the pattern hard to recognize. It is not even clear that the last sentence is the input to classify.

The Same Examples, Well Formatted Classify the sentiment of each review as Positive, Negative, or Neutral.

Review: Great course! Sentiment: Positive

Review: The audio was bad. Sentiment: Negative

Review: It covers the basics. Sentiment: Neutral

Review: Projects were really useful. Sentiment: Every example has the same structure, labels mark input and output, blank lines separate examples, and the open Sentiment: at the end shows exactly where the answer goes.

Rule 1: Use Identical Labels in Every Example What to Do Use the same input and output labels, with the same spelling and capitalization, in every example and in the real input.

Why It Matters The labels are the "skeleton" of the pattern. If one example uses Review: and another uses Text:, the model may not recognize them as the same structure, or it may think the label itself carries meaning.

Example Inconsistent:

Input: I can't log in Category: Access

Ticket: Charged twice Label: Billing

Message: Video freezes Category: Consistent:

Ticket: I can't log in Category: Access

Ticket: Charged twice Category: Billing

Ticket: Video freezes Category: Rule 2: Separate Examples Clearly What to Do Put a clear separator between examples: a blank line, a line of dashes, numbered headings, or XML-style tags.

Why It Matters Without separation, multi-line inputs and outputs can merge into each other, and the model cannot tell where one example ends.

Separator Options Separator Best For Blank line Short, single-line inputs and outputs --- line Multi-line content where blank lines might appear inside examples Example 1:, Example 2: headings When you want to refer to examples by number ... tags Multi-line or complex examples; the clearest boundaries Rule 3: Use XML-Style Tags for Complex Examples When inputs or outputs span several lines, contain blank lines, or include code, XML-style tags give unambiguous boundaries.

Write a one-sentence commit message for each code change.

• def get_price(course):
• return prices[course]
• def get_price(course):
• return prices.get(course, 0) Return 0 instead of raising KeyError for unknown courses

• @login_required def dashboard(request): Require login to access the dashboard

• timeout = 5
• timeout = 30 Explanation wraps the whole set, clearly separating examples from the real input that follows. Each contains one complete input-output pair. and mark the input and output inside each example. The real input uses the same tag, and the prompt ends with an open tag, which acts as an output cue. There is nothing special about these tag names. Choose descriptive names and use them consistently (Lesson 9).

Rule 4: Mark Examples as Examples What to Do Make it explicit that the examples are demonstrations, not data to process or facts to use.

Why It Matters Without this, the model may:

Treat example inputs as part of the actual task, for example by summarizing all the example texts. Use facts from examples as if they apply to the real input. Answer one of the example inputs instead of the real one. Example Instruction The examples below show the expected format and style. They are not part of the input. Apply the same pattern only to the text in . This is especially important when examples and real inputs are about similar topics, such as example tickets and real tickets.

Rule 5: End With a Clear Output Cue What to Do After the real input, end the prompt with the output label from the examples, left empty.

Why It Matters The open label tells the model that the next text should be the output for the real input, in the same form as the example outputs. Without it, the model may:

Write a new example input and continue the pattern indefinitely. Add an explanation before the answer. Repeat the real input. Example Review: Projects were really useful. Sentiment: In API calls that use message pairs (Lesson 26, Method 2), the output cue is implicit: the next message is the assistant's reply, so no open label is needed.

Rule 6: Match the Exact Output Format in Every Example What to Do Example outputs must use the precise format you want, including capitalization, punctuation, spacing, and any surrounding text, or the absence of it.

Why It Matters The model copies the output format very precisely. If one example output is Positive and another is positive., the model may produce either. If example outputs include explanations, real outputs will too.

Checklist for Example Outputs Same capitalization of labels Same punctuation (or none) Same JSON key order and formatting, if JSON No extra commentary unless commentary is part of the desired output Same length range as desired outputs Formatting Styles Compared Different formats suit different tasks.

Input/Output Labels Input: The class is at 6 PM. Output: வகுப்பு மாலை 6 மணிக்கு. Best for: Simple transformations and short outputs.

Question/Answer Q: What does HTTP 404 mean? A: Not Found

Q: What does HTTP 401 mean? A: Best for: Short factual answers (Lesson 9).

Domain-Specific Labels Ticket: Charged twice for the course Category: Billing Best for: Most practical tasks. Domain labels tell the model what kind of data it is reading.

XML Tags Best for: Multi-line inputs, code, documents, and outputs with structure.

JSON Lines {"review": "Great course!", "sentiment": "Positive"} {"review": "Audio was bad.", "sentiment": "Negative"} {"review": "Projects were useful.", "sentiment": Best for: Data-processing tasks where you want JSON output. Note the trade-off: ending with an incomplete JSON object works as a cue in plain completion settings, but in chat models it can result in a response that only contains the rest of the object. It is usually simpler to ask for complete JSON objects (Lesson 31).

Conversation Turns (API) Examples as alternating user and assistant messages.

Best for: Applications where the reply format must be exact and the model should behave as if it had already answered correctly several times.

Choosing a Style Task Recommended Format Short classification Domain-specific labels Short transformations Input/Output or domain labels Factual Q&A Q/A Code, documents, multi-line text XML tags Structured data output Complete JSON objects in example outputs API with strict reply format Conversation turns Building Formatted Examples in Code Writing examples by hand invites inconsistencies. Generating the example block from data guarantees that every example uses the same format.

EXAMPLES = [ { "change": "- timeout = 5\n+ timeout = 30", "commit_message": "Increase request timeout to 30 seconds", }, { "change": "+ @login_required\n def dashboard(request):", "commit_message": "Require login to access the dashboard", }, ]

def wrap(tag: str, content: str) -> str: return f"<{tag}>\n{content}\n</{tag}>"

def build_examples_block(examples: list[dict]) -> str: parts = [] for example in examples: inner = wrap("change", example["change"]) + "\n" + wrap( "commit_message", example["commit_message"] ) parts.append(wrap("example", inner)) return wrap("examples", "\n\n".join(parts))

def build_prompt(change: str) -> str: return ( "Write a one-sentence commit message for the code change in the final .\n" "The examples show the expected style only; they are not part of the input.\n\n" f"{build_examples_block(EXAMPLES)}\n\n" f"{wrap('change', change)}\n" "" )

print(build_prompt("- MAX_UPLOAD_MB = 5\n+ MAX_UPLOAD_MB = 20")) Output:

Write a one-sentence commit message for the code change in the final . The examples show the expected style only; they are not part of the input.

• timeout = 5
• timeout = 30 Increase request timeout to 30 seconds

• @login_required def dashboard(request): Require login to access the dashboard

• MAX_UPLOAD_MB = 5
• MAX_UPLOAD_MB = 20 Code Explanation EXAMPLES Examples are stored as dictionaries with consistent keys. Adding a new example means adding data, not editing prompt text.

wrap(tag, content) A single function produces every tag pair, so opening and closing tags always match and always follow the same layout.

build_examples_block() Builds each from its parts and wraps them all in . Because every example passes through the same code, formatting cannot drift between examples.

build_prompt()

States the task and that the examples illustrate style only. Refers to "the final " so the model knows which change is the real input. Ends with an open tag as the output cue. Handling Input That Contains Your Tags If real input could contain text such as , it could break the structure. For untrusted input, choose tag names unlikely to appear in the data, or remove or escape such sequences before inserting the input. This also relates to prompt injection risks covered in the Prompt Safety section.

Formatting Examples With Reasoning When the output includes reasoning, the examples must show both the reasoning and the final answer in a fixed structure.

Paid yesterday but the course still says "Enroll now". The payment succeeded, but enrollment did not update. Payment-received-but-locked cases are Access. Access The separate and tags allow your code to extract the category reliably while keeping the reasoning available for review. Examples with reasoning steps are the basis of few-shot Chain-of-Thought prompting (Lesson 41).

Common Mistakes Mistake 1: Inconsistent Labels or Separators What it is: Different labels, separators, or capitalization across examples.

Why it happens: Examples are written at different times or copied from different sources.

What it causes: The model does not recognize a single pattern, and output formats vary.

How to fix it: Generate the examples block from data in code.

Mistake 2: No Output Cue What it is: Ending the prompt with the real input and nothing after it.

Why it happens: It seems obvious that an answer should follow.

What it causes: The model may write another example, explain its approach, or restate the input.

How to fix it: End with the empty output label or an open tag.

Mistake 3: Examples Mistaken for Input What it is: The model summarizes, classifies, or answers using example content.

Why it happens: The prompt does not distinguish demonstration from data.

What it causes: Incorrect outputs that include content from examples.

How to fix it: Wrap examples in a container tag and state that they are demonstrations only.

Mistake 4: Example Outputs With Extra Text What it is: Example outputs such as Category: Billing, because the user mentions a refund. when only the label is wanted.

Why it happens: Explanations were added to help the reader of the prompt.

What it causes: Real outputs include explanations, which breaks parsing.

How to fix it: Keep example outputs in exactly the desired form. Put explanations for human readers in comments outside the prompt.

Best Practices Use one structure for every example and the real input. Identical labels, order, and separators.

Separate examples clearly. Blank lines for short examples, XML tags for complex ones.

Wrap the example set and label it as demonstrations. Prevent examples from being treated as input.

End with an output cue. An empty label or open tag tells the model exactly where to answer.

Make example outputs exact. The model copies their format precisely.

Choose the format style for the task. Domain labels, Q/A, XML, JSON, or conversation turns.

Generate examples from data in code. It guarantees consistency and makes examples easy to maintain.

Try It Yourself Exercise 1: Fix the Formatting Rewrite this prompt so the pattern is completely consistent:

translate to hindi english: good morning -> hindi: सुप्रभात English - Thank you | Hindi - धन्यवाद EN: See you tomorrow Add an instruction, consistent labels, separators, and an output cue.

Exercise 2: Compare Formats Build the same 4-example ticket classifier in three formats: domain labels, XML tags, and conversation turns via the API. Run each on 15 test tickets and compare accuracy and how often the output contains anything other than the label.

Exercise 3: Extend the Builder Modify build_examples_block() so each example can include an optional reasoning field, wrapped in tags only when present. Then write code that extracts only the text between and from a model response.