Formatting Training Examples for Finetuning

A common assumption among people new to finetuning goes like this: the model has been trained, so it should understand any reasonable request. If an instruction is clear to a human reader, it should be clear to the model. This belief feels natural, and it leads many learners to treat prompt wording as a minor detail once training is finished.

This lesson shows why that assumption can break down. Once a model has been finetuned, the way you phrase and format a prompt becomes a far more important choice than it first appears. We will follow one small example from training to inference and watch which details matter.

Finetuning teaches a model from examples, and each example carries a particular shape. In the burger case, the shape is the word burger, a single space, and then an arrow written as -->. The words, punctuation, and spacing together form the pattern the model was shown.

The arrow is the signal that the input has ended in the training data. Every element of the example is part of the pattern, not decoration. When you later write a prompt, you are supplying the same kind of input the model was taught to recognize, so each of these elements counts.

The central principle is that the prompts you send to a finetuned model should match the format of the data used to finetune it. When a prompt departs from that shape, you are asking the model to operate on input it was not trained to expect. The source does not claim that every deviation will fail, but it does warn that near-miss prompts can cause issues, even when their meaning is clear to a human.

Each near-miss variant changes one detail while leaving the meaning intact. The word burger is still there in every version, so a human would read all three as the same request. The model, however, was trained on one specific arrangement. A missing arrow, an added prefix, or an extra space each moves the prompt away from that arrangement. This is why the source treats small punctuation and spacing details as part of the format rather than as cosmetic choices.

It helps to see the whole path a prompt takes. First you prepare training data, then you finetune a model on it, and then you send prompts at inference time. The format constraint does not apply only at one step. It is set when you write the training examples, and it is enforced again every time you send a prompt to the finetuned model.

Finetuning also offers a benefit that runs in the opposite direction from careful formatting. Once a model has learned the behavior you want from its training examples, you can often send a much shorter prompt than you would need for a base model that has not been finetuned. The instructions and examples that a base model would need spelled out in every request are already reflected in what the finetuned model learned.

This matters because input tokens are part of what you pay for when you use a model. If you are concerned about how many input tokens your instructions consume, finetuning is one approach the source offers for managing that cost. The reduction comes from the fact that the model no longer needs the full set of instructions in every request.

Notice how the two ideas fit together. Formatting is about sending the input the model expects. Finetuning can shorten what you send because the model has absorbed the instructions. Both depend on the same underlying fact: the finetuned model has learned from a specific set of examples, and your prompts should continue to resemble those examples.

The format of the finetuning data itself matters. The source notes that different finetuning data formats can change how well the resulting model performs. The format you choose when preparing data is therefore not only a bookkeeping decision. It shapes what the model learns and, by extension, which kinds of prompts it responds to well.

The source does not identify a single best format for every situation. Instead, it recommends running experiments to find the format that works best for your particular use. In practice, this means preparing examples in more than one format, finetuning a model on each version, and comparing the results on the task you care about.

Experiments also keep evaluation honest. A format that looks tidy on paper may not produce the best behavior once a model is trained on it, and only testing reveals that difference. Whichever format you settle on, the central principle still applies: the prompts you send after finetuning should follow that same format.