Few-shot: two tiny examples beat a speech

A few-shot is a small worked example you put in the prompt so the model copies the shape, not a lecture.

This post is how many examples to use, what they must contain, and how a bad example teaches the wrong thing.

One good example beats a speech

You want three bullets and a grounded flag.

A long instruction will still get you an essay some days.

One example:

notes: 36 of 40 classes. Rule is 75%.
bullets:
- 36 of 40 is 90%.
- That is above 75%.
- You can miss 8 more and stay at 75%.
grounded: true

The next call with new notes often follows that shape.

If you cannot show one filled object, you are not ready to ask for one.

What the example must have

The same fields you want back. A fail case too.

If you only show grounded: true, the model will avoid false. Add a second example with empty notes and grounded: false, empty bullets.

Two examples is a good start: one pass, one refuse.

Three is plenty. Ten is a stuffing problem. You will also freeze the model on your wording.

Keep examples short. If the example is longer than the real notes, you taught length, not shape.

Where they sit

Put few-shots in the system slot, or in a fixed block you control. Do not take examples from the user’s PDF. That is how injection becomes a “helpful” sample.

If the user can edit examples, they can teach a joke format. Your eval will catch that if you kept the planted-order case.

Walk through once

Build the notes helper with no examples. Run three inputs: good notes, empty notes, joke request. Write what you got.

Add the true example only. Run again. The good case gets cleaner. The empty case may still invent bullets. Add the false example.

Run the joke request. If it now returns three joke bullets in your shape, the shape was copied and the refuse was not. The false example must include the joke-like input, or your code must drop ungrounded bullets.

That last point matters. Few-shots teach format. They do not replace a check.

What good looks like

Two examples. You can read both in a minute.

The true one uses the same keys as the schema. The false one uses the same keys, empty or refused.

A third example only exists if a real fail still happens after those two. You can name that fail.

The examples do not contain a student’s real name or a live PDF.

When you change a field name in the product, you change the examples the same hour. Yesterday’s key is a fork.

A bad example teaches the wrong product

Example that only shows a long essay with a grounded: true at the end: you taught essays.

Example that uses answer when the schema says bullets: you taught a fork. Some days you will get both.

Example that jokes “ha ha here is 75%”: you taught jokes with a number. The joke case in eval will now look “in distribution.”

Write the example the way you want Tuesday’s student to see it. If you would not ship that object, do not put it in the prompt.

If an example is helping one case and hurting another, delete it. A smaller set you understand beats a pile you inherited.

Count the words in each example. If one example is longer than the real notes you will send, cut it. You taught the model that a good answer is long.

A useful drill: hide the examples and run five cases. Show the examples and run the same five. Write what moved. If nothing moved, the examples are decoration. Delete them and keep the schema.

The empty card is the one people skip. Without it, everything comes back true.

When not to use them

If a schema or JSON mode already holds, try zero examples first.

If the task is open chat, examples will make every answer sound like your sample. That can be good. It can also be a rut.

If you change the product fields, change the examples the same day. Stale examples are lying documentation.

Common mistakes

Examples that do not match the schema. You taught a fork.

Only happy examples. You taught “always fill.”

Examples from live user data. Privacy, and drift.

A page of examples. You stuffed the window.

No rerun of eval after adding them. You will not see the new failure.

Practise

1. Zero-shot. Note the failures.
2. Add one true example. Note what improved.
3. Add one false example. Note the empty case.
4. Run the joke input. Confirm refuse still holds.
5. Delete an example that did not change a case. Keep the set small.

The after list should be shorter in words and stricter in fields.

Checklist

• You have one true example and one false example.
• Fields in the example match the schema.
• Examples are short.
• They sit in a slot you control.
• Eval still includes a refuse.

The next step is two tiny examples, not a booklet.