Examples

You can describe the answer you want. You can also show it.

An example is one finished piece of the answer, written the way you want. Say you want flashcards. You write one card as “Q: question” and “A: answer”. Then you ask for more like it.

Lesson 2.1 shows how to say clearly what you want. Lesson 2.5 shows how to ask for a shape or a reading level. This lesson is about showing one.

Brown and others (arXiv, submitted 28 May 2020, version 4 revised 22 July 2020) tested a language model called GPT-3 by putting examples in the request. They call this the few-shot setting: “the model is given a few demonstrations of the task at inference time as conditioning”. Inference time means when the model answers. They add “but no weight updates are allowed”. Weight updates would change the model’s numbers, as in lesson 1.7. Nothing is retrained. The examples are part of the request, so they use up room in the context window (lesson 1.8). The paper “typically” set the number of examples between 10 and 100, “as this is how many examples can fit in the model’s context window”. Lesson 5.6 will cover when to prompt and when to train.

The paper also gives a reason to show, not only tell: “By contrast it is sometimes difficult to communicate the content or format of a task if no examples are given.” Its abstract says few-shot performance was “sometimes even reaching competitiveness with prior state-of-the-art fine-tuning approaches”.

The limits: these are findings about GPT-3, on that paper’s tests, from 2020. The paper did not test Claude or Ministral.

This lesson uses one task. A model turns six lines of notes into flashcards. The notes come from lesson 1.3 on tokens. They say what a token is, and how one tokeniser cuts the word “strawberry”.

Two requests were recorded. Request A is the notes and the words “Turn these notes into flashcards”. Request B adds two example cards and the words “Use exactly this format”.

Request A says nothing about the format. So these runs cannot say whether the words or the examples did the work in request B.

Each request went to two models, three times each. The models are Claude Sonnet 5.5 and Ministral 3 14B. They were recorded on 3 October 2026. That gives twelve answers.

The two example cards are about Ireland, not tokens. Each has one small quirk. Card 1 starts its answer with a small letter and has no full stop. Card 2 ends its answer with a full stop.

In the activity below, you predict which request gives plain Q and A lines with nothing added. Then you see the answers side by side.

Settings, as recorded: no tools, no system prompt, a limit of 4000 tokens for each answer. No temperature was sent, so each model used its own default. The same request can give different answers in different runs, so each was sent three times.

The two models come from two makers. Claude Sonnet 5.5 was called through Anthropic’s API. An API is a way for one program to send a request to another. Ministral 3 14B was called through Mistral AI’s API.

The recording is one task, in one wording, on one day. It does not test examples in general.

Claude Sonnet 5.5, request A, with no examples: all three answers had a title and bold labels. Each card was headed “Card 1” and so on. All three added fill-in-the-blank cards too.

Claude Sonnet 5.5, request B, with examples: all three answers were plain Q and A lines. They had no title, no bold and no extra note.

Ministral 3 14B, request A: all three used the words Front and Back, not Q and A. Each opened with a line of its own. One ended by asking if you want changes.

Ministral 3 14B, request B: all three used Q and A labels. But none gave plain lines. Each opened with “Here are your flashcards in the requested format:”. Each put bold on the labels and a line of dashes between cards.

So the examples fixed the shape for Claude Sonnet 5.5 in all three runs. For Ministral 3 14B they did not fix it in any run, though its answers moved closer.

Bold here means the reply holds Markdown stars, which many chat apps show as bold. “Plain” means every line starts with “Q: “ or “A: “ and nothing else is in the reply.

Claude Sonnet 5.5, request A: run one had eight cards, the last two fill-in-the-blank. Runs two and three had six cards and then a list headed “Optional cloze versions”. Request B, runs one to three: six cards each and no extras.

Ministral 3 14B, request A: all three spelled the word “tokenizer” with a z. The notes spell it “tokeniser”. In request B, all three used the notes’ spelling, “tokeniser”.

What this does not show: why Ministral 3 14B added its extras, or whether another wording of the request would remove them. Only one wording was recorded.

The two example cards disagreed on purpose. Card 1 had a small first letter and no full stop. Card 2 had a capital letter and a full stop.

Did the answers copy a quirk? For most runs, we cannot tell. Without examples, both models already wrote capital letters and full stops. So copying card 2 would look the same as not copying.

One run did differ. In Claude Sonnet 5.5’s first run with examples, every answer ended with no full stop. All but one began with a small letter. That is card 1.

To fit card 1, the model reworded the notes. One answer began “a small piece of text, such as a whole word”. The notes word it differently.

So one run matched a quirk of card 1: the first of Claude Sonnet 5.5. We cannot say why it differed from its other runs. Its runs two and three matched card 2, which is also what it wrote without examples.

