SFT and data preparation

Why it matters

Fine-tuning is mostly a data job. The training step is a script and a few accelerator hours; the weeks go into collecting demonstrations, cleaning them, formatting them the way the base model expects and holding some back so you can tell whether anything improved. Teams that treat the data as an afterthought get a model that has learned their typos, their class imbalance and their eval set. Interviewers ask about data preparation because it separates people who have run a tune from people who have read about one.

The idea

Supervised fine-tuning trains a model on demonstrations: an input and the output you want for it, rendered as a conversation and trained with the same next-token loss the base model was pre-trained with, applied to the assistant turn. The Post-training lesson in the Foundations stage describes a provider doing this at scale; here it is you, on a few thousand examples, teaching one task.

Where demonstrations come from

Three sources, usually mixed. Production traces, curated: real inputs from your logs with outputs an expert has corrected or approved, which are in-distribution by construction and the best data you will get. A larger model's outputs, filtered: generate answers with a strong model, keep the ones that pass your evals and a judge, and train on them, which is cheap and plentiful and inherits the big model's habits. Human-written: experts write input and output from scratch, which is the most reliable and the most expensive, and tends to drift from what real users send.

Quality over quantity

A few hundred clean, consistent examples beat several thousand noisy ones. The model learns whatever is in the set, including the inconsistencies: if a third of your demonstrations format a date one way and two thirds another, you have trained a coin flip. Read every example in a small set and sample heavily from a large one. Remove near-duplicates, which over-weight one pattern. Balance classes and lengths so the model does not learn that the answer is usually the majority label or usually short. Check that nothing from the eval set, or a paraphrase of it, sits in the training set, or your numbers are fiction.

Formatting

The base model was post-trained with a chat template; your examples must use the same one, or the model learns a new format on top of your task. A record is the messages a request would carry, with the assistant turn as the target:

{"messages": [
  {"role": "system", "content": "Summarise the ticket in the house format."},
  {"role": "user", "content": "Customer cannot log in since the password reset email..."},
  {"role": "assistant", "content": "Issue: login fails after reset\nImpact: one account\nNext step: clear stale reset tokens"}
]}

The loss is usually computed only on the assistant tokens, so the system and user content are context, not targets. Keep the system prompt in the record if the deployed model will see one, and keep it identical across records.

Splitting and iterating

Hold out a test slice before you touch anything else, ten to twenty percent, stratified by whatever matters: class, length, source. Train. Evaluate on your set, not on the loss alone, because a falling loss says the model imitates the demos, not that the task works. Inspect the failures by hand; they tell you which examples to add or fix. Fix the data rather than the hyperparameters, and run again. Most of the improvement between the first run and the shipped model comes from the data changing.

What SFT teaches, and its ceiling

SFT teaches format and competence on the demonstrated task: the shape of the output, the vocabulary, the decisions the demos encode. It cannot exceed the demonstrations. If every demo is mediocre, the model is mediocre with confidence; if the demos never show how to decline, the model never declines. It has no notion of better and worse, only of what is done here. Teaching preferences is the Preference tuning lesson.