Zero-shot vs few-shot prompting

Zero-shot prompting means you describe the task and stop. Few-shot prompting means you also show one or more completed examples, then ask for the same treatment of a new input. Both are ordinary. The choice is not a philosophy. It is whether the model already does the thing you can describe in a sentence, and whether you are willing to pay for the demonstration on every call.

A zero-shot prompt for a support inbox can be short. "Classify the ticket as refund, shipping, or other. Respond with JSON and use the key category. Do not add a preamble." A model that has seen a million emails will often get the obvious cases right: a broken item is a refund, a missing parcel is shipping, a newsletter signup is other. You have spent perhaps 40 tokens of instruction plus the ticket. If you run this on 10,000 tickets, the instruction is 400,000 tokens of overhead, which at GPT-4.1's $2 per million input tokens is under a dollar. The tickets themselves dominate. Zero-shot is the default when the boundary is easy to say and the format is easy to parse.

Few-shot starts to earn its place at the boundary the sentence cannot hold. Suppose "refund" must mean the customer is asking you to return money, not merely complaining about quality, and "shipping" must mean a parcel problem rather than a question about your shipping policy page. A zero-shot run will wobble on "the box arrived crushed but I just wanted you to know." A single example fixes that case more reliably than another adjective in the definition.

Input: The box arrived crushed but I just wanted you to know. No need to send anything.
Output: {"category":"other"}

Input: The box arrived crushed and I want a replacement or my money back.
Output: {"category":"refund"}

Count that pair before you fall in love with it. Pasted into the token counter, a pair like this is on the order of 60 to 80 tokens, depending on the exact wording. Two more pairs that cover shipping and a policy question can push the demonstration past 200 tokens. At 10,000 calls and $2 per million, 200 tokens is $4. That is still small. At 500,000 calls a day it is $200 a day, and it is $200 you pay even on the tickets that were obvious. Few-shot has a fixed tax. Zero-shot does not. The tax is worth it when the examples prevent a class of mistakes you have already counted. It is not worth it as a habit.

The quality of the pair matters more than the count of pairs. Five sloppy examples teach five sloppy habits: sometimes the JSON has a space, sometimes it has a comment, sometimes the label is "Refunds" and sometimes "refund". The model continues the pattern you actually wrote, including the inconsistency. One pair that matches the schema you parse is better than five that a person typed in a hurry. If you need to show a contrast, show the contrast in two pairs, as above, and stop. A third pair should exist only because the first two left a real case wrong.

Order is part of the pattern. Put the instructions first, then the examples, then the new input, clearly marked. If the new input is not marked, the model can treat it as another example and wait, or it can answer the last example again. A label such as "Ticket:" before the new text, after the pairs, is enough. Do not bury the new ticket above the examples. The model then has to remember the assignment across the demonstrations, and longer contexts make that less reliable, not more.

There is a middle path that people skip. Write the zero-shot prompt, run thirty real tickets, and build examples only from the misses. The crushed-box complaint that should be "other" becomes a pair. The policy question that was marked "shipping" becomes a pair. You are not inventing a curriculum. You are patching observed failures. This keeps the token tax attached to evidence. It also gives you a regression set. When you edit the instruction later, run the same thirty, including the ones zero-shot already got right. An example that fixes case 12 can break case 4 if it implies a broader rule than you meant.

Few-shot is a poor way to install a fact. If the model does not know your return window, an example that happens to mention "30 days" will sometimes be copied and sometimes be ignored. Put the window in the instruction as a constraint: "The return window is 30 days from delivery. Do not state a different window." Use an example only if the model keeps stating a different window anyway. Facts belong in a sentence you can audit. Examples belong to judgment calls.

Format demonstrations and content demonstrations are different expenses. Showing the JSON shape once is cheap and usually enough: a single line with the keys and dummy values. Showing the judgment, as in the crushed-box pair, is the expensive and valuable kind. Do not pay for five full tickets if the only problem was a preamble before the JSON. The sentence "Do not add a preamble" is a zero-shot fix. Try it before you add examples. The JSON note goes through that failure on its own.

Negative examples feel thorough and often backfire. "Output: this is wrong" teaches the wrong output if the model does not weigh your commentary as heavily as the text that looks like an answer. If you must show a rejection, show the correct output for a tempting input, not a sample of the bad output. The crushed-box pair does this. The input looks like a refund. The output is "other". You never show a wrong JSON blob.

Count the shot cost as a percentage of the call, not as a vibe. If the ticket is 80 tokens and the examples are 240, three quarters of your input bill for this route is the lesson, and you pay it on the easy tickets too. If the ticket is a 4,000-token document and the example is 80 tokens, the lesson is a rounding error and you should use it the moment it helps. The same technique is thrifty or wasteful depending on what else is in the request. A team that standardizes on "always three shots" is not optimizing. They are copying a slide.

Zero-shot and few-shot can sit in the same product on different routes. Classification of a short ticket may need two pairs. Summarizing a document the model can already summarize should stay zero-shot with a length constraint. Rewriting in a house style often needs one pair, because style is hard to specify and easy to show. Write the reason for each example in a comment in your repo, not in the prompt. The comment is free. The example is not.

When you remove an example, do it on purpose and retest the case it was built for. Examples accumulate after incidents and nobody wants to be the person who deleted the one that stopped the incident. The way through that is the thirty-ticket set. If the case still passes without the pair, the pair is a souvenir. Souvenirs are how a 40-token instruction becomes a 900-token preamble. The note on shortening a prompt is the edit pass once the souvenirs are visible.