Counts, by run, for the six answers in each reply. Claude Sonnet 5.5, request B: run one, five answers began with a small letter and none ended with a full stop; the sixth was “Yes”. Runs two and three, six capitals and six full stops. Ministral 3 14B, request B: all three runs, six capitals and six full stops. Without examples, Claude Sonnet 5.5’s six plain cards had capitals and full stops in all three runs.

Other sources say what to do about this. Anthropic’s page says examples should be “Diverse: Cover edge cases and vary enough that Claude doesn’t pick up unintended patterns” (Anthropic’s advice for its Claude models, read on 3 October 2026). Google’s page says: “Make sure that the structure and formatting of few-shot examples are the same to avoid responses with undesired formats.” That is Google’s advice for its Gemini models, on a page dated 17 September 2026. The two cards here broke that rule on purpose.

Three papers on older GPT models show the same kind of sensitivity. Min and others (EMNLP 2022) found that “randomly replacing labels in the demonstrations barely hurts performance” on classification and multi-choice tasks, across 12 models including GPT-3. They say the demonstrations matter for “the label space”, “the distribution of the input text” and “the overall format of the sequence”. That is classification, not writing flashcards. Zhao and others found that “the choice of prompt format, training examples, and even the order of the training examples can cause accuracy to vary from near chance to near state-of-the-art” for GPT-3. Lu and others (ACL 2022) found that order alone “can make the difference between near state-of-the-art and random guess performance”, and that a good order for one model is not transferable to another. No run here changed the order of examples.

An example can guide the shape of an answer. It does not make the facts right. A better request does not guarantee a true answer.

Look at what Ministral 3 14B added. With no examples, all three answers gave other ways to cut “strawberry”. They wrote “straw-berry” and similar cuts. The notes do not say that.

With examples, those extra cuts were gone. But one answer said each token takes up space in the model’s memory. The notes say only that more pieces fill up the room a model has for text.

Nothing in this lesson checked those extra claims. So read the content, not only the shape. Lesson 2.6 shows how to ask again and check. Lesson 4.1 shows how to check an answer against real sources.

Every answer in this recording was compared with the six notes by the writer. Claude Sonnet 5.5’s six plain cards stayed inside the notes in all six runs. Where a run adds a claim, that run’s note says so. None of the added claims was found false by this lesson’s writer, and none was checked against a source, so they are called “not in the notes”, not “wrong”.

Companies say examples help. OpenAI says few-shot learning “lets you steer a large language model toward a new task by including a handful of input/output examples in the prompt, rather than fine-tuning the model”. Anthropic says: “Examples are one of the most reliable ways to steer Claude’s output format, tone, and structure.” Google says: “We recommend to always include few-shot examples in your prompts.” Each is that company’s advice for its own models, read on 3 October 2026. This lesson’s recording tests one task and does not confirm or refute any of them.

Suppose you ask for the same kind of thing often. Keep your best example. Paste it in each time. A saved example you reuse is a template.

How many examples? Anthropic advises three to five for its Claude models. Google warns that too many can make a model copy the examples too closely. These runs used two. So they say nothing about the right number.

Lesson 2.7 shows how to write a repeated task down as a procedure.

PromptSage is a prompt framework by Emanuel Covasa, written up as a paper that is not yet published. This lesson shows how a finished reply can guide an answer; PromptSage keeps reusable reply examples in named parts. It splits a prompt into seven labelled layers, each written between XML tags, such as <identity> and </identity>. The opening and closing tags mark where each part starts and ends.

Disclosure: PromptSage was created by Emanuel Covasa, who also created this site.

Anthropic says XML tags help Claude read a prompt that mixes instructions with other content, such as context, examples and inputs. It says wrapping each kind of content in its own tag “reduces misinterpretation” (read on 4 October 2026). This is its advice for Claude, not a guarantee. You can learn more about XML tags in Anthropic’s guide (opens in a new tab), a free page on a different website, written for developers.

PromptSage is one worked framework for writing prompts, not a standard. Templates are not a layer of it. They are parts of two layers, and the paper’s outline lists them as tags inside the prompt. response_templates sits inside each mode in layer 4, Mode Control. refusal_templates sits in layer 5, Behavioral Protocols. The outline shows response_templates only as an empty tag. The paper fills in only the refusal templates.

A refusal template is a scripted reply that the prompt tells the model to give when a trigger happens. The paper says: “Scripted refusal responses improve consistency and empathy when rejecting manipulation attempts”. Its first example, for a student asking for an answer in examiner mode: “I understand this is challenging. In examiner mode, I assess your knowledge rather than provide answers. Please share your best attempt, and I’ll evaluate it.”

That is the same idea as this lesson, kept for reuse: one finished reply, written the way you want, that the model is shown. The risk from this lesson applies too: an answer may match an example’s quirks, as one run did here.

The paper’s own limits: “All prompt-level constraints are advisory, not absolute.” and “Current findings are based on controlled testing rather than large-scale deployment.” This lesson tested no template.