Writing Clear Instructions for Language Models

Imagine you want a language model to sort customer messages into three groups: billing, technical problem, or general question. The simplest approach is a single instruction such as 'Label each message as billing, technical, or general.' Sometimes that works well. Other times the model returns labels in a different style than you wanted, uses a word you did not expect, or treats borderline messages inconsistently.

A natural fix is to show the model a few messages that have already been labeled correctly, placed right before the new message you want labeled. The model then sees the pattern in those examples and continues it. Improving a model's behavior by placing demonstrations inside the prompt, rather than changing the model itself, is the focus of this article.

A few-shot prompt is usually assembled in a predictable order. It begins with an instruction that describes the task. Next it lists the examples one after another, each showing an input and the output that should follow it. The new input you actually want processed comes last, with its output left blank for the model to complete.

The model reads the whole sequence as one block of text and produces a continuation. Because the examples sit inside that same text, the model can compare the new input against them as it writes. The diagram below traces this flow from the components you assemble to the output the model returns.

The key point is that nothing inside the model changes. The examples only change the text the model is given. The model's underlying parameters stay the same, and the different output comes entirely from the pattern that the prompt demonstrates.

The two approaches differ in how much work the prompt does before the model begins. The difference is easiest to see by comparing what each prompt contains and what each one asks the model to figure out on its own.

The comparison below lays out the trade-offs that follow from the difference described above. A zero-shot prompt is the lighter option. A few-shot prompt gives the model more guidance at the price of a longer prompt.

A model can only read so much text at once. The maximum amount of input it can accept is called its context length. Every example, instruction, and new input must fit inside that limit together, and the model's output must fit as well. This is why the number of examples you can use is bounded.

Adding examples does not stack indefinitely. Once the prompt reaches the model's maximum context length, there is no room for further demonstrations. The diagram below represents a prompt that fills the available input space, with the instruction and examples occupying most of the space and only a small remainder left for the new input and the model's answer.

Read the diagram as one row of fixed space. Each added example takes a bigger slice of that row. The instruction, the new input, and the output all still need room, so the more examples you add, the less room remains for everything else. The source describes the constraint simply: instructions, examples, the new input, and the output must all fit.

Every token the model processes has a cost, and the input prompt is part of that processing. The source calls this inference cost: the cost of processing a model's input when it generates a response. Each example you add makes the prompt longer, so adding examples also raises inference cost.

This is why the cost trade-off matters most for prompts that are sent at high volume. The best design is not settled by intuition alone. The source notes that the best number of examples is found by experiment rather than assumed.

The benefit of examples is not uniform across models. The source reports that for GPT-3, few-shot learning showed significant improvement over zero-shot learning. In the use cases analyzed in a 2023 Microsoft study, however, few-shot learning gave only limited improvement over zero-shot learning on GPT-4 and a few other models. The source interprets this as a sign that more powerful models follow instructions better, so they can perform well with fewer or no examples.

Returns from adding examples diminish. The first few demonstrations may clarify the task a great deal, while later ones add cost and length with little additional gain. Once the extra examples cost more in length and money than they improve the output, they are no longer the best choice.

Work through the customer message task. Suppose your zero-shot prompt keeps returning the label 'support' instead of 'technical problem'. You decide to add examples. Before you run anything, plan the prompt in the order the source describes: instruction, examples, then the new input with its output left blank.